What is the user doing when he is running an application? How is the mobile device used differently from the desktop computer? What special scenarios arising from mobile must you consider different from the desktop? These are all questions considered in User Context.

User Context is consideration for what the user is doing and where he is when he is using your application. The mobile device is different because it is mobile. It can be used in noisy, crowded environments. It may be used in bright environments. The user may be in a situation where he has time to interact with his device only for a small amount of time and only with partial attention and not the long interaction timeframe typical with a desktop.

Mobile applications, therefore, are typically designed to do one task or activity well. The user may be doing something else while using your application. Consider this when designing.

What else do you need to keep in mind when designing your mobile application? Obviously, the mobile device has a much smaller display than a desktop device. How do you need to change your application layout and interaction paradigms to accommodate this difference in user interaction? Input methods are usually different for a mobile device. How will this impact your application design?

How does the environment affect how the user interacts with his device? Is this application intended to be used when one-handed operation is critical? Are you expecting the user to quickly check for a particular piece of information, or will the user be engaged in a protracted interaction?

Furthermore, the device is always on and always connected. Your application can be designed to send notifications to the user at odd times. Because the device is with the user all the time, he will get the notification at any time. The device demands instant interaction, so long wait times are not acceptable.

The application needs a consistent style when interacting with the user. It can't force the user to do extra thinking or remember additional things. The mobile device should be an easy-to-use extension of daily life — not a mandate to memorize different interaction methods.

Finally, the device is extremely personal. A smartphone is typically used by a single individual and not shared. It should, therefore, be easy to customize and personalize. The mobile device can quickly become an extension of the user; an integral fashion accessory, it is now an inseparable element critical to his daily routine.

There are technical considerations for mobile design as well. Though mobile devices are similar in specifications to the desktops of yesterday, they are still not as powerful as today's desktops. You must therefore keep an eye toward the limited resources available for mobile. Memory, both dynamic and non-volatile (analogous to a PC's hard drive) are limited. The CPU is also typically less powerful than that available on a desktop.

When designing your application, you must take these limited resources into account. In choosing algorithms, try to select those that require less memory. When designing data structures, avoid wasted memory. It is critical to spend the extra time upfront to ensure your memory allocation is as efficient as possible.

You also need to design your application so that it can handle situations when such device resources as memory are low or exhausted. Typically this is implemented by handling a signal or message from the system telling you that the system is out of resources. When this happens, your application should make an attempt to free up resources by cleaning up any unnecessary memory usage. You also need to handle the case where a forced application shutdown is imminent. In this case, the application should save state if necessary and prepare to exit immediately.

Bandwidth is also limited on a mobile device. When designing your application, be efficient about how data is requested over the network. Request only the data you really need. Can you prefetch data so that when the user accesses it, the download appears much faster than it actually is?

Additionally, you must code for corner cases not always present in the desktop world. On a mobile device network, coverage is frequently lost and regained. You need to ensure your application gracefully accommodates an unexpected switch into offline mode.

Another common case is low battery. Your application can query battery status and take appropriate action when the level is too low. You can send a message to the user, for example, or switch the application to a mode where less power is consumed. This is not always possible but, depending on the application, it may be possible to trade performance for less battery usage, such as reducing the framerate of video playback application. Below is some example code using Qt (from the Qt Mobility Project) where battery status is monitored and an appropriate message is sent to the user.

void Dialog::displayBatteryStatus(QSystemDeviceInfo::BatteryStatus status)
{
    QString msg;
        switch(status) {
        case QSystemDeviceInfo::BatteryCritical:
            {
                msg = " Battery is Critical (4% or less), please plug in the charger.";
                QMessageBox::critical(this,"QSystemInfo",msg);
            }
            break;
        case QSystemDeviceInfo::BatteryVeryLow:
            {

msg = "Battery is Very Low (10%), please plug in the charger soon";
                QMessageBox::warning(this,"QSystemInfo",msg);
            }
            break;
        case QSystemDeviceInfo::BatteryLow:
            {
                msg = "Battery is Low (40% or less)";
                QMessageBox::information(this,"QSystemInfo",msg);
            }
            break;
        case QSystemDeviceInfo::BatteryNormal:
            {
                msg = "Battery is Normal (greater than 40%)";
                QMessageBox::information(this,"QSystemInfo",msg);
            }
            break;
        };
}

So you see, in designing mobile applications, you need to consider a range of factors. The device is physically different, both in terms of physical characteristics, such as display size or input methods, and the components of the device, such as memory and processor. Furthermore, the environment in which the user interacts with it is different. These are all factors that must be considered when designing your application.

