• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
 

Systematic Generation of Abstract User Interfaces

on

  • 581 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 ...

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.

Statistics

Views

Total Views
581
Views on SlideShare
581
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

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
  • Good morning,Today I would like to present a new approach for generating the abstract user interface from the task and domain modelsIt is “Systematic Generation of Abstract User Interfaces”
  • The presentation is structruredby 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 workflowof the abstract user interface generation and its principal componentsThen next, I will talk about the conclusion of my workFinally, 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.IknowUis an expert system for decidingAUIsbased on the rules.Theserulesrules 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.
  • Unliketwopreviousapproaches, in ROAMsytem, the AUI isgeneratedbased 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 thepaper
  • So the objectives of my research is to generate the abstract user interfacefor multiple platforms such as desktop, mobile phone, palm based on the task and domainmodels.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 generationprocessincluding 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 processThis process is divided into 7 steps depending on the role of participants and tasks that they performThis 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 domainmodelsused in ourexamples.The task model discribesa contact management system whichallows user to add a new contact, to modify an existing one or to search a phone numberbased on the first name and last name.The components are show in thisdomain model are the onesthat relates to the tasks in « contacts » task model. But in practice, the domain model isbiggerthanthis one.
  • Theprocessstartswithlinking the tasks to domain’s components.Once, the task and domain model have been loaded, the UI developerwilllink the tasks in task model to the component of domain model.
  • Thedevelopermakes the links based on the task types: for example: interaction task type islinked to the domain’sobject (in thisexample, itis « category » task); application task type islinked to the attribute « in thisexmple, they are «  first name», « last name », « phone number » tasks; the action task type islinked to the method (in thisexample, they are « modify », « add contact » … tasks).
  • The weight of task are automaticallyassigned 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 weightsin “contact” model are depicted in the figure.
  • Now, the taskswillbegroupedtogetherbased on the operatorsbetweenthem.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 togetherSo 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 assignweight for the tasks. In thisstep, the UI designer willassignweights for the platformsbased 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.
  • Hereis 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 storegeneratedAUIsinto a xml file in terms of UsiXMLspecification.
  • The editor tool has been implemented in Java. Now I will do a small demo to show you how our AUI generation process works.

Systematic Generation of Abstract User Interfaces Systematic Generation of Abstract User Interfaces Presentation Transcript

  • 27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 1
  • • Motivations and related works • AUI generation workflow and its principal components • Conclusion • Demo27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 2
  • • 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 once27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 3
  • IKnowU: expert system for deciding AUIs based on rules27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 4
  • Generating AUIs based on discourse model27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 5
  • ROAM: Generating AUIs based on task model27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 6
  • Dygimes: Generating AUIs based on task model27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 7
  • • Generating the abstract user interfaces for multiple platforms based on: • Task model • and domain model.26/06/2012 8
  • Principal components27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 9
  • AUI generation workflow27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 10
  • Task and domain models Contacts task model Contacts domain model27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 11
  • AUI generation workflow • Link tasks to domain’s components27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 12
  • AUI generation workflow • Link tasks to domain’s components An example of linking tasks to domain components27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 13
  • AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 14
  • AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks Tasks in Contact task model are assigned weights based on the task types27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 15
  • AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 16
  • AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups An example of task grouping An example of operator check27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 17
  • AUI generation workflow• Link tasks to domain’s components• Assign weights for the tasks• Create task groups• Assign weights for the platforms27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 18
  • AUI generation workflow • Link tasks to domain’s components • Assign weights for the tasks • Create task groups • Assign weights for the platforms • Generate configurations27/06/2012 EICS2012 (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 The configuration is generated for Palm platform27/06/2012 EICS2012 (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• Generate abstract user interface27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 21
  • AUI generation workflow• Link tasks to domain’s components 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 . weights for the tasks Assign• Create task groups Rule2: An AbstractInputUI is considered when a task derives from the attributes of the classes that these classes are the edited classes.• Assign weights for the platforms• Rule3: An AbstractOutputUI is considered whenabstract useruser interaction has been created and its Generate name of the task related to this an abstract interaction. label is the task configurations• Rule4: An AbstractDataItemUI is considered when a task derives from the attributes of the classes. Generate abstract user interface 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.27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 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 AUI is generated from configuration specified above27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 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• Store generated AUIs into a xml file in terms of UsiXML specification27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 24
  • • 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 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 25
  • Demonstration: https://www.youtube.com/watch?v=KoY6KxkVzAU&feature=g-upl27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 26
  • Thank you very much for your attention! Any question? See more at: www.usixml.org, www.usixml.eu www.lilab.eu, www.lilab.be27/06/2012 EICS2012 (Copenhagen, Denmark, June 25-28, 2012) 27