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)
- 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.
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.
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).
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).
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.
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:
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).
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.
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.