Tips for Writing Bluepulse Widgets

One of the neat things about the Bluepulse mobile platform is that it makes it very easy to write a mobile application (a widget). In Bluepulse’s case, you write a traditional web application, using whatever flavor server side code you like, and ensure the output adheres to the XHTML subset specified in the Bluepulse SDK.

Because of the ease with which widgets are created, I expect that we’ll see widgets that are created by those who have no previous exposure to mobile development. And because widgets are generally tightly focused, we’re also likely to see widgets created by newcomers to the web application development field.

So I thought some tips were in order. If you’re already familiar with web applications, mobile development, and XHTML, most of these will seem obvious, but hopefully you’ll find one or two points that will be of value. If you have some tips of your own, please add them to the comments, and together we can build a handy document that can be shared with the good folks at Bluepulse, and on the forthcoming bluepulse widgets site (bpwidgets.com).

General

Find an Idea

If you’re looking for ideas on widgets to create, check out the Bluepulse forums and the Bluepulse blog. Some of the widgets described in the blog might spur some creative thinking, and several people have posted widget wish lists in the forum.

Check the Pipeline

You might also want to see if anyone else is working on your idea before you begin your work. The forums and the blog are a start, and Luke Watson at Bluepulse is a good resource. Luke is involved in Sales & Marketing, and also developer relations, so he might be able to tell you what’s in the pipeline.

RTFM

The development kit is short, and it will answer most of your questions, so you might as well read it.

Enthusiast vs. Commercial

There are two categories of Bluepulse developers: enthusiast and commercial. Enthusiasts develop free widgets and commercial developers create fee-based widgets. I’ve attempted several times, but I have yet to figure out how one becomes a commercial developer.

XHTML Format

Syntax Rules

Your web application’s output must be properly formatted XHTML. The primary rules to keep in mind for proper formatting are:

• All tags must be in lowercase
• You must include a doctype
• All tags must be closed (even single barreled tags like <br/>)
• All tags must be properly nested
• All attributes must be in quotes

Watch your entities

Probably the most common mistake is the misuse (or non-use) of entities, and the most commonly misused entity is the ampersand (&).

In XHTML, the ampersand marks the beginning of an entity. An entity is comprised of an opening (&) and closing (;) delimiter, with the entity code in the center. So any ampersand is treated as the beginning of an entity. If the closing delimiter, the semicolon, cannot be found, your document is not properly formed.

This means that a typical query string like: ?&name=widget&id=7 is invalid. Instead, it should be written as ?&name=widget&id=7.

For those of us who use Dreamweaver for UI development, older versions of DW had a helpful and altogether frustrating setting that attempted to rewrite the entities you carefully wrote. Been here before? Go to Edit | Preferences | Code Rewriting and check both encoding options. Incidentally, DW8 has corrected this and has terrific support for CSS. CSS support is alone worth the price of admission.

Validation

If your widget runs fine while testing it in your browser, but you receive “Unsupported Page Type” errors when running it through an emulator, your XHTML is likely formatted improperly. There are a number of validators out there that will help you make short work of finding the problem. View the source via your browser, and paste it into a schema validator like the one found at http://schneegans.de/sv/. It should point you right to the offending part of your document.

Double List View

At a glance, the double list view appears to be a powerful way to display summary text to a user. On the top line, place your title, and on the second line, place a longer text summary.

Unfortunately, the majority of the devices I tested on did not support the double list view, which limits the utility of it. If something is important, make sure it’s on the top line. If it’s not important, you can place it on the second line, in which case most of the text will be truncated for phones that don’t support the view. My preference is to stick with the regular list view, and support all handsets consistently, according to the bluepulse spirit.

Use Templates

I’m not a big fan of developing UI’s. I’m not that good at it, either. One of the things I like most about developing widgets is that I never have to worry about the UI. I have several templates created: list view template, text form template, and text template, and I reuse them for every page in every widget that I create. I’d recommend that you do the same.

More information on XHTML:
http://www.w3schools.com/xhtml/

Emulators and Testing

Developer Suite

I might be in the minority, but I have always had difficulty installing and integrating emulators with my IDE of choice. Nokia’s Developer Suite installs smoothly and offers 40, 60, and 80 Series emulators, along with the ability to plug-in other Nokia emulators.

