Innledning SIF80AP Future and HCI av Brad Myers m.fl.

Problemstilling Grensesnittutvikling har vært bygget på de samme prinsippene siden 1984 (Mac) Nye elektroniske enheter og bortgangen fra den tradisjonelle PCen setter nye krav til hvordan grensesnitt må utvikles

Problemstilling Vindusbasert grensesnitt på desktopmetafor de facto standard Tilpasset PC med mus, tastatur, monitor Positivt for brukere og utviklere

Problemstilling Tradisjonell PC på vei ut PDA, mobiltelefon, kjøleskapsdatamaskin, elektroniske joggesko på vei inn Nye former for input og output Generelt MYE mer variasjon i fremtiden

Hvorfor verktøy? Verktøy bestemmer hva vi kan og ønsker å lage Mindre koding Raskerer prototyping Konsistens

Historie Ser på metoder og teknikker: Hvilke har funket frem til nå? Hvilke har ikke funket? Hvorfor?

Historie Evalueringskriterier -Terskel og tak -Minste motstands vei -Forutsigbarhet -Bevegelig mål

Hva funket? Window Managers and Toolkits Egner seg vel for menneskelig sansing og tankegang Verktøy gjør det lett å bygge konsistent Tvangstrøye?

Hva funket? Event Languages Mapper utmerket mot inputenheter på tradisjonell PC Nye enheter har kanskje radikalt andre former for inputmetoder

Hva funket? Interactive Graphical Tools Kun fokus på utseende (lav terskel) Rask prototyping Begrensning i hva som kan lages

Hva funket? Component Systems Modularisering Gjenbruk

Hva funket? Scripting Languages Rask prototyping og umiddelbare endringer Lav terskel Svært kraftfullt når brukt kombinert med komponenter og GUI-verktøy

Hva funket? Scripting Languages Lavt tak Umulig å lage et språk som er både enkelt OG har avanserte muligheter (lav terskel  høyt tak )

Hva funket? Hypertext Allemannseie Lav terskel for både bruk og visning Mange utvidelser For spesifikt

Hva funket? OO programmering Mapper naturlig mot grensesnitt elementer

Hva funket ikke? UIMS –Tatt av standardiseringen Verktøy basert på formelle språk –Bevegelig mål (dialogmodeller) –Minste motstands vei (sekvensering) –Høy terskel (nytt språk)

Hva funket ikke? Constraints –Uforutsigbart –Høy terskel

Hva funket ikke? Modellbaserte og automatiske teknikker –Uforutsigbart –Høy terskel OG lavt tak –Krav om enhetsuavhengighet kan gi disse et nytt liv!

Hva har vi lært av historien? Unngått bevegelig mål pga. ”Standard” Høyt tak  høy terskel Lav terskel  lavt tak Gjør det lett å gjøre ting riktig! (minste motstands vei)

Fremtiden Datamaskiner allemannseie –Utviklere har ikke noe forsprang på teknologien  bevegelig mål –Høy ytelse = høyere krav

Fremtiden Datamaskiner overalt (eller: alt er datamaskiner) –Endret potensial for input/output –Nye former for interaksjon –Medfører forskjellig grensesnitt for forskjellige plattformer –Enhetsuavhengige teknikker?

Fremtiden Grensesnitt del av fysisk enhet –Prototyping av hele enheten Koordinering mellom enheter av forskjellige typer –Hva skal to brukere med forskjellig enhet se? –Grensesnitt må kjenne sin kontekst

Fremtiden Gjenkjennelsesbaserte grensesnitt (tale, bevegelser, håndskrift) –Brukeren bestemmer input/ouput metode –Input kan feiltolkes –Grensesnittet må vite hva programmet gjør –Hendelsesmodell funker ikke

Fremtiden 3D Sluttbrukertilpassning/programmering

Hensyn å ta i fremtiden Brukernes egenskaper –Eldre brukere –Handikappede brukere Komponentbiblioteker –Tilpassing av komponenter Interaktivitet –Bruker opptatt med andre ting (bilkjøring)

Hensyn å ta i fremtiden Oppmerksomhet –Mengden av enheter kan gjøre oppmerksomhetskrav plagsomt Evalueringsverktøy –Raske itereringer i utvikling krever tilsvarende effektiv evaluering Brukbarhet –Verktøy bør ”tvinge” frem brukbarhet

Operativsystemet Grensesnittet bør kjenne plattformens egenskaper Strengere kobling/kommunikasjon mellom grensesnitt og OS

Konklusjon Vet ikke lenger for hva slags grensesnitt man lager verktøy for Store endringer i design pga teknologiske nyvinninger Bevege seg fra hendelser til grensesnitt som kjenner konteksten og beskriver prosedyrer

Konklusjon Trenger både lav terskel OG høyt tak for verktøy Viktigere med forutsigbarhet enn ”smarte” løsninger Verktøy må løse brukbare grensesnitt