GRIP 2000 Föreläsning 8 Innehåll MDI Informationsergonomi Användargränssnitt Vad, varför, hur? Verktyg för att bygga interaktiva, grafiska applikationer

MDI Människa Dator Interaktion Användargränsnittet Dvs interaktionen mellan dator och människa Användargränsnittet Där mötet mellan människa och dator sker Egentligen lite konstig term Vi hade aldrig kommit på att använda den för tex hålslagare eller kopiatorer Termen användarvänlig gör kanske “mötet” onödigt dramatiskt lätt att använda eller affektiv vore kanske bättre Mycket handlar om utforminingen och att överbrygga klyftan mellan utvecklare och användare

Utveckling av bra användbart datorstöd med bra gränssnitt Utveckling av bra gränssnitt en interdisciplinär verksamhet Datalogi, human-, beteende- och designvetenskap Medverkan av användare dataloger mediadesignfolk experter på mänsklig kommunikation beteendevetare psykologer

Modeller och metaforer Konstruktören skapar, medvetet eller omedvetet, en konceptuell modell (begreppsmodell) Denna modell har många namn i litteraturen designmodell bruksmodellen Den mentala modell användaren skapar över vad man kan göra användarmodellen En explicit bra designmodell underlättar användarens förståelse stödjer inlärning ger uppfattning om möjligheter och begränsningar ger förutsättningar för skickligare användning om användaren formar en användarmodell som nära överensstämmer Designmodellen innehåller ofta också en metafor dvs en liknelse med något som har liknande egenskaper som tillämpningen tex målarlåda, telefon, skrivmaskin, skrivbord, cirkus,….

Informationsergonomi När avancerade system fallerar beror det ofta på handhavandefel den mänskliga faktorn Skall man söka felet hos användaren eller den som byggde systemet? Från andra världskriget började amerikanska försvaret intressera sig för vad “den mänskliga faktorn” var eller berodde på Den nya form av ergonomi som också tar hänsyn till psykologiska faktorer, med inslag av mäsnklig perception och kognition, kallas (synonymt) för: Informationsergonomi Kognitiv ergonomi och på engelska “Human Factors”

Användargränssnitt Är den del av applikationen som låter användaren interagera och kontrollera tillämpningen med (vanligen) mus och tangentbord. Ett användargränssnitt består av grafiska komponenter (eng widgets eller gadgets) som knappar, inmatningsfält och listor. En komponent (widget) beskriver både utseende, delar av beteendet och koppling till applikationsmodellen. Bra användargränsnitt är självförklarande ger bra återkoppling ”kraschar mjukt” med bra förklarande felmeddelanden stödjer både nybörjare och experter

Som utvecklare: varför och hur? Varför är gränssnittet viktigt? Är interaktiva gränssnitt bra? Är en viss typ av gränssnitt bra i alla situationer?

Design och konstruktion av gränssnitt Vad är design? (Efter Carroll och Rosson 1985) En process som svårligen beskrivs i statiska termer Icke hierarkisk, dvs varken strikt botten-upp (bottom-up) eller uppifrån-och-ner (top-down) Processen är radikalt förändrande, dvs den innehåller del- eller detaljlösningar som kan påverka den slutliga designen Designen innehåller i sig själv upptäckande av nya mål

... Traditionell kodbaserad beskrivning Generatorer Grafiska verktyg OpenGL Smalltalk Java X Generatorer Som från textuella beskrivningar genererar gränssnitt Grafiska verktyg Vanligen av typ målarlåda där gränssnitten konstrueras på ett direktmanipulativt sätt

Vad bör man tänka på vid konstruktion? Vad är uppgiften? Vilken information behövs? Hur jobbar man idag? bra, dåligt. Vilka fel görs? Vilka (för-)kunskaper behövs för uppgiften? etc. Vem skall använda systemet? Nybörjare Tillfälliga eller sporadiska användare Personer som använder systemet ofta utan att vara experter Experter I vilken omgivning skall systemet fungera?

Shneidermans principer Princip 1: Var medveten om olikheter Människor är olika Människor lär, tänker och löser problem på olika sätt En del föredrar tabeller, visa gillar grafiska representationer och andra vill helst arbeta med text och siffror Vem skall använda systemet? Vilka uppgifter skall utföras och hur frekvent? Interaktionsstil Direktmanipulation Menyer Formulär Kommandospråk Naturligt språk

