Utredning om bildbank / Digital Asset Management

Här finner du ett utkast på en utredning jag skrivit åt Västra Götalandsregionen kring bildhantering i större skala, så kallad Digital Asset Management. Anledningen till att jag publicerar den här är för att vänligt folk tenderar till att ge hjälpsamma kommentarer men också för att vårt material eventuellt kan hjälpa någon annan organisation.

Har du åsikter eller feedback är du välkommen att höra av dig i valfri kanal.

Förbehåll

Denna utredning tar inte upp driftfrågor, produktstrategier eller andra IT-relaterade angelägenheter. Dessutom förutsätter denna utredning att det finns minst en heltidsanställd bild/mediaredaktör för att hålla ordning och bibehålla god struktur på innehållet.

Språkbruk

• Användare – de personer som lägger till material i systemet för eget bruk eller publik åtkomst, eller letar material att använda i sin kommunikation.
• Mottagare – de personer som är mottagare av publicerat material, exempelvis genom att besöka vgregion.se och exponeras för bild, video, ljud etc.

Tänkta läsare/respondenter/remissinstanser

• IT-strateger/arkitekter/drift.
• Representationer från nedan definierade användargrupper.
• Förvaltningen för dokumenthantering.
• Tillgänglighetsexpertis.
• Informationsarkitekt.
• Kommunikatörsnätverket.

Bakgrund

Utredningens syfte och mål

Denna utredning är ett ansats till att ge en samlad och uppdaterad bild av Västra Götalandsregionens (VGR) behov av ett systemstöd för bilder, och andra mediefiler, som inte har patient- eller personuppgifter relaterat till verksamheten. Våren 2013 gjordes en snabbanalys av befintligt systemstöd, hösten 2013 utfördes en enkät riktad till informatörer inom VGR och för några år sedan gjordes en rapport om VGR:s bildredaktionella behov av konsultföretaget InUse. Dessa arbeten står som inspiration för denna utredning. Det finns dessutom ett beslut från ett branschledningsmöte under 2013 på en så kallad BP0 för att ta fram en ny bildfunktion.

Målet är att ha dokumenterat behoven för en ordnad mediahantering som är kompatibel med en digital livscykelhantering för information.

Slutsatser från verksamhetens svar på höstens enkät

Under september 2013 ställdes frågor om bildbanksrelaterade behov till kommunikatörer inom VGR. Samtliga använder bilder främst för webben och olika sorters trycksaker. En av de som svarade använde bilder till filmer. Bilderna som hanteras finns oftast sparade på någon plats i högre upplösning men de flesta hanterar inte bilder i råformat.

Hälften anger att de använder VGR:s gemensamma bildbank men de flesta använder nätverksdiskar (G-kolon) med egen mappstruktur, Imagevault, fotoakuten.se, sxc.hu och en kör Adobe Bridge lokalt på en dator. Hälften anger att de antingen har någon som är duktig eller åtminstone klarar av bildbehandling eller ett grafiskt arbetsflöde. De flesta har någon gång köpt in bilder eller hyrt fotograf. Verkar dock inte vara något som sker frekvent utan snarare vid större produktioner eller uppfräschning av den egna samlingen av bilder man använder. De flesta har bilder de tagit själva och några få har lånat bilder från andra verksamheter. De flesta har inte publicerat bilder i sociala sammanhang på webben. Det som använts är främst Facebook, men någon gång även Flickr och Linkedin.

Önskemålen på en regional bildbank är i stort att det måste gå snabbt och lätt att hitta en bild man får lov att använda. Att det måste finnas en bra uppsättning genrebilder (för utsmyckning), vård- och medicinbilder för extern användning. Man vill kunna ladda upp många bilder samtidigt (batchhantering). Intuitivt gränssnitt utan tröghet som avbryter ett användbart arbetsflöde (undvika så kallat lagg). Att andra verksamheter delar med sig och att det ska vara lätt att dela ut/sätta rättigheter på sitt eget material.

