Chapter 5. Starting A New App

This chapter marks the start of the real process behind designing and developing an app. Here, you will take a user-driven approach, refining every step of the way with user feedback to ensure the ideal experience. This chapter is focused on the user experience (UX) and information hierarchy to provide a solid foundation for the app.

Before you worry about what your app looks like (graphic design), you need to worry about the deeper requirements. A dresser can have a stunning appearance, but it isn’t particularly useful if the drawers can’t hold the weight of clothes. That means you first need to figure out your app’s requirements. What features should the app have? How is the app organized?

1. The design is based on an explicit understanding of users, tasks, and environments.

2. Users are involved throughout design and development.

3. The design is driven and refined by user-centered evaluation.

4. The process is iterative.

5. The design addresses the whole UX.

6. The design team includes multidisciplinary skills and perspectives.

This explicit understanding comes from real users. It isn’t from reading a study about the “average smartphone user.” It isn’t from looking at statistics. It is from actually going out to real users, talking to them, and experiencing their characteristics, their tasks, and their environment.

Some software teams try to avoid bad outcomes by involving users early on, helping to answer questions about navigation, feature exposure, and more. They take that initial feedback, make whatever changes are needed, and then develop the app. That process is a lot better than not getting user feedback until after the app is basically ready, but a lot can happen between that initial feedback and the release date. UCD requires continuous user involvement throughout every phase of the product lifecycle. Yes, you should be evaluating your wireframes with users and later evaluating your graphic design with them as well, but you should also have users involved with your error handling (when something is wrong, do they understand how to fix it?) and even your algorithms (is this code that sorts photos based on meta data fast enough?).

Does the user’s timeline contain all the tweets the user cares about?

Does the user’s timeline consist only of tweets the user cares about?

Is a chronological order the best for tweets?

By making these goals broad, you keep them separate from the means by which the user accomplishes them. It might just be that a simple, chronological timeline is the best way to read through tweets, but there is a chance that it’s not. What if you were to categorize tweets by content or the type of user who is posting them? What if you included tweets from people who might be interesting to the user but aren’t being followed? What if the user can give feedback about which tweets are valuable and that can be used to push those types of tweets to the top of the list?

Sometimes it can seem a bit challenging to create meaningful user goals. Maybe you’re creating an image manipulation app and all you can come up with is “I want to be able to easily manipulate photos.” That is not a very helpful goal, so you can break it down further. First, think of basic navigation requirements: How will users get to the photos? Next, why are they manipulating the photos? Finally, after they’ve manipulated the photos, what can they do with them? With a bit of brainstorming, your list might look more like this:

I want to browse all images on my device.

I want to improve the visual quality of my photos.

I want to make people in my photos look better.

I want to share the modified photos.

You can certainly come up with a more exhaustive list than this, but this is a good start. Notice that the photo manipulation goals do not define specific ways they are accomplished. Later, you can define features that allow the user to accomplish these goals. You might decide that the app needs to support easy fixing of blemishes such as pimples and also needs to correct red-eye; both of those features are ways to accomplish the third goal: “I want to make people in my photos look better.”

Another segment of your users might be more casual. They love cameras on smartphones not because of the quality of photos but because of the immediacy and the ability to share quickly. Now you define Jim, a guy who couldn’t care less what SLR stands for and just wants to share good photos with his friends. His phone is fairly average and does not take great photos, but he loves being able to immediately share whatever he is doing with all his social networks. You could explain to him that red-eye happens in photos when the flash is too close to the photo sensor, but he doesn’t care. Obviously eyes shouldn’t be red, so the device should be able to fix that automatically.

There are more personas that could (and should) be made, such as a younger user who wants to modify pictures in funny ways to get some laughs with friends, but even with just these two users you can easily see the contrasting needs. Consider the previously defined photo manipulation app and how these two users would use the app to accomplish their goals. Susan wants the photos organized by events, whereas Jim wants the newest photos to be first in the list because they are most likely what he wants to share. Susan cares about manually tweaking the white balance, contrast of shadows, and other features that Jim could not care less about; he just wants to easily make the photo look nice. Their requirements around making people in photos look good are similarly different. Susan wants to select a precise skin tone, whereas Jim just wants to be able to tap on that one horrible Friday night pimple and have it disappear. Finally, they both use sharing but in different ways.

