Transformaties van modellen in model-gebaseerde gebruikersinterface ontwikkeling

Transformaties van modellen in model-gebaseerde gebruikersinterface ontwikkeling Nico Degraef transnationale Universiteit Limburg

17 mei 2004

Inhoudsopgave 1 Inleiding

2

2 Modelgebaseerd User Interface 2.1 Overzicht Modellen . . . . . . 2.1.1 Het Taakmodel . . . . 2.1.2 Het Dialoogmodel . . . 2.1.3 Het Presentatiemodel . 2.2 ConcurTaskTree Notatie . . . 2.3 Enabled Task Sets . . . . . .

Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Tools voor Modelgebaseerd Design 3.1 CTTE . . . . . . . . . . . . . . . . 3.2 Teresa . . . . . . . . . . . . . . . . 3.3 Dygimes . . . . . . . . . . . . . . . 3.4 Mobi-D . . . . . . . . . . . . . . . 3.5 Conclusie . . . . . . . . . . . . . . 4 Van 4.1 4.2 4.3

. . . . .

. . . . .

Taakmodel naar Presentatiemodel Opstellen van het Taakmodel . . . . . Generatie van ETS . . . . . . . . . . . Reduceren van de ETS . . . . . . . . . 4.3.1 Opsplitsing van ETS . . . . . . 4.3.2 ETS met slechts 1 element . . . 4.3.3 Gelijkaardige ETSs . . . . . . . 4.3.4 Conclusie . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 . 4 . 4 . 5 . 6 . 7 . 10

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

14 14 15 17 17 19

. . . . . . .

20 20 20 21 21 25 28 28

. . . .

30 30 34 37 37

. . . . . . .

5 Invloed Op Het Dialoogmodel 5.1 Opsplitsing van de ETS . . . . . . . . . 5.2 ETS met slechts 1 element . . . . . . . . 5.3 Gelijkaardige ETS . . . . . . . . . . . . . 5.3.1 ETSs die in 1 element verschillen 1

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

5.3.2 5.3.3

ETS met meeste elementen gemeenschappelijk . . . . . 39 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . 39

6 Implementatie 6.1 ETS verfijningen . . . . . 6.1.1 Splitsing van ETS . 6.1.2 ETS met 1 element 6.1.3 Gelijkaardige ETS 6.2 Transities . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

40 40 41 41 41 42

7 Uitgewerkt Voorbeeld

44

8 Conclusie

51

2

Lijst van figuren 2.2

2.4 2.5

Voorstelling van de AIO van een checkbox in verschillende omgevingen. . . . . . . . . . . . . . . . . . . . . . . . . . . . Een eenvoudig ConcurTaskTree diagram . . . . . . . . . . . Lijst van basisoperaties in window transition notatie zoals gegeven in [LV00]. . . . . . . . . . . . . . . . . . . . . . . . . . Het startdiagram . . . . . . . . . . . . . . . . . . . . . . . . De priority tree voor 2.4 . . . . . . . . . . . . . . . . . . . .

3.1 3.2

Een foutieve CTT . . . . . . . . . . . . . . . . . . . . . . . . . 15 De omgeving van de CTTE tool . . . . . . . . . . . . . . . . . 16

4.1 4.2 4.3 4.4 4.5 4.6 4.7

Voorbeelddiagram splitsingregel . . . . . . . . . . . . . . . . . De user interface zoals gegenereerd door Dygimes . . . . . . . Opsplitsing van de user interface . . . . . . . . . . . . . . . . . Menu opties na de splitsing . . . . . . . . . . . . . . . . . . . Transities voor 2.4 . . . . . . . . . . . . . . . . . . . . . . . . Voorbeeld van een user interface met een bevestigingsdialoog. De user interface na de samenvoeging. . . . . . . . . . . . . .

22 24 24 25 27 27 28

5.1 5.2 5.3 5.4

Eenvoudige geval van splitsing . . . . . . . . . . . . . . . . . Extra transitie vanuit de te splitsen ETS . . . . . . . . . . . Meerdere transities vanuit de te splitsen ETS . . . . . . . . . Alternatieve oplossingen in geval van meerdere transities vanuit de te splitsen ETS . . . . . . . . . . . . . . . . . . . . . Invloed enabling operatie . . . . . . . . . . . . . . . . . . . . Mogelijke oplossingen . . . . . . . . . . . . . . . . . . . . . . De suspend/resume operator . . . . . . . . . . . . . . . . . . ETS met 1 element, eerste situatie . . . . . . . . . . . . . . ETS met 1 element, tweede situatie . . . . . . . . . . . . . . ETS met 1 element, derde situatie . . . . . . . . . . . . . . . Nut van disabling kan verloren gaan . . . . . . . . . . . . . . 1 element verschillend . . . . . . . . . . . . . . . . . . . . .

32 32 33 33 34 35 35 36 37

2.3 2.1

5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12

3

. .

7 8

. 12 . 13 . 13

. 30 . 31 . 31 . . . . . . . . .

5.13 Ongewenste overgang . . . . . . . . . . . . . . . . . . . . . . . 38 7.1 7.2 7.3 7.4 1 2

Transitieschema Transitieschema figuur 1 . . . . Transitieschema Transitieschema figuur 2 . . . .

voor de CTT van figuur 1 . . . . . . . . . . na toepassing technieken voor de CTT van . . . . . . . . . . . . . . . . . . . . . . . . . voor de CTT van figuur 2 . . . . . . . . . . na toepassing technieken voor de CTT van . . . . . . . . . . . . . . . . . . . . . . . . .

Voorbeeld voor een interface om informatie over een op te vragen. . . . . . . . . . . . . . . . . . . . . . Minieme interface voor het opvragen van informatie museum. . . . . . . . . . . . . . . . . . . . . . . . .

4

. 45 . 47 . 48 . 50

museum . . . . . . 54 over een . . . . . . 55

Samenvatting De laatste jaren zijn er heel wat nieuwe ontwikkelingen geweest zoals GSM, PDA’s,. . . . Deze hebben ervoor gezorgd dat vaak een user interface diende ontwikkeld te worden voor verscheidene platformen. Dit bracht veel extra werk met zich mee en methodes werden onderzocht en uitgewerkt om dit proces te vereenvoudigen. Bij modelgebaseerd user interface design ligt de aandacht vooral op het zoeken naar overeenkomsten tussen de verscheidene modellen en de overgang van een model naar een ander. In deze thesis zullen we bespreken hoe we dankzij het taakmodel naar een goed presentatiemodel kunnen gaan. We gebruiken hiervoor de Enabled Task Sets (ETSs) die we uit het taakmodel kunnen extraheren. Het doel is om Task Sets te maken waaruit we makkelijk een goed presentatiemodel kunnen opstellen. Verder wordt ook nog de invloed van deze aanpassingen op het dialoogmodel besproken.

Voorwoord Vooreerst wil ik alle personen bedanken voor hun medewerking aan deze thesis: Prof. dr; Karin Coninx, mijn promotor Kris Luyten, mijn thesisbegeleider Tim Clerckx, mijn tweede thesisbegeleider Ook wens ik mijn familie en vrienden te bedanken voor hun steun. In het speciaal mijn ouders die ook hebben meegeholpen bij het nalezen van de thesis en het verbeteren van spellingsfouten.

1

Hoofdstuk 1 Inleiding Met de ontwikkeling van allerlei nieuwe technologie¨en wordt het steeds moeilijker om user interfaces te ontwikkelen. Deze nieuwe ontwikkelingen brengen immers ook nieuwe platformen met zich mee. Dit betekent dan ook dat er meer verschillende user interfaces ontwikkeld dienen te worden om compatibiliteit met de verscheidenen platformen te bieden. Dit heeft ertoe geleid dat er de voorbije jaren heel wat onderzoek is verricht naar het automatisch genereren van user interfaces. Verschillende universiteiten en onderzoekscentra werken mee aan de ontwikkeling van frameworks: Expertisecentrum Digitale Media(EDM), Stanford University, . . . . Heel wat frameworks en tools werden dan ook ontwikkeld om dit doel te bereiken. In Hoofdstuk 3 van deze thesis bespreken we enkele van deze frameworks en tools, samen met de mogelijkheden die zij ons bieden. Deze tools zullen echter gebruik gaan maken van een aantal notaties die deze automatische generatie mee helpen ondersteunen of die ons van de nodige informatie voorzien op een duidelijk manier. Vooraleer we deze tools zullen behandelen, gaan we in Hoofdstuk 2 dan ook deze notaties eerst toelichten. Daar veel van de ontwikkelde applicaties steunen op modelgebaseerde user interface ontwikkeling behandelen we ook de verschillende modellen die in het kader van deze thesis van belang zijn. De automatische generatie kan leiden tot onoverzichtelijk interfaces. In hoofdstuk 4 trachten we een aantal technieken voor te stellen en te introduceren die ons toelaten te komen tot een meer overzichtelijke user interface. Hierbij moeten we steeds in het achterhoofd houden dat wijzigingen op 1 niveau ook invloed zullen hebben op de andere niveaus. In hoofdstuk 5 zullen we het dan ook hebben over wat de invloed is van deze technieken op een ander niveau, zijnde het dialoogmodel, welk in Hoofdstuk 2 zal gedefini¨eerd worden. Als ondersteuning voor deze technieken die werden voorgesteld, werd er 2

tevens een kleine tool ontwikkeld. De mogelijkheden van deze tool en tekortkomingen ervan behandelen we in Hoofdstuk 6. Om het voor de lezer wat duidelijker te maken hoe deze regels werken en wat de resultaten ervan zijn, sluiten we af met een hoofdstuk welk een uitgewerkt voorbeeld zal bevatten van een concrete toepassing. We geven een duidelijk overzicht van de ondernomen acties en de resultaten die werden bekomen. Dankzij de reeds ontwikkelde en bestudeerde mogelijkheden en technologie¨en is het nu reeds mogelijk een groot deel van de ontwikkeling van een user interface automatisch te behandelen. Op dit moment is het echter nog niet mogelijk het gehele proces te automatiseren, verder onderzoek blijft nodig.

3

Hoofdstuk 2 Modelgebaseerd User Interface Design De nadruk van deze thesis ligt op het modelgebaseerd user interface design. In dit hoofdstuk introduceren we de begrippen die later in deze thesis zullen gebruikt worden. Zo zullen we het hebben over de verschillende modellen binnen het domein van user interfacing en bespreken we de begrippen die betrekking hebben op de verschillende modellen.

2.1

Overzicht Modellen

