sm3121 design for small devices n.
Skip this Video
Loading SlideShow in 5 Seconds..
SM3121 Design for Small Devices PowerPoint Presentation
Download Presentation
SM3121 Design for Small Devices

SM3121 Design for Small Devices

171 Views Download Presentation
Download Presentation

SM3121 Design for Small Devices

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. SM3121Design for Small Devices Mark Green School of Creative Media

  2. Introduction • Small devices have three main limitations that effect design: • Small screen size – maximum is 320x240, on phones it could be 128x128 or less • Limited input devices – no keyboard, text entry isn’t easy, no mouse • Limited storage – no mass storage devices, some device have flash memory, but nothing like a disk

  3. Screen Size • For PDAs we can assume 320x240 • For phones we will use 128x128, some are smaller and some are larger • Small screens are very different from large screens (at least 640x480) • It is not just a smaller version of the same thing, design and interaction are quite different

  4. Screen Size • On a large screen we can have: • Multiple windows • Multiple applications • Lots of icons and buttons • Complicated menus • For many applications we can see the entire user interface, all the menus, all the commands that we can select

  5. Screen Size • With large screens we can rely on visual recognition, the user will see what he or she needs • We can have multiple applications visible, easy for the user to switch between applications, just click in the window • Easy to combine information from multiple sources/applications

  6. Screen Size • We can’t do this with small displays • Can only have one window and application at a time • Not easy to switch between applications, need several button presses • Can’t see information from multiple sources at the same time • May not be able to see entire application

  7. Screen Size • Not much room for user interface • Often can’t show both user interface and data at the same time • Can’t show a complete menu on the screen • With large screen can have menus with 50 to 100 items, on a phone may only be able to display 3 or 4 items

  8. Screen Size • User interface implications: • User won’t be able to see entire interface, won’t know what’s possible at a glance • May need to perform many actions to get to the item that they want • Using these systems on the run, don’t have time to explore all the menus, try to find where a feature is hidden

  9. Input Devices • Most devices just have a few buttons • A phone will have 15-24 buttons, but typically no way to point at screen • PDAs have fewer buttons, but screen is touch sensitive, can use stylus like a mouse • Text entry is quite difficult, combination of key press, or virtual keyboard

  10. Input Devices • Phones use buttons to navigate screen and user interface • Want to reduce button presses to a minimum • Phone designers want to have few keys, phones are smaller • Few keys makes it hard to design the user interface

  11. Input Devices • Can’t have a key for each function • Each key must have multiple functions, used for different things • How does the user keep track of the functions, know what the key will do • Some keys used for general operations, scrolling up and down a menu, making selections

  12. Input Devices • Soft keys – key changes function depending upon what you are doing • Very common on phones • Need to tell user what the key will do • Label of soft key shown on display, changes when function changes • Takes up display space, users must associate label with key

  13. Storage • Can’t store a lot of stuff on mobile devices • Phones have around 1 MByte, some phones now have a lot more • PDAs can have 32 or 64 Mbytes • Can’t have a lot of applications, and none of them can be large • Can’t have a complete office suite, not near enough storage space

  14. Storage • Also can’t have a modern PC game, some require over 1GByte • Slow data communications complicates the problem, phone can’t quickly get large amounts of data • Need to think carefully about what an application needs, what the user really needs to have with them

  15. Storage • Carefully calculate image resolutions, don’t want to store more data than can be displayed • Are all the images necessary? Can they be compressed? • Only include the functions that people really need • Keep it simple

  16. Social Issues • Mobile devices have a different social role than PCs • A PC stays in one spot, it may be yours but it doesn’t move with you • Its used for a wide range of tasks • Mobile devices are more personal, you carry them with you, they are used for communications

  17. Social Issues • Mobile versus stationary is important • A PC is associated with place or location, we see its role based on its location • An office PC for office work • A home PC for games and entertainment • Mobile devices move with us, they can have many roles, but the emphasis is on communications, social interaction

  18. Social Issues • Mobile devices used in a range of places in different roles • Don’t have control over the environment, who is around you, level of privacy • Mobile devices are personal, people want to make them different, a statement about themselves • People become attached to their mobile devices

  19. Social Issues • Communications technologies change our behavior • Expect fast replies from email, but willing to wait a week or more for a written letter • Email is between written and spoken communications, we expect people to respond quickly, be less formal than written communications

  20. Social Issues • SMS has produced new languages that aren’t used elsewhere • Small screens and text entry difficulties result in many abbreviations and special expressions • Developed around SMS and only use there • How will people react to our application?

  21. Social Issues • Need to study people in their own environment, where they work and play • How do they want to use the technology? • Remember that there are differences between cultures • Applications acceptable in one culture aren’t acceptable in another, need to consider this

  22. Social Issues • Example: in Japan it is considered rude to talk on a mobile phone in public • Instead SMS is used in public areas • Rarely hear someone talk on phone in trains, buses, etc • Here it is considered normal to yell on phones in public areas • In North America that would be view as a sign of aggression and criminal behavior

  23. Basic Design • Design constraints drive our design approach • Need to make good use of limited resources, strip our applications down to the bare essentials • Start with the problem of context • With PCs we can usually see all the information that we need

  24. Basic Design • On PCs cut and paste is common, easy to move things from one application to another • Can’t do this on a mobile device, can only run one application at a time • Can only see one small screen full of information at one time • Most have everything we need visible or easy to remember

  25. Basic Design • Requires a rethink of applications • On a PC can use a set of applications, each responsible for one set of data, to perform a task • On a mobile device, all of this information must be in one place, or very easy to get to, must think about what the user is doing and the information required

  26. Basic Design • The key difference between applications: • PC: designed around data • Mobile: designed around the user’s task • Example: designing a web site • For a PC, we think about the information we want to tell the user, design the pages around the information • An issue of information organization

  27. Basic Design • On a PC users expect to find a well organized web site, based on the information, exploration is okay could even be fun • On a mobile device exploration is difficult, users concentrate on the task at hand • What to get at all of the relevant information quickly, preferably on one screen

  28. Basic Design • Example: web site for an Arts Festival • On PC will want to have lots of images, draw people into the site, encourage them to attend events • Event listing could be one page with all the information on all of the events, presented in a table that the user can scroll through • Able to see all the events in summary form

  29. Basic Design • This won’t work on a mobile device, barely enough room for one event’s information • User won’t be interested in browsing, will probably want the information on a particular event • They are in the MTR heading for the event, they want to know when and where it is, directions for getting there

  30. Basic Design • User wants to enter the name of the event and get location, time, directions as a response • This can all be placed on one screen • Need to have a quick way to navigate to this information on our mobile web site • Summary: think about what the user wants to do, this is harder than just designing a basic site

  31. Design Framework • A few standard approaches to design, some systems force you to follow a strict framework • Applications organized as a set of screens • One screen is visible at a time • Limited number of options on each screen, a few buttons to press, a menu, text entry • Small number of interactions

  32. Design Framework • Think about device screen size, many can scroll horizontally and vertically, but this is hard to use • Avoid horizontal scrolling, users quickly get lost, vertical is okay if designed well, user knows to scroll • The idea is that the user should be able to find everything they currently need on a single screen and it should all be visible

  33. Design Framework • The user moves from screen to screen based on their input • For a web based application can download several screens at a time, but will eventually need to fetch more screens from the server • For non-web based applications, all the screen will be generated locally, no need to wait for download

  34. Design Process • Our design process should be task driven • Determine what the user wants to do, the things that he or she wants to accomplish • Why do they want to use our service or application? • What is the purpose of the interaction? • What information are they after?

  35. Design Process • First determine the set of tasks: • Talk to users, find out what they want to do • Think about what you would like to do • Ask the customer • Guess • For each task determine its priority or importance and the information required to complete it

  36. Design Process • Priority is used to determine its position on the menu • May only be able to display 4 menu items at a time • The first 4 are easy to get at, after that the user must scroll, this will require a button press for each item • Want to reduce button presses, so most important item must be first

  37. Design Process • The information required for the task determines the set of screens required • Want a small number of screens and few button presses • Also want to reduce the number of exchanges with a server, since this will take time • Gather as much information as possible on each screen

  38. Design Process • Divide the work between the mobile device and the server • Information retrieval will have to go on the server, be as specific as possible • Other things are harder to design, things to keep in mind: • Processing power of the device • Cost and time for communications

  39. Design Process • Good idea to validate user input on the device, don’t rely on server for this • Communications is expensive and slow, want to get the most out of each exchange • If there are errors in the input, you get nothing out of the exchange! • Cannot validate everything, but should do as much as possible

  40. Design Process • Remember that input is hard on a mobile device, particularly text • Try to avoid text input, use selection wherever possible • Common items as selections, then use textbox for less common items • Use defaults whenever possible, use input format to avoid switching modes

  41. Design Process • At the end of the design process we will have a set of screens • Know the information that should appear on each screen and the processing required • Need to decide on implementation approach, will this be a web application or will it require Java?

  42. Design Documentation • How do we describe our design? • What documentation techniques can assist with design? • There are two things to keep track of: • Screen content • Relationship between screens • These can be described separately

  43. Design Documentation • For each screen need to record: • Content of the screen • Interaction • Links • Layout • This could be done in several ways, we could have a written description of each screen, may be only choice if we aren’t sure of its design

  44. Design Documentation • Better approach is to use some graphical representation • Basically draw a picture of the screen • Easy to do if the content is static, may be more difficult with dynamic content (examples: game, video, streaming) • Could use a pencil sketch of each screen, good approach in early design

  45. Design Documentation • Use a word processor or drawing program to produce screen images • More work, but better for final documentation • Can capture more of the details, like fonts, styles, size of elements, etc • Don’t need to be exact, need some way to capture your thoughts

  46. Design Documentation • Relationships between screens: how to we navigate between screens? • For mobile devices this will usually be a hierarchy, something that is easy to remember • Again a graphical representation is probably the best • Easier to see how the screens are related

  47. Design Documentation • Use simple diagram with a box for each screen, put name of screen in box • If there is a link from screen A to screen B, draw a line from the box for A to the box for B • Put the main screen at the top of the page and work down • This will show the structure of the application

  48. Design Documentation

  49. Design Documentation • The example was created in a few minutes using PowerPoint, could use this to quickly outline the structure of the application • Diagrams shows the usability of the application: • Is the tree too deep, requires too many clicks to get things done • Too many branches, hard to design easy to use menus

  50. Design Guidelines • Details of design could depend upon how we implement the application, but there are some general design guidelines • Determine the devices you will support: • Minimum and maximum screen size • Colour • Number of buttons • Type of text entry • May not support all devices