IT-universitetet, Chalmers Grafiska Gränssnitt, 6p Kursansvariga: Staffan Björk, Sus Lundgren

Vårt släktträd IT-universitetet, Chalmers Grafiska Gränssnitt, 6p Kursansvariga: Staffan Björk, Sus Lundgren 2003-10-08 Jessica Göransson Annelie Günzel Anna Olvenmyr Yvonne Stenberg Sofia Torbertsson

Inledning Syfte Uppgiften var att skapa en applikation för att låta folk utforska släktdata. Den tänkta applikationen ska låta en användare grafiskt utforska människor som är släkt med varandra. Användaren ska kunna utgå ifrån flera olika stampersoner. Analys Användargrupp och funktionalitet Vår primära användare till vår applikation är en person som vill se vilka släktingar han eller hon har. Därefter har vi utformat tänkta frågor och navigationsbehov. Även en person som bara är intresserad av släkten kan dock ha utbyte av applikationen. Vi har valt att inte göra några åldersavgränsningar. En förutsättning för att kunna använda vår applikation är att användaren måste ha en viss datorvana, eller i alla fall vara intresserad av datorer. Applikationen är till för både nöje och nytta. Navigationsbehov Efter en analys av användaren baserad på diskussioner om designen ansåg vi att det finns flera olika sätt att vilja navigera i en släkt: * Användaren vill följa varje gren och nästa förgrening och nästa till man kommer längst ut i grenen. Därefter går personen tillbaka en nivå och utforskar den och arbetar sig systematiskt tillbaka till stamfadern. 2

* Användaren följer en av släktgrenarna längst ut och vill sedan direkt tillbaka till stampersonen. * Användaren följer släktgrenarna mer slumpmässigt efter någon som fångar intresset. Det är därför viktigt att hela tiden veta var i informationsmängden han /hon befinner sig och vilka delar av trädet som redan är utforskade. * Användaren vill leta upp en särskild släkting. * Användaren har specifika frågor om släkten som till exempel: Vilka i släkten fyller jämnt i år? Vilka i släkten fyller jämnt i år?, Vem är/har blivit äldst/yngst?, Vilka i släkten lever idag?, Finns det någon mer som heter som jag?, Hur gammal blev den äldste i släkten? osv. Zoomning och sökning Vi har inte tänkt oss att användaren ska kunna söka på alla dessa frågor men de ska kunna besvaras via vår applikation. Dessa funktioner vill vi alltså att vår applikation på något sätt ska stödja. Eftersom vår användare är en vanlig privatperson med ett intresse för sin släkt med eventuellt begränsad datorvana har vi valt att använda oss av zoomning. Zoomning är en intuitiv teknik som de flesta känner till från vardagliga sammanhang, som vanliga förstoringsglas. Vår tanke är att användaren ska kunna zooma in på den yta de vill veta mer om och där få möjlighet att titta närmare på släkten. Genom att klicka på en liten modell av trädet ska användaren kunna zooma ut igen för att fortsätta söka i släkten. Vi tror även att det är viktigt för användaren att lätt kunna se var i släkten där han/hon befinner sig, så att han inte känner sig vilse i släkten. 3

Vårt system med zoomningen är utbyggbart att lägga till ytterligare information. Vi har också planer på att lägga till en extra ruta när man pekar på någon person, om informationen skulle bli för omfattande. För att förenkla för den användare som vill ha svar på specifika frågor har vi skapat en sökfunktion. Till den bifogar vi en lista med vanliga frågor, som framgår av prototypavsnittet. Design Våra idéer Vi valde att utgå från den grundläggande informationen som fanns i varje personfil. Där fanns bland annat information om vilka barn personen har, vilka föräldrarna är samt födelse- och dödsdatum samt kön. Gruppen har haft lite olika idéer på lösningar till uppgiften. Den första idén vi kom på var att skapa ett grafiskt träd som användaren skulle navigera i. Tanken träd uppstod snabbt eftersom det är en metafor många människor tänker på angående släkter. Det är ju väl vedertaget att göra denna koppling. Vi tyckte dock att denna metafor kändes tråkig eftersom den kändes så traditionell. När vi funderade vidare kom vi att tänka på idén med ett hus. Vår tanke var att varje generation skulle bo på varsin våning och stampersonen i källaren eller bottenvåningen. Gifta personer skulle bo i samma rum. För att navigera mellan de olika våningarna (generationerna) skulle man använda sig av en sorts hiss. Vi fick dock snabbt problem med detta eftersom släkter blir bredare och bredare ju högre upp man kommer och det blir en konstig proportion på ett hus. Det blev dessutom svårt att bygga till det efterhand som släkten blir större. 4

