Region Skånes bildalbum

Transkript

1 Kungliga Tekniska Högskolan Numerisk analys och datalogi Kurs: 2D1622 Människa Datorinteraktion Kursansvarig: Ann Lantz Handledare: Anders Hedman Region Skånes bildalbum Digital bilddatabas, bildarkiv eller bildalbum? Av: Marcus Olsson - marcus.olsson@skane.se

2 Sammanfattning Denna rapport är en del i fortsättningskursen Människa Datorinteraktion (2D1622), som gavs på Kungliga Tekniska Högskolan under hösten Den är även en del av ett verkligt projekt på Region Skåne i Kristianstad, där författaren jobbar. Rapporten beskriver och utvärderar Region Skånes befintliga bildhanterings system, och kartlägger utvecklingen av ett nytt webbaserat bildhanteringssystem. Fokus för arbetet ligger på användarcentrerad användargränssnittsdesign, och problem inom organisationen relaterade till bildhantering diskuteras. Framtagning och testning av en första prototyp redovisas, varpå utveckling av en andra prototyp baserad på de användartester som gjorts av den första redovisas.

3 Innehållsförteckning Sammanfattning...2 Projektbeskrivning...4 Introduktion...4 Befintligt system och arbetsgång...5 Fotoarkivet i Kristianstad...5 Papperskopior lagrade lokalt hos avdelningarna...5 Inköpta bilder i CD-arkiv...5 Digitala beställda bilder från fotofirmor...5 Målgrupp...5 Användartest 1 (befintligt system)...6 Metod, utformning och utförande...6 Val av referenspersoner...6 Intervjuer...6 Resultat...8 Kommentarer...9 Kravspecifikation...9 Prototyp I digitalt bildarkiv...10 Designval...10 Tillfällig mapp...11 Rättighetssystem...12 Uppladdningsfunktion i två fönster...12 Editerings funktion...13 Administratör funktion...13 Användartest Metod...13 Material, utformning och utförande...13 Resultat...14 Kommentarer...15 Prototyp II - bildalbum...15 Namnbyte...16 Sammanslagning av uppladdnings- och visningsdelen...16 Förenklat uppladdningsgränssnitt:...16 Hjälpfunktion...16 Logg över vem som har laddat ner bilden senast...17 Snabblänk till bild...17 Mailfunktion om tillfälliga bilder...17 Sökfunktionen fick Alla kategorier x3 småbilder:...17 Färgkodning...17 Slutsats...18 Källförteckning...19 Appendix A Layout EPiServer...20 Appendix B Flödesdiagram, prototyp Appendix C - Flödesdiagram Prototyp Appendix C - Flödesdiagram Prototyp

4 Projektbeskrivning Introduktion Region Skåne (f.d. Skåne Läns Landsting) är en organisation med anställda runt om i hela Skåne, uppdelat på 10 sjukhus, och flertalet mindre vårdcentraler. Organisationen har ett stort behov av att hålla sig offentliga, och därmed också stora krav på att distribuera information, och göra informationen lätt tillgänglig för alla. I informationsflödet spelar bilden som informationsbärare en viktig roll. Därför krävs det inom Region Skåne ett centraliserat system för att hantera, byta och publicera bilder. Det arbete som ligger bakom denna rapport fokuserar på att utvärdera och utveckla ett befintliga system för hantering av elektroniska bilder, pappersfoton och pressbilder inom Region Skåne. Dagens befintliga system är utspritt över flera olika lagringsmedia, t.ex. fotoarkiv, enstaka pappersfoton, cd-skivor, lokala hårddiskar och nätverksenheter. Bildkällorna är också både geografiskt och organisatoriskt utspridda på olika avdelningar, och bytet av gemensamma bilder är i det närmaste noll. Då flera avdelningar behöver få tillgång till liknande filer behövs någon form av gemensam samlingsplats för bilder inom Regionen. Detta arbete har därför fokuserat på hur ett webbaserat gränssnitt kan ge möjligheter att ladda upp, hantera, söka och ordna bilder inom Regionen, och kanske även förändra arbetsgången.

