Användarmedverkan i öppna källkodsprojekt Johanna Sefyrin, doktor informatik johanna.sefyrin@miun.se

Användarcentrering i öppna källkodsprojekt? Öppna källkodsprojekt är ofta inte särskilt användarorienterade Dessa drivs ofta – men inte alltid – av utvecklare som ser sig själva som sofistikerade användare, och som vänder sig till andra sofistikerade användare Man kan skilja på utvecklare som också är användare, och på användare som är ointresserade av att delta i utveckling av program och system

IT och användning Informationsteknologier är meningslösa om de inte används / inte har några användare – de uppstår i viss mening i användning Informationsteknologier som inte används faller i glömska och dör Därför är användare och användningskontexter så viktiga

Varför använda IT? Informationsteknologier används därför att De uppfyller ett visst behov för en viss person i ett visst sammanhang (privat eller i ett arbetssammanhang) och Är relativt enkla och möjliga att lära sig att använda, eller Man måste använda dem (tex. för att deklarera för att det ingår i en arbetsuppgifter) – och då spelar det ingen roll om de är krångliga Informationsteknologier används inte därför att De inte uppfyller ett behov De är svåra och krångliga att lära sig att använda Det inte finns något tvång att använda dem

För att få veta måste man fråga För att kunna utveckla informationsteknologier som fyller ett behov hos vissa personer i en viss kontext så måste man veta något om det sammanhanget och det behovet, samt om vilka som är involverade och som kommer att använda sig av teknologin Gäller det tex. bokning och försäljning/köp av flygresor? Här finns då Dels de som arbetar i den organisation som säljer flygresorna och som kommer att ta hand om inkomna bokningar De som bokar flygresorna, privatpersoner eller anställda i företag som behöver flyga i jobbet De som ska arbeta med underhåll och vidareutveckling av systemet Kan även vara anställda på resebyråer, men de brukar ha egna system För att få reda på mer om situationen måste man veta något om hur bokning och försäljning/köp av flygresor går till behöver man lära sig något om situationen utifrån de olika aktörerna

Varför användarcentrering? Flera olika skäl Demokratiska skäl: anställda i org har rätt att delta i beslut som påverkar deras arbetssituation och därmed även IT som påverkar deras arbetssituation Detta kan också ses i ett livsperspektiv; att individer har rätt att delta i beslut som påverkar deras livssituation Program och system blir använda i högre grad om de är anpassade till användare och deras användningspraktiker Det betyder att system som inte anpassas till användare riskerar att inte bli använda, och utvecklingen är därmed kostar pengar och resurser i onödan Det gäller både offentliga och kommersiella system

Vad är användarcentrering? Användarcentrering kan innebära att användare på olika sätt är engagerade i utvecklingen av program, tjänster och system Ett sätt att klassificera olika användarcentrerade ansatser är följande (Iivari och Iivari, 2006) Användarfokus, Arbetsfokus Deltagande design Personalisering

användarfokus Tar i beaktande individuella användare, idealt med syfte att ta i beaktande varje enskild användares behov Ofta svårt då användarna är många, med motstridiga behov, och spridda på olika platser Fokus på användare inom en specifik organisation, som kan vara utspridd över flera länder Vanligt att användarna representeras i form av genomsnittliga, typiska eller fiktiva användare. Fokus på allmänmänskliga utifrån psykologi och ergonomi Vissa anser det onödigt att involvera riktiga användare, och menar att det räcker med fiktiva, dvs. tänkta typer av användare (exempelvis så kallade personas)

Arbetsfokus Fokuserar mer på användningssituationen och användningspraktiker än på enskilda användare – även här i en organisatorisk kontext En viktig fråga blir hur användningssituationen ska förstås och representeras: Risk att fokus hamnar på den organisatoriska situationen snarare än på enskilda användare Användarna är i den här inriktningen framförallt tillhandahållare av information för dem som utvecklar informationssystem och IT-tjänster Det här aktualiserar frågor om makt, men maktfrågor än ganska frånvarande i den här typen av forskning

Deltagande design Fokuserar på maktfrågor, är särskilt stark i de Nordiska länderna Utgick ifrån att de anställda och ledningen på ett företag har olika intressen och synsätt Fokus på arbetsplatsdemokrati och medbestämmande, då nya / ändrade informationssystem förändrar anställdas arbetssituation Den här inriktningen diskuterar inte bara hur användarcentrering ska gå till, utan också varför Idealet är att användarna fungerar som med-designers, som är delaktiga och har inflytande under hela designprocessen Har traditionellt sett fokuserat på organisatoriska kontexter med små och tydliga grupperingar av anställda Det här blir svårt i större organisationer och då användarna befinner sig också utanför organisatoriska kontexter Fokuset på makt har minskat sedan 1970-talet, och flyttats till frågor om hur deltagandet ska gå till (dvs. metodfrågor)