Vi valde istället att återgå till trädmetaforen. Vi sökte inspiration på nätet och tittade på andra redan befintliga program om släktträd. Vår gemensamma uppfattning var att de flesta träd inte bara såg tråkiga ut, de var inte heller speciellt överblickbara. Här myntades idén i att försöka skapa ett roligt och glatt släktträd som skulle vara lättnavigerat. Vi bestämde oss för att vi ville ha ett riktigt träd i bakgrunden och utformade lite olika förslag på sådana. I avsnittet om färger och trädets utseende motiverar vi våra slutliga val beträffande trädet. När vi hade bestämt vilken struktur vi skulle ha hade vi lite överläggningar om hur vi skulle visa släkten. Skulle vi börja med släktens äldsta eller yngsta överst eller underst? Vi bestämde oss för att låta de äldsta, de så kallade stampersonerna, ligga längst ner. Det är de som bygger upp släkten på samma sätt som stammen bär upp trädet. De yngsta i släkten kändes dessutom logiska att ha som löv längst ut i trädet eftersom de är nyast tillkomna. Designbeslut Vi resonerade som tidigare nämnts mycket fram och tillbaka om hur vi skulle visa presentationen av släkten. Det sätt vi slutligen kom fram till var att vi ville börja med en förminskad bild av hela trädet där användaren kan se hur släkten är sammanlänkad, men eftersom trädet blir så stort så går det inte att läsa släktinformationen. Denna bild fungerar som en karta över trädet[3]. Vi har tänkt oss att användaren ska kunna klicka i modellen av trädet och på så sätt välja var i trädet han eller hon vill börja släktforskningen. När användaren klickar på en plats i trädet visas en stor inzoomning av denna del. Här får användaren upp information om den delen av släkten han har valt att titta närmare på. För att navigera runt i trädet från denna inzoomning klickar användaren på pilar i hörnen av bilden och tar sig på så sätt ett steg 5

åt det hållet pilen pekar. Hela trädet ligger här i bakgrunden uppförstorat, men användaren tittar bara på en liten del av trädet i taget. Vi har diskuterat runt att ha zoomingen i olika nivåer, vilket skulle kunna tänkas vara en fördel vid stora träd. När användaren väl har valt vilket ställe i trädet som skall zoomas, skall det sedan i det andra läget vara möjligt att klicka/markera en utvald person. Då kan användaren utnyttja vår funktion med fördefinierade frågor på den markerade personen. Användaren kommer då att ha två möjligheter till att utnyttja denna funktion, antingen genom att alltså först markera personen eller genom att skriva in namnet på personen direkt i en sökruta. Vi har även tänkt att förtydliga den person som är i fokus genom att använda en ram i färg runt personrektangleln. På den inzoomade sidan kommer även en miniatyr av trädet (en knappikon), placerad i övre högra hörnet att visas. Denna miniatyr är klickbar och symboliserar en hänvisning till startträdet och skall ytterligare förtydliga för användaren var han/hon befinner sig i trädet. Om användaren vet till vilken annan plats i trädet han/hon vill komma, känns det kanske onödigt att behöva scrolla bort till denna plats. Lösningen till detta är att då användaren klickar på trädminiatyren, kommer han/hon tillbaka till förstasidan och kan där välja att klicka på en annan plats. Det finns även en markering i det lilla trädet som visar vilken del användaren besöker just nu. Detta för att underlätta navigeringen. Under vårt arbete med designen har det hela tiden dykt upp problem som vi har varit tvungna att diskutera för att kunna gå vidare. Till exempel hade vi funderingar på hur vi skulle visa en ingift persons släkt. Kanske vill användaren ha denna information. I många fall så finns inte denna information eftersom det på ett sätt tillhör en annan släkt än den man fokuserar på. Men denne persons barn tillhör ju i högsta grad släkten så därför är personen ändå intressant. Ett barnbarn vill ju kanske få reda på information om sin farfars släkt och inte bara sin mormors. Vi valde att visa 6

