Luke Wroblewski on Mobile Inputs

This week I attended Luke Wroblewski’s day-long workshop on Mobile Inputs at the UX Immersion 2012 conference. Here are my notes:

Mobile Input Controls

  • New mobile inputs are not just disruptive — They introduce completely new ways of doing things and totally new things to do.
  • Some designers will tell you not to use text inputs because people won’t type on a smartphone, but people send 4 billion SMS messages every day.
  • When people have something they want or need to do on their smartphone they will use text inputs if they have no other choice.
  • That said, avoid having people type any time you can, but don’t avoid text inputs when you can’t. Always encourage input, don’t limit it.
  • Think of people as one eyeball and one thumb when you design. Their partial attention requires a very focused design.
  • Think of a smartphone as a content creation device, not just a media consumption device. The most popular apps are content creation apps — Facebook, Twitter, Instagram, Draw Something.
  • Try to use the standard input types for mobile websites because they have been optimized for the operating system.
  • When you use standard input types, good things happen, because people already know how to use them. But don’t be afraid to go beyond the standard ones.
  • Try not to use select menus in Android if contents are longer than the screen because people may think their choice is limited to what is on the screen.
  • Try non-standard input types when there are too many taps, like the four required to use the select menu picker in iOS.
  • A stepper is easier than a picker if you have a small range (3 to 5) of numeric choices.
  • Only present input controls when people actually need them. Use progressive disclosure. Don’t hit them with everything up front in a long form.

Touch Target Size

  • Design for a physical size, not a pixel size, due to differences in screen resolution and pixel density. Apple, Android, and Microsoft have extensive documentation and recommendations.
  • Use a minimum spacing between tappable objects as recommended by the operating system developer.
  • Studies show that 80% to 90% of people are right handed, and that about 50% of left-handed people use their right hand to for their phone. Most apps can get away with being designed for right-handed users.

How to Make Input Less Error Prone

  • Use the correct keyboard version for email addresses, URLs, and numeric values like zip codes and credit card numbers. For mobile web this is supported by HTML5 input types.
  • Turn off auto-capitalize and auto-correct for login screens.
  • Use input masks to change people’s input to the correct format. For email addresses, use an input mask that puts @yourdomain.com at the end of whatever the user types and show the person this is what is happening.
  • Use smart defaults (for example, the no tax checkbox is selected by default on eBay mobile).
  • Top align field labels because of field zoom.
  • Don’t remove critical features, like password recovery, from a login screen.
  • Consider just showing the password instead of masking it as asterisks, or show it by default and give the user the option to hide it.
  • Apply the concept of “touch first” and only go to the keyboard when there is no other way to collect the information.

Mobile Web vs. Native Apps

  • It’s not about which is better, it’s about what’s right for the use context and business goals.
  • A mobile website has near universal reach; a native app is a much more richer experience (although HTML5 and jQuery Mobile are changing that rapidly).
  • Designers working on the mobile web should look at apps for examples of controls you could try on mobile websites. The creators of Android and iOS built new operating systems from the ground up so they have had to think about making controls better.
  • Many device features like geolocation and access to a device’s compass are now available to web browsers through APIs. Even greater access to a device’s hardware features is coming in the future.
  • Facebook and Twitter get half of their content from mobile devices, and half of Facebook’s mobile content is from the mobile web.
  • The more app usage occurs, the more mobile web use occurs, and vice versa. They both drive each other.
  • The more people engage with a brand through the mobile web or apps, the more they engage with the desktop experience. Recognize they are all part of a holistic experience.

Mobile Web Advantages

  • Cross-platform reach and near universal access with one code case.
  • Faster development time because well-known web technologies like HTML, JavaScript, and CSS are used.
  • Larger developer pool available.
  • You can update your app at any time and don’t have to wait for Apple App Store review or for people to download the app to get the latest features.

Native App Advantages

  • Deeper hardware access.
  • Multi-tasking.
  • App sales and in app sales.
  • Integrated access with other locations like stores is easier (at least today).
  • Faster performance because much of the UI is already on the device.

Design From a Mobile Mindset

  • If you approach a checkout flow from a desktop perspective you’ll just get a shorter form.
  • If you approach it from a mobile mindset you’ll think about whether or not this person is in a physical store with a device that has a camera and can scan barcodes. Mobile devices can streamline the in-store checkout process.

