Enabling and Improving the Use of Mobile eServices

1
Enabling and Improving the Use of Mobile
e-Services

• Workshop1
• _at_
• Human Factors in Telecommunication Symposium 2006
• ETSI, Sophia Antipolis, France
• March 20, 2006

2
Agenda

• 930- 1030 Introduction
• ETSI, TCeurope and the work
• 1030- 1230 Session 1
• 1230- 1330 Lunch
• 1400- 1600 Session 2
• User education and Setup tracks
• 1600- 1630 Sum-up and conclusions
• 1630 HFT 2006 Welcome cocktail
• Coffee and convenience breaks will be flexible

3
ETSI Specialist Task Force 285

• Present
• Bruno von Niman, ITS (vonniman consulting)
• Martin Böcker, BenQ
• Michael Tate, BT
• Pekka Ketola, Nokia
• Absent with a good reason
• David Williams, Motorola (majire)
• Matthias Schneider- Hufschmidt, BenQ
• Margareta Flygt, Sony Ericsson
• Pascale Parodi, Nokia

4
Why standards?
5
What is ETSI?

• A European standards organization
• Officially recognized by the EU EFTA
• Setting globally-applicable standards for
• Telecommunications, in general
• Radio communications, especially mobile
• Broadcasting, and
• Related topics
• Active in all areas of ICT
• An independent, non-profit organization,
  created in 1988
• Offering direct participation of all members
• We have more than 15,000 publications ?
  available for free!

6
ETSI

• We are the home of the GSM standards

and of a lot of others, e.g. ISDN, DECT, DAB,
DVB
7
ETSI

• and a founding Partner in

The 3rd Generation Partnership Project
8
ETSIs Vision (March 2006)
ETSI is the preferred organization for the ICT
industry and other stakeholders, to develop
standards and specifications for the global
market, and to support regional initiatives as
appropriate. In standardization, we have to
understand that we are here to agree on something
useful!
9
ETSIs innovations

• Direct representation in standards-making
• An open and world-wide acceptable process
• Products matched to market needs
• Specialist Task Forces (Project Teams)
• Competence Centres
• Early introduction of electronic working
• ISO 90012000 certification since 1994
• Standards for free

10
ETSI Membership
Service Providers
Others
24
Manufacturers
Users
51
4
Administrations
8
Network Operators
13
11
Expectations from good standards? 1 (2)

• Market relevance
• demand by the market
• fulfilling market needs
• Timely provisioning of
• global networking
• global interworking
• global interoperability
• Basis for fair competition
• Market growth

12
Expectations from good standards? 2 (2)

• Not too detailed, but unambiguous
• Detailed enough in order to allow for
  multi-vendor operation
• Modular structure preferred
• Clearly defined interfaces
• Technology independence
• Easily and fast adaptable to new technology
• Usable in different networks

13
Standardization is

• Load sharing
• Cost saving
• Close Co-operation of competitors
• Reduction of solutions to a minimum preferably
  ? one!
• Creation of a critical mass
• Bringing about economy of scale
• A fight against technical barriers to trade

14
The user experience of ICT1876 1990

• Intelligent agent-assisted, natural
  speech-controlled calls and text messages to and
  from unique wired devices
• Safe, secure, always-on
• Positioning services, context and
  location-sensitive
• Computers processed by specialists
• First Apples and PCs
• Major improvements
• design
• increasing number of users
• HW the handset, handsfree and push-button keys
• technology advances.

15
Consumer experience of ICT1990- Future
Generation

• ICT plays a key role in everyday life - eSociety
• Mobile, multimodal, personal, universal,
  converging, always-on, ever-smarter
• Capabilities evolving further
• More mobile than fixed
• Growth driven by
• Technology
• voice-centric users, data adapters and mobile
  services
• user experience.
• Complexity, interoperability and connectivity
  issues

16
Everyday life- e-Society
17
ETSI TC Human Factors

• Responsible for human factors
• issues in all areas of
• telecommunications and ICT
• Responsibility to ensure ETSI takes
• account of the needs of all users-
• generic, older, young, disabled, etc.
• Produces standards, guidelines and
• reports that set the criteria necessary
• to ensure the best possible user experience
• Chairman Stephen Furner (BT, UK)
• Vice Chairmen Bruno von Niman (ITS, Sweden)
  Lutz Groh (BenQ, Germany)

18
TC HF Major activities/deliverables

• New wave technologies
• Childrens use of ICT
• Telecare
• Real time communications
• Fixed mobile convergence
• Minimum HCI for mobiles
• User profiles
• Enterprise wide systems
• Accessibility and inclusion
• Textphone access to IP text services
• Symbols for access to digital TV
• Multicultural interfaces
• Deliverables
• Around 100 deliverables published so far by ETSI
  human factors committees