En majoritet av de svarande känner att det är angeläget att få mer ordning på de bilder de själva använder. Någon känner att de har god ordning och andra att det är så få (egna) bilder att det är hanterbart.

En tredjedel anger att det vore bra om externa fotografer kan lägga in bilder, särskilt om det är en större mängd bilder. Behovet tycks finnas ganska sällan och kanske inte är så hög prioritet, men det kanske kan få verksamheten att dela ut fler bilder för andra att återanvända?

Definition, användarbehov och informationsarkitektur

Definition av bildbank

Kärt barn har många namn. Namnet ger en indikation på hur man ser på något. Det en trycksaksproducent kallar en bildbank behöver inte betyda mer än att det antyds att det finns en organisation eller struktur innehållandes bilder. En bildbank kan enligt någon vara de där 12 genrebilderna man får lov att använda i sin marknadskommunikation, samtidigt tar andra för givet att en bildbank är omfattande, digital, sökbar och integrerad i alla verktyg som behöver använda bilder. När vi, som i denna utredning, diskuterar ett systemstöd för en bildbank borde vi nog använda det engelska begreppet för denna typ av systemstöd, nämligen Digital Asset Management (DAM). Bilder, video, ljud och annan media är att betrakta som digitala mediaresurser som har många gemensamma behov av ett systemstöd.

DAM enligt Wikipedia:

“Digital asset management (DAM) consists of management tasks and decisions surrounding the ingestion, annotation, cataloguing, storage, retrieval and distribution of digital assets. Digital photographs, animations, videos and music exemplify the target areas of media asset management (a sub-category of DAM).”

Ett DAM-system är med andra ord väldigt mycket mer än ett ordnat sätt att visa bilder i ett galleri, det gäller alla former av media och att det ska vara en del av en digital livscykel.

Exempel på mediaresurser för ett DAM-system:

1. Fotografier (digitala råformat eller inskannad från original).
2. Digitalt skapade trycksaker som broschyrer m.m. (ursprungsfiler från Adobe Indesign, Quark mfl).
3. Ljudklipp, effekter, klipp med tal etc (i ett så ickeförstörande format som möjligt).
4. Video och animation (resultatet i så ickeförstörande format som möjligt)
5. Illustrationer, informationsgrafik, grafer och annan visualisering.
6. Poddsändningar, utbildningsmaterial och annan kronologisk media.
7. 3D-printerfiler och andra ritningar.

Mer normala dokument, som Excel-ark och riktlinjer i Word/PDF, räknas inte in här. Verktyg som Office-paketet används inte in i en professionell miljö där resultatet liknar en mediaresurs. Snarare är de riktlinjer, beslutsunderlag med mera. Däremot kan det finnas en poäng i att spara undan de projektfiler som skapar sammansatta mediafiler, likt PSD-filer från Photoshop, INDD-filer från InDesign etc så ett nytt original kan framställas med andra inställningar.

Att notera med ovan lista med exempel på vad ett DAM-system kan innehålla så gäller det att bevara originalet av en fil i dess mest ursprungliga format för att senare kunna framställa användbara kopior. Från detta original ska det finnas koppling till alla kopior, där vissa kopior är gjorda av användare och andra skapade automatiskt av DAM-systemet. Exempel kan vara en arkitektskiss från ett CAD-program som original och en PDF-export som kopia där det förstås är viktigt att PDF:en kan härledas tillbaka till CAD-filen vid behov av redigering – PDF:en är bara en död kopia för påsyn av lekmän. Att det finns en användbar och tillgänglig kopia/export är viktigt då alla inte har alla programvaror som krävs för att öppna filerna de behöver titta på. Det kanske ska vara ett krav på alla filer som läggs upp – finns ingen normal påsynskopia platsar inte filen i systemet, åtminstone inte som en fil någon annan än skaparen hittar (minskar mängden informationsbrus).