Reflect company XYZ’s branding.

Release beta version to board members in six weeks.

Release 1.0 to Google Play in eight weeks.

Reach 50,000 app downloads within three months of launch.

Earn $5000 gross within three months of launch.

Notice that these goals are not direct considerations of the users, but they do affect the users. The intent to monetize means the app may cost money, it might have ads, it could have in-app purchases, or some other means of making money such as premium account support. The length of time allowed for development controls which features can be included and how refined they can be. These are requirements, but to the best of your ability you should not let them define the app.

The other part of device support is determining the minimum version of Android you will support. Ideally, this decision is driven by your target users. If you’re building an app for just developers, you might be able to get away with support for Android 4.4 and above. If you’re building a chat app for developing nations, targeting only Android 4.4 and above is going to kill any chance you have of success. In most cases, even design that comes from newer versions of Android such as Lollipop can be applied to older versions of Android through the use of the support library, third-party libraries, and even custom solutions. Most apps developed now support version 4.0 (Ice Cream Sandwich) and above or 4.1 (Jelly Bean) and above. If you’re not sure what version your users have, then consider targeting one of these versions.

When it comes to configurations, Android does not have a distinct concept of a “tablet app.” Instead, apps can run on any device, unless you specifically set them not to. It is up to you to decide whether you want to provide an experience optimized for a tablet, television, or any other device. It is fine to release an app that does not have a tablet-specific experience in version 1, but users appreciate knowing that upfront, so be sure to let them know in your app description.

The high-level flow is very directly tied to the goals you have established for your users. If your primary user goal is “read all the tweets that I find important,” then the main screen should facilitate accomplishing that goal. One consideration to keep in mind is that you do not want to overwhelm the user with too many options on any given screen. It’s ideal to have a primary action for a screen with a few optional secondary actions.

