Upload
lamnguyet
View
227
Download
0
Embed Size (px)
Citation preview
Engineering Universal Access:
Unified User Interfaces
UAHCI 2001 Tutorial
Constantine Stephanidis
Anthony Savidis Demosthenes Akoumianakis
Foundation for Research and Technology – Hellas Institute of Computer Science
Human-Computer Interaction and Assistive Technology Laboratory Science and Technology Park of Crete
Heraklion, Crete GR-71110, GREECE
Tel: +30-81-391741, Fax: +30-81-391740 {cs, as, demosthe}@ics.forth.gr
7 August 2001
UAHCI 2001 Page i Stephanidis, Savidis, Akoumianakis
Table of contents Agenda ii Instructors’ Biographies iii Course objectives v Abstract vi Slides Introduction to Unified User Interfaces 1
Universal access Coping with diversity Technical approaches Automatic user interface adaptation The concept of Unified User Interfaces
Designing to cope with diversity 58 Part I: Background
The design issue Understanding context
Part II: The unified design method Concepts Phases Techniques
Part III: Tools
Unified Interface Engineering 170 Unified Interface Architecture Adaptation Scenarios and control flow Unified Interface Architecture Component Analysis
Tools for developing Unified User interfaces 219 Introduction Metaphor Development Toolkit Integration Toolkit Augmentation Toolkit Expansion Toolkit Abstraction
Universal Access and the Web 264 Browsers as interface tools Platform diversity on the Web Automatic Web-page adaptation
Challenges and Future Work 289 Software development process Identifying diversity Designing for diversity Computing platforms and embedded OS Concluding remarks
UAHCI 2001 Page ii Stephanidis, Savidis, Akoumianakis
Agenda
When What
08.30 – 10.00 Introduction: Universal Access, Copying With Diversity, Technical Approaches
10.00 – 10:30 Morning Break
10:30 – 12:00 Unified user interface design
12:00 – 13:30 Lunch
13:30 – 14.00 Tools, examples, case studies
14:00 – 15:00 The unified user interface engineering
15:00 – 15:30 Afternoon Break
15:30 – 16:30 The unified user interface engineering (Cont.)
16:30 – 17:00 Discussion and Conclusions
UAHCI 2001 Page iii Stephanidis, Savidis, Akoumianakis
Instructors’ Biographies Constantine Stephanidis Constantine Stephanidis is Deputy Director and head of the Human-Computer Interaction and Assistive Technology Laboratory at the Institute of Computer Science, Foundation for Research and Technology – Hellas. He is also a member of the Faculty at the Department of Computer Science and member of the Senate of the University of Crete. For many years, he has been engaged, as Prime Investigator, in pioneering research work partly funded by the European Commission and in 1995 he introduced the concept of “User Interfaces for All” as a socio-technical goal in the context of the emerging Information Society. He has published about 200 technical papers in scientific archival journals and proceedings of international conferences related to his fields of expertise. He serves in the Editorial Board of several scientific journals and the Programme Committee of many International Conferences, and has organized international scientific conferences, workshops, seminars, and panels. Prof. Stephanidis is the Editor-in-Chief of the Springer international journal “Universal Access in the Information Society” and the Editor of the LEA book “User Interfaces for All – Concepts, Methods and Tools”. He is the Founding Chair of the International Conference “Universal Access in Human-Computer Interaction”, Founder of the ERCIM Working Group “User Interfaces for All” and General Chair of its annual Workshop, Founder and Chair of the International Scientific Forum “Towards an Information Society for All”, and the project manager of the European Commission funded Thematic Network “Information Society for All” (IS4ALL). Prof. Stephanidis is member of the Executive Committee and of the Board of Editors of the European Research Consortium for Informatics and Mathematics (ERCIM), member of the Advisory Committee of the World Wide Web Consortium (W3C), head of the W3C Office in Greece, and participant in the activities the W3C - Web Accessibility Initiative. Anthony Savidis Anthony Savidis has a B.Sc. in Computer Science, an M.Sc. in Information Systems and Software Engineering, and a Ph.D. in User Interface Development Tools. He is a member of the Human- Computer Interaction and Assistive Technology Laboratory at the Institute of Computer Science, Foundation for Research and Technology – Hellas since 1989, and has been involved in various European collaborative Research and Development projects including: HELIOS-HANDYNET, RACE IPSNI R1066, TIDE GUIB TP103, TIDE GUIB-II TP215, TIDE ACCESS TP1001, and ACTS AVANTI AC042. He is the chief designer / developer of the HOMER UIMS for building Dual User Interfaces, the COMONKIT interface toolkit for Rooms-based non-visual interfaces, the PIM tool for open toolkit integration, and the I-GET UIMS for implementing Unified User Interfaces, the SCANLIB switch-based augmented Windows library, and the HAWK non-visual toolkit supporting open metaphor realisation. His research interest focus on interface implementation languages, development processes and architectures, and interface toolkits for diverse users and computing platforms. Demosthenes Akoumianakis Demosthenes Akoumianakis received a B.Sc. (Hons) in Computing in Business, and he was the recipient of the 1st IBM Prize Award for his Final Year Undergraduate Dissertation. He also received an M.Sc. in HCI on design environments for user adaptable interfaces, and a Ph.D. in HCI on ‘Knowledgeable’ Tools for Evolving HCI Design - Theory and Practice. Since 1993, he is a member of the Human-Computer Interaction and Assistive Technology Laboratory at the Institute of Computer Science, Foundation for Research and Technology - Hellas. Demosthenes Akoumianakis has been involved in several European collaborative Research and Development projects, including TIDE-CORE TP126 and TIDE-CORE TP213, the TIDE-HEART study TP309, TIDE-ACCESS
UAHCI 2001 Page iv Stephanidis, Savidis, Akoumianakis
TP1001, ACTS-AVANTI AC042, and the DE4105 -WAI (Web Accessibility Initiative). Demosthenes Akoumianakis has co-authored many publications and articles in international archival scientific journals and referred conference proceedings in the fields of Human-Computer Interaction and Assistive Technology, and has co-presented tutorials at HCI International ’97 and HCI International ’99. He is member of ACM, member of the Programme Committee and reviewer for the International Conference on Computer-Aided Design of User Interfaces (CADUI), the International Conference on Universal Access in Human-Computer Interaction (UAHCI), the International Workshop on Tools for Working with Guidelines (TFWWG2000) and the World Multi-conference on Systemics, Cybernetics and Informatics (SCI’2000/ISAS2000). Demosthenes Akoumianakis has served as the secretary of the International Scientific Forum “Towards an Information Society for All”. His current research interests focus on methodologies, design support environments and tools for universal access and adaptable and adaptive user interfaces.
UAHCI 2001 Page v Stephanidis, Savidis, Akoumianakis
Objectives of the course Attendees of this tutorial will be introduced to:
• Universal access as the conscious and systematic effort to proactively apply principles, methods and tools for universal design, in order to develop user interfaces that are accessible and usable by anybody, anywhere, at anytime.
• The dimensions of diversity, which are intrinsic to the emerging Information Society, and create the requirement for universal access.
• The need for principled and systematic approaches towards accommodating diversity in the user- and usage- context of interactive products, applications and services.
• The concept of Unified User Interfaces and the Unified User Interface development process as an effective engineering approach integrating and applying the principles and practice of universal design for the development of universally accessible and usable user interfaces.
• Adaptation in the context of Unified User Interfaces. • The need to employ appropriate tools and a corpus of related tool requirements. • An analysis of the appropriateness of the World Wide Web as a platform for facilitating
universal access. • Future challenges for Universal Access in the Information Society.
UAHCI 2001 Page vi Stephanidis, Savidis, Akoumianakis
Abstract Universal access refers to the conscious and systematic effort to proactively apply principles, methods and tools for Universal Design, in order to develop user interfaces that are accessible and usable by anybody, anywhere, at anytime. The requirement for universal access stems from the growing impact of the fusion of the emerging technologies, and from the different dimensions of diversity, which are intrinsic to the Information Society. These dimensions become evident when considering the broad range of user characteristics, the changing nature of human activities, the variety of contexts of use, the increasing availability and diversification of information and knowledge sources and services, the proliferation of technological platforms, etc. Unified User Interfaces have been conceived as a means of accommodating the interaction requirements of the broadest possible end-user population. The Unified User Interface development process conveys a new perspective on the development of user interfaces by providing a principled and systematic approach towards accommodating diversity in the user- and usage- context of interactive products, applications and services. Unified User Interfaces provide a concrete insight into how the principles of universal design can shape prevailing HCI design and development practices so that the range and scope of interactive experiences offered to the end-users are tailored to their individual requirements and expectations. This tutorial introduces the concept of Unified User Interfaces and the Unified User Interface development process, elaborating some of its distinctive properties that render it an effective approach for the development of universally acceptable and usable user interfaces. The most important of these properties is the capability of self-adapting interactive behaviour. The tutorial unfolds the challenges of the Unified User Interface development process, comparing it with currently adopted practices to implementing interactive software, and explaining how this new process integrates and applies the principles and practice of universal design in the user interface development life-cycle. The development of Unified User Interfaces is viewed as a multidisciplinary process, and is elaborated through examples and demonstrations. Particular emphasis is given to the need for combining a range of complementary perspectives, including design methods and techniques, component technologies, interface toolkits and programming. The Unified User Interface design method is presented as a design technique capable of capturing into a single design representation the different design patterns reflecting user- and usage-context- diversity. The Unified User Interface implementation method is presented through incrementally revealing a new distributed architectural framework, along with an engineering strategy for structuring the implementation. The need to employ appropriate tools along the way is identified, and a corpus of tool requirements is established. Tool requirements reflect the needs for metaphor development, and toolkit integration, augmentation, abstraction and expansion. The tutorial also includes a brief discussion of the appropriateness of the World Wide Web as a platform for facilitating accessible and high-quality interaction. Finally, the tutorial identifies some challenging design and implementation issues, requiring further research efforts, and draws some conclusions regarding the contribution of the Unified User Interface Development framework towards Universal Access and Usability in the field of Human-Computer Interaction.
Stephanidis, Savidis, AkoumianakisPage 1UAHCI 2001
ICS-FORTH Slide 1
Engineering Universal Access: Unified User Interfaces
Constantine Stephanidis,Anthony Savidis,
Demosthenes Akoumianakis
HumanHuman--Computer Interaction and Computer Interaction and Assistive Technology LaboratoryAssistive Technology Laboratory
@ ICS@ ICS--FORTHFORTH
ICS-FORTH Slide 2Stephanidis, Savidis & Akoumianakis
Tutorial agenda
Introduction to Unified User InterfacesUnified User Interface DevelopmentUniversal Access and the WebChallenges and Future Work
Stephanidis, Savidis, AkoumianakisPage 2UAHCI 2001
ICS-FORTH Slide 3Stephanidis, Savidis & Akoumianakis
Introduction to Unified User Interfaces - agenda
Universal accessCoping with diversityTechnical approachesAutomatic user interface adaptationThe concept of Unified User Interfaces
ICS-FORTH Slide 4Stephanidis, Savidis & Akoumianakis
Information Society or Digital Age
• Interactive software applications and services for– Anyone - variety in user profiles– Anywhere and Anytime - variety in
contexts of use– Any purpose - variety in tasks
Stephanidis, Savidis, AkoumianakisPage 3UAHCI 2001
ICS-FORTH Slide 5Stephanidis, Savidis & Akoumianakis
Universal Access in the Information Society (1/2)
The right of all citizens to obtain and maintain access to a society-wide pool of information resources and interpersonal communicationfacilities, given the varieties of contexts of use
ICS-FORTH Slide 6Stephanidis, Savidis & Akoumianakis
Universal Access in the Information Society (2/2)
Design for AllDesign for All
Accommodating DiversityAccommodating Diversity
PCPC TVTVKiosksKiosks MobileMobile
phonesphones
CommunicationCommunicationprotocolsprotocols WebWeb SatelliteSatellite
linkslinksBandwidthBandwidth
WorkWorkEntertainmentEntertainment
EducationEducation SocialSocial Application Domain &Services Level
TelecommunicationsInfrastructure
User InterfaceLevel
HealthcareHealthcare
Stephanidis, Savidis, AkoumianakisPage 4UAHCI 2001
ICS-FORTH Slide 7Stephanidis, Savidis & Akoumianakis
HCI for Universal Access
• AccessibilityFor each task, there is a sequence of accessible input actions and associated feedback leading to successful accomplishment
• High-qualityFor any individual user in a particular context of use, there is at least one path that optimally supports the accomplishment of the given task
ICS-FORTH Slide 8Stephanidis, Savidis & Akoumianakis
Accessibility vs Interaction Quality (1/5)
• Accessibility– Dictates support for alternative I/O
• Quality– Dictates support for alternative designs
Stephanidis, Savidis, AkoumianakisPage 5UAHCI 2001
ICS-FORTH Slide 9Stephanidis, Savidis & Akoumianakis
Accessibility vs Interaction Quality (2/5)
The same user may require different access and interaction quality attributes for performing a single task depending on the context of use
ICS-FORTH Slide 10Stephanidis, Savidis & Akoumianakis
Accessibility vs Interaction Quality (3/5)
• While driving– Driver is “situationally” motor- and visually-
impaired• minimum attention, simple dialogues,
speech, etc.
• In a noisy environment– User is “situationally” deaf
Stephanidis, Savidis, AkoumianakisPage 6UAHCI 2001
ICS-FORTH Slide 11Stephanidis, Savidis & Akoumianakis
Accessibility vs Interaction Quality (4/5)
• Low interaction quality may reduceaccessibility– What can I do ? User tasks– How can I do it ? Action sequences– What is this ? Artifact interpretation– Where am I ? Context clarity
ICS-FORTH Slide 12Stephanidis, Savidis & Akoumianakis
Accessibility vs Interaction Quality (5/5)
– Even with a “physically” accessible interface, a particular user may be unable to carry out an interaction task
– What is “good design” for one user, may be a “bad design” for another
– Pursuing a single optimal design for everyone is a utopia
Stephanidis, Savidis, AkoumianakisPage 7UAHCI 2001
ICS-FORTH Slide 13Stephanidis, Savidis & Akoumianakis
Introduction to Unified User Interfaces - agenda
Universal access
Coping with diversityTechnical approachesAutomatic user interface adaptationThe concept of Unified User Interfaces
ICS-FORTH Slide 14Stephanidis, Savidis & Akoumianakis
Universal Access = Coping with Diversity
• User profiles– Age, cultural / educational background, mental /
sensory / motor skills, specific purpose of use, etc
• Contexts of use– Environment (e.g., noise, terminal position,
lighting)– Technological platform (e.g., presence or absence
of particular I/O devices, network bandwidth, etc)
Stephanidis, Savidis, AkoumianakisPage 8UAHCI 2001
ICS-FORTH Slide 15Stephanidis, Savidis & Akoumianakis
Diversity in users
ICS-FORTH Slide 16Stephanidis, Savidis & Akoumianakis
Diversity in contexts of use (1/2)
Stephanidis, Savidis, AkoumianakisPage 9UAHCI 2001
ICS-FORTH Slide 17Stephanidis, Savidis & Akoumianakis
Diversity in contexts of use (2/2)
– Car– Airplane– Ship– Hospital– Factory floor– Office– School
ICS-FORTH Slide 18Stephanidis, Savidis & Akoumianakis
Introduction to Unified User Interfaces - agenda
Universal accessCoping with diversity
Technical approachesAutomatic user interface adaptationThe concept of Unified User Interfaces
Stephanidis, Savidis, AkoumianakisPage 10UAHCI 2001
ICS-FORTH Slide 19Stephanidis, Savidis & Akoumianakis
Technical Approaches for Universal Access
•Reactive– Applying modifications and introducing add-ons
over existing technology, to overcome technology-driven accessibility and interaction quality problems
•Proactive– Systematically catering for accessibility and
interaction quality from the early phases of design and throughout the development life-cycle
ICS-FORTH Slide 20Stephanidis, Savidis & Akoumianakis
Reactive methods (1/3)
Configuration of I/O– Binding of input sequences
• shortcuts, accelerators– Device fine-tuning
• mouse keyboard sensitivity, sticky keys– Display control
• styles, colours, layout
Stephanidis, Savidis, AkoumianakisPage 11UAHCI 2001
ICS-FORTH Slide 21Stephanidis, Savidis & Akoumianakis
Reactive methods (2/3)
Accessibility add-ons– Accessibility technologies (Java / Active
Accessibility)• SDKs to retrieve display structure, and
externally manipulate interaction controls
– Alternative access systems• screen reader, virtual keyboard / mouse
ICS-FORTH Slide 22Stephanidis, Savidis & Akoumianakis
Reactive methods (3/3)
Application of accessibility guidelinesto modify existing inaccessible systems
Stephanidis, Savidis, AkoumianakisPage 12UAHCI 2001
ICS-FORTH Slide 23Stephanidis, Savidis & Akoumianakis
Proactive methods (1/2)
• A new engineering paradigm• Systems accessible by design
– Application of accessibility guidelines– Appropriate development tools
• There is a need for new commercially availabletoolkits supporting accessible interaction elements
– Software I/O control in new computing platforms
ICS-FORTH Slide 24Stephanidis, Savidis & Akoumianakis
Proactive methods (2/2)
• What about Java Pluggable Look&Feel ?A generalisation API over windowing controls, enabling visual style to be altered
• Still rectangular geometry, visual attributes, mouse & keyboard navigation, layout-based instance hierarchy
• X Windows / Xt, X Attribute Defaults, except run-time style switching capability and audio feedback support
Stephanidis, Savidis, AkoumianakisPage 13UAHCI 2001
ICS-FORTH Slide 25Stephanidis, Savidis & Akoumianakis
Reactive vs Proactive methods (1/3)
• Reactive– Lower interaction quality – modifications
instead of alternative designs
• Proactive– Higher interaction quality – alternative
designs adapted to user and context attributes
ICS-FORTH Slide 26Stephanidis, Savidis & Akoumianakis
Reactive vs Proactive methods (2/3)
• Reactive– Many dialogues cannot be reproduced
(appropriately modified), hence some applications or application parts can not be made accessible
• Proactive– All dialogue scenarios can be implemented– Applications are explicitly designed and developed
for accessibility
Stephanidis, Savidis, AkoumianakisPage 14UAHCI 2001
ICS-FORTH Slide 27Stephanidis, Savidis & Akoumianakis
Reactive vs Proactive methods (3/3)
• Reactive– Relatively cheap, and may quickly provide
some sort of accessible interaction
• Proactive– Relatively expensive initial overhead
ICS-FORTH Slide 28Stephanidis, Savidis & Akoumianakis
Introduction to Unified User Interfaces - agenda
Universal accessCoping with diversityTechnical approaches
Automatic user interface adaptationThe concept of Unified User Interfaces
Stephanidis, Savidis, AkoumianakisPage 15UAHCI 2001
ICS-FORTH Slide 29Stephanidis, Savidis & Akoumianakis
Automatic User Interface Adaptation (1/9)
Feedback on operationFeedback on operationcompletion (completion (here, here,
bookmark additionbookmark addition) )
Links presented Links presented as buttonsas buttonsLink enumerationLink enumeration
and structureand structureoverview paneoverview pane
ICS-FORTH Slide 30Stephanidis, Savidis & Akoumianakis
Automatic User Interface Adaptation (2/9)
Interaction for motorInteraction for motor--impaired: automatically impaired: automatically
scanned window scanned window manipulation toolbarmanipulation toolbar
Interaction for motorInteraction for motor--impaired: automatically impaired: automatically scanned HTML elementsscanned HTML elements(including image(including image--maps)maps)Interaction for motorInteraction for motor--
impaired: all GUI objectsimpaired: all GUI objectsaccessible through accessible through automatic scanningautomatic scanning
Stephanidis, Savidis, AkoumianakisPage 16UAHCI 2001
ICS-FORTH Slide 31Stephanidis, Savidis & Akoumianakis
Automatic User Interface Adaptation (3/9)
Interaction for motorInteraction for motor--impaired: keyboardimpaired: keyboardlayouts that speedlayouts that speedup interaction (e.g.up interaction (e.g.by following letterby following letter--frequency criteria)frequency criteria)
Interaction for motorInteraction for motor--impaired: onimpaired: on--screenscreen
keyboard for text inputkeyboard for text input
ICS-FORTH Slide 32Stephanidis, Savidis & Akoumianakis
Automatic User Interface Adaptation (4/9)
Adapting to the Adapting to the context of use: context of use:
kiosk mode kiosk mode operationoperation
Stephanidis, Savidis, AkoumianakisPage 17UAHCI 2001
ICS-FORTH Slide 33Stephanidis, Savidis & Akoumianakis
Automatic User Interface Adaptation (5/9)
The interface’s responseThe interface’s responseto the detection of the factto the detection of the fact
that the user seems incapablethat the user seems incapableto complete the task of selectingto complete the task of selecting
a link from the “Link Bar” a link from the “Link Bar”
ICS-FORTH Slide 34Stephanidis, Savidis & Akoumianakis
Automatic User Interface Adaptation (6/9)
A simple dialog from whichA simple dialog from whichthe user selects and loadsthe user selects and loads
previously visited documents...previously visited documents...
Stephanidis, Savidis, AkoumianakisPage 18UAHCI 2001
ICS-FORTH Slide 35Stephanidis, Savidis & Akoumianakis
Automatic User Interface Adaptation (7/9)
... gets converted to the... gets converted to thesame dialogue with integratedsame dialogue with integratedguidance, if the user seems toguidance, if the user seems to
be unable to comprehend be unable to comprehend its use.its use.
ICS-FORTH Slide 36Stephanidis, Savidis & Akoumianakis
Automatic User Interface Adaptation (8/9)
• User awareness– User-oriented information / knowledge
• Usage-context awareness– Context-oriented information / knowledge
Stephanidis, Savidis, AkoumianakisPage 19UAHCI 2001
ICS-FORTH Slide 37Stephanidis, Savidis & Akoumianakis
Automatic User Interface Adaptation (9/9)
• Sources of knowledge– Knowledge which is made available or can
be inferred prior to initiation of an interaction session (off-line)
– Knowledge which can be only inferred by analysing interaction monitoring information (on-line)
ICS-FORTH Slide 38Stephanidis, Savidis & Akoumianakis
Two Types of Interface Adaptation
• Adaptability• Adaptivity
Differentiate according to the type of knowledge employed in performing adaptation
Stephanidis, Savidis, AkoumianakisPage 20UAHCI 2001
ICS-FORTH Slide 39Stephanidis, Savidis & Akoumianakis
Adaptability - Definition
Interface adaptation applied on the basis of off-line knowledge
Applied before initiation of interaction to deliver an accessible and high-quality user interface
ICS-FORTH Slide 40Stephanidis, Savidis & Akoumianakis
Adaptability - Properties
• User- and context- attributes are considered known off-line
• An appropriate design is selected for the end-user, and the given usage-context
• Adaptability takes place before interaction is initiated
• Adaptability realises an accessible interface
Stephanidis, Savidis, AkoumianakisPage 21UAHCI 2001
ICS-FORTH Slide 41Stephanidis, Savidis & Akoumianakis
Adaptivity - Definition
Interface adaptation applied on the basis of on-line knowledge
Applied during interaction, aiming to enhance the initially delivered user interface
ICS-FORTH Slide 42Stephanidis, Savidis & Akoumianakis
Adaptivity - Properties
• User- and context- attributes are dynamically inferred on-line
• The design already chosen for the end-user and the given usage-context is enhanced
• Adaptivity takes place after interaction is initiated
• Adaptivity requires an accessible interface
Stephanidis, Savidis, AkoumianakisPage 22UAHCI 2001
ICS-FORTH Slide 43Stephanidis, Savidis & Akoumianakis
Adaptivity and Adaptability -Complementary Roles
user 1 user N
Automaticallyadaptedinterface
interfaceinstance 1
interfaceinstance N
Adaptability -provide initial interface
user i
interfaceinstance 1
context 1 context N context i
Adaptivity -continuously enhance
ICS-FORTH Slide 44Stephanidis, Savidis & Akoumianakis
Introduction to Unified User Interfaces - agenda
Universal accessCoping with diversityTechnical approachesAutomatic user interface adaptation
The concept of Unified User Interfaces
Stephanidis, Savidis, AkoumianakisPage 23UAHCI 2001
ICS-FORTH Slide 45Stephanidis, Savidis & Akoumianakis
Unified User Interfaces (1/3)
End-User view– A user interface tailored to individual user
attributes and to the particular context of use
ICS-FORTH Slide 46Stephanidis, Savidis & Akoumianakis
Unified User Interfaces (2/3)
Design view– A user interface design populated with
polymorphic artifacts, i.e., encompassing alternative dialogue artifacts• each alternative artifact addresses
specific user- and usage-context-parameter values
Stephanidis, Savidis, AkoumianakisPage 24UAHCI 2001
ICS-FORTH Slide 47Stephanidis, Savidis & Akoumianakis
Unified User Interfaces (3/3)
Engineering view– A repository of implemented dialogue
artifacts, out of which the most appropriate are selected at run-time • decision making is needed to select
the appropriate interaction artifacts given the end-user- and usage-context-attribute values
ICS-FORTH Slide 48Stephanidis, Savidis & Akoumianakis
Unified User Interface - Definition
• A user interface self-adapting to user- and usage-context, encompassing– Alternative implemented dialogue artifacts– User- and context- information– Decision making capability selecting user-
and context- appropriate dialogue artifacts– Interface control to apply decisions made
Stephanidis, Savidis, AkoumianakisPage 25UAHCI 2001
ICS-FORTH Slide 49Stephanidis, Savidis & Akoumianakis
Levels of Adaptation in UnifiedUser Interfaces
semantic
syntactic
constructional
physical
internal functionality, information represented
dialogue sequencing, syntactic rules, user tasks
devices, object attributes, interaction techniques
ICS-FORTH Slide 50Stephanidis, Savidis & Akoumianakis
Polymorphism in Unified User Interfaces (1/6)
• Automatic adaptation at any level implies the ability to polymorphose– i.e., for a given task, design alternative
interactive artifacts according to different user- and usage-context- attribute values
Stephanidis, Savidis, AkoumianakisPage 26UAHCI 2001
ICS-FORTH Slide 51Stephanidis, Savidis & Akoumianakis
Polymorphism in Unified User Interfaces (2/6)
• Lexical polymorphism– construction of the physical design domain– design properties space
• I/O devices• interaction techniques• interaction objects and their attributes
ICS-FORTH Slide 52Stephanidis, Savidis & Akoumianakis
Polymorphism in Unified User Interfaces (3/6)
AcousticAcousticFile nameFile nameFile nameFile nameFile nameFile name
File :File :DeskDesk--toptop
File nameFile name
DELETEDELETE
““target”target”
CartoonCartoon
““Delete”Delete”
““file name”file name”
DeleteDelete
Example of lexical polymorphism
Stephanidis, Savidis, AkoumianakisPage 27UAHCI 2001
ICS-FORTH Slide 53Stephanidis, Savidis & Akoumianakis
Polymorphism in Unified User Interfaces (4/6)
• Syntactic Polymorphism (task-structure differentiation)– sequences of user actions– initiation / interim / completion feedback– availability of operations and interaction
progress preconditions– multiple views and direct manipulation
ICS-FORTH Slide 54Stephanidis, Savidis & Akoumianakis
Polymorphism in Unified User Interfaces (5/6)
delete file = define file before delete commanddefine file = provide name or select directly
delete a file
define_file delete_command
provide_name provide_directly
before
parallel
Example of syntactic polymorphism
Stephanidis, Savidis, AkoumianakisPage 28UAHCI 2001
ICS-FORTH Slide 55Stephanidis, Savidis & Akoumianakis
Polymorphism in Unified User Interfaces (6/6)
delete file = define file before delete commanddefine file = select targetdelete command = activate
delete a file
define_file delete_command
select_target activate
before
Example of syntactic polymorphism (cont.)
ICS-FORTH Slide 56Stephanidis, Savidis & Akoumianakis
Summarising on Unified User Interfaces (1/2)
• Automatic User Interface Self-Adaptation
• User- and usage-context- attribute driven
• Implies polymorphism potentially at lexical, syntactic and semantic levels
Stephanidis, Savidis, AkoumianakisPage 29UAHCI 2001
ICS-FORTH Slide 57Stephanidis, Savidis & Akoumianakis
Summarising on Unified User Interfaces (2/2)
• There is a need for a new development process– Design process– Implementation architecture– Engineering process
• There is a need for new development tools– Capabilities / functionality– Assessment, availability, and suggestions
ICS-FORTH Slide 58
Designing to cope with diversityConcepts and Principles
Stephanidis, Savidis, AkoumianakisPage 30UAHCI 2001
ICS-FORTH Slide 59Stephanidis, Savidis & Akoumianakis
Plan
• Part I: Background– The design issue– Understanding context
• Part II: The unified design method– Concepts– Phases– Techniques
• Part III: Tools
ICS-FORTH Slide 60
Part I: BackgroundThe design issue
Understanding context
Stephanidis, Savidis, AkoumianakisPage 31UAHCI 2001
ICS-FORTH Slide 61Stephanidis, Savidis & Akoumianakis
The notion of context
• Context refers to the parameters whichshape and influence the execution of a task– user condtition, requirements and abilities– technological platform (terminal, bandwidth,
etc)– usage context (desktop, mobile, ubiqutous, etc)
ICS-FORTH Slide 62Stephanidis, Savidis & Akoumianakis
The research question
• Understanding context– Ethnographically-inspired inquiries– Scenarios
• Modelling context– User modelling techniques– Context modelling
• Accounting for context variety– Adaptable and adaptive interaction
Stephanidis, Savidis, AkoumianakisPage 32UAHCI 2001
ICS-FORTH Slide 63Stephanidis, Savidis & Akoumianakis
HCI and the study of context
• Traditionally, a hard issue for HCI design– Assumptions about:
• average «typical» users, • the device is typically a desktop PC• the context of use was the business environment
– Methodoliogical focus on:• productivity enhancement• how tasks should be carried out rather than how
they are being carried out– Keystrokes as unit for studying interaction
ICS-FORTH Slide 64Stephanidis, Savidis & Akoumianakis
Reality is different ...
• Diversity regarding– the users operating computational devices– the type of devices– the context of use– the type, nature and scope of tasks– etc
Stephanidis, Savidis, AkoumianakisPage 33UAHCI 2001
ICS-FORTH Slide 65Stephanidis, Savidis & Akoumianakis
Coping with diversity
• To allow for deviation such a model of HCI introduced the notion of adaptation to cope with unforeseen events
• Originally, it was the user that was required to adapt
UserUser
MachineMachine
AdaptationAdaptation
ICS-FORTH Slide 66Stephanidis, Savidis & Akoumianakis
Coping with diversity (Cont.)
• Progressively, the device obtained the computational power to exhibit adaptations
AdaptationAdaptation
UserUserMachineMachineUserModel
DesignerDesigner
AdaptationAdaptation
Stephanidis, Savidis, AkoumianakisPage 34UAHCI 2001
ICS-FORTH Slide 67Stephanidis, Savidis & Akoumianakis
The prevalent methods devised
• Adaptable interfaces– customising– tailoring
• User modelling– explicit models of user behaviour
• Adaptive interfaces– run-time modifications of dialogue
• Intelligent interfaces– systems that exhibit human-like behaviour
ICS-FORTH Slide 68Stephanidis, Savidis & Akoumianakis
Adaptable interfaces: Taloringaspects of interaction
Stephanidis, Savidis, AkoumianakisPage 35UAHCI 2001
ICS-FORTH Slide 69Stephanidis, Savidis & Akoumianakis
User modelling
• Explicit representation of user’s personalinformation such as domain knowledge, beliefs, preferences, interests, etc.
• Several approaches– Overlay models– Embedded user models– User modelling shells– User modelling servers
ICS-FORTH Slide 70Stephanidis, Savidis & Akoumianakis
Adaptive interfaces
Stephanidis, Savidis, AkoumianakisPage 36UAHCI 2001
ICS-FORTH Slide 71Stephanidis, Savidis & Akoumianakis
Intelligent user interfaces
• Systems exhibiting human-likebehaviour– Model-based approaches– Agents– Adaptive interaction
ICS-FORTH Slide 72Stephanidis, Savidis & Akoumianakis
The problem today
• The Information Society has invalidated many of the original assumptions which shaped progress in the field– the user is no longer a tractable element to be studied
in a laboratory– the device is no longer the traditional PC with a
keyboard, mouse and a VDU– the context of use is no longer bound to the business
environment
Stephanidis, Savidis, AkoumianakisPage 37UAHCI 2001
ICS-FORTH Slide 73Stephanidis, Savidis & Akoumianakis
Furthermore
• Interaction remains complex and multi-faceted phenomenon
• Its social dimension adds to the complexity
ICS-FORTH Slide 74Stephanidis, Savidis & Akoumianakis
Consequently ...
• Keystrokes can no longer provide an informative unit for the study of interaction
• The field is in search of– more adequate theoretical frames of reference, thus the
shift towards developmental sciences– richer development frameworks, thus recent proposal
for tangible interfaces, embodied interfaces, disappearing computers
– novel evaluation perspectives, thus the claims for co-operative evaluation, participatory design
Stephanidis, Savidis, AkoumianakisPage 38UAHCI 2001
ICS-FORTH Slide 75Stephanidis, Savidis & Akoumianakis
The Need
• Capture global execution context of a task
• Task execution context is dictated by– user abilities and preferences– technological platform– context-of-use
• Lack of suitable methods
ICS-FORTH Slide 76
Part II: The unified design methodConcepts
PhasesTechniques
Stephanidis, Savidis, AkoumianakisPage 39UAHCI 2001
ICS-FORTH Slide 77Stephanidis, Savidis & Akoumianakis
What is a method?
• HCI literature reports on a plethora ofmethods– micro-level– macro-level
• According to (Olson and Moran, 1996) a complete method comprises– a statement of the problem it aims to addreess– a device (technique, tool or represetantion)– a procedure for using the device– a clear set of outcomes
ICS-FORTH Slide 78Stephanidis, Savidis & Akoumianakis
Unified design method
• Problem statement– Develop a representation of the global execution context
of a task
• Device– Polymorphic task decomposition
• Procedure– Enumerate - Abstract - Rationalise cycles
• Outcomes– Polymorphic task hierachy– Styles and accompanying design rationale
Stephanidis, Savidis, AkoumianakisPage 40UAHCI 2001
ICS-FORTH Slide 79Stephanidis, Savidis & Akoumianakis
Task Execution Context
• An execution context refers to how a task is to be accomplished by a user U, using an interaction device P in a specified context of use C
• Traditional design techniques assume– “Average” or typical user– Desktop platform– Business-oriented usage
ICS-FORTH Slide 80Stephanidis, Savidis & Akoumianakis
Relaxing the assumptions …
• The “typical” user assumption– anybody
• The desktop platform assumption– anywhere
• The business-oriented use assumption– anytime
Stephanidis, Savidis, AkoumianakisPage 41UAHCI 2001
ICS-FORTH Slide 81Stephanidis, Savidis & Akoumianakis
Implications
• A single design no longer suffices• A task could have multiple
interactive manifestations• Design space becomes complex
– Enumeration (of design alternatives)– Representation– Rationalization
ICS-FORTH Slide 82Stephanidis, Savidis & Akoumianakis
Consequently …
• We need new design methods– Cope with diversity– Guide designers through a structured
process – Orthogonal to existing design practices
• Unified design is a solution
Stephanidis, Savidis, AkoumianakisPage 42UAHCI 2001
ICS-FORTH Slide 83Stephanidis, Savidis & Akoumianakis
Unified design is a complete micro-method
• ProblemTo capture and represent in a unified design-structure all the alternative dialogue artefacts
• Device Polymorphic task hierarchies
• ProcessAbstract task definition with incremental polymorphicphysical specialisation
• OutcomePolymorphic task modelDesign artefactsRecorded rationale for
alternative design patterns
ICS-FORTH Slide 84Stephanidis, Savidis & Akoumianakis
Polymorphic task decomposition
• A technique which has the following properties:– Hierarchical structure– Root represents reusable design patterns– Non-root nodes are contextually bound instances of a
design abstraction– Leaf nodes represent concrete interaction components
• Each alternative decomposition is called a decomposition style, shortly a style
Stephanidis, Savidis, AkoumianakisPage 43UAHCI 2001
ICS-FORTH Slide 85Stephanidis, Savidis & Akoumianakis
Styles
• User interface as a compistion of styles• Styles can be analysed through any other
appropriate design method– Heuristics, – GOMS analysis,– Traditional HTA,– UAN, – Formal specifications
style 1 style n
Task 1
polymorphism
Task 11 1Task 1n 1
decomposition
ICS-FORTH Slide 86Stephanidis, Savidis & Akoumianakis
An example
DeleteFile
DirectManipulation
SelectFile Select
DeleteSelect
File SelectDelete Confirm
Delete
before before before
scanning visual non-
visu
allis
tbox
Modaldialogue
Stephanidis, Savidis, AkoumianakisPage 44UAHCI 2001
ICS-FORTH Slide 87Stephanidis, Savidis & Akoumianakis
In other words
• Styles correspond to execution contexts• Execution contexts are defined by the triad
<User profile, Platform, Context >
• A style should be designed so as to facilitate specific task execution context(s)
• A particular style may be good enough for an execution context but totally inappropriate for another
ICS-FORTH Slide 88Stephanidis, Savidis & Akoumianakis
Style: Interactive File icons
f1.txtf1.txt
f2.txtf2.txta1.txta1.txt
a2.txta2.txt
Stephanidis, Savidis, AkoumianakisPage 45UAHCI 2001
ICS-FORTH Slide 89Stephanidis, Savidis & Akoumianakis
Style: Command line
C:\ del f1.txt
ICS-FORTH Slide 90Stephanidis, Savidis & Akoumianakis
Style: Interactive Directory Tree
Stephanidis, Savidis, AkoumianakisPage 46UAHCI 2001
ICS-FORTH Slide 91Stephanidis, Savidis & Akoumianakis
Style relationships
C:\ del f1.txt commandline
f1.txtf1.txt
f2.txtf2.txta1.txta1.txt
a2.txta2.txt
interactivedirectory tree
interactivefile icons augmentation
compatibility
compatibility
ICS-FORTH Slide 92Stephanidis, Savidis & Akoumianakis
Styles definition
• New styles may be generated– By unfolding established patterns and
implementing corresponding artefacts (c.f. styles for deleting a file)
– By re-engineering arteacts
Stephanidis, Savidis, AkoumianakisPage 47UAHCI 2001
ICS-FORTH Slide 93Stephanidis, Savidis & Akoumianakis
Artefact re-engineering
• Assumes the availability of an artefact
• Requires competence in using abstraction
abstractionsidentified
physicalscenario
higher-leveldesign scenario
3
2
1 rolesrolesassignedassigned
instance ofinstance of
filter via role-based
model
ICS-FORTH Slide 94Stephanidis, Savidis & Akoumianakis
For each style ...
• Develop suitable argumentation for each style– Why does it exist ?– What issue does it support ?– When should it be initiated ?– Where is it implemented ?– How does it compare against competing styles
Stephanidis, Savidis, AkoumianakisPage 48UAHCI 2001
ICS-FORTH Slide 95Stephanidis, Savidis & Akoumianakis
Process
ScenariosTask analysisEnvisioningScreening modelsAnalytical HCI methods
Design templatesAbstract Objects
GuidelinesEngineering modelsHuman factors experimentsDesign space analysisIssue-based analysisClaims analysis
Abstract
Enumerate
Rationalise
Iterative process
ICS-FORTH Slide 96Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise
• An argumentative process:– Reflection on action
• Identify existing tasks and how they are performed• Assess break downs in existing task structures
– Creative stage• Set filters (or questions) which describe the breakdown
– User questions (e.g. how is the product use by a blind user?)– Platform questsions (e.g. how is the task executed on a portable
device?)– Context questions (e.g. how can the task be executed away from
the desktop?) • Develop proposals for envisioned task structures
Stephanidis, Savidis, AkoumianakisPage 49UAHCI 2001
ICS-FORTH Slide 97Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise Techniques used
• Observation which reveals patterns and artefacts in use
• Task analysis in cases where a “system” is already available
• Envisioning and rapid prototyping to assess with users likely options
• Other formative techniques which reveal artefacts and patterns of use (e.g., scenarios)
ICS-FORTH Slide 98Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise An example scenario
XXX has just completed an order for several pharmaceuticals items. The on-line pharmacy store requests XXX to enter the credit card number to proceed with clearence of the order and delivery of goods.
Stephanidis, Savidis, AkoumianakisPage 50UAHCI 2001
ICS-FORTH Slide 99Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise The design task
• Design the dialogue through which a user can enter information about his/her credit card
• Information to be entered includes:– Card number– Expire data– Type of card– etc
ICS-FORTH Slide 100Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise Identifying the issues
• Issues raised:– How does the user
insert his/her credit card number?
– How does the user specific the expire data?
– How does the user indicate the type of card?
Issues
I-1:How does the user insert the credit card number
I-2:How does the user specify the expire date
I-3:How does the user indicate the type of card
Stephanidis, Savidis, AkoumianakisPage 51UAHCI 2001
ICS-FORTH Slide 101Stephanidis, Savidis & Akoumianakis
O-1-1:Type in digit-by-digit the number
O-1-2:Speak out digit-by-digit the number
O-1-3:Select digit-by-digitfrom a selection set
Enumerate - Abstract - Rationalise Describing the options
Issues I-2:How does the user specify the expire date
I-3:How does the user indicate the type of card
I-1:How does the user insert the credit card number
ICS-FORTH Slide 102Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise Exploring O-1-1
• O-1-1: Type in Digit-by-Digit the number
Card No: ^
Issues I-2:How does the user specify the expire date
I-3:How does the user indicate the type of card
O-1-1:Type in digit-by-digit the number
O-1-2:Speak out digit-by-digit the number
O-1-3:Select digit-by-digitfrom a selection set
I-1:How does the user insert the credit card number
Stephanidis, Savidis, AkoumianakisPage 52UAHCI 2001
ICS-FORTH Slide 103Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise Envisioning the artefact
• Form-based dialogue for providing credit card information
• Typical in Web documents
Credit Card No: ^Credit Card No: ^ Expires: ^__/__Expires: ^__/__
VISAVISA
Other ^Other ^
MasterCardMasterCardAccessAccess
SubmitSubmit
ICS-FORTH Slide 104Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise Re-engineering an artefact
• Re-engineering may be facilitated using different techniques such as– screening using re-engineering ‘filters’– abstraction
Stephanidis, Savidis, AkoumianakisPage 53UAHCI 2001
ICS-FORTH Slide 105Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise Setting filters
• How can the task be performed by a user with gross-temporal control familiar with switch-based interaction?
• How can the task be carried out with an alternative pointing device (e.g. a stylus of a palmtop computer)?
• How can the task be performed in a public kiosk?
ICS-FORTH Slide 106Stephanidis, Savidis & Akoumianakis
Card No: ^
Enumerate - Abstract - Rationalise Alternative option
Issues I-2:How does the user specify the expire date
I-3:How does the user indicate the type of card
O-1-1:Type in digit-by-digit the number
O-1-2:Speak out digit-by-digit the number
O-1-3:Select digit-by-digitfrom a selection set
I-1:How does the user insert the credit card number
Stephanidis, Savidis, AkoumianakisPage 54UAHCI 2001
ICS-FORTH Slide 107Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise Another option
• Switch-based interaction• Use of dedicated artefacts (e.g. visual keyboard)
00495276880049527688NumberNumber
VISAVISAMasterCardMasterCard
VISAVISA
AccessAccess
Card typeCard type
SubmitSubmit
11 22 33 44 55 66 77 88 99 1010 1111 1212ExpireExpire datedate
6620022002 20022002 2002200220022002
MonthMonthYearYear
CorrectCorrect
ICS-FORTH Slide 108Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise A non-visual option
Issues I-2:How does the user specify the expire date
I-3:How does the user indicate the type of card
O-1-1:Type in digit-by-digit the number
O-1-2:Speak out digit-by-digit the number
O-1-3:Select digit-by-digitfrom a selection set
I-1:How does the user insert the credit card number
Stephanidis, Savidis, AkoumianakisPage 55UAHCI 2001
ICS-FORTH Slide 109Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise Using abstractions
Credit Card No: ^Credit Card No: ^Expires: ^__/__Expires: ^__/__
VISAVISA
Other ^Other ^MasterCardMasterCard AccessAccess
SubmitSubmit
ICS-FORTH Slide 110Stephanidis, Savidis & Akoumianakis
logical grouping(abstract syntactic)
Enumerate - Abstract - RationaliseIdentifying roles
groupseparator
(generalisedsyntactic)SubmitSubmit
command(abstractsyntactic)
Credit Card No: Credit Card No: Expires: Expires:
VISAVISA
Other Other MasterCardMasterCard AccessAccess
label associatedto domain object
(abstract syntactic)
check-boxes(exclusive choice -abstract semantic)
__/____/__
Number or name(abstractsemantic)
Stephanidis, Savidis, AkoumianakisPage 56UAHCI 2001
ICS-FORTH Slide 111Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseProducing Abstract Model
label & valuator
grouping
exclusive choices & labels
command
label & valuator22
11
33
44
4 groups,4 digits/group
title
month,year
ICS-FORTH Slide 112Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseDeriving Alternatives (1/2)
VISAVISA
MasterCardMasterCard
11 22 33 44 55 66 77 88 99 1010 1111 121219971997 19981998 19991999 20002000
““Expires”Expires”
Radio Groups
^̂
WindowWindow
VISAVISA
SubmitSubmitAccessAccess
ComboBoxComboBox
PushButtonPushButton
TextEntryTextEntry
““CardNoCardNo””
Stephanidis, Savidis, AkoumianakisPage 57UAHCI 2001
ICS-FORTH Slide 113Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseDeriving Alternatives (2/2)
textfield“card no”
Room
frontwallentry
sound
leftwallentrysound
rightwallentrysound
textfield“expires”
toggle“VISA”
toggle“MasterCard”
toggle“Access”
button“Submit”
“card info”
ICS-FORTH Slide 114Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise
• Identify common design abstractions amongst design alternatives
• Model the abstractions– Abstract interaction
elements– Design templates
TaskContext
Set_number
Set_month Set_year
Issue_commandCard_details
Set_date
Stephanidis, Savidis, AkoumianakisPage 58UAHCI 2001
ICS-FORTH Slide 115Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - Rationalise
• Develop suitable argumentation for each design options– Why does it exist ?– What issue does it support ?– When should it be initiated ?– Where is it implemented ?– How does it compare against competing alternatives ?
• Decide on suitable representation
ICS-FORTH Slide 116Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseInformal definition
• For a design variable, rationalisationinvolves assessing alternatives against a designated set of criteria, to select an optimal assignment, given the current state of the knowledge available.
Stephanidis, Savidis, AkoumianakisPage 59UAHCI 2001
ICS-FORTH Slide 117Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseFormal definition
Let the following hold true: X is a design varibaleS={S1, S2, …, Sn} the set of alternative assognmnetsC={C1, C2, …, Cn} the set of criteria
thenRationalisation entails devising a technique which allows the decision maker .to select for X a maximally preferred option from S, given CI ∈ C.
ICS-FORTH Slide 118Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseAn example
Task to be studiedDevelop the polymorphictask hierarchy for command order in direct manipulation user interfaces
Approach1. Enumerate alternatives by observing users2. Abstract to identify common dialogue structures & criteria of differentiation3. Rationalise on the grounds of the identified criteria or empirical justification
Outcomes1. Design alternatives2. Polymorphic task hierarchy 3. Design criteria4. Justification or rationale
Stephanidis, Savidis, AkoumianakisPage 60UAHCI 2001
ICS-FORTH Slide 119Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseSteps to be followed
• Steps of the designer– Associate the task with the abstract design pattern
“Decide_command_order”– Declare design variable– Define alternatives– Identify criteria for polymorphosing the pattern
• heuristics, preferences, experiment, GOMS analysis, etc
– Collect evidence– Consolidate evidence to reasonable representation
ICS-FORTH Slide 120Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseProblem description
• Design variable– commandOrder
• Set of alternatives– {of_Syntax, fo_syntax}
• Criteria– task completion time, Tc– efficiency of task performance, E– frequency of errors, F– planning time, Pt– action time, At
Stephanidis, Savidis, AkoumianakisPage 61UAHCI 2001
ICS-FORTH Slide 121Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseEnumerating alternatives
• Function-Object syntax– First click on function– Second click on object
ICS-FORTH Slide 122Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseEnumerating alternatives (Cont.)
• Object-Function syntax– First click on object– Second click on function
Stephanidis, Savidis, AkoumianakisPage 62UAHCI 2001
ICS-FORTH Slide 123Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseDefining plausible criteria
• Dependent variables constitute the range of possible criteria for decomposition– task completion time, Tc– efficiency of task performance, E– frequency of errors, F– planning time, Pt– action time, At
• Choice of criteria based on experimental results
ICS-FORTH Slide 124Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseCompiled evidence
• Hypothetical conclusions– Command ordering is indifferent across a range
of dependent variables• task completion time• efficiency of task performance• frequency of errors
– There is a preference ranking for command for• action time• planning time
Stephanidis, Savidis, AkoumianakisPage 63UAHCI 2001
ICS-FORTH Slide 125Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseCriteria for polymorphosis
Decide_Command_Order
Any_other option
Select_Select_commandcommand
Select_Select_optionoption
Manipulate Manipulate optionsoptionsBeforeBefore
Planning time
BeforeBefore
Polymorphosis can only be justified for two criteria:
planning time, Pt action time, At
Action time
Manipulate Manipulate optionsoptions
Manipulate options
Select_Select_optionoption
Select_Select_commandcommand
ICS-FORTH Slide 126Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseRepresentation scheme
Representational primitivesA: A ∈ {A1, …, An} / Aj=Dependent variableTC: TC ∈ {TC1, …, TCn} / TCj=Application-specific task contextC:C ∈ {C1, …, Cn} / Cj=Independent variableO:O ∈ {O1, …, On} / Oj=Factor level of dependent variable
The design space (DS) is defined as
DS = { x: x ∈ A1(O1) ∪… ∪ An(On)}
Preference and indifference expressionsp (TC, C, A, Ok, Oj) i (TC, C, A, Ok, Oj)
Stephanidis, Savidis, AkoumianakisPage 64UAHCI 2001
ICS-FORTH Slide 127Stephanidis, Savidis & Akoumianakis
Enumerate - Abstract - RationaliseExtract from representation
/*------ Task context aggregation policy -------*/policy(graphic_Editing,action_Time(true),command_Order)policy(graphic_Editing,planning_Time(true),command_Order)policy(graphic_Editing,error_Frequency(true),command_Order)...h(graphic_Editing, action_Time(true), command_Order,FO_syntax, OF_syntax)h(graphic_Editing, planning_Time(true), command_Order,FO_syntax, OF_syntax)
/*------ End of task context aggregation policy -------*/
/*-----Solicited Preferences ---------*/p(graphic_Editing,command_Order, action_Time(true), FO_syntax, OF_syntax)p(graphic_Editing,command_Order, planning_Time(true), OF_syntax, FO_syntax)i(graphic_Editing,command_Order, task_completion_Time(true),OF_syntax,FO_syntax)i(graphic_Editing,command_Order, error_Frequency(true), OF_syntax, FO_syntax)…
/*-----End of Solicited Preferences ---------*/
ICS-FORTH Slide 128
Part III: ToolsCase studies & examples
Stephanidis, Savidis, AkoumianakisPage 65UAHCI 2001
ICS-FORTH Slide 129Stephanidis, Savidis & Akoumianakis
Design support
• Analysing users– identifying requirements– identifying tasks and preferred patterns
• Analysing the context of use– identifying the execution context of tasks
• Analysing the interaction platform– interaction objects and attributes– input/output devices– available/desirable interaction techniques
ICS-FORTH Slide 130Stephanidis, Savidis & Akoumianakis
USE-IT: A design tool for user-adapted interactions
• Developed in the ACCESS project• Part of the ACCESS development platform• Intended for the designer not the end user• A knowledge -based system• Focus on lexical aspects of interaction• Running under Windows
Stephanidis, Savidis, AkoumianakisPage 66UAHCI 2001
ICS-FORTH Slide 131Stephanidis, Savidis & Akoumianakis
Supported high-level design tasks
• Elicitation of user parameters– definition of parameters and valid value range– populating the user taxonomy
• Description of platform resources– input / output devices– interaction object classes
• Description of task context– logical view of intended interaction styles
ICS-FORTH Slide 132Stephanidis, Savidis & Akoumianakis
Output
• Rule base• Lexical adaptions• Critiquing of completeness and consistency• Task context schemas• Conditional rules, defaults, preferences• Conflict depection and resolution• etc.
Stephanidis, Savidis, AkoumianakisPage 67UAHCI 2001
ICS-FORTH Slide 133Stephanidis, Savidis & Akoumianakis
USE-IT session
• Reprersentation of the target platform– designate object classes and attributes– input / output devices
• User model– declare parameters and value range– define user abilities, preferences
• Task context scema– use styles of unified design to decide on task contexts– populate task contexts
ICS-FORTH Slide 134Stephanidis, Savidis & Akoumianakis
User modelling approach
• Developing user scenarios– A user is to carry out a text-editing task in a
graphical user interface. The user has mild motor impairments, which delimit control to gross temporal movements, exercised through contact with the fist. Fingertips cannot be reliably employed due to tremor on key-press, while movements can be performed in timed patterns and upon demand.
Stephanidis, Savidis, AkoumianakisPage 68UAHCI 2001
ICS-FORTH Slide 135Stephanidis, Savidis & Akoumianakis
The user modelling tool
ICS-FORTH Slide 136Stephanidis, Savidis & Akoumianakis
A new USE-IT project
Stephanidis, Savidis, AkoumianakisPage 69UAHCI 2001
ICS-FORTH Slide 137Stephanidis, Savidis & Akoumianakis
Defining user parameters
ICS-FORTH Slide 138Stephanidis, Savidis & Akoumianakis
A populated taxonomy
1
Stephanidis, Savidis, AkoumianakisPage 70UAHCI 2001
ICS-FORTH Slide 139Stephanidis, Savidis & Akoumianakis
Developing a device representation
ICS-FORTH Slide 140Stephanidis, Savidis & Akoumianakis
Describing interaction objects
Stephanidis, Savidis, AkoumianakisPage 71UAHCI 2001
ICS-FORTH Slide 141Stephanidis, Savidis & Akoumianakis
An example of a visual platform
ICS-FORTH Slide 142Stephanidis, Savidis & Akoumianakis
Example of non-visual platform
Stephanidis, Savidis, AkoumianakisPage 72UAHCI 2001
ICS-FORTH Slide 143Stephanidis, Savidis & Akoumianakis
Representation
ICS-FORTH Slide 144Stephanidis, Savidis & Akoumianakis
The user model
Stephanidis, Savidis, AkoumianakisPage 73UAHCI 2001
ICS-FORTH Slide 145Stephanidis, Savidis & Akoumianakis
The rules
• The rules compiled are subsequently used to:– select plausible devices for the
user– select plausible interaction
techniques (e.g. scanning)– set parameters of interaction
techniques (e.g. manual versus autop scanning
– etc
ICS-FORTH Slide 146Stephanidis, Savidis & Akoumianakis
Accessibility filters
• Employing accessibility filters– How is the product used by a user who possesses
alternative reliable control acts (e.g., movement of one hand, movement of both hands, directed eye-gaze, head movement, movement of lower limbs, vocalisations)?
– How is the product used by a user who possesses alternative contact site (e.g., finger tips of one hand, finger tips of both hands, fist, hand-held pointer, headstick, mouthstick, left upper part of head, right upper part of head, from top of head)?..
Stephanidis, Savidis, AkoumianakisPage 74UAHCI 2001
ICS-FORTH Slide 147Stephanidis, Savidis & Akoumianakis
Task context descriptions
• Identifying relevant guidelines– “… for a GUI to be
accessible by motor impaired users, there should be a method for carrying out mouse, or other pointing device functions, with a keyboard or a keyboard emulator”
• Envisioning artefacts
ICS-FORTH Slide 148Stephanidis, Savidis & Akoumianakis
Iterative prototyping
Design wisdomand Rationale
Stephanidis, Savidis, AkoumianakisPage 75UAHCI 2001
ICS-FORTH Slide 149Stephanidis, Savidis & Akoumianakis
Artefacts
• A prototype of the virtual keyboard
ICS-FORTH Slide 150Stephanidis, Savidis & Akoumianakis
Artefacts (Cont.)
• Prototypes for window mangement
Stephanidis, Savidis, AkoumianakisPage 76UAHCI 2001
ICS-FORTH Slide 151Stephanidis, Savidis & Akoumianakis
Adding justification
ICS-FORTH Slide 152Stephanidis, Savidis & Akoumianakis
Assigning styles to task contexts
• Style prototypes
Stephanidis, Savidis, AkoumianakisPage 77UAHCI 2001
ICS-FORTH Slide 153Stephanidis, Savidis & Akoumianakis
Declaring alternatives
Unified design method- hierarchical task decomposition- enumeration- abstraction-rationalisation
Task context instancesto be populated
Abstract task context(encapsulated alternatives)
ICS-FORTH Slide 154Stephanidis, Savidis & Akoumianakis
Populating the task context
Stephanidis, Savidis, AkoumianakisPage 78UAHCI 2001
ICS-FORTH Slide 155Stephanidis, Savidis & Akoumianakis
Populating the task context
ICS-FORTH Slide 156Stephanidis, Savidis & Akoumianakis
Conditional rules
Stephanidis, Savidis, AkoumianakisPage 79UAHCI 2001
ICS-FORTH Slide 157Stephanidis, Savidis & Akoumianakis
Checking the context schema
ICS-FORTH Slide 158Stephanidis, Savidis & Akoumianakis
Running the adaptation engine
Stephanidis, Savidis, AkoumianakisPage 80UAHCI 2001
ICS-FORTH Slide 159Stephanidis, Savidis & Akoumianakis
Silent critic
ICS-FORTH Slide 160Stephanidis, Savidis & Akoumianakis
Generating recommendations
Stephanidis, Savidis, AkoumianakisPage 81UAHCI 2001
ICS-FORTH Slide 161Stephanidis, Savidis & Akoumianakis
Formatted recommendations
ICS-FORTH Slide 162Stephanidis, Savidis & Akoumianakis
Revising the original design
Unified design method- hierarchical task decomposition- enumeration- abstraction-rationalisation
Deleting through scanning options in a selection set
Stephanidis, Savidis, AkoumianakisPage 82UAHCI 2001
ICS-FORTH Slide 163Stephanidis, Savidis & Akoumianakis
Design updates
ICS-FORTH Slide 164Stephanidis, Savidis & Akoumianakis
Applying the recommendations
Unified interface
specification
USE-IT
adapt(Object, Attribute,TaskContext,Value)
adapt(Object,Attribute,
TaskContext,Value)
Stephanidis, Savidis, AkoumianakisPage 83UAHCI 2001
ICS-FORTH Slide 165Stephanidis, Savidis & Akoumianakis
Concluding remarks
• USE-IT is a system that implements some of the concepts of unified design– Abstract interaction objects– Style designtation through task contexts– Hierarchical organisation of task contexts– Object binding to task contexts
• Depending on the task context the same object may exhibit alternative interactive manifestation
ICS-FORTH Slide 166Stephanidis, Savidis & Akoumianakis
Concluding remarks (Cont.)
• Additional functions of USE-IT– Generates consistent and complete recommendations in a toolkit-specific
format– Non-trivial attributes, e.g.,
• feedback (initiation, interim, completion)• presentation policy (access, topology)
– Semantic binding of an adaptation decision to<task context, object class, criterion, attribute>
– Incremental design updates• new styles can be introduced by declaring new task contexts
– Contextual definition of scope of adaptations e.g.,• object classes, devices, user categories to be addressed by the
adaptation engine
Stephanidis, Savidis, AkoumianakisPage 84UAHCI 2001
ICS-FORTH Slide 167Stephanidis, Savidis & Akoumianakis
Concluding remarks (Cont.)
• In the current version, USE-IT does not support– style relationships
• compatibility, substitution, augmentation, etc– adaptations at syntax or semantic levels
ICS-FORTH Slide 168Stephanidis, Savidis & Akoumianakis
Summary
• Use when execution context varies– alternatives should be enumerated for differentiating user-
and context- parameters for the same tasks
• Based on polymorphic task hierarchies,– styles designated to execution contexts of a task
• Driven by diversity – user- and context- attributes, being the primary design
parameters
Stephanidis, Savidis, AkoumianakisPage 85UAHCI 2001
ICS-FORTH Slide 169Stephanidis, Savidis & Akoumianakis
General remarks
• Unified design introduces concepts which offer an insight to designing for diversity– polymorphic task hierarchies– styles– focus on artefact and supporting rationale
• Suitable for various design fashions– bottom up: identifying concerete artefacts and then abstracting– top-down: from abstractions to concrete artefacts– middle out: combining the above
• Application in the AVANTI browser
ICS-FORTH Slide 170Stephanidis, Savidis & Akoumianakis
Unified Interface Development (agenda)
PrologueUnified interface design
Unified interface engineeringTools for unified interfaces
Stephanidis, Savidis, AkoumianakisPage 86UAHCI 2001
ICS-FORTH Slide 171Stephanidis, Savidis & Akoumianakis
Unified Interface Engineering –Outline (1/3)
• A run-time architecture for implementing interface adaptation supporting:– Evolution– Reuse– Distribution
ICS-FORTH Slide 172Stephanidis, Savidis & Akoumianakis
Unified Interface Engineering -Outline (2/3)
• Specific scenarios describing distributed control flow and inter-component communication to accomplish adaptation
Stephanidis, Savidis, AkoumianakisPage 87UAHCI 2001
ICS-FORTH Slide 173Stephanidis, Savidis & Akoumianakis
Unified Interface Engineering -Outline (3/3)
• Some techniques to bring the software implementation more close to the interface design, thus making easier to program design changes
ICS-FORTH Slide 174Stephanidis, Savidis & Akoumianakis
Unified Interface Engineering (agenda)
Unified Interface ArchitectureAdaptation Scenarios and control flow
Stephanidis, Savidis, AkoumianakisPage 88UAHCI 2001
ICS-FORTH Slide 175Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern
Provide dialogue according
to user-, and context-attributes values
• Divide and conquer• Role separation• Orthogonality• Eliminate replication
Starting pointVehicle
ICS-FORTH Slide 176Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern (1/9)
User-, Context-Attributes
Provide adapteddialogue
Stephanidis, Savidis, AkoumianakisPage 89UAHCI 2001
ICS-FORTH Slide 177Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern(2/9)
User-, Context-Attributes
Decide which dialogues to
activate
Activate decideddialogues
ICS-FORTH Slide 178Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern(3/9)
Userattributes
Decide which dialogues to
activate
Activate decideddialogues
Contextattributes
Stephanidis, Savidis, AkoumianakisPage 90UAHCI 2001
ICS-FORTH Slide 179Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern(4/9)
Userattributes
Decide which dialogues to
activate
Activate decideddialogues
Contextattributes DialoguesDialoguesDialoguesDialogues
ICS-FORTH Slide 180Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern(5/9)
Userattributes
Decide which dialogues to
activate / cancel
Activate / canceldecided
dialogues
Contextattributes DialoguesDialoguesDialoguesDialogues
Stephanidis, Savidis, AkoumianakisPage 91UAHCI 2001
ICS-FORTH Slide 181Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern(6/9)
Decide which dialogues to
activate / cancel
Activate / canceldecided
dialogues
Contextattributes DialoguesDialoguesDialoguesDialogues
UserInformation
Server
ICS-FORTH Slide 182Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern(7/9)
Decide which dialogues to
activate / cancel
Activate / canceldecided
dialogues
DialoguesDialoguesDialoguesDialogues
UserInformation
Server
ContextInformation
Server
Stephanidis, Savidis, AkoumianakisPage 92UAHCI 2001
ICS-FORTH Slide 183Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern(8/9)
Activate / canceldecided
dialogues
DialoguesDialoguesDialoguesDialogues
UserInformation
Server
ContextInformation
Server
DecisionMaking
Component
ICS-FORTH Slide 184Stephanidis, Savidis & Akoumianakis
Revealing an Architectural Pattern(9/9)
UserInformation
Server
ContextInformation
Server
DecisionMaking
Component
DialoguePatterns
Component
Stephanidis, Savidis, AkoumianakisPage 93UAHCI 2001
ICS-FORTH Slide 185Stephanidis, Savidis & Akoumianakis
Unified Interface Architecture
UserInformation
Server
ContextInformation
Server
DecisionMaking
Component
DialoguePatterns
Component
ICS-FORTH Slide 186Stephanidis, Savidis & Akoumianakis
Component Analysis
• Role and behaviour• Content• Communication• Implementation
Stephanidis, Savidis, AkoumianakisPage 94UAHCI 2001
ICS-FORTH Slide 187Stephanidis, Savidis & Akoumianakis
Context Information Server- Role and Behaviour
• To supply context attribute values(machine and environment)– Static (non-changing during interaction,
e.g. peripheral equipment)– Dynamic (may change during interaction,
e.g. environment noise)
ICS-FORTH Slide 188Stephanidis, Savidis & Akoumianakis
Context Information Server- Content (1/2)
• Awareness of I/O devices and their properties– e.g. hand-held binary switches, speech
synthesiser (English, Greek), high resolution display (mode 16bits, 1024x768, 75Hz), Pentium-III 500MHz / 2MB cache / 128 MB memory, 20 GB hard disc
Stephanidis, Savidis, AkoumianakisPage 95UAHCI 2001
ICS-FORTH Slide 189Stephanidis, Savidis & Akoumianakis
Context Information Server- Content (2/2)
• Environment information (requires appropriate sensors)– e.g. acoustic noise, light reflection on
display, presence of the user in front of the terminal, humidity, smoke detection
ICS-FORTH Slide 190Stephanidis, Savidis & Akoumianakis
Context Information Server- Communication (1/2)
• Context information is supplied in the form of (attribute, value) pairs– Simple model– Highly generic– Value can be aggregate – e.g. (“environment noise”, “78db”)
(“resolution”, “1024x768”) (“user presence”, “no”)
Stephanidis, Savidis, AkoumianakisPage 96UAHCI 2001
ICS-FORTH Slide 191Stephanidis, Savidis & Akoumianakis
Context Information Server- Communication (2/2)
• Send by request– all / some attributes with their values
• Send by modification– post attributes when their value changes
during user interaction
ICS-FORTH Slide 192Stephanidis, Savidis & Akoumianakis
Context Information Server- Implementation
• Registry for I/O equipment• Use of sensors for retrieving
environment parameters• Location awareness
Stephanidis, Savidis, AkoumianakisPage 97UAHCI 2001
ICS-FORTH Slide 193Stephanidis, Savidis & Akoumianakis
User Information Server -Role and Behaviour
• To supply user attribute values– Known off-line, before initiating interaction– Detected on-line, from real-time
interaction-monitoring analysis• e.g. fatigue, loss of orientation, inability
to perform the task, interaction preferences
ICS-FORTH Slide 194Stephanidis, Savidis & Akoumianakis
User Information Server -Content (1/2)
• Repository of user profiles• Logic for interaction-monitoring
analysis
Stephanidis, Savidis, AkoumianakisPage 98UAHCI 2001
ICS-FORTH Slide 195Stephanidis, Savidis & Akoumianakis
User Information Server -Content (2/2)
computerknowledge
Webknowledge
expert
ability touse left hand
frequent average casual native
verygood good average some limited none
perfect good some limited none
Parameters Value domainP1
P2
Pn
User profile model
User profile instance
ICS-FORTH Slide 196Stephanidis, Savidis & Akoumianakis
User Information Server -Communication
• Send by request– all / some attributes with their values
• Send by modification– post attributes when their value changes
during interaction– post dynamically detected attributes and
their values
Stephanidis, Savidis, AkoumianakisPage 99UAHCI 2001
ICS-FORTH Slide 197Stephanidis, Savidis & Akoumianakis
User Information Server -Implementation (1/3)
• Could employ a database to store / retrieve user profiles
• Dynamic attribute detection requires further processing
ICS-FORTH Slide 198Stephanidis, Savidis & Akoumianakis
User Information Server -Implementation (2/3)
Interactionhistory
Designinformation
Inferencecomponent
Userprofiles
Interactionmonitoringdata
Userattribute
values
User Information Server
Stephanidis, Savidis, AkoumianakisPage 100UAHCI 2001
ICS-FORTH Slide 199Stephanidis, Savidis & Akoumianakis
User Information Server -Implementation (3/3)
UserModels
BehaviouralAction
Patterns
PatternMatching
Interactionhistory
Userprofile
Inference Component
ICS-FORTH Slide 200Stephanidis, Savidis & Akoumianakis
Decision Making Component -Role and Behaviour
• Matches user- and context-attribute values to the most appropriate dialogue artifacts
• Decides why, when and how to adapt
Stephanidis, Savidis, AkoumianakisPage 101UAHCI 2001
ICS-FORTH Slide 201Stephanidis, Savidis & Akoumianakis
Decision Making Component -Content
• Awareness of design artifacts (e.g. named, indexed), user- / context-attributes and respective values (e.g. “age”, integer, 5...110)
• Decision making knowledge
ICS-FORTH Slide 202Stephanidis, Savidis & Akoumianakis
Decision Making Component -Communication
• Receives user- and context-attributes (from UIS)
• Posts decisions for activation or cancellation of implemented dialogue patterns (to DPC)
Stephanidis, Savidis, AkoumianakisPage 102UAHCI 2001
ICS-FORTH Slide 203Stephanidis, Savidis & Akoumianakis
Decision Making Component -Implementation (1/2)
• Knowledge-based component, playing the role of an adaptation expert
• Rule-based implementation framework may suffice
ICS-FORTH Slide 204Stephanidis, Savidis & Akoumianakis
Decision Making Component -Implementation (2/2)
• If given particular user, usagecontext, dialogue state, and interaction history, a human designer can decide optimal adaptation– then we can make the machine able to
adapt as well by embedding designer’s decision logic
Stephanidis, Savidis, AkoumianakisPage 103UAHCI 2001
ICS-FORTH Slide 205Stephanidis, Savidis & Akoumianakis
Dialogue Patterns Component -Role and Behaviour
• Applies adaptation decisions, making available to the user the necessary dialogue patterns
• Knows where implemented dialogue patterns reside
ICS-FORTH Slide 206Stephanidis, Savidis & Akoumianakis
Dialogue Patterns Component -Content
• Repository of implemented dialogue patterns– Local / remote address– Source / binary form
Stephanidis, Savidis, AkoumianakisPage 104UAHCI 2001
ICS-FORTH Slide 207Stephanidis, Savidis & Akoumianakis
Dialogue Patterns Component -Communication
• Receives activation / cancellationdecisions for dialogue components
• Receives interaction monitoring control commands
• Posts interaction monitoring data
ICS-FORTH Slide 208Stephanidis, Savidis & Akoumianakis
Dialogue Patterns Component -Implementation (1/2)
• Communication with other components
• Coordination of dialogue artifacts• Manipulation of dialogue artifacts• Monitoring of interaction within
dialogue artifacts
Stephanidis, Savidis, AkoumianakisPage 105UAHCI 2001
ICS-FORTH Slide 209Stephanidis, Savidis & Akoumianakis
Dialogue Patterns Component -Implementation (2/2)
Communication
Monitoring
Coordination
Manipulation
ImpementedDialogueArtifacts
ImpementedDialogueArtifactsAP
I, C
ompo
nent
Mod
el,
Inde
, Cat
alog
ue
Dialogue Patterns Component
ICS-FORTH Slide 210Stephanidis, Savidis & Akoumianakis
Unified Software Architecture -Some Key Remarks (1/2)
• Comprehensive start-up cost to set-up an interactive system as a unified implementation...
• But afterwards, the incorporation of adaptation behaviour becomes a standardised convenient process
Stephanidis, Savidis, AkoumianakisPage 106UAHCI 2001
ICS-FORTH Slide 211Stephanidis, Savidis & Akoumianakis
Unified Software Architecture -Some Key Remarks (2/2)
• …more dialogue artifacts• …more interaction monitoring• …more user attributes• …more interaction-analysis logic• …more context attributes• …more adaptation-oriented logic
ICS-FORTH Slide 212Stephanidis, Savidis & Akoumianakis
Unified Interface Engineering (agenda)
Unified Interface Architecture
Adaptation Scenarios and control flow
Stephanidis, Savidis, AkoumianakisPage 107UAHCI 2001
ICS-FORTH Slide 213Stephanidis, Savidis & Akoumianakis
Adaptation Scenarios and Control Flow – Example (1/5)
• Detecting dynamically confusion in performing a task and providing task-based guidance
ICS-FORTH Slide 214Stephanidis, Savidis & Akoumianakis
Adaptation Scenarios and Control Flow - Example (2/5)
UIS requests monitoring for
a particular task
DPC accepts request,and activates necessarymonitoring components
DPC continuously posts interaction monitoring
data back to UIS
1
2
3
Stephanidis, Savidis, AkoumianakisPage 108UAHCI 2001
ICS-FORTH Slide 215Stephanidis, Savidis & Akoumianakis
Adaptation Scenarios and Control Flow - Example (3/5)
UIS receivescontinuously data
and builds anannotated interaction
history UIS continuouslyanalyses interaction
history to detectparticular action
patterns UIS detects confusion pattern for a particular task,
and sends this assumption
to DMC
4
5
6
ICS-FORTH Slide 216Stephanidis, Savidis & Akoumianakis
Adaptation Scenarios and Control Flow - Example (4/5)
DMC receives anassumption forconfusion on
a particular taskDMC decides to
activate a dialoguecomponent providingtask-based guidanceto resolve confusion
DMC posts thenecessary activation
message to DPC
7
8
9
Stephanidis, Savidis, AkoumianakisPage 109UAHCI 2001
ICS-FORTH Slide 217Stephanidis, Savidis & Akoumianakis
Adaptation Scenarios and Control Flow - Example (5/5)
DPC receives theactivation message
and locates thecorresponding
dialogue component
Finally, DPC activates this specific dialogue
component
10
11
ICS-FORTH Slide 218Stephanidis, Savidis & Akoumianakis
Unified Interface Development (agenda)
PrologueUnified interface designUnified interface engineering
Tools for unified interfaces
Stephanidis, Savidis, AkoumianakisPage 110UAHCI 2001
ICS-FORTH Slide 219Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces(agenda)
• Introduction• Metaphor Development• Toolkit Integration• Toolkit Augmentation• Toolkit Expansion• Toolkit Abstraction
ICS-FORTH Slide 220Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces -Introduction (1/7)
• What is the “entrance barrier” for interface tools in order to facilitate the development of universally accessible interactions ? Or more specifically...
Stephanidis, Savidis, AkoumianakisPage 111UAHCI 2001
ICS-FORTH Slide 221Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces -Introduction (2/7)
• Considering the diversity in end-users and usage-contexts, which are the most important implementation ingredients for building unified interfaces ?
ICS-FORTH Slide 222Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces -Introduction (3/7)
• Different users, in different contexts and situations of use, likely require different interaction metaphors
Metaphor development
Stephanidis, Savidis, AkoumianakisPage 112UAHCI 2001
ICS-FORTH Slide 223Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces -Introduction (4/7)
• Since designers may employ any particular interaction toolkit, the interface tool employed for implementation should enable programmers to utilise this toolkit
Toolkit integration
ICS-FORTH Slide 224Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces -Introduction (5/7)
• Support the introduction of additional interaction techniques within interaction objects, for the cases in which the built-in techniques are not sufficient
Toolkit augmentation
Stephanidis, Savidis, AkoumianakisPage 113UAHCI 2001
ICS-FORTH Slide 225Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces -Introduction (6/7)
• Support the introduction of new interaction objects within toolkits, for the cases in which the originally supplied set is not sufficient
Toolkit expansion
ICS-FORTH Slide 226Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces -Introduction (7/7)
• Facilitate the manipulation of interaction objects completely relieved from physical interaction properties
Toolkit abstraction
Stephanidis, Savidis, AkoumianakisPage 114UAHCI 2001
ICS-FORTH Slide 227Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces(agenda)
• Introduction
• Metaphor Development• Toolkit Integration• Toolkit Augmentation• Toolkit Expansion• Toolkit Abstraction
ICS-FORTH Slide 228Stephanidis, Savidis & Akoumianakis
Metaphor Development -Why ? (1/5)
• Interaction metaphors are user-oriented– Design should reflect the attributes of
target users– It is unlike that a single metaphor can be
globally optimal for all end-users
Stephanidis, Savidis, AkoumianakisPage 115UAHCI 2001
ICS-FORTH Slide 229Stephanidis, Savidis & Akoumianakis
Metaphor Development -Phases in Unified Paradigm (2/5)
• Design
• Realisation
• Implementation
ICS-FORTH Slide 230Stephanidis, Savidis & Akoumianakis
Metaphor Development -Phases (3/5)
concepts,features,entities,properties,behaviours,relationships
media, modalities,interaction objects,interaction techniques,attributes,dialogue design
coding, implementation libraries, programming model,run- time architecture
MFC, InterViews,Motif, Mac Toolbox, JFC, UIML
testingtesting
testingtesting
Design
Realisation
Implementation
Stephanidis, Savidis, AkoumianakisPage 116UAHCI 2001
ICS-FORTH Slide 231Stephanidis, Savidis & Akoumianakis
Metaphor Development -Advantages of the Approach (4/5)
• Multiple realisations of a single metaphor design– Modifications on a metaphor realisation
can be applied without affecting original metaphor design
ICS-FORTH Slide 232Stephanidis, Savidis & Akoumianakis
Metaphor Development -Advantages (5/5)
• Multiple implementations of a single metaphor realisation– Modifications on a metaphor
implementation are allowed without affecting original metaphor realisation
Stephanidis, Savidis, AkoumianakisPage 117UAHCI 2001
ICS-FORTH Slide 233Stephanidis, Savidis & Akoumianakis
Design of an Interaction Metaphor - Where to Start From
• Top-level container interaction objects play the most important role
ICS-FORTH Slide 234Stephanidis, Savidis & Akoumianakis
Top-level Containers -Key Role (1/5)
Windowing / Desk-top Metaphor ?
Stephanidis, Savidis, AkoumianakisPage 118UAHCI 2001
ICS-FORTH Slide 235Stephanidis, Savidis & Akoumianakis
Top-level Containers -Key Role (2/5)
Books Metaphor ?
ICS-FORTH Slide 236Stephanidis, Savidis & Akoumianakis
Top-level Containers -Key Role (3/5)
Teacher / Whiteboard Metaphor ?
Stephanidis, Savidis, AkoumianakisPage 119UAHCI 2001
ICS-FORTH Slide 237Stephanidis, Savidis & Akoumianakis
Top-level Containers -Key Role (4/5)
• Embedded Objects do notAffect Overall Interaction Metaphor
Open
Button
Save
Save as...
Quit
•Push buttons - Electric devices•Sliders / potentiometers - Electric devices•Check-boxes - From filling•Menus - Restaurant•Gauges - Electric devices
ICS-FORTH Slide 238Stephanidis, Savidis & Akoumianakis
Top-level Containers -Key Role (5/5)
Door to another room
Interaction object
Group: “floor”,“ceiling” andfront, left, back,right “walls”
LIFTLIFT
LIFT
Leads to rooms which are one levelabove or bellow
Non-Visual Rooms - COMONKIT Toolkit
Stephanidis, Savidis, AkoumianakisPage 120UAHCI 2001
ICS-FORTH Slide 239Stephanidis, Savidis & Akoumianakis
Top Level Containers –A Step Foward
• HAWK Non-Visual Toolkit providing a generic container class, supporting programmable:– Navigation dialogue for contained objects– Display / presentation policy– I/O device binding
ICS-FORTH Slide 240Stephanidis, Savidis & Akoumianakis
HAWK Toolkit –Typical Embedded Objects
• Embedded objects are non-visual realizations of broadly used metaphoric objects:– Menu– Listbox– Radio button– Single- / multi- line editor– etc
Stephanidis, Savidis, AkoumianakisPage 121UAHCI 2001
ICS-FORTH Slide 241Stephanidis, Savidis & Akoumianakis
HAWK Toolkit –Used in Demanding Projects
• To implement non-visual custom-made hypermedia tool in the ACCESS project
• To implement the non-visual component of the unified AVANTI browser
ICS-FORTH Slide 242Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces(agenda)
• Introduction• Metaphor Development
• Toolkit Integration• Toolkit Augmentation• Toolkit Expansion• Toolkit Abstraction
Stephanidis, Savidis, AkoumianakisPage 122UAHCI 2001
ICS-FORTH Slide 243Stephanidis, Savidis & Akoumianakis
Toolkit Integration
• As toolkits we consider software libraries providing the implementation of interaction elements– e.g. Windows, OSF/Motif, JFC, HAWK,...
ICS-FORTH Slide 244Stephanidis, Savidis & Akoumianakis
Toolkit Integration -Definition
• The ability of interface development tools to import toolkits, thus making imported interaction elements available in the dialogue implementation process.
Stephanidis, Savidis, AkoumianakisPage 123UAHCI 2001
ICS-FORTH Slide 245Stephanidis, Savidis & Akoumianakis
Toolkit Integration -Role in Unified Development
• Utilise elements from multiple sources (i.e. multi-toolkit platform)
• Supplying a common API, as opposed to native toolkit programming models
ICS-FORTH Slide 246Stephanidis, Savidis & Akoumianakis
Toolkit Integration -Cross-Metaphor Interoperability
DocumentObject
RoomsContainer
Left Wall
BlackBoardContainer
CalendarObject
LibraryContainer
BookContainer
WindowContainer
Right Wall
WindowContainer
FileManagerObject
VideoObject
Stephanidis, Savidis, AkoumianakisPage 124UAHCI 2001
ICS-FORTH Slide 247Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces(agenda)
• Introduction• Metaphor Development• Toolkit Integration
• Toolkit Augmentation• Toolkit Expansion• Toolkit Abstraction
ICS-FORTH Slide 248Stephanidis, Savidis & Akoumianakis
Toolkit Augmentation -Definition
• The process through which additional interaction techniques are injected into the original (native) interaction elements supplied by a particular toolkit
Stephanidis, Savidis, AkoumianakisPage 125UAHCI 2001
ICS-FORTH Slide 249Stephanidis, Savidis & Akoumianakis
Toolkit Augmentation -Role in Unified Development
• Enhancing the accessibility and quality of interaction elements by augmenting with extra interaction techniques (both display, as well as input, may be affected)
ICS-FORTH Slide 250Stephanidis, Savidis & Akoumianakis
Toolkit Augmentation -An Example (1/6)
• Augmented Windows MFC• Switch-based access (binary
switches)• Lexical dialogue decomposition into
two fundamental actions: select, next
Stephanidis, Savidis, AkoumianakisPage 126UAHCI 2001
ICS-FORTH Slide 251Stephanidis, Savidis & Akoumianakis
Toolkit Augmentation -An Example (2/6)
• Categories of object classes subject to augmentation:– Top-level windows– Container objects– Text-entry objects– Composite objects– Button categories
ICS-FORTH Slide 252Stephanidis, Savidis & Akoumianakis
Toolkit Augmentation -An Example (3/6)
• Top-level windows
– All top-level windows have been augmented with an additional toolbar, supporting scanning interaction, providing all window management operations
Stephanidis, Savidis, AkoumianakisPage 127UAHCI 2001
ICS-FORTH Slide 253Stephanidis, Savidis & Akoumianakis
Toolkit Augmentation -An Example (4/6)
sizemanipulation
positioncontrol
statecontrol
ICS-FORTH Slide 254Stephanidis, Savidis & Akoumianakis
Toolkit Augmentation -An Example (5/6)
• Text-entry objects– Requiring text to be supplied, imposing the
need for keyboard emulation
Stephanidis, Savidis, AkoumianakisPage 128UAHCI 2001
ICS-FORTH Slide 255Stephanidis, Savidis & Akoumianakis
Toolkit Augmentation -An Example (6/6)
ICS-FORTH Slide 256Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces(agenda)
• Introduction• Metaphor Development• Toolkit Integration• Toolkit Augmentation
• Toolkit Expansion• Toolkit Abstraction
Stephanidis, Savidis, AkoumianakisPage 129UAHCI 2001
ICS-FORTH Slide 257Stephanidis, Savidis & Akoumianakis
Toolkit Expansion -Definition
• The construction of new interaction objects, not originally supported by toolkits
ICS-FORTH Slide 258Stephanidis, Savidis & Akoumianakis
Toolkit Expansion -Role in Unified Development
• To implement the various artifactsin adapted interactions, developers may need to build new interaction objects – In this process, the development tool
should provide all the adequate support
Stephanidis, Savidis, AkoumianakisPage 130UAHCI 2001
ICS-FORTH Slide 259Stephanidis, Savidis & Akoumianakis
Tools for Unified Interfaces(agenda)
• Introduction• Metaphor Development• Toolkit Integration• Toolkit Augmentation• Toolkit Expansion
• Toolkit Abstraction
ICS-FORTH Slide 260Stephanidis, Savidis & Akoumianakis
Toolkit Abstraction -Definition
• The provision of interaction objects entirely de-coupled from physical interaction properties
Stephanidis, Savidis, AkoumianakisPage 131UAHCI 2001
ICS-FORTH Slide 261Stephanidis, Savidis & Akoumianakis
Toolkit Abstraction -Abstract Selector Example
No ofoptions
Userchoice
4
2
“Open”
“Quit”
“Save as...”
“Save”
3Dpointing
soundfeedback
syntheticspeech
4
op : Opensv : Savesa : Save as...qu :Quit
>op_
3
auditory /3D pointing
command based
circular“clock”
column“restaurant”
4
4
Open Save
Quit Save as..
abstractSELECTOR
1
1
(( ))(( ))
(( ))(( ))
Open
Quit
Save as...
Save
ICS-FORTH Slide 262Stephanidis, Savidis & Akoumianakis
Toolkit Abstraction -Role in Unified Development (1/2)
• The provision of abstract objects at the implementation layers, enables the construction of unified artifacts:– i.e. dialogues composed of abstract objects
which can be instantiated, through programming control, to alternative physical forms
Stephanidis, Savidis, AkoumianakisPage 132UAHCI 2001
ICS-FORTH Slide 263Stephanidis, Savidis & Akoumianakis
Toolkit Abstraction -Role in Unified Development (2/2)
• The abstraction requirement is technically considered to be the most important for unified interface development
ICS-FORTH Slide 264Stephanidis, Savidis & Akoumianakis
Tutorial agenda
Introduction to Unified InterfacesUnified Interface Development
Universal Access and the WebChallenges and Future Work
Stephanidis, Savidis, AkoumianakisPage 133UAHCI 2001
ICS-FORTH Slide 265Stephanidis, Savidis & Akoumianakis
Universal Access and the Web -agenda
Browsers as interface toolsPlatform diversity on the WebAutomatic Web-page adaptation
ICS-FORTH Slide 266Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(1/10)
• Interactive components– what is interactively presented to the user
via the Web-page
• Non-interactive components– functionality “behind the scenes”, not
dealing with interaction or display
Stephanidis, Savidis, AkoumianakisPage 134UAHCI 2001
ICS-FORTH Slide 267Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(2/10)
• Web-page specific, i.e. client side– HTML, CSS, XML, scripts (JavaScript,
VisualBasicScript), embedded components (ActiveX, JavaBeans)• Varying implementation forms (script,
content, programmed interactive components, style definition and use)
ICS-FORTH Slide 268Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(3/10)
• Server-side functionality– CGI (Common Gateway Interface),
ServeLets (Server-side applets), ASP (Active Server Pages)• Usually perform some type of data
filtering, processing and retrieval, and then dynamically construct a target Web page
Stephanidis, Savidis, AkoumianakisPage 135UAHCI 2001
ICS-FORTH Slide 269Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(4/10)
• Client-side code is actually the User Interface
• Server-side code is mainly the non-interactive functional core
ICS-FORTH Slide 270Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(5/10)
• Browsers seem to preserve the principle of separation– A principle which was a “hot issue” for
interface tools in the early 80s,...– subject to dispute and argumentation in the
early 90s, …– and silently integrated within most of
commercial interface tools in the late 90s
Stephanidis, Savidis, AkoumianakisPage 136UAHCI 2001
ICS-FORTH Slide 271Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(6/10)
• Diverse development techniques– Declarative hypertext (HTML)– Scripting procedural (scripts)– Declarative formatting (styles)– Interface structural definition (forms, UIML)– Std programming (embedded components)– Semantic definitions (XML)
ICS-FORTH Slide 272Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(7/10)
• Most of the alternative techniques are not standardised...
• There are variations per technique– JavaScript / VisualBasicScript– ActiveX / JavaBeans– DOM notational access– CSS use syntax
Stephanidis, Savidis, AkoumianakisPage 137UAHCI 2001
ICS-FORTH Slide 273Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(8/10)
• What Web mostly offered to UI developers ?– Interactive document metaphor– Instant global delivery
ICS-FORTH Slide 274Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(9/10)
• Is development easier compared to traditional desk-top applications ?– For simple things yes, for serious applications, no– Non-linear growth of development complexity, in
relation to application complexity– Non-linear growth of entrance barrier in relation to
application complexity
Stephanidis, Savidis, AkoumianakisPage 138UAHCI 2001
ICS-FORTH Slide 275Stephanidis, Savidis & Akoumianakis
Browsers as Interface Tools(10/10)
applicationapplicationcomplexitycomplexity
developmentdevelopmentcomplexity,complexity,
entrance barrierentrance barrier
desk-top applicationapplicationcomplexitycomplexity
developmentdevelopmentcomplexity,complexity,
entrance barrierentrance barrier
web
ICS-FORTH Slide 276Stephanidis, Savidis & Akoumianakis
Universal Access and the Web -agenda
Browsers as interface tools
Platform diversity on the WebAutomatic Web-page adaptation
Stephanidis, Savidis, AkoumianakisPage 139UAHCI 2001
ICS-FORTH Slide 277Stephanidis, Savidis & Akoumianakis
Platform Diversity on the Web(1/5)
• Spread over a wide range of operating systems, with various browsers– PCs, MACs, Work-stations
• Porting to embedded operating systems with alternative protocols– WAP phones, Web-enabled devices
ICS-FORTH Slide 278Stephanidis, Savidis & Akoumianakis
Platform Diversity on the Web(2/5)
• Are all browsers on the various platforms accessible ? with high quality interaction ?– ...blind user access ?– …motor-impaired users ?– …what about the elderly ?– …the children ?
Stephanidis, Savidis, AkoumianakisPage 140UAHCI 2001
ICS-FORTH Slide 279Stephanidis, Savidis & Akoumianakis
Platform Diversity on the Web(3/5)
• Browsers for blind users– pwWebSpeak, V-Lynx, AVANTI,
NAUTILOS
• Browsers for motor-impaired users– AVANTI, NAUTILOS
ICS-FORTH Slide 280Stephanidis, Savidis & Akoumianakis
Platform Diversity on the Web(4/5)
• …or alternatively– Use an alternative access system, over a
typical browser• Screen-reader for blind• Virtual keyboards for motor-impaired.
– W3C / WAI guidelines for Web authoring, to enable alternative access systems make a better job
Stephanidis, Savidis, AkoumianakisPage 141UAHCI 2001
ICS-FORTH Slide 281Stephanidis, Savidis & Akoumianakis
Platform Diversity on the Web(5/5)
• There is no alternative browser, nor an alternative access systems for platforms such as:– phones– home appliances
• TV, refrigerator, washing machine,...– office equipment
• fax, copier, coffee machine,...
ICS-FORTH Slide 282Stephanidis, Savidis & Akoumianakis
Universal Access and the Web -agenda
Browsers as interface toolsPlatform diversity on the Web
Automatic Web-page adaptation
Stephanidis, Savidis, AkoumianakisPage 142UAHCI 2001
ICS-FORTH Slide 283Stephanidis, Savidis & Akoumianakis
Automatic Web-page Adaptation
• Client-side– Adaptation logic, constituents and control
embedded within the Web-page
• Server-side– Adaptation logic and control residing on
server side, producing adapted Web-pages
ICS-FORTH Slide 284Stephanidis, Savidis & Akoumianakis
Automatic Web-page Adaptation -Client-side (1/2)
• Limited adaptation at the level of:– Document structure– Document content– Dialogue components
Stephanidis, Savidis, AkoumianakisPage 143UAHCI 2001
ICS-FORTH Slide 285Stephanidis, Savidis & Akoumianakis
Automatic Web-page Adaptation -Client-side (2/2)
• Implementation mechanisms– Style differentiation (CSS, XML / XSL)– Content / dialogue differentiation (via scripting for
dynamic content selection)– For more dynamic dialogue, embedded
components must be implemented– User profile management requires persistent
shared data and state maintenance
ICS-FORTH Slide 286Stephanidis, Savidis & Akoumianakis
Automatic Web-page Adaptation -Server-side (1/2)
• Flexible adaptation at the level of:– Document structure– Document content– Dialogue components
Stephanidis, Savidis, AkoumianakisPage 144UAHCI 2001
ICS-FORTH Slide 287Stephanidis, Savidis & Akoumianakis
Automatic Web-page Adaptation -Server-side (2/2)
• Implementation mechanisms– User profile database– Page templates– Decision making– Dynamic page construction
ICS-FORTH Slide 288Stephanidis, Savidis & Akoumianakis
Automatic Web-page Adaptation -Wrap-Up
• Server-side adaptation is functionally superior to client-side adaptation
• While development responsibility is on document authors, re-usable services may help in making automatically adapted sites
Stephanidis, Savidis, AkoumianakisPage 145UAHCI 2001
ICS-FORTH Slide 289Stephanidis, Savidis & Akoumianakis
Tutorial agenda
Introduction to Unified InterfacesUnified Interface DevelopmentUniversal Access and the Web
Challenges and Future Work
ICS-FORTH Slide 290Stephanidis, Savidis & Akoumianakis
Challenges and Future Work
Software development processIdentifying diversityDesigning for diversityComputing platforms and embedded OSConcluding remarks
Stephanidis, Savidis, AkoumianakisPage 146UAHCI 2001
ICS-FORTH Slide 291Stephanidis, Savidis & Akoumianakis
Software Development Process(1/7)
• Unified interface development is a new interface development strategy aiming to cope with diversity on users and usage-contexts– There are specific technological steps
which will move us closer to unified interfaces
ICS-FORTH Slide 292Stephanidis, Savidis & Akoumianakis
Software Development Process(2/7)
• Employment of component-ware technologies through which prefabricated dialogues are delivered– e.g. ActiveX, JavaBeans, OpenDOC
Stephanidis, Savidis, AkoumianakisPage 147UAHCI 2001
ICS-FORTH Slide 293Stephanidis, Savidis & Akoumianakis
Software Development Process(3/7)
• Bridges among the various component technologies enabling interoperability– Ability to combine dialogue components
complying to different component-ware layers
ICS-FORTH Slide 294Stephanidis, Savidis & Akoumianakis
Software Development Process(4/7)
• Development of dialogue component repositories / directoriessupporting indexing and queryingon the basis of design parameters– sub-task(-s)– user- / context- attributes– other
Stephanidis, Savidis, AkoumianakisPage 148UAHCI 2001
ICS-FORTH Slide 295Stephanidis, Savidis & Akoumianakis
Software Development Process(5/7)
• Standardisation of user-oriented information, and production of universal user-profile databases– Legal issues are involved, so that
permissions and access restrictions can be managed or regulated by users themselves
ICS-FORTH Slide 296Stephanidis, Savidis & Akoumianakis
Software Development Process(6/7)
• Representation and deployment of design logic in computable forms, to enable run-time design assembly– Production of design knowledge-bases,
supporting querying by criteria matching, and exploration, to enable re-usability
Stephanidis, Savidis, AkoumianakisPage 149UAHCI 2001
ICS-FORTH Slide 297Stephanidis, Savidis & Akoumianakis
Software Development Process(7/7)
• Standardisation of adaptation-oriented s/w interface reference architectures– Proposals for specific inter-component
communication protocols and functional behaviour • i.e. such as the unified architecture
communication protocol
ICS-FORTH Slide 298Stephanidis, Savidis & Akoumianakis
Challenges and Future Work
Software development process
Identifying diversityDesigning for diversityComputing platforms and embedded OSConcluding remarks
Stephanidis, Savidis, AkoumianakisPage 150UAHCI 2001
ICS-FORTH Slide 299Stephanidis, Savidis & Akoumianakis
Identifying Diversity (1/2)
• How do we reveal those human-personality related parameters which are likely to affect the way interaction should be delivered ?
ICS-FORTH Slide 300Stephanidis, Savidis & Akoumianakis
Identifying Diversity (2/2)
• Is it possible practically, theoretically or legally to make such information available to a s/w system ?
Stephanidis, Savidis, AkoumianakisPage 151UAHCI 2001
ICS-FORTH Slide 301Stephanidis, Savidis & Akoumianakis
Identifying Diversity -Example
• User anxious, in a hurry, tired, does not understand the interface feedback– Body language analysis ?– Heart-beat rate monitoring ?– Facial expression analysis ?
• In this politically correct ?
ICS-FORTH Slide 302Stephanidis, Savidis & Akoumianakis
Challenges and Future Work
Software development processIdentifying diversity
Designing for diversityComputing platforms and embedded OSConcluding remarks
Stephanidis, Savidis, AkoumianakisPage 152UAHCI 2001
ICS-FORTH Slide 303Stephanidis, Savidis & Akoumianakis
Diversity-Based Optimal Design(1/2)
• Given individual attributes are known, how do we design in an optimal manner for those ?
ICS-FORTH Slide 304Stephanidis, Savidis & Akoumianakis
Diversity-Based Optimal Design(2/2)
• How do we decide that differentiation of design artifacts is dictated when some individual attribute values differ ?
Stephanidis, Savidis, AkoumianakisPage 153UAHCI 2001
ICS-FORTH Slide 305Stephanidis, Savidis & Akoumianakis
Challenges and Future Work
Software development processIdentifying diversityDesigning for diversity
Computing platforms and embedded OSConcluding remarks
ICS-FORTH Slide 306Stephanidis, Savidis & Akoumianakis
Computing Platforms and Embedded OS (1/4)
• The installation of embedded OS in various computing platforms, e.g. phones, home appliances, home electronics, public terminals, moves us away from the h/w manufactured applications and services (including the User Interface)
Stephanidis, Savidis, AkoumianakisPage 154UAHCI 2001
ICS-FORTH Slide 307Stephanidis, Savidis & Akoumianakis
Computing Platforms and Embedded OS (2/4)
• Software firms are enabled to deliver competitive s/w for new computing platforms, while users have choices from a collection of alternative interactive s/w applications
ICS-FORTH Slide 308Stephanidis, Savidis & Akoumianakis
Computing Platforms and Embedded OS (3/4)
• The separation between the h/w producer and the service developer opens new opportunities for interactive s/w, over a large variety of computing platforms
Stephanidis, Savidis, AkoumianakisPage 155UAHCI 2001
ICS-FORTH Slide 309Stephanidis, Savidis & Akoumianakis
Computing Platforms and Embedded OS (4/4)
• An example:– We buy a mobile phone, and then we
purchase the s/w we need:• a phone-book from W • an agenda from X• a Web-browser from W, and • a remote file-manager from Z
ICS-FORTH Slide 310Stephanidis, Savidis & Akoumianakis
Challenges and Future Work
Software development processIdentifying diversityDiversity-based optimal designComputing platforms and embedded OS
Concluding remarks
Stephanidis, Savidis, AkoumianakisPage 156UAHCI 2001
ICS-FORTH Slide 311Stephanidis, Savidis & Akoumianakis
Concluding Remarks(1/3)
• The Information Society is characterised by a considerable diversity in users and usage contexts
• Accessible and high-quality of interaction is crucial to ensure that anyone,anywhere and at anytime is enabled to use interactive s/w applications and services
ICS-FORTH Slide 312Stephanidis, Savidis & Akoumianakis
Concluding Remarks(2/3)
• Design differentiation is necessary to address diversity – no single design can satisfy the needs of all users
in all usage-contexts• Unified User Interface Development
aims to address those challenges through a systematic interface design and engineering process, pursuing automatic user interface adaptation
Stephanidis, Savidis, AkoumianakisPage 157UAHCI 2001
ICS-FORTH Slide 313Stephanidis, Savidis & Akoumianakis
Concluding Remarks(3/3)
• During the design phase, the Unified User Interface development mainly affects the artifact organisation process, rather than the artifact generation approach
• During the engineering phase, it mainly affects the software architecture, and dialogue component organisation, rather than the dialogue implementation approach
• These factors contribute to low deployment cost