Retrospective and Challenges for Model-Based Interface Development Pedro Szekely.

Presentasjon om: "Retrospective and Challenges for Model-Based Interface Development Pedro Szekely."— Utskrift av presentasjonen:

1 Retrospective and Challenges for Model-Based Interface Development Pedro Szekely

2 Introduksjon ● Model-based interface development tools er verktøy som benytter seg av fyldige representasjoner (oppgavespisifikasjoner, data -og relasjonsmodeller, presentasjon -og dialogspesifikasjoner etc.) for å hjelpe utviklere i arbeidet med utforming av brukergrensesnitt. ● Eksempler på slike verktøy kan være: – Automatisk brukergrensesnittgenerering – Automatisk hjelpesystemsgenerering – Brukergrensesnittrådgivning – Brukergrensesnittevaluering ● Til tross for en del sofistikerte verktøy har ikke denne typen blitt spesielt populær i kommersiell sammenheng.

3 Modellbasert Grensesnittutviklingsprosess

4 Retrospektiv: Automatiserte designverktøy (1) ● Har som hovedmål å automatisere så mye som mulig av design og implementasjon av brukergrensesnitt. ● Benytter seg av domene -og oppgavemodellene og genererer abstrakt og konkret grensesnittspesifikasjon. ● Brukes i hovedsak til å generere grensesnitt som benyttes til databasemanipulasjon.

5 Retrospektiv: Automatiserte designverktøy (2) ● Etter generering kan en designer benytte en “grensesnittsnekker” (interface builder) for å gjøre designet estetisk penere. ● Problemer: – Det er vanskelig (umulig?) å lage gode grensesnitt ved kun å benytte seg av domene -og oppgavemodellene. – Brukere vil gjerne ha brukergrensesnitt på en form som ikke lar seg automatisere. – Genererer et unødvendig stort antall vinduer.

6 Retrospektiv: Automatiserte designverktøy (3) ● Designutvikling bør ikke være 100% automatisert, heller et samarbeid mellom designeren og verktøyet. ● Verktøyet bør komme med forslag og alternativer, men det er designeren som tar avgjørelsene. ● Den abstrakte og konkrete spesifikasjonen bør være tilgjengelig for designeren. ● Spesifikasjonene må være mulig og tilpasse på all plan.

7 Retrospektiv: Spesifikasjonsbaserte verktøy (1) ● Gir designer tilgang på et kraftig språk for spesifisering av grensesnitt. ● Skal gi designer mulighet til å spesifisere alle tenkelige grensesnitt.

8 Retrospektiv: Spesifikasjonsbaserte verktøy (2) ● ITS, eksempel på spesifikasjonsbart verktøy ● Man mapper fra abstrakt representasjon (over) til konkret representasjon v.h.a. stilregler, som gjerne inneholder betingelser av typen “if the content is a choice, then construct a vertical group of a title, and something else, depending on which of the nested conditions match.”

9 Retrospektiv: Spesifikasjonsbaserte verktøy (3) ● Forskjellen på automatiserte og spesifikasjonsbaserte systemer er filosofien, modelleringsspråket er henholdvis lukket og åpent. ● Spesifikasjonsbaserte verktøy benytter seg gjerne av vinduklasser, slik at man ikke trenger å lagre regler for alle vinduene, bare klasser av vinduer.

10 Retrospektiv: Generering av hjelpesystemer ● Benytter seg av modellene som ble brukt til å konstruere selve brukergrensesnittet. ● Kan gjerne svare på spørsmål av typen “Hvordan gjør jeg X”. ● Noen systemer generer animasjoner som viser brukeren hvordan ting gjøre, andre genererer tekstlig hjelp – eller begge deler. ● Muligheten til å automatisere konstruksjonen av hjelpsystemer er en av hovedgevinstene ved å bruke modellbasert teknologi.

11 Retrospektiv: Modelleringsverktøy (1) ● ITS, som er det mest brukte verktøyet for modellbasert brukergrensesnittutvikling benytter seg ikke av et grafisk grensesnitt, men en teksteditor. Hvorfor? – Utviklere lærte seg språket fort. – Et grafisk grensesnitt ble utviklet, men sluttbrukerene ville ikke bruke det. – Teksteditoren var lett og lære og hadde kjekk funksjonalitet som klipp og lim, effektiv søking, global erstatting, enkel kommentering osv...