Med tillgängligheten bör man också räkna in att materialet är användbart och kopplat till de plattformar som behöver återpublicera materialet. Som webbredaktör ska man inte bekymra sig över format utan bör kunna fokusera på bildval, eventuell beskärning för att sedan enkelt skapa en koppling mellan DAM-systemet och webbplatsen som sedan sköter resten. Väl kopplat kommer DAM-systemet skicka bilden i den upplösning mottagaren behöver, komprimerat på den nivå mottagarens uppkoppling behöver och andra frågor redaktören inte bör ta ansvar för om denne inte uttryckligen väljer det.

I exemplet med poddsändningar så borde ett DAM-system rimligen kunna stå för själva kanalen som mottagaren prenumererar på och i så fall göra det på ett sätt som känns som en kompetent webb, men också stå som bakomliggande system för en enkel webbfront.

DAM-systemet behöver med andra ord vara aktivt och utgöra navet i maskineriet som erbjuder grundfunktionalitet för alla sorters medieresurser. Det är inte säkert att det finns ett nyckelfärdigt system för detta, men oavsett vad krävs det att man ser på den data systemet har att bevara, hur innehållet ska hittas, standarder att följa med mera. När man vet det är man mogen för att leta ett färdigt verktyg eller välja ett där man får ta tag i de behov som blev över.

Vad man har att vinna på att introducera ett DAM-system

Beroende på vad man jobbar med ser man olika nyttor med ett DAM-system. För denna utrednings del är det värt att i alla fall ta upp några exempel för att belysa inom vilken domän ett sånt här arbete rör sig.

Lägga ner andra system (för många användare)

Det finns garanterat andra föråldrade system att lägga ner, troligtvis ett antal som “man fått på köpet” eller egenhändigt skapade verktyg man vuxit ur. Något som nämnts i svaren på enkäten var att flertalet hade egen lagring av bilder på nätverksdiskar (G-kolon) vilket kanske funkar för väldigt enkla behov. Det stödjer troligtvis inte att man delar med sig av bilder till de som inte ingår i den närmaste verksamheten, inte heller har man anpassat stöd för att få filerna integrerade i en större söklösning eller andra informationssystem.

Att använda nätverksdiskar för sina filer är inte att dra full nytta av vad dagens teknik kan bistå med. Att inte ha fler system än nödvändigt sparar pengar man kan satsa på annat. Exempelvis har vi i ImageVault och Fotoware två system som funktionsmässigt överlappar varandra i stor utsträckning. Båda har en ganska saftig årlig licenskostnad som motiverar att man gör mesta möjliga av utgiften och kanske nöjer sig med att behålla bara det bästa verktyget.

Bättre koll på upphovsrätt och samtycke

Vem äger en bild man hittat internt? Får den återanvändas? Var får den användas? Måste bilden tas bort efter viss tid? Tidsgränser, nedräkning och påminnelser om att licenstiden håller på att löpa ut? Frågor om upphovsrätt och samtycke är dels ett problem under tiden material produceras men det är definitivt en utmaning att spara och ha en funktionell logg över dessa uppgifter under materialets livslängd.

Gemensamt samtycke-register skulle förenkla mycket för att få vår personal att samla in samtycke men också då behov finns att reda ut samtycke på andras bilder. Samtycket dokumenteras på papper eller digitalt med hjälp av mobila lösningar, och samtycket samlas centralt i DAM-systemet för långtidslagring.

En gemensam plats för att ta reda på bilder man har rätt att använda och möjlighet att kolla om man får använda en bild man sett andra använda. Blir en säker zon där man har god anledning att inte vara orolig för rättigheterna. Hjälpa användarna att fylla i allt kring samtycke och upphovsrätt (kryssa i om person finns på bild -> kryssa i om samtycke registrerats).

Detta ger möjlighet till att etablera en riskzon med material med mer oklara rättigheter användarna kan välja att undvika men blir tydligt för de som laddar upp material vad som behövs i form av dokumentation.

