Navigation Bar

Is one of the first thought of most customer when they require a mobile app, the fixed header section. It serves for three main reasons, consistently with the generic number of sub-elements contained (as shown in Figure 1)

Figure 1 - Apple common navigation bar for native apps.

• Go back, step by step: the common back-button should show the label of the previous location (not just a “back” label).
• Explain context: it answers the question “Where am I?”, the title should always reflect the location of the current view.
• Contextual buttons: Apple guidelines defines this as “content-specific control”, to directly manage contents in the current screen. It’s generally contextual to the current view, so it’s common to see a button to add an entry on a list with a “+” button on the right side of the navigation bar.

Due to technical restriction imposed by Apple, fixed position of the navigation bar (always visible in the viewport while body content is scrolling) is obtained, before iOS 5, via a workaround in JavaScript by simulating native scroll on the body of the application (see iScroll4). In complex applications (E.g., G+) that may not be so efficient as native webkit scrolling. So consider the option to wait iOs 5 and your header to remain at the top of the page (and not the viewport) while user scrolls.

The temptation of an high level of brandization of this element may bring designers to lack some of these points.

An example is the wall-mart website mobile version,in Figure 2 showing a section called “Value of the Day”. In this example, designers preferred to show a relative big logo of the company instead of the title of the current page, shifted in the grey area below with a small font size. Moreover, they omitted to implement the classical back button. The three icons on the right side of the navigation area covers the function of contextual buttons, though they are not contextual the current view, it can’t be strictly considered as an error  because of the natural of a mobile-optimized website.

Figure 2 - Wall-mart mobile version. In the picture the view for a specific product. Lacks of back button and title in the main area of the application.

Selectbox vs Tableview: make them choose

One of the most usable paradigm to make a user select an option, on a desktop website, is the classic html <select> element.

On iPhone or recent smartphones the choice is implemented via tableview (Figure 3): a list of elements. This method works excellently especially when user has to make multiple, hierarchal choices via two or more tableviews; this paradigm is successfully implementable in web-apps with the classic iOs left-to-right animation between a tableview and another, thanks to mobile safari’s support for hardware-accelerated transformation (read the blog post on webkit site).

Figure 3 - a tableview example

Select-boxes in web-apps are still used, but Apple guidelines about pickers becomes more and more valuable:

• use picker for well-known choices options (E.g., sex).
• use a tableview, instead, for large lists of options.

Consider the example above in Figure 4: the image shows a snapshot of Meridiana Fly web-app. All choices are implemented via html select-box elements. Departure element, if tapped shows the webkit native picker with 40 options:only 4 of them are visible per time (Figure 5).

Figure 4 - Meridiana flight search; all user selections has been implemented via select-boxes html elements.

Figure 5 - selectbox generates a pick element that shows up to 4 items per time in the viewport.

Often we have to deal with complex data structure. In this case, lack of a native multi-column picker suggests to design an hybrid solution, dividing user choices depending on options contents. Figure 6 shows an alternative mockup in this sense.

Figure 6 - example mockup for flight search booking: divides long lists and not-known options in tableviews and keep others in select-boxes.

Another note about tableviews is about convention in symbolism: if you are building a web-app with multiple, hierarchical tableview choices that lead to a certain final page, consider that you can count on those iOs guidelines:

The simple arrow indicates that, if tapped, the element will bring you to another tableview (another choice)

the circle arrow indicates that, when tapped, will bring you to a detail page contextual to your choice.

Search.

10+ years of usability in web design suggest to include Search feature in our digital products, and keep it visible and consistent in every section.

iOs native apps tends to include search launcher in the tab-bar at the bottom of the viewport, and display a modal, quick interface with the input box at the top of the screen on the following step, search results are indexed in a list below.

Replicating this feature on web apps might lead to compromises. Fixed tab-bar, at the bottom of the screen (iOs native’s like), may not results very usable because of the small screen available considering the standard Safari toolbar (unless user adds the web-app to his home screen). Therefor there’s a trend in including search launcher at the top of the screen, in the navigation bar. That may result a good strategy because search icon will be evident in any section of the site, but may take possession of a place reserved, theoretically , to interact with page content elements.

Once landed in search section, one of the most important thing is optimize the small screen available by dividing the viewport in the header section and the results section, as tradition set in iOs native apps. In Figure 7 there is an example of that implementation with a standard DHTML technique: Facebook mobile web-app. Asynchronous calls to server injects new data while user types; an improvement version of a search feature includes local indexed data to serve data instantly. This result may be acquired by integrating local database support as part of the web storage HTML5 capabilities (view document by W3).

Figure 7 - Facebook mobile app uses a modal search.

Launch Image

One of the most misunderstood UI element is the launch image. It’s the splash page to display while app (or web app) is loading.

Several designers insert a page with a logo and custom graphics (as shown in Figure 8). What it really should contain is a minimal, high quality picture representing the real UI of the application: it covers the waiting time by decreasing launch-timing perception.

A custom launch image, that has nothing to do with the app UI, has simply no sense. Despite indications and guidelines about this feature, there is a huge number of native apps that abuse launch image with stunning graphics and logos.

In Web-apps is it possible to add a launch-image and it will be shown only if user will add the app on the home screen.

Figure 8 - A comparison between two apps' launch image. Instagram (on the left) shows a minimal version of its UI. F1.com prefers a logo and a label "Loading".

Tab bar

The black, bottom-sided menu list with fixed position relative to user’s viewport. It represents common UI element for native-iOs applications. By Apple specifications it should flattern the navigation system by subdividing different conceptual areas of the application. While it’s highly recommended to make it accessible from anywhere in the app, many use to design this element as a sub navigation menu, avoiding usage of segmented controls (the ones ideated for this purpose).

Implementing a tab bar menu in webapps may be achieved, again, by emulating native scroll keeping fixed a portion of the page. Is one of the rarer design pattern taken from iOs native apps to web-apps, due to non-optimal experience obtained by simulating native scroll, especially on older devices like iPhone 3G. Despite that, in a near future with native, fixed positioned elements usage of a tab bar might be a successful choice to address app navigation in a simple, flat way.

Conclutions

With current and future mobile browsers enhancements, the phrase (and excuse) “it’s just a mobile-optimized version of our site” shall loose any sense. All potentials of iPhone (and Android devices as well) lead to a new generation of mobile, web-based applications. Some design patterns and guidelines could be taken from the well-tested native iOs ground; but there’s still a wide, empty space for imagination and continuos improvements. If the era of web designers seems over, new gates are opening by both sides of designers and developers; it’s the era of technical specialists. Mobile development requires an highly skilled profile because of limited screen availability, environment distractions and requirements of new paradigm of interaction never tested before. By the other hand, a skilled web developer has to face the limitations of mobile devices memory, optimizing code without  falling back to huge JavaScript frameworks that are not optimized for mobile specific browsers.