The main way that people choose to work on high-level flow is with flowcharts. Typically, you represent screens with shapes that have lines or arrows connecting to other screens. This lets you quickly see how easy or difficult it is to navigate through the app. In some cases, people like to create very crude drawings of screens to more easily understand what goes in them. Do whichever works best for you. Plenty of software options are available, such as full desktop solutions like Visio (http://visio.microsoft.com/en-us/pages/default.aspx) for Windows and OmniGraffle (https://www.omnigroup.com/omnigraffle/) for Mac. There are also open source solutions that work on Linux as well such as yEd (http://www.yworks.com/en/products/yfiles/yed/). If you’re looking for a web-based option, Google Drawings (http://www.google.com/drive/start/apps.html#drawings), LucidChart (https://www.lucidchart.com/), and Gliffy (https://www.gliffy.com/uses/flowchart-software/) are worth taking a look at. Whether you’re creating the flowchart digitally, on a whiteboard, or on paper, this early planning is exceedingly valuable.

Let’s say you are working on an app for new woodworkers. During your initial user research, you found that new woodworkers have a difficult time determining what tools to buy, so your app is going to focus on helping them decide. You brainstorm various ways to organize this and decide on a basic hierarchy with some filters. After some work, you come up with a hand-drawn flowchart that shows the basic app organization (Figure 5.1). You’ve decided that the hierarchy should be based on power tools with anything else falling under an accessories section. The users will drill into either handheld or stationary for a given category, and then brand, and then a specific tool.

This seems very reasonable, so you walk some users through the flowchart and you learn there is a big problem with your flow. Experienced woodworkers can have very strong opinions about brands, but a lot of new woodworkers have no idea which brands are good. Their choice ends up being arbitrary, making this step unnecessary. You also find that some users are specifically looking for battery-powered tools, and this flow doesn’t offer any easy way to do that. One more issue they ran into was looking for clamps. It seems that clamps are vital to woodworking and, although you reasonably consider them an accessory, they’re sought after enough to make them worth promoting to the top level. In addition, some of the other tools such as planers and joiners weren’t looked at by any of the novice woodworkers.

Wow, that’s a lot of feedback saying that the flowchart is wrong. Does that mean you screwed up? No! Your flowchart was a first stab at organizing the app and it generated all this valuable feedback! Not bad for some crude pencil work and a little time with some users. This is where the iteration comes in. Now that you have this great feedback, you can create an updated flowchart that addresses the concerns found in the first one and test it with users. Repeat this process as much as you need to get a solid flowchart. Once it is ready, you should create a digital version (if you haven’t already) and detail it with all the other states you are going to need to worry about. These states are things like loading and failure. By getting these in your flowcharts, you’ll have a much better idea of how much effort will be required for the app and you can ensure that people are thinking about them from the beginning. Figure 5.2 shows an example of an updated flowchart.

There are many different tools for wireframing. Starting out with a simple sheet of paper and a writing utensil is a great way to quickly try out a few different ideas. You can use a pen to force yourself to keep moving and trying new things without tweaking what’s there or a pencil for a more detailed draft. You don’t need to be an artist to create good wireframes. Look at the difference between the three wireframes in Figure 5.3; they all illustrate the same screen but with different levels of fidelity. They all let you quickly see if something seems to work or not.

There are a few techniques you can apply to make your wireframes look better. First, stencils are a great way to make sure you are consistent, so consider picking up some such as the Android UI Stencil Kit (http://www.uistencils.com/products/android-stencil-kit). Next, break your sketching into small pieces. Many shapes are just a bunch of straight lines, so it’s worth spending some time practicing drawing straight lines. Sure, it’s not the most exciting thing to do, but it makes a major difference in how sharp your wireframes look. When you’re first getting better at drawing lines, put a dot at your starting point and at your finishing point. Concentrate on moving your arm (not your wrist!). Watch where you want the line to go rather than where you’re currently drawing. It won’t take long before you can draw straight lines without giving it any thought.

One more thing that comes in handy is knowing how to draw a circle or arc. Just like with drawing a line, you don’t want to rely on your wrist. Instead, find a pivot point and move the paper. For large circles and arcs, the tiny bone opposite of your thumb near your wrist provides the pivot point. Put it down on the paper and then hold the pen or pencil like you normally would. If you need a full circle, rotate the paper while keeping your drawing hand stationary. If you just need an arc, you can move your elbow while keeping your wrist straight. Need a medium-sized circle or arc? You can use one of the knuckles of your pinky finger as the pivot point (usually the middle knuckle works best, but it depends how you hold the pen or pencil). If you need a small circle or arc, you can hold the pen or pencil between your index and middle fingers and put your middle finger against the paper as the pivot point (see Figure 5.4). If nothing else, you can always try to find something that’s round and the approximate size you need (such as a pen cap) to trace around.

When you’re ready to work with software to create more polished wireframes, a lot of different tools are available to you. Many designers are already familiar with vector-based programs such as Adobe Illustrator (http://www.adobe.com/products/illustrator.html) and Inkscape (https://inkscape.org) and prefer to stick with those. Some tools that are good for flowcharts are also good for wireframes such as the previously mentioned Omnigraffle. Another popular tool that’s available on Macs is Sketch (http://bohemiancoding.com/sketch/), which has features that extend beyond just wireframes. If you’re looking for a tool that’s available as a desktop app and a web app, give Balsamiq a try (https://balsamiq.com/); it uses a “sketch-like” style to keep the focus on what you really want to test with wireframes. Wireframe Sketcher (http://wireframesketcher.com/) is another cross-platform tool you might consider. Really, there are a lot of tools out there and there isn’t a single tool that works best for everyone. Give a few different tools a try and do a quick Google search for more if none of these work for you.

It is important to remember that the purpose of wireframing is not graphical design. Your wireframes should generally not use custom colors unless they are for defining content groups, showing interaction (e.g., a touch or swipe), or showing alignment. In fact, many wireframing tools use sketch-like graphics to help keep the focus on the content and its positioning, rather than its appearance. It is fine to use native components (such as Material Design buttons), but avoid adding in your own custom controls with any more detail than necessary. You can show a custom chart, but you should not add gradients or other visual treatments. Ultimately, the purpose is to put the emphasis on the content positioning and its hierarchy and not on the visual design. This is your opportunity to determine positioning and sizing of elements on the screen relative to the other elements.

The simplest form of navigation uses fixed tabs (see Figure 5.5 for an example). It ensures that the major sections of your app are visible, it creates a clear hierarchy, and interaction is obvious. The downsides are that tabs work best when you have only a few major sections, and they also take up some screen space. The content represented by tabs should be swipeable, so that you can change tabs by swiping almost anywhere on the screen. Tabs should also only appear at the top of the section they’re appropriate for. For instance, if you were building an app for podcasts, you might have a tab for discovering new podcasts, a tab for podcasts in your library that you haven’t listened to, and a tab for podcasts that you have listened to. If the user is on the tab for discovering new podcasts and taps on a suggestion to go to the detail page for a podcast, the tabs should not appear on that detail page. In general, if your app has two to four sections, you should strongly consider tabs.

A variation on tabs is scrollable tabs (see Figure 5.6 for an example). This is where you have tabs at the top again, but they are in a horizontally scrollable view, allowing you to fit more than you can when they’re fixed. This allows you to use tabs for apps that might have five or six sections while still giving you the benefit of being obvious to users. Users might not realize the view can scroll, so selecting a tab should move it to the center of the view if it isn’t at the edge. This allows you to show the other tabs that are available and teaches users that these tabs aren’t static.

An increasingly common form of navigation is the navigation drawer or nav drawer (see Figure 5.7 for an example). It shows a hamburger icon (the icon with three horizontal lines) that can be tapped to slide the drawer in from the left. A user can also swipe from the left edge of the screen to display the drawer. The advantage of the navigation drawer is that it allows you to have a large number of top sections without using screen space when the drawer is hidden. It does have the major problem of discoverability because it is effectively invisible and it can cause confusion with navigation with the back button. Tapping a section swaps out the content on the screen rather than drilling in, which means the back button should not go back to that section (you aren’t adding to the backstack); however, the transitions often occur as the drawer is sliding back out of the way, preventing users from seeing the visual cues that transitions provide.

Another navigation scheme is to have a central page that provides links out to other sections, if needed. This works well when you have some core information that the user wants to see and either no secondary actions or just a few uncommon ones. For instance, an app that is primarily designed to just show elevations on a map should jump directly to that map view. A search feature can be in the app bar, but you don’t really need any tabs or other navigation.

It is often very helpful to see how other apps handle problems similar to yours. It’s very valuable to see how the native apps that were designed by Google work because they tend to best reflect the current state of Android design and UX. You should also look at popular third-party apps to see how they handle some of the challenges your app faces. You can learn both what apps do well and what they do poorly by spending some time exploring them.

Considering the woodworking tools app, what navigational strategy would you use? There are probably seven sections: clamps, saws, drills, sanders, routers, lathes, and more. You might be able to put lathes into the more section, but you’re really at the limit of how many items you want as scrollable tabs. Perhaps a navigation drawer is a good start? Looking at your updated flowchart, you can also see that choosing a tool type pushes the user toward another decision: stationary, handheld with a power cord, or handheld with a battery. You might want to go to a page about the tool type, explaining the general purpose of the tool with three buttons to dig into one of those categories. You might instead want to go straight to one of those categories, so that you can immediately show content. Another option is to combine those two and go to a page about the tool type with four tabs: About, stationary, handheld, and battery (see Figure 5.8 for an example flowchart with this organization). This is the situation where wireframing is particularly helpful. It would take a lot of work to build out all three of these possibilities, and you’d end up throwing away two-thirds of that. Instead, you can relatively quickly test out what these options look like and try them with users.

When creating a list of content, you need to think about what is most important and what is different between items. Weight might be very important for some tools, but it isn’t as important to put in the list view if all tools in that list weigh roughly the same. That means a little bit of research can be helpful. Similarly, knowing real examples can make a big difference in how you organize the info, how big or small you make fonts, and so on. For instance, if you’re making a list of news stories, you want to know what the normal length of headlines is so that you don’t end up with ellipses in every item after two words.

There are a lot of techniques for learning what is most important. The simplest is to just ask real users. This will generally get you pretty close, but there are often important things users don’t think about or don’t realize are important, so a helpful technique is to actually watch users and ask questions. For example, you could watch users navigating a woodworking tool site and after seeing them drill in and back out of tools a few times, ask what they’re looking for or what is causing them to back out. Also consider what a photo can get you. It’s a nice visual, but it can often convey information more effectively than words and a photo is especially helpful for users who might be unfamiliar with what they’re looking for.

After working with some real users yet again (hopefully you’re seeing the value of users by now), you might discover that the name, price, power, and photo of tools is most important. Alignment is imperative when starting to lay out content, so it’s a good idea to start with the most vital element (say, the photo in this case), and lay the other elements around it with consideration about how they align in a list. Photos in a list will generally be in one of three places: the left (start), the right (end), or the background. If you have photos for only some of the items, you generally don’t want to put them at the left edge because you will end up with a zigzag effect (see Figure 5.9) unless you include generic thumbnails that don’t add user value. Photos in the background are best when the content area is large, ensuring the text that overlays them does not completely obscure them. These list items are likely to be pretty small, so either the right side or the left side will be best. Given that this list will be hand-curated, photos should be available for all items, so the left side seems good.

The name is the next most important element. Given the variation in length, making sure it has as much room as possible is a good idea, so the top left seems like a good choice. Price is a very comparable element, so putting it on the right side to make it easy to scan might work. Finally, the power can go directly below the name. Figure 5.10 demonstrates what this could look like.

When you need to test out text alignment and you don’t actually have real text content available, you can use what’s called “lorem ipsum” text. It’s essentially filler text meant to allow you to focus on typography, alignment, and other aspects of the page without worrying about the text content itself. The text is inspired by Latin, but altered to be improper and nonsensical. A quick web search for “lorem ipsum generator” will lead you to plenty of pages that can supply text for you to copy and paste. There are also variations such as “bacon ipsum,” “hipster ipsum,” and others that you can find by searching for “lorem ipsum alternative.”

The app bar often contains secondary actions on detail pages, but there isn’t any immediate need for any in this app. That means the bar can just contain the up navigation and might not even need a title. See Figure 5.11 for what the detail page wireframe looks like.

Sometimes it can be helpful to do wireframing without any device borders to contain it. What does that UI look like in its natural form? How wide should a text view be before you make the content wrap to the second line? Is the button connected to the bottom right of the content or the bottom right of the screen?

Playing around with the content positioning early on can make it clear how you can better support not only different devices but also landscape and portrait orientations specifically. Although many apps do not support landscape orientation on phones, there is little reason not to. The amount of work involved is not significant if you are already following best practices and planning to support a variety of device sizes.

Tablets generally fit two fragments side-by-side in what is referred to as the “master/detail” flow (where “master” refers to your list of content and “detail” refers to the detailed information about the item selected from that list). Of course, there’s nothing preventing you from doing something totally different. Many of the best tablet apps have completely custom tablet layouts that take much better use of the available space than simply moving fragments around can give you. Others are able to provide a very simple interface where the user doesn’t have to change screens because it can all fit on the tablet screen. See Figure 5.12 for an example of what the woodworking tools app might look like on a tablet with minimal work by reusing what will already be built for the phone version.

Android also has conventions for specific assets (see http://developer.android.com/design/style/iconography.html#DesignTips). Icons, for instance, start with “ic_” and then the icon type. For example, ic_dialog_warning.png would be the icon used in a warning dialog. Typically, filenames have a suffix that indicates the state. For example, button_primary_pressed.9.png would be the primary button in its pressed state; chances are you’d also have a button_primary_focused.9.png and others. Usually, the StateDrawable (see Chapter 4 “Adding App Graphics and Resources”) is named either with no state (e.g., button_primary.xml) or with a suffix to indicate that it’s stateful (e.g., button_primary_stateful.xml or button_primary_touchable.xml). This book will use the former, but remember that these are all just conventions, not requirements. Use what makes sense to you; just be consistent. See Table 5.1 for more examples.

If you follow naming conventions, such as those in Table 5.1, it will be much easier to swap out assets and see how something different looks. In most cases, it’s enough to start by supplying just high-resolution assets such as all XXHDPI or XXXHDPI assets. Later in the process, when the assets are closer to finalized, you can create files for each of the other densities.

After reading this chapter, you should find navigation to be much clearer. It is particularly important that you understand the difference between the back button and “up” navigation, as discussed in this chapter. If you’re still unsure, see how the native Android apps handle this. In the next chapter, you will see how to develop prototype apps using the wireframes from this chapter, and you will learn to implement navigation so that you can see which really will work best for this woodworking tools app.