SM3121 Design for Small Devices

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
  isnt 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 cant 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
• Cant 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 cant show both user interface and data at
  the same time
• Cant 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 wont be able to see entire interface, wont
  know whats possible at a glance
• May need to perform many actions to get to the
  item that they want
• Using these systems on the run, dont 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

• Cant 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

• Cant 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
• Cant have a lot of applications, and none of
  them can be large
• Cant have a complete office suite, not near
  enough storage space

14
Storage

• Also cant have a modern PC game, some require
  over 1GByte
• Slow data communications complicates the problem,
  phone cant 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, dont 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
  doesnt 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
• Dont 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 arent 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 arent
  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
• Cant 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 users 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 wont work on a mobile device, barely enough
  room for one events information
• User wont 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,
  dont 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 arent 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
• Dont 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

51
Design Guidelines

• Keep smallest screen in mind when designing
• Want to avoid horizontal scrolling, all elements
  should be narrower than screen width, check
  images for this
• Vertical scrolling is okay, but still need to be
  careful, may require many button presses to get
  to the end of the screen

52
Design Guidelines

• Use compact layouts
• Dont waste space
• Avoid large vertical gaps, confuses some users
• Flow text around images
• Dont use decorations, keep to the essential
  material
• Remember the task at hand, make it easy for the
  user

53
Design Guidelines

• Keep text simple
• Most mobile devices dont have a large number of
  fonts, maybe only 2 or 3, so dont specify
  particular fonts
• Keep variations in style to a minimum, only two
  or three styles per page
• On a small screen too many text styles look bad,
  too hard to read

54
Design Guidelines

• Control use of colour, many phones dont have
  colour displays!
• Colour quality may be poor on low end phones and
  PDAs
• Use simple background colour, and only a few
  foreground colours per screen
• Dont refer to items by colour, wont work on bw
  phones

55
Design Guidelines

• Aim for a consistent look
• The same basic layout or design on each screen,
  few different screen types
• Easier for the user to find information, know how
  to use the application
• Remember, they will be doing something else while
  using your application, dont have 100 of their
  attention

56
Design Elements

• What can I put on a screen?
• Depends on how the application is implemented
• Look at what we can do with web pages, this will
  work on the widest range of mobile devices
• Later look at Java and other implementation
  techniques

57
Design Elements

• To be specific we will look at
• Mobile profile of xHTML, xHTML MP
• WAP cascading style sheets, WCCS
• This will run on most modern mobile phones
• Similar to using HTML, divide a web site into a
  number of pages, each page is a separate file

58
Design Elements

• Browser downloads one file at a time
• May want to put several screens in the same file
  to save download time
• Standard screen format
• Title page title at the top of the screen
• Softkeys one or two keys at the bottom of the
  screen
• Body the rest of the screen

59
Design Elements
60
Design Elements
61
Design Elements

• The title should be fairly short, less than 14
  characters, indication of screen content
• Not all users will read the title, so dont put
  anything crucial there
• Softkeys may not be available, some browsers use
  them for their own commands
• Be careful not to confuse the user here

62
Design Elements

• Can have most of the standard text items
• Think carefully about formatting text
• Long lines will wrap to the next line by default
  on most browsers
• Use breaks
  to control text layout, dont
  try to be much fancier
• Look at the screen shots to see just how little
  space there is for text

63
Design Elements
64
Design Elements

• Notice the difference in formatting between the
  two phones
• This is a simple list, imagine what would happen
  with more complex layouts
• The screen size has a large impact on formatting
• Need to test on several phones to see how things
  will look

65
Design Elements

• There are two ways to get more control over
  format
• Use style sheets or element
• Use tables
• Tables can be used in xHTML MP, either to control
  layout of items or to present tabular data
• You need to be careful with tables, or they will
  make the formatting worse

66
Design Elements

• Be careful of table width, two columns is
  probably the widest
• Avoid column labels, they take up space and are a
  waste if the table content is obvious
• Keep cell content short, long content can cause
  too much vertical scrolling to read the table