5 Befintligt system och arbetsgång De befintliga bildkällorna är: Fotoarkivet i Kristianstad Det befintliga fotoarkivet är ett pappersbildarkiv som hanteras av en fotofirma i Kristianstad. Det var tänkt att fungera som ett gemensamt lagringsutrymme för Region Skånes foton, men visade sig vara både kostsamt, och i praktiken helt oanvändbart, då tekniken ej medger förhandsvisning av bilderna, utan beställning av foton måste ske över telefon. Papperskopior lagrade lokalt hos avdelningarna Många avdelningar väljer att anställa en fotograf för att skaffa bilder. Detta blir självklart kostsamt, och användandet av bilderna är begränsat jämfört med om hela organisationen kunde ha använt sig av bilderna. Inköpta bilder i CD-arkiv Flera CD-skivor med varierande motiv finns inköpta till Info-avdelningen, men eftersom skivorna ej kan kopieras och distribueras används dessa endast av den centrala informationsavdelningen, och kommer ej utanförliggande organisationer till gagn. Digitala beställda bilder från fotofirmor Vid behov av speciella bilder till exempelvis en trycksak beställs digitala bilder från bildbyråer. Dessa lagras lokalt hos beställaren, och används endast en gång. Målgrupp Produkten kommer att användas av alla de personer som kommer i kontakt med publicering av bilder. Det är framförallt de tre huvudgrupperna informatörer, grafiker och webbpublicister. Dessa tjänster finns på olika avdelningar i Region Skåne, utspridda geografiskt över hela Skåne. Eventuellt ska även externa journalister kunna tillgå bilder från bilddatabasen. Användarna har olika arbetsuppgifter, och kommer således att använda databasen på olika sätt. Gemensamt för alla användare är att de jobbar mycket i Region Skånes webbaserade webbpubliceringsverktyg EPiServer (Se Appendix A), samt att deras arbetsuppgifter flyter in i varandra. Informatörer: Har ett övergripande ansvar för vilken information som publiceras, och även vilka bilder som publiceras. De har även hand om PR, och kontakter med tidningar. Informatören behöver ha en övergripande vetskap om vilka bilder som finns att tillgå inom organisationen, och kunna leverera dem vid tillfälle. Webbpublicister: Ansvarar för de texter och bilder som publiceras på webben. Både designmässigt och innehållsmässigt ansvariga. Webbpublicisterna är en stor användargrupp med mycket skiftande kompetens. Dessa anses komma att använda produkten för att söka bilder för publicering på lokala och externa webbsidor. Grafiker:

6 Ansvarar för de trycksaker som Region Skåne publicerar, och för layout, bildsättning, kommunikationer med tryckerier, mm. Samtliga användare i målgruppen är bekanta med Internet, filhanteraren, uppladdning av filer över webben, och av EPiServer. Användartest 1 (befintligt system) För att kunna få en förståelse av problemrummet [36, Preece] och hur verktyget ska kunna underlätta att användas gjordes undersökningar av hur arbetet med bilder går till idag. Metod, utformning och utförande För att på ett så tidigt stadium som möjligt kunna sätta mig in i behoven, arbetsgången, organisatoriska frågor samt tankesätt valde jag att göra fältstudier [ , Preece]. Detta för att fältstudier kan göras flexibelt, och kan ge en bredare förståelse för själva problemet, och var tidsbesparingar kan göras. Särskilt lämpligt är detta att använda för att kartlägga de olika målgruppernas inbördes förhållande, som målgrupperna ibland kanske inte själva är medvetna om. Jag valde att göra intervjuer, samt att studera en referensgrupp på sina arbetsplatser. Intervjuerna fördes över telefon, pga. logistiska bekymmer. Val av referenspersoner Referenspersonerna valdes ut som en representativ del av målgruppen. Två grafiker som jobbar med trycksaker, två webbpublicister som jobbar med att publicera text och grafik på webben med content managementsystemet EPiServer, och en infomaster som jobbar med information och övergripande struktur. Samtliga referenspersoner har ungefär lika mycket datorvana. Webbpublicisterna sitter på Centralsjukhuset i Kristianstad, och de andra tre sitter i en annan byggnad, på Regionkontoret. Intervjuer Genom resonemang med min beställare på infoavdelningen, samt genom att själv fundera kring vad som var av intresse för vidare utveckling kom jag fram till ett antal frågor. Dels generella frågor som skulle få användaren att resonera kring sin situation, och locka fram frågeställningar och problem som användaren kanske själv inte var medveten om, och dels specifika sakfrågor som var av direkt betydelse för produktens funktionalitet. Specifika frågor: Vilka källor till bilder har du? Vilken hänsyn tar ni till PUL? Hur hanterar ni licensfrågor? Har ni något system för märkning av vilka personer som är med på bilderna? Vilka webbyråer använder du dig av? Finns det något befintligt numreringssystem, eller indexeringssystem? Finns det något befintligt kategoriseringssystem Generella: Hur gör ni i praktiken när ni designar en sida för tryck/för webb?

7 Vem gör vad? Hur arbetar ni tillsammans? Vilka arbetsuppgifter är gemensamma? Hur väljer ni bilderna? Hur sparar du ner bilder lokalt? Hur väljer du bild? Vilken kontakt har ni mellan enheterna Hur gör ni för att beställa bilder från det befintliga fotoarkivet hos extern leverantör? Frågorna varvades, och ingen speciell ordning följdes, utan användaren lämnades mycket fritt utrymme för att berätta om sitt arbete med bilder.

