Design for Mobile : Sketches (part 3) - Tying It All Together

10/12/2012 2:14:39 AM

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.

Figure 11. Placing the tab bar at the top makes more sense

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.

Figure 12. Wireframing the “standalone” mode of our app for iOS

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.

Figure 13. Adding a back button completes our standalone mode

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.
Most View
Belkin AC1200 DB Wi-Fi ADSL Router
Ditch Your Laptop For Your Phone (Part 1)
Installing and Configuring SharePoint 2013 : Creating the Farm (part 1)
Using Services for UNIX to Integrate UNIX Systems with an Active Directory/Exchange Server 2007 Environment
Apple - Celebrating 7 Years Of Success
ASP.NET 4 : Error Handling, Logging, and Tracing - Handling Exceptions
Security Pros Get Caught Out By QR Codes
Samsung ATIV Tab Review - A Wonderful Windows RT Tablet (Part 2)
How To Extend Life For Mac (Part 1)
Edifier E10 Exclaim - Exclamation Mark
Top 10
Sharepoint 2013 : Developing Applications Using Office Services - What’s New in Access Services
Sharepoint 2013 : Developing Applications Using Office Services - The New Machine Translation Services
Sharepoint 2013 : Developing Applications Using Office Services - Word Automation Services and the New PowerPoint Automation Services
Sharepoint 2013 : Developing Applications Using Office Services - What’s New in Excel Services
Sharepoint 2013 : Developing Applications Using Office Services - WOPI and the New Office Web Apps Server
Sharepoint 2013 : Building a BCS-enabled Business Solution : Building an Integrated BCS Solution with an App for SharePoint Containing an App for Office
Business Connectivity Services in Apps for SharePoint 2013 : Building an App-level BCS Solution for Office 365 SharePoint Online
Business Connectivity Services in SharePoint 2013 : Adding a Business Data Connectivity Model to Office 365 SharePoint Online
Remote Event Receivers in Sharepoint 2013 : Introducing Remote Event Receivers
Windows Server 2008 and Windows Vista : Common GPO Troubleshooting Tools (part 3) - GPResult, GPOTool