Design Guidelines for Better 3G User Interfaces Matthias Schneider ETSI STF322 mschacm'org

1
Design Guidelines for Better 3G User
Interfaces Matthias Schneider ETSI STF322
msch_at_acm.org
2
Topics

• ETSI
• The work of ETSI Specialist Task Force 322
• Introduction
• Tasks
• Sample Guidelines
• The work carried out is co-financed by the
  EC/EFTA in response to the ECs ICT
  Standardisation Work Programme.

3
ETSI

• The home of the GSM standards

and ISDN, DECT, DAB, DVB
4
ETSI

• and a founding Partner in

5
What is ETSI?

• ETSI, the European Telecommunication Standards
  Institute
• A European standards organization, active in all
  ICT areas
• Independent, non-profit, created in 1988
• 700 members from 60 countries on 5 continents
• Officially recognized and co-funded by the EU
  EFTA
• Setting globally-applicable standards for
• Telecommunications (in general)
• Radio communications (especially mobile)
• Broadcasting, and
• Related topics
• Offering direct participation of all members
• More than 18,000 publications ? all available for
  free at www.etsi.org

6
We need standards to ensure

• Compatibility of equipment and services from
  different suppliers
• Full interoperability
• Transfer of learning
• Accessibility to equipment and services
• Better safety and security
• Load sharing, cost saving, co-operation of
  competitors

7
The Usability Gap

• Featurism - product complexity increasing
• Range of mobile technology users broadening
  from children to elderly and disabled

8
Decreasing the Usability Gap

• Possible ways to decrease complexity include
• understanding of user needs,
• excellent user interfaces,
• Innovation,
• simplicity of setup and configuration,
• personalization capabilities,
• ease of operation.
• Also the usability gap can be helped by
• technological advances, e.g. natural
  interaction/direct manipulation
• speech recognition, touch screens
• ICT maturity.

9
Guidelines for generic UI elements? For mobile???

• 12-key keypad character repertoire, key mapping
  and sorting
• Inconsistent, expensive, time-consuming,
  irrelevant as a mean for competition, confusing
  to the user
• ETSI Standard for 28 languages, expanded to 101
• Spoken command vocabulary
• A considerable effort
• ETSI Standard for 12 languages, expanded to 30
• Accessibility design guidelines, Multimodal
  design guidelines
• Generic UI design guidelines
• 2G and GPRS
• 3G and HSPA (under development)

10
Generic UI elements!
11
Rationale for generic UI elements (1/3)

• Manufacturers differentiate their products
  through industrial and screen design, feature
  sets and UIs
• Generic UI elements are accepted
• in safety-relevant products (e.g. cars),
• for products to be used by many people (products
  in public or work environments), and
• In UIs following de-facto standards (GUIs in PC
  software or musical instruments).

12
Rationale for generic UI elements (2/3)

• Generic UI elements result from
• De-facto standards (e.g. GUIs), and from
• official standardisation (e.g. keypad arrangement
  on public phones).
• Generic UI elements potentially benefit all,
• end users,
• manufacturers, and
• service providers.
• Can facilitate the uptake of new and emerging
  technologies and user interfaces, e.g.
• ETSI ES 202 130 Character repertoires, ordering
  rules and keypad assignment (under expansion)
• ETSI ES 202 076 Generic spoken command vocabulary
  (under expansion)

13
Rationale for generic UI elements (3/3)

• Basic considerations of what makes a UI area a
  candidate for generic UI elements
• No barrier to innovation
• No obstacle to good product-specific user
  interfaces
• Only the semantic of a generic user-interface
  element should be specified, not the actual
  design and implementation
• End-user aspects, such as learnability,
  familiarity, trust, configuration and access
• Commercial aspects (quicker uptake of new
  technologies, larger user base)
• Legal requirements and possible regulation

14
EG 202 132 GSM and GPRS-specific Guidelines

• Terminology, symbols, acoustic signals and user
  guides
• Configuration for service access, interworking,
  portability and error handling (now superseded by
  EG 202 416 the Setup guidelines)
• Terminal and network related generic UI elements
• Service and application specific UI elements

15
ETSI STF 322 (The 3G Guide)

• Co-funded by the EC/EFTA
• Leader
• Bruno von Niman (ITS (SE), vonniman consulting)
• Experts
• Pekka Ketola (Nokia)
• David Williams (Motorola/Majire/Asentio Design)
• Matthias Schneider (Siemens/BenQ Mobile/Nokia
  Group)
• Follow up EG 202 132 (STF231), focusing on the
  3G-specific aspects
• Time plan
• Set up in 2006, work started in 2007
• Final draft deliverable ready (TB approval) on
  September 22, 2008
• ETSI publication foreseen in December 2008

16
Scope of the 3G work (1/2)

• Simplify end-user access to ICT services for end
  users and consumers from mobile 3G/UMTS
  telecommunication terminals
• without restricting the ability of market players
  to further improve and develop their terminals,
  services and applications.
• Expand scope of EG 202 132, Human Factors
  Guidelines for Generic Mobile User Interface
  Elements for Mobile Terminals and Services
  (August 2004)
• to 3G specific issues
• Address specific and important 3G key issues from
  the end user's perspective
• providing guidance on proposed generic user
  interface elements for basic and advanced mobile
  terminals, services and applications, including
  their accessibility.

17
Scope of the 3G work (2/2)