Consider designing for different cultures when planning your application. Obvious cultural factors include different languages and different methods for text entry. But different cultures also can have significantly different design aesthetics. Remember this when designing your application.

Even the use of color can have cultural significance. In Western cultures, white commonly connotes freshness and purity; in Eastern cultures, white can be a symbol for death. Fundamental symbolism can be radically different across cultures. Testing with real users is the best way to avoid these pitfalls.

Forum Nokia describes characteristics for four of the major mobile markets — China, Europe, India, and the US.

China is a market composed of heavy mobile users. There is more emphasis on leisure time use of the mobile, and user interfaces tend to be more busy and crowded. Chinese users also are typically heavy users of the mobile internet.

Europe is a more mature market for mobile. The market is composed of many different countries, ethnicities, and languages so there can be much variation. Generally the design aesthetic in Europe calls for simplicity, clarity, and a logical flow.

India is a diverse marketplace with huge potential. It is the largest market for entry-level devices. Therefore, there is a preference for applications with lightweight technical requirements. The mobile phone can be the user's first real contact with technology. Like China, the "more is more" principle applies.

The US is a massive mobile market recently caught up with the rest of the world in terms of mobile data and mobile application usage. American pop culture spreads rapidly around the world, making the US an epicenter of new ideas and styles. Americans appreciate ease of use, so that a long list of features sometimes is less important. Americans also appreciate a good visual and tactile experience.

More detailed analysis of these regions can be found in a series of four Design Update articles from Forum Nokia at:

Why are you building the product? In this phase you outline the basics to understand what you want to do and why you are doing it. Did you identify a market need that is not currently being met, or are you planning to improve a product that already exists.

This is also a good time to start choosing your technology approach. Will you use a native SDK like Qt, or will you use HTML5? Is there a new technology that now makes things possible that weren't before?

At this early stage, you should understand what you are trying to accomplish, as well as the constraints you are under — both business and technical — in order to get it done.

You should understand your target user and the marketplace you are aiming for. You should also learn about competitors and why your product is better than theirs.

In the next section we talk about research, which will help you better understand the information you need to move forward.

Why do research? It can help you generate or evaluate ideas, clarify your product's strengths or potential, understand strengths and weaknesses of competing products, and understand how your user will use your product.

There are two main types of design research: quantitative and qualitative. Quantitative research focuses on gathering and analyzing numerical data. The output is usually in the form of charts, tables, or graphs. An example of quantitative research data collection is counting the number of times a user does a particular task during the day, such as checking his calendar appointments.

Qualitative research attempts to cast a wider net and gain a more holistic understanding of how your product will be used. Some techniques commonly used in performing qualitative research are observation, interviews, and photographic studies.

Observation, as the name sounds, means to observe someone doing something. This can be as simple as sitting on a park bench watching how people interact with their mobile devices. Or it can be more structured observation, such as giving the user a particular task assignment and seeing how he accomplishes it. For example, you might ask, "How would you view the vacation photos you took last summer?" Structured observation can involve shadowing, following behind someone in their day-to-day activities, or undercover study. In an undercover study, you pretend to be someone for the sake of observation — a bank customer, for example, to better understand the process of creating a new account.

Interviewing means talking to people and asking about how they perform a task or use a product. When interviewing, remember that what people say and what they do can be very different. Some useful techniques for interviewing are story telling or desk tours. In story telling, you ask the participant to walk you through some of his activities as though he is telling you a story. In a desk tour you examine part of the participant's life much as you might the contents of his office desk. You walk through each part in detail to try to gain an insight into the overall desk situation.

Photographic studies mean taking pictures of people, places, and things you are interested in. Afterwards you can group the photos to make observations and draw conclusions.

It is also possible to gain much information by researching on the Internet or reading documentation. This is especially useful for gathering market data and understanding competitor's products. Remember, though, that reading information is no replacement for getting out and talking to real people.

Remember to document your findings. Also, it is good practice to involve the project stakeholders in the research process as much as possible from the very beginning.

Now that we've completed our research, let's start designing our app. Conceptual design is the stage where you start thinking about your application's main features and flows.

Brainstorming is one technique that can be a good place to start. It also gives you a chance to involve your entire team in the creative process. To brainstorm, gather all team members and give them 10 to 15 minutes to design on their own. Then members share their ideas. In brainstorming, it is important to make everyone feel comfortable to share ideas no matter how crazy. It is also a good way to generate new ideas and can foster a sense of ownership and buy-in from the team.

