Generating AUIs from Task and Domain Models
•Download as PPTX, PDF•
0 likes•348 views
An abstract user interface is defined according the Came¬leon Reference Framework as a user interface supporting an interactive task abstracted from its implementation, independently of any target computing platform and interaction modality. While an abstract user interface could be specified in isolation, it could also be produced from various models such as a task model, a domain model, or a combination of both, possibly based on information describing the context of use (i.e., the user, the platform, and the environment). This paper presents a general-purpose algorithm that systematically generates all potential abstract user interfaces from a task model as candidates that could then be refined in two ways: removing irrelevant candi-dates based on constraints imposed by the temporal operators and grouping or ungrouping candidates according to constraints imposed by the context of use. A model-driven engineering environment has been developed that applies this general-purpose algorithm with multiple levels of refinement ranging from no contextual consideration to full-context consideration. This algorithm is exemplified on a some sample interactive application to be executed in various contexts of use, such as different categories of users using different platforms for the same task.
Recommended
Recommended
More Related Content
Similar to Generating AUIs from Task and Domain Models
Similar to Generating AUIs from Task and Domain Models (20)
More from Jean Vanderdonckt
More from Jean Vanderdonckt (20)
Recently uploaded
Recently uploaded (20)
Generating AUIs from Task and Domain Models
- 1. 27/06/2012 1 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 2. • Motivations and related works • AUI generation workflow and its principal components • Conclusion • Demo 27/06/2012 2 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 3. • Today, there exists many ways for generating an Abstract UI (AUI) from different sources such as: • Task model • Domain model (more than a mere data model) • Context model • Consequences • Heterogeneity of techniques • No coverage of all possible AUIs at once 27/06/2012 3 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 4. IKnowU: expert system for deciding AUIs based on rules 27/06/2012 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012) 4
- 5. Generating AUIs based on discourse model 27/06/2012 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012) 5
- 6. ROAM: Generating AUIs based on task model 27/06/2012 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012) 6
- 7. Dygimes: Generating AUIs based on task model 27/06/2012 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012) 7
- 8. • Generating the abstract user interfaces for multiple platforms based on: • Task model • and domain model. 18-03-22 8
- 9. Principal components 27/06/2012 9 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 10. AUI generation workflow 27/06/2012 10 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 11. Task and domain models 27/06/2012 11 Contacts task model Contacts domain model EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 12. AUI generation workflow • Link tasks to domain’s components 27/06/2012 12 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 13. AUI generation workflow • Link tasks to domain’s components 27/06/2012 13 An example of linking tasks to domain components EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 14. AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks 27/06/2012 14 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 15. AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks 27/06/2012 15 Tasks in Contact task model are assigned weights based on the task types EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 16. AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups 27/06/2012 16 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 17. AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups 27/06/2012 17 An example of task grouping An example of operator check EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 18. 27/06/2012 18 AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups • Assign weights for the platforms EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 19. AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups • Assign weights for the platforms • Generate configurations 27/06/2012 19 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 20. AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups • Assign weights for the platforms • Generate configurations 27/06/2012 20 The configuration is generated for Palm platform EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 21. 27/06/2012 21 AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups • Assign weights for the platforms • Generate configurations • Generate abstract user interface EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 22. 27/06/2012 22 AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups • Assign weights for the platforms • Generate configurations • Generate abstract user interface Rule1: An AbstractSelectionUI is considered when a task derives from an attribute of a domain class which is not the edited class and the relationships between the edited class and another one is ‘1-1’ or ‘n-1’and . Rule2: An AbstractInputUI is considered when a task derives from the attributes of the classes that these classes are the edited classes. Rule3: An AbstractOutputUI is considered when an abstract user interaction has been created and its label is the task name of the task related to this abstract user interaction. Rule4: An AbstractDataItemUI is considered when a task derives from the attributes of the classes. Rule5: An AbstractTriggerUI is considered when a task derives from an operation of a class. For example. Once the tasks have been grouped by the developer based on the screen size of devices, the AUIs are generated automatically by system. EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 23. 27/06/2012 23 AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups • Assign weights for the platforms • Generate configurations • Generate abstract user interface AUI is generated from configuration specified above EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 24. 27/06/2012 24 AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups • Assign weights for the platforms • Generate configurations • Generate abstract user interface • Store generated AUIs into a xml file in terms of UsiXML specification EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 25. • Providing a general process for systematically generating abstract user interfaces from the task and the domain models is necessary, but not sufficient • Providing a palette algorithms for specifying abstract user interface types and configurating these abstract user interfaces is definitely a plus • Implementing a software that supports this process is important for maximal usage • Import/export facilities need to be elaborated (for the moment, only UsiXML is supported) 27/06/2012 25 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 26. Demonstration: https://www.youtube.com/watch?v=KoY6KxkVzAU&feature=g-upl 27/06/2012 26 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
- 27. Thank you very much for your attention! Any question? See more at: www.usixml.org, www.usixml.eu www.lilab.eu, www.lilab.be 27/06/2012 27 EICS'2012 (Copenhagen, Denmark, June 25-28, 2012)
Editor's Notes
- Good morning, Today I would like to present a new approach for generating the abstract user interface from the task and domain models It is “Systematic Generation of Abstract User Interfaces”
- The presentation is structrured by the following manners: Firstly, I will talk about the motivation which produces the subject of my research and the related works … Secondly, I will present you the workflow of the abstract user interface generation and its principal components Then next, I will talk about the conclusion of my work Finally, I finish my presentation by a demo
- The motivation of our work comes from the following important points.
- To highlight the issues raised above, we present some major processes of abstract user interface generation. These processes differ from each other in terms of input information such as task model, discourse model and domain model. IknowU is an expert system for deciding AUIs based on the rules. These rules rules concern device characteristics (i.e. space), user preferences, contextual issues.
- Bogdan et al use discourse models to generate different abstract user interfaces for different target devices such as cell phone, PC or PDA. Discourse model is used to describe the human communicative acts. The figure shows a discourse model that presents information about an animal selected by the user from a map.
- Unlike two previous approaches, in ROAM sytem, the AUI is generated based on task model. In order to generate the different AUIs for the different plaforms, the UI designer has to create the different layout structures; one layout structure created is suitable to one platform. The figure depicts the associations between task model and a concrete layout.
- Not in the paper
- So the objectives of my research is to generate the abstract user interface for multiple platforms such as desktop, mobile phone, palm based on the task and domain models. In our process, the task and domain models are adopted for the following reasons: The Task model describes the abstract user interface which is independent of the platform, the devices and the environment. The Domain model provides the special features for creating the user interface: such as specifying the Abstract user interface type, the size
- Here are the principal components of AUI generation process including three process-roles (UI developer, UI designer and System) and six workproducts (Mapping rules, platform information, Algorithm document, task model, domain model and Aui model).
- Here is our AUI generation process This process is divided into 7 steps depending on the role of participants and tasks that they perform This process will be presented step by step. In each step, I will do an example to show you how this step is performed.
- Firstly, I show you the task and domain models used in our examples. The task model discribes a contact management system which allows user to add a new contact, to modify an existing one or to search a phone number based on the first name and last name. The components are show in this domain model are the ones that relates to the tasks in « contacts » task model. But in practice, the domain model is bigger than this one.
- The process starts with linking the tasks to domain’s components. Once, the task and domain model have been loaded, the UI developer will link the tasks in task model to the component of domain model.
- The developer makes the links based on the task types: for example: interaction task type is linked to the domain’s object (in this example, it is « category » task); application task type is linked to the attribute « in this exmple, they are « first name», « last name », « phone number » tasks; the action task type is linked to the method (in this example, they are « modify », « add contact » … tasks).
- The weight of task are automatically assigned by the system.
- Each task in task model is assigned a weight depending on its task type. The weight is estimated by the UI designer. This value is constant for all platforms. Let’s assume that we have four task types and each one has a weight as depicting in Table. So the task weights in “contact” model are depicted in the figure.
- Now, the tasks will be grouped together based on the operators between them. This phase is decomposed in two sub-steps.
- The first one tries to find all of the possible groups of tasks without examining operators between these tasks (see the first figure). But in practice, tasks can also exclude each other so they cannot be grouped together So in the second one, the unsuitable task groups will be rejected from the ones created in the first sub-step by checking operators between the tasks (see the second figure). In this example, the “Submit” task and “Modify” task can not be grouped together.
- Similar to assign weight for the tasks. In this step, the UI designer will assign weights for the platforms based on platform information. Usually, this weight is in direct ratio to the screen’s size, the power of processor and memory, screen type ...
- Once the tasks have been grouped and the platform has been assigned a weight, the system automatically specifies the configurations by selecting one or more task groups. The system generates the different configurations for the different platforms.
- Here is an example of configuration generation. The figure depicts the configuration of contacts for a task model with a device weight of 11
- AUIs are generated based on the mapping rules and the task groups specified above.
- Here are the rules for determining the abstract user interaction type.
- AUI is automatically generated by the system.
- And finally, the user can store generated AUIs into a xml file in terms of UsiXML specification.
- The editor tool has been implemented in Java. Now I will do a small demo to show you how our AUI generation process works.