8 Resultat Intervjuerna gav god insikt i de arbetsuppgifter som målgruppen har, och gav en ungefärlig bild av vilka funktioner som behövde implementeras. Förståelsen av hur stor tidsbesparingen kommer att vara gav också motivation till att fortsätta utveckla produkten. Under intervjuerna märktes att de generella frågorna gav mycket användbar information som ej framkom av de direkta sakfrågorna. De direkta sakfrågorna gav svar på konkreta önskemål och krav från användaren, men de generella frågorna gav mer frågeställningar och beskrivning av verkliga problemsituationer som användaren ställs inför varje dag. Exempelvis upplevde grafikerna det som ett stort problem att få rätt bildstorlek och format för tryck från andra avdelningar. När jag ska göra en trycksak för en speciell avdelning så måste jag få material från dem. Då ringer jag runt och snokar upp någon som har hand om bilderna, och ber dem skicka originalbilderna. Dom skickar en kopia i låg upplösning, och jag måste ringa igen, och förklara att jag behöver originalbilden. Så kan det gå fram och tillbaka flera, flera gånger innan jag får tag i rätt bild Flera användare kände också ett problem i att veta vad som tidigare hade använts, och i vilken publikation. Såhär sa en av webbpublicisterna: Om jag har fått en bild från en annan avdelning så måste jag alltid höra med dem var dom har använt den, och sen får man ju se till att inte använda den för många gånger på olika webbsidor Några andra viktiga synpunkter som kom fram under intervjun var: Man ville ha möjlighet att kunna titta på, och ladda ner en lågupplöst version av bilden, en s.k. skissbild Man använder sig av ett befintligt digitalt bildarkiv skapat av bildbyrån Johner AB. Man vill kunna söka efter bilder på ämnesord, t.ex. läkare Man vill kunna kategorisera bilderna efter bl.a. verksamhetsområden och geografiska områden Det är problem med kommunikationen mellan beställare av bilder, och av den som har bilderna. Man vill veta vem som äger bilden, eller vem som publicerat bilden. Det är problem med olika bildformat Grafikerna har problem att få tillräckligt högupplösta originalbilder från andra avdelningar. Man vill kunna lägga till egna kategorier efter hand. Produkten måste vara levande, dvs. det ska vara lätt att lägga in bilder. Man sparar ner alla produktioner med bilder och allt i samma folder, och flyttar därefter till en arkivfolder med hjälp av utforskaren.

9 Genom att besöka användarna framkom att flera av grafikerna i målgruppen faktiskt sitter på Macintosh-datorer, som ej är tillåtna att kopplas in till skå-net (Region Skånes nätverk), utan tvingas koppla upp sig med ett speciellt ADSL-modem. Detta innebär att alla grafiker saknar åtkomst till det interna nätverket, med de nätverksenheter som tjänstgör som organisationens gemensamma lagringsutrymmen. Anledningen till denna udda konfigurering sades vara ett centralt beslut från ITavdelningens ledning, där man bestämt att Macintosh ej skulle tillåtas att kopplas in på skå-net. Vissa av Mac-användarna använder sig också av PC-datorer, för att publicera texter. Därför använder man sig ofta av e-post för att skicka bilder mellan användare, och även mellan Mac och Pc. Mac-problemet ställer till med stora problem för det fortsatta arbetet, eftersom arbetet nu inte kan basera sig på en enhetlig miljö med gemensamma lagringsutrymmen (se nedan, om planer för utvidgning av tillfällig mapp ). Även tekniska säkerhetsproblem uppstår, det ej längre är möjligt att skilja externa och interna användare genom att se vilket nätverk de kommer ifrån. Efter samtal med min närmsta chef, Susan Principe gavs dock besked om att ingen hänsyn skall tas för de som använder sig av Macintosh, eftersom det finns ett centralt ledningsbeslut om att den gemensamma miljön Windows skall användas. Regionen skall ej lägga tid på utveckling och anpassning för någon annan plattform. Detta beslut står tyvärr i direkt konflikt med användarcentrerad produktutveckling. Jag har försökt ha Mac-användare i åtanke i mitt fortsatta arbete, men utan att lägga ner extra tid, eller kompromissa gällande funktion för Windows-användare. Mac-problemet är ett viktigt problem, som ej framkom under intervjuerna, men som istället kom fram vid besök hos användarna. Kommentarer Under intervjuerna märkte jag att det var svårt att hålla sig till övergripande designfrågor, utan att spåra in på detaljfrågor som var pilarna för navigeringen skall sitta, eller hur många bilder som skall visas på varje sida. Detta kan undvikas genom att: Öppna intervjun på rätt sätt, dvs. inte förklara att intervjun syftar till att skapa en digital bilddatabas med många funktioner, utan förklara att man gör en förstudie. Ställa mer generella frågor som får användaren att berätta om sitt arbete, och problemen i sitt arbete. Inte prata för mycket om själva produkten Om samtalet börjar gå in för mycket på specifika sakfrågor så kan man försöka lämna det öppet, och hänvisa till senare designfrågor Om användaren har speciella önskemål kan man fråga varför han vill ha det så, istället för att fråga precis hur han vill ha det. Om diskussioner förs kring detaljerade lösningar till utseende och funktion för tidigt i designprocessen kan det bli svårt att göra övergripande förändringar. Både designer och användare kan känna sig låsta till en viss funktionalitet och glömma bort att fokusera på problemet. Kravspecifikation Efter intervjuerna och samtalen med beställare formulerade jag en kravspecifikation efter vilka funktioner som skulle prioriteras och uppfyllas.