International Character Support

In two widgets that I created, Ebay OnTheGo and Amazon OnTheGo, international characters and currency symbols (e.g. yen, pound) resulted in “Unsupported Page Type” errors via Bluepulse during testing.

The quickest way around this (from a performance perspective) is to use regular expressions to filter out the offending characters. I have a couple utility methods that I use for this purpose. One returns a Boolean, and one returns a clean string.

For example, calling checkRegExp(shaun@bpwidgets.com, “[^a-zA-Z0-9]”) returns true, and calling cleanRegExp(shaun@bpwidgets.com, “[^a-zA-Z0-9]”) returns “shaunbpwidgets.com.”

public static boolean checkRegExp(String value, String regexp) {
Pattern pattern = Pattern.compile(regexp);
Matcher matcher = pattern.matcher(value);
if(!matcher.find()) {
return false;
}
return true;
}

public static String checkRegExp(String value, String regexp) {
Pattern pattern = Pattern.compile(regexp);
Matcher matcher = pattern.matcher(value);
if(matcher.find()) {
return matcher.replaceAll(“”);
}
return value;
}

Peter from Bluepulse has an additional handy tip regarding character support:

“If you make sure all special characters are UTF-8 encoded, you can include pound signs, vowels with funny lines/dots and more. Some phones, particularly Nokias, allow the user to type these characters into a Text Form View, so if you use that view, you should be prepared to deal with them.”

Test on Multiple Emulators

Bluepulse takes much of the concern out of this. If it works on one emulator, it should work on them all. This is in stark contrast to the field you play on when developing a typical mobile application! Even though the widget will likely work across all emulators, you might be surprised to see how it looks across different emulators. As a sanity check, see what your widget looks like in several different emulators. You’ll likely find yourself rearranging menu items, editing screen titles, and reworking text here and there.

Test on a Real Device

Similar to testing on multiple emulators, you should test your widget on one or more real devices. Emulators will primarily point you to UI differences between phones, but testing on a real phone might open your eyes to some performance implications of running your widget. It’s also nice to see how your widget will look on the phones with which you are most comfortable – your own.

Traditional Mobile Development Tips

Constrained Resources

Always be aware that users will be using your widget on devices with limited display and data transfer capabilities, and data input is only slightly more amusing than shaving with a cheese grater. Most of the tips in this section follow this constrained resource theme.

Titles and Text

The amount of text that will appear in certain views is limited. For example, in the text-form view, long strings are truncated. Short, terse instructions are better than incomplete instructions.

Menu item title display is generally left to the implementation, though I’m not sure if bluepulse has done any work around standardizing. In traditional mobile development, both short and long labels can be provided, and the implementation decides which one to use. To be on the safe side, try to keep your labels one word long, and front-load them.

Similarly, your screen titles might be truncated, so put the most important characters at the beginning. This has improved dramatically over the years, but not so long ago, it was a real art to determine how to intuitively name your functions or screens with as few characters as possible.

Less important, but still advisable, is to make the first characters of your labels unique from other labels. This will enable users to easily differentiate among the commands available to them. Also keep in mind the potential items added to the menu by the bluepulse client, and ensure that there are no naming collisions.

Use the title of a list page to tell users what to do with that list.

Provide Reasonable Defaults

• Rather than requiring text entry, allow users to select from a list, if at all possible.
• When using lists, offer the most popular choices near the top.
• If your list only has one item, what’s the point of having a list? Just drop users to the action page.
• If you are forced to use text boxes for data entry, provide a reasonable default value.
• Whatever value a user types into that box, save, and present to them as the default the next time around.
• Persist data in a database between visits, rather than asking the user to enter it again on the next visit.

Provide Reasonable Navigation

On any page within your widget, anticipate where your users might want to go next. Provide direct navigation via the menu, rather than requiring the user to back out of an interaction. At the same time, make your widget back friendly, for those who love to mash on those back buttons.

Conclusion

That’s about all I can think of off of the top of my head. As you can see, Bluepulse takes most of the headache out of widget development, but there are still some considerations we all should all keep in mind.

Tags: Bluepulse, widgets, cell phone, mobile application, mobile development, mobile 2.0, bpwidgets