Sketching is a useful technique for communicating ideas. Pick some of the top ideas from brainstorming and develop those further using sketching. Sketches are quick drawings that begin to bring the product to life in a visual sense. They can also describe technical aspects, such as flows or diagrams.

The next step is to define scenarios, also called use cases. Scenarios tell a story of how your product will be used. A scenario for an e-mail application, for example, might be "create a new e-mail and send it to someone in my contacts list." These are very useful in understanding how all the parts fit together to allow the user to accomplish a particular task. They are also useful to help team members understand how the product will really be used. This will help the developer make better decisions when designing and building the product.

The goal of conceptual design is to synthesize business goals, initial ideas, and research into a product idea. If you have a good idea of what the product is and how it fits into the marketplace, then it is time to move to the next step in the process, interaction design and prototyping.

Interaction design is the next step, a point at which your product or application is designed in greater detail. Ideally interaction design should be coupled with prototyping. A prototype is an early implementation of your product or application, one that can begin to allow real interactions. Prototyping allows you to validate, test, and then evolve your design based on real feedback.

Interaction design is the act of defining the touch points, behaviors, and interactions involved with a product. It can include specification of hardware and software controls and affordances; system logic, including background processes and states; and system feedback, such as notifications and alerts. It can also include manipulation models, such as touch or gestures, animations, sounds, and vibrations.

Good interaction design encompasses these elements:

Consistency is important to ease the user's cognitive load. Inconsistencies force the user to think and remember more than necessary, contributing to a more painful user experience. It is important to build a level of trust with users. Otherwise, they will not trust your company or brand for future iterations.

Your product should be clever. How do you define a clever product? That's a good question with a difficult answer. How does one define a beautiful painting or a fragrant flower? This gets to the essence of design — yes, design has core elements that need to be taught and studied, but truly great design is like great art. Throughout this chapter we give rules and guidelines for building great products, but I can give step-by-step guidance for creating a clever product only as easily as I could give step-by-step guidance for creating a great painting or sculpture.

Lack of responsiveness can cause the user to wonder if the application is broken. Most times the perception of responsiveness is as important as the application's actual responsiveness. So even if your application takes some time to perform a task such as accessing the network or doing a long calculation, it is important to give the user an indication that the application is doing something and still able to take user input. And lastly, playfulness is important even for adults. Remember that a mobile device is very personal and usually carried 24 hours a day. All work and no play does indeed make Jack a dull boy.

Documentation is very important in interaction design. It is useful to communicate your product vision and helpful to clarify your thoughts when the ideas are being formed. Documentation specifies how your application should work. It should include descriptions of application architecture, flows, states, views, data structures and bindings, components, and content, such as strings, tool tips, and alert text.

Documentation is useful only if people read and understand it, so it should be concise and should communicate ideas you are trying to express. Remember that a picture is worth a thousand words, so that it is often better to communicate your ideas with pictures or diagrams, rather than only text. Some useful types of documentation are navigation maps, task flow diagrams, wireframes, and prototypes.

Navigation maps are one useful form of navigation, like the one seen in Figure 2-1. Navigation maps show the hierarchical structure of your application and document the interconnections between views.

Figure 2.1. An example navigation map (courtesy Forum Nokia)

Task flow diagrams (shown in Figure 2-2) are another type of diagram used to document applications. These diagrams document the flow a user can go through to achieve a certain task. This drawing usually includes decision points where the flow can change based on system state or the user's input.

Figure 2.2. An example task flow diagram (courtesy Forum Nokia)

Wireframes (shown in Figure 2-3) present a visual representation for how the application will look without specifying the visual or industrial design. Wireframes show placement of functional and structural visual elements, such as buttons, check boxes, input fields, scroll bars, and so on. Wireframes show the different application views and also how the views are related to each other.

Figure 2.3. An example wireframe diagram (courtesy Forum Nokia)

Prototypes are perhaps the most useful method to document your interaction design. They can be used to document your current design and as a means to iterate and expand the design for the future. Prototypes should be quick to build and quick to modify, so that new ideas can be evaluated in a timely manner. A complex prototype can quickly become useless if the design has evolved rapidly beyond what the prototype can show.

Instead of one large all-encompassing prototype, it may be more efficient to make multiple smaller prototypes that focus on a single feature or experience of the application. Furthermore, prototypes do not need to be actual working code. Some application behavior can be represented and explored using a static visual representation, such as PowerPoint or even drawings on pieces of paper.

