Projekt 2: Informationsvisualisering av släktträd

Transkript

1 Projekt 2: Informationsvisualisering av släktträd IT-universitetet i Göteborg Interaktionsdesign - Grafiska gränssnitt Deltagare: Anders Lundell it3luan@ituniv.se Programmering, idéspruta Annica Löfving it3loan@ituniv.se Programmering, idéspruta Anna Lindvall d00anna@dtek.chalmers.se Dokumentation, idéspruta Helena Callert d00cache@dtek.chalmers.se Dokumentation, idéspruta Kalle Ulvstig ix3ulka@ituniv.se Dokumentation, idéspruta Uppdrag: Att skapa en applikation för att låta folk utforska släktdata. Applikationen ska tillåta användare att grafiskt utforska en samling människor som är släkt till varandra och det ska gå att börja från flera olika stampersoner. Utveckla ett koncept för ett grafiskt gränssnitt samt implementera en prototyp. 1. Inledning Vi börjar med att återge delar av arbetsgången där vi även definierar vår målgrupp och uppgiften utifrån den. Därefter diskuterar vi motiveringen av vårt koncept samt jämför det med redan kända begrepp. Detta följs av en beskrivning av vår slutliga applikation och implementeringen av densamma. Vi avslutar med att presentera önskvärda funktioner som i dagsläget inte finns implementerade. 2. Introduktion Projektet startade med diskussioner kring vår användare och vad målet med vår applikation skulle vara. Vi arbetade med Post-It -lappar som vi försökte kategorisera och sortera kring olika tänkta målgrupper. Rätt snart insåg vi att diskussionerna mer och mer började bero av designen för vår applikation och eftersom vi inte hade någon målgrupp att utgå ifrån utan själva skulle definiera den, så tyckte vi att vi kunde övergå till att skissa på olika designförslag och sedan försöka para ihop dem med våra Post-Its.

2 2.1 De olika designförslagen Skissandet och diskuterandet ledde slutligen fram till fem olika förslag, alla med sina föroch nackdelar, som presenteras här. Vi har hela tiden haft problemet med flera hundra noder i åtanke samt att vi även ska klara av att implementera den slutgiltiga designen. Ett tidigt mål vi strävade mot var att användaren inte ska behöva scrolla i något led då detta gör att han/hon snabbt tappar fokus och det blir svårt att se samband i informationen Designförslag 1 Detta förslag illustreras i figur 1. Tanken är att släktträdet utgår från en stamperson och sedan byggs vidare nedåt med dennes efterföljare. Då det inte är möjligt att visa all information om alla efterföljare samtidigt (speciellt inte för flera hundra noder), skall användaren kunna välja vad som skall visas genom att med musen klicka på de små plus- och minustecken som finns vid de olika personernas namn (om mer information finns att visa). Genom att klicka på ett plustecken vid en person visas denna persons make/maka samt eventuella barn. Genom att klicka på ett plustecken vid ett av barnens namn kan man visa ytterligare en nivå nedåt i denna gren, o.s.v. Om man klickar på ett minustecken skall informationen som är kopplad till detta döljas. Figur 1 Fördelar: Användaren kan själv välja vilken del av släkten som skall visas. Fokus sätts på den del av släkten som visas, övriga grenar stör inte visningen. Generationer visas på samma rad och åldersskillnad kan visas med äldsta syskon längst till vänster. Nackdelar: Det är inte säkert att man vill börja uppifrån med en stamperson i en "vanlig" släkt. Passar kanske bättre i tillämpningar i stil med "visa Gustav Vasas ättlingar", alltså i

3 mer formella fall än den egna släktforskningen då man kanske har större intresse av att se regenter i rakt nedstigande led. Trädet kan bli stort och ohanterligt om användaren väljer att inte klicka bort information genom att använda sig av minustecknen. Programmeringen blir för komplicerad Designförslag 2 Detta designförslag bygger på att man utgår från en person och sedan följer dennes släkt bakåt och "åt sidorna" (kusiner etc.). Förslaget visas i figur 2. Figur 2 Fördelar: Både moderns och faderns släkt kan visas samtidigt och jämföras. Syskon grupperas tillsammans och alla personer i en viss generation hamnar på samma nivå. Nackdelar: Det blir svårt både att bygga upp och att se strukturen i trädet när det blir större. Trädet blir lätt både högt och långt, användaren kommer antagligen att behöva scrolla för att kunna se allt, vilket gör att översikten försvinner. De båda släkterna hänger (antagligen) bara samman på ett ställe, vid person X. Det blir ett ineffektivt utnyttjande av ytan när man visar båda samtidigt.

