Objekt–åtgärdsgränssnitt
Objekt-handlingsgränssnitt , även förkortat OAI , är en förlängning av det grafiska användargränssnittet , speciellt relaterat till användargränssnitt för direkt manipulation och det kan bidra till att skapa bättre gränssnitt mellan människa och dator och öka användbarheten av en produkt.
Det finns i princip två liknande modeller när det gäller OAI. [ citat behövs ]
Denna modell fokuserar på objektets prioritet framför åtgärderna (dvs. den betonar det objekt som väljs först, och sedan alla åtgärder som utförs på det. OAI följer denna modell.
OAI modell
OAI-modellen representerar grafiskt användarnas arbetsplats med hjälp av metaforer och låter användarna utföra handling(er) på objektet. Sekvensen av arbetet är att först markera objektet grafiskt (med mus eller annan pekanordning), och sedan utföra en åtgärd på det valda objektet. Resultatet/effekten av åtgärden visas sedan grafiskt för användaren. På så sätt blir användaren befriad från minnesbegränsning och syntaktisk komplexitet i åtgärderna. Dessutom emulerar den WYSIWYG . Denna funktion hos OAI låter användaren styra sin handlingssekvens och visualisera effekterna under körningen. Om en åtgärd resulterar i en oönskad effekt, ändrar användaren helt enkelt sin sekvens av åtgärder.
I action–objekt-modellen ses datorn som ett verktyg för att utföra olika åtgärder. Medan i objekt-handlingsmodellen får användaren en stor känsla av kontroll från känslan av ett direkt engagemang. Datorn i detta fall ses som ett medium genom vilket olika verktyg representeras, vilket är isomorft att interagera med objekt i den verkliga världen.
Att designa en OAI-modell börjar med att undersöka och förstå de uppgifter som ska utföras av systemet. Domänen av uppgifter inkluderar universum av objekt inom vilka användaren arbetar för att uppnå ett visst mål såväl som domänen för alla möjliga åtgärder som användaren utför. När man kommit överens om dessa uppgifters objekt och åtgärder, börjar designern med att skapa en isomorf representation av motsvarande gränssnittsobjekt och åtgärder.
Figuren ovan visar hur designern kartlägger objekten i användarens värld till metaforer och handlingar till planer. Gränssnittsåtgärderna utförs vanligtvis av pekdon eller tangentbord och måste därför vara visuella för användaren så att den senare kan dekomponera sin plan i steg av åtgärder som att peka, klicka, dra, etc.
På så sätt ger DMUI:er en ögonblicksbild av situationen i den verkliga världen och kartlägger det naturliga sättet för användarens arbetssekvens genom gränssnittet. Detta gör att användarna inte behöver memorera handlingsförloppet och det minskar tiden som krävs för att bekanta sig med den nya arbetsmodellen. Dessutom minskar det minnesbelastningen för användarna avsevärt och förbättrar därför användbarheten.
Uppgiftshierarkier av objekt och åtgärder
Uppgifter är sammansatta av objekt och handlingar på olika nivåer. Positionshierarkin för ett objekt och dess relaterade handling kanske inte är lämplig för alla användare, men genom att vara begripliga ger de en hel del användbarhet.
För användaren
Det naturligaste sättet att lösa ett komplext problem är att dela upp det i delproblem och sedan ta itu med dem självständigt. Genom att sedan slå samman lösningarna nås en lösning på huvudproblemet. Detta är i grunden en Dela-och-härska-strategi för problemlösning. Detta tillvägagångssätt följs i den verkliga världen av användare när de utför uppgifter. Varje komplex uppgift är uppdelad i enkla uppgifter. Det är lätt att se att genom att hantera olika nivåer inom en hierarki förenklas processen. Genom denna metod lär sig användare att utföra uppgifter utan att överväga implementeringsfrågorna.
För designern
Ben Shneiderman föreslår följande steg för designers att bygga en korrekt uppgiftshierarki:
- Känna till användarna och deras uppgifter (intervjua användare, läsa arbetsböcker och ta utbildningssessioner)
- Generera hierarkier av uppgifter och objekt för att modellera användarnas uppgifter
- Designa gränssnittsobjekt och åtgärder som metaforiskt mappar till det verkliga universum
Gränssnittshierarki av objekt och åtgärder
Denna hierarki liknar den för uppgiftshierarkin och innehåller:
Gränssnittsobjekt
Användare som interagerar med systemet bygger upp ett grundläggande koncept/modell av datorrelaterade objekt som filer, knappar , dialogrutor etc. De får också en kort erfarenhet av objektens egenskaper och hur man manipulerar objektet genom dess egenskaper. Dessutom lär de sig hur man utför åtgärder på dessa objekt för att uppnå sina datormål. Därför upprätthålls en hierarki av sådana objekt (som representerar gränssnittets resurs).
Gränssnittsåtgärder
Denna hierarki består av nedbrutna lågnivåenheter av komplexa åtgärder som skulle kunna utföras på objekt som är relevanta för domänen av datorer som tilldelas i gränssnittsobjekthierarkin. Varje nivå i hierarkin representerar olika nivåer av nedbrytningar. En plan på hög nivå för att skapa en textfil kan innebära åtgärder på mellannivå som att skapa en fil, infoga text och spara den filen. Åtgärden på mitten av att spara en fil och filen kan delas upp i åtgärder på lägre nivå, som att lagra filen med en säkerhetskopia och tillämpa åtkomstkontrollrättigheterna. Ytterligare åtgärder på lägre nivå kan innebära att välja namnet på filen, mappen att spara i, hantera fel som utrymmesbrist och så vidare.
För användaren
Det finns flera sätt som användare lär sig gränssnittsobjekt och -åtgärder som demonstrationer, sessioner eller försök och felsessioner. När dessa objekt och handlingar har en logisk struktur som kan relateras till andra välbekanta uppgiftsobjekt och handlingar, blir denna kunskap stabil i användarens minne.
För designern
OAI-modellen hjälper en designer att förstå de komplexa processer som en användare måste utföra för att framgångsrikt kunna använda ett gränssnitt för att utföra en viss uppgift. Designers modellerar gränssnittsåtgärder och objekt baserat på välbekanta exempel och finjusterar sedan dessa modeller för att passa uppgiften och användaren.
- Ben Shneiderman, Designa användargränssnittet
- Amir Khella, Object Action Interface Model