Towards Task-Based Linguistic Modeling for designing GUIs
•Download as PPTX, PDF•
2 likes•983 views
The document presents a linguistic task model for designing GUIs. It begins by discussing Nielsen's virtual communication protocol for interaction and how the linguistic task model is based on this. It then provides examples of how tasks can be modeled at different linguistic levels from goal to widgets. The linguistic task model employs a configurable state diagram to identify task input elements and allow relationships between tasks. It is argued to address limitations in existing task models. Finally, an example usage of the notation is shown to model searching for a flight.
Recommended
More Related Content
What's hot
What's hot (17)
Viewers also liked
Similar to Towards Task-Based Linguistic Modeling for designing GUIs
Similar to Towards Task-Based Linguistic Modeling for designing GUIs (20)
More from Jean Vanderdonckt
More from Jean Vanderdonckt (20)
Recently uploaded
Recently uploaded (20)
Towards Task-Based Linguistic Modeling for designing GUIs
- 1. Towards Task-Based Linguistic Modeling for designing GUIs Iyad Khaddam, Nesrine Mezhoudi, Jean Vanderdonckt Université catholique de Louvain Louvain School of Management (LSM) Place des Doyens, 1 – 1348 Louvain-la-Neuve (Belgium) iyad.khaddam@uclouvain.be
- 2. Agenda • What is the Linguistic perspective? • Yet another task model? • The Linguistic Task model • Example and Demo • Questions and answers Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 2
- 3. The Linguistic Perspective IHM’2015 Presentation (Toulouse, France, 29 October 2015) 3 • A perspective to develop GUIs • Aims at enhancing maintainability • Based on the Nielsen’s Virtual Protocol for Interaction
- 4. Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 4 Goal Pragmatic (Task) Semantic Syntactic Lexical Alphabetical Physical Goal Pragmatic (Task) Semantic Syntactic Lexical Alphabetical Physical Realizers Linguistic Classification of Interaction Nielsen’s Virtual Communication Protocol for Interaction (1986)
- 5. Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 5 Level Key GUI Concept at the level Goal Task UI Elements Semantic Syntax-time Containers and navigation elementsSyntax-Space Widgets UI WidgetsWidgets Properties -
- 6. 6
- 7. Example: Goal and Task levels Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 7 Fill Registration Information Pay Conference Fees Register for a conference Goal Task Finalize Order
- 8. Example: Goal and Task levels Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 8 Fill Registration Information Pay Conference Fees Register for a conference Goal Task Finalize Order
- 9. Example: Goal and Task levels Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 9 Fill Registration Information Pay Conference Fees Register for a conference Goal Task Pay Detailed Function Detailed Function Semantic
- 10. Example: The Semantic level Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 10 First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements Personal Information Conference Fees Regular Fee Discount Fee Student Fee Description for Discount Uploaded file name Upload letter Regular Fee Discount Fee Student Fee Description for Student University letter Uploaded file name Info msg: no file ……. Finalize Order
- 11. Example: The Syntax-Time Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 11 First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements Personal Information Conference Fees Regular Fee Discount Fee Student Fee Description for Discount Uploaded file name Upload letter Regular Fee Discount Fee Student Fee Description for Student University letter Uploaded file name Info msg: no file Finalize Order
- 12. Example: The Syntax-Space 12 style 1 style 2 First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements Personal Information Next Step First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements Personal Information Next Step
- 13. Example: The Widget level Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 13 First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements First Name Last Name Email Special dietary needs Detailed dietary needs Special Requirements Personal Information Next Step Label Text Box Drop-Down Button Panel
- 14. Example: The Widget Properties level 14
- 15. A Linguistic Modeling of GUIs Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 15 GM1 GM2 TM1 TM2 SM1 SM2 STM1 STM2 SSM1 SSM2 WM1 WM2 WPM1 WPM2 Goal Task Semantic Syntax-time Syntax-space Widgets Widgets Properties Two different abstractions/notations on the level Interface between the two levels
- 16. Agenda • What is the Linguistic perspective? • Yet another task model? • The Linguistic Task model • Example and Demo • Questions and answers Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 16
- 17. Linguistic Task model Requirements IHM’2015 Presentation (Toulouse, France, 29 October 2015) 17 R1: Well-defined criteria to separate goal and task levels. R2: Well-defined criteria to separate task and semantic levels. R3: A notation that supports identifying task input elements.
- 18. Review of existing task models Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 18 Task Model Stopping Criteria Linguistic Levels GOMS judgment calls : The analyst needs to decide when to stop relying on a psychological theory or model for how people do the work Covers Goal, Task and Semantic levels CTT may continue and stop at the granularity of identifying needed user input element Goal, Task, Semantic, K-MAD elementary action Goal, Task, Semantic R2: Task Decomposition Stopping Criteria
- 19. Review of existing task models Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 19 R2: Task Decomposition Stopping Criteria Guerrero’s Model: criteria are based on changes on the work environment .They are: Change of space: when the location of operations changes. Change of resource: a different resources is exploited. Resources are of types: • User • Material (Hardware) • Immaterial (Software) Change of time: a different time period in which the task is performed. Three type: • interruption • waiting point (decision or accumulation) • permanence of execution unit (synchronization point). Change of nature: tasks can have the following natures: • Manual, • Automatic • Interactive • Mechanical.
- 20. Review of existing task models Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 20 R3: A notation to identify task input elements • The widely used notation is the CTT notation, with variations in different task models • Temporal relations in CTT are not enough to identify task input elements. Search Select Flight No Airways Time 1 Jetair 12:30 2 Ryanair 14:50 3 EasyJet 18:45 Can we re-execute the search? Can the user change the already- selected flight?
- 21. Agenda • What is the Linguistic perspective? • Yet another task model? • The Linguistic Task model • Example and Demo • Questions and answers Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 21
- 22. The Linguistic Task Model IHM’2015 Presentation (Toulouse, France, 29 October 2015) 22 • Follows the HTA theory. • Categories of tasks: user, interactive, system, mechanical and abstract. • Employs a configurable task state diagram => identify task input elements.
- 23. The linguistic task state diagram Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 23 Created StartedOffered Destroyed Completed Suspended Repeat. If task is repeatable. Automatic destroy. IIf the task is created by another task cancel startoffer suspend complete resume State-full Rollback Stateless Rollback Creat e Errored recover error Manual state transitions identify task input elements State transitions can have a type: User, automatic or based on a condition.
- 24. Task Relations Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 24 Event, Condition and Action (ECA ) rules Event ON TS.State TS is the source task Condition TD.State= “value” TD is the destination task Action TD.Transition Example: ON Search_params.Completed If (Display_Flight.State=”Created”) Display_Flight.offer Search Params Display Flights On Completed offer State: Created
- 25. Task Repetition Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 25 Repetition can be implemented on a task T using relations like: On T.Completed If (true) T.create T is a dynamic task The decision to create a a dynamic task is either a system or a user task. A Justification to create a repetition task Repetition is implemented using repetition tasks as: On R.Completed If (true) T.create R is called a pumping task This would produce an infinite number of tasks
- 26. Agenda • What is the Linguistic perspective? • Yet another task model? • The Linguistic Task model • Example and Demo • Questions and answers Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 26
- 27. Example on using the notation 27 Search for flight Id Parent Task Justification Configuration 1 / Search for a flight Grouping Abstract, Stateless rollback, 2 1 Fill Search params. - Interactive, State-full rollback, canCancel=true 3 1 Display Flights Grouping Abstract, Stateless rollback, 4 3 Repeat on flights Repetition. System, Stateless rollback, repetitionTask=true 5 3 Display a Flight From 2: Change in nature: interactive->system System, Stateless rollback, canCancel=false 6 3 Select the Flight From 5: Decision point, System- >Interactive Interactive, Stateless rollback, canCancel=false 1. Search for flight 2. Fill Search Params. 3. Display Flights 4. Repeat on Flights 5. Display a flight 6. Select the flight On Completed offer On Completed create On Completed create Abstract User SystemRepetitive Dynamic Task Categories On Completed Complete On CompletedComplete Any
- 28. Demo Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 28
- 29. Thanks for listening Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 29
- 30. Questions? Louvain School of Management Presentation (Louvain-la-Neuve, 17 March 2015) 30
Editor's Notes
- Hello, My name is Iyad Khaddam. I’m here to present the linguistic task model. (click)
- First, i think many of you may question the need for another task model as we already have plenty. The anwser is yes we need a task model that fulfils requirements imposed by the linguistic perspective to design GUIs. So what is the linguistic perspective? (click) Thats the first item in this presentation to motivate the need for the linguistic task model. (click) The third item is to present the proposed linguisti task model and then we give an example on using this model and present a demo (click). I will try to finish as fast as i can to give more time to (click) questions and answers.
- The linguistic perspective is a perspective to develop GUIs with the aim at enhancing maintainability. It is based on Nielsen’s Virtul Protocol for Interaction. (click)
- In 1986, Jacob Nielsen introduced his Virtual Communication Protocol of Interaction. He aims to use his protocol to analyze the interaction between the human and the machine. His protocol employs a linguistic classification of the interaction (click). The protocol consists of seven levels (ordered by level of abstraction): goal, task, semantic, syntax, lexical, alphabetical and physical. These levels form a stack of interaction, where each lower level implements required services by the upper level (click) (realizes the upper level) . Therefore, the interaction is analyzed in a refined way from the goal to physical level. In a previous work, we turned this protocol from an analysis tool to a taxonomy tool to classify GUI concepts and artifacts. The taxonomy also classifies activities of developing a GUI on linguistic levels, like: Where to identify a task? Where to define navigation between containers? Where to define placement on the screen? The result is a classification of GUI concepts and elements on adapted levels from the original protocol. (click)
- The slide can read as: Identification of UI elements is at the task and semantic levels. On syntax-time, we define the navigation model using time-containers. On the syntax-space level, we define space containers to determine the placement of elements on the screen. The Widgets level maps UI elements to concrete widgets, and the widgets properties level sets the properties of these widgets. Let’s explain the Linguistic perspective through an example.
- Take the example of a GUI for registration to a conference. The end-user needs to fill registration information and then pay the fees (which is not shown on the slide). Registration information include the user’s personal information, registration type (regular, student or discounted fees), additional information if exists, and billing information. The goal of the user from using the GUI is: Register for a conference. This goal is further refined at the task level into two tasks: (click)
- “Fill registration information” and “Pay conference fees”. This is on the system side, but what about the user’s side? the user needs an input element (click) to carry out the task. When the user clicks the “Finalize order” (click)
- The related task completes and the « Pay Conference Fees » task is activated and displays an input elements to the user to carry out the task.
- On the semantic level, we need to define detailed functions to carry out the task (click). These detailed functions in turn identify all UI elements needed to carry out the task. The user at this level would have more UI elements to interact with to help in carrying out the task. (click)
- That is what the user sees at this level. Gery rectangles represent output elements while white rectangles represent input elements. Notice that the task input element « Finalize Order » is also visible because the task level produces this elements. This level will be further refined to the final GUI (click) on the left. Now let’s refine it on the syntax-time level (click)
- On the syntax-time: we define a correct distribution on time (with respect to environment constraints). We may have two styles: (1) Display UI elements at the same time. (2) Define navigation among them. On the Syntax-space (click), for conciseness, we will refine the « Personal Information » only (click)
- We place elements on the screen. This will be displayed like this (click) on the final GUI. Or we could use another style like this (click), which will be displayed like this (click). (click)
- On the widget level: map UI elements to concrete GUI widgets. (click)
- Finally, on widget Properties level: Setting properties of widgets to get the final GUI. (click)
- A linguistic modeling approach aims at abstracting modules on linguistic levels. The marriage between modeling approaches and the linguistic perspective promises to have the benefits of both: follow an engineering discipline with enhanced maintainability in the GUI. The linguistic perspective follows an iteratively-refined method. It emphasizes a clear interfacing between levels. Thus, two models can exsist on the same level as far as they respect interfacing constraints among levels. For example: we can have two models for navigation and both are used in the design.
- Now, let’s get back to the first question: do we need another task model?
- The linguistic perspective has specific requirements for an appropriate task model: First it must fit on the task level and only the task level. Thus we need well-defined criteria to separate the goal level from the task level (click) and the task level from the semantic (click). Unfortunatily, the first requirement can’t be satisfied, if we follow a Hierarchical Task Analysis. This is because the hierarchy of tasks is in fact a hierarchy of goals and sub-goals. That are linked by plans. Plans describe how to perform a sub-goal and determine conditions to trigger a sub-goal. Thus, goals and tasks are coupled together and are unseparable. The third requiremet is related to the role of the task model in the GUI development. The task model provides two outcomes: the tasks needed to archeive the user’s goal, and task input elements for the user to carry out tasks. Thus, we need a notation (click) that allows to represent tasks hierarchically and to support identifying task input elements.(click)
- Reviewing existing task models (click) reveals a limitation in satisfying the second requirement: Task decomposition stopping criteria to separate what is a task from what is a detailed function. We analysed several task models: GOMS, CTT and K-MAD. Criteria employed by these models allow the resulting model to cover more than the lingsuitic tasl level. For instance, CTT stopping criteria is at the granularity of identifying needed user element. This means, the CTT model covers the task, semantic and syntax-space levels.
- An interesting model for the linguistic perspective is Guerrero’s. This model addresses developing user interfaces to workflow systems. Shortly said, this model employs the CTT to design the GUI as a sub activity in the workflow development. It employs interesting criteria to identify root tasks to be modeled using CTT. These criteria are based on changes to the work environment. They are: (click and read) These criteria are interesting because they can be applied in the linguistic task model to separate what is a task a nd what is a detailed function. We adopt them.
- Now for the third requirement, The task notation. We need to use a notation that supports identifying task input elements. (click) CTT notation is widely used, with variations in different task models. (click) Temporal relations in CTT are not enough to identify task input elements. Take the example of search for a flight where the user fills some search parameters and the system displays a list of flight for the user to select one among them. If we emply CTT notation in the linguistic task model (click), we would identify only two input elements: the search and select. But the final GUI shows that we need a select for each displayed flight. This is not possible to predict from the CTT notation. This is a limitation in supporting dynamic aspects in the CTT notation. Besides, Can we re-execute the search? Or is the user allowed to change his mind and select a different flight? (click) the notation is silent in this regard. It doesn’t tell if a task can be reverted after completion or not. This is essential to the linguistic task model as reverting a task requires a task input element on the GUI.
- Now let’s present the proposed linguistic task model.
- First it follows the same theory of Hierarchical task analysis. Categories of Tasks are: user, interactive, system, mechanical and abstract. It employs a configurable task state diagram that helps identifying task input elements. Let’s have a look at the task state diagram. (click)
- An ordinary task lifecycle is: created, offered, started and completed. If the task can be suspended, it can pass from the started stat eto the suspended state. If the task can’t be carried out, it passes to the errored state (an example if online payment is not available, the online payment task passes to the errored state. This allows exploring alternatives, like offline payment). If the task can be reverted while maintaining already-captured information (click), the state diagram is changed to support a trarnsition from the completed state to the started state. If the revert is stateless (discard task information) (click), a transition to the offered state is added. If the task can be repeated (click), a transition to the created state is added.If a task is created by another task, the later can pass to the destroyed state. Transitions among tasks can be (click) manual, automatic, or based on a condition. In the case of manual transition, a task input elements is required in the GUI for the user to be able to change the state of the task (click). Thus, the task state diagram allows identifying task input elements to carry out a task. (click)
- Now let’s see how to define relations among tasks. Relations take the form of ECA rules. An example is (click and read the example). (Click)
- Now let’s see how to represent dynamic aspects (repetition) using the notation. To repeat a task, this recursive task relation would be enough. In this case, T is a dynamic task because it is created by another task at run-time. The problem in this notation is that it leads to (click) infinite number of tasks. The repetition decition (the decision to create a dynamic task) (click) is taken by the user or the system. This represents a decision point which justifies the identification of a task according to the task identification criteria. (click). Thus, to implement repetition on a task, we need to use a repetition task and model and represent the relation as (click). In this example, R is called a pumping task because it pumps dynamic tasks in the model at run-time (click). (click)
- Now let’s show an example on how to use the notation. (click)
- Let’s model the search for flight example using the proposed notation. The first step is to identify the tasks in the given scenario with the appropriate justification. The first task we identify is the Fill Search Params. It doesn’t need a justification because it is the first task. The second is display a flight with justification of change in nature from interactive to system. The third is select the flight. This task is justified by the change in nature and as a decision point. To allow dynamic creation of tasks, the task Repeat on flights is added with justification as repetiotion. This is the pumping task. The three tasks are grouped in a parent task Display Flights and then a root parent task: Search for flight. The last column in the table « configuration » denotes teh configuration of tasks which leads to confirguration of the task state diagram for each task. Now lets see this model in action. Till here 20 min 10 s
- 2 minutes