• Project Teams/STFs
• 31 have completed work to date 5 are in
  preparation more on the way!

19
ETSI HF Specialist Task Forces

• - Requirements for assistive technology devices
  in ICT
• - Generic spoken command vocabulary for ICT
  devices and services
• - Guidelines on the multimodality of icons,
  symbols and pictograms
• - Guidelines for ICT products and services
  Design for All
• - Access to ICT by children Issues and
  guidelines
• - Alphanumeric characters in European languages
  sorting orders and assignment to the 12-key
  telephone keypad
• - Human Factors of work in call centers
• - Multimodal interaction, communication and
  navigation
• - Maximizing the usability of UCI based systems
• - Guidelines for generic UI elements of mobile
  terminals and services
• - Telecare in and outside of intelligent homes
• - User profile management
• - Guidelines for the design and use of ICT by
  children
• Duplex universal speech and text communication
• Multicultural aspects of ICT
• Etc.

20
(No Transcript)
21
STF285 User Education and Set-up Procedures

• Contracted experts representing
• Nokia,
• Siemens,
• Sony Ericsson and
• Independent consultants
• Takes into account previous work
• Open, result-oriented, pro-active work based on
  consensus
• All results agreed with key players in the
  industry
• ETSI Guides to be published in September 2006

22
STF 285 Scope

• Elaborate the previous work in two key areas
• Set-up procedures
• User Education
• Provide guidelines on both areas in order to
  support device and service design
• Support users in first-time device and service
  set up
• Support users in using features and services
• Principles identifying minimum quality standards
• Ensure a design-for-all approach (universal
  design)
• Outline solutions for ensuring access by the
  widest possible range of users

23
Rationale for minimum standards in set-up
procedures

• Failure to set up successfully mobile devices and
  services leads to low or no service uptake,
  decreased trust in manufacturer and service
  provider
• Mobile devices and services are complex and
  abstract, and cannot always be pre-installed by
  the manufacturer
• Trends that underline the importance of the
  issue
• Changing population demographics
• Population mobility
• Increasing user expectations
• The deployment of advanced social services
• Access to services by all
• Increasing variability in the segmentation of
  customers.

24
Areas covered set-up procedures

• Importance of set up procedures
• Previous work
• Initial set up and product replacement
• Life cycle, user activity and context of usage
• Use cases for set-up activities

• Generic set-up guidelines
• Terminal-specific set-up guidelines
• e-service-specific set-up guidelines
• Set-up procedures and design for all
• Development and evaluation of set-up procedures

25
Draft ETSI Guide Setup Procedure Design
Guidelines for 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.

26
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

27
Setup activity framework
To ensure that our use cases cover all relevant
aspects of setup activities, we classify them
using a three-dimensional 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)).

28
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 power-user
• M-Commerce JOHANNA WANTS TO UPDATE CREDIT CARD
  INFORMATION AT HER FAVORITE ON-LINE STORE
• Johanna is a female adult
• 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 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
• Peter is a male adult

29
Use case template

• 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

30
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

31
Example use case (2)

• The ideal flow

32
Example use case (3)

• Extensions alternative sub-flows or user
  problem sub-flows

33
Example use case (4)

• Variations device/service/network problem
  sub-flows

34
Use cases to explore (1)

• Filling grey-time
• DIRK (20) IS MAKING AN MMS OF VIDEO AND AUDIO TO
  SEND TO A V-JAYING COMPETITION BUT HE DOESNT
  HAVE RIGHTS TO USE THE CONTENT ON HIS PHONE
  (student)
• DOMEK (30) WANTS TO UPDATE A TRIAL VERSION OF A
  GAME THAT WAS PREINSTALLED ON HIS HANDSET
  (freelance designer)
• TIBO (45) WANTS LESS REGULAR WEATHER UPDATES ON
  THE LIVE CONTENT AREA OF HIS HOME SCREEN (keen
  hiker)

35
Use cases to explore (2)

• Browsing for content
• BRUNO (45) HAS JUST UPGRADED HIS HANDSET AND
  WANTS TO SEE HOW THE LATEST F1 GAME FROM HIS
  FAVOURITE GAMES PORTAL LOOKS ON THE NEW HANDSET
  (manager)
• SOPHIE (37) WANTS TO CHANGE HER WAP HOME PAGE AND
  STORE A FAVOURITE MEDIA SITE THAT SHE IS
  CURRENTLY VIEWING (journalist)