4 2.1.3 Designförslag 3 I figur 3 visas ett förslag som bygger på den princip som används för att visa filsystemet i en dator. "Roten" utgörs av den stamperson som trädet skall utgå ifrån (jmfr förslag 1). Stampersonens barn visas under roten och genom att klicka på plustecknet bredvid en person utvecklas strukturen för denna person. Figur 3 Fördelar: Lätt att känna igen uppbyggnaden från ett vanligt filsystem. Nackdelar: Strukturen kan bli mycket lång och bred då många grenar skall visas samtidigt. Det kan bli svårt att få översikt och att kunna jämföra personer på samma nivå, detta brukar man ju inte göra i ett filsystem. Det går inte att skilja på gifta par och det blir svårt att visa att personer varit gifta flera gånger Designförslag 4 Detta förslag, som visas i figur 4, bygger på idén att visa både översikt och detaljvy samtidigt. Till vänster visas hela släktträdet och till höger en mindre del som blivit uppförstorad. Tanken är att användaren på något sätt skall kunna välja vilken del av trädet som skall zoomas, t.ex. genom att flytta runt en zoom-ruta som fungerar som ett förstoringsglas.

5 Figur 4 Fördelar: Översikt och detaljvy visas samtidigt, vilket underlättare förståelsen och ger en helhetsbild. Samma struktur visas i båda, den högra är bara mer detaljerad (konsekvens är bra för användaren). Nackdelar: Det kan vara svårt att förstå vilken del av det stora trädet som blir inzoomad om detta inte visas mycket tydligt. Även om noderna i översiktsträdet ritas mycket små kan det för medelstora släkter ändå bli omöjligt att visa all information samtidigt. Kan man inte göra detta förloras idén med en fullständig översikt. Om släkten är tillräckligt stor för att översikten trots allt inte kan innehålla all information måste en del av informationen finnas i detaljvyn. Och om detaljvyn ska innehålla funktionalitet som kan förändra dess utseende måste även översiktsvyn kunna ändra utseende om man vill bibehålla konsekvensen. Implementeringen blir genast mer komplicerad Kompletterande designidé - tidslinje Genom att markera olika personers födelse- och dödsår på en tidslinje, kan man illustrera levnadslängd och jämföra olika personer med avseende på detta på ett enklare sätt än att bara jämföra årtal. Ett förslag till tidslinjerepresentation visas i figur 5. Denna idé är tänkt som ett komplement till något av de designförslag som beskrivits ovan.

6 Figur 5 Fördelar: Livslängden illusteras tydligt och det går lättare att jämföra olika personer. Man kan både se personens ålder samt relativa livslängd. Nackdelar: Bilden blir lätt stor och rörig då många personer visas samtidigt Slutsatser efter dessa tidiga designförslag Fastän vi försökte undvika att tänka i banor om traditionell trädstruktur när vi designade så slutade det ändå med ett konstaterande att en trädstruktur nog trots allt var det bästa sättet att visa släktrelationer. Det minskar också den kognitiva belastningen hos användaren eftersom det är ett vanligt sätt att visa relationer mellan ting. Vi kan även konstatera att trots vårt strävade mot att undvika scrollning så blir det nog tyvärr en omöjlighet att helt utesluta denna funktion. Det skulle innebära icke-önskvärda begränsningar på applikationen som att t.ex. enbart visa en generation åt gången därför att person X råkar ha för många syskon. Att visa hela släktträdet samtidigt i en översikt är en bra tanke men fungerar ändå inte om släkten innehåller flera hundra noder. Det är näst intill omöjligt att visa en komplett översikt redan för medelstora släkter, om översikten skall representeras av en klassisk trädstruktur, men det är samtidigt önskvärt att ha en översiktsbild för att inte helt "gå vilse" i släktdjungeln Man får begränsa sig på något sätt genom att antingen ta bort viss information eller ändra utseendet på översikten. Slutligen kan man bara konstatera att tanken på att designen skulle vara möjlig att implementera har begränsat våra diskutioner och vår fantasi kraftigt. 2.2 Användaranalys Vi har definierat målgruppen för denna uppgift till de personer som är intresserade av att interaktivt utforska sin och andras släkter, personer som känner till sin allra närmaste

