Day 1 of the Future of Web Design was a fantastic workshop on designing for mobile with Josh Clark aka @globalmoxie, fellow Brooklynite and author of Tapworthy, a sharp guy, and a great speaker. Hop below the fold for the full notes.

§1: Mobile Context

Intro

• Early assumptions about designing for mobile may not have been right
• JC wrote “TapWorthy: Designing great iPhone Apps”. More of a general touch-ui specific book than exclusively iPhone.
• Q: “What’s your favorite app?” A: uhhhhh…they all drive me crazy? Maybe MindSnacks. Discuss w/ yr neighbor.
• Software used to be very grey and dry, but it’s tough to get you to stop talking about your favorite app. It’s an engaging question. First the web, and now especially mobile, have made software much more human and lovable and fun.

Anthropology

• We’re all anthropologists here.
• Though we design monolithically, there’re lots of mobile cultures.

Myths

Myth 1: Mobile users are rushed and distracted

Mobile isn’t actually mobile anymore. It’s on the couch, in the kitchen, on the 3 hour layover. We have time. Mobile != Desktop Lite

• Example: alibris (amazon competitor) left its main differentiating feature (rare book sales) off the mobile app.
• 28% of US mobile web users mostly use the web on mobile
• 25mm people only see the web via a phone
• Making all content and features is a “civic responsibility”. Mmm…

Myth 2: Mobile == Less

• Jacob Nielson recently advised a separate, feature-reduced site for mobile. JC does not agree.
• Don’t confuse context with intent.

Myth 3: Complexity is a dirty word

• Complexity is good. It’s powerful.
• Mitigate confusion, not complexity.
• Figure out what the user needs.
• Example: “Do I need an umbrella”? app is perfect for JC. For his Weather-Channel-watching father in law, it’s condescending.
• It’s not that ‘less is more’; it’s that ‘just enough is more’.
• Original Facebook iOS app was desktop-lite; users were incensed. “No comments?! No photos?!” It’s since grown to include ~90% of the desktop feature set, and it the most-used FB interface.
• Don’t manage complexity all at once; manage it through give-and-take.
• Don’t confuse clarity and density
• “Every screen should have a primary task”.

Myth 4: Extra taps and clicks are evil

• We’re not on dial-up modems anymore. A lot of “minimize clicks” ethos had to do with mitigating the effects of latency.
• “Every tap should deliver satisfaction”: more information, a smile, whatever.
• “Progressive disclosure”: give a little bit at a time, as its asked for.
• An interesting opportunity for phones is that there’s probably only one user; you can train a specific user. E.g., twitter was hiding some controls. To educate the user, they opened the screen w/ hidden controls visible, and then hid them after 250ms. Later, they turned off the animation once the user triggered the “Show more controls” button.
• “Mobile == More“
• How can mobile do more? It’s got cameras, microphones, gyroscopes.
• Start with a basic site, use feature-sniffing javascript to discover what the client can do.

Myth 5: Gotta have a mobile website

• You need a great mobile experience, but a mobile website? Maybe not.
• There is no ‘mobile web’. Don’t silo by device.
• if “www.mysite.com” redirects to “mobile.mysite.com”, you’re doing it wrong. URL == Uniform resource locator.
• We only know device context, not user context.
• Ideally, there should be One Web.
• The mobile site shouldn’t have less stuff than desktop because there’s a smaller screen. It should have less stuff because most of the stuff on desktop is crap.
• Luke W.’s whole “mobile first” point is that small-screen design constraints are a useful filter for everything.
• Content runs the show. Your interface is a collection of apps plugging into the wellspring of content.

Myth 6: Mobile is about apps (or websites)

• We tend to focus on a single container (e.g. apps or websites)
• An app isn’t a strategy; it’s an app.
• Your product isn’t an app, or a website, or a feed, etc. These are all containers. You’re product is your content.
• We have to pull back from our obsession with presentation and think about content.
• Civilians (not just geeks) are beginning to expect their content to be available on every device.
• Some people have all the devices (laptop, tablet, phone), others only have one.
• We’re also beginning to expect that this content is integrated: when I put down my Kindle and start reading on my phone, or I pause a Netflix movie on the TV and pick it up in bed on my iPad, it picks up where I left off. With iCloud, this is happening with the content we create.
• We’re all iCloud developers now.
• Every native app should be a web client. The browser’s a native app, btw.
• Some thoughts on this stuff: http://futurefriend.ly

