Transcript Document 7281292

SM3121
Design for Small Devices
Mark Green
School of Creative Media
Introduction
Small devices have three main
limitations that effect design:

1.
2.
3.
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
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
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
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
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
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
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
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
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
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
Input Devices
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
 Soft
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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?
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
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
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
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
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
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
Design Documentation
Main
Task A
Task A1
Task B
Task A2
Task B1
Task C
Task B2
Task C1
Task C11
Task C12
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
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
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
Design Guidelines
 Use




compact layouts:
Don’t waste space
Avoid large vertical gaps, confuses some
users
Flow text around images
Don’t use decorations, keep to the essential
material
 Remember
for the user
the task at hand, make it easy
Design Guidelines
 Keep
text simple
 Most mobile devices don’t have a large
number of fonts, maybe only 2 or 3, so
don’t 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
Design Guidelines
 Control
use of colour, many phones don’t
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
 Don’t refer to items by colour, won’t work
on b&w phones
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, don’t
have 100% of their attention
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
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
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
Design Elements
Design Elements
Design Elements
 The
title should be fairly short, less than
14 characters, indication of screen content
 Not all users will read the title, so don’t 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
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 <br/> to control text layout,
don’t try to be much fancier
 Look at the screen shots to see just how
little space there is for text
Design Elements
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
Design Elements
 There
are two ways to get more control
over format:


Use style sheets or <style> 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
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
Design Elements
Design Elements
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
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 doesn’t
need to be downloaded
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, don’t
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
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
 Doesn’t work on all phones
Design Elements
 Don’t
underline regular text, users will
think it’s a hyperlink
 Users can’t mouse over text to see if it’s a
link, like on a PC browser, so underlined
text will confuse
 Don’t remove underline style from
hyperlinks, users won’t know that they can
select it
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
Design Elements
 Most
of the standard input elements can
be used including:






Text
Checkbox
Radio buttons
Text area
Selection
Hidden
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, don’t want
the user to scroll too much
Just collect the necessary data
Design Elements
Design Elements
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
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
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
Java
 Why
not use some other language or
package?



Java is already available on most phones,
don’t 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
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
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
Java Applications
How do Java applications get onto a
mobile device?
Lets start with phones
As a developer we produce two files:



1.
2.
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
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
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
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
Java Applications
How do MIDlets do this?
All MIDlets have three standard
procedures:


1.
2.
3.
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
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
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
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
Design Elements
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
Design Elements
Design Elements
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
Design Elements
Design Elements
 Information
can be collected from users
using standard elements:






Text fields
Text areas
Check boxes
Radio boxes
Dates
Progress meters
Design Elements
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
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
Design Elements
Design Elements
 On
some implements of MIDP the date
element is a calendar or clock,
unfortunately in the emulator it’s 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
Design Elements
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
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
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
Java Games
1805 French Empire
1941 Frozen Front
Java Games
Ice Racer
MMS Game
Examples

Another site with a
collection of games
on it is
http://www.wirelessga
mes.com
 Fast and Furious a
racing game
Examples
Arkanoid
Examples

Another well known
mobile game
company is Dwango
http://www.dwango.co
m
 Here is their Aqua-X
game
Examples
Dwango Racing
Examples

Cocoasoft Cocktail Manager, and SMS based
program for cocktail recipes
Examples
Eon the Dragon
Examples
Mobile Grand Prix