Användarvänlighet i Optimizely/Episerver

Optimizely (tidigare Episerver) är ett väldigt flexibelt system. Det finns massor att göra för att anpassa verktyget både för besökare och redaktörer. Det som jag så ofta förvånas över är att så få gör något åt redaktörsgränssnittet.

Jag tror att en orsak till det är att det är så enkelt att ändra så att ingen gör det. De som utvecklar ser det inte som ett problem att det finns fält med konstiga namn eller flikar som man inte har nytta av. Det spelar ingen roll att det ligger många mappar i filhanteraren, för de ska ju ändå inte användas. Men från mitt perspektiv kan man inte ha mer fel. Det är precis detta som spelar roll.

En person som aldrig har sett Optimizely har ingen aning om att dessa saker är enkla att ändra på och tror att det måste vara så. Att fältet där en redaktör ska skriva sin text heter Main Body innebär inte att det är logiskt för denna att där skriva sin Brödtext. Detta skapar två problem. Det första är att det är stor risk att personen tycker att systemet är svåranvänt och tråkigt. Den andra problemet är att man gör det onödigt svårt för en person att lära sig systemet.

Mitt råd till er är att redan i kravställningen av webbplatsen se till att alla namn och fält blir rätt från början. Det finns ingen anledningen att vänta med det. Jag får så ofta höra, att vi tar det senare. Problemet är bara att “senare” sällan kommer. Det blir helt enkelt inte gjort. Även om man inte gör det direkt så måste det vara gjort innan utbildning av redaktörer. Det är ofta då redaktörerna möter systemet första gången och du vet ju hur man brukar säga, first impression last.

För att förenkla för dig som är kravställare/beställare har jag gjort en lista på saker som behöver gås igenom i Optimizely innan utbildning, så att redaktörsläget blir så enkelt som möjligt att lära sig och förstå. Om du själv inte vet hur saker och ting ska göras, ta med listan till din leverantör och gå igenom den tillsammans.

Alla fält som finns i mallar kan ha egna namn och hjälptexter. Dessa blir ofta ganska tekniska namn och hjälptexter saknas ofta. Det bör finnas bra tydliga namn som gör att det är lätt att förstå vad varje fält ska innehålla. Detta kan göras i XML-filer så att det är möjligt att ha redaktörsgränssnittet på flera olika språk om så önskas. Fatta beslut om vilka språk ni ska ha innan utbildning. Ändra helst inte på standardnamn från Optimizely, då detta kommer att påverka användardokumentationen framöver.

Sätt fälten i en logisk ordning, så att det blir enkelt att fylla en sida med innehåll. Bestäm ifall vissa fält ska vara tvingande eller inte. Se också till att det är logiskt att förstå varför vissa fält ligger på en viss flik. Generellt brukar det vara lämpligt att placera fälten såsom sidan är uppbyggd, uppifrån och ner helt enkelt.

Bestäm i vilken ordning som flikar ska visas och vilka namn de ska ha. Sätt eventuellt rättigheter ifall inte alla ska se alla flikar.

I och med den nya editorn är det fullt möjligt att ha olika inställningar på olika editorfält i samma mall. I ingressfältet vill man normalt inte tillåta samma möjligheter som i ett brödtextfält. Man vill säkert inte heller ha ett lika stort fält. Allt detta går att anpassa. Fatta beslut om storlek, knappar och design i respektive fält. Se bifogat exempel från annan kund. Läs gärna ett gammalt blogginlägg om det här.

När man skapar en ny sida, visas ofta alla mallar i en lista. Vilka som ska visas går att styra på olika sätt, dels genom vilka som ska vara tillgängliga under en viss mall, men också per behörighet. Det behöver fixas så att redaktörer inte tror att de kan skapa alla typer av sidor. Ge också alla mallar logiska namn och hjälptexter. Sortera dem i en logisk ordning på de ställen där de är fler i samma lista.

Om Optimizely filhanterare ska användas så bör det finnas en färdig struktur med behörigheter på mappar. Det måste finns ett logiskt sätt att hitta filer och veta vart de ska placera. Gör man inte detta från början, kommer filhanteraren bli som en höstack som det är omöjligt att hitta något i. Det är viktigt att bestämma vilka startpunkter som ska användas och strukturera dem så att rätt startpunkt visas först.

Filer och block hanteras i samma struktur, vilket innebär att det behövs mappstruktur med eventuella rättigheter för block.

Ska ni använda mycket formulär, hamnar även dessa i samma mappstruktur som filer och block. Styr upp så att man förstår hur man ska hitta de olika delarna.

De olika behörigheter som olika grupper ska ha, bör vara uppsatta inför utbildningen. Det blir dumt om en person har rätt att göra saker under kursen, men inte har det sedan. Risken är att det leder till att man blir förvirrad av för mycket saker under kursen och sedan när man kommer tillbaka blir man frustrerad över att man inte kan göra saker som gjorde under kursen. Man tror ofta att man gör fel, fast att det egentligen är systemet som har begränsningar.

Trädet bör vara så rent som möjligt, med så mycket “riktigt” data som möjligt. Ta bort allt vad test och annat heter och styr upp så att alla eventuella systemsidor ligger lite undangömda för redaktörer. Trädet ska så långt som möjligt återspegla den struktur man ser på webbplatsen, det blir mest logiskt för redaktören.

I många lösningar är flerspråksstödet aktiverat fast det inte är meningen att man ska jobba på flera språk. Ska webbplatsen bara finnas på ett språk, bör denna funktion avaktiveras.

Ska ni kunna publicera mycket innehåll samtidigt, kan ni använda den inbyggda projekthanteringen. Om inte så se till att dölja denna funktion så den inte stör.