... Shneidermans ... Princip 2: Åtta gyllene regler Sträva efter enhetlighet Erbjud kortkommandon (för den erfarne användaren) Ge återkoppling Designa dialoger så att dom är ”slutna” med handlingar organiserade med tydlig början, mitt och slut Undvik att låta användaren göra fel (tex genom att menyer används) och försök göra felhanteringen enkel Gör det enkelt att ångra handlingar (”undo”) Sträva efter att användarna av systemet känner att dom har kontroll (och inte systemet som kontrollerar dem) Minimera belastning av korttidsminnet 7 ± 2

... Shneidermans Princip 3: Undvik fel Användare gör fel hela tiden! I ordbehandlare, kalkylark, databaser, trafikledning, osv En undersökning visade att erfarna professionella användare av ordbehandlare och operativsystem gjorde misstag eller valde ineffektiva strategier i 31% av uppgifterna som tilldelades dem Vissa förbättringar genom bättre felmeddelanden fast bättre att undvika felen! För varje felmeddelande fundera på om det inte finns en lösning som undviker felet helt och hållet. Meddela vad som är fel (tex matchande parentesfel) Se till att kompletta sekvenser genomförs Korrigera kommandon Genom automatisk ifyllnad Eller hellre, undvik felen genom ett direktmanipulativt gränssnitt

Det finns även andra "som har principer" Tex Nielsens och Molich Heuristiska utvärderingskriterier (lite fritt översatt och förenklat nedan) Tydliggör alltid systemets status för användaren Anpassa systemet till verkligheten Ge användaren "modet" att experimentera genom att erbjuda sätt att ångra och göra om (dvs erbjud undo och redo) Var konsekvent i språkbruk och följ plattformens standard Undvik om möjligt fel redan från början Försök få användare att känna igen istället för att behöva minnas Gör systemet flexibelt och användbart både för nybörjare och experter Undvik onödig information (i tex dialoger) Hjälp användare att känna igen, diagnostisera och återskapa efter fel Erbjud lättillgänglig, lättsökt och konkret hjälp

Hur presentera information? Organisera skärmen Var konsekvent terminologi, förkorningar, användning av stora bokstäver, etc Effektiv kunskapsinhämtning för användaren familjär och uppgiftsanpassad design Minimera belasting av användarens minne organisera informationen så att risken för att användaren glömmer något minimeras (använd ”lablar” mm) Gör ut- och inmatning så lika varandra som möjligt om möjligt skall data kunna matas in eller editeras där det presenteras Gör det möjligt för användaren att kontrollera eller anpassa form och format att passa sina egna önskemål

... Påkalla användarens uppmärksamhet Intensitet Markering Storlek använd två nivåer där den högre (påkallande) används sparsamt Markering omslutande rektangel, pekare, bulle, asterisk, små markörer, etc Storlek Font Invers video Blinkande Färg ”Färgbytesblink” Ljud

Hur bör inmatning ske? Var konsekvent liknande sekvenser av operationer skall leda till liknande resultat Minimera antalet användaroperationer tänk bla på experter och kopiera in tidigare inmatade data som defaultvärden Minimera belasting av användarens minne undvik att användaren skall behöva komma ihåg långa listor eller koder Gör ut- och inmatning så lika varandra som möjligt Gör det möjligt för användaren att kontrollera eller anpassa form och format

GUI:s, IDE:er mm För att utveckla grafiska interaktiva gränssnitt används idag ofta så kallade gränssnittsbyggare, Graphical User Interface (GUI) builders Dessa är idag vanligen av typ målarlåda där man istället för att rita linjer, cirklar, polygoner, mm bygger man knappar, listvyer, tabeller, mm Man använder komponenter med både grafik och beteende (s.k. widgets) Tidiga (mitten av 80-talet) är HyperCard, ExperInterface Builder, NeXTs Ger snabbare utveckling av applikationer än med "traditionell" metodik En annan trend är Integrated Development Environment (IDE) Dessa ger stöd för hela utvecklingsprocessen med vanligen med speciella verktyg för att skriva, avlusa och versionshantera kod Innehåller idag ofta också GUI-byggare Bland dom tidigaste och mest tongivande var Smalltalk (mitten av 70-talet) Några vanliga VisualAge, Borland JBuilder, Visual Basic, VisualWorks Snabbar upp processen att utveckla, underhålla, förändra och samarbeta vid programutveckling ytterligare.

Gränssnittsbyggare, vad? Verktyg för att konstruera grafiska gränssnitt både presentation och interaktion Synonymer UIMS (User Interface Management Systems) IB (Interface Builder) Tidigare användes ofta textbaserade tekniker kod formella språk Idag oftast grafiska av typ målarlåda

Att använda gränssnittsbyggaren för konstruera fönster med egen vy Definiera gränssnitt Inställningar Palett ”Rityta”