Voice/Audio Input and Proximity Sensors

  • Android allows voice input to any form that allows text input.
  • Apple has Siri, and it is rumored Apple may open Siri APIs to programmers at the Worldwide Developers Conference in June.
  • Shazam and IntoNow use ambient sounds around a person as audio input.
  • If you put an iPhone next to your face during a call the proximity sensor hides the keypad so you don’t “cheek dial”.
  • With proximity sensors “every object in the world is now an input”.

Device Sensors for Input

  • Instapaper speeds up or slows down scrolling speed when you change the pitch of the device, allowing people read at their own pace without swiping.
  • Nearest Tube uses device motion, GPS, and the compass to show nearest London Underground station.
  • Google Goggles and FitBit are also examples of using hardware features as inputs.
  • The Android Galaxy Nexus, the first phone to come with Android 4.0 installed, uses facial recognition for its Face Unlock feature.
  • A proposed addition to the GetMediaUser API would open this to web browsers.
  • While Windows 8 is a desktop operating system, it allows people to create logins by logging custom gestures on lock screen images, for example drawing a line from a child to a pet on the picture. This is a very human solution to login problems. It’s like telling the computer “Hello, it’s me, let me in.”

Gestures for Input

  • Multiple finger gestures: two-finger drag moves an object, three-finger drag moves an entire pane in an app, four-finger drag moves the user between apps, and five-finger drag invokes operating system functions. However, these are emerging pattern, not universal rules.
  • Teach in context to help people learn how the app works when they need to know it, not in some large upfront tutorial (the Clear app does both).
  • Use content as navigation to remove as much chrome as possible.

Luke Wroblewski is the author of Mobile First. You can follow him on Twitter at @lukew

Mobile UX Design With Rachel Hinman

This week I attended Rachel Hinman’s day-long workshop on The Mobile Frontier at the UX Immersion 2012 conference. The conference, a new gathering arranged by User Interface Enginnering, featured deep dives on mobile and agile development. Here are my notes:

There are Many Similarities Between Mobile and Desktop UX Design

  • Many of the tools and techniques we use are the same.
  • We sketch.
  • We prototype.
  • We need to learn what our users need and want.

But There are Also Differences

  • A phone is not a computer.
  • There is no sense of having windows or UI depth.
  • There is a smaller screen for user input and new inputs based on context and device sensors.

How a UX Designer Transitions to the Mobile Mindset

  • Buy a device and integrate it into your life.
  • Know the medium and become mindful.
  • Participate in the experience.
  • Brace yourself for a fast and crazy ride.
  • This is an emergent area of user experience so nothing we do will be constant for long.
  • Embrace ambiguity, it’s fun and exciting.

Context is complex but is essential to great mobile experiences

  • The mobile context is about understanding the relations between people, places, and things.
  • Relationships between people, places, and things are spatial, temporal, social, and semantic.

Designing for Contexts

  • Design for inattention and interruption.
  • The mobile use experience is snorkling, the desktop user experience is scuba diving.
  • Reduce cognitive load at every step in the experience.
  • Ideate in the wild — you can’t innovate in mobile from behind your monitor.
  • Ruthlessly edit content and features down to what’s essential.

Sketching

  • It’s a good way to develop ruthless editing skills.
  • You can change a design quickly at little cost.
  • No expert skills needed.

Prototyping

  • The exercise helps designers new to mobile who do not yet know the heuristics and constraints of the medium.
  • It’s essential for mobile UX because the medium is so new.
  • If you are prototyping for a desktop app and a mobile app, allocate to mobile triple the amount of time you devout to the desktop.
  • Prototyping helps you fail early and fast.
  • Because a mobile experience is so contextual and personal, explore techniques like body storming and storyboarding.
  • Prototyping is a great way to fail when it matters (and costs) the least.
  • Desktop prototyping is a luxury, mobile prototyping is essential.

Graphical User Interface vs. Natural User Interface

  • We are at a pivotal moment in the design of user experiences — the NUI/GUI chasm.
  • A GUI features heavy chrome, icons, buttons, affordances; what you see is what you get.
  • A NUI features a little chrome as possible and is fluid so content can be the star.
  • As UX designers we need to work to eliminate chrome, not make the chrome beautiful.

Motion as a Design Element

  • Animations and transitions can teach users how the information unfolds (see Flipboard).
  • Motion brings fun to the party, and who doesn’t want to have fun.