Erbjuder ett system för de som saknar ett

För de som ännu inte börjat med att katalogisera sina egna bilder kan man få dem att följa en gemensam standard direkt i ett verktyg där andra inom organisationen kan dra nytta av det man delar med sig av.

Minska mängden dubbelarbete där man lägger resurser på att ordna fram nytt material där något motsvarande redan finns att återanvända.

Bringa ordning i material och få bättre informationsarkitektur

Ger bättre möjlighet till sökbarhet om ett mer enhetligt arbetssätt kring struktur och metadata införs. Mindre osäkerhet över huruvida en bild man hittat internt får lov att återanvändas och i vilket sammanhang.

Centralisera insatserna till en plats

Med ett gemensamt system för digitala resurser är det lättare att få bred användning av nya tekniker löpande, exempelvis att anpassa sig efter nya format i framtiden, som WebP och h.265, när de väl kan hjälpa till att göra vårt befintliga material bättre hos mottagarna. Det är som sagt inte ett arkiv, det materialet som i sitt ursprungliga format läggs in idag ska kunna konverteras till framtida format och behov utan manuell insats. DAM-systemet ska kunna gå in som stöd för alla andra informationssystem som mer eller mindre bra försöker hantera mediafilers skapande, aktiva användande, återanvändande och arkivering.

Med ett gemensamt system får alla anställda färre gränssnitt att vänja sig vid eller egenheter i navigering att anpassa sig efter. Det blir enkelt att veta var man ska leta efter material om det bara finns en plats där man vet att det finns gott nog med innehåll att det är väl värt ett besök.

Identifierade grupper av användare/personas

På sätt och vis är det lite konstigt att gruppera användare av ett DAM-system i målgrupper då verktyget egentligen ska stödja alla oavsett om de jobbar med mediafiler eller konsumerar dem. Nedan är dock de målgrupper som är lätta att identifiera och egenskaperna kommer delvis ur den enkät som skickats ut till informatörer inom VGR.

• Grupp 1 – webbredaktörer.
• Grupp 2 – kommunikatörer.
• Grupp 3 – kunskapsarbetaren i verksamheten.
• Grupp 4 – den anställde som vill deponera filer eller samarbeta kring mediafiler.
• Grupp 5 – tryckerier och externa stödpersoner

Alla grupper måste få sina högsta prioriteringar i första versionen av ett regionalt DAM-system. Inte nödvändigtvis i samma verktyg då kraven på vårt DAM-system behöver vara att det ska vara väldigt utbyggbart för framtida behov vi idag inte kan föreställa oss.

Hur vi hanterar metadata och informationsarkitekturen

Hanteringen behöver vara kompatibel med dokumenthanteringsplanens metadata-spec, men komplettera med för respektive medieformat relevant standard, som EXIF. Nyckelordshanteringen behöver troligtvis vara en mix av kontrollerade vokabulär som MeSH, ICD–10 med flera för vårdrelaterade filer.

För andra typer av mediafiler behöver en informationsarkitekt tillsammans med en referensgrupp utvärdera administrativa vokabulär som EuroVoc. Till detta finns anledning att fundera på att upprätta en folksonomi, det vill säga en ordlista med det språkbruk de anställda använder som inte finns i kontrollerade vokabulär. Dessa ordlistor behöver integreras friktionsfritt när en användare lägger upp nytt material i ett DAM-system, genom nyckelordsförslag, så en frivillig standardisering uppstår när man lättare finner redan använda ord än att hitta på egna.

Metadata måste vara på en högre nivå än att det ska gå att söka reda på innehållet från en sökruta, det behövs troligen kategorier som kompletterar nyckelord med koncept som ryms inom mediafilen. Att behöva sätta flera kategorier på materialet hjälper till att skilja anledningen till metadata från tron att det har med navigering i DAM-systemet att göra. Användare ska med morot och piska få hjälp att fylla i kvalitativ metadata i en utsträckning som gör sökbarheten rimlig. Detta behöver vara väldigt intuitivt och användarvänligt enligt riktiga användare – annars riskerar det inte bli någon meningsfull metadata alls.