10 Vi kom överens om att produkten skall fungera som en central källa för bildmaterial inom Region Skåne. Bilderna skall kunna nås utanför Region Skånes nätverk, och det måste finnas någon form av rättighetssystem för vem som är ansvarig för bilderna, och har rätt att ändra informationen om dem. Dessutom skall man kunna: Ladda upp bilder Indexera, och skriva till metadata Kategorisera Sortera Utföra textbaserad sökning ur indexet Förhandsgranska i lämplig storlek Det finns även vissa önskemål om en framtida version med stöd för att knyta bilddatabasen till det befintliga content managementsystem som idag används för webbpublicering. Detta kommer att has i åtanke, och kanske kommer gränssnittet att efterlikna det befintliga systemet, för att användaren ska känna igen sig. Prototyp I digitalt bildarkiv Sökmotorer likväl som bilddatabaser har utvecklats till lite av en de-facto standard som många användare börjar få en intuitiv känsla för. Det har jag försökt ta tillvara på när jag skapade gränssnittet för visning av bilder genom att studera flera olika befintliga bilddatabaser, däribland den som beställaren angett som referens. Jag har också tittat på de funktioner jag själv tidigare implementerat i en egenutvecklad, privat webbaserad bilddatabas. Detta gav mig inspiration till de grundläggande tankarna kring att kunna visa 3x3 småbilder, som man kan klicka på, som tar en till en lite större bild (skissbild). Också kategoriseringsfunktionen och sökfunktioner med beskrivningsfält är inspirerade av befintliga system. Dock finns inga givna regler gällande funktioner för uppladdning och editering, där jag istället försökt inspireras av EPiServers editeringsfunktioner. Prototyp 1 är gjord som ett statiskt gränssnitt i HTML, där alla länkar fungerar, och tar en vidare till simulerade statiska sidor. På så vis kan man följa applikationens flödet obehindrat. Jag valde att prioritera flödes- och funktionsfrågor framför layoutfrågor, och eftersom användaren är väl familjär av EPiServers layout så valde jag att hämta färgschema och tabell-layout från detta verktyg. Designval Flödet i prototyp 1 syns i Appendix B. Det övergripande flödet bygger på att uppladdningsverktyget är skiljt från verktyget som används för att titta på bilder. Detta val grundar sig på att användaren som ämnar lägga till bilder ej antas titta på bilder samtidigt som han laddar upp bilder. Ju mindre knappar och möjligheter, desto enklare att göra uppgiften är den princip som användes. Detta kom dock att ändras. Den som vill titta på bilder tas först till inloggnings-sidan, därifrån vidare till en sida som visar senast inlagda bilder, och härifrån kan användaren söka på valfria bilder, och hitta rätt bild genom att bläddra bland mindre bilder, och därifrån editera bilder, om han har rättigheter till det. Navigationslisten ligger i en ram till vänster, vilket känns igen från EPiServers layout.