Typisk struktur vid konstruktion mha gränssnittsbyggare Beskrivning av gränssnitt och interaktion Användargränssnitt ”Brygga” som tillämpningsanpassar domänmodellen Tillämpningsmodell Domänmodell Logisk applikationsmodell (business model)

Typiskt gränssnitt Verktyg Knappar Textyta

Typisk gränssnittsbyggare Består av Canvas, en yta där komponenter placeras Palett, en uppsättning av olika komponenter Canvas tool, för hantering av komponenterna och öppnande av specialverktyg specialverktyg, för att konstruera menyer, ikoner mm Tillvägagångsätt "rita" gränssnitt (mha widgets i paletten) konstruera kodstubbar (ofta halvautomatiskt) definiera relationer och beteende beskriv vad som skall hända vid förändringar (ungefär som att definera tillståndsövergångar) Upprepas ofta om och om igen!

Vi kodar ofta delar av ett gränssnitt på vanligt sätt och använder gränssnittbyggaren för att definiera vanliga widgets, layout osv Med gränssnittsbyggaren ”skapar” vi enkelt ”snyggare gränssnitt” för inbäddade (MVC-) komponenter

Avsikt Anledningar till att använda gränssnittsbyggare Konstruera goda interaktiva tillämpningar på så kort tid som möjligt. Låta programmerare (och andra) fokusera på designen istället för på detaljer i miljö och implementationsredskap. WYSIWYG (What You See Is What You Get) med IBs baserade på målarlåda Enklare att "portera" och återanvända kod

Motivation Varför IBs? Stor del av koden har med UI att göra Undersökningar har visat att så mycket som 80% av koden kan hänföras till gränssnittet (Myers, Blair och andra) Bråttom att få ut produkter Kraven på att tiden från idé till produkt skall vara kort har ökat Mindre kod att skriva för hand Grafiska utvecklingsverktyg reducerar ofta den del av koden som måste skrivas på konventionellt sätt med 80%

... forts ... Enklare för domänexperter och användare att delta i utvecklingen Man önskar att kravställare, slutanvändare och människor med olika expertkunskap skall kunna bidra och deltaga under alla steg av utvecklingen Prototyper För att minimera missförstånd (i tex krav) eller få bättre utgångspunkter vid designdiskussioner vill man ofta så fort som möjligt konstruera prototyper

... forts Anpassning till olika underliggande mjuk- och hårdvara Separation av applikation och grafiska paket på lägre nivå gör det enklare att implementera olika interaktionstekniker eller unyttja olika hårdvaror Minimera risken för fel Med en gränssnittsbyggare ökar trovärdigheten och risken för fel i dessa delar minimeras genom att (väl-) designade och uttestade komponenter används.

Tillämpbarhet Grafiska interaktiva tillämpningar (dvs idag dom flesta) Grafiska tekniker har också använts för att beskriva mer funktionella aspekter av en applikation (Chang, Myers) temporala aspekter constraints

Variationer Olika metaforer Det finns till och med verktyg där man har gått så långt att man betraktar komponenterna som skådespelare på en scen (Director) som kanske också lärs upp att bete sig på önskat sätt (Programming by Rehearsal, Gold & Finzer)

Struktur Struktur (typisk) Pre-processor “run-time” Efter-processing stöd under körning Lim Analyspaket Bibliotek med Interaktionstekniker Gränssn.def Loggning o.dyl. Interaktionsteknik- byggare

Delar "Deltagande" delar i gränssnittet Rita Konstruera Målarlåda med duk Palett med objekt (widgets) Verktyg för att konstruera speciella komponenter i gränssnittet, såsom meny-verktyg, ikonverktyg, positioneringsverktyg Konstruera Generator som genererar kod från beskrivningar

Testa Kör Applikationskod Presentationsdel (presentera, ändra, göm mm) Interaktionsdel (agera) Stöd vid körning (tex med namn och bindningar och liknande)

Relationer mellan delar Samarbete Basbyggstenar toolkit med widgets eller gadgets klassbibliotek framework gräsnittsdefintionsbyggaren hjälper till att avbilda interaktionshändelser på metoder i applikationen (ger ofta call-backs eller händelser)

Möjliga problem Fallgropar Design utan eftertanke Lappverk baserad på en tidig ostrukturerad prototyp Olika ”standards” kan ge framförallt layoutproblem MAC Motif Windows95

... fler problem Andra problem Fordrar ofta lång träning (kanske speciellt nytt språk) Svårt att beskriva alla delar med IB-teknik (man behöver kanske hoppa fram och tillbaks mellan olika beskrivningssätt) Ofta svårt att göra systemoberoende “utseende och känsla” (eng. look and feel) (jmf standards ovan)

