Mobilising websites: guidelines for WRT Widgets development, part 1

jappit | 19 May, 2009 10:13

Since there's a lot of excitement around mobile Web, and particularly about WRT Widgets, I started thinking about which possible guidelines could help both Web and mobile developers to face this new opportunity. Of course, for developers already familiar with WRT and/or mobile environment, most of these points could sound quite obvious: I would be glad to have any kind of feedbacks about them, and to know which other points you consider important in WRT Widgets development.

So, let's start.

1. Widgets are not Websites

Building Widgets with Web technologies does not mean that you can reuse all common patterns found on the Web itself. Some examples are:

  • Multiple pages: Widgets are what commonly known as "single page applications". This means that, if you want to show another "page" to your users, you cannot simply let it "navigate" to another page: you have to do it by manually manipulating the DOM of the only page you have.
  • Browsers' back and forward button: you have not such a navigation paradigm within widgets since, as told, widgets do not have the standard "page" concept. So, you cannot assume that your users will be automatically able to "go back" within your widgets screens: you must take care of implementing all the navigational logic by your own. Also, no standard "reload" functionality is available: if you want to reload your Widget's content, you have to programmatically do it.
  • Content is (mainly) local: one big plus of Widgets versus mobile Websites is that you can deploy all the resources you want (textual and image ones) on the device itself, packaging them within the .wgz file itself, and avoiding the need for the user to connect to network to retrieve those resources. Of course, this makes sense only for static data, but it's anyway a point you should never forget when designing a new WRT widget.

2. Let it update!

WRT Widgets are by all means mobile applications. This means that, when you want to add or modify some of its functionalities, most of times you have to release a new version of the application itself. So, it is recommended that you implement an update mechanism within your Widget itself, so that the user can check (or the widget itself, e.g. automatically at startup) if there's a new version of your widget.

Fortunately, you can find a ready-to-use code snippet that does exactly this on Forum Nokia Wiki:

3. Create viral effect

When you're on a website, you can often suggest a webpage to a friend by sending him an email. So, why should you not do it on a mobile device? So, you could let your users send your Widget download link by email, just putting a link as the following:

<a href="mailto:test@test.com&subject=My Widget&body=Dowload this great Widget! http://www.yourwidgetlink.com">Email</a>

but, being on a mobile phone, why not allow them to send a simple SMS message? You can do it with a link like this:

<a href="sms:1234567890&body=download this great Widget! http://www.yourwidgetlink.com">SMS</a>

Both these links open up the email/SMS editor, respectively, with some precompiled data. So that your user has only to push the "Send" button.

But, wouldn't be great to integrate this functionality within your own Widget, without letting the user leave your app? If you think so (and you should :)), check out this Forum Nokia Wiki article, that explains how to send SMS messages using Platform Services:

4. Design an application, not a website

Ok, I'm insisting a bit on this point :)

Even if technologies are the same, you should be aware of the differences between approaches of an user toward a mobile website and a WRT Widget. For an end user, it has never been that important which technology you use to develop an application. Basically, if he sees an icon, he thinks about an application, and behaves accordingly. So, apart from the already mentioned ones (local content, different navigation paradigms) another important point to mention is that (hopefully) most of times your WRT widget will use a tabbed nagivation mode, or a totally custom approach implemented via JavaScript. So, differently from a Website, you'll have your users moving around jumping from a focusable item to the next, instead of moving a cursor around. Consider this, its limits, but above all the potential to build the best possible navigation for your end users.

5. Go remote only if needed (and if covered..)

This will seem quite obvious for any mobile application developers but, seeing it from a Web developer perspective, going remote isn't really an option, since the Web IS remote (ok, forget about the cache ;)). So, when mobilising your website, you should take care of considering some basic points related to network access:

  • Network traffic costs
  • Network coverage is not everywhere

So, to really use the potential of a WRT widget, when compared to a standard mobile Website, here are some key points to consider:

  • Implement your own local cache: current WRT capabilites allow you to save only textual data, and persist this data between different usage sessions, by using setPreferenceForKey() and preferenceForKey() method. By using this capability, you can avoid unnecessary requests and give more responsiveness to your Widget.
  • Design your Widget also for offline usage: this is surely not suited for all scenarios (imagine a real-time quotes widget) but, even if your widget accesses network to retrieve information, you could let your users use it even when offline, with a someway limited subset of functionalities (e.g.: you could let them view the last downloaded information)
  • Implement a delayed update mechanism: imagine you're building a WRT game with remote scores table. You could let your user play your game even when offline, and then send its scores to your server only when he's under network coverage again.

 

Feedbacks are welcome!

These are the first 5 points (not necessarily in order of importance) I would like to comment with you all. Meanwhile, part 2 of this guide is on the go :)

Browsing , S60 , Web Runtime (WRT) | Next | Previous | Comments (0) | Trackbacks (0)

RSSComments

You must login to post comments. Login
 
Featured links
Develop
Distribution
Blogs
Community
Resources
Site Map
Terms & Conditions
Privacy Policy
Nokia Developer aims to help you create apps and publish them so you can connect with users around the world.

京ICP备05048969号  © Copyright Nokia 2012 All rights reserved