7 släkt och snarare är intresserade av relativ och statistisk information än att se exakt hur släkten är uppbyggd. Prototypen har designats efter en målgrupp bestående av personer med genomsnittlig datorvana, d.v.s. personer som är tillräckligt bekanta med datorer för att överhuvudtaget vara intresserade av en sådan här applikation. 2.3 Uppgiftsanalys Applikationen är till för att ta reda på mer om sin och andras släkter och skall stödja utforskning av en släkt i flera generationer bakåt och framåt samt sökning av individer i släktträdet. Genom att med musen klicka sig genom gränssnittet ska användaren få reda på mer om individerna och vilka relationer de har till varandra. Systemet skall kunna läsa in olika släktinformation på samma format och sedan visualisera denna. Visualiseringen skall ske i form av en klassisk trädstruktur - detta är den representation av strukturer som folk är mest vana vid. En översikt skall finnas med vid användandet av programmet som visar var i släktträdet man befinner sig. Den ska indikera relationer och information relativt person X snarare än ge en fullständig grafisk vy över individernas relationer till varandra. Vidare skall en del funktioner anknutna till översikten implementeras (se 4.2). 2.4 Första prototypen Utifrån de tidiga designförslagen (se ) och vår uppgiftsanalys (se 2.3) gjorde vi en allra första prototyp (figur 6) där översikten hamnade till höger och detaljvyn till vänster. Längst ned hamnade tidslinjen (se 2.1.5) och högst upp delar av den då påtänkta funktionaliteten. Tanken var då att navigeringen skulle ske utifrån detaljvyn och översikten var enbart till för att se var man befann sig i släktinformationen. I detaljvyn ser man bara syskon till den person som är i fokus ( roten som är rödmarkerad) och för att se t.ex. sina mostrar och morbröder får man byta fokus till sin mor genom att klicka på henne. Grenarna som inte slutar på någon nod är avsedda att indikera att mer information finns tillgänglig i databasen och för att se den får man klicka sig vidare. Alltså är tanken att man ska kunna se att mor- och farföräldrarna även de har föräldrar medan barn 1 och barn 2 inte har några egna barn. Syskon placeras i förhållande till roten efter ålder. Äldre syskon ritas ut till vänster om roten och yngre till höger. Man ska även kunna se åldersskillnaden i översikten enligt den principen. I översikten ritas personerna ut som små boxar längs en x- och en y-axel. Y-axeln visar vilken generation man befinner sig i och x-axeln visar antalet personer i varje generation samtidigt som de sorteras från äldst till yngst. Detta betyder att ålder inte tas hänsyn till annat än var roten befinner sig i förhållande till sin generation. Generation noll har vi definierat som den äldsta generationen vilket egentligen inte blir konsekvent med en y-axel eftersom den börjar i origo (noll) och ökar i värde ju längre upp på axeln man kommer. Men vi tror att det är så vanligt att definiera den äldsta genera-

8 tionen som noll (jmfr. ursprung, begynnelse) och att den generationen oftast hamnar längst upp i ett släktträd så att vi bortsåg från denna inkonsekvens. Figur 6 3. Jämförelse med andra metoder Innan vi beslutade definitivt om vilken design vi skulle välja läste vi igenom de relaterade artiklarna på kurshemsidan. Där fanns mycket intressant och många idéer som liknade våra egna även om de programmeringstekniskt sett var mycket mer komplicerade. 3.1 Zooming Många metoder verkar bygga på en gränssnitt som går att zooma in och ut i. Eftersom vi själva hade ett designförslag som byggde på zooming (se 2.1.4) tyckte vi att dessa metoder verkade mycket intressanta.

