• Home
  • Events
  • About
  • Rich(Mobile) != Rich(Desktop)

    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.

    After having a look at different architectural approaches (ranging from device-specific fat clients to browser-based generic Web applications), we decided to go with an in-between approach: a GWT application tailored for mobile devices that runs in a generic, JavaScript-enabled mobile browser and connects to a server-side service infrastructure to fetch data and post back state changes.

    For the target devices, we used a brand-new iPhone and an older iPAQ (about two years old, running Windows Mobile 2003).

    The back office application is written in server-side Java, using UltraLightClient as the RIA technology.

    Here is a screenshot of the mobile client:

    Showcase application: mobile screen

    Here is a screenshot of the corresponding back office application (click on the image to view a larger screenshot):

    Showcase application: Back office screen

    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:

    • whereas the generic, browser-based approach supports any device that hosts an up-to-date browser (with JavaScript support enabled), it also prevents a tight integration into the device itself: the look and feel is not completely “native”, its usability may be different from the concepts known from other device-native applications, and the application shows a “low fidelity”. In addition, the reuse of existing device-specific applications such as map tools, address book or telephony application is either impossible or only achievable in a device-specific way (e.g. the iPhone supports dialing numbers from a website that are encoded as a URL with link type “tel://”, other devices may support the “callto://” link type, others may not support this functionality at all). A browser-based mobile application is somehow isolated from the device, running in its own world. This is especially irritating as two of the most current developments in the mobile world, Google’s Android and Sun’s Java FX Mobile, propagate an application model that is based on the reuse of existing applications available on the mobile device.
    • one evil thing we know from the desktop world also holds true for the mobile world: browser hell. There is no „write once, run anywhere“ (not even with GWT’s cross-browser abstraction layer). This is due to the fact that there are various different mobile browser products and versions available on the market. Some of them are state-of-the-art and support a wide set of JavaScript and CSS features, others provide no JavaScript support at all (or only a very small subset of the language). Some of the good browsers are not available for free (such as Opera Mobile). Tweaking CSS properties and pixels was part of the daily business while developing the showcase application.
    • in mobile scenarios, (bad, broken) connectivity is an important topic, and so is offline capability. Thanks to the client-side JavaScript-based approach of GWT, offline “reading” is possible to a certain extent, but modifying data offline and synchronizinig the changes back to the server has very narrow limits in a browser-based world. Typically, there is no on-device persistent storage (such as a local database) available for browser-based application, as the browser builds some kind of a sandbox for that application. Ideas and projects such as Google Gears aim to ease those limitations, but currently require the installation of additional software (i.e. a browser plugin) on the mobile device.
    • 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!

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Leave a Comment

    Time limit is exhausted. Please reload the CAPTCHA.