Usability Matters
Mobile-first UX for developers and other accidental designers
Matt Lacey
  • July 2018
  • ISBN 9781617293931
  • 392 pages
  • printed in black & white

At last! A systematic treatment of the many different aspects involved in designing an app that people can use intuitively.

Alan Lenton, www.IBGames.com

Usability Matters: Mobile-first UX for developers and other accidental designers gives you practical advice and guidance on how to create attractive, elegant, and useful user interfaces for native and web-based mobile apps.

Table of Contents detailed table of contents

preface

acknowledgments

about this book

Who should read this book

How this book is organized: a roadmap

About the author

Part 1—​Context

1 Introduction

1.1 What’s usability, and why does it matter?

1.1.1 Usability matters to everyone

1.1.2 Usability, UX, and design

1.1.3 The formula for app success

1.1.4 Great usability experiences are intuitive

1.2 Six components of great app experiences

1.2.1 Context of use underpins everything in an app

1.2.2 Input includes all ways data and information get into the app

1.2.3 Output includes and goes beyond what is shown onscreen

1.2.4 Responsiveness: how output is perceived

1.2.5 Connectivity changes and isn’t always guaranteed

1.2.6 Resources are finite and must be managed

1.3 How considering all six components can make apps better

1.3.1 Example 1: an email client

1.3.2 Example 2: a news app

1.3.3 Example 3: a tower defense game

1.4 Why you need to consider the six components in your apps

1.4.1 Experience is an important differentiator

1.4.2 Meet the expectations of those who’ll use your app

1.4.3 Planning for success

Summary

2 Who’s using the app?

2.1 You aren’t your users

2.1.1 How you’re different from your users

2.1.2 You’re not an average user

2.1.3 Be aware of the effects on your thinking

2.2 Who’s the app for?

2.2.1 Who’ll get value from your app?

2.2.2 Understanding the potential user base

2.2.3 Are there enough people who want the app?

2.2.4 Targeting groups of individuals

2.2.5 Putting on a persona, or several

2.2.6 Enterprise app usage

2.3 People aren’t all the same

2.3.1 Consider people’s differing abilities

2.3.2 Consider people’s differing expectations

2.3.3 Consider people’s differing goals

2.4 What are people doing?

2.4.1 What are people doing with the app?

2.4.2 What else are people doing?

Summary

3 Where and when is the app used?

3.1 Where is the app used?

3.1.1 App usage at a macro-geographic level

3.1.2 App usage at a micro-geographic level

3.2 The regional impact on an app

3.2.1 Considering support for multiple languages

3.2.2 How culture and locale can impact an app

3.3 When is the app used?

3.3.1 Consider the time of day

3.3.2 Consider the day of the week

3.3.3 Consider the time of year

3.3.4 How long is the app used?

3.4 What activities are being undertaken while using the app?

3.4.1 Is the person using the app moving or stationary?

3.4.2 Is the user dedicated or distracted?

3.4.3 Is use isolated or in conjunction with something else?

3.4.4 Are they standing, sitting, or lying down?

Summary

4 What device is the app running on?

4.1 Write once, run everywhere?

4.2 Supporting multiple operating systems

4.2.1 OS-imposed restrictions

4.2.2 Looking like you belong on the OS

4.2.3 Belonging on a version of the OS

4.2.4 Belonging in the enterprise

4.3 Maintaining brand identity and differentiation

4.3.1 Branding vs. visual identity

4.3.2 Separating your brand from the OS

4.3.3 Maintaining OS conventions while still reflecting a brand

4.4 Supporting different device capabilities

4.4.1 Handling multiple physical device sizes

4.4.2 Variations in internal hardware capability

4.4.3 Accounting for software variations

Summary

Part 2—​Input

5 How people interact with the app

5.1 Supporting different pointing devices

5.1.1 Providing input with a finger

5.1.2 Providing input with a stylus

5.1.3 Providing input with a mouse and the keyboard

5.2 Using a pointing device to provide input