Myth 7: CMS and API are for database nerds

• We all need to think about this stuff.
• Structured content is going to allow us to design for multiple platforms.
• “Metadata is the new art direction.” Ethan Resnick, @erd_ux 19-yo NYU student(!)
• Ergo, we have to drive our design skills further down the stack.
• Traditional editorial judgement often disappears when we go mobile, e.g. newspaper layout (reflects editorial judgement about what’s important) vs. many digital interfaces (often simply reverse-chronological order).
• Let the robots do it: e.g., the Guardian parses InDesign .indd files to gauge importance and reflect that on the web.
• Repurpose design content.
• Create content and design strategies that aren’t tied to a particular container.

Summary

• Mobile != rushed
• Mobile != less
• Complex != complicated
• Tap quality > tap quantity
• No such thing as ‘mobile web’
• Focus for all platforms
• Don’t think ‘app’; think ‘service’.
• Metadata is the new art direction

Everywhereness is a design nightmare

• It suggests infinite possibilities and therefore infinite priorities.
• “Simplify before we suppress.” – Ethan Marcotte

Contexts we tend to design mobile against:

Context #1: I’m microtasking:

• Capture lost time: waiting on line, when your dining companion leaves for the bathroom, etc.
• identify lost tasks
• Find the primary task for an app and make it available everywhere (e.g. todo apps should have an ‘add task’ icon on every screen).

Context #2: I’m local

• Mobile is the primary device not because it’s always with you (though that’s important), but because it knows the most about you: sensors, personal data
• change context, not content:
  • Shopper: shuffles your shopping list depending on where your geolocated in the store, e.g. produce aisle, dairy, etc.
  • Word Lens: point camera at a word in a foreign language, see translation.
  • IntoNow: foursquare for TV that listens (like Shazam) to identify season and episode.
• Save input effort on these devices because they’re not that good at traditional input.
• Table Drum: map table taps to drum kit sounds. WANT! Transforms your environment into an interface.
• How can we use the superpowers of the device for input?

Context #3: I’m bored

• It’s not so much “i’m bored” as “i have attention to spend”.
• Software isn’t just for work anymore: fart-apps might be frivolous, but they represents a shift from software-as-business-tool to software-as-distraction and entertainment for civilians (not just geeks).
• Exploration is a common theme for escape apps (reading, games, etc).
• Work apps have a lot of untapped potential for exploration; quantified life apps are video games for narcissists.
• Don’t just optimize for the fastest interaction; give them a chance to slow down and explore.

How do we use these?

usage of device (mobile, tablet, desktop) vs hour-of-day.

• iPad use explodes after 6pm or so; it’s the return of the evening newspaper.
• Phone is mobile, tablet is portable.
• iPhone: very active browsers, more willing to buy, skew older, wealthier, more educated, have more sex than other mobile users.
• NB: eBay == 25% of US mobile commerce
• Ads are a good proxy for how companies think of themselves and their customers
• Apple ads for Facetime: Louis Armstrong, parent seeing child, grandparents seeing graduate. Sentimental.
• When people get these devices for the first time, they’re surprised at how emotionally attached they are
• Verizon droid ad: sci-fi alien cyborg. It’s about the technology.
• Android skews techy, users customize their phones more (wallpaper, ringtones), skews more to straight communication. Apps are tools, not media. Skews younger, less affluent.
• Windows mobile: formerly MS + Symbian were 80% of market. Slaughtered by iPhone.
• Metro interface is helping MSFT come back. Very interesting UI. Aiming for a specific user (young, mobile couple, very plugged into social media). Incorporates personalization.
• No clear winner right now.
• 46% of US adults have smartphones. There’re still a lot of people on feature phones.
• 75% of US adults use text message. Teens do about 8 texts / waking hour(!).

§2: Finger-Friendly Design

What do you wish your phone could do?

Brainstorm a quick list of apps to work on.

• Collate tour recommendations into an offline touring app
• Allow me to make calendar appointments / decisions and communicate them via email in a non-shitty way
• Turn objects on the table into a drum machine
• capture 3D panoramas
• capture panoramic workspaces, eg capture my whiteboards and foamcores in virtual space and let me view windows into them