Flowella is an interaction design and prototyping tool available from Forum Nokia. It is meant for designers and other nonprogrammers to quickly prototype and interact with UIs during the design and development process. The tool allows you to quickly and easily add navigation and flow information to visual assets, then play with the resulting prototype on a desktop simulator or on an actual mobile device using Flash, web widgets, or even QML. The graphical assets can be anything from simple sketches or wireframes to production-ready artwork. Flowella allows an easy creation of device-ready prototypes, so it is a cool way to quickly generate lots of real-world interaction data.

Let's take a more detailed look at Flowella by walking through an example. Let's imagine we want to design an application to look at data of recent earthquakes. We probably want to see all the recent quakes displayed in a list. When you touch a single quake, we want to go to a details screen that shows more information about that particular event. Finally, it would be cool to display a map with the location and magnitude of all the quakes. Let's call the app Shake. We can get the data from USGS web feeds, but for now we're only worried about the UI We'll talk more about this application when we implement it using first the QtSDK and again using HTML5. In this section, let's focus on the visual and interaction design of Shake.

Installing Flowella

Let's get started by downloading and installing Flowella. You can get it from Forum Nokia here:

www.forum.nokia.com/info/sw.nokia.com/id/7557c13f-0b43-4805-85ce-8414bfbade57/Flowella.html

Flowella is built using Adobe Air, so you need to make sure Air is installed as well. If you don't yet have it on your PC, download Air from here:

http://get.adobe.com/air/

Flowella includes the application, a short tutorial, and an example podcast application. Let's launch Flowella and take a quick look at the UI. The Flowella UI contains five work areas:

• Library

• Workspace

• Toolbox

• Top menu bar

• Preview window

Flowella is shown in Figure 2-4 below.

Figure 2.4. The Flowella desktop.

The library is displayed on the right side of the Flowella workspace. This contains the graphic images that you will drag into Flowella. These images are then dragged into the workspace to construct the flows. The workspace is the large area in the center of UI where you arrange and connect your views. The toolbox is a floating command box with buttons to zoom in, zoom out, and preview. The top menu bar gives you access to things like saving your project and adjusting project settings. Last, the preview window opens as a separate popup window when you launch a Flowella preview.

Now let's get started designing Shake.

Create Views

First we need to create our views. In Flowella each view is a graphical representation of the display. This can be production-ready art or a simple sketch that has been digitized with a scanner. Flowella applications do not contain any application logic; it is designed only to prototype user interactions. Flowella can understand images formats in png or jpg. For Shake, we have four views:

• List view

• Selector view

• Map view

• Detail view

These four views are shown in Figure 2-5 below. You should save these images using an easy remember names such as List, Select, Map, and Details.

Figure 2.5. The four views used in the Shake Flowella example.

Create the Project

Let's now create a new project. Select File

Next, drag the images from the library to the Flowella workspace. Let's start by dragging only the list view. When you define a Flowella project, you need to tell Flowella which view to launch when the app is started. You do this by dragging the Start Point in the Flowella workspace (the Start Point is visible in Figure 2-4 previously) to the view where you would like the app to launch from. For this example, drag the Start Point to the list view. Finally, drag the details view to the workspace. Now we are ready to connect the two views together.

Create the Connections

The next step is to connect the views together. This is done by defining hotspots for each image. A hotspot is an area that when pressed by the user causes another view to open. To create a hotspot, first click the view where you would like to create your hotspot. This should cause the view to become much larger so you can see the detail more easily. Next, use the mouse to click-and-drag to define a rectangular hotspot area. Let's do this by creating a hotspot around the first list item in the list view. This is the item labeled Oklahoma City Urban Area. After the hotspot is created, it should look something like Figure 2-6.

Figure 2.6. Creating a hotspot around the Oklahoma City Urban Area list item

After the hotspot is created, mouse over the hotspot to make the controls visible. The hotspot has three main controls: a button to delete the hotspot, seven resize handles that can be dragged to resize the hotspot, and a connector. The connector is the dot with an arrow in the center of the hotspot. This is what you use to assign an action to the hotspot. These controls are shown in Figure 2-7.

Figure 2.7. Hotspot controls.

To tell Flowella which view to go to when the hotspot is touched, click on the connector dot and drag the area to the view that you would like to be activated when the touch spot is touched. For our example, drag the touch spot for the Oklahoma City quake to the details view.

Tip

When the view is enlarged, it sometimes will cover the view you would like to indicate as the target. When this happen simply grab the enlarged view by its gray border and drag it out of the way to expose the intended target.