Personalisering Ett informationssystem eller en tjänst kan anpassas av enskilda användare under användningen Det kan på sätt och vis ses som en ideal situation där användarna är med och utvecklar en produkt – dock inom vissa ramar som satts under utvecklingen Aktuella exempel är smarta mobiltelefoner vilka användarna kan anpassa genom att ladda ned och installera de program de vill använda

Särskilda förutsättningar Öppna källkodsprojekt skiljer sig ofta från traditionella slutna projekt: De genomförs ofta av personer som befinner sig på olika fysiska platser, och genomförs i olika organisationer och vid olika tidpunkter De är ofta beroende av kommunikation och koordination via internet Användarna befinner sig också ofta på olika platser och i olika organisatoriska / andra kontexter De användare som vill använda systemet utan att behöva bry sig om tekniska frågor deltar sällan i de forum som används för kommunikation De följer en annan logik: ”release early and release often”, dvs. inte samma planering

beslutsstrukturer Hierarki / lökstruktur: Kärnteamet är de som bestämmer De anförtrodda får också ändra i källkoden Bidragsgivare kan skicka in bidrag och hoppas att dessa blir godkända kärnteam anförtrodda bidragare aktiva användare passiva användare

Deltagande genom olika roller Deltagande kan ske på olika sätt, genom olika roller: Att användare informerar om arbetspraktiker och åsikter Att användare tillfrågas om arbetspraktiker och åsikter och agerar som konsult till utvecklare Att användare deltar i utvecklingen

Deltagande genom representation Användares arbetspraktiker och åsikter kan representeras av någon slags mellanhänder, tex. MDI-experter Även dessa kan ha en informerande, konsultativ eller deltagande roll Användare kan representeras i form av generaliserade eller typifierade användare, tex personas

Användarcentrering med olika syften Att förstå användarna och deras användningssituationer Att i samarbete med användare eller representanter för dessa utforma delvis nya användningspraktiker för dessa Att användarna får utvärdera (testa) (delvis) färdiga lösningar såsom prototyper, betaversioner eller andra former av lösningar / lösningsförslag

användbarhet Informationsteknologier används därför att de uppfyller ett visst behov, eller därför att man måste använda dem Vissa talar om användbarhet (usability): Den grad i vilken användare i ett givet sammanhang kan bruka en produkt för att uppnå specifika mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt. Upphovspersonen till begreppet vill också inkludera Hur lätt det är att lära sig använda för en nybörjare Hur lätt det är att minnas hur man gjorde om man gör ett uppehåll och därefter börjar använda produkten igen Hur många eller få fel som användarna gör Arbete med användbarhet är inte detsamma som deltagande, utan sker oftast genom användarexperter

Svårigheter med öppna källkodsprojekt Följande bilder utgår ifrån ett användarfokus, och tittar på bla följande: Utvecklarnas inställning Den öppna källkodskulturen Begränsningar i processen Följande slides kommer framförallt ifrån följande artiklar: Nichols, David M. & Twidale, Michal B. (2003): The Usability of Open Source Software Bach, Paula M. et al (2009): Designers Wanted: Participation and the User Experience in Open Source Software Design Hedberg, Henrik & Iivari, Netta (2009): Integrating HCI Specialists into Open Source Software Development Projects.

utvecklarna Utvecklarna är inte typiska slutanvändare – de är tekniskt sofistikerade och kunniga användare – och de tycker att typiska icke-tekniska slutanvändare är okunniga Ej unikt för öppen källkodsutveckling Öppen källkodsutveckling bygger på egoistiska motiv dvs ”scratching a personal itch” (Raymond, 1998) – och utvecklarna får erkännande av andra utvecklare för att de utvecklar tekniskt sofistikerade lösningar, och användbarhetsfrågor har lägre status och ses som mindre utmanande, och ointressanta

Utvecklarna igen Funktionalitetsproblem är lättare att specificera och modularisera än gränssnittsproblem En liten ändring i ett gränssnitt kan medföra att logiken i hela gränssnittet måste ändras Ändringar i underliggande funktionalitet görs genom att ändra en modul Utvecklarna värderar ofta tekniskt komplicerade program med många funktioner framför enkelhet

Den öppna källkodskulturen Användbarhetsexperter släpps inte in i / engagerar sig inte i den öppna källkodskulturen (för de är inte utvecklare) Öppen källkod bygger på frivilligt arbete och det finns inga resurser för högkvalitativt användbarhetsarbete – som kan finnas i slutna kommersiella sammanhang Design av användargränssnitt bör ske i början av designprocessen men ofta sker utveckling i snabba, iterativa utvecklingscykler med fokus på funktionalitet (”release early and release often”) vilket ger lite tid åt användarcentrerad design