Group suggestions

• Family intercom app so I don’t have to shout to my kids acorss the house
• Find the nearest open burger king; the Junk App aka Junkfinder
• dictophone that translates into mini notes for music
• universal remote for home
• on-the go IDE
• customize your phone
• home automation app
• integrated augmented reality app
• organize work by client or project on the go
• touring recommendations
• calendar & comms on a single screen
• aug-reality whiteboard

Winner: integrated home automation (coffee, lights)

Consider the physical affordances of the device

• Huge physical load, but also huge cognitive load
• clarity trumps density
• handheld => industrial design. how do your pixels feel? In one hand?
  • one hand, tapping with thumb
  • two-handed, tapping with thumbs
  • hold with one hand, tap with the other

Thumbs are awesome

• one-handed, tapping w/ thumb is the most common

• Top-vs-bottom is the main axis of emphasis; don’t worry about left vs right.
• In iOS, edit buttons tend to go top-right; available, but not risking accidental taps

Occlusion

• Traditional physical design tends towards control at bottom, content at the top.
• How to keep fingers from occluding content?

Placing Controls

• It’s a bad idea to stack controls on touch devices, especially on the bottom of the screen. Lots of opportunity for mis-taps.
• Primary system controls are good at the bottom.
• Tabbing works a little better at the top for Android, bottom for iOS.
• Position:fixed is really poorly implemented on mobile browsers, especially for Android. It’s hard to get position:fixed to work right.
• Apps like LinkedIn overwrite native scrolling in javascript to do things like pinning controls to the bottom.
• Ad Age uses a “MENU” button on the top right, which is an anchor link to the full-screen nav located at the bottom. HTML 1.0. Quick, clean, DRY, universally implemented.

Placing Navigation

• iPhone: screen bottom
• Android: screen top (don’t compete w/ primary hardware buttons)
• Native web: page bottom

Tablets

• Avoid putting controls on top-middle of screen.
• Put controls in the top-corners.
• UNLESS you need to preview the effects in the main window above, in which case controls need to be on the bottom.

Targets

• Apple suggests 44pt is the minimum target size for tap targets.

INTERLUDE: Pixels vs points

• Now that screen density varies widely, measure in points: 1/96th of an inch.
  

• Android: “Density-independent pixel (dp)”

• iOS: Point (not to be confused w/ typography points)
• CSS: “Pixel”. D’oh!

iPhone

• Originally 320×480.
• Retina doubled it to 640×960. How to deal w/ legacy screens?
• Introduce points: Retina: 2px == 1pt.
• Other displays: 1px == 1pt.
• iOS knows that image@2x.png (100×100) is the retina version of image.png (50×50).
• Design in vector, beware half-pixel divisions.

Back to Pixels vs Points

• On the web, its a little uglier: <img width='50' height ='50' src='image@2x.png'>. Now we’re shoving hi-res images down the pipe even for screens that can’t handle it.
• Responsive image serving is a hard problem w/in the context of HTML.
• grigsby responsive images
• argument for changing HTML
• CSS
  .className { background-image: url(image.png); /*50 px square */ }
@media only screen and (-webkit-min-device-pixel-ratio: 2)
.className { background-image: url(image@2x.png); /*100 px square */ }
.className { background-size: 50%; /*50 px square */ }

Targets!

• Mobile touch is not only an interface for the hand, but of the hand.
• 44pts (~7mm) is a useful touch target (size of the fingertip)
• 44px is close enough on the web.
• e.g. iPhone keyboard is 44pt high.
• You can squeeze the other dimension as low as 29pt and it’ll still work, so 44×29 or 29×44 are ok.
• iOS uses 44pt heights all over the place (key size, row height, top and bottom nav); it becomes a regular element of the graphic system, almost like a grid. Home icons are 88pts.
• Android standardizes on 48dp (~10mm), because there’s enough variability in the hardware that they need a little margin for error.
• The closer the buttons are together, the larger they have to be.
• Hardware detection area accounts for occlusion (the target is a little below the visual), so smaller targets where you’re really concentrating and trying to be precise are actually harder to hit!
• Touch targets tend to be larger than the visual area implies.
• If you do have to take tap-risks and jam things together at the bottom of the screen, do the extra work and rebuild the bottom nav so the touch area isn’t that huge.
• It’s ok / desirable to make your tap targets larger than they appear.
• Don’t just make it easy to read; make it easy to touch. Clarity trumps density.
• Don’t just design in Photoshop; put it on the app and test.
• Glance test: put it on the phone, hold at arms length, and see if it makes sense.
• Bite-size content (e.g. a weather app) should eschew scrolling when possible. Single-screen makes the app feel more solid, almost like a physical object.

