1 / 25

Design Guidelines for Better 3G User Interfaces Matthias Schneider ETSI STF322 msch@acm

Design Guidelines for Better 3G User Interfaces Matthias Schneider ETSI STF322 msch@acm.org. Topics. ETSI The work of ETSI Specialist Task Force 322 Introduction Tasks Sample Guidelines

ivan
Download Presentation

Design Guidelines for Better 3G User Interfaces Matthias Schneider ETSI STF322 msch@acm

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design Guidelines for Better 3G User InterfacesMatthias Schneider ETSI STF322 msch@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 EC’s 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@acm.org The work carried out here is co-financed by the EC/EFTA, in response to the EC’s ICT Standardisation Work Programme.

More Related