Design for mobile

1. Jim Warren (with lots of inspiration from http://www.ibm.com/developerworks/library/wa-interface/wa-interface-pdf.pdf) Design for mobile

2. Learning outcomes • Identify the major challenges in designing web application for use on mobile devices • Consider how mobile scenarios may differ from desktop scenarios • Be aware of technical solutions to allow Web applications to be responsive to user display size • Take inspiration from successful patterns used by others

3. Challenge: Smaller form factor • Kinda obvious, but just to ‘unpack’ the challenge… • Mobile means an application can be accessed just about anywhere • But will it be usable? Will the user have a positive experience? • A single application has to work across a wide range of screen real estate sizes • Yet not appear cramped at the low end or stretched at the high end • Also exasperated by potential vertical orientation and possibility of orientation changing on the fly!

4. Challenge: touch screen instead of mouse • Mouse and touch ‘feel’ different • The mouse is a Fitts’ Law device: you drag the cursor through the screen space between its old position and the new ‘target’ • A touchscreen (stylus or fingers) promotes jumping to a new location • The stack of events evoked are different (and conflated) • Typically browsers map a touch to a sequence of traditional events (allows old Web sites to work with touch devices) • E.g. ‘touch’ = hover, click, mousedown and mouseup in some order • But there are also touch-specific events (touchstart, touchmove, touchend) • Need to be careful not to run multiple event handlers for the same user action • Hover (so useful on desktops) is particularly tricky • And now touch PCs are becoming popular (might have mouse and touch)

5. Challenge: system diversity • iOS (Apple) • Uses gestures and widgets to move the user through views • Home button on the bezel used to close applications and navigate out of folders. • Android • Uses gestures, widgets and hardware buttons (home, back, menu, search) • So you might hide the unnecessary nav controls (that you needed for iOS) when on Android • Input methods can vary by device model and by service providers • Problem is acute for Android devices because virtual keyboard layouts and the left to right order of bezel buttons varies by service provider and device manufacturer

6. Multi-device interaction • Need to rethink the scenarios for your application with mobile in mind • In many cases the user may sometimes use a desktop interface and sometimes a mobile one • On the whole, they will probably tend to use your application differently in each setting

7. http://www.ibm.com/developerworks/library/wa-interface/wa-interface-pdf.pdfhttp://www.ibm.com/developerworks/library/wa-interface/wa-interface-pdf.pdf

8. Use a toolkit • A toolkit saves effort (e.g. pre-formulated solutions for lots of common interaction challenges), but also (if it’s the right one) will provide features such as responsive layout • E.g. Bootstrap • Popular front-end framework for creating web sites and applications • Well-suited to creating one site/application with appropriate appearance on both desktop and mobile • Makes heavy use of CSS, and also handy components based on Javascript (including sometimes jQuery) and CSS • ‘Grid system’ (based on CSS) allows decision of column-width to be made dynamically based on device screen size • E.g. DIVs converting from a horizontal to a vertical flow automatically

9. Bootstrap ‘Grid system’ responsive layout Content SB1 Content SB1 SB2 SB2 Small display: go for vertical flow instead Large display: Side bar (SB) content on sides

10. Bootstrap size model for grids • Recognizes four sizes • Conceptually 12 columns • Allocate number of columns to a DIV depending on device size • E.g. <div class=“col-sm-3”> says to give this DIV 3 of 12 columns on devices small, medium or large (768px screen width and up) • At size Extra Small everything defaults to 12 columns • i.e. it takes the whole screen width and so other DIVs float below it and the flow is vertical

11. More on ‘design responsively’ • Simply shuffling the DIVs around while providing uniform content is one step • This will implicitly change the visual flow, and often mean the user does vertical scrolling • A next step is to change how much you put to a single screen • A more radical step is to change more fundamentally how features work, or even what features you offer • Go back to the personas and scenarios • Which functions are likely to be frequent in a mobile context • Make those work well

12. Changing the amount on screen iPad iPhone

13. Changing workflow • With images, they can scale automatically, but may be more useful if… • Show thumbnail by default on smaller screens and require touch to open larger version • Or show version cropped to key element • Another example of workflow change… • Facebook (the Web version, not the app) changes from showing comment threads by default to just showing comment count and requiring a touch to open a comment thread • It then takes over the whole screen, and offers a ‘done’ button to return to the user’s main feed

14. Media queries • Using the CSS media ‘rule’ you can adapt presentation for handheld devices, printing and other formats • Valuable for accessibility broadly, not just mobile

15. Media rule example • The style in the example below tells the browser to display a 14 pixels Verdana font on the screen. But if the page is printed, it will be in a 20 pixels font and red. Notice that the font-weight is set to bold, both on screen and on paper <head><style>@media screen  {  p.test {font-family:verdana,sans-serif;font-size:14px;}}@media print  {  p.test {font-size:20px;color:red;}}@media screen,print  {  p.test {font-weight:bold;}}</style></head> <body>....</body> http://www.w3schools.com/css/css_mediatypes.asp

16. Look native • There are device/brand-specific conventions and expectations • Especially for Apple • E.g. standard look and action of lists, “+” to add an element, a rounded blue rectanglar “Done” button… • Toolkits often refer to their mechanism for matching native looks as ‘themes’ • E.g. seehttp://dojotoolkit.org/reference-guide/1.9/dijit/themes.html(The DoJo toolkit is an open-source modular Javascript library)

17. Recycle • Successful patterns (ones on popular sites) tend to represent: • Significant design effort by others • Darwinian selection (if it was bad, it got changed, or got less popular) • Further, there’s the ‘external consistency’ advantage of looking and acting similar to what people are used to • OK, this is not the path to innovation, but it will lead to efficiency for users who are familiar with the sites you emulate • Note it’s generally acceptable to take ideas (not code), although too much of this could land your company in trouble • http://www.usatoday.com/story/tech/2014/05/02/apple-samsung-trial-decision/8537339/ (Apple got $131M recently, but not the $2B they sought for infringements by Samsung, including features such as ‘slide to unlock’) • Large collection of successes at http://pttrns.com/

18. Log In patterns (from pttrns.com) • Use of low saturation text to indicate desired input is an interesting convention – saves space that would otherwise be given to caption/label text display the human 1

19. ‘Notification’ patterns • Use of cartoon style ‘callouts’ • Notification of functions reached by ‘swipe’ gesture

20. Keyboard ‘disruptive’ in mobile • Size, position and lack of tactile feedback make typing more difficult on mobile than desktop • Also the keyboard covers part of the screen • It’s already a good design heuristic to allow users to select rather than to specify, and to avoid requiring input if you can • Just more so with mobile • Also, more reason to pursue the good practice of auto-completion / progressive filtering of option • When you do require input, use the HTML5 types (text, numeric, telephone number (‘tel’), email, URL • Client browser can optimize keyboard so required special characters are easier to reach

21. Stay close to home • The competition for space between navigation and content is fiercer on mobile • We may not be able to show the menu and the content on one screen, or even to show all of the menu • So it’s better to keep the structure of the Web site as simple as possible • Two or max three levels • When navigation exceeds two levels • Provide easy way to return to the application Home • On iOS, this will mean virtual home and back buttons • For Android devices, don’t display these because physical home and back buttons are provided

22. Be graphic • Well-designed graphics will convey key points more readily than textual or tabular data • Graphics can also communicate affordances (e.g. booklet or dog-eared page to indicate swipe for more) Dojo graphical and visualisation widgets

23. Avoid pitfalls • Doing nothing • Your desktop-styled site will probably be annoying, and possibly unusable, for your mobile users • Ignoring performance • Avoid large downloads • Relying on help • All UIs should be intuitive, but even stronger case with mobile as user is likely to be intermittent (and thus training will be less of a good investment) • Misapplying creativity • Novel or idiosyncratic interaction will make it more likely user needs help to figure out – users will understand applications that look and behave like what they’re used to • Ignoring browser interactions • Best if you site provides all the navigation needed without users having to go to the browser’s layer of controls

24. Summary • Mobile interaction means users can reach your content almost anywhere • But it isn’t the same as interacting through a desktop PC • Consider the shift in scenarios • Consider the differences in display real estate and controls