9 Flip zooming [5] är en metod som tillåter användaren att se många grenar i en hierarki på samma gång och samtidigt välja en gren som visas i detalj. Metoden ger alltså både översikt och detaljvy. De olika grenarna illustreras som små brickor (tiles). Den bricka som väljs placeras i mitten, zoomas in och ger då möjlighet till detaljstudier. Hierarkiskt lagrad information kan visas på ett överskådligt sätt, men det påminner inte mycket om en trädstruktur. Att använda metoden för att illustrera släktdata kan troligen förvirra användaren och det krävs förmodligen en viss inlärningsperiod för att förstå hur en släkt hänger samman. Dock kan man säga att vi tagit fasta på en del av tankarna bakom flip zooming utan att påstå att vi använt oss av metoden. Fisheye views [6] ger tillgång till både översikt och detaljvy på samma gång. Dessutom fås en mer specialiserad detaljvy. Fisheye views förekommer naturligt i samhället: man vet t.ex. mycket om gatunamnen i sin närmaste omgivning, medan man längre bort endast känner till huvudlederna. Metoden kan säkert lämpa sig för att zooma in släktträd, men det krävs en del arbete för att avgöra exakt hur det skall göras. Vad skall visas i inzoomningen och hur skall släktinformationen graderas? (Är det t.ex. mer intressant att visa syskon än mor- och farföräldrar? etc.) Vi använder ju en kraftigt förenklad variant i det fjärde designförslaget (se 2.1.4), men för att skapa en riktig fisheye view behövs nog fullfjädrade programmeringskunskaper. Pad++ [2] är ett zoomande grafiskt gränssnitt som gör det lättare att hitta specifik information i stora datamängder. Gränssnittet verkar väldigt enkelt att använda men det kräver att man har en datormus med tre knappar, alla med olika funktioner. Implementeringen förefaller dessutom inte vara lika enkel. Vårt gränssnitt har som mål att istället göra det lättare att hitta relativ information i stora datamängder. I denna artikel hittade vi även vårt mål definierat (även om vi inte uppnådde målet på samma sätt som i artikeln): One challenge in navigating through any large dataspace is maintaining a sense of reltionship between what you are looking at and where it is with respect to the rest of the data (i.e. balancing local detail and global context). [2] 3.2 På liten yta Treemaps [4] är en metod för att visa information som normalt illusteras med träddiagram på ett sätt som kräver mindre utrymme (ett vanligt träddiagram utnyttjar utrymmet väldigt ineffektivt). Treemaps är mycket användbara när den viktigaste informationen som skall visas för varje objekt är dess storlek. Detta lämpar sig bra för att illustrera t.ex. filsystem. Gränssnitt som bygger på TileBars [3] gör det möjligt för användaren att ta beslut om vilka delar av informationen han/hon vill utforska närmare, endast genom ett ögonkast: The goal is to simultaneously and compactly indicate (i) the relative length of the document, (ii) the frequency of the term sets in the document, and (iii) the distribution of the terms sets with respect to the document and to one another [3]

10 När det gäller Treemaps och TileBars så har vi även här använt oss mycket av de bakomliggande idéerna (till vår översikt) utan att direkt använda hela konceptet (inte så konstigt eftersom t.ex. TileBars är utvecklat för att strukturera filer). 3.3 Andra metoder Andra metoder som vi inspirerades till att använda var t.ex. Cone Tree [3] som är en visualiseringsmetod i 3D. Men vi insåg dock direkt att vi vare sig skulle klara av eller hinna implementera ett sådant gränssnitt vilket vi tyckte var väldigt synd eftersom det hade kunnat utvecklas och bli i princip hur bra som helst. En annan intressant metod är Butterfly [3] som visserligen inte kändes speciellt applicerbar på vår uppgift utan lämpar sig bättre för applikationer där relationerna i informationen inte är lika komplicerade som i ett släktträd. Det som fångade vårt intresse för metoden var det faktum att när man klickar på vissa objekt så skapas nya fjärilar i nya fönster. Problemet med nya fönster är bara att det finns ett viktigt samband mellan alla fönster som dyker upp men att detta samband inte visas [2]. Därför valde vi att inte arbeta med flera fönster. 4. Vår applikation Vår slutgiltiga applikation blev till slut en variant på vår första prototyp och kan ses i figur 7. Översikten hamnade istället ovanför detaljvyn eftersom vi ansåg att vi untyttjade ytan bättre på det viset. Till följd av det roterades detaljträdet 90 grader moturs vilket betyder att trädet byggs i sidled istället. Fler förändringar i detaljvy respektive översikt finns under 4.1 respektive 4.2. Tidslinjen längst ned tog bort helt och hållet då vi inte längre ansåg den vara nödvändig. Vi använder oss av färger för att göra distinktioner [7] i översikten och samma färger används i detaljvyn men vilka färger som används är inte av stor vikt här. I nuläget är det de färger som kan implementeras i Java som används men om vi hade haft ett val hade vi inte valt så bjärta färger eftersom man som användare inte riktigt vet vilken färg man ska fokusera på. Att ta hänsyn till färgblinda (vilket inte görs i nuläget) blir lätt eftersom färgen inte ensam bär navigationen, det är bara att välja färger med olika intensitet så att de i svartvitt får olika gråa nyanser. Det är distinktionen som är det viktiga. Översikten skulle ha fått funktionalitet om vi hunnit implementera detta (se 4.2)

