One of the key points that eWEEK Labs would extract from these detailed recommendations is that a Web application should not rely on the conventions of the Web browser to handle basic tasks such as navigation among pages. Applications should detect available resources such as the size of the screen or assume the minimal base-line client discussed in the W3C document if device parameters cannot be determined.Another key point that eWEEK Labs would emphasize is developers need to accept that their applications wont always work correctly. When mobile connections arent as reliable as they are for fixed users, or when mobile users arent giving an application the same undivided attention that they might if they were in an office or other undistracted environment, its likely that there will be confusion either behind the screen or in front of it. Developers should anticipate and forestall this problem by writing applications that devote plenty of logic to limiting user choicefor example, by using drop-down lists and auto-completion of entries instead of plain fill-in text boxes whenever possible. Applications also should strive to detect errors at any point in the application stack; they should then give informative descriptions of what has happened and what the user can do about it. Mobile applications must minimize the burden that they place on the user. For example, rather than asking a user to "try again later" if a site is overloadeda browsers-eye model of the Weba mobile application should offer to retry access automatically and alert the user when a resource becomes available. The mobile user is likely to be even less tolerant than a desk-bound user of Web-based interactions that require input, then a wait, then another input, then another wait. A mobile application should do as much as possible to let a user make several choices and then dispatch the requests to the site for processing. Rather than assuming that the mobile user will watch the screen awaiting a response, a mobile application should offer the option of having a response delivered by e-mail or some other asynchronous means that lets the user look at the results at his or her convenience. Mobile applications should also be more discriminating than typical Web applications in offering the user access to hyperlinks. The desk-bound user with a high-speed connection may not mind loading a sizable PDF file to answer a simple question, but the mobile user may lack the bandwidth or the screen space to use that resource. Developers should give their applications the capability to look ahead down the links that they provide and offer the user a simple indication of whether content at that destination is suitable for retrieval and use by a mobile device. The curves of mobile application usage are on steeply upward slopes. An application thats begun this year, without consideration of future mobile access issues, is an application that will have to be replacednot merely refinedbefore the decade is out. Peter Coffee can be reached at firstname.lastname@example.org. Check out eWEEK.coms for the latest news, reviews and analysis on mobile and wireless computing.
The application itself should then present content, offer choices and respond to user input in a way that suits that context.