Binnen het domein van user interfacing zijn er een groot aantal modellen te onderscheiden. We beperken ons hier echter tot de 3 modellen die het meest van belang zijn binnen het kader van deze thesis: het taakmodel, dialoogmodel en het presentatiemodel.

2.1.1

Het Taakmodel

Het taakmodel is het meest cruciale model in het ondersteunen van een design filosofie waarin de gebruiker centraal staat en bevindt zich op het requirements level [JMM03]. Dit mede door het feit dat het ons een cognitieve beschrijving geeft van de gebruikerstaken. Doch geeft het ons niet alleen een beschrijving van de taken die een gebruiker uitvoert, het geeft ook aan welke interactiemogelijkheden er ontwikkeld dienen te worden [PA97]. Dankzij deze sterke gerelateerdheid met het conceptueel model van de gebruiker is het taakmodel een zeer interessant model om nieuwe applicaties te kunnen ontwikkelen. Patern´o onderscheidt twee soorten taken. Zo hebben we enerzijds de fysieke taken zoals ’Selecteer OK’ en anderzijds de logische taken 4

waaronder we het ophalen van informatie kunnen klasseren. Voor het modelleren van taken werden reeds verschillende benaderingen ontwikkeld. [PA97] geeft een beschrijving van deze benaderingen, waarvan we hier kort een overzicht geven. Een eerste benadering waar men reeds in de jaren ’60 mee bezig was, is de Hierarchical Task Analysis. Het idee achter deze benadering is om de activiteiten, die logisch gestructureerd zijn, in verschillende levels te beschrijven. Deze benadering beschreef echter de relatie tussen de verscheidene activiteiten op een nogal primitieve manier. Later kwam dan de GOMS (Goals, Operators, Methods, Selection rules) familie. Deze benadering voorziet in een hi¨erarchische beschrijving in termen van operatoren. Deze benadering is vooral geschikt om de performantie van taken te beschrijven en is dan ook reeds veelvuldig gebruikt in een aantal industri¨ele applicaties. Tegenwoordig zijn er een aantal versies van GOMS in gebruik. We gaan niet verder in op al deze versies, maar vermelden ze kort: Keystroke-Level Model (KLM) en NGOMSL. Een nog andere benadering heet UAN (User Action Notation). Deze notatie heeft als belangrijkste doel het design te communiceren. Ontwikkelaars kunnen het dynamische gedrag van de grafische user interface beschrijven met deze notatie. Een laatste benadering is deze van de ConcurTaskTrees, welke we apart behandelen later binnen dit hoofdstuk. Meer informatie over de andere benaderingen kan men terug vinden in [PAT] en [DFAB98].

2.1.2

Het Dialoogmodel

Het dialoogmodel vertelt ons hoe de dialoog tussen de gebruiker en het systeem verloopt. Het dialoogmodel vinden we terug op het design level [JMM03]. Het specifieert wanneer de eindgebruiker functies kan starten door bvb. drukknoppen, commando’s,. . . , wanneer de gebruiker input kan geven maar ook wanneer de computer aan de eindgebruiker informatie kan presenteren [PA97]. Het is mogelijk om allerhande informatie voor het dialoogmodel reeds uit het taakmodel te halen, al dan niet op een indirecte wijze. [LV00] en [MV02] bespreken een notatie welke het dialoogmodel kan voorstellen op het mid-level niveau. Het mid-level niveau is 1 van de 4 dialoogniveaus die onderscheiden worden in het TRIDENT framework [VB93]. We spreken van het mid-level wanneer men het heeft over het specifi¨eren van de dialoog, de conversatie binnen eenzelfde presentatie eenheid of tussen de verscheidene vensters [MV02]. De notatie die voor dit niveau ontwikkeld werd wordt de ’Window Transition notation’ genoemd. [MV02] definieert een window transitie als een middel om van een bronvester (WS) naar eender welk doelvenster (WT) te gaan waarbij deze beide vensters delen van of

5

A

gehele (sub)taken voorstellen. Meer formeel geldt: WS → WT ⇔ een event gegenereerd door bronvenster WS een transitie van type A activeert naar doelvenster WT. Deze notatie voorziet tevens in een aantal basisoperaties die we kort vermelden in figuur 2.1. [LV00] bespreekt verder nog hoe men transities tussen verschillende dialogen voorstelt op mid-level niveau aan de hand van deze notatie. Deze transities kunnen van verschillende types zijn, welke gedefinieerd worden door de operatoren in de CTT notatie. [VLF03] bespreekt hoe we de structuur voor de navigatie kunnen afleiden uit de structurele en temporele eigenschappen van het taakmodel. Hierin beperkt men zich tot de enabling operator en de enabling met informatie uitwisseling.

2.1.3

Het Presentatiemodel

Het presentatiemodel bevat de informatie over hoe we de interactie aan de gebruiker kunnen presenteren. We kunnen dit model classificeren op het implementation level [JMM03]. Belangrijke elementen binnen dit model zijn de zogenaamde Abstract Interaction Objects(AIO) en de Concrete Interaction Objects(CIO)[VB93]. CIO zijn grafische objecten voor de invoer en het tonen van data die betrekking hebben op de interactieve taak van de gebruiker. Vaak worden de CIO’s ook ’widgets’ genoemd. De AIO brengt een abstracte voorstelling van de CIO waar de fysieke karakteristieken volledig platformonafhankelijk zijn. AIO’s hebben bij definitie geen grafische voorstelling, maar zijn gerelateerd met een aantal CIO’s voor verschillende platformen. We kunnen de AIO selecteren op basis van een aantal selectieregels welke de AIO’s mappen met de gedetailleerde semantische specificatie. Over het algemeen bestaan deze uit een viertal informatiebronnen, zijnde data van het applicatiemodel, informatie over deze data, gebruikersvoorkeuren en andere parameters. Meer informatie over deze selectieregels en de nadelen ervan kunnen gevonden worden in [VB93]. Als oplossing voor enkele problemen geeft [VB93] de AIO selectie volgens beslissingsbomen, maar hierop gaan we niet verder in. Tot slot geven we nog even een voorbeeld om het onderscheid duidelijk te maken tussen AIO’s en CIO’s. Waar de AIO gedefinieerd wordt door een unieke naam, zoals check box, geeft de CIO ons een mogelijke voorstelling voor deze naam in een specifieke omgeving. Figuren 2.2(a) en 2.2(b) tonen ons een AIO check box in respectievelijk de Windows XP en de Mac OSX omgeving.

6

(a) AIO van checkbox in Windows XP omgeving

(b) AIO van checkbox in Mac OSX omgeving

Figuur 2.2: Voorstelling van de AIO van een checkbox in verschillende omgevingen.

2.2

ConcurTaskTree Notatie

In de vorige sectie hebben we reeds de term taakmodel ge¨ıntroduceerd. Echter, hoe we kunnen we zo een taakmodel op een eenvoudige en intu¨ıtieve manier voorstellen? De meest gebruikte notatie voor dit doel is de ConcurTaskTree(CTT) notatie. Deze onderscheidt zich van andere notaties doordat het een grafische representatie geeft van het taakmodel. Figuur 2.3 geeft een eenvoudig voorbeeld van een CTT waarbij men een document kan openen of een nieuw aanmaken. Iedere knoop binnen deze boom stelt een taak voor, welke eventueel kan onderverdeeld worden in subtaken. Binnen deze notatie onderscheiden we twee types van relaties. Enerzijds een structurele relatie omwille van de boomstructuur die ons wordt aangeboden. Anderzijds heeft men ook de temporele relaties. Deze geven de relatie weer tussen twee taken op hetzelfde niveau binnen een boom. Verder in deze sectie komen we terug op de verschillende mogelijkheden van temporele relaties. Uiteraard zijn niet alle taken hetzelfde. Sommige zullen acties van de gebruiker omvatten, andere zijn eerder acties dat het systeemt dient te ondernemen. We geven een overzicht van de verschillende types van taken die in de CTT notatie beschikbaar zijn.

7

Abstracte taak: Dit omvat een taak die niet aan 1 van de ander categorie¨en kan toegewezen worden. Gebruikerstaak: Dit is een taak die enkel door de gebruiker uitgevoerd wordt. Dit kan o.a. het lezen van data zijn. Interactietaak: We gebruiken dit soort taak om aan te geven dat bij de uitvoering van de taak de gebruiker interactie met het systeem dient te hebben. Invullen van gegevens kunnen we een interactietaak noemen. Applicatietaak: Deze taak wordt volledig door het systeem uitgevoerd zonder enige tussenkomst van de gebruiker. Het inloggen op het systeem kan als zo een taak aanzien worden (niet te verwarren met het invullen van de logingegevens). We merken nog op dat wanneer de kinderen van een taak allen van hetzelfde type zijn, de parent ook dit type zal overnemen. Wanneer een taak kinderen van een verschillend type omvat, geven we deze taak best het type abstract.

Figuur 2.3: Een eenvoudig ConcurTaskTree diagram Eerder hebben we reeds gezegd wat het nut is van de temporele relaties binnen de CTT notatie. Doch beperken ze zich niet tot het aangeven van de relatie tussen taken. Ze geven ook aan hoe men taken onderling kan ordenen volgens de tijdsperiode waarin ze uitgevoerd kunnen worden. Zo geeft de enabling relatie ’>>’ aan dat de taak rechts van deze relatie pas kan uitgevoerd worden na afloop van de taak die zich links bevindt van deze relatie. We geven een overzicht van de beschikbare temporele relaties die de CTT

8

