1. Jim Warren (with lots of inspiration from http://www.ibm.com/developerworks/library/wa- interface/wa-interface-pdf.pdf) 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 2

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! 1-3

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) 1-4

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 1-5

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 1-6

7. 1-7 http://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 1-8

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

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. 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 1-10

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 1-11

12. Changing the amount on screen 1-12 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 1-13

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 1-14

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 1-15 @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;}}.... 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. see http://dojotoolkit.org/reference-guide/1.9/dijit/themes.html (The DoJo toolkit is an open-source modular Javascript library) http://dojotoolkit.org/reference-guide/1.9/dijit/themes.html 1-16

17. Recycle 1-17 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’) http://www.usatoday.com/story/tech/2014/05/02/apple-samsung- trial-decision/8537339/ Large collection of successes at http://pttrns.com/http://pttrns.com/

18. the human 1 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

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

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 1-20

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 1-21

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) 1-22 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 1-23

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 24