Typical Design and Development Issues with Mobile Applications

Screen Size

Compared to desktop and laptop computers, mobile phones have a smaller screen size. Since all relevant information has to be squeezed into a relatively limited space, page layouting becomes a challenging task. As lengthy scroll-down lists are not user friendly, the instructions on each screen need to be narrowed down to the crucial information. That means designers need to avoid long text sessions and big graphics. Further complicating the design challenge, mobile applications can only display one window at a time, making multitasking difficult. Consequently, it is important that the individual screens form an intuitive screen flow.

Navigation

The majority of mobile phones are navigated only through a number of fixed buttons controlling discrete, predefined areas on the screen, e.g. a navigation key or roller wheel [88, p.77]. In contrast to platforms with a continuous pointing device such as a computer mouse, mobile phone applications are less flexible. One design development to counter this was the introduction of the Softkey, a button that dynamically performs whichever function is currently displayed. However, real flexibility is only achieved by new generation phones that simplify these navigation issues with touch screen technology, for example the Apple iPhone [89]. Then,

for each application the navigation elements can individually be designed and loaded on the screen, which is yet impossible with fix or soft key buttons [90].

Bandwidth

Bandwidth is an important consideration when developing internet applications for mobile devices. In recent years, browsing average web pages has been enabled by the introduction of 3G networks such as UMTS (Universal Mobile Telecommunication System) with typical transfer rates of around 384 kbit/s. However, developers need to consider that many users only have slower 2G or 2.5G connections, like HSCSD (High-Speed Circuit-Switched Data) with 14.4 kbit/s or GPRS (General Packet Radio Service) with 80.0 kbit/s maximum downloading rates. Displaying data-intensive multimedia content, such as video or high resolution pictures can be very frustrating due to long download times.

Limited battery power

Every command and initiated process on a mobile device requires processing power and battery consumption, which is a rather scarce resource on mobile devices. One can prevent unnecessary battery consumption by considering low-power architectures for mobile devices, e.g. storing complex algorithms on the server side and using the mobile frontend as a thin client whenever possible.

Programming Platform

There are many types of mobile devices, ranging from basic voice-centric phones and enhanced smart phones with Personal Information Management (PIM) functions to wireless information devices and all kinds of hybrids in those categories [88, p.63]. Furthermore, they run on different operating systems (e.g. Symbian, Windows Mobile, Palm OS, Mac OS X, etc.) that support various application programming interfaces (API) for the development of custom software in the specific device category. Some of those APIs are proprietary and not cross platform compatible, e.g. the .NET Compact Framework or Python, which is limited to Microsoft or Nokia (S60 Series) devices. Another popular platform is the Java 2 Platform Micro Edition (J2ME), a set of Java APIs for software development on constrained devices, such as mobile phones or PDAs (Personal Digital Assistant). The benefit of J2ME is that its applications are compatible to a wide range of mobile phones. The related J2ME configuration, CLDC (Connection Limited Device Configuration) is supported by 99% of all currently sold phones [91], basically embracing all mobile phone owners as potential users.

A significant drawback of J2ME as well as applications from all other platforms mentioned above is that they need to be installed before usage. This can sometimes be a significant barrier of uptake for non-technical users who are challenged by the installation process. With browser- based applications on the other hand, one only needs a single application, that is a mobile internet browser to access an unlimited number and various types of web-based applications. However, mobile web applications require a decently fast internet connection, and, depending on the service provider and type of contract each new page request may cost money.

CityFlocks utilizes a web-based system architecture for a number of reasons. When developing an information system, the highest priority is to make sure that as many target users as possible can access it. As the target group of CityFlocks covers all tourists and residents of a city, the user demographics and types of mobile devices to be addressed are diverse. Thus, the application has to be cross platform compatible, running e.g. on Symbian driven mobile phones as well as Microsoft or Palm devices. Second, as many people decide to use such an information service rather spontaneously, they should not be required to run through an installation process first, but provide instant access. As described above, a browser-based application bypasses both of those issues. Besides a one-time installation of a mobile web browser, there is no installation necessary for mobile web applications. However, internet enabled phones usually come with a preinstalled browser, for example the Opera Mini Browser [92]. Furthermore, they are

compatible with all platforms and mobile phones that support mobile web. The web based architecture brings some additional benefits to the development of CityFlocks as a mobile information system:

• Seamless updates: The core logic and functionality of a web application is usually on the server side. That means that the system can be upgraded with new features without asking the users each time to install new, updated versions of the client. This characteristic, referred to as “perpetual beta”, is used by many successful business on the web. For example Google services, such as Google Mail [93], Google Calendar [94] or Google Text and Tables [95]

• Low-power architecture: As a typical web service, CityFlocks uses the Hypertext Transfer Protocol, a request/response protocol between a service requestor (client) and a service provider (server). The client makes a HTTP request, which is then processed on the server side and the results are sent back as a dynamic HTML page to be displayed on the client again. As the data processing, such as database retrieval and formatting happens on the server side, the mobile device is a rather thin client that needs much less computation - and thus - power resources.

• Multichannel capabilities: The fact that CityFlocks is operated on a web server makes it accessible not only to mobile devices, but for any device that is connected to the internet. Later in this thesis the multichannel quality and inherent flexibility of the web architecture will be shown on an additional output interface, a GoogleMaps mash-up application that provides a geographic overview of all stored comments in the database (Section 5.3.2). Section 5.4 will discuss some other use scenarios and value added services that this flexible web architecture affords.