12 Retrospektiv: Modelleringsverktøy (2) ● Men erfaring med CASE-verktøy har vist at grafiske verktøy for modellering er praktisk under utvikling av store applikasjoner. ● Eksempel: Grizzly Bear – Forsøker å skjule modellen for utvikleren og gir han/hun muligheten til å tegne grensesnittet som i en tradisjonell “grensesnittsnekker”. – Verktøyet bygger grensesnitt basert på en demonstrasjon av hvordan applikasjonen skal brukes. – Er det første skritt på vei mot denne typen verktøy, men mye jobb gjenstår før det kan brukes til utvikling av større applikasjoner.

13 Retrospektiv: Designkritikere og rådgivere (1) ● Kan evaluere et design på mange felt, basert på modellene: – Egenskapsverifikasjon: Kontrollerer at grensesnittet har visse egenskaper (f.eks. at alle skjermbilder kan dukke opp) – Sluttbrukersimulering: Forsøker å forutse hvor lang tid en bruker vil bruke på forskjellige oppgaver, læringstid, sannsynligheten for feil osv. – Sjekking av rettningslinjer: Finner ting som f.eks. mangel av mnemonisk F i File.

14 Retrospektiv: Designkritikere og rådgivere (2) ● Designrådgivere kan sees på som pro-aktive kritikere. ● Istedet for å fortelle designerene hva de gjør feil, forsøker de å styre dem vekk fra dårlig design. ● Kompletterer spesifikasjonsbaserte verktøy slik at designeren slipper å lage spesifikasjoner på egenhånd. ● Blir istedet ledet av ekspertisen til de som lagde rådgiveren.

15 Utfordringer og muligheter (1) ● Så mye av dette forrige onsdag. ● Vi ser nye inn -og utenheter i horisonten. – Større og mindre utenheter – Tale, håndskrift og håndbevegelser vil bli brukt som input. ● Modellbaserte verktøy er i prinsippet bedre egnet for utvikling av fremtidens grensesnitt enn dagens “grensesnittskreddere”.

16 Utfordringer og muligheter (2) ● Oppgavesentrerte grensesnitt – Problem: Brukerene har vanskeligheter med å finne ut hvordan de skal bruke alle mulighetene i programmet. – Løsninger: Veivisere (Wizards f.eks. i Office) og guider (f.eks. hjelpesystemet i Office, søker etter hjelpeord, guiden kommer med forslag til hjelp) – I dag lages denne funksjonaliteten uavhengig av selve grensesnittet. – Bør kunne automatiseres.

17 Utfordringer og muligheter (3) ● Multiplatformstøtte – I dag: Designe den samme applikasjonen fra grunnen av for flere platformer. – Det ideelle hadde vært å fått til en automatisk konvertering. – Eksempel: Skalering til forskjellige typer utenheter (desktop > laptop > PDA > mobiltelefon)

18 Utfordringer og muligheter (4) ● Skreddersydde grensesnitt: Muligheten til å skreddersy og optimalisere designet til den kontekst det brukes i. – Designet kan skreddersys hos utvikler eller av sluttbrukeren selv. – Skreddersøm både på abstrakt og konkret nivå. – Forfatter mener det bør bli mulig med mer støtte for skreddersøm på sluttbruker -eller administratornivå.

19 Utfordringer og muligheter (5) ● Multi-modale grensesnitt – Et grensesnitt må kunne tolke input fra innenheter som tale og håndbevegelser. – I dag: Denne funksjonaliteten lages uten hjelp fra grensesnittverktøy.

20 Konklusjon ● Modellbaserte teknologier har til nå ikke blitt brukt i voldsomt stor grad. ● Men med nye inn -og utenheter kan denne teknologien få en ny vår. ● To utfordringer: – Det må lages applikasjoner som viser styrken til modellbaserte verktøy. – Man må ta for seg de utfordringer som er diskutert over.