Some days ago I've put together 5 first guidelines that I usually find useful when thinking about any new WRT Widget. These can be summarized as follows:

1. Widgets and Websites: same technologies, but with some differences
2. Implement an update mechanism
3. Create viral effect
4. Design an application, not a website
5. Carefully consider network connectivity

Today I would like to continue this series, with new points that will hopefully help Web Runtime Widgets developers.

6. Think about scrolling

Ok, this could perfectly be a subpoint of section 4 ("Design an application, not a website"), but I really think this point is important when thinking about a WRT widget. While scrolling is something usual on any (mobile or not) website, when you think about a widget, compared to a website, you want a slicker and faster experience.

So, while standard browser scrolling is a fast option to allow users to view large portions of data, there are surely better or refined alternatives, that will allow a better user experience. Usual scenarios, where implementing custom scrolling is a good option, could be:

• a classic widget with a header and a footer, where you want to scroll content but want to always keep fixed and visible these top and bottom bars (as well as other elements)
• a widget where you want to use and manage custom scrollbars
• a scrolling mechanism where you want to allow users to do fast scrolling (e.g.: pressing left/right keys, or double pressing up/down keys)
• a smooth scrolling (or similar) effect

While for some scenarios CSS properties will do the job (e.g.: set "overflow-y: auto" to tell a single html container to vertically scroll its content, if higher than its own height), for others you must dig into JavaScript, and write your own customized code. Check out how STEW for an example of simple, CSS based scrolling with fixed header.

7. Prepare different layouts for different resolutions

When designing a WRT widget, you basically have 2 choices:

• design a layout that adapts to different screen resolutions (e.g.: using css properties like 'width: 100%')
• design a single layout for each resolution/orientation that you want to support

While the first option could seem someway simpler, the second one turns out to be the more attractive, both for users and developers. The STEW example Widgets shows 2 different layouts for the different display orientations.

While this make sense for a simple display rotation, it does even more when you want to support both S60 3rd and 5th edition device with a single widget. Not only for the totally different display resolutions, but also for the different input methods, that allow users on 5th edition to interact by touches, so needing particular attention to specific guidelines, as you can read on Forum Nokia Library:

• http://library.forum.nokia.com/index.jsp?topic=/Design_and_User_Experience_Library/GUID-3143A96B-9285-4D4E-8BF1-1AA1E472C9AE.html

8. Use Platform Services

Platform Service really are the key for success of Web Runtime. Without them, you could not build anything more than plain, installable websites. You must not use them "because it's cool", but because their purpose its clear: access user- or device-related data, that can bring added value to your user, and so to your application. Simple examples go from access to plain network signal/battery level, to access to Location for LBS applications.

But, how to mantain compatibility between WRT 1.0 and 1.1? This Forum Nokia Wiki article shows how to check if Platform Services are supported in a particular runtime, so that you can accordingly manage your widget functionalities depending on it, without building two different versions of your Widget:

•  http://wiki.forum.nokia.com/index.php/Checking_for_S60_Platform_Services_support_in_a_WRT_widget
  

9. Use animations and transitions

Remember the "good old" mobile Web? Ok, now forget it ;)

As you probably already know, S60 browser offers a powerful JavaScript environment to perform quite cool effects within your Widget. So, don't rely on the concept of a static, overly simple mobile Web, and consider all the benefits that good-designed transitions can bring to your application. Do you want some hints, right? :)

• http://wiki.forum.nokia.com/index.php/Mobile_Design_Patterns:_Screen_Transitions
• http://www.youtube.com/watch?v=v1eqNkhh0eI 

10. It's full JavaScript, but it's not full power!

Ok, point 9 says you should not be shy to implement cool effects within your Widget. This is true, but full JavaScript engine does not mean you can do the same things you do on desktop browsers. And so, never think you can use full-blown JavaScript libraries, without worrying that much about their content and functionalities. So, what to consider before adopting a particular library?

• Its size: even if it's locally deployed (so network traffic and delay is not a problem), you could encounter slow responsiveness of your Widget if you use BIG libraries (think about Dojo)
• Its purpose: do you really need a library? Many libraries offers HTML components, but most of times they're not suitable for a mobile application, due to different factors (e.g.: screen size, different interaction modes). Also, most of times JavaScript libraries include big portions of code to solve desktop browsers' incompatibilities, but this code is (fortunately) useless in WRT environment.
• Its support: there are a lot of libraries that use objects still not available in S60 browser environment. An example is the 'canvas' object: WRT Widgets do not have it, so check if your library uses it.