HUMAN COMPUTER INTERACTION Small screens

1. HUMAN COMPUTER INTERACTIONSmall screens CMPSMM23 Autumn 2009 Dan Smith

2. Lecture 8: Small screen design • Small Screen design lecture goals to: • Be aware of the different contexts in which small screens are used • Be familiar the problems and solutions when attempting to display large amounts of information in a small space • Know about small screen design guidelines • Review recent developments in the field

3. Designing for small screens • what’s different • it’s not just about screen size • we have a lot to learn • a lot of what we know is wrong or different • why there’s hope • trust the process

4. Designing for small screens • A small sample of the diversity of mobile phone displays currently on the market • “If you thought web browser diversity was fun, get ready for euphoria” (Marc Rettig)

5. Mobiles for all? • PCs in use: over 1B • 2006 • mobile phones: 2 billion • PCs market is fairly saturated at 900 million • mobile phones market already twice the size and growing at high speed

6. …the global phenomenon • rural computing, in developing countries • phone users, never had access to PC • phone = first access to the digital world

7. Increased emphases • context of use • people moving around into all sorts of surprising places • attention • you often don’t have people’s full attention; they’re doing something else while using your device • activity • people use small-screen devices for activities other than desktops; • don’t assume you understand these activities already

8. Small Devices • More opportunities for context or purpose-specific devices, than for general-purpose solutions that try to work for everyone in any situation? • Diverse contexts of use

9. Small Devices • context of use • Static, temporarily static or mobile? • Quiet environment? • Light environment? • Ease of access to mobile device?

10. Small Devices • Your device doesn’t always have their full attention… X • … in fact, attention may be the thing in shortest supply

11. Small Devices • attention • Is it easy to operate with half your concentration (or less)?

12. Small Devices • Activities • What are they doing when they use it? • Use is often social... • more multi-tasking

13. Small Devices • May be linked to other technologies • Scenario: commuting between home and work • Mobile user interface supports • recall: bookmarked site • execute: navigation system • the real work I do on my desktop • PC  mobile phone synchronised

14. Small Devices • There is hope – trust the process attempt to fit understand research people, context, and activities mock it up, prototype it, get it out in the world find out what you did wrong translate the data into design frameworks

15. Modified design process • Don’t skimp on user research • Learn new prototyping techniques Students testing a new audio device. The intelligence is in the minds of the 2 designers following the user around. The audio content is in the laptop. The interface is a fimo-clay lo-fi prototype.

16. Evaluation • Test early and often • Test more times than web sites or desktop apps, • we know less about this new territory • there is more variation in context and personal habit. • Not just lab testing – field testing is critical Mobile phone with camera for testing in the lab. But need to go OUT with the phone too

17. Do your task analysis • know the frequency of commands • know how commands align with tasks and task frequency • most frequent = most handy • weigh critical nature of commands into this consideration • annotate the tasks with information needed, success measures, barriers to success,…

19. environment display Small Devices input

20. Small Devices - Input • input devices stylus? phone keypad? jog dial wheel? speech? external keyboard? gesture? • context of use people often on the move • speed and ease of use The actions required to input data should be minimal, and intuitive.

21. Small Devices - Input • which PDA input do users prefer? http://psychology.wichita.edu/surl/usabilitynews/62/HHC.htm

22. Small Devices - Input • the most obvious input device: "Never fat finger your IPhone again."

23. Small Devices – Sensory Input • SOAP: mouse-like pointing device that works in mid-air - monitors the motion between the core of the mouse and its hull. Communication is wireless via Bluetooth etc – NO MAT Nintendo Wii – accelerometers detect movement http://www.patrickbaudisch.com/projects/soap/index.html

24. Small Devices – Sensory Input …or maybe don’t touch it at all

25. Small Screen Design Constraints • Smaller Screen Size (Pixels, Resolution, ) • Less Colour • greyscale • 4,096 (12-bit) • 65,536 (16-bit) colour • Different input devices • smaller or no keyboard, no mouse • Limited capabilities • Audio • Graphical • Battery • Storage • Varying Light conditions (Backlight viewing) • Potentially unreliable networking capabilities

26. User Constraints • One handed use • Unfocused attention • Unfamiliar territory • new navigation techniques, • different from familiar desktop metaphor