11 Tillfällig mapp För att kunna hålla bilddatabasen levande och användbar krävs det att man har ett enkelt och effektivt verktyg för att lägga in bilder. Om det tar för lång tid, eller är för krångligt att lägga in bilder kommer ingen att göra det. Detta står i konflikt till att bildernas metainformation måste vara av hög kvalitet för att användaren ska kunna göra en precis sökning och få upp passande bilder. Eftersom det tar tid att kategorisera, och skriva in bra beskrivningar till en bild måste det finnas ett sätt att ladda upp bilder tillfälligt, för att kategorisera och indexera mer korrekt vid senare tillfälle. Därför skapades en funktion som kallas tillfällig mapp. Varje användare med rättigheter att ladda upp har en egen tillfällig mapp dit bilder som inte uppfyller bilddatabasens högt ställda krav på kategorisering och informationsinmatning kommer att laddas upp. Bilderna i användarnas tillfälliga mappar kommer ej att synas för andra användare, förrän användaren väljer att uppdatera informationen, och väljer att publicera informationen. På så sätt kan användare som sitter upptagna med en publikation innehållande en ny bild gå in och ladda upp bilden utan att namnge, eller kategorisera bilden. När arbetsdagen är slut, eller projektets deadline har nåtts kan användaren gå till sin tillfälliga mapp och kategorisera bilder så att de läggs in i bildalbumet och blir tillgängliga för andra användare. Figur 1a) Länk till tillfällig mapp Figur 1b) Tillfällig mapp expanderad Vid en vidareutveckling av produkten kan man även tänka sig att den tillfälliga mappen knyts till en nätverksenhet på det lokala nätverket, så att användaren endast behöver kopiera själva filen över till den tillfälliga mappen på nätverket utan att starta en webbläsare, och under natten söker bildalbumet igen efter nya bilder, och indexerar dessa, så att användaren nästa dag kan logga in i bildalbumet och fylla in nödvändig information om bilden, och publicera den. Det viktiga är att själva filen laddas in i systemet. Indexering och kategorisering kan göras vid lediga tillfällen. Olika namn på funktionen har testats. Metaforer som t.ex. karantän, privat fotoväska eller temp folder har testats och presenterats för användarna, med olika svar. Jag fastnade själv för tillfällig mapp, som är okomplicerat, men fyller en funktion genom att uttrycka att bilder inte egentligen bör finnas i detta läge längre än tillfälligt.

12 Rättighetssystem Efter att ha kartlagt de olika funktionernas inbördes relationer i jämförelse med befintliga rättighets system inom organisationen kom jag fram till att produkten bör ha fem nivåer för rättigheter: Administrera hela bildalbumet: En person på info-avdelningen, och en person på IT-avdelningen som har övergripande ansvar. Redigera samtliga bilder: bildansvariga på den centrala info-avdelningen och IT-avdelningen. Ladda upp och redigera egna bilder: Alla som kan tänkas komma i kontakt med inkommande bilder Titta på bilder och ladda ner original: Personer som kan tänkas komma att vilja publicera bilder för Region Skåne Titta på skissbilder: Personer utanför organisationen, som ej har tillåtelse att använda bilderna offentligt. Rättighetssystemet kommer att fortsätta utvärderas, och behovet kan komma att ändras efter hur produkten används. Därför kommer det att byggas flexibelt, så att man kan ändra och lägga till funktioner. Uppladdningsfunktion i två fönster En annan funktion för att göra det enklare och snabbare att lägga in flera bilder efter varandra är att uppladdningsfunktionen består av två lika fönster ovanför varandra. Detta för att vid uppladdning av stora originalfiler kommer användaren att tvingas vänta på att ladda upp nästa fil, och detta kan vara störande och underlättas genom att användaren ges möjlighet att fylla i information om nästa fil under tiden den första filen laddas upp till databasen. Senast inlagda bilder För att göra bildalbumet mer levande har jag valt att lägga en inspirationssida som den första sidan man kommer till efter att ha loggat in. Sidan innehåller en översikt över de senast inlagda bilderna, och skall ge folk inspiration. Ett alternativ till denna sida skulle kunna vara att man gör en sida som slumpar ut 9 bilder från databasen, för att göra den mer dynamisk.

13 Editerings funktion För att man lätt ska kunna ändra och lägga till information kring en bild har jag valt att integrera bildvisning med bildeditering. Därför kommer användare som har rättigheter att editera informationen få möjligheten att ändra information för den bilden när han tittar på den. En användare utan editeringsrättigheter kommer endast att se informationen Administratör funktion För att beställaren ska kunna sköta databasen själva så mycket som möjligt så har administratören rättigheter att lägga till kategorier, och radera fil efter id nummer. Att ta bort kategorier är inte möjligt, då det ger både informationsförluster och tekniska problem. Om en kategori behöver tas bort, eller editeras pga. strukturförändringar, krävs det en genomarbetad plan, som gås igenom med tekniskt ansvarig för databasen. Man bör ha full teknisk och organisatorisk förståelse för vad denna förändring innebär innan ändringen görs manuellt direkt i databasen. Någon slags bekräftelse och säkerhet skall komma att byggas in i filraderingsfunktionen i den färdiga versionen. Exempelvis att man får se bilden innan man väljer att radera den. Användartest 2 När den statiska prototyp 1 var färdig gjordes användartest 2. Många av kundens konkreta krav var uppfyllda, men det som framförallt skulle testas var funktionaliteten och användbarheten av de nya funktioner som var tänkta att lösa de generella problem som framkom under intervjuerna. Metod För att få en konkret och verklig utvärdering av användargränssnittet valde jag att använda mig av användbarhets testning. Efter resonemang med min handledare valde jag att använda mig av en korsning av att observera, och att testa användarna. Samma referenspersoner som i första testet användes. Jag valde att spela in testen med videokamera, för att: Kunna utvärdera efteråt, och gå tillbaka Kunna fånga användarnas diskussioner mellan varandra Observera hur användaren för markören, och om det uppstår förvirring, eller några fördröjningar. Ha verkligt material att hänvisa till om något av mina designval skulle bli ifrågasatt. Material, utformning och utförande Utrustningen för testet bestod av en videokamera med stativ och 3 st. 90 minuters band bärbar dator med extern mus, på vilken den statiska prototyp 1 finns lagrad i formen av ett webbgränssnitt papper och penna och tre grupper ( ) med de fem referenspersoner som deltagit i användartest 1.

