Användarmedverkan i öppna källkodsprojekt

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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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)

9. 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

10. 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)

11. 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

12. 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

13. 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

14. 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

15. 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, texpersonas

16. 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

17. 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

18. 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 UserExperience in Open Source Software Design Hedberg, Henrik & Iivari, Netta (2009): Integrating HCI Specialists into Open Source Software Development Projects.

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. Att involvera HCI-experter • Flera forskare rekommenderar att MDI-experterska involveras i öppna källkodsprojekt, men det kan finnas svårigheter med detta • MDI-experternakan 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)

28. 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

29. 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 - RemoveTrustwaveCertificate(s) from trustedrootcertificates • 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

30. Frågor?