Widget Anatomy – The Keys for a Great User Experience

Widget Anatomy – The Keys for a Great User Experience

  • Comments 9
  • Likes

Previous post: Widget Anatomy – The Manifest

This is part two of my “Widget Anatomy” series which will explain the ins and outs of the Widget Framework that is shipping as part of Windows Mobile 6.5.  In this Article we will discuss the major challenges of creating a great user experience that not only looks great, but it integrates nicely with the phone and it’s snappy and fun to use.

The dark side of choice… dealing with screen DPIness

One of the coolest things about the Windows Mobile®  ecosystem is that there are many different devices with all shapes and forms for me to pick up the one that matches my lifestyle best.  All those choices do have a dark side though, there is a variety of screen resolution/sizes we need to make sure our Widgets work and look great on.

The table bellow shows all the supported Resolution/DPIs Windows Mobile 6.5 supports and as you can see it is a big table.

bb264320.wm6_2(en-us,MSDN.10)[1]

Thankfully for widget writing, there really are only two options, one that we will call HiDPI (for 192) and then LoDPI for the rest.  The reason is that, in practice, a document designed for 96 DPI (Internet Explorer on the desktop at 100%) will look fine on 96 DPI, 131 DPI and 128 DPI but it will look way too small on a 192 DPI screen.

Now that we have reduced the supported DPIs to only two, then the best (and easiest) way to handle this in your widget is as follows:

1) Generate two CSS Style Sheets for your widget. You can call them something like HiDPI.css and LoDPI.css, and the basic rule is, for HiDPI, things should be about twice as big to look the same way as they do on the desktop.

2) Detect the screen resolution at runtime to determine which CSS to load.  Here is an example:

   1: function applyCSSStyle() {
   2:     var width = document.documentElement.clientWidth;    
   3:     var cssFile = "css/LoDPI.css";    
   4:     if (width >= 480) {        
   5:         // The document is wider than 480 pixels        
   6:         // it must be a High DPI device       
   7:         cssFile = "css/HiDPI.css";   
   8:     }
   9:     
  10:     // Add the correct CSS style sheet to the document    
  11:     var headID = document.getElementsByTagName("head")[0];    
  12:     var cssNode = document.createElement('link');    
  13:     cssNode.type = 'text/css';    
  14:     cssNode.rel = 'stylesheet';    
  15:     cssNode.href = cssFile;    
  16:     cssNode.media = 'screen';    
  17:     headID.appendChild(cssNode);
  18: }
  19:  
  20: function onLoad() {    
  21:     applyCSSStyle();
  22: }

How to best utilize those SoftKeys

The Widget API gives you full control over the soft key menu bar, but since we want our widgets to behave as native  applications do there are a few guidelines we should try follow:

1. The left soft key should always represent the default action and it should be context sensitive to what the user is supposed to do at that particular step in the User Scenario.

2. The right soft key can be either a menu or a button, when there only are two possible actions you should save the user one click and make it a button… that said, if you do this there should be a way for the user to exit the widget somewhere on your UI.

Just as a quick reminder, calling widget.menu.append(menuItem) Adds a menu item to the right SoftKey, if it was a button it will turn into a menu with the non configurable label “Menu”, also, the “Exit” menu item is added automatically and can’t be renamed nor removed.  calling widget.menu.setSoftKey(menuItem, widget.menu.rightSoftKeyIndex) removes all menu items from the right SoftKey and turns it into a button.

Best practices

The following are some of the best practices we have found really help greatly widgets be the best they can be:

  1. When possible, integrate with the phone “skin” by using theme able colors like “highlight” (details)
  2. Use art assets that match the screen DPINess, or, just provide a high resolution set (shrinking is always better than expanding)
  3. Minimize scrolling, vertical scrolling is ok on some cases, horizontal scrolling in almost all cases is a general NO NO
  4. Handle the screen rotation event, remember that this must be fast
  5. Load fast, generate all dynamic content after the widget is loaded.
  6. Give visual feedback to all user actions.

  7. Next post: Widget Anatomy - Performance and Battery Life