• Consider user requirements and integrate
  available results of standardisation work
• providing implementation oriented guidance.
• Do not restrict ability of market players
• to further improve and develop their devices and
  services.
• Do not limit options to trademark UI elements or
  profile the user experience
• of brand-specific user interface implementations
  as a competitive edge.
• Provide guidance on simplifying end-user access
  to basic and selected advanced functions of
  mobile communication services from mobile
  communication devices.

18
3G/UMTS specifics addressed by the 3G work (in
DEG 202 972) (1/2)

• Introduction of the present draft
• Scope, methodology, topics
• Approach
• Collaboration with industry
• Work plan and time schedule
• Requirement collection
• Dissemination plan
• Reference group
• Consensus building process, workshops and
  activities
• Infrastructure and device-related guidelines
  (chapter 5)
• 5.1 Managing quality of service and cost of
  connectivity
• 5.2 Internet access
• 5.3 Always-on, always on-line
• 5.4 Specialized UIs
• (Terminology, symbols and auditory signals)

19
3G/UMTS specifics addressed by the 3G work (in
DEG 202 972) (2/2)

• Guidelines for services, media and applications
  (chapter 6)
• 6.1 Data-intensive services and applications
• 6.2 Distributed, non-device-native (local and
  remote) UIs
• 6.3 Customization, personalization and
  operator-bundled packages
• 6.4 Services of public interest (societal
  services/ services to the public)
• 6.5 Mobile Internet development guidelines
• (Terminology, symbols and auditory signals)
• Guidelines for other (related) areas (chapter 7)
• 7.1 Application installation and software updates
• 7.2 Computer access
• 7.3 IMS-based application guidelines
• 7.4 3G-enabled accessibility applications
• 7.5 In-car use
• (Terminology, symbols and auditory signals)

20
UI design guidelines for connectivity issues

• Provide user support for finding the optimal
  connection (cost, speed, reliability).
• If an existing used connection is closed, provide
  the reason for this to the user.
• In roaming situations, explain to the user which
  network provides 3G bandwidth and data rates for
  Internet access.
• Each application should clearly indicate its
  connectivity options and on-line status at all
  times.
• Network changes should not require user
  involvement if there are no cost implications.
• Transmission efficiency should be considered
  (e.g. the use of compressed, lower-resolution
  pictures) and, when reasonable, optimized for the
  browser.
• If content cannot be displayed due to missing
  browser plug-ins this should be indicated to the
  user.
• If dedicated browsers are used (e.g for YouTube
  content), their limitations should be indicated
  to the user.

21
UI design guidelines for cost and data rate/QoS
issues

• The cost of using data-intensive applications
  should be made clear prior to the application
  being activated.
• The charging scheme for data transmission should
  be made clear to the user.
• Roaming charges should, to the largest possible
  extent, be indicated to the user.
• If an application depends on minimum data rates
  (e.g. location based information services) the
  available data rate should be indicated to the
  user and insufficient data rates should be
  clearly flagged.
• Functional application limitations due to roaming
  should be indicated to the user.
• All applications should degrade gracefully if
  the available data-rate decreases.
• An option for limiting cost of data transfer
  should be available at all times. User-controlled
  cancellation of data transfer when reaching this
  limit should be a standard feature of the device.
• Indicate if the available QoS does not support or
  is insufficient for usage of the intended
  service.
• Show the availability of networks in a way which
  helps users understand their QoS.
• Allow users to adjust QoS parameters in whatever
  way they wish (as long as it does not compromise
  basic applications such as voice call).
• Help users to make an informed choice of
  available networks by offering QoS and related
  cost information, such as special tarrifing.
• QoS should be shown in relation to the services
  that it enables, rather than in abstract forms.

22
UI design guidelines dealing with device
functionality and coordination issues

• Emergency call functionality should always be
  available and prioritized.
• Applications and services should still be useful
  to the user in off-line mode. If this is not
  possible the status of the applications should be
  communicated to the user
• Indicate delays caused by running parallel
  applications.
• Indicate delays caused by connection limitations
• Applications not available in off-line mode
  should be clearly marked.
• Indicate power consumption and remaining battery
  lifetime based on current estimates.
• Indicate if data may be unavailable in off-line
  mode.
• Mobile Web content should be mobileOK compliant

23
Sample UI design guidelines related to device
limitations

• Provide UI functionality for an overview and the
  zooming of pages larger than the available
  display.
• Ensure that controls for zooming and scrolling
  are always available to the user.
• Provide alternate means to navigate the data
  displayed on the device.
• Provide means to control data storage
  (local/remote).
• Clearly indicate where data is stored in the
  system.
• Ensure that software updates are not interrupted
  through network failures in unrecoverable failure
  mode.

24
UI design guidelines dealing with privacy issues
in 3G networks

• The security and protection status of a data
  connection should be displayed.
• External attempts to tamper with secure data
  connections should be indicated to the user.
• The user should always be in control of any
  access rights to sensitive and private data.
• Indicate unavailability of secure data connection
  to protected data.
• The reasons for unavailability of protected data
  connections should be indicated to the user.
• The user should be in control of which personal
  data is made available to other parties (e.g.
  location information of the device).

25
Thank you!

• QUESTIONS?
• msch_at_acm.org
• The work carried out here is co-financed by the
  EC/EFTA, in response to the ECs ICT
  Standardisation Work Programme.