67
Design Elements
68
Design Elements
69
Design Elements

• Changing the table style gives it a different
  feel, can easily experiment with this using style
  sheets
• Hyperlinks are used to
• Load another file
• Move within the current file
• Dial a phone number
• Send an email

70
Design Elements

• Linking within the same file is a useful
  technique
• Divide the file into several logical screens,
  could contain related information
• Can then jump from one logical screen to another
• Happens quickly since a new file doesnt need to
  be downloaded

71
Design Elements

• In theory this sounds easy, but in practice it
  takes a lot of planning
• Need to have blank space on the xhtml page
  between the logical screens, dont want to see
  part of next screen while on current screen
• Amount of blank space will vary from phone to
  phone, need to do a lot of experimentation

72
Design Elements

• On Nokia phones links can appear on Option menu,
  look like commands, easy to get to
• Access keys can be associated with links, one of
  the phone keys (numbers 0-9)
• When key pressed the browser will transfer to the
  link, fast access to a screen
• Doesnt work on all phones

73
Design Elements

• Dont underline regular text, users will think
  its a hyperlink
• Users cant mouse over text to see if its a
  link, like on a PC browser, so underlined text
  will confuse
• Dont remove underline style from hyperlinks,
  users wont know that they can select it

74
Design Elements

• Forms can be used to collect information from the
  user
• Works in basically the same way as html forms,
  and could probably be used with the same scripts
• Collects information from the contained elements
  and sends it to the server for processing, gets a
  new page back in return

75
Design Elements

• Most of the standard input elements can be used
  including
• Text
• Checkbox
• Radio buttons
• Text area
• Selection
• Hidden

76
Design Elements

• When designing a form keep the following in mind
• Reduce text entry as much as possible
• Use defaults to reduce the number of user actions
• No unnecessary labels and text, dont want the
  user to scroll too much
• Just collect the necessary data

77
Design Elements
78
Design Elements
79
Design Elements

• You can use hidden elements to store state
  between pages
• Example customer number, so we know what they
  have ordered
• You should keep this to a minimum since it will
  be sent to the phone for each page
• Remember people are paying by the minute or KByte
  for access to your service

80
Design Elements

• With forms need to write scripts for the server
  to process the information
• Usually done with CGI, but there are packages
  that can do some of this for you
• You may need a programmer to help with this
• Also need to work with ISP to ensure they can run
  the scripts

81
Java

• Why would we want to use Java and not xHTML?
• Application is too complex for xHTML
• Dynamic application, lots of screen updates
• Application requires a lot of computations,
  better to do on the device
• An xHTML application would require too much
  network bandwidth, would take too long or cost
  the user too much

82
Java

• Why not use some other language or package?
• Java is already available on most phones, dont
  need to download a plugin, saves user time and
  money
• As developer, we can assume its there, makes our
  job simpler
• Run on most modern phones, PDAs and even on Lego,
  write the code once

83
Java

• Not going to force you to do Java programming,
  but if you are interested you can give it a try
• Need to understand the process of running a Java
  application on a mobile device
• Need to know what can be done in Java, whether
  your application can use it, whether its easy

84
Java

• Will look at the MIDP profile, widely available,
  but not the only one
• A MIDP based Java application will run on the
  widest variety of devices
• Start by looking at the process of loading and
  running a Java application, then look at the
  design elements that Java gives us

85
Java Applications

• How do Java applications get onto a mobile
  device?
• Lets start with phones
• As a developer we produce two files
• Jar this file contains the program and anything
  it needs (images, sounds, etc)
• Jad a text file that describes your application,
  name, version, size, author, etc

86
Java Applications

• When the user requests the application, the phone
  tries to download it
• First it checks the Jad file
• Will the program fit on this device?
• Do we already have this program?
• The Jad file is small, and can save time and
  money if the application is too large, or we
  already have it

87
Java Applications

• Next the Jar file is downloaded and stored on the
  device, as long as we have enough memory it only
  needs to be downloaded once (different from xHTML
  applications)