11 Figur 7. I översikten är Visa föräldrar och VIsa barn valda 4.1 Detaljvy För att spara utrymme tog vi bort strecken mellan noderna (jmfr figur 6) men detta påverkar inte perceptionen då vi använder principen om närhet istället. På grund av programmeringstekniska själ placeras rotpersonen (rödmarkerad) inte centrerad som tanken egentligen är. En annan förändring från den första prototypen är att vi inte längre visar rotpersonens syskon, detta mest för att trädet ska få plats utan att användaren ska behöva scrolla. Vill man se rotpersonens syskon får man helt enkelt klicka sig upp en nivå, då visas alla barn till den nya rotpersonen. För att markera att det finns mer information än den som visas i detaljvyn sätts ett plus i den ruta vilken ytterligare information finns kopplad till istället för streck utan noder som i första prototypen. Nytt är också knapparna Tillbaka och Framåt som hjälper användaren att hålla reda på vilken gren man senast utforskade i släktträdet (funktionaliteten dock inte implementerad).

12 4.2 Översikt Den första idén till vår översikt föddes när vi konstaterat att vi inte kunde bygga upp den som ett traditionellt träd såvida vi inte ville skära i informationen (se 2.1.6). Figur 8 visar principen för översikten. Man kan tänka sig ett traditionellt släktträd där man först tar bort alla streck och alla tomma ytor mellan noderna. Sedan förskjuter man hela trädet till vänster och vips så har man en översikt som kan visa det mesta förutom att man inte direkt kan se vem som är barn till vem. Detta är dock inte omöjligt, användaren behöver bara aktivera visa föräldrar -funktionen (se figur 9). Figur 8 Man kan enkelt se hur stor släkt man har och man kan jämföra olika personer i släkten genom att t.ex. aktivera visa kusiner -funktionen för några olika rotpersoner. Varje generation är dessutom sorterad från äldst till yngst vilket blir logiskt då person nummer ett (se figur 9) i varje generation borde vara den som är född först i generationen. Exempel på frågor om sin släkt man enkelt kan få svar på är: Hur många personer är jag släkt med? Har en viss person fler eller färre kusiner än vad jag har? Vem är äldst respektive yngst i min generation? Hur många avlidna finns det i min släkt? Listan kan göras hur lång som helst genom att passande funktioner implementeras.

13 Figur 9 Översiktsfönstret som visas i den slutgiltiga prototypen (figur 7) är i nuläget bara som en bild och innehåller ingen funktionalitet. Önskvärt vore att översiktsbilden kunde fungera som en del av navigationen genom att när man klickar på en ruta (person) i översiktsbilden skall detaljträdet för vald person visas i detaljfönstret. Tanken är att när man håller musen över en person i översikten ska personens namn visas och på så sätt blir det enkelt att navigera vidare. Färgerna i översikten ska vara desamma som i detaljvyn (se 4) för att enkelt kunna relatera dessa till varandra. Det är meningen att översiktens utseende ska bero på den för tillfället valda rotpersonen och inte visa all information i databasen. Detta innebär att både moderns och faderns släkt kommer att finnas med i översikten samt alla ingifta parter. Översikten kommer således se exakt likadan ut för rotpersonens syskon och föräldrar men inte för kusiner. Med kusiner har man ju bara halva släkten gemensam. 5. Implementation Vi valde att implementera prototypen i Java och detta av två anledningar: dels fick vi tillgång till redan utvecklad Javakod för att läsa in databasen, och dels så kunde vi i Java utveckla prototypen som en Applet för att senare underlätta upplägget i gruppens portfolios. Vi utgick från den första prototypen (figur 6) när vi påbörjade kodningen, men fick revidera idéerna lite under arbetets gång. Den största förändringen som gjordes var att

14 trädstrukturen i detaljfönstret vreds 90 grader motsols för att bättre kunna utnyttja fönstrets storlek. Under programmeringens gång införde vi även användningen av färger i detalj- och översiktsvyn för att visualisera de olika nivåerna i generationshierarkin. 6. Hur vi löste problemet med flera hundra noder Problemet med att applikationen ska stödja släktinformation som innehåller flera hundra personer har vi haft i åtanke under hela utvecklingsprocessen vilket gjorde att det i slutändan inte blev något större problem. Vi upptäckte vid vår allra första pixling (figur 10) hur stort ett översiktsträd skulle bli redan för fyra generationer, och då visar det ändå bara föräldrar och barn i rakt nedstigande led. Men översikten ville vi fortfarande ha med och alltså fick vi tänka över syftet med den för att kunna förändra utseendet. Figur 10. Översikten överst och detaljvyn nedanför. Eftersom vår slutgiltiga protoyp och framför allt översikten i den är framtagna i huvudsak för att klara av större släkter så blir det ingen förändring i applikationen, den fungerar på samma sätt även för stora släkter.

