Jim Warren

1
Design for mobile

• Jim Warren
• (with lots of inspiration from
  http//www.ibm.com/developerworks/library/wa-inter
  face/wa-interface-pdf.pdf)

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

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!

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)

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

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

7
http//www.ibm.com/developerworks/library/wa-inter
face/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 its 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

9
Bootstrap Grid system responsive layout
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. ltdiv classcol-sm-3gt 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

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

12
Changing the amount on screen
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 users main feed

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

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

ltheadgtltstylegt_at_media screen    p.test
font-familyverdana,sans-seriffont-size14px
_at_media print    p.test font-size20pxcolorred
_at_media screen,print    p.test
font-weightboldlt/stylegtlt/headgt ltbodygt....
lt/bodygt
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. seehttp//dojotoolkit.org/reference-guide/1.
  9/dijit/themes.html(The DoJo toolkit is an
  open-source modular Javascript library)

17
Recycle

• 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, theres 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 its 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/appl
  e-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)
• Large collection of successes at
  http//pttrns.com/

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

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

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 its 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, dont display these because
  physical home and back buttons are provided

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)

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 theyre used to
• Ignoring browser interactions
• Best if you site provides all the navigation
  needed without users having to go to the
  browsers layer of controls

24
Summary

• Mobile interaction means users can reach your
  content almost anywhere
• But it isnt the same as interacting through a
  desktop PC
• Consider the shift in scenarios
• Consider the differences in display real estate
  and controls