Note that because Flowella does not allow any kind of application logic or data processing, we must manually link one particular item to a static image of details for that item. This is because Flowella is targeted at prototyping visual interactions and navigation flow, not full application functionality.

We have created one connection: from a list item to the details view. Now let's complete the application flow by creating the following additional connections:

• Connect the title bar of the list view to the selector view.

• Connect the title bar of the details view to the selector view.

• Connect the back button of the details view to the list view.

• Connect the map and list buttons of the selector view to the map and list view, respectively.

• Create a hotspot on the map over Oklahoma City. Connect this to the details view.

Your completed flow should look as shown in Figure 2-8.

Figure 2.8. The completed Shake prototype in Flowella.

Now click on the Preview button in the Toolbox. The preview popup window should open and let you try your application interaction. Try it out. What do you think? Is this the type of interaction you would like to see for Shake?

Export and Interact

One of the coolest things about Flowella is that it is so easy to preview your application on a real device. To do this, you need to export your prototype to a format that can be installed on a device. The supported formats are Flash, QML, and web widget.

Exporting your prototype is quite simple. Go to the top menu and select File

Tip

When exporting to Flash, make sure to copy all the files to your device. There are a number of files created, including images, XML files, and a SWF file. Make sure to copy all of these to your device. Just click to run.

Tip

When exporting to WRT format, the files are saved as a .wgz formatted file. This file type can be run on Symbian, but not MeeGo devices.

Visual and information design determines what your application looks like. It includes designing the layouts, copyrighting, colors, fonts, graphics, icons, animations, and transitions of your application. The visual aspect of your application is often the first thing the user notices, so it is important. Strong information design promotes strong usability of your application. It can highlight and prioritize critical elements, and help clarify the purpose of UI controls. A beautiful product can enhance your company's brand and image and will definitely help to market your product.

Detailed tips on visual design are presented below. This section is based on information presented by Forum Nokia. More complete information can be found on the Web here:

Screen Size

When designing the visual appearance of your application, consider screen size. Depending on the device you are targeting, screen sizes can come in a wide variety of resolutions from 120 × 160 (or less) up to 360 × 640.

Furthermore the physical size of the display is also very important. Consider the three devices shown in Figure 2-9. All have the same resolution of 320px × 240px, but because of the difference in screen size, graphics displayed on one can look very different on another.

Figure 2.9. These three devices have the same resolution, but different physical screen sizes (courtesy Forum Nokia)

Consider all possible display resolutions and dimensions when designing the visuals for your application. Test on real devices as much as possible.

Full-Screen Usage

Use full-screen mode where appropriate for your application. Full-screen mode means your application takes up the entire screen and does not show any system chrome, such as battery-level or signal strength indicators or application title bars. In some cases, such as watching a movie or web browsing, it is desirable to use all available screen real estate.

There are three rules for full-screen usage:

1. Use full-screen mode when appropriate.

2. The UI can look different.

3. The visual look may vary, but the application behavior should remain the same.

Figure 2-10 below shows an example of the Symbian photo application. In this case the application designers felt it was important to use the entire screen area to display the photo. The UI does not look like the standard Symbian UI: there is no header and the controls do not look like standard Symbian buttons or menus. This is a good illustration where full-screen usage is desired to present great photo viewing to the user, yet the application functionality is not compromised.

Figure 2.10. The Symbian photo application is an example of full-screen usage

The last step in the design process is testing and evaluation. Until your product is tested with real users on real devices, you cannot know for certain whether it is successful. The mantra here is test early and test often. Test on real devices. Test with real users. Iterate until your product is perfect!

For more information on testing, we will return to this topic in more detail later in Chapter 8.

Gestalt is a German word meaning shape or form. Within the context of design, gestalt refers to a design's wholeness, which is more than the sum of its parts. Gestalt emphasizes how the different parts of a design interrelate. Key principles of gestalt perceptual organization are:

We don't have space to cover the gestalt principles in detail in this book, but an excellent introductory article can be found at the Forum Nokia web site here:

Unity is another important goal in design. Unity means the entire application fits together as one. To achieve unity, gestalt principles are applied to these design elements:

Again, for excellent coverage of Design Unity, please look at the Forum Nokia web site here:

We have presented a good, generic multistep framework for how to approach the product design phase of your application. Now let's jump into some specific tips guiding you toward good usability and visual design.