5.2.1 Supporting gesture-based input

5.2.2 Supporting multi-touch input

5.3 When pointing and touch input become difficult

5.3.1 Touch events don’t always do what the user wants

5.3.2 Raw input events need special attention

Summary

6 User-entered data

6.1 The goals of the people using the app

6.1.1 Improve tasks by minimizing input

6.1.2 Improve tasks with defaults and suggestions

6.1.3 Improve tasks with alternative inputs

6.2 How to ask for data to be entered in forms

6.2.1 Optimizing how the form is arranged

6.2.2 Simplify how text is entered

6.2.3 Password entry requires special consideration

6.2.4 Simplifying entry from a fixed set of options

6.2.5 Validation and required fields

Summary

7 Data not from a user

7.1 Data from web-based resources

7.1.1 Dealing with the data you directly request

7.1.2 Dealing with data pushed to the app

7.2 Getting data from the device

7.3 Getting data from sensors

7.3.1 Transparency and permission when using sensor data

7.3.2 Allow for variations in sensor input

7.4 Using heuristics and inferring input

7.4.1 Enhancing the app experience based on an individual’s usage

7.4.2 Enhancing the app experience based on the usage of all people

Summary

Part 3—​Output

8 Displaying items in the app

8.1 The fundamentals of good visual output

8.1.1 Focus on the person using the app and their goals

8.1.2 Meet the expectations of the people using the app

8.1.3 Account for the specific device being used

8.1.4 Respect standards and conventions

8.2 Laying out controls on a screen

8.2.1 Implying meaning and relationships through alignment and hierarchy

8.2.2 Implying meaning and relationships through consistency

8.2.3 Implying meaning and relationships through proximity

8.3 Navigating within the app

8.3.1 Common navigation patterns

8.3.2 Special navigation considerations

8.4 Avoiding discrimination with what you display

8.4.1 Ensure your UI works for everybody

8.4.2 Saying the same thing to everybody who uses the app

8.5 Many factors affect the display of images

8.5.1 One size doesn’t fit all

8.5.2 Physical size isn’t everything: consider formats and formatting too

8.5.3 Customizing image placeholders

8.6 Use distinct icons with specific meanings

8.7 Allow for extremes of connectivity and content

8.7.1 Content that loads slowly or doesn’t load at all

8.7.2 When content isn’t available

8.7.3 Avoiding empty states

Summary

9 Non-visible output

9.1 Physical and audio output support changes onscreen

9.1.1 Give your app a voice

9.1.2 Haptic feedback starts with vibration

9.2 Output to other apps and devices

9.3 Communicating from your backend

9.3.1 Allowing for multichannel communication

9.3.2 Sending effective push notifications

9.3.3 Using badges with push notifications

9.4 Communication via channels beyond the app

9.4.1 Using email to communicate with your users

9.4.2 Using SMS to communicate with your users

9.4.3 Using third-party messaging services to communicate with your users

Summary

Part 4—​Responsiveness

10 Understanding the perception of time

10.1 How people perceive mobile time

10.1.1 Context influences the perception of responsiveness

10.1.2 Perception is about feelings, opinions, and comparisons

10.1.3 Being responsive with notifications

10.1.4 Meet expectations, don’t just be as fast as possible

10.2 Influencing the perception of responsiveness

10.2.1 Answer questions about what the app is doing

10.2.2 Show appropriate progress when something’s happening

10.2.3 Animation can hide delays

10.2.4 Usable isn’t the same as finished

10.3 Perceptions associated with the age of your app

Summary

11 Making your app start fast

11.1 Doing the minimum to start the app

11.1.1 Deciding what to do on startup

11.1.2 Displaying a splash screen when launching the app

11.2 Preloading content to make the app faster

11.2.1 Preloading content to distribute with the app

11.2.2 Preloading content for the app’s next use

11.3 Preformatting content retrieved by the app

11.4 Caching content to save time and money

11.4.1 Using in-memory and disk-based caches

