a Model-driven development methodology for 3D User Interface for Information Systems in a Principle based way
Upcoming SlideShare
Loading in...5
×
 

a Model-driven development methodology for 3D User Interface for Information Systems in a Principle based way

on

  • 1,463 views

 

Statistics

Views

Total Views
1,463
Views on SlideShare
1,452
Embed Views
11

Actions

Likes
0
Downloads
34
Comments
0

2 Embeds 11

http://www.slideshare.net 10
http://www.onlydoo.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • My motivation. Since I was a kid I always dream about being in a virtual reality. Of course at the time I did not refer to those spaces as they are technically known. I did my studies in computer sciences always with the goal of reaching my dream. So far, I think that I put the first stone to build that dream.
  • Nowadays, I am glad to see that 3D interaction is not anymore present in research labs and that we could virtually interact with other people by means of the virtual space. Several are the examples of the increasing presence of the 3D metaphor in desktop based systems such as the 3D effect in windows vista or web browsers. However, I do not like the fact that those metaphors are suddenly broke while interacting. For instance Space Time 3D shows a preview of the different web sites corresponding to your search but when you want to access to the web site, the metaphor in not consitant anymore and suddenly your are pop out the application and obliged to continue the interaction in 2D.
  • Even when we have pure 3D interaction, such as in this example of purchasing a sit in a stadium, a high detailed 3D object which can be generated only manually. Notice that the controls for buying the ticket need some work and can not be created by relying on a toolkit. The controls for such objects need some work that if you start from scratch would be time consuming. In order to contribute to build this kind of solutions we contruct a methodology for developing 3DUI.
  • First, we need to locate you in the context of the definitions. Whhat is a 3DUI. A user interface is know as the communication Channel for the Human to interact with a device. When it refers to 3D we meant that such interaction is by means of a 3D representation. They have been associated to different domain of application such as those in virtual reality, mixed reality, augmented reality, and 3D desktop environments. Similarly as a 2D UI a 3DUI can assist you in your daily life it is just a difference in the representation but of course relying on a 3D representation to replace its 2D counterpart has some pros and cons.
  • Let’s review first the advantages: They increase user satisfaction because they are really appreciated by a specific category of users, is a subjective preference that sometimes has been proved with statistical data. Also, cognitive perception of 3D objects are better comppared to 2D obejcts, users tend to remember better 3D than 2D UI, is part of our daily life to intereact in a 3D world so it is normal to have better understanding of a 3DUI rather than a 2DUI. 3D primitives are better compared to 2D representations [Carr03] Users tend to remember better objects shapes and location in 3D [Robe00]
  • Unfortunately there are also cons when using 3DUIS as a solution: studies have revelaed that they decrease user performance (oclusion, deep perception), among other reasons bacause they increase the manipulation complexity for an avarahe user, gain this is not for everybody, and neiteher for every task. As Bowman says « we are still looking for the problem to solve and the type of user interested in this. This is why we attemp to characterize the problem we want to solved and the population as follows:
  • The information Systems for the organization, addressing problems for administrative tasks, which are characterized by the routine and repetition. For this kind of task different interaction styles have identified, most of them has been depply explored but 3DUI has been poorly explored.
  • Always three axis are around my work, models, a method and a language, This is the case of the state of the art:
  • A series of comparative analysis were conducted on development methodologies, languages, transformational approaches, 3D Toolkits from which we learn in different proportions about the models, the laguage, the method and the software tool for the methodology.
  • Even more important from this review a series of shortcomings were identified which we wanted to addressed in the context of this dissertation vie a set of requirements, which were grouped into categories accordingly to the axis of the methodology.
  • When we first look at creating an intolgoy for 3DUIs our first impression was to specialized existing knowledge of 2D Uis because what is the difference between 2D and 3D? Our first impresion was that the second was just an specilization of 2D which means just adding
  • Then we got the model of what was known as 3d rendering of a 2D GUI, that corresponds to most of existing solution for 3D Uis. Being our model then we start to explore other dimmension for developing 3DUIs. An soon we realize that this model was good for this category of 3DUIs but was not accurate in other contexts.
  • Particularly because we wanted to explore the use of other modalities of interaction and multiple representations something that was not naturally possible with the existing model and more important crontavened the principle of separation of concerns.
  • So, after some iterations and exploration of different models and in collaboration with the a researcher of a greek lab of HCI
  • we create the 3DUI model that include concepts to express haptic interaction and different representations for 3D UIs
  • So, we have the models now we now a method to operate over the models, and for that
  • Implementation on specific devices (e.g. HTML, SVG or Java)
  • Thanks to the models all the layers can express concepts related to 3DUIs, including the transformations needed a round 85 transformations rules (25 old, 15 adapted, 45 new) Then we have the method for forward engineering development but we considered that we needed more deatils on how to operate the method, in which condisions take the correct design decision, when it was realted to 3DUI development. Even more, how to evaluate the results while progressing in the design?
  • Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
  • At the task model level to assist you on the correct selection of task attributes, based on examples and namespaces
  • For the selection of interaction facets, whether it is input, output, control, navigation or a combinatio of them.
  • Assistance for the correct selection of the concretization of the task but also to select the desirable representation.
  • For the selection of interaction facets, whether it is input, output, control, navigation or a combinatio of them.
  • There are some guidelines that can be encoded using a computer based format and that can be tested in order to prevent the code generation and time wasted while evaluating a 3DUI with usability problems
  • So, we have the models now we now a method to operate over the models, and for that
  • Our contribution could be added to other UIDLs, such as XIML, UIML, but this requires that the consortium leading these languages (companies) will adhere to that. Companies are often reluctant to do this because of Ownership
  • So, we have the models now we now a method to operate over the models, and for that
  • Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
  • Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
  • Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
  • Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
  • Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
  • What it makes difference is that we did not just implement some replication of 2D GUI but there are some innovation on the representation of different 3DUI widgets
  • So, we have the models now we now a method to operate over the models, and for that
  • clearly explain the difference between normal user (see virtual reality scene made of widgets) and sight-impaired user (manipulate the haptic part of each widget or hapget). In other words, say that you have introduced here the concept of hapget, haptical extension of a widget.
  • Show the layout of the FMS as it is today, the main goal is to change the interface of this alphanumeric UI into a GUI wityh 3D effects
  • Show the layout of the FMS as it is today, the main goal is to change the interface of this alphanumeric UI into a GUI wityh 3D effects
  • Show the layout of the FMS as it is today, the main goal is to change the interface of this alphanumeric UI into a GUI wityh 3D effects
  • So, we have the models now we now a method to operate over the models, and for that
  • (To reinfor(Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams)ced the systematic design of task models and provide substantial information to support the transformational approach) (Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams) (A sanity check of the AUI model that end in a consolidated version)
  • The Domain model is a description of the classes of objects manipulated by a user while interacting with a system. The domain model is composed of DomainSubModel, which is a way to represent a domain model that at the same time can be composed of a different domain sub-model. For instance, Java packages where different submodels can be within a model and they can be associated to different domain facets. A DomainElement describes the characteristics of a set of objects sharing a set of common properties. It can ca composed of DomainItem and DomainCollections. A DomainItem is an atomic unit of data, i.e. which cannot be decomposed further. The DomainItem has an attribute called itemType denoting a data type, such as, but not limited to: Boolean, hour, date, natural, integer, real, character, string. A DomainCollection expresses the notion of data collection, i.e. how to collect individual domain items into a structured format; it can be composed of DomainCollections . A concrete example of a collection of collections is a table. The DomainCollection can be composed of DomainItems . A concrete example of a collection of items is a comboBox. The DomainCollection attribute called collectionType denotes any data structure, such as, but not limited to: set, list, stack, tree, binary tree, shared tree, matrix.   The DomainRelationship describes various types of relationships between domain elements. They can be classified in two types: Constraint and FunctionalDependency . The Constraint relationship is self descriptive as it refers to constraints that affect to DomainElements. The Constraint is described with the condition attribute that specifies a condition attached to a constraint, i.e., a rule that must be fulfilled in the specification before or after the application of a Constraint. The Constraint is specialized in:   Existence denoting the constraint for one DomainElement to consider the existence of another DomainElement, this is specialized in a ValueConstraint, for instance , to pay a flight ticket the user must have inserted their payment method . Relevance denoting the relevance or importance of a DomainElement compared to another DomainElement. For instance, in a webmail site the login box is more relevant than the welcome box. CardinalityConstraint denoting the cardinality constraint from one DomainElement to another. For instance, on an ecommerce application the shopping cart has a cardinality constraint to have at least one item when passing to the check out section. ReplicationConstraint denoting the constraint of replicating one DomainElement into another DomainElement.   The FunctionalRelationship denotes the relationship between two DomainElements A and B bounded by a functional dependency if and only if for each value of A, there is at most one value of B. A is called the determinant element, while B is called determined element. This relationship is described with the attribute semanticFunction that is the name of a method belonging to the semantic core of the interactive application, such as any method from a class.
  • (To reinfor(Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams)ced the systematic design of task models and provide substantial information to support the transformational approach) (Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams) (A sanity check of the AUI model that end in a consolidated version)
  • (To reinfor(Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams)ced the systematic design of task models and provide substantial information to support the transformational approach) (Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams) (A sanity check of the AUI model that end in a consolidated version)
  • (To reinfor(Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams)ced the systematic design of task models and provide substantial information to support the transformational approach) (Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams) (A sanity check of the AUI model that end in a consolidated version)
  • In the state of the art we have identify some significant work, and we now have explicit trnaformation accordingly to MDA which was our goal
  • Usually, we can say that expected benefits of Model-Driven Engineering (MDE) can be subsumed as follows: 1. Benefits resulting from the existence of a design phase: • Reducing the gap between requirements and implementation: A design phase aims to ensure in advance that the implementation really addresses the customer’s and user’s requirements. • Developer coordination: Previous planning of the developed system enables the developers to coordinate their work e.g. by dividing the system into several parts and defining interfaces between them. • Well-structured systems: A design phase provides explicit planning of the system architecture and the overall code structure. This facilitates implementation itself as well as maintenance. 2. Benefits resulting from the use of visual abstract models: • Planning on adequate level of abstraction: Modeling languages provide the developer concepts for planning and reasoning about the developed system on an adequate level of abstraction. • Improved communication by visual models: The visual character of modeling languages can lead to increased usability (understanding, perceiving, exploring, etc.,) of design documents for both author and other developers. • Validation: (Semi-)Formal modeling languages enable automatic validation of the design. • Documentation: Models can be used as documentation when maintaining the system. • Platform-independence: Platform-independent models can be reused or at least serve as starting point when implementing the system for a different platform. This includes development platforms like a programming language or component model, as well as deployment platforms like the operating system or target devices. 3. Benefits resulting from code generation: • Enhanced productivity: Generating code from a given model requires often only a teeny part of time compared to manual mapping into code. • Expert knowledge can be put into the code generator: Expert knowledge – e.g. on code structuring, code optimizations, or platform-specific features – can once be put into the code generator and then be reused by all developers. • Reduction of errors: Automatic mapping prevents from manual errors. 4. Meta goals: Easier creation and maintenance of development support • Knowledge about creation of modeling languages: MDE concepts and definitions reflect existing knowledge about modeling, modeling languages, and code generation. • Frameworks and tools: Tools like Eclipse Modeling Tools (p. 27) provide sophisticated support for all steps in MDE like creating and processing metamodels, creating modeling editors, and defining and executing transformations. • Maintenance of modeling language and transformations: Systematic and explicit definition of metamodels and transformations facilitates maintenance of modeling languages and code generators. • Reuse of metamodels and transformations: MDE compliant explicit metamodels and transformations can easily be understood and reused by others.