Förslag till vidare arbete

Här ges två förslag på hur vi nu kan resonera oss fram till nästa steg. Alternativ 1 står för den iterativa lösningen där behov kan identifieras löpande och alternativ 2 är den om man tror sig ha full koll på exakt vilken lösning man behöver. Först exempel på identifierade behov, en lista som behöver kompletteras av de olika intressentgrupperna.

Exempel på identifierade krav/behov

Nedan krav behöver stämmas av bland alla intressenter, prioriteras och ingå i ett projektdirektiv. Saknas något behöver det kompletteras i det projektdirektiv som tas fram.

Målet ska vara att ersätta all annan hantering av mediafiler förutom dess publicering till mottagare. Inga andra system ska behövas utöver de verktyg man har för bearbetning av filerna innan lagring i DAM-systemet eller de publiceringsplattformar man använder som front mot mottagarna.

1. Kunna hantera samtycke från objekt

DAM-systemet måste kunna långtidslagra samtycket. Dessutom behöver hanteringen vara väldigt enkelt för den som fotograferar. Om det är DAM-systemet eller annat verktyg (se bildexempel nedan på app) som stödjer insamlandet av samtycket spelar inte så stor roll så länge som det är intuitivt för användarna och lagras på ett korrekt sätt tillsammans med mediamaterialet. Gärna med en kortadress (långlivad URL-tjänst) för kontaktväg till hur man återkallar sitt samtycke eller kommer i kontakt med aktuell bildredaktör.

2. Metadata i DAM-systemet ska skrivas till filerna

Filerna i ett DAM-system kommer att spridas för vinden via webben och alla andra kanaler ut som finns. För att den som kommer över mediematerial ska kunna kolla källan, om det finns uppdateringar, upptäcka mer information behöver metadata skrivas till varje fil så långt det är tekniskt möjligt. På grund av spårningsbehov för den som finner en fil från oss, vår egen relevans i intern sökmotor och att bland annat bilders EXIF-data hjälper oss på externa sökmotorer ska DAM-systemet kunna skriva respektive mediafil metadata. För bilder är det EXIF, ID3 för MP3-ljudfiler och för detta ändamål behöver en komplett lista med minimikrav sättas upp per typ av fil.

En URI (beständig och unik internetadress till filens ursprung) anges i metadata för att dessa filer ska kunna automatiseras av framtida informationssystem bortom dagens uppfinningsrikedom.

3. Längd på videoklipp/tyngd på material

Videoklipp, film och ljud är format som kan ta mycket plats i anspråk. Gränser som maximal filstorlek ska kunna överskridas utan en massa merjobb. Varje användare bör rimligen ha rätt att ladda upp ett visst antal större filer och somliga användare kommer behöva lägga upp väldigt många tunga filer då de jobbar med rörlig bild etc.

Att IT-systemet är lätt att drifta ska väga väldigt lätt jämfört med användarnas behov av lagring.

4. Förenkla upphovsrätten för användarna

Man ska inte av misstag råka använda filer man inte har rätt att återanvända. Däremot bör verktyget stödja att man kan filtrera fram även dessa resurser så man kan bekräfta att de finns och be ägaren om att få använda materialet. Gränssnittet ska intuitivt låta användarna navigera bland de resurser man har rätt att använda utan onödig tankekraft eller manuell ansträngning.

5. Referera till flera källor per mediaresurs

På grund av att en sammansatt informationsprodukt, som en trycksak eller informationsgrafik, kan innehålla flera resurser med olika licensförhållanden behöver man i DAM-systemet kunna ha kommentarer/länkar/referenser för att peka ut vilka interna som externa resurser man använt. Detta behöver fungera över minst lika lång tid som man kan förvänta sig att filerna kommer vara i omsättning.

