1. HIT3328 / HIT8328 Software Development for
Mobile Devices
Dr. Rajesh Vasa, 2011
Twitter: @rvasa
Blog: http://rvasa.blogspot.com
1
Lecture 05
Working with
Forms
2. R. Vasa, 20112
Lecture Overview
•Short Recap (previous weeks)
•Principles of Mobile Form Design
•Saving Form Data and Passing Messages
Back
4. R. Vasa, 20114
UI Interaction Handling Pattern
•Component.setOn......Listener ( handler
)
•E.g. button.setOnClickListener
•Handler is an anonymous inner class
•On...Listener handler = new
On....Listener() {}
5. R. Vasa, 20115
Bundle stores simple state
information
BundleBundle
putString(key, value)
putDouble(key, value)
putInt(key, value)
putStringArray(k
ey, value[])
It is a Key, Value store system
(like a Hash Table or a Hash Map)
Code Snippet:
state.putString("inputTemperature", inputTemp);
Code Snippet:
state.putString("inputTemperature", inputTemp);
6. R. Vasa, 20116
A Key Design Different (iOS Vs
Android)
Activity-AActivity-A
Activity-CActivity-C
Activity-BActivity-B
UIAppDelegateUIAppDelegate
UIViewController-UIViewController-
AA
UIViewController-UIViewController-
BB
UIViewController-UIViewController-
CC
ApplicatiApplicati
onon
UIAppDelegate has Life
Cycle
Activities have
a parent
application
Activity has Life CycleApplication is NOT
managed directly by
the O/SLife Cycle => Managed by Operating
System
View Controllers are
managed by the App
internally
7. R. Vasa, 20117
Manifest XML - What is it?
Manifest informs Runtime about the App.Manifest informs Runtime about the App.
8. R. Vasa, 20118
Controlling Input Type
(Android)
•Android has a large number of options
•You can merge them to create more
complex input types
textUri
textEmailAddress
textPassword
textPersonName
number
numberSigned
numberDecimal
numberPassword
textUri
textEmailAddress
textPassword
textPersonName
number
numberSigned
numberDecimal
numberPassword
android:inputTypeandroid:inputType
9. R. Vasa, 20119
Sending an Async. Message
Android uses an asynchronous messaging
model (known as Intents) to send messages
between Activities
Android uses an asynchronous messaging
model (known as Intents) to send messages
between Activities
10. R. Vasa, 201110
A Typical Scenario
•User is required to provide information in a
form when booking an airline ticket.
•For example: Name, Address, DOB
•High-Level Solution:
•Design a form
•Get user to fill in data
•Pass data around screens
•Store the data
11. R. Vasa, 201111
Lecture Overview
•Short Recap (previous weeks)
•Principles of Mobile Form Design
•Saving Form Data & Passing Messages Back
12. R. Vasa, 201112
Questions Arise when designing
forms
•What is the best way to
layout?
•How many fields should we
put per screen?
•How can we capture data
quickly?
•Should the screen offer
scrolling? or be a wizard?
•Do we put a ‘Submit’
button?
•If so, where?
13. R. Vasa, 201113
Layout on mobile phones is
hard
In Landscape -- fields
appear to use too much
space
In Landscape -- fields
appear to use too much
space
Needs to scroll, but
how does the user
know?
Needs to scroll, but
how does the user
know?
Do we need OK/Cancel
buttons?
Do we need OK/Cancel
buttons?
14. R. Vasa, 201114
Layout Options - Which is
ideal?
Labels above Input Field
Right-Aligned Labels
Left-Aligned Labels
15. R. Vasa, 201115
Label Layout (Usability
Research)
Labels above Input Field
Right-Aligned Labels
Left-Aligned Labels
Recommended
method for phones
16. R. Vasa, 201116
Label Layout (Usability
Research)
Labels above Input Field
Eye tracking shows
that user can focus on
both the label and field
at the same time
Eye tracking shows
that user can focus on
both the label and field
at the same time
Trade-Off: Need more vertical space -- which is at
a premium
Offers rapid-processing with least confusion
17. R. Vasa, 201117
Label Layout (Usability
Research)
Right-Aligned Labels
Users scan form before entering
data (when presented like this)
Users scan form before entering
data (when presented like this)
Advantage is in terms of space used
Trade-Off: Reduces reading speed (of labels)
18. R. Vasa, 201118
Label Layout (Usability
Research)
Left-Aligned Labels
Advantage is in terms of space used,
label scanning is easy
Users scan form before entering
data (when presented like this)
Users scan form before entering
data (when presented like this)
Trade-Off: Gap between label and
field can be very large for some fields
19. R. Vasa, 201119
Improving Layout with
TableLayout...
The layout of these blocks is not perfect
(it has been done with spaces in a Linear layout)
20. R. Vasa, 201120
Improving Layout with
TableLayout...
Linear has slight
misalignment
Table Layout
offers better
alignment
21. R. Vasa, 201121
Improving Layout with
TableLayout...
Table Layout
offers better
alignment
But, default setting does not stretch columns
22. R. Vasa, 201122
Improving Layout with
TableLayout...
Each View will be a
new column in the
row
Each View will be a
new column in the
row
23. R. Vasa, 201123
Improving Layout with
TableLayout...
Table Layout offers control over
columns
All columns stretched
Second column
only stretched
Useful Tip: Columns can be weighted to offer more
control
Useful Tip: Columns can be weighted to offer more
control
24. R. Vasa, 201124
Improving Layout with
TableLayout...
Stretch second column (zero indexed)Stretch second column (zero indexed)
Stretch all columns equallyStretch all columns equally
25. R. Vasa, 201125
Table Layout is Flexible
android:stretchColumns="0,2,4"
You can stretch a sub-set of columns
android:shrinkColumns="2"
Shrink the third column (zero indexed)
android:collapseColumns="0"
Get rid of the first column
Rows can have different number of columns
Views can be placed without TableRow
26. R. Vasa, 201126
Questions Arise when designing
forms
•What is the best way to
layout?
•How many fields should
we put per screen?
•How can we capture data
quickly?
•Should the screen offer
scrolling? or be a wizard?
•Do we put a ‘Submit’
button?
•If so, where?
27. R. Vasa, 201127
UX Principle - Read-Tap
Asymmetry
•This principle is related to Touch Interfaces
•We all have ‘fat fingers’ -- compared to the
mouse pointer
•The (common) touch size is 1cm x 1cm
•Any area on a screen that we want users to
touch (to interact) has to be one square cm
•Interestingly, we can read text that is far too
small to ‘touch’ --> Read-Tap Asymmetry
28. R. Vasa, 201128
UX Principle - Read-Tap
Asymmetry
•We can read text that is too small to ‘touch’
•This principle can be used to our advantage:
•Make labels smaller than for input fields
•Error messages can be added between fields
Label can be read at smaller sizes (to a point)
Errors, can be
added
Errors, can be
added
29. R. Vasa, 201129
Using Read-Tap Asymmetry
Labels set to 24sp Labels set to 14sp
In Forms, we can reduce label text
size, while keeping input field size at
unchanged
In Forms, we can reduce label text
size, while keeping input field size at
unchanged
30. R. Vasa, 201130
Label Size Manipulation has
Limits
Labels set to 14sp
Consider the above situation (with
10sp) for app. used by older age
groups (e.g. 75+)
Consider the above situation (with
10sp) for app. used by older age
groups (e.g. 75+)
Labels set to 10sp
31. R. Vasa, 201131
How small can a label size be?
Labels set to 14sp Labels set to 10sp
The only safe way to determine the
smallest possible label size is to undertake
Usability testing
(user background and abilities matter)
The only safe way to determine the
smallest possible label size is to undertake
Usability testing
(user background and abilities matter)
32. R. Vasa, 201132
Using Simple Styles
•In the form design example:
•The field label sizes can be
altered directly
•Time consuming/error
prone to adjust many labels
•An easier and
recommended approach is
to use styles
•We define a style and use
that consistently through
out the app.
33. R. Vasa, 201133
What is a style?
•A style allows us to create a common
resource and use it across the app.
XML file stored
under values
XML file stored
under values
35. R. Vasa, 201135
Using the Style
<TextView
android:text="First Name:"
android:id="@+id/firstNameTextView"
style="@style/FormLabel"
android:layout_width="wrap_content"
android:layout_height="wrap_content">
</TextView>
Styles are set directly (no android:)
36. R. Vasa, 201136
Impact of the Style
<TextView
android:text="First Name:"
android:id="@+id/firstNameTextView"
style="@style/FormLabel"
android:layout_width="wrap_content"
android:layout_height="wrap_content">
</TextView>
37. R. Vasa, 201137
Impact of the Style
<TextView
android:text="First Name:"
android:id="@+id/firstNameTextView"
style="@style/FormLabel"
android:layout_width="wrap_content"
android:layout_height="wrap_content">
</TextView>
You can move layout
width/height as well to the
style
You can move layout
width/height as well to the
style
38. R. Vasa, 201138
Questions Arise when designing
forms
•What is the best way to
layout?
•How many fields should we
put per screen?
•Should the screen offer
scrolling? or be a wizard?
•How can we capture data
quickly?
•Do we put a ‘Submit’
button?
•If so, where?
39. R. Vasa, 201139
Scrolling Long Forms is Ideal
•Users are getting used to quickly scrolling
on a mobile phone
40. R. Vasa, 201140
Scrolling Views
•Can make any Layout (View Group) scroll by
encapsulating it inside a ScrollView
android:scroll.... properties offer
fine-grained control (e.g. control the delay
before scroll bars fade out)
android:scroll.... properties offer
fine-grained control (e.g. control the delay
before scroll bars fade out)
41. R. Vasa, 201141
Questions Arise when
designing forms
•What is the best way to
layout?
•How many fields should we
put per screen?
•Should the screen offer
scrolling? or be a wizard?
•How can we capture data
quickly?
•Do we put a ‘Submit’
button?
•If so, where?
42. R. Vasa, 201142
Entering Data into a Mobile
Form
•Typically this is via a soft-keyboard
Soft Keyboard
automatically
pops-up
Issue: Where is the
“TAB” button to navigate
to the next field?
43. R. Vasa, 201143
Input Method Framework
•The framework offers Input Method Editor
(IME) - users can select their preferred
method
• Soft Keypad or Hardware Keypad
• Multiple vendors offer IME’s
Swiftkey Swype
44. R. Vasa, 201144
IME can be customised to
improve UX
Default
Customised
to show
Next
Customised
to show
Next
Useful Factoid: TAB key is not provided by
default
Useful Factoid: TAB key is not provided by
default
45. R. Vasa, 201145
Customising IME
<EditText android:layout_width="match_parent"
android:id="@+id/firstNameText"
android:imeOptions="actionNext"
android:text="" android:layout_height="wrap_content">
</EditText>
Many IME
options
are
available
Next Button
Useful Factoid: iOS also offers similar
customisation
Useful Factoid: iOS also offers similar
customisation
46. R. Vasa, 201146
Soft Keyboards cover the
screen
Issue: By default, you
cannot scroll the form if
the soft keyboard is
displayed
47. R. Vasa, 201147
Soft Keyboards cover the
screen
To make form resize and
scroll properly, while soft
keyboard is visible you
need to adjust the
Activity in Manifest
48. R. Vasa, 201148
Questions Arise when designing
forms
•What is the best way to
layout?
•How many fields should we
put per screen?
•Should the screen offer
scrolling? or be a wizard?
•How can we capture data
quickly?
•Do we put a ‘Submit’
button?
•If so, where?
49. R. Vasa, 201149
Short Problem - To Cancel or
not!
•Context: Android has a ‘Back’ button, iOS
does not -- but has a back-nav icon at the
top of the screen in general.
•Situation: A single screen (scrolling) form.
•Design Question:
•Do you need both the Submit and Cancel
buttons?
•A more general question:
•Do you really need a ‘Cancel’ button on web
forms?
50. R. Vasa, 201150
Short Problem - Do you need to
OK?
•Does your mobile phone offer an “OK”
button when changing contact information?
•Is the OK/Submit button needed at all?
•When would you create an explicit ‘Submit’
button?
•Key Point: Question the need for every UI
component on a mobile device.(Useless?) Factoid: The first recorded use of the word “OK” was on 23
March 1839 on the second page of the Boston Morning Post. via
@ThinkQuarterly
(Useless?) Factoid: The first recorded use of the word “OK” was on 23
March 1839 on the second page of the Boston Morning Post. via
@ThinkQuarterly
51. R. Vasa, 201151
Short Problem - Do we tip?
•What are the design choices available if you
want to show some help information to the
users as they are filling in the form.
•Will tool tips work? (If so, how?)
•Do you show a “?” symbol next to each
field?
•Do you put a “help” button per each form at
the top / bottom of the screen?
52. R. Vasa, 201152
We can add a hint for an input
field
•The aim of a tool-tip is to offer a short
hint as to the function.
•Android/iOS allow hints for views where
text is empty
android:hint="AU state or territory name"android:hint="AU state or territory name"
Hint is removed as soon as field gains focus
53. R. Vasa, 201153
Buttons and Tool Tips on Touch
Devices
•Buttons cannot offer a tool tip
•There is no mouse to hover over a button
•The only way to know the function of a
button is to click it and find out
•This situation presents issues,
•Can the user ‘undo’ an action?
•May be cause for concern in an app. that
offers mobile banking
•The only way out is to ‘Confirm Action’
54. R. Vasa, 201154
Should we confirm every
action?
•The heuristic is very simple:
•Can the user undo (or) change their mind
with minimal penalty?
•Example 1: Making a mistake entering
contact information. Can be corrected via
the edit option. So, no confirmation required
when saving.
•Example 2: Booking an airline ticket. Messy
to undo (or) change once committed.
Hence, confirm action.
55. R. Vasa, 201155
UX Guideline - Make is possible to
undo
•User should have the option to change their
mind for all actions.
•Design to ensure that mistakes are not
penalised heavily.
•This applies even to the airline ticket
booking.
•Example: Google Android Market allows
users to return purchases 15 minutes after
install is complete (was 48 hours before)
•Mainly to cover issues where app. does not
work on their device
56. R. Vasa, 201156
How do we display an error
message?
•Displaying errors on mobile forms is a
non-trivial task
•Aim to reduce potential errors at input
•Use input type restriction
•Show potential options (via a drop-down as
you type)
•When input has to be validation and error
shown -- consider a message in small font
58. R. Vasa, 201158
More example (no labels)
Maybe, labels are not always important!
59. R. Vasa, 201159
Examples (mix-n-match)
Do we really
need these
labels?
Are they
obvious?
Did you know you can take
a picture by clicking on the
camera?
60. R. Vasa, 201160
Lecture Overview
•Short Recap (previous weeks)
•Principles of Mobile Form Design
•Saving Form Data & Message Passing
61. R. Vasa, 201161
Sending Data Back to Caller
Back
The simplest option is to use a Bundle (esp. for primitives)
can also send Objects back (but involves more w
62. R. Vasa, 201162
Expecting Data (What is
involved?)
•Activities communicate asynchronously
•They send e-mail like messages to each
other
•When we start an activity, we need to
indicate that we are expecting a result
(explicitly)
Expecting a result Unique code
63. R. Vasa, 201163
Expecting Data Back (What is
involved?)
Unique code
Code can be any integer.
Needed to know which activity we are sending back
the result to
Code can be any integer.
Needed to know which activity we are sending back
the result to
64. R. Vasa, 201164
Receiving the Data
Call back method
Request Code that we
sent when activity was
started
We use the request code to
determine which activity is calling
back
We use the request code to
determine which activity is calling
back
65. R. Vasa, 201165
Extracting the Data
Data is packaged in the
Intent
We obtain data from a Parcel
(like a Bundle, but stores objects)
We obtain data from a Parcel
(like a Bundle, but stores objects)
68. R. Vasa, 201168
Sending the data back ...
Do this when “Back” button is pressed
Create an Intent (message) to be sent
back
Create an Intent (message) to be sent
back
69. R. Vasa, 201169
Sending the data back ...
Do this when “Back” button is pressed
Place Person object into an ArrayList for
transport
Place Person object into an ArrayList for
transport
70. R. Vasa, 201170
Sending the data back ....
Do this when “Back” button is pressed
Store Person object(s) in this IntentStore Person object(s) in this Intent
71. R. Vasa, 201171
Sending the data back
Do this when “Back” button is pressed
Send (intent message) back to the
caller
Send (intent message) back to the
caller
72. R. Vasa, 201172
The Magic Behind the Scenes
•Sadly, there is a bit of messy code that
makes all of this work.
73. R. Vasa, 201173
Parcel Protocol (more
details)...
This constant has to be created and named
CREATOR
This constant has to be created and named
CREATOR
74. R. Vasa, 201174
Person (object we want to move
around)
Person (object we want to move
around)
Parcel Protocol (more
details)...
75. R. Vasa, 201175
Methods are required by protocolMethods are required by protocol
Parcel Protocol (more
details)...
76. R. Vasa, 201176
Private Constructor that we have
to write
Private Constructor that we have
to write
Parcel Protocol (more
details)...
77. R. Vasa, 201177
Private Constructor that we have to
write
Private Constructor that we have to
write
Parcel Protocol (more
details)...
78. R. Vasa, 201178
What if we have complex data?
•What if we need to send a more complex
block of data back?
•We will have to look at other options
•Potential options:
•Shared Preferences (environment variables)
•External SQL database
•Application object
79. R. Vasa, 201179
References
•On Screen Inputs
•http://developer.android.com/resources/artic
les/on-screen-inputs.html
•What users really see -- results from an eye
tracking study
•http://repository.library.csuci.edu/handle/10
139/3017