Shortly before the end of last year, we completed a mobile demo application, which we used to analyze and investigate the status of Rich Internet Applications (RIA) technologies for mobile devices (what we will refer to as “RIA4Mobiles” within this blog post) .
The showcase application we developed describes the following scenario: field engineers use a mobile device to receive their daily work tasks or orders (called “mission” in our application) which they need to complete for that day and to communicate certain states such as “starting to work on mission X” or “completed mission Y” to a back office team application. The field engineer can use the mobile device to book the time spent and material used for a certain mission, so that the back office team can directly process the billing once a mission has been completed. In addition, the back office team can send “high prio” missions to a specific field engineer.
The back office application is written in server-side Java, using UltraLightClient as the RIA technology.
Here is a screenshot of the mobile client:
Here is a screenshot of the corresponding back office application (click on the image to view a larger screenshot):
Instead of going into the gory technical details here (we will do that in a future posting), let me discuss some of the lessons learned:
First, the approach chosen (GWT application + “Web services”) works for mobile applications. We were able to deliver the mobile application to the mobile device. Nevertheless, there are some shortcomings:
- even in times with high-end mobile devices such as the iPhone, performance issues on mobile devices are ubiquitous. The rendering performance is often poor, resulting in disturbing lags when rendering large option lists or tables (on the iPAQ device, even DOM manipulations on small HTML-based tables lead to unwanted “update effects”).
In addition to these shortcomings, rooted in the architectural approach chosen for the showcase, another thing became obvious to us: Rich(Mobile) != Rich(Desktop):
- one important difference when it comes to “rich”, especially related to the usability aspect of richness, is the fact that on mobile devices, users do not have a mouse pointer. Mobile users use either a pen, their fingers, or a navigation button (for devices without touch screens). These facilities reduce pointing precision. There is no “mouse move” equivalent as there is no difference between moving the pointer and activating the pointer (as soon as you touch the screen, an event is triggered). This reduces the number of available gestures and thus, prevents applications from using some of this gestures for interaction (e.g. hovering effects or tooltips are normally not supported on touch screen devices due to the lack of “mouse move” events). A further effect of the reduced set of useful gestures for mobile devices and the corresponding pointing devices is that gestures often get “overloaded” (on the iPhone, for example, dragging means “scroll the web page”, and not “perform a drag and drop operation”).
- the set of useful UI widgets is reduced as a consequence of the low-precision pointing device and the small screen size. Widgets such as spinners that allow toggling a value up and down using small arrows is not very usable on a mobile device, the same applies to scrolling in large lists (guess why the iPhone provides enhanced support for selecting a value from a combobox shown on a Web page).
- the general layout-policy for mobile devices differs from desktop-based RIAs: whereas on desktop RIAs, layouts such as the dock layout are often used to provide as much flexibility to the user as possible and let the user choose almost any desired application with as little clicks as possible, mobile applications use a stack-based layout that limits the information displayed and the actions available to the user at a given moment. A mobile application needs to reduce the application context to the most important information and actions at any given time. This layout resembles the page-based approach of old-school Web applications that the one of modern RIAs.
The bottom line: RIA4Mobiles developers will need to focus a lot more on usablility, device limitations and richness compared to the development of desktop RIAs in order to deliver highly usable, responsive and appealing mobile RIAs.
All in all, RIA4Mobiles is an exciting new application area. Stay tuned to hear more about our showcase application!