15 7. Önskvärd funktionalitet Diverse programmeringsstrul och tidsbristen gjorde även att vissa delar i prototypen inte hann implementeras som önskat och de delar som framför allt vore önskvärt att arbeta på i en eventuell fortsättning är följande: 7.1 Detaljvyn I detaljfönstret skall äkta hälft(er) visas för vald person, dess barn samt även för barnbarnen. Barnbarns-delen är inte implementerad i den nuvarande prototypen. Detaljfönstret skall gå att scrolla för att möjliggöra visning av fler generationsnivåer. I nuvarande prototyp visas bara två generation uppåt (föräldrar och mor- farföräldrar) och två generationer nedåt (barn och barnbarn) från vald person. 7.2 Översikt Översiktsfönstret som visas i prototypen (figur 7) är i nuläget bara som en bild och innehåller ingen funktionalitet. Önskvärt vore att översiktsbilden kunde fungera som en del av navigationen genom att när man klickar på en ruta (person) i översiktsbilden skall detaljträdet för vald person visas i detaljfönstret. Andra funktioner man skulle kunna tänka sig i översikten är: Visa ålder Visa avlidna Visa personer födda fr.o.m. xxxx till xxxx En räkne-funktion som skulle kunna användas tillsammans med de andra funktionerna så man slipper räkna själv. 7.3 Faktaruta I ett informationsfönster skall detaljinformation om vald person visas. Exempelvis namn, födelsedata, intressen samt annan information som lagrats i databasen. 7.4 Sökfönstret I sökfönstret skall det finnas funktionalitet för fritextsökning (namn, årtal, osv.) och sökning från en lista med alla personer i databasen.

16 8. Sammanfattning Vi upplevde att implementeringsdelen av projektet begränsade oss i designarbetet. Om vi hade haft mer programmeringserfarenhet i gruppen hade vi troligtvis valt att satsa på en mer avancerad och annorlunda visuell lösning. Tänkbara alternativ i detta fall hade varit 3D-grafik (t.ex. Cone Tree ) eller en fisheye-lösning. Fastän vi gjorde vårt bästa med att försöka frångå traditionell trädstruktur så var det ändå där vi till slut hamnade. Något vi upptäckte alldeles för sent var att i detaljfönstret visas generationer från vänster till höger medan översikten visar generationerna från topp till botten. Detta beror på att i den första prototypen ritades trädet i detaljfönstret ut uppifrån och ned. Vi valde att behålla översikten som det var trots att detaljträdet roterades i tron att det var lättare att förstå. Kanske borde vi istället hållit på konsekvensen och roterat även översikten? Till sist kan man konstatera att gruppens bristande erfarenheter av programmering och utveckling med Java gjorde att vi fick tidsbrist mot slutet av projektet. För att få fram en mer fungerande prototyp borde vi ha lagt ner mer tid och resurser på programmering och implementering.

17 9. Referenser [1] Bier, E., Stone, M., Pier, K., Buxton, W., & derose, T. (1993) Toolglass and Magic Lenses: The See-Through Interface, Proccedings of SIGGRAPH 93, Computer Graphics Annual Conference Series, ACM, 1993, pp [2] Bederson, B.B., & Hollan, D. (1994). Pad++: A Zooming Graphical Interface for Exploring Alternate Interface Physics, ACM UIST 94, pp [3] Rao, R., Pedersen, J.O., Hearst, M.A., Mackinlay, J.D., Card, S.K., Masinter, L., Halvorsen, P-K., & Robertson, G.C. (1995) Rich interaction in the digital library. Communications of the ACM, 38(4): [4] van Wijk, J.J., & van de Wetering, H. (1999) Cushion Treemaps: Visualization of Hierarchical Information, Proceeding 1999 IEEE Symposium on Information Visualization (InfoVis 99), October 25-26, 1999, IEEE Computer Society, pp [5] Björk, S. Hierarchical Flip Zooming: Enabling Parallel Exploration of Hierarchical Visualizations. Proceedings of Advanced Visual Interfaces (AVI), [6] Furnas, G.W. (1986) Generalized fisheye views. Human Factors in Computing Systems CHI 86 Conference Proceedings, Boston, pp [7] Tufte, E. R. Envisioning Information: chapter 4 - small multiples. Graphics Press, UK, 1990