Transformaties van modellen in model-gebaseerde gebruikersinterface ontwikkeling

Transcriptie

1 Transformaties van modellen in model-gebaseerde gebruikersinterface ontwikkeling Nico Degraef transnationale Universiteit Limburg 17 mei 2004

2 Inhoudsopgave 1 Inleiding 2 2 Modelgebaseerd User Interface Design Overzicht Modellen Het Taakmodel Het Dialoogmodel Het Presentatiemodel ConcurTaskTree Notatie Enabled Task Sets Tools voor Modelgebaseerd Design CTTE Teresa Dygimes Mobi-D Conclusie Van Taakmodel naar Presentatiemodel Opstellen van het Taakmodel Generatie van ETS Reduceren van de ETS Opsplitsing van ETS ETS met slechts 1 element Gelijkaardige ETSs Conclusie Invloed Op Het Dialoogmodel Opsplitsing van de ETS ETS met slechts 1 element Gelijkaardige ETS ETSs die in 1 element verschillen

3 5.3.2 ETS met meeste elementen gemeenschappelijk Conclusie Implementatie ETS verfijningen Splitsing van ETS ETS met 1 element Gelijkaardige ETS Transities Uitgewerkt Voorbeeld 44 8 Conclusie 51 2

4 Lijst van figuren 2.2 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 Een foutieve CTT De omgeving van de CTTE tool Voorbeelddiagram splitsingregel De user interface zoals gegenereerd door Dygimes Opsplitsing van de user interface Menu opties na de splitsing Transities voor Voorbeeld van een user interface met een bevestigingsdialoog De user interface na de samenvoeging 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 element verschillend

5 5.13 Ongewenste overgang Transitieschema voor de CTT van figuur Transitieschema na toepassing technieken voor de CTT van figuur Transitieschema voor de CTT van figuur Transitieschema na toepassing technieken voor de CTT van figuur Voorbeeld voor een interface om informatie over een museum op te vragen Minieme interface voor het opvragen van informatie over een museum

6 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.

7 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

8 Hoofdstuk 1 Inleiding Met de ontwikkeling van allerlei nieuwe technologieën 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ëerd worden. Als ondersteuning voor deze technieken die werden voorgesteld, werd er 2

9 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ën 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

10 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 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ó onderscheidt twee soorten taken. Zo hebben we enerzijds de fysieke taken zoals Selecteer OK en anderzijds de logische taken 4

11 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ërarchische 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ële 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] 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ëren 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

12 gehele (sub)taken voorstellen. Meer formeel geldt: WS A 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 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

13 (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 Concur- TaskTree(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

14 Abstracte taak: Dit omvat een taak die niet aan 1 van de ander categorieën 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

15 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

16 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ëert 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

17 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 1 {Select Registreren, Select Login} ETS 2 {Insert Data} ETS 3 {Doe Login} ETS 4 {Lees Bericht} ETS 5 {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

18 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

19 Figuur 2.4: Het startdiagram Figuur 2.5: De priority tree voor

20 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], 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öperatief 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

21 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

22 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

23 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

24 de transformaties die toegepast moeten worden definiëren 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 één taal om alle componenten, structuren en relaties tussen de modellen te definiëren. 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 Gebruikte modellen Extra vereisten CTTE Taakmodel TERESA Taakmodel Dygimes Taakmodel Abstracte user interface beschrijving Mobi-D Taakmodel en domeinmodel Designer moet veel beslissingen nemen. Tabel 3.1: Een overzicht van de tools en de modellen waarop ze werken. 18

25 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

26 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

27 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 één 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 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_ } 21

28 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_ } 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 <DynamicBehaviour> <Rule> <TaskSet>TS1</TaskSet> <Transition> <Task name="insert_ " /> </Transition> <TaskSet>TS2</TaskSet> </Rule> </DynamicBehaviour> In het verdere verloop stellen we zo een transitie voor door de volgende notatie: Insert T S 1 T S 2 22

29 Na de splitsing verkrijgen we Insert P aswoord T S 1 T S 2 Insert T S 2 T S 3 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 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

30 (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 (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

31 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 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 S 2 T S 4 DoeLogin T S 2 T S 4 25

32 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: <Rule> <TaskSet>TS2</TaskSet> <Transition> <ConditionOnTasks> <BooleanOperator name="and" /> <Transition> <Task name="insert data" /> </Transition> <Transition> <Task name="doe Login" /> </Transition> </ConditionOnTasks> </Transition> <TaskSet>TS4</TaskSet> </Rule> 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 één 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

33 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 één enkele dialoog konden stoppen door gebruik te maken van de zogenaamde check boxes. Het resultaat is te zien in figuur

34 Figuur 4.7: De user interface na de samenvoeging 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 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

35 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

36 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

37 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

38 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

39 (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

40 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