sådan information i ett annat släktträd. När användaren klickar på den ingifta släktingen förflyttas användaren till ett annat träd och fokus hamnar på denna person. Ett annat dilemma som dök upp var hur man löser problemet med en ingift släkting då informationen om personen behövs på mer än ett ställe i trädet, dels vid föräldrarna och dels vid maken/makan. I vår lösning har vi valt att enbart skriva ut den ingifta personens namn nedanför i samma textruta som maken/makan. Som ingift tilldelas personen således ingen egen nod i trädet. Vill man istället veta mer om den ingifta personens släkt så är det möjligt att förflytta sig till personens egna släktträd genom att klicka på namnet som vi gjort till en länk. I de fallet då det är frågan om en ingift släkting kommer länken istället att förflytta användaren till ett annat ställe i samma träd. Färger och trädets utseende Figur1. Vår bakgrundsbild till släktträdet Vi utformade lite olika förslag på bilder av träd. Vi tror inte att vår trädbild stör användaren eftersom det mer fungerar som en bakgrund till de verkliga fakta vi vill presentera. Syftet med att visa en uppförstorad del av trädet var att användaren lätt skulle kunna se var han befinner sig, i stammen, rötterna eller i kronan. Vi 7

hade diskussioner om både färg och form. De olika färgerna på löven innehåller ingen information. Löven har tre olika färger av estetiska skäl, det ger ett mer levande och vackert intryck. Även trädets grenar och rötter skiljer sig åt formmässigt för att ge ett mer levande och vackert intryck. Vi inspirerades av höstens vackra färger och valde brunt till stammen och rötterna och med gul och orange färg på löven. Vi har valt färger som är webbsäkra (gula färger), men har samtidigt medvetet försökt välja färger som ändå är ganska harmoniska. Möjligen skulle vi ha valt något ljusare nyanser för att uppnå en större kontrast och framhäva persondata, de skyltar som innehåller textinformation. Edward R. Tufte skriver i Envisioning Information [3] att ett bra sätt är att använda sig av färger som finns i naturen, särskilt de ljusa färgerna, exempelvis gult och blått. Dessa färger ger ögat harmoni. Kanske hade det därför varit bättre för ögat om vi hade haft en sorts ljusa akvarellfärger. Till den textinformation som visas i trädet har vi valt att ha en grå bakgrund. Eftersom vi valt gula och orange färger till bakgrunden ville vi ha en färg som skiljde sig från detta och som dessutom var relativt neutral. Allt för att skapa kontraster. För att tydliggöra att den ingifta släktingen är klickbar valde vi att göra denna länk grön för att skilja den från den svarta text de vanliga släktingarna har. Figur2. Bildexempel på en person-nod i släktträdet. I vår prototyp(director) har vi även gjort namnet understruket eftersom det är vanligt förekommande för länkar på Internet. Enligt Tufte är det viktigt att färgskillnader inte är det enda sättet att visa information på.[3] 8

Den klickbara ikonen av trädet som finns på den uppförstorade sidan skiljs åt genom att dess bakgrund har en orangeaktig färg. Detta visar att ikonen inte finns i samma lager som det uppförstorade trädet. Diskussion Problemet med en stor struktur är att det finns för mycket att visa från detaljer till den övergripande strukturen. I en sådan struktur är det förstås lätt att gå fel och varken hitta tillbaka eller hitta den informationen man är intresserad av. Skälet är troligtvis att vyn inte visar var den passar in i den globala strukturen. Flera metoder används för att lösa det här problemet med fokus- och kontextvisualiseringar, ofta en typ av zoomande lins. Syftet med en zoomande lins är att visa en balans mellan detaljen och kontexten. Detaljer behövs i vårt fall för att hitta information om närmaste släkting. Kontexten behövs för att visa vilken struktur som finns och var i strukturen (släktträden) användaren befinner sig. Målet är att ge användaren nödvändig detaljerad information och samtidigt en känsla och kunskap om den övriga strukturen[2]. Vi har tittat på flera tekniker för zoomning. Först fastnade vi för G W Furnas Fisheye-metod. Den bygger på att människor i många sammanhang beskriver sitt eget kvarter detaljerat men bara en bit bort endast de kända landmärkena. Samma tendens finns när det gäller relationer mellan människor. Anställda känner ofta till mellancheferna på den egna och de närliggande avdelningarna men bara de högsta cheferna för andra avdelningar [1]. Principerna återfinns också i nyhetsjournalistiken och samhällsvetenskapen genom närhet avståndsprincipen. De här resonemangen innebär att Fisheye-tekniken kan vara användbar för stora informationsstrukturer på en datorskärm som ju är relativt liten. 9

