5. Tying It All Together
So, we have all the components of our application in place. The problem is they’re
separate contexts, so we need a way for our users to flick between them easily. Luckily
for us, there’s a tried and tested solution out there that we can use—the tab bar. Let’s
review some of the features of the tab bar:
establishes the structure of an application
lets users easily move between an application’s sections
indicates the current state/location of the app
Sounds right up our alley! The flat hierarchy of the tab bar actually suits us here;
we have three main sections that are of equal importance.
However, the implementation of a tab bar needs careful consideration, especially when
thinking about a mobile web application. In a native app, the tab bar is usually a fixed
element at the top or bottom of the screen. Inside the browser, though, this is trickier
to accomplish. So what are our options? Placing the tab bar at the base of the viewport
would mean placing it directly above the browser controls.
For a mobile web application, it makes more sense to place the tab bar at the top of
the viewport, for the result shown in Figure 11.
This improved placement has the added advantage of fitting the expectations of Android
users, since tabs on that platform are generally at the top anyway. If we roll the tab bar
out to each of the screens we’ve looked at already, we can see our application is starting
to take shape. There’s a consistent, flexible structure, and our users can easily identify
which context they’re in.
6. The Fix Is Out
Whether it appears at the top or bottom of the screen, the tab bar is often fixed in
position, with the main content of the application flowing underneath it. This presents a
couple of problems, the most obvious being that none of the current crop of mobile
browsers support position: fixed in CSS. We
need to determine whether the user experience benefits are worth this trade-off in
performance. Do our users need access to each section of the app at all times? Will it be
confusing if they don’t have it?
As a general rule, erring on the side of simplicity is the best way to go. For the
in-browser version of our application, we’re going to let the tab bar scroll offscreen;
users can simply scroll back to the top to change contexts.
7. Home Screen
On iOS, we have an extra mode that sits somewhere between a web application and a
native application. iOS lets us set an option to run Mobile Safari in full-screen mode
when our users bookmark our application on their home screen. Let’s spend a bit of time
designing a modified look and feel for this standalone mode. This gives us the opportunity
to make our site conform more closely to the iOS user-interface paradigm.
None of the other platforms we’re looking at offer this function, so when we’re in
standalone mode we can conform to the “iOS way” and move the tab bar down to the bottom.
It’s nice and close to our users’ thumbs, as you can see in Figure 12.
That all sounds wonderful, right? And it is, but it’s not without problems. The main
design gotcha we need to think about at this stage is the lack of the standard browser
controls. Our navigational model is drill-down, with the user’s options being to move
deeper, shift back up a level, or start at the top of the tree again. Without a back button, however, one of those options is impossible; there’s no way for
our users to go back, so we’d be forcing them to retrace their steps whenever they wanted
to move up a level in our navigation. That means we have to include our own back button
somewhere in our standalone mode interface. iOS users expect the back button in the
top-left corner, so that’s where we’ll put it.
Figure 13 shows our full-screen wireframe with the
addition of an iOS-style navigation bar and back button.
Phew! Now that we’re happy with the structure and flow of our application, let’s
attack the fun part: the style and aesthetics of our application.