6. Kunna bjuda in externt folk för att ladda upp filer

Inte nödvändigtvis via FTP (gammaldags sätt att föra över filer) men det ska absolut gå att deponera flera filer i taget via en modern webbläsare för taggning i klump och individuellt. Målgrupp är externt anlitade fotografer och mediaredaktörer.

7. Tvinga, och hjälpa, användare att ange ett visst minimum av metadata

Exakt mängd metadata för egen användning, eller för publik åtkomst, är något VGR bör göra efterforskningar kring, pröva ut på representativa anställda och stämma av med någon informationsarkitekt. Systemet måste kunna uppmuntra, förklara och motivera användarna att få metadata-märkningen gjord i den nivå som behövs för resursens tänkta användning.

8. Behörighetsstyra resursers tillgänglighet

På grund av att en användare kan representera flera olika kommunikationskanaler behöver detta en separat utredning för att användarna inte ska tvingas hålla tillgodo med vad systemen erbjuder oavsett om det är intuitivt eller ej.

9. Olika storlekar/upplösningar av bilder/video kan erbjudas i vidareanvändande system utan att användarens manuella insats

Om inte användaren uttryckligen valt annat ska den för stunden, och för besökarens enhetstyp, mest lämpade storleken/upplösning på material skickas. Det kan vara att så kallade retina-skärmar (de har många bildpunkter per ytenhet) automatiskt får tyngre filer – om nu den vidareanvändande förvaltningen så önskar, exempelvis webbförvaltningen.

Det kan exempelvis innebära att en stillbild via en publik webbsida i EPiServer har ett visst antal standardstorlekar (“uppskalningar”) där normalbilden är 320 pixlar bred men erbjuds även i bredderna 512,1024, 2048, 3840 pixlar för de situationer där det är lämpligt. Här skall också mottagarens uppkoppling till nätet vägas in som faktor över vilka filer som skickas automatiskt.

Det kan också vara att en ett återanvändande system upptäckt en adaptiv utmaning likt dålig återstående batteritid hos den mottagande enheten och då efterfråga en videoström som inte använder lika påfrestande nätverkstrafik.

10. Erbjuda utgåvor/beskärningar anpassade efter mottagarens skärmstorlek

Vissa kombinationer av upplösningar och storlekar på skärmar gör att behovet av en mer inzoomad bild finns för att bilden ska vara meningsfull. Se exempel på nedan länk där en bild på personer för en mobil blir så liten och lågupplöst att det inte går att identifiera vilka som är på bilden. Se exempel på Smashing Magazine.

Denna “tillgänglighetsversion/lowres-kopia” behöver för DAM-användaren smärtfritt kunna skapas vid behov och av användaren regelstyras på ett intuitivt sätt oavsett om ursprungsbilden redan är publicerad eller ej. Görs en lowres-version ska det slå igenom på alla platser som lever upp till regelstyrningen (vilket kan vara exempelvis för skärmar med mindre än 500px bredd).

11. Allt material ska kunna speglas till lokala distributionsplatser (CDN) över klotet och fungera som ett CDN gentemot egna informationssystem

Allt material kan ha behov av att kunna skickas från andra platser på klotet än Västra Götalandsregionen på grund av prestandaskäl för mottagaren, kostnad för trafik etc. Vara kompatibel utan användarnas aktiva insats kunna sprida ut innehåll på etablerade leverantörers CDN.

12. Behöver stödja öppna och proprietära-, dagens och framtidens, fil- och mediaformat

Hur gör nuvarande produkter med eventuellt framtida format vi kan komma vilja använda? Som WebP som sparar cirka en tredjedel jämfört med en JPG-fil för fotografier.

Vilka format som är lämpliga till respektive konsumentplattform har ändrat sig mycket de senaste åren, och det lär fortsätta. DAM-systemet måste ha ett strukturerat sätt att internt konvertera till mer ovanliga/kommande format och dra nytta av deras vinster. Exempelvis att ett original-ljudklipp i WAV- eller OGG-format ska kunna dra nytta av ett kommande komprimerat format. Eller att videoklipp av idag ska kunna sändas som h.265 eller VP9 när det blir etablerat nog i framtiden att sända i så kallad 4K/Ultra-HD.

