Design for Mobile : Sketches (part 1) - Finding Sightings By Location

In any project, but particularly when we’re designing for a form with which we’re unfamiliar, sketching and wireframing is a great way to gain a sense of how the flow and overall structure of the app will work. What exactly is a wireframe, you ask? It’s a low-fidelity visual representation of the layout of our application. We can use it to represent the basic page layout and navigational model of our app.

Since wireframes are considerably quicker to make than a fully fledged mockup, we can spend some time early on prototyping a range of approaches—testing our interface ideas and rejecting them promptly when they’re not working. Once you start the design process, it’s easy to get caught up in the small details: perfecting that shade of blue, or achieving just the right balance of type. At this early stage, sketches can provide a sense of the user experience as a whole, allowing us to spot potential usability problems before we commit too much time to building the interface.

How you build your wireframes is really a matter of personal preference. There are a whole host of tools out there that make the process very easy. Here are a few of the more popular options:

Pencil and paper

Sometimes the simplest tools are the best. There’s something wonderful about the process of physically sketching a layout. It removes the distraction of the tools and lets us focus on the task at hand. The downside to hand-drawn wireframes is that when we want to iterate our design, we’ll have to redraw each layout.

Balsamiq, http://www.balsamiq.com/products/mockups

Balsamiq is a simple wireframing application with a range of common interface elements. It’s an Adobe Air application that runs on Windows, Mac, and Linux, and has a hand-drawn look that’s designed to keep you focused on the structure rather than the appearance of your mockups.

Mockingbird, https://gomockingbird.com/

An online tool, Mockingbird lets you build and share your wireframes in-browser. It has a similar sketchy style to Balsamiq.

Omnigraffle, http://www.omnigroup.com/products/omnigraffle/

Omnigraffle is a Mac-only application that, among its many features, is a fully featured wireframing tool. The real benefit of Omnigraffle is the range of interface stencils that are available for free. Check out Graffletopia for all your wireframing stencil needs, including many mobile-specific templates for various platforms.

Figure 1. An empty wireframe containing only the device shell

For our purposes, OmniGraffle will do the job just fine. Let’s have a look at some sketches for StarTrackr. Because there are a bunch of stencils available out there for iOS wireframes, we’re going to use the chrome from an iPhone as the frame for our sketches—but our interface will look the same on any platform.

First, we’ll need to set up the correct dimensions and place some of the default elements in there. You can see our starting point in Figure 1.

That’s our blank canvas. Now there are some standard interface elements we’ll need to account for, as shown in Figure 2.

Figure 2. Adding the operating system and browser chrome

On iOS, the status bar weighs in at 20px, and in Mobile Safari, the toolbar at the bottom of the screen takes up 44px of vertical space. On Android, the browser chrome disappears from the screen once the page has loaded, but the status bar takes up 25px; the same is true of the browser on webOS.

Let’s ignore these elements for a minute and look at the layout of our application in an empty screen. To start things off, it’s often useful to establish the distinct objects that make up the application at large. For StarTrackr, these are easy to identify: we have celebrities (stars) and locations (spots) that are linked together by sightings. However we end up combining them in our interface, those three objects form the basis of everything we do. If we’ve identified the three main features we’re going to focus on, what information or actions might each one contain?

1. Finding Sightings By Location

This one really is about the context. Our users are out and about, so they might be able to act on the information our app provides and go to the spot where a star has been sighted. While it might seem handy for a user to see all the most recent sightings, finding sightings that have happened nearby is probably much more useful. With that in mind, we’ll want a list of locations—ordered by distance—that our users can drill down into.

A list, eh? Well, that sounds familiar. In fact, the list pattern is perfect for presenting this information. We want to let our users quickly flick through a series of locations, and then move into a detailed view of that spot if it piques their interest.

Figure 3 shows a wireframe of our list of spots, ordered by distance from the user. We’re showing the important information on the left—the name and distance—and on the right, we’ve added the number of sightings at that given location. This will probably mean very little to our users initially, but there’s no need to force content on them. It’s okay to let them discover that information on their own.

Figure 3. A wireframe of StarTrackr’s “Spots” listing

Makes sense, right? The only problem is that to make this real, we need to know the location of our users. There are a couple of ways to go about this. The JavaScript Geolocation API exposes the functionality we need to access the device’s location sensors, as many smartphones include a GPS. So, we can merely place a button in our interface that starts that process. Unfortunately, the Geolocation API isn’t available on all mobile devices, so we’ll need a fallback of some sort.

The addition of a fallback text field to our geolocation button has the advantage of giving our users the flexibility to modify their location if they so wish. Why would they want to do that? We’ll go into the nitty-gritty of the implementation of the Geolocation API a little later on, but it’s worth knowing that it’s sometimes a bit like magic. Each device, and indeed each browser, has a different way of figuring out a location; information can sometimes be unreliable or inaccurate, so allowing a user to refine their position can be a useful feature. Furthermore, if we limited ourselves to using just the Geolocation API, it would mean that users would be limited to only exploring their actual physical location; so if they wanted to explore the hot spots in a different city, they’d have to actually go there!

Figure 4 shows the standard approach to asking a user for their location.

Figure 4. An excessive address form

That’s not very friendly, is it? Entering data on a mobile device (especially one without a physical keyboard) is much harder than through a keyboard and mouse combination, so if we can reduce the effort our users have to make, we should.

A much better option—even outside of mobile context—would be to let our users enter information in a free text field, and then infer their location using a third-party service or API . The canonical example of this kind of field is the Google Maps search interface.

Figure 5 shows an example of a simpler location entry interface.

Figure 5. A simpler approach

That’s much better!

This brings us to an important (and easy to overlook) consideration for touchscreen devices. The available area for our form changes, depending on whether or not the keyboard is displayed. Figure 6 shows a minimal form on an iPhone, with the keyboard active.

Figure 6. The on-screen keyboard can obscure a significant portion of a page

Our once blank canvas is now half-filled with a keyboard. In fact, in portrait mode, the iOS keyboard takes up 260px of the 480px space we have to play with, reducing our usable space to less than half of what we started with. When building forms for mobile devices, always keep this in mind, and make sure you’re not hiding essential information or controls behind the keyboard.