27. Basic SSB approaches • SSB=Small Screen Browser • ALWAYS use CSS • CSS hasmedia=“handheld”attribute<link rel="stylesheet" type="text/css" media="handheld" href="file_name.css">no effect on people using large-screen browsers; only handheld browsers that support CSS will be sent to the alternative stylesheet • Goodbye tables and frames, hello <div> • never use another <font> tag again! • max-width and max-height properties are very useful • Design a whole separate version? • Apply what you know about SSBs to large page designs?

28. Basic SSB Design guidelines • Aim for pages at around 10K each • common throughput for a wireless device such as a mobile phone (not bluetooth) is closer to 19.6kbps. Best-case-scenario about 56kbps • throughput limits may range from around 32K up to 100K or beyond • every byte counts (tabs, CRs, LFs … all white space) • Code in (X)HTML, not WML, and make your HTML XHTML-compatible. • Proxy servers may filter stuff you send • images may be broken down, or not sent at all • SSBs aren’t cross platform • 4 main OSs: Palm OS, Symbian, Windows CE, RIM • Opera is the only SSB to offer SSB compatibility testing

29. Basic SSB Design guidelines • Nearly all those OSs on newer SSBs now support html, while remaining backwardly compatible with WML. XHTML favoured by Open Mobile Alliance. • Support for javascript is scanty and random • PDAs have a good array of font sizes but others don’t • Use 3 basic font sizes • Use <h> tags to give good font size control • avoid using pixels for anything larger than 5px - use ems or % instead • There is only one basic font face • Never underline anything that isn’t a link

30. Basic SSB Design guidelines • Use 120 pixels as maximum target width • Range from (w x h) 320x480 to 122x96 • For details see http://hotwired.lycos.com/webmonkey/04/12/index4a_page8.html?tw=design • Don’t use large pictures • some images are removed and others are scaled. Images are shown one at a time, so image slicing or stacking will fail. • <alt> tags are essential for when images are switched off • Use colour with care • not all SSBs support. Use CSS <strong> tags to cater for both • Check contrast out using grayscale • One- or two-column layout

31. Be aware of de facto standards and habits • it’s everywhere: • the + button, A and B buttons, the Start button • a generation is learning conventions for navigating • text and graphics with just three buttons

32. Use the power • web folks aren’t used to taking full advantage of computing power. In the world of small devices: • processor/£ is going up • memory/£ is going up • but display area: constrained by device size • so… use the power • and be smart about what you show

33. Result … We can do better

34. Research agenda • long term goalhow much and what functionality can/should we offer mobile device users? • short term goalovercome limitations of small screen size

35. Old habits die hard • We have WIMP habits (Windows, Icons, Menus, Pointing Device) but times have moved on … we have a lot to learn Stanford Power Browser (CHI 2000)

36. expand collapse small screensolutions store content off-screenhalo store content in another layermultiblending squeezing it infishnet make the unreadable readablesummary thumbnails manually collapse irrelevant materialcollapse-to-zoom

37. + halo • Problem

38. halo • entry and exit points • point of viewarrow-based techniques • partially out of the frame halo • rings are familiar, graceful degradation

39. halo - trials • arc/arrow fading off • scale 110-300m/cm • map as backdrop • readability ok • same selectable size • hypothesis: halo faster legend halo ring distance from display border

40. halo - tasks

41. halo • participants underestimated distances by 26% • participants saw ovals • halo 16%-33% faster than arrows • Subjective preference:

42. solution multiblending:glass palette distinguished from background photo& background more recognizable Multiblending • problemwith traditional alpha blending: is thisbush in palette or background?

43. Multiblending

44. Multiblending • preserve the most relevant features allow different weight for each features class • avoid visual ambiguity

45. Multiblending desaturate emboss…

46. opaque alphablending multiblending • Complete example • recent graphics cards (with pixel shader 2.0) does computation on the fly • 145 frames/sec

47. Multiblending • glass palettes is just one possible example • other application scenarios may favour different palette styles • general procedure: for each feature class • decide which layer benefits more from it • eliminate feature from other layeror map it to a different feature class • eg, if the background makes foreground unreadable, blur it.

48. Multiblending • palette works better on lighter backgrounds

49. Fisheyes • document lens [Robertson, uist’93] • unifying presentation space [Carpendale, uist’01] • focus+context sketching on a Pocket PC [Lank, chi’04]

50. Peephole • Ka-Ping Yee [CHI’03]