14 Jag valde att göra testerna på referenspersonernas arbetsplatser, för att få testet så verkligt som möjligt. Referenspersonerna blev anvisade att två och två använda produkten på den bärbara datorn. Anledningen till att testes gjordes på den bärbara datorn istället för referenspersonernas egna datorer var att skärmen flimrar för mycket på referenspersonernas vanliga skärmar, och då skulle det vara svårt att genomföra en analys av användarens rörelser med pekaren. Under testet skulle ledning ges av testförrättaren, och uppgifter skulle lösas av referenspersonerna. Videokameran placerades snett bakom referenspersonerna riktad mot den bärbara datorns skärm. Videokamerans inbyggda mikrofon tog upp ljud under testet. Testet planerades vara intuitivt, och referenspersonerna skulle få utforska verktyget fritt, och tala högt om vad de tyckte och upplevde. Resultat Generellt sett fick jag mycket feedback av testet, men framförallt var det mycket lärorikt att göra testerna. Ordet arkiv gav under testet upphov till en stor debatt om i vilken mån produkten skulle vara levande, och om det skulle användas för att just arkivera, eller för att bläddra bland, varav det sistnämnda självklart är att föredra. Arkiv låter ju som att det är en person som skall ha ansvar för att lägga in bilder, och sortera dem för långtidslagring Inom Region Skåne finns även ett stort projekt som kallas arkivet, som syftar till att arkivera journaler, vilket kan ha föranlett denna reaktion. Det visade sig också att samtliga användare var mycket mer intresserade av att utforska visningsdelen av verktyget, än att testa på att ladda upp filer. Detta kan förklaras med att uppladdningsfunktionen inte fungerade, vilket gör det mindre intressant. Det kan också visa att den delen av verktyget kanske inte är så lockande. Detta är en viktig synpunkt, som påverkade flödes-designen till prototyp II.

15 Några andra synpunkter som kom fram under testet var: Flera referenspersoner ville veta hur sökningen fungerade, och om man kunde söka med ett ord i en viss kategori, och hur man gjorde för att söka i alla kategorier samtidigt, och om man kunde använda plustecken Man ville ha möjlighet att ta sig tillbaka, då främst till startsidan Man ville att skissbilden skulle ha 640x480 upplösning för att man ska kunna testa olika bilder i en publikation, utan att det tar för mycket plats Tillfällig mapp var en bra lösning, och uppskattades Dubbla fönster för uppladdning uppfattades som rörigt, särskilt om man inte hade maximerat fönstret som man testade i Intuitivt klickade många användare på skissbilden när de såg den, vilket ledde dem till nedladdning av originalbilden. Detta är inte önskvärt, utan borde snarare ta användaren tillbaka till föregående sida med t.ex. sökresultat. En av användarna ifrågasatte om bilder som inte var godkända enligt PUL överhuvudtaget skulle läggas in i bildalbumet Vissa användare använder alltid maximerade fönster, andra gör tvärtom Man behöver något sätt att kontrollera var bilden har använts tidigare, för att undvika att en bild används i två publikationer samtidigt, som står i kontrast till varandra. Kommentarer Praktiska bekymmer uppstod tidigt, och det var mycket att tänka på gällande utrustning. Under det första testet uppstod problem redan innan användarna hunnit börja använda verktyget. Vid inloggningen till prototyp 1 var passwordfältet utbytt mot ett textfält, vilket resulterade i att användarens lösenord skrevs ut i ren text på skärmen, som videofilmades. Detta kan ha påverkat testet negativt. Senare under första testet tog även batteriet i kameran slut, och en av användarna flyttade datorn lite så att skärmen syns lite dåligt i inspelningen. Ljudet blev ganska lågt inspelat, och bilden ganska mörk, men den fungerar som referensmateriel. Stativet medgav svårigheter att placera, då de flesta arbetsplatser är för små för 3 personer plus en kamera. Innan sista testet förflyttades datorn påslagen, och vid testets början var musen ur funktion, vilket resulterade i att referenspersonerna tvingades använda datorns inbyggda pekdon, vilket var obekvämt och försvårade testet mycket. Testerna blev inte heller så intuitiva och utforskande som jag hade hoppats, utan mycket mer styrda. Detta kanske kan förklaras med att referenspersonerna inte var riktigt bekväma i situationen med en främmande bärbar dator och videokamera. Hade testerna gjorts på referenspersonernas egna datorer hade tyvärr bara en av användarna känt sig bekväm framför datorn. Kanske vore det bästa att använda en stationär arbetsplats för testerna, som inte kändes lika privat, som i fallet med min bärbara dator som kan ge ett intryck av att vara för personlig för att utgöra en neutral testmiljö. Prototyp II - bildalbum Grunden i prototyp I (bildarkivet) finns kvar i prototyp II (bildalbum), men flödet och layouten har förändrats efter hur användartest 2 gick. Mycket av funktionaliteten är dock densamma.