Rachel Hinman is the author of the forthcoming The Mobile Frontier. You can follow her on Twitter at @hinman

The Wisdom of Edward Tufte

I finally took Edward Tufte’s day-long information design course last week. Tufte, long a thought leader on the topic of graphically showing quantitative and scientific data, shared his principles for displaying this evidence in any media. Here are my notes:

  • Designers of data displays, either printed or online, should strive to reduce the time it takes to learn the display format and increase the time the reader devotes to thinking about the data.
  • Use “small multiples“, repeated use of the same type of graphic, to reduce learning time. Once a person figures out how one graphic is read, they know how to read all the graphics.
  • Charts and other graphical displays should always tell stories. This often involves displaying information using a time scale.
  • Data displays should supply context as well as information. A price increase from one year to the next tells little unless it is shown in the context of the past five or 10 years.
  • Multi-variate data graphics supply the richest context and tell the best stories. Price increases (or declines) shown over time and compared to wage increases (or declines) for the same period tell a much more powerful story than simply showing the price increase alone.
  • Keep “chartjunk” and “chartoons” to a minimum. Embellishments like gradients or patterns for the backgrounds of charts and graphs only get in the way of the information. Designers should strive for a high ink to data ratio.
  • If content in a display needs to be compared to other content, put the two chunks of content next to each other. It’s unreasonable to ask a person to go back and forth between web pages or printed pages when trying to compare two or more things.
  • Using area to display quantitative data is a risky proposition. Unless the scale of the area of all diagram elements exactly matches the scale of the data, the graphic is lying.
  • In a related thought, the only thing worse than using a pie chart to display quantitative data is using multiple pie charts. It is impossible for people to figure out what percent of the whole is represented by the pie pieces without the numbers being displayed on the slices. And if you need to display the numbers, why not use a simple table instead.
  • When designing line and bar charts, don’t place a legend off to the side. This forces people to have to scan back and forth between the graphical element and the legend. It is better to put the notation near the elements in the graph itself.
  • A graphical user interface should be “invisible” so that people can focus on the information. If we as designers do our jobs correctly, people won’t be aware of our work.

I’m sure there are points I missed. All of Tufte’s principles are covered in four of his beautifully produced books that came with admission to the course. They are themselves examples of Tufte’s principles.

Touchscreen Design Best Practices

Saturday was Day 2 of the Mobile UX sessions at Nielsen Norman Group’s Usability Week in San Francisco. The focus was on designing for touchscreens. Here are my notes:

  • Allow Users To Go Back and Undo: Make sure users can compensate for accidental taps. Have them confirm any action that would delete their data, erase their work, or process a transaction.
  • Don’t Force Users To Change Device Orientation: Whether your app is a content app like the New York Times or a utility app like American Airlines make sure it can adjust its layout to however a person is holding their device.
  • Pad Those Links And Buttons: Padding a widget can improve people’s accuracy in clicking it. For example, if you display an product image and description in a list layout, make the whole row clickable, not just the image or the text.
  • Padding Can Prevent Errors, But Won’t Increase Efficiency: In cases where you have a clickable invisible padding area around an object, people will still slow the movement of their finger as it approaches the target. Because they don’t know the target is actually larger, they treat it like it is smaller. Fitts’ law is still on the books.
  • Pad Links On Your Wired Site If You Want It Used on Tablets: Many site managers have learned that iPad and other tablets owners are using their wired sites instead of the mobile versions that were designed with smartphones in mind. See Yahoo!’s tablet site for cues on how a wired site can be tweaked to work on a touchscreen tablet.
  • Avoid Localized Swipes: When a left or right swipe only changes one horizontal section of a screen, it confuses people as to what the gesture does. Localized swipes don’t match real world movement, in which pushing something moves the entire object, not a portion of it. Don’t make your app a stack of independent carousels.
  • Provide Cues To Unseen Functionality: Gestures are great for maximizing screen layout but can be undiscoverable by new users. The convention of pulling down on a screen to refresh content that Twitter and other mobile sites use is hidden from the view of new users. Provide cues to new users to help them learn these gestures.
  • Don’t Rely On The Accelerometer For Navigation: People who are new to more advanced mobile devices may not even know about “shaking” as a means for input. Others may find it clumsy or uncomfortable. It’s OK to use the accelerometer, but don’t make it to sole means for input. Urbanspoon’s iPhone app is a good example of an app that uses the accelerometer but also has a big red button.
  • Use Sliders With Caution: Sliders as interface controls are imprecise. Don’t use them if the person has to get to an exact value.
  • Tablets Are Not Smartphones: Don’t be afraid of rich interactions on iPads and other tablets. Tablet users are not “on the go” in the same way as smartphone users.
  • Design A Distinctive Home Screen Icon: Make your app’s icon distinct so it can be recognized on a crowded home screen. If people have to remember your app’s icon, they may never click it.
  • More Is Often Less: Adding features to your mobile app doesn’t always make it better, especially if they add too much complexity. Add features of they make sense in a mobile context, not just because they exist on your wired site.