11.4.2 Checking for new versions of cached items

11.4.3 When to invalidate and delete cached items

Summary

12 Making your app run fast

12.1 Using eager loading so people don’t have to wait

12.1.1 Eager loading complements preloading content

12.1.2 Beware of being too eager

12.1.3 Knowing what to load eagerly

12.2 Parallel operations take less time

12.2.1 Synchronous and asynchronous operations

12.2.2 Advice when working in parallel

12.3 Combining requests for improved speed and control

12.3.1 Controlling the server your app connects to

12.3.2 Getting faster responses by combining requests

12.3.3 Simplifying the client by combining requests

12.3.4 Combining requests and local files

Summary

Part 5—​Connectivity

13 Coping with varying network conditions

13.1 Not all connections are the same

13.1.1 Securing your connection

13.1.2 Connection speed can vary

13.1.3 Connection cost can vary

13.2 Occasionally connected is the norm

13.2.1 Connections may not be possible

13.2.2 Connections may be lost

13.2.3 Connections may change

13.3 Optimizing for subprime conditions

13.3.1 Caching improves the experience in subprime conditions

13.3.2 Compression improves the experience in subprime conditions

13.3.3 Deferring actions increases what’s possible in subprime conditions

13.3.4 Batch operations in subprime conditions

13.3.5 Automatic retries improve the experience in subprime conditions

13.4 Balancing usability and a poor connection

13.4.1 Prioritizing important activities in poor conditions

13.4.2 Adjusting network usage based on network conditions

13.5 Keeping the user in control when conditions are poor

Summary

Part 6—​Resources

14 Managing power and resources

14.1 When it’s gone, it’s gone

14.2 Do you really need it?

14.2.1 Lazy loading reduces wasted effort

14.2.2 Using alternatives to save resources

14.3 How often are you going to use it?

14.3.1 Managing resources that are only used once

14.3.2 Managing resources that are used repeatedly

14.4 Do you still need it?

14.4.1 Turning off resources when finished

14.4.2 Responding to changing circumstances

Summary

Appendixes

Appendix A: Exercise answers

Chapter 2 Who’s using the app?

2.1.3 Know that you’re different

2.3.3 Being aware of people’s differences

2.4.2 Learn about and from the people using the app

Chapter 3 When and where is the app used?

3.2.2 Regional and location impact

3.3.4 When the app is used

3.4.4 Activities influencing the app

Chapter 4 What device is the app running on?

4.2.4 Understanding different operating systems

4.3.3 Brand identity and differentiation

4.4.3 Varying hardware and software capabilities

Chapter 5 How people interact with the app

5.2.2 Appropriate gestures

5.3.2 The truth about challenging touch input

Chapter 6 User-entered data

6.1.3 Minimizing input

6.2.5 Evaluate this login form

Chapter 7 Data not from a user

7.1.2 Data from the web

7.2.3 Data from the device

7.3.2 Data from sensors

Chapter 8 Displaying items in the app

8.1.4 Visual fundamentals

8.3.2 Navigation

8.7.3 Handling extremes

Chapter 9 Non-visible output

9.1.2 Physical and audio output

9.3.2 Backend communication

9.4.3 Communicating beyond the app

Chapter 10 Understanding the perception of time

10.1.4 Perceiving time

10.2.4 Influencing perception

Chapter 11 Making the app start fast

11.3 Preloading and preformatting content

11.4.1 Where to cache

11.4.3 Caching, true or false?

Chapter 12 Make the app run fast

12.1.3 When to load data eagerly

12.2.2 Acting asynchronously

12.3.4 Combining requests, true or false?

Chapter 13 Coping with varying network conditions

13.2.3 Occasional and varied connections

13.3.5 Coping with subprime network conditions

13.5 Communicating app activity

Chapter 14 Managing power and resources

14.2.2 Doing what’s needed

14.3.2 Frequency of use

14.4.2 Changes and turn offs

Appendix B: Put it into practice