16 Namnbyte Efter de synpunkter som framkom kring digitalt bildarkiv så valde jag att byta namn på produkten till bildalbum, för att skapa en känsla av att det faktiskt är något man tittar i tillsammans, uppdaterar och håller efter kontinueligt. Något som känns mer levande än ett arkiv. Eftersom ordet digitalt inte ger något mervärde togs det också bort. (särskilt med tanke på att bilderna i arkivet kommer att vara inscannade från analoga bilder). Sammanslagning av uppladdnings- och visningsdelen Eftersom testet tydligt talade om att referenspersonerna inte var så intresserade av uppladdningsdelen av verktyget valdes istället att lägga in uppladdningsverktyget i samma fönster som visningsverktyget. På så sätt kan användaren lättare nå det, oftare bli påmind om det, och inte känna sig så främmande för gränssnittet. Tanken är att det ska kännas enkelt och naturligt att gå in och ladda upp bilder och man ska känna igen sig från visningsverktyget. Förenklat uppladdningsgränssnitt: Uppladdningsfunktionen är som standard enkelsidig, men funktionen för att få upp två uppladdningsrutor samtidigt finns som tillval. Detta för att inte förvirra användaren med dubbla ramar, och rullister. Hjälpfunktion I prototyp 2 finns en kontextbaserad hjälpfunktion speciellt tillgänglig på de ställen som användaren hade frågor kring, som tex. sökfunktionen, eller där användarna blev stilla under test 2, exempelvis kring uppladdningsverktyget. Hjälpfunktionen nås genom ett litet frågetecken i kanten av de fält som kan tänkas behöva en förklaring. Först utvecklades en dynamisk hjälpsida som endast visade hjälpinformation för den aktuella funktionen, men eftersom det kändes onödigt att begränsa sig, gjordes den om till en statisk html-sida, med ankarlänkar. Man tas till det aktiva kapitlet direkt från sidan, och kan sen titta vidare på andra hjälpavsnitt. Hjälp-funktionen kommer upp i ett popup fönster, och kan även nås från huvudmenyn. (se figur 2) Den är även tänkt att fungera som produktens manual. Figur 2: Hjälpfunktionen i pop-up fönster

17 Logg över vem som har laddat ner bilden senast För att få en bättre bild av vem som laddat ner bilden senast har en ny funktion lagts till, som loggar alla användare som laddar ner en högupplöst fil. Användarens namn, samt vilken avdelning användaren jobbar på visas längst ner på skissbildens sida. På så sätt kan man få en uppfattning av hur stort intresse det finns för bilden, samt eventuellt ta kontakt med personen som laddat ner den tidigare. "Övrigt"-fältet är också tänkt att fungera som ett sätt för användare att kommunicera om bilderna. Därför kommer "övrigt"-fältet alltid att vara redigeringsbart för de som har rättighet att ladda ner originalbilder. Snabblänk till bild För att underlätta kommunikationen mellan olika avdelningar, när man diskuterar vilka bilder som används finns en snabblänk till bilden, så att man direkt kan maila länken till sin kollega, och kollegan kan gå till URL en, logga in, och titta på bilden direkt, istället för att maila själva filen. Mailfunktion om tillfälliga bilder En funktion som ej ännu är implementerad är att användaren som har bilder i sin tillfälliga mapp skall få ett påminnels , t.ex. varje fredag som uppmanar honom att kategorisera de bilder som ligger i hans tillfälliga mapp. Sökfunktionen fick Alla kategorier Alla kategorier lades till i rullisten för befintliga kategorier. Detta gör det mer lättförståligt att söka i alla kategorier. 3x3 småbilder: Antalet bilder per sida i sökresultatet har minskats till 9, för att passa in i fönstret, och knappar för navigering har lagts till längst ned. (se figur 3a och b) Figur 3a och b: Sökresultat och navigationsknappar Färgkodning För att skilja på visningsläge och editeringsläge har färgkodning använts. Kodningen följer det schema som används av EPiServer, dvs. brunt i editeringsläge, och grönt i visningsläget. (se figur 4a och b)