Navigation is the process by which the user travels through your application to get information or perform a task. Using a mobile device, we often have only the user's partial attention so navigation should be simple. Unlike a desktop, we cannot have multiple views at one time, so there is a temptation to lead the user through a long series of screens to get to where he wants to go. This should be avoided.

Don't force the user to configure things that can be configured automatically. A clever application can learn from the user's behavior, and additionally allows the user to manually change options that the system incorrectly assumed.

Plan for user customization.

Consider whether your target device is touch (the user can interact with the device by touching the display) or non-touch (the user must use hardware keys to interact with the device), or a hybrid combining both. This will fundamentally determine the navigation paradigm for your application. In recent times, touch UI has become preferred. A common case is to design for touch to be used for primary navigation, with hardware keys to be used as task accelerators. An example of this is the red end key. Typically, to exit an application, you choose the "exit" menu sub-option from the "options" menu. Pressing the red end key is a shortcut path to the same exit functionality.

When designing touch areas for your application, ensure the touch targets are large enough to be easily selected. Historically, the Symbian S60 UI style provides the following guidelines:

These guidelines still apply today with Qt on Symbian and MeeGo.

Entering information with a keypad is obviously more difficult than with a desktop keyboard. Keep in mind that the user has multiple avenues to enter information on the mobile. GPS sensors can be used to enter position information. The camera can be used to enter information such as by scanning a 2D barcode. The camera can also be used to enter information by taking a picture. Nokia's Point and Find, for example, takes input from the camera and returns new information about the photographed object. Motion sensors can be used as a method to input information by sensing gestures. When designing for keypad entry, consider that some devices will have a numeric keypad, while some will have a complete alphanumeric keypad. And, of course, consider that now touch is an extremely popular modality on today's modern mobile handsets. Depending on the target device, design for touch as a primary input, with keypad entry an optional accelerator.

To make it easier to enter information, you should try to automate data entry as much as possible. Try to automatically populate fields where appropriate. For example, the contact database can be queried to autocomplete entries or fill in additional fields.

Do not force the user to re-enter information after navigating back and returning to a data entry screen.

Finally, consider different languages and methods for input when designing your application. Chinese, for example, will have methods for information entry much different from Western languages.

On a mobile device, space available to present information is limited, so you must carefully think through how information is presented to the user. Consider the overall function of your application and decide how best to organize and order the information so that it is convenient for the user.

Consistency is important. Use colors, graphics, and icons consistently. Use them in a way to support the user's ability to perform a task or extract some information. Avoid overuse of graphics that instead cause distraction. Do not use icons to replace essential information conveyed as text.

Consider whether to present your application in portrait or landscape — this will depend largely on the specifics of your application design. In a movie application, for example, it might make sense to force the user to use a landscape layout since this better fits the native aspect ratio of the movie. In many cases it may be better to support both portrait and landscape and let the user select either by physically rotating the device or using other methods.

Many useful applications will take advantage of connectivity to exchange information over the network. However, connectivity is a double-edged sword. The device can easily lose network coverage, and in some cases the user may be charged to access the network. Furthermore, connecting over the network can be slow.

So design your application to use network connections as efficiently as possible. Allow the user to manage the connections when appropriate. Ensure that sufficient status information is presented to the user about the connection state. Design your application to gracefully handle on and offline modes.

Enterprise applications are typically administered by IT departments. Remember to build in features useful for administrators. This includes providing features that allow administrators to configure applications and installation packages, and features for remote administration. It is useful if the administrative interface can be integrated into existing administrative tools.

Because the mobile device is so personal, sensitive information stored on the device must be treated with care. Use passwords and encryption where appropriate. Back up critical data if possible. Allow the user to delete all sensitive information when desired.

Advertising is becoming increasingly popular in mobile applications. When placing advertising, consider that it should not be obtrusive to the user. Placing ads in natural application breaks or screen white space is a convenient way to insert it without affecting the application flow too much. Avoid using pop-ups and floating ads since these can be annoying to the user. Make sure the ads do not slow the user from accomplishing the application's primary task. Don't greet the user with an ad when the application first loads. It is better to draw the user into the application, then provide an advertisement within a relevant context. Be judicious with full-page advertisements.

Ads should clearly indicate that something is being advertised and be different from application content. Consider creating an easily recognizable look for advertising content. Take advantage of context to provide advertising content more meaningful to the user.

Use platform components whenever possible. These have been developed specifically to implement the design paradigms mandated for that platform. Using the platform components also gives you additional technological benefits, such as support for scalable UI and theming.

Information on platform components for Symbian is available here:

And information for the MeeGo/Maemo platform is available here: