1 User Interface Design Guidelines for Setup Procedures of Mobile Terminals and E-services The complexity of mobile services and devices creates a digital divide between users with the ability to use new services and those who do not know how to get access to these services. Goals: Support service and device designers through user interface design guidelines for the development of appropriate setup procedures. Enable all users to access mobile services through their devices. Overcome the hurdle to using remote services for first-time users with limited capabilities. ETSI STF 285
Transcript
1
User Interface Design Guidelines for Setup Procedures of Mobile Terminals and
E-services
The complexity of mobile services and devices creates a digital divide between users with the ability to use new services and those who do not know how to get access to these services.
Goals: Support service and device designers through user
interface design guidelines for the development of appropriate setup procedures.
Enable all users to access mobile services through their devices.
Overcome the hurdle to using remote services for first-time users with limited capabilities.
ETSI STF 285
2
Our Approach: From Use Cases to Guidelines
Use cases provide a common non-technical language for investigating user activities and their relation to system behaviors.
From these use cases we develop user interface design guidelines for the development of appropriate procedures and interfaces.
These guideline are categorized into main “themes”: major principles for the user interface design of setup procedures.
Strive for completeness through a comprehensive set of use cases which cover all major aspects of setup procedures.
3
Our Setup-Activity-Framework
The Life-cycle of device/service usage: A new service or device is first put into
use, during standard usage, or at the end of its lifetime when the device
or service is replaced by a successor. The Types of User Activities: High-level
setup activities are considered in the following areas: Communication, Fun/Filling Grey-Time, M-Commerce, Content Gathering/Browsing, Personalisation, and Synchronisation/Update.
The Context of Usage: Key aspects of context are: the User (personas can be used to
address needs of special user groups) , Mobility (walking or standing, static but
in transit (e.g. in a train), static with/without laptop (e.g. in the kitchen)).
To ensure that our use cases cover all relevant aspects of setup activities, we classify them using a three-dimensional framework:
4
Example Use Cases
Personalization: PETER WANTS TO GET THE SAME SETTINGS (SKINS, MUSIC, RINGER TONES etc.) THAT HE HAS ON HIS OLD PHONE ON A NEW PHONE BOUGHT IN SPAIN.(Peter is a retired UK inhabitant, living in Spain, with PC available)
Synch/Update: BRUNO WOULD LIKE TO ACTIVATE A NEW SERVICE (COST-OPTIMIZED GPRS-ROAMING) AND DISABLE THE PREDECESSOR (Bruno is a deaf user).
M-Commerce: JOHANNA (a female adult) WANTS TO UPDATE CREDIT CARD INFORMATION AT HER FAVORITE ON-LINE STORE.
Communication: WHILE COMMUTING TO SCHOOL LEA WANTS TO SEND AN MMS BUT CANNOT SEND THE MESSAGE. (Lea is a high-school student).
Sync/Update: PETER (an adult) HAS LOST HIS PHONE AND NEEDS TO RECOVER HIS PERSONAL INFORMATION ONTO A NEW DEVICE. ALSO, HE WANTS TO PROTECT HIS INFORMATION ON THE LOST PHONE.
5
Main UI Principles for Device and Service Setup User Interfaces
Leave the control of the setup process with the user. Automate the setup process as far as possible. Keep the configuration at a minimum number of steps. Always keep necessary addresses for help/information. Provide all necessary information to the user. Provide all configuration information in the user's native or
other preferred language. Provide all configuration information in the user’s
vocabulary. Use existing standards and guidelines. Design for different abilities and knowhow.
6
Leave the control of the setup process with the user.
Always allow for interrupts from the user (Cancel button) “Always allow a way out, but make it easier to stay in.”
Provide "back", "next", "cancel", and "finish" as well as "help" controls.
Indicate the progress of the configuration procedure to the user.
Make actions reversible, allow for human error Navigation should be under user control throughout
the configuration procedure.
7
Automate as Far as Possible
Pre-configuration is the preferred solution for configuration of terminal and service access.
If pre-configuration cannot be achieved, some means of guided configuration should be provided, taking into consideration the needs of all users (including elderly or disabled users)
Provide means for guided and/or manual configuration in the terminal, if pre-configuration cannot be achieved.
Subsequent updates of settings, e.g. OTA, should provide the default entries for terminal or service resets.
8
Keep configuration at a minimum number of steps
Don’t ask for unnecessary confirmations. Don’t provide extraneous information during the
setup process. Avoid disturbances during setup wherever possible. Provide auto-completion where appropriate; allow
disabling of this feature under user-control. If a service is unavailable due to other reasons (e.g.
network not available, service not configured for roaming while user is abroad) the user should get a correct indication of the reason for failure.
9
Keep necessary addresses for help/information
As a fallback solution a service phone number should be available through which the configuration can be initiated from a call center.
Each service provider should provide a manual, face to face channel to modify sensitive data details in the event of failure of the automated process.
Operator-specific service information should be provided directly in the handset, including the means to control the service.
10
Provide all necessary information to the user
Provide a clear description of what equipment and information the user needs to have ready to hand during the configuration procedure, and if necessary, how to obtain it.
Convey what settings need to be configured and what effect configuring a setting will have by providing natural entry points into the configuration procedure.
Indicate the progress of the configuration procedure to the user.
Success or failure for each setup step should be communicated to the user. Steps to correct the failure should be communicated as well.
11
Provide all configuration information in the user's native or other preferred language
Option to explicitly select a preferred language should be part of every setup process.
The language of the device can be a good default for the service setup language.
Users should be prompted to select their ideal language when using a new device.
12
Provide all configuration information in the user’s vocabulary
Do not display machine code error messages. Where necessary, provide explanations of concepts
that need to be understood by the user during configuration.
Provide consistent terminology across all sources of configuration information.
Avoid giving unnecessary information to the user. As far as possible, hide technical concepts that the
user does not need to understand during configuration.
Help information is required for each entry in the MMS configuration as most parameters are not self-explanatory.
13
Allow for human error
Provide error handling to prevent a change of setting entries which would in turn prevent access to basic services.
If the user is permitted to change the setting entries, resetting the terminal to factory settings should present the user with a choice of whether to keep or reset the current settings for terminal and service access.
Error messages should include information on how to correct errors, e.g. in case of server unavailability: “Please control the server setting on you device by sending an empty SMS to phone number xxxx. Follow the instructions after the receipt of the return SMS. If your settings are correct please retry to send you message. If this fails again the server may unavailable. Please retry after 15 minutes or call xxx for further support”
14
Allow access to setup-information during setup-procedures
Access to the main menu of the device should be possible during OTA setup procedures.
The user should have access to device information pertinent to setup processes for services Phone model and serial number Username/Password IMEI Software version Possibly Hardware version Subscription details (services subscribed)
15
Use exisiting standards and guidelines
The most recent versions of management protocols and mechanisms, as specified in OMA working documents and reference specifications (see bibliography), with corresponding UI elements, are the recommended, generic technical solution for configuration for terminal and service access.
Follow customer/service provider specific guidelines Guidelines for changing modalities/ use of applicable
modalities, see [11] Setup dialogs are user-machine interactions: if style
guides exist in the environment, use them!! Refer to outcome of STF Multi-culty if available. There should be consistency between device, bearer
(e.g. MMS), and service (e.g. “ticketing”) setup procedures
16
Design for differing user abilities or know how
Multimodal interaction should be used wherever possible; as a fallback access to a personal call-center support is strongly advised.
Reminders with easy access to a setup-dialog are helpful for first-time users of a service.
An option to use a large font should be provided. The user preference for detailed or short feedback,
wizards and other guided procedures should be considered (even if setup is automated the activities carried out in each automated setup may be required by the user).
Feedback to the user should be confirmed to the user in the preferred way
17
Terminal-specific setup guidelines
Provide consistent and coherent categories of settings.
Easy back-up method should be available, and user should be encouraged back-up phone data frequently.
The result of back-up should be confirmed. The reason and importance of back-up should be
explained to the user. Simple guidance and support for first back-up should
be available. Especially problem solving for handling data and phone incompatibilities should be supported.
The result of restore should be confirmed. All device internal settings should be preset by the
device manufacturer (with the option of modification by the service provider).
18
E-service Specific Setup Guidelines
The user should be informed at an appropriate level and through appropriate channels of the costs connected to the service to be configured.
Clearly describe the means by which the setting entries will be delivered to the terminal, e.g. via SMS.
For remote configuration via a web site, provide a "send" control with instructions to confirm that the terminal is switched on.
No automatic reconfiguration if cost issues are relevant.
A wireless method for protecting the content of a lost phone should be available.
A wireless method for backing-up the content of a lost phone should be available.
19
Future Work and Research Topics For practioners: How to apply our set of guidelines?
How to deal with contradicting guidelines?
How to prioritize design guidelines?
How to achieve a higher degree of automation?
Setup guidelines for accessibility features
Specific guidelines for elderly or very young users
Setup guidelines for multi-user services
Usability testing of our guidelines
Can we develop technology-independent design guidelines?
Based on Cockburn (1997) Use case describes a high-
level set-up activity to be achieved.
Variations/Extensions explore problems during set-up.
Guidelines generated from problem solutions.
Solutions are near-term
USE CASE 1A setup goal
Goal in Context User, Life-Cycle, Activity
Scope & Level NA
Preconditions Assumptions?
Success End Condition
When is goal accomplished?
Failed End Condition When is goal not accomplished?
Primary, Secondary Actors
User and others?
Trigger What starts the use case?
DESCRIPTION Step Action
(Main success scenario)
1..x Ideal set-up solution
EXTENSIONS in user actions
Alternative sub-steps
Branching Action. These are also potential user eroors.
(Potential problem and error cases)
1..X
VARIATIONS in the phone states and behaviour
Alternative sub-steps
Branching Action. These are also potential system
22
Backup: Example Use Case (1)
PETER WANTS TO GET THE SAME SETTINGS (SKINS, MUSIC, RINGER TONES etc.) THAT HE HAS ON HIS OLD PHONE ON A NEW PHONE BOUGHT IN SPAIN.(Peter is english and has retired to Spain. He has a PC available)
USE CASE
Data transfer between phones in second country.
Goal in Context
Life-Cycle: Initial useActivity: Synchronisation: Copy content from old phone to new phone provided by an operator in another country for initial use. Context: User is 65 years old with slight visual impairment. User is at home seated in living room. PC access is possible. Prefers guided instructions.
Scope & Level Device configuration for initial use.
Preconditions User has access to old phone. User has backed-up data on his home network due to reminders from UI avatar in his old phone. User is aware that back-up is possible
Success End Condition
All required data is copied onto the new phone.
Failed End Condition
No data is copied onto new phone.
Primary, Secondary Actors
User, new phone, old phone, PC
Trigger New phone has been bought in Spain
23
Backup: Example Use Case (2)
The ideal flow (Main success scenario)
1 User accesses Spanish operator WAP portal using new phone
2 User enters user name and password in “back-up” page
3 User navigates to last back-up that they made on their home network.
4 User activates back-up from network to new phone
5 All content appears on new phone.
24
Backup: Example Use Case (3)
Extensions : alternative sub-flows or user problem sub-flows
EXTENSIONS in user actions
Branching Action. These are also potential problem and error cases
(Potential problem and error cases)
1 Alternative: Rather than WAP, user activates preloaded back-up management application. The application accesses the network.
1.1 User does not know WAP address for operator portal
2.1 User has forgotten user name and/or password
2.2 User advised he incorrectly entered name/password
3.1 User has trouble navigating due to small text and ambiguous labelling of menu options.
25
Backup: Example Use Case (4)
Variations : device/service/network problem sub-flows
VARIATIONS in the phone states and behaviour
Branching Action. These are also potential problem and error cases
1.0 The device is set to Spanish language
1.1 WAP is not configured correctly and connection to network server is refused.
1.2 User uses PC to navigate to operator portal
2.1 User account is not recognised (because it is in the UK) and user is asked to re-enter password
3.1 Latest back-up is not shown
4.0 New phone is not compatible with backed-up data
4.1 Phone battery is spent during back-up
4.2 User receives a call during back-up
4.3 Phone loses coverage during back-up as peter walks into the garden