• RICCARDO (55) HAS HEARD THAT MOBILE TRANSACTIONS
  ARE NOT SECURE AND WANTS TO UPGRADE THE SECURITY
  SETTING OF HIS BROWSER (bank employee)

36
Use cases to explore (3)

• Synchronisation/ update
• TASMIN (50) HAS JUST RECEIVED AN AUTOMATIC OTA
  UPDATE OF HER CONTACTS APPLICATION THAT SHE
  DOESNT LIKE. SHE WANTS TO RETURN TO HOW THINGS
  WERE BEFORE THE UPDATE (personal recruiter with
  visual problems)
• Personalisation
• MARCO (40) WOULD LIKE TO CHANGE THE GREETING ON
  HIS NETWORK VOICEMAIL. HE WOULD LIKE TO USE AN
  AMUSING MP3 FILE THAT HE SON HAS DOWNLOADED ONTO
  HIS PHONE (construction worker)

37
Main UI principles for device and service setup
UIs

• 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
  users vocabulary
• Use existing standards and guidelines
• Design for different abilities and know-how

38
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

39
Leave the control of the setup process with the
user

• If the configuration procedure fails or is
  aborted the state of the terminal should revert
  to that previous to the start of the
  configuration procedure. The user should be
  informed on how to proceed in order to complete
  the configuration
• If a service recognizes that it is not configured
  properly it should inform the user and initiate
  the setup process if requested

40
Leave the control of the setup process with 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
• During the transfer of setup information from one
  device to another non-optimal transfer should
  require confirmation by the user
• Transfer of setup information from one device to
  a second device should not modify the contents on
  the first device. (Attention license information
  may be a problem) Any modification on the source
  device should be confirmed by the user
• As far as possible, avoid forcing the user to
  input entries for settings. Provide appropriate
  default entries for settings

41
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

42
Automate as far as possible

• It should be possible to return to an interrupted
  setup procedure without loss of earlier input
• A service/device should be usable with minimum
  setup/come preconfigured with place-holder values
  like e.g. greeting message

43
Automate as far as possible

• Use the language selected for the phone as a
  default for configuration of services
• A service should be able to control/correct its
  configuration on the users device without user
  intervention, as long as there is no cost
  implication
• Basic setup should be available OTA e.g. by
  sending a short message to a service centre,
  which automatically configures the service and
  the device settings

44
Keep configuration at a minimum number of steps

• Dont ask for unnecessary confirmations
• Dont 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

45
Keep necessary addresses for help/information

• Provide simple access to call-centres or to
  detailed information during setup processes
• Links to information and information in the
  service/device should be kept up-to-date during
  the lifetime of a device/service
• Relevant information on how to deal with for
  worst-case scenarios (e.g. lost or stolen phone)
  should be available (on the service provider side)

46
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 centre
• 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

47
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

48
Provide all necessary information to the user

• Provide clear indication and differentiation of
  what the setting is and what the actual entry of
  the setting is
• Provide clear instructions on what type of
  information is required at each step of the
  configuration procedure. Provide illustrative
  examples
• Provide examples of the correct format for the
  required setting entries and support for handling
  the formats
• Provide information to the user on which settings
  are pre-configured
• Provide a clear overview of the steps of the
  configuration sequence

49
Provide all necessary information to the user

• Provide a logical and consistent order to the
  configuration procedure. Provide information on
  how to change settings later
• Provide clear feedback when the configuration
  procedure ends
• Only provide steps that involve instructions,
  choices or feedback relevant to the configuration
  procedure. All other steps are redundant
• Exploration users should have easy access to all
  features that can be configured
• Where possible these features should be related
  to the users experience, know -ow, environment,
  preferences, and location
• Cost consequences should be shown to the user

50
Provide all necessary information to the user

• The user interface should communicate if the
  configuration is related to a remote or a local
  feature
• During the transfer of setup information/contents
  from one device to another, steps that cannot be
  completed or are completed in a non-optimal way
  need to be signalled to the user
• Pending automated registration should be
  communicated to the user
• If a service is unavailable due to the
  unavailability of underlying network services
  this should be clearly indicated to the user to
  prevent frustrating configuration attempts or
  un-intended reconfiguration of the requested
  service

51
Provide all necessary information to the user

• Reasons for unavailability of services should be
  clearly indicated
• If a setup-action has not been successful the
  device should inform the user as to why the
  action has not been carried out. State of the
  system must be clear to the user and should be
  communicated to the user
• Information should be provided on authentication
  and authorisation
• Where common services are provided on web/WAP
  these services should be indicated (space
  permitting)