Vi ses flera nackdelar med denna metod utifrån hur vi anser att vår användare vill att släkten ska visas. Vår användare är intresserad av att få en tydlig översikt över hela släkten och hur den hänger ihop på samma vy. Samtidigt vill han eller hon ha detaljerad information om vissa personers födelsedatum med mera. Det är inte självklart att det som är halvlångt bort eller riktigt långt bort är mindre intressant när man är på detaljnivå. För en ovan användare kan det också skapa onödig förvirring när proportionerna och fokus förändras. Edward R. Tufte förordar istället en så stor mängd information som möjligt i synfältet. Ju mer information desto bättre när man till exempel ska göra ett val. Informationstät design tillåter också användaren att ha möjlighet att själv välja data. På så sätt överlämnas kontrollen över information till användaren från designers, redigerare och formgivare. I motsatta fall där informationen är utspridd över flera sidor måste användaren lita till sitt visuella minne som inte är särskilt bra. Dessutom när kontexten hela tiden byts ut tvingas användaren att koncentrera sig på förändrade visuella miljöer istället för på data. Användaren måste också komma ihåg saker som man sett i en vy för att uppfatta nästa vy effektivt[3]. Med mikro/makrodesign vill Tufte göra det möjligt för användaren att både göra lokala och globala jämförelser och samtidigt slippa att byta kontext. Vi bestämde oss för att den metoden passade vår målgrupp med begränsad datorerfarenhet bättre. Mikroperspektivet i vårt fall motsvaras av de enskilda släktingarna och makroperspektivet av släktträdet. Makroperspektivet behålls som vi nämnt tidigare hela tiden av en liten bild av trädet i det översta högra hörnet. På det lilla trädet finns också en liten röd prick som hela tiden markerar var i trädet man befinner sig för att underlätta att veta var i kontexten man befinner sig, det vill säga vilket område i trädet man zoomat in. 10

I det stora trädet, där hela trädet är synligt samtidigt (inte uppförstoringen som användaren scrollar i), får användaren hjälp med färgmarkeringar genom nedtonade färgskalor för att tydligt visa de delar han eller hon har utforskat, det allra senaste området får en mer upplyst (ljus) färgton för att visa var fokus ligger/var användaren var senast[3]. Men, hur är det med informationen som inte får plats och måste inte data förenklas? Nej, anser Tufte och menar att de ståndpunkterna bara är resultaten av en misslyckad design. Uppfattningen att enkelhet när det gäller data och design ger tydlighet baseras på trender och personligt tyckande. Förenkling är en estetisk preferens och inte en strategi för tydlig informationsvisualisering. Det mindre komplexa och subtila är oftast mindre intressant. Vad man ska eftersträva är istället en rik datamängd, en jämförande kontext och en förståelse för komplexitet. Istället för en förenkling och redigering av data propagerar Tufte för lager och separation för att göra informationen tydligare när den blir för detaljerad så att man tappar överskådligheten. Tekniken är också bra för att gruppera data på ett sådant sätt att förståelsen av den ger fler dimensioner. Information består av skillnader som gör skillnad. I vårt släktträd har man möjlighet att dels söka på namn, dels att använda färdiga sökningar som vi lagt upp. För att visa dessa använder vi oss av lager och separation. Vår idé bygger på att sökträffar visas som klickbar text i en lista och genom att de efterfrågade personerna markeras på trädet. Som komplement till lager- och separationstekniken använder vi oss av en traditionell form av zoomning. Genom att kunna zooma direkt till den nivå som användaren är intresserad av just vid ett aktuellt tillfälle kan användaren själv välja vilken information han eller hon vill gradera som viktig just för tillfället, helt i linje med Tufte. Vår önskan har varit att åstadkomma zoomning i flera nivåer. 11

Prototyp Vi valde i projektets slutskede att skapa två prototyper, en i Java och en i Director. Anledningen till detta var att vi stötte på motgångar i programmeringen och vi ville inte göra några större kompromisser beträffande vår idé p g a detta. Vi valde därför att ta fram en kompletterade prototyp som verkligen visar vårt tankesätt. Här nedan presenteras några bilder från våra prototyper. Våra två prototyper finns att beskåda och köra i sin helhet på våra portfoliosidor. Bild 1. Vår meny Vi har använt oss av en enkel meny som skall så långt det är möjligt följa standard och där valen skall vara enkla att förstå och tolka. Under menyn Arkiv finns valen Öppna och Stäng. Under valet Öppna väljer användaren själv vilken släktfil som skall köras. Under Stampersoner kommer samtliga stamfäder i den laddade släktfilen att visas och användaren kan välja vilken träd och stamperson han/han vill börja att utforska. 12