Review

• You’re designing a physical device.
• Where do fingers and thumbs sit? (hot zones).
• Varied rules for phones (iOS: controls at bottom. Android: controls at top).
• Tablet: push to edges and corners.
• Big fat touch targets: at least 44pt.
• Progressive disclosure: clarity trumps density.

Building: Layout

Design the main screen

• Featured content
• Primary Tasks
• Secondary Tasks
• Navigation to other views

Remember

• Make use of the sensors
• Create room for exploration
• Capture lost time

Design w/ team!

§3: Navigation

• Remember Choose Your Own Adventure books? Tangled navigation paths.
• Paths should not cross.
• Paths should be predictable and unique.
• It may seem that multiple paths give more convenience, but they’re harder to model mentally.

3 models:

Flat Pages:

• Good for casual browsing, focused content, or discovery.
• Good for variable screens, custom content.
• Easy to swipe between pages.
• Very little interface chrome; good for saving space, but not a lot of inference.
• It’s flexible: typically let ppl change order, add cards.
• Downside: can’t jump to a specific screen.
• Limited to 20 (practically, ~10) cards; past that, there’s no more room for the navigation!
• Works best for homogenous content; when the cards are different, it’s tough to remember which screen is which.
• Works best for no-scroll screens. It feels like a card, like something physical. We’re not that good at scrolling in two directions.

Tab Bar

• Very familiar; this is where people start to design by default.
• Easily allows for heterogeneous content.
• Constant advertisement / reminder for what the app can do.
• iPhone is limited to 5 tabs; add more and you’ll automatically get the “More” tab.
• DO NOT use the ‘More’ as a junk drawer.
• Have the discipline to leave things at 5 tabs on iOS; if you need more, go to Tree Structure.
• If you’re on Android, drop to 4 tabs.
• Android Ice Cream Sandwich introduces the Action Bar: show one tab, with 1 or more tools (depending on screen size and orientation).
• Order: righties will have the leftmost tab in prime tab position, vice versa for lefties. New convention is to have the prime action being the center. How to draw attention? Make it a little bigger (a la old instagram or new foursquare).
• Path: interesting vertical tab structure with invoked tabs, but a little weird and tough to discover.

Toolbar vs Tab bar

• Toolbar: usually light background. Act locally (on the content on the individual screen).
• Tab bar: usually dark background. Think globally. (change to show whatever tools you need to affect that content.)
• Don’t show both at once.

Tab Bar Pro’s:

• One tap access to all main features.
• Clearly labeled menu advertises features.
• It’s always there.

Tab Bar Cons:

• Limited to four (five?) buttons.
• Committing a lot of screen space.

Tree Structures

• Scales to a ton of content.
• Familiar mental model.
• Direct interaction w/ content: the word or picture you want to use; it removes abstractions.
• Nested folders, a lot like column view in Finder.
• Allows longer and more customizable menu options.
• Often a list.
• But sometimes you’ll see springboards (facebook) or galleries (photo albums).
• Not much room for a way out or ‘back to home’. Leads to a lot of ‘back back back’ garbage taps. It’s not easy to switch branches.
• Work-around: combine w/ tab bar.
• It would be nice to have a gesture to go back. “Swipe across the top” is becoming the norm.
• As designers, we need to protect users from actions that will do them harm. Gesture Jiujitsu can help, e.g. using swipes (easy to do, hard to do accidentally) for undo or Return To Home.
• One of the great things about touch is that it removes mediation; you deal directly w/ what you want.
• Cons:
  • Main categories available only from top.
  • Inefficient to switch branches.
  • No standard for returning to top level.

Popovers

• iPad is a monster in the tablet space (although Kindle Fire is coming on strong in the US).
• It’s too big a screen to be switching pages all the time. Often the phone’s “card-flipping” model doesn’t work as well.
• Long-hold is the right-click of gestural interfaces.
• Pop-overs are ok for quick interactions.
• Use popovers to act on content.
• Use popovers for quick peaks.
• Avoid popovers for exploration or navigation.