a Model-driven development methodology for 3D User Interface for Information Systems in a Principle based way a Model-driven development methodology for 3D User Interface for Information Systems in a Principle based way Presentation Transcript

  • Unused Section Space 1 A Model-Driven Approach for Developing 3D User Interfaces of Information Systems in a Principle–Based Way Juan Manuel González Calleros PhD Public Defense February 4, 2010 - LLN
  • February 4, 2010 - LLN PHD Public Defense Virtual Reality Augmented Reality
  • February 4, 2010 - LLN PHD Public Defense Windows Vista
  • February 4, 2010 - LLN PHD Public Defense
      • Locate your sit in a stadium
  • Outline
    • Introduction
    • State of the Art
    • Methodology
      • Ontology
      • The Method
      • Towards a UIDL for 3DUI
      • Software for Supporting the Methodology
    • Validation
    • Conclusion
    February 4, 2010 - LLN PHD Public Defense
  • What is a 3D User Interfaces? February 4, 2010 - LLN PHD Public Defense Augmented Reality Virtual Reality 3D User Interface 3D desktop environments
  • Why 3D User Interfaces?
    • Increase user satisfaction.
    • Improve cognitive perception
    • Indices sense of (tele)presence
    • 3DUIs are not automatically superior or inferior to 2DUIs.
    February 4, 2010 - LLN PHD Public Defense
  • Why NOT 3D User Interfaces?
    • Decrease user performance
    • Increase manipulation complexity for an average user
    • Are not appropriate for any task
    • Are hard to evaluate for their usability
    February 4, 2010 - LLN PHD Public Defense
  • Focus of the dissertation
    • Information systems (data, process, resources)
    • Administrative tasks (routine, repetition)
    • Interaction styles (form filling, multi-windowing, direct manipulation, iconic interaction, graphic interaction, multimedia interaction, and 3DUIs)
    February 4, 2010 - LLN PHD Public Defense
  • Thesis Statement
    • In this thesis we argue that developing 3DUIs for Information Systems is an activity that would benefit from the application of a methodology which is typically composed of:
        • a set of models gathered in an ontology,
        • a method manipulating the involved models based on guidelines,
        • a language that express models in the method.
    • Define a model-driven approach for structuring the development life cycle of a Three-Dimensional User Interface of an Information System in a principle based way.
    February 4, 2010 - LLN PHD Public Defense
  • Comparative analysis February 4, 2010 - LLN PHD Public Defense
    • 3DUI development methodologies
    • Language
    • Transformation Engines
    • 3D Toolkits
    • Models
    • Language
    • Methods
    • Software tools
  • Requirements
    • Methodological (7)
    • Ontological (3)
    • Language (1)
    • Software tool support (1)
    • Methodological support for the development life-cycle of 3DUI for Information Systems
    February 4, 2010 - LLN PHD Public Defense
  • Outline
    • Introduction
    • State of the Art
    • Methodology
      • Ontology
      • The Method
      • Towards a UIDL for 3DUI
      • Software for Supporting the Methodology
    • Validation
    • Conclusion
    February 4, 2010 - LLN PHD Public Defense
  • February 4, 2010 - LLN PHD Public Defense
    • 3D UI as an specialization of 2D
    • Benefits:
      • Relying on existing 2D UI by specializing
      • Factoring out 3D vs 2D UIs
    VS.
  • February 4, 2010 - LLN PHD Public Defense 3D Rendering of a 2D GUI VUITOOLKIT [Moli08]
  • February 4, 2010 - LLN PHD Public Defense
    • Shortcomings:
        • Adding another modality breaks the factoring out
        • Hard to provide multiple representations of 3D objects
        • No full separation of concerns
  • February 4, 2010 - LLN PHD Public Defense
    • Shortcomings:
        • Adding another modality breaks the factoring out
        • Hard to provide multiple representations of 3D objects
        • No full separation of concerns
  • February 4, 2010 - LLN PHD Public Defense Support for different representations Support for basic Haptic Interaction 3DUIs
  • Outline
    • Introduction
    • State of the Art
    • Methodology
      • Ontology
      • The Method
      • Towards a UIDL for 3DUI
      • Software for Supporting the Methodology
    • Validation
    • Conclusion
    February 4, 2010 - LLN PHD Public Defense
  • Method Outline February 4, 2010 - LLN PHD Public Defense Task and Domain Model Model to Model Abstract UI Model Model to Model Concrete UI Model Code Generation Final UI Control Task and Domain Model Physical Control Software Control Physical interaction object 2D 3D
  • February 4, 2010 - LLN PHD Public Defense Task and Domain Model Model to Model Abstract UI Model Model to Model Concrete UI Model Code Generation Final UI
    • A structured catalog of transformation rules that form a body of design knowledge that can be reused in any 3D method
  • February 4, 2010 - LLN PHD Public Defense Code Generation Final UI Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
    • A set of Principles were added to the method
      • Guidelines
      • Task patterns
      • Canonical list of task types
  • February 4, 2010 - LLN PHD Public Defense
      • Canonical list of task types
    Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
  • February 4, 2010 - LLN PHD Public Defense
      • Facet Selection
    Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
  • February 4, 2010 - LLN PHD Public Defense Select Element Input Slider
      • AIO Selection
    Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
  • February 4, 2010 - LLN PHD Public Defense
      • Graphical representation selection
    Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
  • February 4, 2010 - LLN PHD Public Defense
      • Automatic guidelines evaluation
    Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
  • February 4, 2010 - LLN PHD Public Defense
  • Outline
    • Introduction
    • State of the Art
    • Methodology
      • Ontology
      • Method
      • Towards a UIDL for 3DUI
      • Software for Supporting the Methodology
    • Validation
    • Conclusion
    February 4, 2010 - LLN PHD Public Defense
    • Language Engineering Approach
      • Semantics – Meta Models, UML Class diagrams
      • Syntax
        • Abstract – XML Schema
        • Concrete – XML
      • Stylistics – Different graphical representations of the concepts
    February 4, 2010 - LLN PHD Public Defense
    • UsiXML
      • Structured accordingly to the Model Driven paradigm
      • UsiXML relies on a transformational approach
      • UsiXML allows the modification of the developments steps
      • UsiXML allows reusing parts of previously specified
      • UsiXML is open
      • Follows a Language Engineering Approach
    February 4, 2010 - LLN PHD Public Defense
  • Outline
    • Introduction
    • State of the Art
    • Methodology
      • Ontology
      • Method
      • Towards a UIDL for 3DUI
      • Software for Supporting the Methodology
    • Validation
    • Conclusion
    February 4, 2010 - LLN PHD Public Defense
  • February 4, 2010 - LLN PHD Public Defense Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
      • IdealXML
  • February 4, 2010 - LLN PHD Public Defense Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
      • YATE
  • February 4, 2010 - LLN PHD Public Defense Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
      • TransformiXML
  • February 4, 2010 - LLN PHD Public Defense Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
      • UsabilityAdvisor
  • February 4, 2010 - LLN PHD Public Defense Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
  • February 4, 2010 - LLN PHD Public Defense
  • February 4, 2010 - LLN PHD Public Defense
  • Outline
    • Introduction
    • State of the Art
    • Methodology
      • Ontology
      • Method
      • Towards a UIDL for 3DUI
      • Software for Supporting the Methodology
    • Validation
    • Conclusion
    February 4, 2010 - LLN PHD Public Defense
  • February 4, 2010 - LLN PHD Public Defense Case Study Complexity Man/Month LOC Context Polling System + 6 6, 000 VRML Information Systems Student Trainer System + 6 3, 000 X3D Information Systems Haptic Browser ++ 4 (collaboration) 0 Information Systems Visual Impair users AHMI +++ 48 2, 000 X3D 10, 000 + Open GL Information Systems Aeronautics
  • February 4, 2010 - LLN PHD Public Defense
    • Polling System. Devoted to the development of an opinion polling system.
  • February 4, 2010 - LLN PHD Public Defense
    • Hapget = 3D widget + haptic feedback
  • February 4, 2010 - LLN PHD Public Defense
    • Haptic Browser- Google web site. Rendering of web site in the haptic web browser.
  • February 4, 2010 - LLN PHD Public Defense
    • The AFMS is a text-only system that calculates the exact route of the aircraft along a given list of waypoints considering possible altitude, time or speed constraints.
    • After a trajectory is generated and successfully negotiated with ATC the AFMS can generate input commands for the autopilot and thus control the aircraft in space and in time.
  • February 4, 2010 - LLN PHD Public Defense
    • The AFMS application is controlled via the Advanced Human Machine Interface (AHMI), the main application of the target system to be investigated in the HUMAN project
  • February 4, 2010 - LLN PHD Public Defense
    • Problems :
      • Discontinuity with the rest of the environment
      • Difficult to modify due to its Complexity
      • Usability guidelines
      • Widgets have a 3D nature in the context of a cockpit
  • February 4, 2010 - LLN PHD Public Defense
    • Our goal is to provide a 3D Advanced Human Machine Interface.
      • New se t of CUI models
      • Consolidation of existing models
      • New application domain
  • External evaluation February 4, 2010 - LLN PHD Public Defense
  • External evaluation February 4, 2010 - LLN PHD Public Defense
    • Final rendering – Feedback from the haptic browser
      • Difficult recognition of some hapgets.
      • Lack of user preference adaptation
      • Limited exploitation of the haptic characteristics
      • Long sentences to provide a value
      • Size of hapgets
      • Speech recognition problems
      • Sound become annoying
      • Slow loading
  • Outline
    • Introduction
    • State of the Art
    • Methodology
      • Ontology
      • Method
      • Towards a UIDL for 3DUI
      • Software for Supporting the Methodology
    • Validation
    • Conclusion
    February 4, 2010 - LLN PHD Public Defense
    • We introduced a 3DUI Development Methodology articulated on three axes:
      • Models
      • Method
      • Language
    February 4, 2010 - LLN PHD Public Defense
    • Models (More than 200 attributes, 90 classes, 100 relationships)
      • Task: Canonical list of task types and guidelines for task modeling.
      • Domain Model: Improving existing Domain Model that will be considered for the NexOF-RA the European standardization process
      • AUI: Improving existing AUI Model that will be considered for the NexOF-RA The European standardization process
      • CUI: Enriching CUI Model by adding haptic support, separation of concerns 2D vs 3D by specialization. 3D support. Hapgets ( set of 3D widgets enhanced with haptic feedback)
    February 4, 2010 - LLN PHD Public Defense
  • February 4, 2010 - LLN PHD Public Defense Domain Model AUI Model Integrates 3DUI in the context of MBUI development Incubator group Integrates new concepts to their ontology based on UsiXML http://www.w3.org/2005/Incubator/model-based-ui/wiki/Main_Page http://forge.morfeo-project.org/wiki_en/index.php/Interactive_Application_Models
    • Methodological aspects adheres to the MDE paradigm. Models and transformations are explicitly defined and used (Around 85 transformations rules)
      • Step 1: Task and concepts (T&C) definition
        • Task and Concepts Consolidation
        • Selection of task types, items and user categories
        • Guidelines of best-practices for structuring task models
      • Step 2: From T & C to Abstract UI (AUI) Model
        • Identification of abstract UI structure
        • Selection of AIC
        • Spatio-Temporal arrangement of abstract interaction objects
        • Definition of abstract dialog control
        • Derivation of AUI to domain mappings
      • Step 3: From AUI to CUI Model
        • Reification of AC into CC
        • Selection of CICs
        • Selection of the graphical representation of the CIC
      • Step 4: From CUI to FUI Model
    February 4, 2010 - LLN PHD Public Defense
    • All aspects are stored in UsiXML files that can be exchanged, shared, and communicated between stakeholders (designers, developers, and end users).
    • Advantages of this language were discussed
      • Modifiability
      • Complexity
      • Rigorous.
      • Reasoning.
      • Processable.
    • Adopt a Language Engineering Approach
      • Semantics – Meta Models
      • Syntax
        • Abstract – XML Schema
        • Concrete – XML
      • Stylistics – Different graphical representations of the concepts
    • Our contribution is independent of UsiXML
    February 4, 2010 - LLN PHD Public Defense
    • Five Software modules are used to support the methodology.
      • Conceptual definition of the tools.
      • Supervising of their development
      • Testing with our case studies the performance of the tools
    • Final rendering (48 men/month, more than 10, 000 LOC)
    February 4, 2010 - LLN PHD Public Defense
  • February 4, 2010 - LLN PHD Public Defense
  • Benefits from our methodology February 4, 2010 - LLN PHD Public Defense MDA Expected Benefits Reducing the gap between requirements and implementation Developer coordination. Dividing the system into several parts and defining interfaces between them Well-structured systems. This facilitates implementation itself as well as maintenance. Planning on adequate level of abstraction Improved communication by visual models Validation: (Semi-)Formal modeling languages enable automatic validation of the design Documentation: Models can be used as documentation when maintaining the system. Platform-independence. At least serve as starting point when implementing the system for a different platform Enhanced productivity. Expert knowledge can be put into the code generator Reduction of errors Knowledge about creation of modeling languages Frameworks and tools Maintenance of modeling language and transformations Reuse of meta-models and transformations
  • Future Work
    • External e valuation should be targeted to three: designers, developers and users:
      • User testing with control experiments in labs
      • Designer and developers
    • Extend the set of 3DUIs components.
    • Integrated development Environment
    • Explore Other dimensions of the Cameleon framework
    • Explore other context of use
      • Learning Objects
      • Augmented reality
    February 4, 2010 - LLN PHD Public Defense
  • Acknowledgements February 4, 2010 - LLN PHD Public Defense 2004 2009 2007 2008 2005 2006
    • UsiXML Consortium
    • The Information Systems Research Unit
    • The ALBAN program
    • The CONACYT program
    • The SIMILAR project
    • The Human project
    • The NexOF project
    • The Itea 2 UsiXML project
    • The Promep project
    _____________PhD _______________ ______DEA _______ 2010
  • Q&A February 4, 2010 - LLN PHD Public Defense