September 2015
Volume 30 Number 9
Modern Apps - Usability Practices for Modern Apps
By Rachel Appel | September 2015
.jpg "Rachel Appel")
Usability is an important but often overlooked aspect of application development. Developers tend to leave usability up to the UX experts and UI designers. However, there are some usability tricks—some small, some larger—developers can apply that have a big impact.
The primary motivator is developing software that’s actually easy to use. This means popular commands are prominent and readily available. Less popular commands are available with as few clicks as possible. I’ll review several usability tricks that will help you build great modern apps.
Many developers dislike the term “best practices.” It seems to imply the practice in question is the only way to do something, and you know that’s just not true. There are practices that work well in most scenarios, and a broad spectrum of techniques that may or may not work well. That’s why most are reluctant to use the term “best practices.” Instead I’ll use the term “good practices.” These practices generally work as well as, if not better than, other ways of doing things. That doesn’t mean you should apply them in every scenario, though.
Bad practices are often clearly bad. They’re design or development techniques for which there is a better way to do things. It’s easy to spot bad practices as they manifest themselves in frustrating software. Any time you’ve ever wanted to pull your hair out because you couldn’t use software, a bad practice was the culprit.
Good Usability Practices
The first and arguably most important usability practice is accessibility. The more accessible the software, the easier it is to use. There are a few types of users for whom accessibility is a challenge. You must consider those with low or no hearing, visual impairment, motor impairment and cognitive impairment. It’s relatively easy to develop Web sites and apps that incorporate accessible design. Many of those techniques include small modifications to HTML or CSS. See my column, “Design and Develop Accessible Modern Apps” (msdn.microsoft.com/magazine/dn913189), for more details on accessible design techniques.
Popular commands should be prominently displayed. Don’t make your users dig for information. Instead, use something like the Visual Studio Quick Launch functionality that lets users search for commands by typing the name or a synonym of the command. Add a Quick Launch feature to the regular menus and navigation. Along the same lines, don’t make users work too hard to perform tasks. Many users will stop at any roadblocks, and review apps in app stores poorly when they can’t easily accomplish tasks.
Consistency is the key to building great software. Use consistent aesthetics, within the app itself and between the app and its OS. Anyone can tell you how frustrating it is to try to use an app on an Android or Windows device that tries to look and behave like an iPhone app. Part of the reason people buy devices is because they like its style. Stick with the style paradigms of the host OS, and then add your own flair. This means you’ll need separate code bases, but you can still share back-end code between the apps.
Consistent navigation is also essential. Use the same navigation style throughout the Web site or app. As part of good navigational design, make sure users have quick access to their frequently used commands. You can determine those commands by logging every time the user launches them. Ensure that elements such as buttons and controls in forms have consistent labels. If you’re writing a novel, getting out the thesaurus and mixing synonyms improves your prose. In software, using alternate words or phrases for the same actions or fields only confuses users.
Everybody already has too many logins. As a side effect of that, many use the same password for all their resources. This is the kind of thing security experts warn you not to do. Then developers design Web sites that encourage this bad practice by insisting you code your own security infrastructure instead of using a trusted security provider such as OAuth, Microsoft or Google. Even Facebook or Twitter authentication is better than creating your own.
Whenever possible, give your users options. You can create your own login system, but then you must maintain it and you’ll be responsible if data is ever breached. Going with a trusted provider shifts the responsibility to them. They have entire teams working on maintaining and securing user data. Leaving the security to security experts leaves you time to be the business expert and solve the business problems with your software.
Proper defaults go a long way toward accessibility. It’s 2015, yet many Web sites and apps still force you to enter a city and state, instead of asking for a ZIP code and automatically filling in the details. Entering a small sequence of numbers is quite easy for users as compared to having to select from a massive list of items in a small dropdown. Check out my column, “A Mobile-First Approach to Modern App Development” (msdn.microsoft.com/magazine/dn948114), for more details on building software using a mobile-first design.
Responsive UIs scale up and down to fit the form factor and capabilities of a specific device. Obviously, tailoring software to the device is a good thing for users. Responsive UIs tend to be mobile-first. And mobile-first designs tend to be more useable than traditional software. For more on building responsive UIs, check out “Build a Responsive and Modern UI with CSS for WinJS Apps” (msdn.microsoft.com/magazine/dn451447).
A minimalist design is another hallmark of modern apps. Users will dump an app that overwhelms them with lots of rarely used choices. They’ll use apps that are straightforward and present choices as contextually necessary. In apps for Windows 8 and later, you can use app bars that can hide while the user works in the app, then present options as needed.
Bad Usability Practices
Many Web sites and apps include forms requiring the user to enter his e-mail twice. If he can’t get his e-mail correct, why does anyone think he’ll enter his address, city, state or other information correctly? Why aren’t all those fields duplicated?
Asking a user to re-enter his e-mail address is irritating. That’s because humans are creatures of habit. Typing and typos are like other habits. A user is just as likely to make the same typos in both boxes.
The concept of a Captcha is noble. A Web site or app will show an image containing a number, word or phrase. Then the user enters that number, word or phrase. The number, word or phrase in the image is usually obscured somewhat so computers can’t identify the image. The problem is nowadays AI systems can perform image recognition and easily recognize a Captcha. Most humans ironically have a difficult time. Human eyes are about par with computers when looking at an obscured pattern. Sometimes what seems like a good idea may not be after all.
Infinite scrolling and automatic page refreshes are also problematic, especially for those who rely on assistive technologies such as screen narrators. While Facebook, and more recently Twitter, do infinite scrolling well, there can still be difficulties when new content arrives and pushes old content aside. Consider trying alternative input and accessible devices if you’re implementing these features.
Tiny close buttons can drive even skilled users crazy. Often, people with touch devices can’t even use them because the tiny area is non-responsive to a tap. It’s not as bad if there’s a prominent close button. However, many dialog boxes contain only a button to continue, but no way to back out. Responsive modern apps always provide easy ways to back out of actions.
Bad formatting is the bane of good Web site design. Many users cringe when they see a telephone field in a form. You never know what kind of crazy validation is happening. Does this field want the country code? Should I enter the parenthesis and dashes with the number, or just enter the number? Users will often try to enter a number they believe to be in the correct format, only to be promptly scolded by a modal dialog that further interrupts their workflow.
Along with scary phone fields come URL fields. Many of these won’t automatically put in the https://. These same Web sites and apps never tell you the https:// is required until you click submit, fail validation and the form fields reset themselves.
There’s an entire set of bad practices concerning form failures. The entire reason forms exist is to capture data. Yet developers often make forms difficult and confusing. It’s maddening to attempt to fill out a form that insists on clearing its data if you forget something or do something wrong. Many Web sites and apps continue to do this. It takes twice the time to get things done.
If your app is trying to make money, this is a bad way to go. You’re blocking the user from making purchases. The more likely an app is to do things like clearing forms is proportional to how long it takes to fill it out. The longer it takes, the more likely a developer has decided to clear the form on unsuspecting users.
Another form fail is not implementing proper defaults. Are your users mostly from your country? Then default to that, but show the other countries as well. The same thing applies to states, ZIP codes, or the most popular value of any particular field. If your app has already been deployed, you can check the database for those values. If still in development, ask your users. One default Web sites never seem to miss, though, is setting the option to receive a newsletter or product information to checked.
Many Web sites and apps don’t provide proper search functionality. Some don’t provide search functionality at all. Search Engine Watch says a whopping 92 percent of Web users use at least one search engine all the time.
Present search results in easy-to-consume summaries and in a clear and consistent manner. Put ads around the search results or content, but not on top of it. When a user sees an ad inside a set of search results, she might think that’s the end of the results, so she’ll leave because she didn’t find anything.
There are several aesthetic don’ts in UI design. I like to call them “UI eyesores.” This includes things like tiny fonts that need to be zoomed in on to be read, too many ads or ads that contain ads. Many Web sites and apps rely on advertising revenue, so ads are a necessary evil. However, if your ads contain ads (yes, that is happening), it’s a disaster.
Another popular usability anti-pattern is button colors and placement. Often, a button designated to take or continue with an action is colored bright red. This color indicates stopping or canceling an action. Like traffic lights, green, yellow, and red colors tend to indicate go, caution, and stop, respectively.
Other Usability Practices
Navigation goes under “other usability principles” because there are some types of navigation that are conducive to ease of use, and some that aren’t. When designing a navigation scheme, it should be clear and consistent. It’s usually best to go with the host OS paradigms. Maintaining that consistency between the app and the OS makes it easier on users. This is especially true of new users or those who don’t use much technology. Nevertheless, it still holds true for experienced users who like shortcuts based on paradigm consistency.
Tabbed menus are often more appropriate and easier for navigation. However, if there are too many rows of tabs, it becomes difficult to navigate. Desktop apps do well with traditional pulldown menu structures, but Web apps and native device apps often require a different scheme. For example, Windows Phone uses Live Tiles to enhance the user’s experience by providing large, easy-to-tap areas to launch apps or navigate.
Hamburger menus are said to significantly drive down app or Web site engagement by a significant amount, according to the technology media site TechCrunch. If you choose a hamburger menu, then you need to keep informed about usage statistics. For more information on navigation usability essentials, check out “Navigation Essentials in Windows Store Apps” (msdn.microsoft.com/magazine/dn342878).
Wrapping Up
As a rule of thumb, more accessible software is more usable software. You can increase your user base by as much as 20 percent by implementing tiny changes. That’s a giant number by business standards, and any manager worth their salt (even pointy-haired bosses) would jump on those kinds of numbers. A great way to incorporate accessibility, and therefore better usability, is to try accessible technologies yourself. Blindfold yourself and try to use a page with a screen reader. Use a voice device.
While some practices here are listed as “good” or “bad,” that doesn’t mean they’re always one or the other. You can always break the mold of bad practices and make something more usable. It’s easy for good practices to go awry, as well. Ask your users what they like, but don’t always believe them because they can occasionally be wrong. Monitoring app usage is a great way to see what they’re really doing. Use your best judgment.
Rachel Appel is a consultant, author, mentor and former Microsoft employee with more than 20 years of experience in the IT industry. She speaks at top industry conferences such as Visual Studio Live!, DevConnections, MIX and more. Her expertise lies within developing solutions that align business and technology focusing on the Microsoft dev stack and open Web. For more about Appel, visit her Web site at rachelappel.com.
Thanks to the following Microsoft technical expert for reviewing this article: Frank La Vigne