Mobile Design Best Practices

Today was Day 1 of the Mobile UX sessions at Nielsen Norman Group’s Usability Week in San Francisco. Here are my notes:

  • Design For Interruptions: Since mobile usage is out “in the wild” you have to assume interruptions will happen. Support auto-save and user initiated saving of work. Remember what people type into form inputs and never make them type the same information twice.
  • Design For Continuous Experiences: If users can enter information or save things on your wired site, make sure they can access that information on your mobile app/site. And also let them save and add information on the mobile version that flows back to the wired site.
  • Reduce Interaction Cost: Anything you can do to remove typing reduces interaction cost. Even on the most advanced mobile device, typing is annoying at best (I know this because I’m writing this on an iPad). Whenever your design asks a person to type, ask yourself if there is another way to get this information other than the device keyboard.
  • Make Designs Self-Sufficient: Don’t make people have to leave your app/site to get a necessary piece of information. For example, if your site is a banking site that only processes transactions on business days, don’t offer a date picker that includes weekends or holidays. If someone has to get into their device calendar to check if June 19 is a weekend, they may not get back to the same place in the transaction and may have to start over.
  • Don’t Force People To Rely On Memory: Don’t send people an email with a cryptic promotion code and then send them to a site where they have to remember that code. Pass the code in on the URL if they click anything on the email and keep it in memory for the length of their session. If they have to go to their email when presented with a promo code input during checkout, they may never get back to complete the transaction.
  • Preserve Session State Throughout The Visit: Don’t let people click a Save to Favorites icon from a search results screen and then send them back to a screen where they have to reenter their search term(s) to get the same results list. Remember what they were doing and get them back intact when they go down alternative paths. And provide them a way to easily start a new search if indeed they are done with their previous search.
  • Remember People’s History: Don’t make people reenter information they already provided. If someone enters a zip code or selects a gender while shopping for shoes, persist that throughout their session (at a minimum). There’s little that’s more annoying than having to reenter information on a mobile keyboard.

Day 2 of Mobile UX is tomorrow. The focus is on touchscreens. You can follow the live tweets at #nnguw.

Having Fun With a Great Idea

I can’t remember the last time I had so much fun working on a weekend. This happened when I had the good fortune to be a participant in the UX For Good’s UXXU 2011 design challenge about a week ago. I got to spend two days with some really smart folks trying to help solve some very serious social problems. It was time well spent.

My challenge team got to partner with the Adler School of Professional Psychology to develop a plan to better engage their students, faculty, and city with their mission of advocating a community-based approach to addressing mental health issues. For two days we delved into the challenges the Adler School faces and brainstormed on short- and long-term solutions.

Did we solve the problems? No. But did we expect to? Not really. To be honest, these are some fairly complex social problems that are way beyond the ability of 100 or so dedicated people to resolve in 48 hours. There have been critics of what we did, but they totally missed the point. Instead of rebutting I’ll let Cia Romano’s thoughts make the case.

So what did we accomplish? I think we showed the five non-profits that short exercises in brainstorming can be extremely productive. We showed that tapping engaged and passionate people who may lack in-depth domain expertise but have a knack for quickly ferreting out the details of a situation can be a beneficial exercise. We showed that opening discussions about a problem to a wider audience can yield fresh ideas.

Is this approach how the social ills these groups are fighting will be solved? Probably not, at least not by itself. But can it be part of a larger recalibration of how we address problems that have been so seemingly intractable for so long? I certainly hope so. And that is success.

Note: UX for Good will in New Orleans next year. I can’t think of a better place to move this idea forward.