18 Figur 4 a och b: Visningsläge och editeringsläge Slutsats Prototyp II är en god bit på vägen mot en användaranpassat verktyg för bildhantering inom Region Skåne. Hänsyn har tagits till hur verktyget skall användas, vilka användarna är, deras bakgrund och verktyget har gjort skalbart. Teknisk implementering förväntas ske i januari-februari. Inmatning av riktiga bilder börjar förhoppningsvis under våren, tillsammans med skarpa tester av funktionalitet och design, för att itereras vidare till skarp version. Ett stort arbete kvarstår även av integrering av verktyget i verksamheten, och kanske bör ledningen titta lite närmare på hur själva arbetsprocessen vid bildhantering går till. Förhoppningsvis kan detta verktyg hjälpa till vid kommunikation och utbyte mellan avdelningarna, och ge större variation i utbudet av bilder på både webb, och i trycksaker. Förhoppningsvis kan verktyget även spara pengar i form av licensavgifter och inhyrning av frilansande fotografer, och göra det mer ekonomiskt försvarbart att köpa in fler gemensamma bilder. Arbetet med integration av Macintosh och PC är en annan aspekt på arbetsflödet inom organisationen, som bör ses över. Detta är dock utanför denna rapports innehåll.

19 Källförteckning 1. Interaction Design Jennifer Preece, Yvonne Rogers, Helen Sharp 2. Bilddatabas från Johner bildbyrå AB.

20 Appendix A Layout EPiServer

21 Appendix B Flödesdiagram, prototyp 1 Databas default.asp Logga in CheckUserInfo GetCategoryInfo Main.asp Första sidan Länkar Sökfunktion upload.asp Lägg in bilder Fil att ladda upp Beskrivning Kategorier Licensfrågor PUL-uppgifter Övrigt Tillfällig mapp/publicera JavaScriptfunktion för att UploadFile Search Bekräftan All Bildinfo Tillfällig mapp/publicerad Senast inlagda bilder Search_result.asp Sökresultat 3x3 Småbilder Min tillfälliga mapp Småbilder /admin/ Admin Lägg till kategori Radera bild GetFileInfo DeleteFile AddCategory Show_image.asp Visa skissbild 640 x 480 Info, format, storlek Filnamn, ID Beskrivning Kategorier Licensfrågor PUL-uppgifter Övrigt Länk till Högupplöst bild Show_image.asp Visa skissbild 640 x 480 Info, format, storlek Filnamn, ID Beskrivning Kategorier Licensfrågor PUL-uppgifter Övrigt Bekräftan Högupplöst bild Zip-format UpdateFileInfo Bekräftan Tillfällig mapp/publicerad All Info

22 Appendix C - Flödesdiagram Prototyp 2 default.asp Logga in Databas CheckUserInfo GetCategoryInfo Main.asp Första sidan Länkar Sökfunktion Help.asp Hjälp Statisk HTML Logout.asp Logga ut Search Senast inlagda bilder Search_result.asp Sökresultat 3x3 Småbilder Show_image.asp Visa skissbild 640 x 480 Info, format, storlek Filnamn, ID Beskrivning Kategorier Licensfrågor PUL-uppgifter Övrigt Senast nedladdad av Länk till Högupplöst bild GetFileInfo Min tillfälliga mapp Småbilder Show_image.asp Visa skissbild 640 x 480 Info, format, storlek Filnamn, ID Beskrivning Kategorier Licensfrågor PUL-uppgifter Övrigt Senast nedladdad av upload.asp Lägg in bilder Fil att ladda upp Beskrivning Kategorier Licensfrågor PUL-uppgifter Övrigt Tillfällig mapp/publicera JavaScriptfunktion för att UploadFile Bekräftan All Bildinfo Tillfällig mapp/publicerad /admin/ Admin Lägg till kategori Radera bild DeleteFile AddCategory Bekräftan Visning av bild innan den tas bort Högupplöst bild Zip-format UpdateFileInfo Bekräftan Tillfällig mapp/publicerad All Info