• For PDAs the process is a bit simpler, usually
  the files are just copied from a PC
• Need to have a small program that starts Java
  with our program

88
Java Applications

• A MIDP application is called a MIDlet, a program
  designed to work with a phone
• Only one application can run at a time, have
  control of the screen, but we want to switch
  between applications
• When applications switch, the old application
  keeps track of its data, can quickly switch back
  and continue

89
Java Applications

• How do MIDlets do this?
• All MIDlets have three standard procedures
• startApp() called when the application should
  start running
• pauseApp() called when we switch to another
  application
• destroyApp() called when the user want to quit
  the application

90
Java Applications

• When our application starts, the phone will call
  startApp()
• When applications switch, pauseApp() is called,
  when the user switches back to this application
  startApp() is called again
• This is an organized way of passing control
  between applications, works around the limitation
  of one application running at a time

91
Design Elements

• Like xHTML, MIDP is screen oriented
• An application can have any number of screens,
  but only one is displayed at a time
• Program switches between screens based on user
  actions
• Screen limited to width of display screen, but
  can scroll vertically

92
Design Elements

• With Java we get more freedom in how we format
  the screen, depending upon what packages we use
• The high level library based on the Screen class
  produces interfaces similar to xHTML
• We have a title, the screen contents and then
  some soft keys for navigation

93
Design Elements
94
Design Elements

• Pressing the next button gets us to the next
  screen
• This screen has a list of commands, that end up
  on a soft key menu
• Two of these commands take us to alerts that
  produce short information screens
• Note this may end up looking different on other
  versions of MIDP

95
Design Elements
96
Design Elements
97
Design Elements

• There is a problem with this design, the user
  must click the menu key to see the options
• A list screen solves this problem, we can give it
  a set of names to construct a menu from
• Unfortunately, this takes up screen space, so
  there are tradeoffs involved

98
Design Elements
99
Design Elements

• Information can be collected from users using
  standard elements
• Text fields
• Text areas
• Check boxes
• Radio boxes
• Dates
• Progress meters

100
Design Elements
101
Design Elements

• This example has a ticker across the top of the
  screen requesting information
• The ticker element is the width of the screen and
  scrolls its contents across the screen
• There are two text fields on this form that
  collect the name and address of the user
• This info is saved in the program

102
Design Elements

• An information alert is then used to verify the
  information and thank the user
• Check boxes and radio buttons look basically the
  same as xHTML and behave in the same way
• The date and progress meters are interesting and
  worth taking a look at

103
Design Elements
104
Design Elements

• On some implements of MIDP the date element is a
  calendar or clock, unfortunately in the emulator
  its a simple entry field
• A gauge element can be used to show progress, or
  even enter a value
• It can be used to show the progress of a download
  or computation

105
Design Elements
106
Design Elements

• The emulator shows a relatively primitive
  progress bar, other implementations may show
  better ones
• The user can click on either end of the bar to
  change the value
• This could be used to enter a numeric value

107
Examples

• To see what can be done its worth taking a look
  at what others have done
• Most mobile service companies provide downloads
  and have previews and short descriptions of the
  applications
• Take a look at some of the local ones, see what
  they currently have on offer, and how much they
  charge for them

108
Examples

• There are some good web sites showing different
  types of games
• Open of the better ones is http//www.handy-games.
  com
• They have a variety of games for different types
  of services, such as Java, WAP, MMS and i-mode

109
Java Games
1805 French Empire
1941 Frozen Front
110
Java Games
Ice Racer
111
MMS Game
112
Examples

• Another site with a collection of games on it is
  http//www.wirelessgames.com
• Fast and Furious a racing game

113
Examples
Arkanoid
114
Examples

• Another well known mobile game company is Dwango
  http//www.dwango.com
• Here is their Aqua-X game

115
Examples
Dwango Racing
116
Examples

• Cocoasoft Cocktail Manager, and SMS based program
  for cocktail recipes

117
Examples
Eon the Dragon
118
Examples
Mobile Grand Prix