The wiki platform is being decommissioned. All content not being decommissioned must be migrated off the platform and moved to community.oracle.com, or the platform of your choice, by June 25, 2015. If you have any questions or concerns, please contact: firstname.lastname@example.org.
Know your end users.
Before designing, spend time getting to know the role of your end users and the specific needs that they will have while mobile. Understanding key characteristics of your users, their work environments, and the tasks that they perform will help ensure that your product has the right features and optimal user experience. We have created a set of mobile personas that are based on international ethnographic research for the following roles: sales representative, field service technician, manager, retail merchandiser, and Generation Y. See the Know Your Users Guideline.
Define the essentialmobile tasks.
A mobile application must be able to stand alone and not depend on an understanding of a related desktop version. When assessing how to convert an existing desktop application into a mobile design, be aware that the key task for the desktop may be quite different from that of the mobile. We strongly encourage you to think through the mobile use case rather than relying on the desktop workflows. Do not hesitate to eliminate tasks that are not essential to the mobile requirements. Successful mobile applications are frequently simplified to primary tasks, such as searching for coworkers or managing task lists. See the Mobile Task Flow Guideline
Mobile applications are used in trains, warehouses, taxis, oil platforms, and more. Designs must work in the target work environment and maximize context awareness of the mobile device. A GPS-enabled device that maps sales representatives’ locations helps them arrive at their next appointments on time. A device that scans and displays information about an asset, such as details of the last service, helps a technician bring the right parts and make the appropriate repairs.
Create a flattened navigation model.
Users do not want to traverse deep structures to complete a task. Flatten the navigation model for quick access to key task flows. Once users navigate to begin their work, provide a clear understanding of where they are and how they can return to their starting point. Instead of having a user log in, access a section, find an object, and then perform a task, a flattened navigation model provides quick access to the mobile task immediately after login.
Design for the two-minutes-to-get-it-done mobile work style.
Typically, mobile devices are used in short bursts, while personal computers are used for extended work sessions. Mobile users will not tolerate designs that require a lot of data entry or multistep flows because they need to get to work faster and complete their tasks more quickly. Tasks should be simple and quick to complete.
Analytics and business intelligence are not limited to the desktop. Mobile users need analytics that work for small screens. A regional sales manager might see a screen that highlights store locations with the biggest sales data from last quarter or last year. A color-coded grid of locations versus key metrics draws attention to good, moderate, and bad situations. The first step in determining which analytics will be useful is to understand the mobile use case and how to integrate analytics that help decision making. A needless insertion of analytics takes up valuable real estate and makes it harder for mobile workers to do their jobs.
Simplify search requirements.
Search is an important part of mobile applications and must be quickly accessible. Because mobile data entry is more difficult, simplify search entry requirements to a single field when possible and place the field above related data. If a user is on an inventory screen within a handheld application and initiates a search for an item, all results should relate to inventory attributes. When multiple-field searches are required, load field values with default data that the user can change with choice lists and lists of values. Do not require the user to enter text in multiple fields.
Embed collaboration into workflows, and include triggers to call a person, connect to a social network, and text using SMS and IM. The proliferation of social networking within the work environment demonstrates the increased importance of keeping in touch with colleagues and affiliated professionals. Mobility extends this trend by keeping coworkers in contact more often and in more places.
Progressively disclose information.
Because screen real estate is precious on handheld devices, carefully consider the type and quantity of data that you display when designing the application. Information must be concisely summarized with basic overviews and limited actions. Details and additional actions should be available in drill-down pages. An example of progressive disclosure is used by mobile email programs that simplify functions in the overview interface and require a user to select an email address and only then provide functions for reply, delete, forward, and so on from the resulting details screen.
Leverage the mobile platform.
Mobile applications can be built to run in the browser or as native applications installed on the device. Enterprise applications should leverage mobile capabilities that enable a user to tap a phone number to call or text, touch an address to map its location, and rotate the device for an alternate view. Native enterprise applications enable more integration than those applications run in the browser and provide the ability to transfer enterprise data to local built-in applications, such as calendars and contacts, so that users can view important business information without signing in. Understanding each platform and maximizing the appropriate mobile actions will ensure a productive and natural mobile experience.
The individuals who post here are part of the extended Oracle community
and they might not be employed or in any way formally affiliated with Oracle.
The opinions expressed here are their own, are not necessarily reviewed in
advance by anyone but the individual authors, and neither Oracle nor any
other party necessarily agrees with them.