9 Comments
You must be logged in to comment. Sign in or Join Now
  • Let me explain... When we look in different directions, we access different parts of our brain. These are called "Eye Accessing Cues." When a woman is in a bar setting and looking down, she's accessing her emotional brain.

    www.thetaoofbadass-reviews.com Tao of Badass Review

    If she makes eye contact with you, looks down then back up again, she's saying: "I have an emotional response to you looking at me and I'm looking down." And if she tilts her head down as well (and doesn't just use her eyes to look down), she's physically dropping herself a little bit lower and showing submission.

  • Mobile is becoming the future. Mobile IE browser issues are something that needs to be thought ahead of time. The scoll is definately needing speed tests and work done as I have herd of users complaining that the system is to slow.

    www.goldphotography.com.au

  • yorusan
    1 Posts

    Very well written article indeed, thank you so much for sharing such information with us, i hope we will see more from author in the future. Cheers.

  • This is great! I think reading this, I loved every word. Seriously, keep posting the good information.

  • Quikboy
    30 Posts

    It would be really more ideal if the Windows Mobile team could find a UI replacement for Soft Keys in Windows Mobile 7. In fact, replacing the old-fashioned two-paned menu system would be wonderful.

    The two-paned menu system or Soft Keys as a methd of navigationis too cumbersome in most cases, as trying to find the right task by glancing at every task and then possibly having to scroll can take longer than necessary. The two-paned menu system is also not very attractive, and belongs more on non-touch based phones.

    Instead, I'd like to see something else like redesigning the interface to avoid having to use a Soft Key approach throughout the system, and to replace the Soft Keys, there could be visual icons to represent specific tasks that users will easily remember and locate when accessing them.

    Instead, I'd recommend placing a little icon button representing "Options"

    .

  • many screen res's means more work and cost for simple apps, especially logistics apps eg: barcoding and rfid which dont require all that res! does wm 6 and 7 make life easier to

    dev for multiple screen res's??

    giovanni

    http://syrius.com.au

    http://fotografiacoppola.com

  • Wirecup
    1 Posts

    This article has a table of supported mobile screen resolutions and a rurmor I have read said that WinMo 7 would only support screen resolutions of  800x480 and 854x480 with a 3.5 inch or larger screen. I believe higher resolutions would provide a better experience in Mobile Excel for my application and have written up two suggestions.  Where can these be sent for comment?

  • Hi your_myopenid_is_broken,

    That is a really good collection of questions so I'll do my best to answer them all :)

    Q: "Therefore, the first question that has yet to be detailed anywhere, is what version of IE is actually running on Mobile devices?  Where does it fork from the IE engine (ver 5? ver 6?)... does it get patched with fixes from IE7? IE8?"

    A: Well, is a mixed bag, we started with IE6 and then we added the JScript engine from IE8, also, we integrated a ton of fixes from both IE7 and 8 for performance and memory utilization, however, other than transparent PNG support and native window.XMLHttpRequest the engine has the same DOM and CSS support as IE6 did.

    Q: Does mIE support PNG alpha transparency

    A: Yes (new on 6.5)

    2.) Does mIE support a native javascript XMLHTTPRequest object?

    A: Yes (new on 6.5)

    3.) Does mIE support flash?

    A: Yes (IE6on6 in WM 6.1.4 and greater)

    4.) Does mIE support layering content above Select elements?

    A: I don't think so (IS a limitation we inherited from IE6)

    5.) Does mIE support CSS 2.1? and CSS 3?

    A: No

    6.) Does mIE support any CSS/JS that IE8 Does NOT!

    A: No

    7.) Does mIE support any GeoLocation javascript?

    A: No

    8.) Does mIE support zooming? e.g. can it display regular web pages or does it require minimized, dedicated content?

    A: Yes, non-interactive zoom in 6.1.4 and fully interactive zoom on 6.5

    9.) Does mIE support SVG or Canvas?

    A: No

    10.) For any "NO"s above, when can we expect support?

    A: We are always working on improving our mobile internet experience and having a competitive and fully featured browser is extremely important for us.  that said, I can't reveal any product plans at the moment other than what has been announced for 6.5... but stay tuned :-)

    Jorge

  • (first off, your myopenid.org openid implementation doesn't work)

    Now onto the comment.  The IE Blog has a history of ignoring the Mobile IE browser when questions are asked, but Eric Lawrence has recently indicated that questions about Mobile IE (even though IE related) should not be asked over there, but over here instead.

    Therefore, the first question that has yet to be detailed anywhere, is what version of IE is actually running on Mobile devices?  Where does it fork from the IE engine (ver 5? ver 6?)... does it get patched with fixes from IE7? IE8?

    A quick recap of the top 10 questions about Mobile IE would be appreciated.

    1.) Does mIE support PNG alpha transparency

    2.) Does mIE support a native javascript XMLHTTPRequest object?

    3.) Does mIE support flash?

    4.) Does mIE support layering content above Select elements?

    5.) Does mIE support CSS 2.1? and CSS 3?

    6.) Does mIE support any CSS/JS that IE8 Does NOT!

    7.) Does mIE support any GeoLocation javascript?

    8.) Does mIE support zooming? e.g. can it display regular web pages or does it require minimized, dedicated content?

    9.) Does mIE support SVG or Canvas?

    10.) For any "NO"s above, when can we expect support?

    Feel free to respond in several blog posts.