13. Kunna vattenstämpla bilder

Bland annat behöver bilder kunna vattenstämplas för att återkallas från publicering utan att ställa till det i publicerande plattform. Med andra ord kan man behöva kunna välja att ersätta en bild med vit bakgrund med en vattenstämpel som förklarar problemet. Vattenstämpel kanske också kan användas för att poängtera att man inte har behörighet att sprida bilden?

14. Hantera egen upphovsrätt

Vara generös med vårt eget material. Bilder kan vattenstämplas med Creative Commons. Har inte användaren aktivt valt en begränsande licens ska en så fri licens som möjligt vara standardinstallation. Viktigt hur detta flöde hanteras i DAM-systemet, dels med att man inte ska ha ledande frågor till begränsning men också att man minimerar antalet misstag där bilder VGR inte är ägare till kommer ut som något vi satt fri licens för.

15. Prenumerera på bilder

Likt Flickr. Ha exempelvis mallar i CMS som skapats på förhand som vid en framtida tidpunkt publiceras och hämtar bilder baserad på ett filtreringsbegrepp, tagg eller följer en fördefinierad kanal. Används för evenemang och bilder till pressrum för den alltmer bildbaserade berättelsetekniken på nätet. Med prenumeration avses RSS/ATOM-flöden, utvecklares motsvarigheter som JSONP, activity streams och detta behöver kunna kompletteras med nya format vid framtida behov.

16. Erbjuda flera nivåer av statistik/analys för användning

Dels behöver det i systemet finnas någon form av återkoppling till användarna så de förstår vad som är populärt att välja, vad som visats många gånger ute hos mottagarna med mera. Det är också viktigt att systemet stödjer en fullfjädrad loggning av ett externt system likt Google Analytics eller Piwik så det går att utföra webbanalys även på denna typ av material och inte enbart textsidor inom webbpubliceringssystemen.

17. Överlämna full transparens gentemot externa system, exempelvis Enterprise Search-lösning

All information om mediaresurserna behöver vara exponerade i en rimlig kombination av API och screenscraping/indexering/crawling helt utan att behöva ansluta till DAM-systemets databasmiljö.

18. Lägga till textning av video, ljud och bild

För film behöver textning, alternativt transkribering kunna göras direkt eller i efterhand som komplement till befintlig användning av resurserna. Ljud, och mer omfattande bilder som exempelvis informationsgrafik, behöver kunna transkriberas så någon mottagare med textbehov kan begära ut den versionen istället. Alla mediafiler behöver ha alternativtitlar som beskriver eller introducerar materialet för de som inte kan eller vill ta del av innehållet.

19. Privata/publika anteckna under resursens livslängd

Jämför hanteringen Google Analytics har. Anteckningar där man sätter anteckningar till valda datum/klockslag för att ange exempelvis när ett videoklipp spreds initialt, när något annat väsentligt hände som inkludering i ett utskick eller annan potentiell förändring. Detta används dels för spårning men kanske främst för att dra erfarenheter av vad som fungerar att kommunicera ut till mottagarna.

20. Enklare redigering av material

Bilder ska kunna beskäras etc. Klippa ljud/video? Skapa PDF-exporter av bilder/skisser etc?

Roller som behöver stötta arbetet

Kontrollinstanser som behöver ha löpande insyn i projektet är:

• Någon som bevakar att tillgänglighetsbehoven möts med åtminstone de funktionsnedsatta mottagarnas intresse.
• Interaktionsdesigner och/eller användbarhetsdesigner.
• IT-strateg, utvecklingsstrateg och/eller webbstrateg.
• Informationsarkitekt.
• Mediaredaktör.
• Film- och stillbildsfotografer.
• Kommunikatörer.