Begränsningar i processen Proprietär programvara är så dominerande att den sätter standarden för gränssnitt, vilket gör att öppna källkodsprojekt ofta kopierar existerande proprietär programvara istället för att utveckla egna nya gränssnitt Tex. Open Office

Användbarhetsfrågorna får allt större plats De användbarhetsproblem som många öppna källkodsprojekt har kan liknas vid dem som proprietära projekt hade tidigare (80-talet) Till en början vände sig proprietära utvecklingsprojekt till en begränsad grupp tekniskt kunniga användare När gruppen användare blev större och mindre tekniskt kunnig blev man tvungen att använda användarcentrerade metoder för att produkterna skulle bli (sålda och) använda En liknande utveckling gäller öppna källkodsprojekt, som i ökande grad vänder sig till större grupper av användare som också inkluderar tekniskt ointresserade personer, och då blir man tvungen att ta hänsyn till användbarhetsfrågor

Sätt att jobba användarcentrerat Kommersiella ansatser: att anlita företag som tar hand om användbarhetsfrågor Tekniska ansatser: automatiserad utvärdering av gränssnitt Akademiskt engagemang: genom att involvera tex. datateknikstudenter Involvera slutanvändarna: mer nedan Att skapa infrastrukturer för användbarhetsdiskussioner: mer nedan Att dela på användbarhetsanalys och –design, dvs. att göra användbarhetsstudier på enskilda individer, koordinera dessa och använda dem i design Att involvera MDI-experter: mer nedan

Involvera slutanvändarna Vanliga användare deltar inte i felrapportering via forum för att det är krångligt och tar lång tid Applikationer för kraschrapportering är däremot enkla och snabba att hantera Användare skulle kunna rapportera problem genom applikationer för kraschrapportering, men även genom att delta i forum för rapportering av problem Att skapa färdigpaketerade användartester som kan genomföras på avstånd, av vem som helst när som helst Dessa förslag möjliggör för användare att delta utan att kunna de tekniska detaljerna Det kan dock vara viktigt med feedback för dem som deltar

infrastrukturer för användbarhetsdiskussioner Det kan behöva skapas specifika infrastrukturella förutsättningar för att involvera vanliga användare i diskussionsforum för felrapportering Diskussionsforum för felrapportering och –åtgärder bör bli mindre tekniskt fokuserade om vanliga användare ska kunna delta Diskussionsforumen är dessutom textbaserade, och det kan behövas möjligheter att skissa eller visa bilder för att beskriva problem som är relaterade till grafiska gränssnitt – tex. skärmdumpar och videoklipp

Att involvera HCI-experter Flera forskare rekommenderar att MDI-experter ska involveras i öppna källkodsprojekt, men det kan finnas svårigheter med detta MDI-experterna kan få det svårt att visa sitt värde för de utvecklare som är tongivande i en visst projekt om dessa inte förstår värdet av användbarhetsfrågor Därför kan det uppstå kommunikationsproblem Det kan också vara så att fokus ligger på att göra (”release early and release often” snarare än att förstå (användarnas situation och praktiker)

kommentarer Dessa slutsatser och förslag bygger på en snäv bild av vad ”vanliga” icke-tekniska användare är intresserade av Dvs. att de nästan enbart skulle vara intresserade av enkla gränssnitt och inte av funktionalitetsfrågor Man utgår ifrån en generaliserad kognitionspsykologisk modell med utgångspunkten att alla människor fungerar ungefär likadant Man uppmärksammar tex. inte att människor använder programvaran i olika praktiker och har olika behov i dessa Det handlar inte om demokrati, medbestämmanderätt eller möjligheten att få vara delaktig i att påverka ens liv Fokus ligger på att reagera på förutsättningar som andra redan har satt Här finns flera intressanta maktfrågorna som dock inte är synliga

Exempel Exempel på aktuella öppna källkodsprojekt som jobbar mer eller mindre användarcentrerat Mozilla Firefox, exempel på projekt med hög användbarhetsfokus: Mozilla: Bug 513414 - Reduce the number of installation steps on Windows Mozilla: Bug 724929 - Remove Trustwave Certificate(s) from trusted root certificates Inkskape, exempel på projekt med mellanhögt fokus på användbarhet https://bugs.launchpad.net/inkscape ksoap2-android, ett projekt med lågt användbarhetsfokus: https://code.google.com/p/ksoap2-android/issues/list

Frågor?