Byggare i historien Några kända gränssnittsverktyg Utvecklingen av grafiska gränssnittsbyggare tog fart främst under 80-talet i och med att grafiska (direktmanipulativa) tekniker spreds ExperInterface builder (Hullot) en tidig fransk (kanske den allra första utanför laboratorieväggarna) IB baserad på Lisp NeXT IB (i NeXTStep) Elegant. Använder Objetive-C

... fler gränssnittsbyggare ... HyperCard (Apple) ett verktyg för Macintosh byggt kring en kort-och-bunt-metafor. använder ett händelsebaserat språk HyperCard gjorde tekniken känd och populär Guide För X genererar C-kodstubbar stubbarna behöver editeras manuellt - som det är gjort är det svårt att efter editering åter använda de grafiska verktygen Peridot interaktionstekniker kan beskrivas genom att utvecklaren “demonstrerar” hur de skall gå till (Programming by Example)

... ännu fler ... Garnet VisualSmalltalk och Parts for Java Delphi efterföljare till Peridot med många olika verktyg för att bygga applikationer VisualSmalltalk och Parts for Java direktmanipulativa, händelsestyrda gränssnittsbyggare Delphi för (bla) ObjectPascal ARK (Alternate Reality Kit, Smith) rolig direktmanipulativ IB som bygger på fysikaliska lagar

... Visual Basic (Microsofts) JBuilder VisualAge för Smalltalk, C++ och Java från IBM VisualWorks Baserad på Smalltalk-80 och ättling till Xerox Smalltalk i rakt nedstigande led ... och många många fler ...

VisualSmalltalk

...resultat.

Parts for Java

Klippa och klistra samt Drag and Drop Lyssnare och adaptorer beskriver ett relativt komplext maskineri för att hantera interaktiva applikationer Ändå har vi inte diskuterat behovet av flera parallella aktiviteter, exempelvis animerade cursors och indikatorer-för att ge återkoppling sliders och liknade som visar hur stor del av en ”uppgift” som är avklarad (tex en kopiering) Sådana saker implementeras ofta mha trådar (/lättviktsprocesser), semaforer, monitorer och liknande

... I direktmanipulativa gränssnitt har vi också ofta krav på att kunna klippa ut och klistra in objekt både texter och andra objekt som bilder, ljud, filmsekvenser eller hela dokument Inom en applikation kan vi alltid klara av detta genom att definiera en egen klippbuffert Mellan olika applikationer behöver vi (i det generella fallet) stöd från bakomliggande system i UNIX finns stöd för att flytta text på MAC och i Windows finns också stöd för bilder och en del andra typer av objekt

... Ännu mer komplext är att dra ett objekt från en plats och släppa det på en annan (Drag and Drop) Då krävs att vi får återkoppling i själva processen, med mekanismer som indikerar att vi släpar iväg ett objekt, att möjliga ”destinationer” ger återkoppling på vägen (tex med invers video för dem som kan hantera objektet) ett objekts tillstånd påverkas av både applikationens och andra objekts tillstånd dom ingående applikationerna behöver också ett format som gör att dom både kan ta hand om ”transporterat data” och utbyta information mellan varandra, både under pågående dNd och vid själva data/objekt-utbytet Typiskt kommuniceras kontroll: tillåtet att aktivera, ändra, sluta, ta över processen förändringar: ge återkoppling, kan vi droppa här, bli inaktiv

… Idag är klippa och klistra mer eller mindre "en standard" och programspråk som VisualWorks och Java har högnivåstöd för detta I VW hanteras detta via klasserna ParagraphEditor för lokala textklipp och via Pixmap respektive Screen för att hantera bilder respektive kommunicera med omgivande system I Java hanteras motsvarande i java.awt.datatransfer med klasserna DataFalavour, Clipboard och gränssnitten Transferable samt ClipboardOwner i spetsen Släpa-och dra I VisualWorks är det ett antal olika klasser med DragDropManager som motor som definierar hur det hela skall gå till I Java stödjs drag-and-drop fom JDK1.2 För att kunna göra detta mellan olika applikationer generellt behövs stöd från underliggande system (finns tex i COM)

Kan man ha nytta av GUI:s och IDE:er? Slutsatser Kan man ha nytta av GUI:s och IDE:er? Snabbar upp konstruktion av speciellt interaktiva, grafiska applikationer Bra vid snabb protyputveckling Stödjer (ibland) teamutveckling Förenklar inlärning och utnyttjande av speciellt komplexa omfattande klassbibliotek Bra vid "refactoring" Förenklar underhåll och andra typer av förändringar Minskar risken för fel och snabbar upp processen att hitta och rätta fel om dom uppkommer