Chapter 2 Who’s using the app?

2.2.6 Know your users

2.4.2 Analyze app usage

Chapter 3 Where and when is the app used?

3.1.2 Location of app usage

3.2.2 Regional impact on your app

3.3.4 When the app is used

Chapter 4 What device is the app running on?

4.2.4 Knowing the OS your app runs on

4.4.3 Device differences

Chapter 5 How people interact with the app

5.1.3 Different input devices

5.2.2 Gestures and multi-touch input

Chapter 6 User-entered data

6.1.3 Align your form with user goals

6.2.5 Optimize your forms

Chapter 7 Data not from a user

7.1.2 Data from the web

7.2.3 Data from the device

7.3.2 Using sensors for input

7.4.2 Giving people what they want without asking

Chapter 8 Displaying items in the app

8.1.4 Visual fundamentals

8.2.3 Be consistent with layout

8.3.2 In-app navigation

8.4.2 Avoid discrimination

8.5.3 Displaying images

8.6 Be iconic

8.7.3 Empty states

Chapter 9 Non-visible output

9.1.2 Nonvisual output

9.1.2 Nonvisual output

9.2 Output and other apps

9.3.2 Output from the backend

9.4.3 Communicating outside the app

Chapter 10 Understanding the perception of time

10.1.4 Time perception and your app

10.2.4 Influencing perception

10.3 App updates

Chapter 11 Making your app start fast

11.1.2 Making your app do the minimum on startup

11.2.2 Preload content in your app

11.3 Preformat content used by your app

11.4.3 Cache content used by your app

Chapter 12 Making your app run fast

12.2.2 Making asynchronous requests

12.3.4 Combine requests

Chapter 13 Coping with varying network conditions

13.1.3 Allowing for connection variations

13.2.3 Allowing for occasional connections

13.3.5 Allowing for subprime network conditions

13.4.2 Usability in poor conditions

13.5 Keep the user in control

Chapter 14 Managing power and resources

14.1 Managing battery life

14.2.2 Resource alternatives

14.3.2 How often you use resources

14.4.2 Do you still need it?

Appendix D: Bibliography

index

About the Technology

Just because a mobile app works doesn’t mean real people are going to like it. Usability matters! Most mobile developers wind up being part-time designers, and mastering a few core principles of mobile UI can make the difference between app and crap.

About the book

Usability Matters is a guide for developers wrestling with the subtle art of mobile design. With each expertly presented example, app developer and designer Matt Lacey provides easy-to-implement techniques that instantly boost your design IQ. Skipping highbrow design theory, he addresses topics like gracefully handling network dropouts and creating intuitive data inputs. Read this book and your apps will look better, your users will be happier, and you might even get some high-fives at the next design review.

What's inside

  • Understanding your users
  • Optimizing input and output
  • Creating fast, responsive experiences
  • Coping with poor network conditions
  • Managing power and resources

About the reader

This book is for mobile developers working on native or web-based apps.

About the author

Matt Lacey is an independent mobile developer and consultant and a Microsoft MVP. He’s built, advised on, and contributed to apps for social networks, film and TV broadcasters, travel companies, banks and financial institutions, sports companies, news organizations, music-streaming services, device manufacturers, and electronics retailers. These apps have an installed base of more than 500,000,000 users and are used every day around the world.

Matt previously worked at a broad range of companies, doing many types of development. He has worked at startups, small ISVs, national enterprises, and global consultancies, and written software for servers, desktops, devices, and industrial hardware in more languages than he can remember. He lives in the UK with his wife and two children.


FREE domestic shipping on three or more pBooks

An engaging and easy read. It is instantly apparent this book distills years of experience into easy-to-digest chapters.

Desmond Horsley, NSW Health Pathology

Highly recommended to any developer trying to wrap their head around app usability.

Clifford Kamppari-Miller, The Tech Service

There were many gems in this book that brought on an ‘Oh yeah, that makes sense!’ kind of response.

Alvin Raj, Oracle