• Changes impacting the service should be indicated
  to the user if they necessitate reconfiguration
• If a service can be activated and deactivated
  through several channels, the result should be
  the same (and the information channels should
  interoperate)

52
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

53
Provide all configuration information in the
users 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

54
Allow for human error

• Provide error handling to prevent a change of
  setting entries, preventing 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 your 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 your message. If this fails again,
  the server may unavailable. Please retry after 15
  minutes or call xxx for further support

55
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)

56
Use existing 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 reference 11 in the
  draft EG
• Setup dialogs are user-machine interactions if
  style guides exist in the environment, use them!
• Refer to outcome of the Multi-cultural STF, when
  available
• There should be consistency between device,
  bearer (e.g. MMS), and service (e.g. ticketing)
  setup procedures

57
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

58
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)

59
Terminal-specific setup guidelines

• While the initial configuration over a web site
  using a PC may be the preferred option it must be
  possible to initiate a configuration attempt from
  the device itself.
• The back-up summary/history displayed in the user
  interface should indicate where the backed-up
  data is and exactly what was backed-up (those
  elements that could not be backed-up should be
  shown)
• The time since the last back-up should be
  available in the user interface
• Objects that can be backed up, e.g. images/music
  should have last backed-up and location
  information associated with them
• This could be presented in text form (Date),
  iconic form (location) or by using other display
  characteristics such as colour (to show age)

60
Terminal-specific setup guidelines

• If a back-up process is interrupted by an
  external event or the user, some indication
  should remain in the user interface that back is
  still in progress or that it has terminated with
  failure
• Prompts reminding users to back-up should be
  unobtrusive and not interrupt task flow (unless a
  back-up has not been made for a long
  (user/operator defined) time)
• Instructions on recovery of back-ups should be
  available at time of back-up and should be
  associated with content that may be backed up
  (rather than being in a sync or back-up menu)

61
Terminal-specific setup guidelines

• If basic back-up setup is not complete on the
  device, the user should be notified as soon as
  possible. In order to complete back-up the user
  should be directed to Web, IVR or human customer
  service agents
• Users should be prompted to make periodic
  back-ups to network, PC, memory card etc.
• If approved by the user, the back-up process
  should be automatic based on pre-configuration /
  user configuration
• The first step in the recovery/setup process
  should be to inform the user if their phone is
  compatible with the backed-up data.
• In addition, the data elements which can and
  cannot be backed-up should be represented
• Where possible reasons should be given for those
  elements which cannot be backed-up.

62
Terminal-specific setup guidelines

• During the back-up process, users should be
  allowed to modify the available locations for
  back-up, e.g. PC, network, external memory card
• The user should be able to view a back-up history
  and location on their device without being
  connected to the network
• Labelling of menu items should clearly describe
  their contents (pre-design labelling studies may
  be required for abstract functions such as
  synchronisation/back-up
• The information that is needed in a lost-phone
  situation should be available easily
• User should have easy-to-find and easy-to-access
  guidance for actions in a lost-phone situation

63
Terminal-specific setup guidelines

• Simple guidance and support for first back-up
  should be available
• Simple guidance and support for restore should be
  available. Especially problem solving for
  handling data and phone incompatibilities should
  be supported
• The result of restore actions should be
  confirmed.
• A wireless method for protecting the content of
  lost phone should be available
• A wireless method for backing-up the content of
  lost phone should be available

64
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

65
e-service specific setup guidelines

• If a service is not properly configured (e.g.
  missing service provider phone number) the device
  should inform the user or try to reconfigure
  before attempting to access the service (cost
  savings).
• Each service provider should provide an interface
  through which the user can select OTA
  configuration for all subscribed services
• Service providers should offer an SMS address
  which can be used to initiate re-configuration
  processes
• This number should be stored on the SIM
• The configuration server should be able to handle
  all necessary configuration processes required to
  make a service usable.

66
e-service specific setup guidelines

• For personal critical information If the
  modification action has not been successful the
  service provider should be informed and action
  should be taken to contact the user
• The user should be made aware of where their
  personal details are stored and should be able to
  manage these personal details
• The information provided about new services
  should be complete and accurate
• When configuring a new service, the dependencies
  on other services should be indicated and
  explained to the user, preferably in a
  personalized way

67
Proposal for Part II of the Workshop

• Open discussion on document structure
• Open discussion on existing guidelines
• -----------------------
• Work in groups on three different use cases.
• Try to identify missing guidelines
• -----------------------
• Summary and final discussion (Plenum)

68
Its all about the users, not the technology

• Tim Berners-Lee
• W3C 10th Anniversary
• December 1st, 2004, Boston