I Hjälpmenyn finns en hjälp alltid tillgänglig. Under detta menyval finns även om vårt släktträd med lite information om programmet. Bild 1. Laddat släktträd När användaren valt vilken släkt programmet skall börja att visa, ritas alla personnoder ut på vår träd enligt ovan. Här kan då användaren välja vilken del av trädets som skall utforskas härnäst genom att klicka på en del av trädet för att zooma. 13

Bild 2. Zoomad del av släktträd När den zoomade delen visas vill vi att hela trädet skall skymta i bakgrunden vilket vi inte har kunnat realisera fram till idag. Tillsammans med vårt lilla ikonträd i högra hörnet skall den förtydliga och visa var i trädet man befinner sig i trädet. När användaren klickar på ikonen för att komma tillbaka till hela trädet markeras det område besökaren just befann sig på för att användaren lätt skall få en överblick över vilka delar av trädet som har blivit utforskade. Bild 3. Sökresultat Längst upp i vänsterkolumnen finns vår sökmeny och under den presenteras sökresultatet. I bild 3 har frågan ställts om vem som blev äldst i släkten och namnet på personen visas i resultatrutan. 14

Projektutvärdering Då projektspecifikationen uppmanade till att dokumentations- och programmeringsarbete skulle löpa parallellt för att klara av tidsfristen, satte vi genast igång med programmeringen. Eftersom samtliga medlemmar i gruppen inte har programmeringsvana så var arbetsfördelningen enkel. Med facit i hand kan vi konstatera att vi från första början borde ha klargjort vilka delar vi ansåg att vi skulle kunna realisera och fokuserat på dem. Eftersom Java-kunskap finns inom gruppen menade vi att vi tillsammans skulle lösa de designförslag vi kommit fram till och ville inte begränsa vår kreativitet p g a av orutin i dynamisk gränssnittsprogrammering. De svårigheter vi har upplevt under vår prototyputveckling har varit av programmeringskaraktär men även i olika funderingar och frågor om bland annat hur vi skulle visa inzoomningen, om den exempelvis skulle göras i flera olika nivåer, hur vi skulle kunna förmedla känslan av zoomningen på bästa sätt. En annan aspekt som vi har fokuserat på är vilka frågor vi ansåg att användarna skulle vilja ha svar på och hur dessa skulle ha realiserats. Vi vill även komma åt problemet med redundans. Vi har även haft en del generationsproblem vid utritningen av trädet. I vår javaprototyp syns syskonen på olika höjd vilket vi givetvis hade velat ha på en och samma höjd. Eftersom vi valde att lägga fokus på ett gränssnitt som tilltalar ögat istället bara för ren funktionalitet, innebar det att vi stötte på problem med bild- och lagerhantering. Vi valde i projektets slutskede att skapa två prototyper, en i Java och en i Director. Återigen så ville vi inte att tidsbrist och en del motgångar i programmeringen skulle få begränsa en mycket bra idé. Därför ville vi ta fram en kompletterade prototyp som verkligen visar vårt tankesätt. Så här i 15

efterhand kan vi säga att vi borde ha påbörjat Director-prototypen tidigare så att den kunde löpa parallellt i takt med att vi fick fler idéer och som idag har all önskvärd funktionalitet. Vi har dragit mycket lärdom av detta projekt och tycker att vi har löst uppgiften efter bästa förmåga och tror på vår idé. Givetvis hade vi velat kunna lösa allt i Java men en prototyp är trots allt en prototyp och vi har ju faktiskt fått fram två som är fungerande. Referenser [1] Furnas, G.W. Generalized Fisheye Views, In Proc. of CHI 86, pp. 16-23, ACM Press, 1986. [2] Bederson, Benjamin B och Hollan, Larry och James D. Pad++: A Zooming Graphical Interface for Exploring Alternate Interface Physics. ACM, UIST 1994, pp 17-25. [3] Tufte, Edward R. Envisioning information. Graphics Press 1990. 16