Alternativ 1 – Utvärdera befintliga systems mångsidighet som DAM-system

Tillsammans med utsedd referensgrupp gå igenom absoluta krav för att inte måla in sig i ett hörn. Även lista nivåer av önskvärda krav innan man tittar på vad produkterna. I detta alternativ tilldelas endast informationsarkitekten, ID/användbarhetspersonen och tillgänglighetspersonen vetorätt.

Detta alternativ går ut på att man identifierar grundkrav och garanterar innehållets levnad över tid, sekundärt är vilket eller vilka system som kan presentera innehållet och hjälpa till med arbetsflödet så länge som vi är trygga med att man inte sitter fast i en systemstandard (avseende informationen).

Förslag: minst 3 kategorier och minst 5 nyckelord från befintligt vokabulär, valfritt antal egna ord (som hamnar i folksonomin). Tycker vi återvinner sxc.hu’s kategorilista om vi inte hittar någon annan standardiserad som fungerar bättre på mer än bilder. Dessa metadata-krav ska provköras på de olika användargrupperna vi identifierat. Kanske med ett antal fotografier, några videoklipp och så iakttas deltagarna när de försöker få till tänkt mängd metadata.

Ett förslag för detta alternativ är att först utvärdera produkterna ImageVault och FotoWeb på grund av att vi redan har dem i verksamheten.

En diskussion behöver tas om hur den vanliga anställda ska förstå skillnaden mellan dokumenthantering och DAM-systemets användningsområden, det räcker nog inte med att en policy upprättas för hur det är tänkt. Projektet behöver komma på hur bildhantering förhåller sig till dokumentplanen och arkivering.

Alternativ 2 – Köpa ett system som antas vara nyckelfärdigt och framtidssäkrat

Detta alternativ går ut på att köpa ett så färdigt system (ekosystem) så man aldrig i framtiden vill göra egna modifieringar (som oftast leder till svårigheter att uppgradera produkten). Mer av en produkt- eller leverantörsstrategi än något annat. I denna typ av projekt är det mycket viktigt att bevaka verksamhetens, användarnas och mottagarnas intressen först, att kritiskt granska interna och externa leverantörers utfästelser.

Exempel på plattformar att utvärdera:
* Sharepoint är halvbra på det mesta men har utmaningar att leva upp till att stödja ett grafiskt arbetsflöde på egen hand. Det pratas mycket om att Sharepoint har en kompetent metadatahantering, innan man köper in på det behöver vi hitta oberoende bevis från någon som använt sin metadatamärkta data från Sharepoint till något med motsvarande komplexitet vi själva ser framför oss.
* ImageVaults styrka är dess integration med webbpubliceringssystemet EPiServer, men i en senare version av ImageVault finns en tydligare API-strategi som gör att man eventuellt helt kan bortse från ett upplevt beroende till ett CMS.
* FotoWare har en till synes komplett svit av applikationer för mediahantering, indexering och återfinnande. De tycks ha en hygglig API-strategi som kanske gör att man kan känna sig fri att använda sina mediafiler som man själv vill. Verkar vara sprunget ur en väldigt redaktionell värld vilket nog inte är majoriteten av de användare vi hoppas få till ett DAM-system.

Ska alla ha vetorätt här? Är ju en del av problemet med att någonsin välja ett system. Även om man väljer ett så kallat nyckelfärdigt system måste innehållet garanteras över tid och ingen stängd eller proprietär systemstandard etableras.

Alla kommentarer på detta utkast mottages tacksamt.

Några av de inkomna tipsen:

• Kristian Norling tipsar om Real Story Groups bloggpost om skillnaden mellan DAM och MAM. Real Story Group har också utvärderat några leverantörer av DAM-system.
• Peter Krantz tipsar om att ha ett öppna data-perspektiv på sin bildhantering, likt Livrustkammaren som deponerar bilder på Commons hos Wikimedia.