notatie ons biedt en wat hun betekenis is. Concurrency (T1 ||| T2) De acties behorende bij de twee taken kunnen in om het even welke volgorde zonder specifieke beperkingen. Choice (T1 [] T2) Men heeft de mogelijkheid te kiezen uit een set van taken. Eens de keuze gemaakt, kan de taak uitgevoerd worden. De andere taken zijn niet beschikbaar tot de huidige taak afgelopen is. Concurrency met informatie uitwisseling (T1|[]|T2) Twee taken kunnen onafhankelijk uitgevoerd worden maar moeten met elkaar gesynchroniseerd worden zodat ze informatie kunnen uitwisselen. Order Independency (T1 |=| T2) De volgorde waarin de taken uitgevoerd worden is van geen belang. Deactivation (T1 [> T2) Eens de de actie van de tweede taak werd uitgevoerd is de eerste taak definitief gedeactiveerd. Enabling (T1 >> T2) Hier gaat de ene taak een andere taak activeren eens ze afgelopen is. Enabling met doorgave van informatie (T1 []>> T2) Buiten het activeren van taak T2 door taak T1 zal taak T1 ook nog T2 voorzien van informatie. Suspend - Resume (T1 | > T2) Deze operator geeft aan taak T2 de mogelijkheid om T1 te onderbreken. Wanneer dan T2 afgelopen is, kan T1 weer geactiveerd worden bij de toestand die bereikt was voor de onderbreking. Iteration (T*) Taken met een * naast hun naam zijn taken die herhaaldelijk uitgevoerd worden. Eens ze afgelopen zijn, worden de acties meteen weer van vooraf aan gestart. Finite Iteration (T1(n)) Dit wordt enkel gebruikt wanneer de ontwerper reeds op voorhand weet hoe vaak een taak zal uitgevoerd worden. Optional Task ([T]) Dit geeft ons de mogelijkheid om aan te geven dat de uitvoering van een taak optioneel is. Ze worden steeds aangeduid door vierkante haakjes.

9

Deze temporele relaties zijn essentieel binnen onze boomstructuur. Bij de generatie van een user interface hangt het mede van deze relaties af hoe alles gegroepeerd zal worden binnen verschillende dialogen en hoe de verschillende dialogen zich onderling zullen gedragen. In [TC03] kan men een formele beschrijving vinden van deze notatie.

2.3

Enabled Task Sets

Een Enabled Task Set(ETS) kan men beschouwen als een set van taken die over eenzelfde tijdsperiode geactiveerd kunnen worden door een gebruiker rekening houdend met de beperkingen opgenomen in het taakmodel [PAT00]. Doorheen het automatisch user interface generatieproces spelen deze een grote rol. Het is vanuit deze ETSs dat men komt tot een verzameling van abstracte presentaties. We geven nu kort een overzicht hoe men tot de ETSs kan komen vertrekkende van een taakmodel. We doen dit door de temporele relaties binnen het taakmodel te analyseren en een priority tree op te stellen. Een priority tree is een ConcurTaskTree met dezelfde semantische betekenis als het taakmodel maar waarbij de temporele relaties tussen de kinderen steeds dezelfde prioriteit zullen hebben [TC03]. Om dit te kunnen bereiken zullen we aan iedere temporele relatie een graad van belangrijkheid moeten geven. De keuze relatie ’[]’ krijgt zo de hoogste prioriteit toegewezen terwijl de enabling relatie (>>) alsook de enabling relatie met informatie uitwisseling ’[]>>’ de laagste toegewezen krijgen. [PAT00] defini¨eert de prioriteiten als volgt: {[]} >prio {|||, |[]|, |=|} >prio {[>} >prio {| >} >prio {>>, []>>} Een formele beschrijving van het gebruikte algoritme is te vinden in [TC03]. We beschrijven het proces om tot de ETSs te komen aan de hand van een concreet voorbeeld. We bespreken het voorbeeld van een berichtenbox waar men dient in te loggen om berichten te kunnen lezen. We zien de CCT hiervoor in Figuur 2.4. Figuur 2.5 geeft de priority tree voor dit voorbeeld, waarbij ’Dummy’ een extra knoop is die we introduceren om aan de definitie van een priority tree te voldoen zoals beschreven in [TC03], p.40. We gaan kijken naar de kinderen van onze root. We zien hier dat de temporele relatie tussen de taken ’Registreer’ en ’Login’ de hoogste prioriteit heeft van alle taken op dat niveau binnen onze boom. We gaan nu verder vanuit de eerste taak ’Registreer’ en beschouwen het eerste kind, zijnde de taak ’Select Registreer’. Sibling naar rechts brengt ons bij de taak ’Insert Data’, waartussen zich de enabling relatie bevindt. Deze heeft de laagste 10

prioriteit en kan niet aan de huidige ETS toegevoegd worden. Ook verdere sibling naar rechts heeft weinig nut, daar taken die zich verder naar rechts bevinden geen kandidaten kunnen zijn voor deze ETS doordat we reeds een enabling relatie zijn tegengekomen (in dit geval zouden we niet verder kunnen siblen). We werken nu verder op de taak ’Login’ en beschouwen het eerste kind, ’Select Login’. Ook hier zien we weer een enabling relatie en mogen we hier stoppen. Ook Login zelf heeft een enabling relatie met zijn rechterbroer ’Doe Login’. Dit resulteert in onze eerste ETS bestaanden uit de taken ’Select Registreren’ en ’Select Login’. Verder hebben we enkel temporele relaties die de laagste prioriteit bezitten (>> en []>>) wat ertoe leidt dat de andere taken elk apart in een ETS staan. We geven nog even de ETSs die ontstaan zijn uit het voorbeeld in figuur 2.4: ETS ETS ETS ETS ETS

1 2 3 4 5

{Select Registreren, Select Login} {Insert Data} {Doe Login} {Lees Bericht} {Insert Login}

Enabled Task Sets kunnen ons van dienst zijn bij het aanmaken van een presentatiemodel. Vaak is het zo dat de ETSs die gegenereerd worden vanuit het taakmodel leiden tot onoverzichtelijke user interfaces. Door het reduceren van het aantal ETSs en het omvormen ervan kunnen we tot een beter presentatiemodel komen en dus een overzichtelijkere user interface. Toch kan dit meestal niet zomaar en zijn er enkele ingrepen nodig in de structuur van de verschillende ETSs. Hierbij is vooral het behoud van consistentie met het taakmodel belangrijk. In hoofdstuk 5 stellen we enkele methoden voor die kunnen aangewend worden om de ETSs om te verbeteren. Hoe we hiervoor te werk gaan en welke problemen dit kan opleveren komen in een later hoofdstuk nog uitgebreid aan bod.

11

Maximalisatie: Vergroot het venster tot de maximaal mogelijke grootte in verhouding tot de schermgrootte.

Titeling: Reduceert het venster tot enkel de titelbalk. Het venster is wel nog actief in deze positie.

Minimalisatie: Minimaliseert het venster tot zijn icoon.

Tiling weergave: Rangschikt het venster zodat het getegeld lijkt ten opzichte van de andere bestaande vensters.

Overlappende weergave: De verschillende vensters overlappen gedeeltelijk de andere vensters. Indien het venster reeds ervoor gereduceerd werd (titeling of minimalisatie), dan wordt het naar zijn oude grootte en positie gezet.

Gebruikers gedefinieerde overlapping: De vensters overlappen elkaar gedeeltelijk zoals gedefinieerd door de gebruiker.

Systeem gedefinieerde overlapping: De vensters overlappen elkaar gedeeltelijk zoals gedefinieerd door het systeem.

Sluiten: Sluit het venster. Het is mogelijk dat de gebruiker gevraagd wordt om niet opgeslagen documenten of informatie eerst op te slaan alvorens het sluiten van het venster plaatsvindt. Figuur 2.1: Lijst van basisoperaties in window transition notatie zoals gegeven in [LV00].

12

Figuur 2.4: Het startdiagram

Figuur 2.5: De priority tree voor 2.4

13

Hoofdstuk 3 Tools voor Modelgebaseerd Design In dit hoofdstuk zullen we enkele tools bespreken die ons toelaten op basis van modellen user interfaces te ontwikkelen. Vele tools zijn reeds ontwikkeld voor dit doel, maar niet allen zijn even uitgebreid. Sommigen laten enkel een klein gedeelte ervan toe, zoals CTTE. Anderen daarentegen, zoals Mobi-D [PA97], begeleiden de gebruiker gedurende het gehele design proces. In dit hoofdstuk beperken we ons tot de bespreking van 4 tools: CTTE, TERESA, Dygimes en Mobi-D. Er zijn uiteraard veel meer tools, waar een aantal onder hen een gelijkaardig doel hebben. Enkele andere tools die werden ontwikkeld aan onderzoeksinstellingen en universiteiten zijn: TRIDENT [VB93][BHL94], TADEUS[SE96], MEFISTO[NPP01], Fuse [LS97],. . . .

3.1

CTTE

De CTTE tool[MPS02] is een tool die ontwikkeld werd door de HCI groep van ISTI(Pisa). De tool wordt vooral gebruikt om een taakmodel op te stellen aan de hand van de ConcurTaskTree notatie. Toch is dit niet de enige functionaliteit die de CTTE tool ons biedt. We overlopen dan ook kort de mogelijkheden die deze tool ons aanrijkt. • Het aanmaken van een taakmodel: Dit kan zowel voor een ’single user’ als voor een ’co¨operatief’ taakmodel. • Het wijzigen van een bestaand taakmodel. Dit kan zowel ingelezen worden vanuit een ctt formaat als vanuit het XML formaat. • Generatie van de Enabled Task Sets. 14

• Structuur van het model controleren: De tool kan nagaan of het gemaakte taakmodel onvolledigheden bevat. Dit is een belangrijke functionaliteit. Een fout taakmodel leidt namelijk tot een niet correcte UI. Als voorbeeld nemen we figuur 3.1, welke een foutieve versie is van het taakmodel in figuur 2.4. De taak ’Registreer’ staat hier aangegeven als een abstracte taak, terwijl zijn kinderen beiden interactieve taken zijn. Dit impliceert dat ook de parent interactief moet zijn en de CTTE tool zal dit als een waarschuwing melden. Ook de taak ’Lees Bericht’ staat als abstract gedefinieerd. Een blad kan echter nooit een abstracte taak voorstellen en ook dit is dus foutief. • Taakmodel aanmaken aan de hand van een informele beschrijving van het systeem: Ondersteunt de gebruiker bij het extraheren van de belangrijke informatie uit de informele beschrijving van het systeem. • Aanmaken van scenario’s: Het is mogelijk om een aantal gedragingen van de gebruiker te simuleren. Dit kan door in de CTTE tool een aantal scenario’s hiervoor aan te maken.

Figuur 3.1: Een foutieve CTT De CTTE tool is dankzij zijn overzichtelijke en handige interface (Figuur 3.2) dan ook de meest gebruikte tool om een taakmodel op te stellen.

3.2

Teresa

De Teresa tool [MPS03] is een half-automatische omgeving die ontwikkeld werd door de HCI groep van ISTI-C.N.R. en welke gebaseerd is op transformaties. Het is ontwikkeld voor designers die hun design op verschillende abstracte niveau’s wensen te ontwikkelen en analyseren. Later is het dan 15

Figuur 3.2: De omgeving van de CTTE tool mogelijk om de concrete interface te laten genereren voor verscheidene platformen (desktops en mobiele apparaten). We geven een kort overzicht van de mogelijkheden die Teresa ons biedt: • Generatie van Presentatie Sets, wat wij de ETS genoemd hebben en transities tussen deze ETSs. • Omzetting van taakmodel gerelateerde informatie naar een abstracte UI. • Omzetting van een abstracte UI naar een concrete UI. De designer krijgt hiervoor een aantal parameters die hij kan instellen om de concrete UI te personaliseren. Deze concrete UI kan zowel voor desktops als voor mobiele apparaten gegenereerd worden. • Automatisch UI generatie. Vertrekkend van de concrete UI wordt er de uiteindelijke UI gegenereerd. Dit gebeurt aan de hand van een aantal standaardinstellingen met betrekking tot de UI generatie. 16

Als ondersteuning voor de implementatie behorende bij deze thesis zullen we Teresa vooral gebruiken om onze CTT om te zetten naar het XML formaat. We merken hierbij op dat TERESA geen gebruik maakt van een standaard XML specificatie maar hun eigen XML ontwikkeld heeft.

3.3

Dygimes

Dygimes [CLV03] staat voor ’Dynamically Generating Interfaces for Mobile Computing Devices and Embedded Systems’ en is een framework dat ontwikkeld werd aan het onderzoekscentrum ’Expertisecentrum Digitale Media’ (EDM) in Diepenbeek. Het maakt gebruik van XML-gebaseerde high level user interface beschrijvingen, in combinatie met verscheidene modellen, om te komen tot een UI voor verscheidene platformen. Dygimes heeft als bedoeling om de creatie van UI’s te vergemakkelijken zonder dat men specifieke kennis moet hebben over de hardware of het software platform waarvoor we de UI gaan ontwikkelen. Dit is mogelijk omdat men het design van de UI scheidt van de implementatie van de applicatiecode. De belangrijkste eigenschappen van Dygimes zijn: • Aan de hand van een abstracte XML beschrijving komen tot UI’s die geschikt zijn voor meerdere platformen. • Integratie met component gebaseerde software ontwikkeling. • Een automatisch lay-out beheer en presentatie templates. • Ondersteuning voor CTT taakmodellen. [CLV03] bespreekt Dygimes in meer detail. Naast een uitvoerige bespreking van de mogelijkheden die Dygimes biedt, vindt men er ook een uitgebreide beschrijving van de werking van dit framework.

3.4

Mobi-D

Mobi-D [PA97], wat staat voor Model-Based Interface Designer, is een project van Stanford University. Het is een interactieve omgeving welke user-centered ontwikkeling ondersteunt en een gestructureerd design toelaat vanuit abstracte objecten zoals gebruikerstaken. Het maakt gebruik een beschrijving van gebruikerstaken en objecten tijdens het ontwikkelingsproces. De tool is, in tegenstelling tot vele andere tools, niet automatisch. Zo zal de designer zelf 17

de transformaties die toegepast moeten worden defini¨eren en aangeven welke verdere beslissingen er genomen dienen te worden. [PA97] geeft drie belangrijke innovaties op gebied van modelgebaseerde interface ontwikkeling, zijnde: • Metalevel modelleertaal: Mobi-D gebruikt ´e´en taal om alle componenten, structuren en relaties tussen de modellen te defini¨eren. Hierdoor wordt het makkelijk om de verschillende types van interface elementen met elkaar te relateren. • Formele definitie van het interface design. Het interface design vertelt ons bvb. hoe een bepaalde widget gerelateerd is met de dialoogstructuur. • Het interface design laat de designers en eindgebruikers toe om beslissingen te maken. Verder voorziet Mobi-D in een duidelijke communicatie tussen de eindgebruiker en de designer alsook tussen het designproces en beide partijen. Tevens is het makkelijk om de ontwikkelde designs te gebruiken in andere applicaties door het declaratieve formaat van de designs. Mobi-D biedt totnogtoe enkel ondersteuning voor desktop applicaties wat in deze tijden van GSM, PDA, . . . toch een belangrijke beperking is voor deze tool. Voor meer informatie over de architectuur van Mobi-D, kan de lezer [PA97] raadplegen. Men vindt er tevens een voorbeeld in terug welke de werking van Mobi-D kan verduidelijken. Tot slot van dit hoofdstuk geven we een kort overzicht van de zonet besproken tools en de modellen waarop ze werken (Tabel 3.1). Tool CTTE TERESA Dygimes

Gebruikte modellen Taakmodel Taakmodel Taakmodel

Mobi-D

Taakmodel en domeinmodel

Extra vereisten

Abstracte user interface beschrijving Designer moet veel beslissingen nemen.

Tabel 3.1: Een overzicht van de tools en de modellen waarop ze werken.

18

3.5

Conclusie

We hebben in dit hoofdstuk een aantal notaties voor modelgebaseerd UI design en de mogelijkheden van een aantal belangrijke tools besproken. De besproken tools maakten allen gebruik van het taakmodel, eventueel aangevuld met extra informatie. We zien dat vele van de huidige tools tekortschieten om het volledige UI ontwikkelingsproces te behandelen. Van de besproken tools zijn Dygimes en Mobi-D veruit de meest uitgebreide tools, maar ook deze zijn nog in volle ontwikkeling.

19

Hoofdstuk 4 Van Taakmodel naar Presentatiemodel In dit hoofdstuk zullen we het vooral hebben over aanpassingen die we kunnen doen aan onze ETSs om te komen tot beter geschikte ETSs waaruit we een user interface kunnen genereren. We baseren ons hiervoor op enkele voorstellen die reeds in [PS02] werden besproken en werken deze verder uit.

4.1

Opstellen van het Taakmodel

Voor we starten met de aanpassingen aan onze ETSs moeten we eerst komen tot onze ETSs. Hiervoor stellen we eerst het taakmodel op. We gebruiken hiervoor de CTTE tool die ons grafisch bijstaat gedurende dit ontwikkelingsproces en ons toelaat fouten makkelijk op te sporen. Deze stap is zowat de belangrijkste stap. Fouten in ons taakmodel zullen verregaande gevolgen hebben voor onze user interface die later gegenereerd zal worden.

4.2

Generatie van ETS

Vervolgens hebben we onze ETSs nodig. Hiervoor gaan we de zonet aangemaakte CTT inladen in TERESA welke voor ons de ETS zal genereren. Handig is tevens dat TERESA toelaat ze te exporteren naar het XML formaat zodat we ze makkelijk kunnen inlezen in ons programma door de XML file te parsen. Deze stap kan ook uitgevoerd worden door de TaskLib tool, ontwikkeld aan het EDM, die toelaat de CTT in XML vorm te laten inlezen en de ETSs te laten berekenen.

20

4.3

Reduceren van de ETS

Wanneer we van een taakmodel de ETSs genereren leidt dit vaak tot een zeer groot aantal ETSs. Dit zou kunnen leiden tot een overvolle en/of onoverzichtelijke user interface. Het is dus nodig de ETSs aan te passen zodat deze problemen zo goed mogelijk verholpen worden. Een aantal regels worden in deze sectie ge¨ıntroduceerd en verduidelijkt. Wanneer we deze ETSs omvormen volgens ´e´en of meerdere van bovenstaande regels, gaan de eigenschappen van de ETS verloren. Het is dus nodig deze te voorzien van een andere naam.[TC03] noemt deze nieuwe, omgevormde ETSs Compound Task Sets(CTSs). Volgens de definitie zoals gegeven in [TC03] kunnen we ze beschouwen als het resultaat van het samenvoegen van verscheidene ETSs. Hier gebruiken we echter ook deze naamgeving voor het resultaat dat we verkrijgen na het opsplitsen van een ETS.

4.3.1

Opsplitsing van ETS

Om ons toe te laten meer controle te krijgen over de ETSs leggen we enkele restricties op bij het aanmaken van het taakmodel. We gaan de gebruikersacties specifiek aangeven. We doen dit als volgt: Wanneer de gebruikerstaak inhoudt dat hij iets moet selecteren geven we de taak de naam ’Select . . . ’. Gaat het om het invoeren van gegevens geven we als naam ’Insert . . . ’ op. De bedoeling hiervan is dat wanneer we een user interface zouden genereren voor een mobiel toestel zoals een gsm, we slechts over een beperkte ruimte beschikken (Vb.: Slechts 2 regels om gegevens in te voeren zijn maximaal zichtbaar, slechts 2 knoppen kunnen gebruikt worden om iets te selecteren). Dankzij deze restrictie kunnen we in ons programma nagaan hoeveel van eenzelfde soort taken zich bevinden in een bepaalde ETS. Bedraagt dit aantal meer dan het maximum toegelaten aantal, dan splitsen we onze ETS op in enkele nieuwe CTSs. Ook het dynamische gedrag tussen de ETSs dient aangepast te worden aan deze splitsing. Op die manier vermijden we dat gebruikers moeten scrollen om alles ingevoerd te krijgen en eventueel dingen vergeten in te vullen (mensen niet zo vertrouwd met het mobiel toestel vergeten nogal eens deze handeling) We illustreren deze regel aan de hand van een klein voorbeeld. Beschouwen we figuur 4.1. Op het niveau van het dialoogmodel kunnen we dit zien als een registreersysteem. De gebruiker doorloopt eerst het registratieproces en kan dan pas inloggen. De ETSs voor dit voorbeeld zijn ETS 1 {Insert_Login, Insert_Paswoord, Insert_Naam, Insert_Email} 21

Figuur 4.1: Voorbeelddiagram splitsingregel ETS 2 {Login} Voor een GSM met slechts voldoende regels voor twee invoervelden zouden we dan ETS 1 splitsen om zo te komen tot volgende nieuwe ETSs ETS 1 {Insert_Login, Insert_Paswoord} ETS 2 {Insert_Name, Insert_Email} ETS 3 {Login} Dit is vrij simpel te verwezenlijken. Een ander belangrijke aanpassing bevindt zich echter in de transities tussen deze ETSs. We bekijken even deze transities in XML formaat zoals gegenereerd door de TERESA tool. De transitie die we voor dit voorbeeld hebben is TS1 TS2 In het verdere verloop stellen we zo een transitie voor door de volgende notatie: Insert Email T S1 −−−−−−−→ T S2

22

Na de splitsing verkrijgen we Insert P aswoord T S1 −−−−−−−−−−→ T S2 Insert Email T S2 −−−−−−−→ T S3 Hoe komen we tot dit resultaat? Oorspronkelijk konden we binnen eenzelfde tijdsperiode alle gegevens invullen en werden we vervolgens ingelogd. Na de splitsing kan men binnen deze tijdsperiode enkel de login en paswoord invullen. Pas na het uitvoeren van deze taak heeft men de mogelijkheid zijn naam en email in te vullen waarna de login pas kan plaatsvinden. Dit uit zich ook in de transitieregels, welke tevens van een opsplitsing voorzien wordt. Ook de omgekeerde redenering is mogelijk. Wanneer we bvb. een taakmodel hebben waar we in een eerste stap een login en paswoord moeten kiezen en in een volgende stap onze adresgegevens moeten opgeven, is het mogelijk de twee ETSs die hieruit gegenereerd worden samen te voegen indien de applicatie voor een desktop PC ontwikkeld zou worden. Op zo een desktop PC is de ruimte immers aanzienlijk groter en is het niet nodig zulk een proces in kleine delen te hebben. We eindigen deze sectie met een concreet voorbeeld van een user interface op een GSM toestel. In figuur 4.2(a) zien we hoe het hierboven besproken voorbeeld als een user interface zou gerenderd worden voor een GSM met behulp van het Dygimes framework. We zien dat de gebruiker zal dienen te scrollen om alle informatie te bekijken en in te vullen. Nadien kan men in het menu voor ’register’ kiezen en de registratie laten plaatsvinden (Figuur 4.2(b)).

23

(a) Interface voor registratie

(b) Menu opties

Figuur 4.2: De user interface zoals gegenereerd door Dygimes

Figuren 4.3(a) en 4.3(b) tonen de user interface na de opsplitsing van de ETS.

(a) Ingave naam en email (b) Keuze login en paswoord

Figuur 4.3: Opsplitsing van de user interface

In figuur 4.4(a) zien we dat het menu nu ons niet de optie ’register’ 24

biedt maar wel een optie ’next’ waarmee we naar de volgende stap van het registratieproces gaan. Pas bij de laatste stap is er de optie ’register’ zoals getoond in figuur 4.4(b).

(a) De eerste stap

(b) De laatste stap

Figuur 4.4: Menu opties na de splitsing

4.3.2

ETS met slechts 1 element

Een andere mogelijkheid om het aantal ETSs te beperken is te kijken naar de ETSs met slechts 1 element. Wanneer we kijken naar de ETSs die horen bij figuur 2.4 zien we bvb. dat er twee mogelijke scenario’s zijn om te komen tot de taak ’Doe Login’, zowel na het registreren als na het inloggen. Verder wordt deze taak met geen enkele andere gelinkt. We zouden dus deze ETS kunnen laten vallen en ’Doe Login’ in zowel ETS 2 als ETS 5 kunnen bijvoegen zonder andere taken te be¨ınvloeden. In deze methode schuilt echter het gevaar dat onze transitieregels niet langer correct zijn. Het is dus nodig de transitieregels aan te passen aan de nieuwe situatie. Bekijken we hiervoor figuur 4.5. We zien dat we van ETS 2 naar ETS 3 kunnen door de taak ’Insert Data’ uit te voeren en dat ETS 3, welke de applicatietaak ’Doe Login’ bevat, ons toelaat om te komen tot ETS 4, het eigenlijke lezen van berichten. Het verwijderen van ETS 3 verplicht ons dus ook deze transities aan te passen. Dit leidt tot volgende transitieregels: Insertdata T S2 −−−−−−→ T S4 DoeLogin T S2 −−−−−→ T S4

25

We zien echter dat beide taken moeten uitgevoerd worden om tot TS 4 te komen. In onze transitieregels kunnen we dit aangeven door gebruik te maken van de tag ’ConditionOnTasks’. Voor de duidelijkheid grijpen we hier even terug naar onze notatie in XML zoals gegeneerd door TERESA. Het toevoegen van dit element geeft ons volgende structuur: TS2 TS4 Nu is het nodig dat zowel ’Insert data’ als ’Doe Login’ uitgevoerd worden alvorens we naar de volgende Task Set kunnen gaan. Tot slot geven we een concreet voorbeeld van deze methode. Het voorbeeld is er ´e´en van een dialoogbox op het Windows platform waar men kan registreren. Men ziet de dialoog in figuur 4.6(a) waar men de benodigde gegevens kan invullen. In figuur 4.6(b) ziet men de bevestigingsdialoog die verschijnt na het invoeren van de gegevens.

26

Figuur 4.5: Transities voor 2.4

(a) Registratiedialoog

(b) Bevestigingsdialoog

Figuur 4.6: Voorbeeld van een user interface met een bevestigingsdialoog.

We zien dat we dit makkelijk in ´e´en enkele dialoog konden stoppen door gebruik te maken van de zogenaamde check boxes. Het resultaat is te zien in figuur 4.7.

27

Figuur 4.7: De user interface na de samenvoeging.

4.3.3

Gelijkaardige ETSs

In [PS02] stelt men voor om tevens de ETSs die de meeste elementen gemeenschappelijk hebben samen te voegen. Als voorbeeld wordt aangegeven dat, wanneer de gemeenschappelijke taken binnen de ETSs zich rechts van de disabling ([ >) relatie bevinden, we deze twee ETSs mogen samenvoegen. Echter, binnen onze ETS beschikken we nergens over deze informatie van positie t.o.v. relaties. Extra informatie is echter niet nodig. We kunnen deze informatie immers uit ons taakmodel halen. [PS02] stelt ook voor om de ETSs die slechts in 1 element verschillen en op hetzelfde niveau verbonden zijn met een enabling relatie, samen te voegen in 1 ETS en de volgorde te behouden. Ook hiervoor maken we gebruik van de informatie binnen het taakmodel. We kunnen dus ook deze laatste twee regels toepassen zonder dat we hiervoor extra informatie moeten opslaan. Bij het opstellen van deze regels hebben we enkel gekeken naar de mogelijke voordelen voor het presentatiemodel. Overvolle user interfaces kunnen vermeden worden wanneer we deze ontwikkelen voor een mobiel apparaat. Wanneer we wel over voldoende ruimte beschikken om onze user interface voor te stellen, kunnen we beter hiervan gebruik maken en bepaalde informatie bundelen in 1 enkele dialoog. Voor we deze regels effectief in gebruik nemen is het dan ook best dat we eerst kijken naar de gevolgen van deze aanpassingen voor het dialoogmodel.

4.3.4

Conclusie

We hebben net enkele technieken besproken die kunnen leiden tot betere ETSs. We hebben ook gezien dat het vaak moeilijk is om zo een techniek 28

concreet toe te passen en wat we kunnen doen om een aantal problemen te omzeilen. We mogen dus duidelijk niet zomaar een techniek bedenken en toepassen. Een grondige analyse van elke techniek is nodig en mogelijke problemen moeten opgespoord worden. Een aantal kleine problemen op vlak van detectie werden reeds besproken. In het volgend hoofdstuk gaan we kijken wat het effect is op het dialoogmodel en hoe we problemen kunnen voorkomen.

29

Hoofdstuk 5 Invloed Op Het Dialoogmodel De in het vorig hoofdstuk voorgestelde regels voor het verfijnen van de ETS heeft ook een grote invloed op het dialoogmodel. Ook transities tussen de staten van de user interface ondergaan mogelijk wijzigingen die tot inconsistentie zouden kunnen leiden. In dit hoofdstuk gaan we voor elk van de regels na wat mogelijk effecten op het dialoogmodel kunnen zijn en welke van de mogelijke oplossingen hiervoor de beste zijn.

5.1

Opsplitsing van de ETS

(a) Startsituatie

(b) Optie 1

(c) Optie 2

Figuur 5.1: Eenvoudige geval van splitsing Stel we hebben oorspronkelijk dat we van dialoog 1 naar zowel dialoog 2 als 3 kunnen 5.1(a). Laten we nu de ETSs van dialoog 3 opsplitsen. We kunnen nu op twee manieren dialoog 1 linken met de opgesplitste dialoog 3. Of we linken naar het eerste deel van dialoog 3 zoals figuur 5.1(b) ons toont, die dan op zijn buurt verder linkt naar het opgesplitste deel. Een andere 30

optie is dat we vanuit dialoog 1 linken naar alle delen van dialoog 3 (Figuur 5.1(c)). De eerste oplossing geniet hierbij de voorkeur omdat we de transities van dialoog 1 ongemoeid laten op deze manier. Echter, we kunnen ook hebben dat dialoog 3 in de beginsituatie (In

(a)

(b) Optie 1

(c) Optie 2

Figuur 5.2: Extra transitie vanuit de te splitsen ETS figuur 5.2(a) voorgesteld als dialoog 1) nog transities naar andere dialogen bevat. Ook hier hebben we dan dezelfde twee mogelijkheden voor het plaatsen van de nieuwe dialogen bekomen door de splitsing. De methode in figuur 5.2(b) geniet hier de voorkeur: Wanneer we naar de andere oplossing kijken, gegeven in figuur 5.2(c), dan zien we dat we in de problemen kunnen komen wanneer er informatie vanuit dialoog 1 naar dialoog 2 werd doorgegeven in de oorspronkelijke situatie. Stel dat de informatie nu in deel 1b zit van de opgesplitste dialoog. We zien dat er geen transitie is van hieruit naar dialoog 2. In de eerste optie is dit wel het geval en kunnen we tevens aan de gegevens uit dialoog 1a geraken. Een andere mogelijkheid is dat we vanuit de ETS die we splitsen, meer-

(a)

(b) Beste oplossing

Figuur 5.3: Meerdere transities vanuit de te splitsen ETS dere transities hebben naar andere ETSs. In het dialoogmodel vertaalt zich dat naar de situatie in figuur 5.3(a). Wanneer we de ETS behorende bij dialoog 1 opsplitsten hebben we een aantal mogelijkheden om de transities aan te passen. In figuren 5.3(b), 5.4(a) en 5.4(b) worden drie mogelijk oplossingen aangereikt. In de twee laatste blijkt dat de eigenlijke bedoeling 31

gedeeltelijk verloren gaat, zoals ook reeds opgemerkt bij het voorbeeld van figuur 5.2(a). Een andere methode, welke in de implementatie ge¨ımplementeerd werd,

(a)

(b)

Figuur 5.4: Alternatieve oplossingen in geval van meerdere transities vanuit de te splitsen ETS

bestaat erin te kijken via welke taak de transities gebeuren. Komt de taak na de splitsing in een nieuwe dialoog voor, dan wordt de transitie aangepast zodat deze met de nieuwe dialoog gelinkt wordt. Meer uitleg over deze techniek is terug te vinden in het hoofdstuk ’Implementatiedetails’. Welke invloed oefenen de temporele relaties uit? Het kan tevens zeer interessant zijn om te kijken naar de temporele relaties en welke invloed deze uitoefenen bij het splitsen van de ETS. We kijken naar het eenvoudige voorbeeld voor het splitsen van tasksets. Stel dat de taak waarmee we van dialoog 1 naar dialoog 3 gaan over de temporele relatie ’>>’ beschikt. M.a.w. De eerste taak zal een volgende taak enablen. Na het splitsen zou het kunnen dat de taak die ge-enabled werd, in een nieuwe deel van de opgesplitste ETS terecht komt. Wanneer we dan de transities toepassen in oplossing die we eerder als beste hadden bestempeld, zouden we deze enabling relatie teniet doen. In dit geval is het dan ook best om toch de oorspronkelijke ETS, samen met de transities, te gaan aanpassen. Ook wanneer het gaat over een disabling transitie komen we bij het-

Figuur 5.5: Invloed enabling operatie

32

(a) De goede methode

(b) Verlies aan informatie

Figuur 5.6: Mogelijke oplossingen

zelfde probleem terecht en is dus de ’minst goede’ oplossing aan te raden. Wanneer het een temporele relatie betreft met informatie uitwisseling zoals de ’[] >>’ en ’|[]|’ relatie, is het niet mogelijk de ’minst goede’ oplossing te kiezen. We verduidelijken dit even aan de hand van een voorbeeld. Nemen we het geval waarbij een persoon zich registreert om toegang te krijgen tot de toepassing (Figuur 5.5). De dialoog betreft een invulformulier waar we onze adresgegevens invullen en onze login en paswoord dienen te kiezen. De splitsing zorgt ervoor dat deze dialoog in twee delen wordt opgesplitst: Het deel voor onze adresgegevens en het deel voor onze login. Het is duidelijk dat we hier informatie uitwisseling zullen hebben tussen de registratiedialoog en de volgende dialoog die we te zien zullen krijgen (dit kan om een dialoog gaan die de inschrijving bevestigt). Zouden we nu de transities zetten zoals in figuur 5.6(b), dan zien we dat de informatie uit de tweede dialoog nooit kan uitgewisseld worden met onze ’bevestigingsdialoog’. Dit zou de bedoeling van de inschrijving volledig teniet doen. We kiezen dan ook ervoor om de transities te zetten zoals in figuur 5.6(a) getoond wordt. Moeilijk wordt het wanneer we te maken hebben met de suspend/resume

Figuur 5.7: De suspend/resume operator relatie tussen twee taken van een andere ETS. Beschouwen we hiertoe figuur 5.7 in de situatie na de splitsing. We gaan d.m.v. een transitie van een taak uit 1b naar een taak in 2. De temporele relatie hiertussen betreft een suspend resume. Echter, na de splitsing zouden we eigenlijk 1a en 1b als 1 geheel moeten beschouwen, daar deze tot 1 ETS behoorde en dus feitelijk 33

gedurende dezelfde tijdsperiode konden uitgevoerd worden. We zouden dus nu kunnen hebben dat het resumen gebeurt binnen de dialoog 1a. Het is dan ook aan de gebruiker om te bepalen of hij deze als 1 wenst te beschouwen of niet. Dit vergt uiteraard wel de nodige aanpassingen binnen onze code. Waar we vroeger slechts 1 optie hadden waar de resume kon plaatsvinden, kan dit nu op 2 of meerdere ’plaatsen’ (in ons geval binnen 1a en 1b). Enkele richtlijnen om problemen te vermijden. We wensen uiteraard deze problemen te vermijden. Enkele richtlijnen kunnen opgesteld worden welke, indien men ze volgt, een aantal problemen reeds op voorhand uitsluiten. • Splits geen ETS waar een taak betrokken is in een suspend-resume relatie. • Na splitsing kan een choice relatie tussen twee taken a.h.w. een enabling gedrag verkrijgen. Neem als voorbeeld een registratieproces. • Ontwerp het taakmodel voor de kleinste user interface nodig. • Vermijd een grote opeenvolging aan choices op eenzelfde niveau. Dit leidt tot onoverzichtelijke user interfaces waar een gebruiker enkel in verloren kan lopen.

5.2

ETS met slechts 1 element

Wanneer we onze regels toepassen om de ETS met 1 element weg te werken en samen te voegen met de andere ETSs stoten we niet op deze problemen. Hoe het dialoogmodel hierdoor be¨ınvloed wordt zien we in deze sectie. We vertrekken voor ons eerste voorbeeld vanuit de situatie in figuur

(a)

(b) Na samenvoeging

Figuur 5.8: ETS met 1 element, eerste situatie

5.8(a). Hier stellen we de dialoog met 1 element voor door het vierkant 34

met de horizontale streep (gelabeld met nr. 2). We zien dat we van hieruit een transitie hebben naar dialoog 3 en een binnenkomende transitie hebben vanuit 1. Na het samenvoegen komen we tot de situatie zoals geschetst in figuur 5.8(b). Het ene element werd toegevoegd aan de ETS van dialoog 1. De transitie die we hadden naar onze dialoog met 1 element werd vervangen door een rechtstreekse transitie naar dialoog 3. We zien ook dat we als het ware een nieuwe transitie gecre¨eerd hebben. Vroeger konden we niet vanuit dialoog 2 naar 4 geraken, waar dit na de samenvoeging wel het geval blijkt te zijn. Laten we nu het moeilijker geval beschouwen dat we meerdere inkomende

(a)

(b) Na samenvoeging

Figuur 5.9: ETS met 1 element, tweede situatie transities hadden in onze dialoog met 1 element. De situatie hier wordt voorgesteld in figuur 5.9(a), het resultaat na de samenvoeging is te zien in 5.9(b). We zien dat we komen tot een veel eenvoudigere set van dialogen en transities. 3 transities werden herleid tot slechts 1. De overige zijn dankzij de samenvoeging overbodig geworden. Tot slot kijken we nog even naar een situatie waarin we een lusstructuur

(a)

(b) Na samenvoeging

Figuur 5.10: ETS met 1 element, derde situatie hebben (Figuur 5.10(a)). De dialoog met 1 element kan hier bijvoorbeeld een bevestiging voor een actie zijn. We kunnen deze bevestiging ook meteen in onze startdialoog zetten. (Bvb., de OK bevestiging zou een checkbox kunnen worden in onze startdialoog die dient aangevinkt te worden.) 35

Figuur 5.11: Nut van disabling kan verloren gaan Wat is de invloed van verscheidene temporele relaties? Door het feit dat we hier gaan samenvoegen in plaats van te splitsen zijn een aantal problemen meteen gelimineerd. We gaan hier net zoals eerder de dialoog met slechts 1 element samenvoegen met een andere dialoog. We hebben tussen deze dialogen de temporele relatie [] >>, m.a.w. enabling met informatie uitwisseling. Na het samenvoegen geeft dit geen enkel probleem, daar we nu binnen dezelfde dialoog werken en dus steeds aan de informatie geraken die we anders hadden doorgekregen. Wel een probleem stelt zich indien het hier om de disabling operator ([>) ging. Laten we even figuur 5.11 beschouwen. In dat geval zou namelijk de taak in dialoog 1 definitief gedeactiveerd worden bij het uitvoeren van de taak binnen dialoog 2. Wanneer we deze twee echter zouden samenvoegen bevinden we ons in dezelfde dialoog en zouden we dus de tak(a)k(en) binnen dialoog 1 wel nog kunnen uitvoeren. Gelukkig hebben we binnen een dialoog steeds de mogelijkheid om elementen te disablen wat dit probleem zou kunnen oplossen. Ook weinig problemen komen we tegen indien het om de suspend/resume operator betreft. Na het samenvoegen is ook hier makkelijk bij te houden waar de resume dient plaats te vinden. Het enige waar we wel rekening mee dienen te houden is dat de resume in dit geval steeds binnen de huidige dialoog zal plaatsvinden, wat de bedoeling van de temporele relatie enigzins verloren doet gaan doordat we ons nu binnen dezelfde ETS en dus binnen dezelfde tijdsperiode bevinden waarin die taken uitgevoerd kunnen worden. Indien het om een iteratieve taak gaat, gaan we bij het samenvoegen een keuze moeten maken. Of de taak is niet langer iteratief (wat niet consistent is met ons taakmodel en dus af te raden), of we voorzien een mogelijkheid om deze taak iteratief binnen de huidige dialoog uit te voeren (een button die deze actie vervolgens uitvoert is mogelijk, maar werkt niet wanneer het om het invoeren van gegevens gaat). In dit geval laten we best de betrokken ETSs ongemoeid. Enkele richtlijnen om problemen te vermijden. Ook hier kunnen we enkele problemen vermijden door vooraf een aantal dingen in acht te nemen: • Vermijd transities naar ETSs met 1 element die disablen. 36

• Een iteratieve taak in een ETS met 1 element kan leiden tot inconsistentie met het taakmodel bij het samenvoegen met andere ETSs. • Een suspend/resume als temporele relatie tussen twee taken (waarvan 1 zich in de ETS met 1 element bevindt) gaat als het ware verloren bij het samenvoegen.

5.3 5.3.1

Gelijkaardige ETS ETSs die in 1 element verschillen

(a)

(b) Na de samenvoeging

Figuur 5.12: 1 element verschillend

37

Figuur 5.13: Ongewenste overgang In dit geval gaan we ETSs samenvoegen die slechts in 1 element verschillen. In figuren 5.12(a) en 5.12(b) zien we deze samenvoeging ge¨ıllustreerd. Soms kan zo een samenvoeging echter voor enkele problemen zorgen. Het is namelijk goed mogelijk dat we ongewenste overgangen gaan introduceren. Figuur 5.13 verduidelijkt dit probleem. We kunnen vanuit dialoog 0 naar dialoog 1. Dialogen 1 en 2 worden door onze regels samengevoegd. Echter, vroeger geraakten we vanuit dialoog 0 niet aan het niet-gemeenschappelijk element van dialoog 2, zijnde 6, waar we na de samenvoeging daar wel kunnen raken. Tijdens het uitvoeren van de regels op onze ETS zal de keuze moeten gemaakt worden of men deze overgang gaat toelaten. We zouden dit makkelijk kunnen toelaten omdat we weten dat de temporele relatie toch een disabling zal zijn (dit is zo vastgelegd bij het opstellen van de regel). We weten dus dat er geen uitwisseling van informatie zal gebeuren die tot foutieve resultaten kan leiden. Wat is de invloed van verscheidenen temporele relaties? Onze regel impliceert dat de taken die gemeenschappelijk zijn, zich rechts van de disabling operator bevinden op hetzelfde niveau. Het is nu wel zo dat we na deze samenvoeging meer elementen zullen gedisabled hebben dan we ervoor zouden gedaan hebben. We voegen immers niet-gemeenschappelijke taken van een andere ETS toe. Zo wordt het ook perfect mogelijk dat taken die anders niet binnen eenzelfde tijdsperiode konden uitgevoerd worden, nu wel op die manier kunnen uitgevoerd worden. Voor de gemeenschappelijke elementen gebeuren er geen aanpassingen, we dienen ook dit hier niet verder te beschouwen. Het enige dat enigzins verandert is dat we, waar we vroeger bvb. twee inkomende transities hadden, we nu slechts eentje zullen overhouden door de samenvoeging.

38

Enkele richtlijnen om problemen te vermijden. • Gemeenschappelijke taken moeten zich links van een disabling relatie bevinden. • Een suspend/resume relatie tussen twee niet-gemeenschappelijke elementen is ook hier te mijden. We plaatsen immers beide taken in dezelfde ETS waardoor het nut hiervan enigzins verloren gaat.

5.3.2

ETS met meeste elementen gemeenschappelijk

Hier geldt hetzelfde als in het voorgaand besproken geval. Doordat we echter meerdere elementen hebben die niet gemeenschappelijk zijn is de kans op ongewenste overgangen uiteraard een stuk groter. Ook kunnen we door deze samenvoeging een soort van lusstructuur gaan cree¨eren die niet bestond. Dit is echter vrij eenvoudig op te sporen. We hebben dan de keuze of we dit soort lussen er meteen uitfilteren, ofdat we ze laten zodat deze achteraf handmatig kunnen verwijderd worden.

5.3.3

Conclusie

We merken dat er zich wel degelijk een vrij groot aantal problemen stellen. Sommige hiervan kunnen omzeild worden mits de nodige aanpassingen door te voeren. Voor een aantal kan dit niet en is het aan de designer om aan te geven of hij de ge¨ıntroduceerde inconsistentie door de vingers ziet. Tevens kan er getracht worden het taakmodel te wijzigen en een aantal regels in acht te nemen bij het opstellen ervan zodat problemen op voorhand vermeden worden. Het zijn dit soort problemen die ertoe leiden dat het maken van een volledig geautomatiseerde tool moeilijk, zo niet onmogelijk is. De designer zal steeds de nodige keuzes moeten maken.

39

Hoofdstuk 6 Implementatie De implementatie bestaat erin een tool te ontwikkelen met 2 doelen. Enerzijds zal de tool de in Hoofdstuk 6 voorgestelde regels implementeren. Anderzijds laat de tool toe om zelf de nodige transities toe te voegen en/of aan te passen op zo een manier dat er geen inconsistentie kan optreden met het taakmodel. De tool is ontwikkeld als een uitbreiding op de reeds bestaande tool TaskLib. Meer info over deze tool kan men vinden op http: //www.edm.luc.ac.be/software/TaskLib/. We lezen de concurTaskTree in in XML formaat. De gebruikte XML is deze welke gegenereerd werd door de TERESA tool. Toch kan deze XML door de parser geweigerd worden. Een bug kan zorgen voor parse errors bij het parsen van de gegenereerd XML file. Dit doordat TERESA geen gebruikt maakt van een bestaande parser, maar hun eigen ontwikkelde parser gebruikt. We geven een voorbeeld van wanneer het fout kan lopen. Wanneer een taak de naam ’Show room artworks & adjacent rooms’ draagt, wordt de & niet consequent omgezet naar &. Het is dan aan de gebruiker om de gegenereerde XML aan te passen om foutieve resultaten te vermijden. We bespreken de mogelijkheden van deze uitbreiding in dit hoofdstuk en gaan wat dieper in op de problemen die zich voordeden samen met de aanpak voor deze problemen.

6.1

ETS verfijningen

We zullen deze sectie bespreken per regel die er werd ge¨ımplementeerd. Welke problemen er zich voordeden en hoe deze in de tool werden verholpen komen tevens aan bod.

40

6.1.1

Splitsing van ETS

Voor het uitvoeren van deze stap heeft de tool een extra parameter nodig. Deze parameter geeft aan hoeveel select of insert statements men maximaal toelaat per ETS. Zo is het voor een GSM logisch om de waarde 2 mee te geven (Een GSM bevat nl. vaak slechts twee knoppen voor selecties en slechts een beperkt aantal regels op 1 scherm), terwijl een desktop pc veel meer ruimte en middelen aanrijkt voor selecties. Vervolgens wordt er voor iedere ETS nagegaan of deze meer dan x aantal van zulke taken bevat. Het is echter niet eenvoudig om te weten welke taak een insert of een select taak is. Hiervoor is het noodzakelijk voor een goede werking van de tool dat deze taken een bepaalde naamgeving volgen (select . . . en insert . . . ). De ETS wordt opgesplitst en de transities zullen door de tool automatisch aangepast worden. De ID van de nieuw aangemaakte ETSs wordt bijgehouden. Vervolgens worden alle transities nagekeken, vergeleken met de nieuwe ETSs en indien nodig wordt de ID aangepast. Alle relaties tussen twee taken worden hierbij behouden en er vindt geen wijziging plaats in de types van de transities.

6.1.2

ETS met 1 element

Zoals reeds besproken in Hoofdstuk 6 is het aanpassen van transities belangrijk. We gaan immers samenvoegen, een transitie laten staan of vergeten aan te passen zou leiden tot niet correcte User Interfaces (de ETS voor de dialoog is immers verdwenen). De tool tracht deze aanpassingen zelfstandig uit te voeren. De ETS met 1 element wordt samengevoegd met ALLE ETSs waarvan er een transitie is naar de aan te passen ETS. Uiteraard heeft dit ook gevolgen voor de ETSs die volgen op de net verwijderde ETS. Hun index klopt immers niet meer. Ook deze benodigde aanpassingen worden door de tool verwerkt.

6.1.3

Gelijkaardige ETS

Om deze regel succesvol te kunnen toepassen dient er een extra parameter meegegeven te worden. Deze parameter geeft aan in hoeverre twee ETSs op elkaar mogen gelijken. Een voorbeeld maakt dit duidelijk. Stel dat we de parameter de waarde 2 zouden geven, dan zouden volgende ETSs succesvol herkend worden (Voorbeeld ETS uit [PS02]) ETS 1 {Show room artworks&adjacent rooms, Return to map, Exit museum} ETS 2 {Select adjacent room, Select artwork, Return to map, Exit museum}

41

Hierbij nemen we aan dat de gemeenschappelijke taken ’Return to map’ en ’Exit museum’ zich rechts van een disabling operator bevinden zoals voorgesteld in [PS02]. Samenvoegen vereist ook hier weer een aanpassing van de transities die we automatisch laten gebeuren. Deze detectie vereist wel wat werk. Ieder element van elke ETS moet immers vergeleken worden met elk element binnen de andere ETSs. De tijdscomplexiteit van dit zoekproces ligt vrij hoog, zijnde O(n4 ), waarbij n het aantal taken binnen het taakmodel voorstelt, maar is nog steeds polynomiaal. In sommige gevallen is het mogelijk dat door het automatisch laten aanpassen van de transities er twee of meer dezelfde transities ontstaan. We doorzoeken dan ook onze transitielijst op dubbels en filteren deze uit het eindresultaat.

6.2

Transities

De tool laat tevens toe dat de gebruiker zelf de transities gaat aanpassen of toevoegen. Eerst wordt er gekeken of de transitie niet reeds bestaat. Dubbele transities zijn sowieso niet toegelaten. Vervolgens wordt nagegaan of de toegevoegde transitie toegelaten is volgens de specificaties van het taakmodel. De gebruiker wordt tijdens het toevoegen van een transitie begeleid door de applicatie. Beschikbare taken worden getoond wanneer men de startof eindETS kiest. Ook wordt een lijst gegeven van de beschikbare soorten transities die mogelijk zijn. We bespreken kort deze soorten. Een volledige uitleg over deze transities is terug te vinden in [TC03]. Enabling transitie : Wanneer een een enabling transitie is van ETS1 naar ETS2 via een taak ’x’ zullen bij het uitvoeren van taak x de taken van ETS2 beschikbaar worden om uitgevoerd te worden. Disabling transitie : Bij een disabling transitie van ETS1 naar ETS2 zal bij het uitvoeren van de taak behorende bij de transitie ETS1 gedisabled worden en keert men terug naar ETS2. Iterative transitie : Dit geeft aan dat men deze taak een onbeperkt aantal keer na mekaar kan uitvoeren. We gaan dus eigenlijk steeds van ETS1 naar ETS1 en cre¨eren een lus binnen de transitie. Expiring transitie : We spreken van een expiring taak t wanneer t een blad is binnen onze CTT en wanneer er geen taak t’ bestaat zodat we een transitie hebben van t naar t’. Transities die door zulk een taak veroorzaakt worden noemen we expiring transities. 42

Wanneer een gebruiker handmatig transities gaat toevoegen kunnen we echter op een aantal problemen stoten. In [TC03] wordt aangegeven dat wanneer we een expiring taak hebben wiens voorouder een enabling operator heeft aan de rechterkant, we deze taak niet verder beschouwen en reeds behandeld is. Echter, het is niet zeker dat de gebruiker eerst alle enabling taken heeft uitgevoerd. We gaan dus preventief reeds zulke transities als niet geldig beschouwen en de gebruiker ervan op de hoogte brengen dat deze later in een enabling transitie zal betrokken zijn. Voor het detecteren van de enabling en disabling transities gebruiken we een algoritme gebaseerd op de beschrijving in [TC03], p. 56-62. Om de gebruiker toe te laten de nodige aanpassingen door te voeren in het taakmodel, of om een correcte transitie in te geven, voorzien we telkens de gebruiker van feedback over waar het fout liep. Voor de gebruiker van het programma is het wel noodzakelijk reeds over voldoende kennis te beschikken over het taakmodel. Zonder deze kennis is het vrijwel onmogelijk de nodige aanpassingen die moeten gebeuren, te begrijpen. Het nagaan van deze geldigheid van de toegevoegde transitie kan een vrij intensief proces zijn bij ingewikkelde taakmodellen van vrij grote diepte. Dit komt doordat het zoekproces een recursief proces is dat, indien nodig, naar de parent zal kijken en van daaruit verder werkt tot de boom doorlopen is, of totdat een oplossing werd gevonden.

43

Hoofdstuk 7 Uitgewerkt Voorbeeld Ter afsluiting van deze thesis werken we enkele concrete voorbeelden uit om voor de lezer te verduidelijken hoe de implementatie concreet een CTT behandelt en de technieken erop toepast. We bestuderen hiervoor 2 voorbeelden. Beide voorbeelden handelen over een interface voor het bekijken van museum informatie. In het ene geval een uitgebreid voorbeeld, voor een desktop PC bijvoorbeeld, in het andere geval een minieme versie, eerder geschikt voor gebruik met een PDA. We beschouwen eerst het taakmodel zoals weergegeven in figuur 1 en laten de ETSs berekenen door de tool. Het bekomen resultaat is: ETS 0: {Show_intro, Select_access_to_gen_info, Select_access_to_artworks, Select_access_ticket_booking} ETS 1: {Show_museum_info, Exit} ETS 2: {Show_info_on_sections, Back_to_home, Select_section} ETS 3: {Cancel, Submit} ETS 4: {ShowsTicketBooking, Insert_Name, Insert_Surname, Insert_DayOfVisit, Insert_CreditcardNumber, Select_UseOfGuide} ETS 5: {Receive_code} ETS 6: {Show_section_artworks, Back_to_start, Select_artwork} ETS 7: {Show_artwork_info, Close_info, Select_access_to_review} ETS 8: {Show_review, Close} Aan de hand van deze ETS en de CTT worden nu de transities berekend, we stellen deze transities grafisch voor in figuur 7.1.

44

Figuur 7.1: Transitieschema voor de CTT van figuur 1 Allereerst gaan we kijken of er ETSs voorkomen die slechts 1 element bevatten, we zien dat dit het geval is voor ETS 5. We voegen de taak binnen ETS 5 nu toe aan alle ETSs die betrokken zijn met ETS 5 via een transitie, enkel voor ETS 3 is dit het geval. De nieuwe set van ETSs wordt nu: ETS 0: {Show_intro, Select_access_to_gen_info, Select_access_to_artworks, Select_access_ticket_booking} ETS 1: {Show_museum_info, Exit} ETS 2: {Show_info_on_sections, Back_to_home, Select_section} ETS 3: {Cancel, Submit, Receive_code} ETS 4: {ShowsTicketBooking, Insert_Name, Insert_Surname, Insert_DayOfVisit, Insert_CreditcardNumber, Select_UseOfGuide} ETS 5: {Show_section_artworks, Back_to_start, Select_artwork} ETS 6: {Show_artwork_info, Close_info, Select_access_to_review} ETS 7: {Show_review, Close} We zien dat ETS 5 verwijderd werd en de indices van de ETSs die volgden werd aangepast. Uiteraard brengt dit ook de nodige wijzigingen in de 45

transities. Omdat het aantal aanpassingen miniem is, geven we deze weer in tekstuele notatie: Transitie van ETS 3 -> Submit ->ETS 5 vervalt Transitie van ETS 5 -> Recieve_code ->ETS 0 wordt ETS 3 -> Receive_code -> ETS 0 Verder is er geen ETS met slechts 1 element. We gaan nu kijken naar het aantal ’Insert’ en ’Select’ taken per ETS. Het maximum aantal toegelaten taken per ETS werd op 2 gedefinieerd. We zien dat zowel ETS 0 als ETS 4 een te groot aantal van dit taken bevat. Het is dan ook nodig deze ETSs op te splitsen in meerdere ETSs. Dit geeft ons de volgende lijst van ETSs: ETS 0: {Show_intro, Select_access_to_gen_info, Select_access_to_artworks} ETS 1: {Show_museum_info, Exit} ETS 2: {Show_info_on_sections, Back_to_home, Select_section} ETS 3: {Cancel, Submit, Receive_code} ETS 4: {ShowsTicketBooking, Insert_Name, Insert_Surname} ETS 5: {Show_section_artworks, Back_to_start, Select_artwork} ETS 6: {Show_artwork_info, Close_info, Select_access_to_review} ETS 7: {Show_review, Close} ETS 8: {Select_access_ticket_booking} ETS 9: {Insert_DayOfVisit, Insert_CreditcardNumber Select_UseOfGuide} De benodigde aanpassingen hiervoor binnen de transities zijn vrij talrijk. Indices dienen aangepast te worden voor de taken die werden opgesplitst. Om de splitsing weer te geven, zullen we gebruik maken van een dummy transition. Het nieuwe transitieschema is te zien in figuur 7.2. Tot slot gaan we nog na welke ETSs gelijkaardig zijn. In dit voorbeeld is deze techniek niet van toepassing. We gebruiken een andere CTT om dit voorbeeld te verduidelijken.

46

Figuur 7.2: Transitieschema na toepassing technieken voor de CTT van figuur 1 Laten we hiervoor de CTT in figuur 2 beschouwen. Ook hier laten we de ETSs genereren en aan de hand van deze informatie en onze CTT tevens de transities (Figuur 7.3). ETS 0: {Access to map} ETS 1: {Show museum map, Exit museum} ETS 2: {Select room, Exit museum} ETS 3: {Show room artworks & adjacent rooms, Exit museum, Return to map} ETS 4: {Exit museum, Return to map, Select adjacent room, Select artwork} ETS 5: {Exit museum, Return to map, Show artwork info, Return to room}

47

Figuur 7.3: Transitieschema voor de CTT van figuur 2 Voor dit voorbeeld geven we aan dat het maximaal aantal verschillende elementen tussen 2 ETSs slechts 2 mogen bedragen. Onze tool detecteert dan ook als eerste mogelijkheid ETSs 1 en 3, welke maximaal t.o.v. elkaar verschillen in slechts 2 taken, zijnde ’Show room artworks & adjacent rooms’ en ’Return to map’. We zien dat de gemeenschappelijke taak tevens voldoet aan de voorwaarde dat ze zich rechts van een disabling operator dient te bevinden en gaan dan ook de samenvoeging uitvoeren. We verkrijgen volgende ETS structuur: ETS 0: {Access to map} ETS 1: {Show museum map, Exit museum, Show room artworks & adjacent rooms, Return to map} ETS 2: {Select room, Exit museum} ETS 3: {Exit museum, Return to map, Select adjacent room, Select artwork} ETS 4: {Exit museum, Return to map, Show artwork info, Return to room} 48

Er vindt een aanpassing van de indices plaats voor de oorspronkelijke ETS 4 en 5, deze krijgen nu respectievelijk de indices 3 en 4. In de lijst van transities zouden we nu dubbels introduceren in de accept states. We verkrijgen namelijk volgende wijzigingen: Transitie: 3 -> Exit Museum -> accept wordt 1 -> Exit Museum -> accept Transitie: 3 -> Return to map -> 1 wordt 1 -> Return to map -> 1 De hierboven ge¨ıntroduceerde dubbel wordt door de tool automatisch verwijderd. In een volgende iteratie worden de nieuwe ETS 1 en 3 herkend als zijnde gelijkaardig. Aan alle eisen wordt voldaan en een nieuwe samenvoeging vindt plaats. Opnieuw verkrijgen we een aangepaste set van ETSs. ETS 0: {Access to map} ETS 1: {Show museum map, Exit museum, Show room artworks & adjacent rooms, Return to map, Select adjacent room, Select artwork} ETS 2: {Select room, Exit museum} ETS 4: {Exit museum, Return to map, Show artwork info, Return to room} Na deze iteratie worden er geen gelijkaardige ETSs meer gevonden en zal het programma stoppen. Het nieuwe transitieschema, met verwijdering van eventuele dubbels en aanpassingen van de indices, is te zien in figuur 7.4.

49

Figuur 7.4: Transitieschema na toepassing technieken voor de CTT van figuur 2

50

Hoofdstuk 8 Conclusie Op het gebied van omvorming van ETSs is er nog maar weinig onderzoek gebeurd en echte concrete methoden werden nog niet gegeven. In deze thesis hebben we geprobeerd concreet enkele voorstellen uit te werken aan de hand van voorbeelden. Wellicht zijn er nog talloze regels op te stellen voor het omvormen van deze ETSs. Men moet echter ook nagaan wat de haalbaarheid van deze regels is. Daartoe hebben we ook de invloed van deze regels op het dialoogmodel besproken. We zijn tot het besluit gekomen dat voor de verscheidene voorgestelde regels er een aantal dubbelzinnigheden en problemen kunnen optreden die niet steeds op een voor de hand liggend manier kunnen opgelost worden.

51

Bibliografie [DFAB98] Dix, A., Finlay, J., Abowd, G., Beale, R., Human-Computer Interaction (second edition) [PS02] Patern´o, F., Santoro, C. One Model, Many Interfaces [TC03] Clerckx, T., Integrating Task Models in Automatic User Interface Generation [LV00] Limbourg, Q., Vanderdonckt, J., Souchon, N., The Task-Dialog and Task-Presentation Mapping Problem: Some Preliminary Results [MV02] Mbaki Luzayisu, E., Vanderdonckt, J., Window Transitions: A Graphical Notation for Specifying Mid-level Dialogue [PAT] Patern´o, F., Task models in Interactive Software Systems [PA97] Puerta, A., A Model-Based Interface Development Environment [PAT00] Patern´o, F., Model-Based Design and Evaluation of Interactive Applications [PV02] Pribeanu, C., Vanderdonckt, J., Exploring Design Heuristics for User Interface Derivation from Task and Domain Models [VB93] Vanderdonckt, J., Bodart, F., Encapsulating Knowledge for Intelligent Automatic Interaction Objects Selection [VLF03] Vanderdonckt, J., Limbourg, Q., Florins, M., Deriving the Navigationel Structure of a User Interface [PE99] Puerta, A., Eisenstein, J., Towards a General Computational Framework for Modelbased Interface Development Systems [CLV03] Coninx, K., Luyten, K., Vandervelpen, C., Van Den Bergh, J., Creemers, B., Dygimes: Dynamically Generating Interfaces for Mobile Computing Devices and Embedded Systems 52

[JMM03] L´opez-Jaquero, V., Montero, F., Molina, J.P., Fern´andezCaballero, A., Gonz´alez, P., Model-Based Design of Adaptive User Interfaces Through Connectors [NPP01] Navarre, P., Palanque, P., Patern´o, F., Santoro, C., Bastide, R., A Tool Suite for Integrating Task and System Models through Scenarios. [BHL94] Bodart, F., Hennebert, A-M., Leheureux, J-M., Provot, I., Vanderdonckt, J., A Model-Based Approach to Presentation: A Continuum from Task Analysis to Prototype [LS97] Lonczewski, F., Schreiber, S., The FUSE-System: an Integrated User Interface Design Environment. [MPS02] Mori, G., Patern´o, F., Santoro, S., CTTE: Support for Developing and Analysing Task Models for Interactive Systems. [MPS03] Mori, G., Patern´o, F., Santoro, S., Tool Support for Designing Nomadic Applications. [SE96] Schlungbaum, E., Elwert, T., Dialogue Graphs - A Formal and Visual Specification Technique for Dialogue Modelling.

53

54

Figuur 1: Voorbeeld voor een interface om informatie over een museum op te vragen.

Appendix A

Appendix B

Figuur 2: Minieme interface voor het opvragen van informatie over een museum.

55