None of the above: new interfaces

• Design the personality of your app at the outset.
• A personality will emerge no matter what; if you don’t design it, you’ll be at its mercy.
• Simple things like backgrounds can change the personality greatly, even while sticking to the same design patterns.
• Emotion is a design element.
• Q: do you like skeumorphism? At worst, it can be kitschy, but at best it can show you how to use the app. What does your metaphor propose? and what does it promise? If it looks like a book, I should be able to turn the page (I’m looking at you, iPad contacts). Be true to your metaphor when you go skeuomorphic.
• Skeumorphism often takes a strong point of view, which can be good or bad.

Metaphorically speaking

The Dark Art of Aping Real Objects

• Some clones are the same size: Guitar tuner, apple remote. Sounds and animation can enhance that illusion. You’re absorbing all the industrial design thought that went into the original, though you may lose some ergonomic affordances.

• Minitures (Chess, GarageBand’s piano) are a bit different. The interface loses its ergonomics.

• Sometimes it’s just eye-candy. (E.g. voice capture app w/ its microphone).

• Lots of shelves these days. Its just a dressed-up tree structure, but we love collections. It’s fine for things that belong on a shelf (e.g. books), but you’ll lose emotional resonance when the objects can’t really be on shelves and the metaphors break.

• When contemplating metaphors:

  • Is this a problem that can be solved with built-in, native tools?
  • Are you being too clever? Is the metaphor complicating the mental model?
  • Is your metaphor appropriate to the device? Phone OS’s are card-based; bringing windows in gets weird.
  • Do you have more interface than you need?
  • Don’t be different to be different, be different to be better. Different means I have to learn something new.
  • Creative interfaces can be joyful. See: BeBot (robot synth app).
  • Ask: am I going too far? Am I going far enough?

Gimmicky presentation

• “The sin of pridefully obvious presentation”: Ed Tufte.
• The NYT app quacks a lot like a newspaper. Why so boring?
• Apple asked NYT to build a demo for the iPad, just before the iPad was announced. Three young designers / developers were brought in: two weeks to do it, no contact with home base, no cell phones. “You’ll be demo’ing to Steve, make us proud.” Eep!
• After 2 days, they built a Deck-based version. Realized it was wrong; went back to what became “NYT Editors Choice”. “Strong if conservative first effort”.
• Sometimes you can impress most by doing it quietly.
• NYT App: “Yawn. It looks like the NYT”. Flipboard: “HOLY CRAP! It looks like the NYT!!!”
• Old conventions aren’t necessarily old-fashioned.
• Feature the content, not the interface.

Gestures

Multitouch with Two Hands

• Uzu app for iPad: multitouch manipulation of particle generators.
• The utility of keyboard shortcuts comes from being able to do them w/o looking. Gestures provide a similar opportunity.

• Gestures that begin at the edge should be OS-level gestures: android, WebOS, Meego all did this. Apple used to, but recently has been breaking edge gestures by taking them over.

• Buttons require cognitive and physical effort.

• Gestures ~= keyboard shortcuts.
• Use entires screen as a controls.
• Standards are emerging: tap, swipe, pinch/spread, long tap.
• Model content as physical objects.
• Explore multitouch gestures.
• Follow the toddlers; they’re better at this than we are. They haven’t been spoiled by 20 years of desktop interactions.
• Make a 3 yr old your beta tester. She won’t understand the content of the app, but she can use the interface and navigate.
• “NUI”: Natural User Interface

Haptics

• Shake is a powerful gesture, but can be gimmicky. It takes the focus off the app, and onto the device.
• Younger people are more inclined to rotate the phone; older folks stay with portrait.
• Landscape tends to be more engaging: both hands are occupied, and the aspect ration is closer to our biological field of view.

Conclusion

• The more backward-compatible (accessible) your app is, the more forward-compatible (future-proof) it’ll be.
• Mobile’s a great wedge, because it’s got everyone in a panic right now. We’ve been building websites the wrong way for 15 years.
• We’ve got the most exciting job in the world!

Tweets

• When designing for mobile, don’t confuse context with intent. – Josh Clark
• clarity trumps density

 

About the Author

Biography