Udviklere! Sådan giver I redaktøren den bedste oplevelse

Med få tilpasninger kan man som udvikler gøre sit CMS væsentlig mere brugervenligt for redaktøren. I dette indlæg vil jeg forklare, hvordan du helt enkelt gennem værktøjerne i Episerver CMS kan skabe større brugervenlighed og undgå en stribe undrende spørgsmål fra redaktøren.

En velkendt samtale?

Uden at fornærme nogen, kan jeg godt konstatere, at en udvikler sjældent ser helt det samme som en indholdsredaktør. Hvad, der forekommer som ’logik for burhøns’ for en udvikler, kan være noget kryptisk for en redaktør, men som leverandør skal udvikleren gerne levere et produkt, som giver mening for kunden. Det er faktisk slet ikke så svært med Episerver CMS.

Jeg har flere gange overhørt (eller selv haft) en samtale, der udspillede sig cirka som nedenstående:

Redaktør: ”Jeg vil gerne have et billede og en tekst på forsiden.”

Udvikler: ”Ja? Har du ikke læst min mail med 32 punkts guiden?”

Redaktør: ”Joeh… men jeg forstå ikke helt, hvorfor jeg skal oprette to blokke og en ny folder i medie biblioteket — det virker lidt voldsomt, når jeg bare gerne vil have billedet fra vores TED talk på?”

Udvikler: ”Jamen vi blev nød til at lave et *volapyk* for a kunne dele *noget med et interface???* og så skal du huske at *noget med en server og noget ’content’*.”

Redaktør: ”Nå eh… okay… jeg prøver, kan du hjælpe mig hvis jeg ikke kan finde ud af det.”

Udvikler: ”Ja det kan jeg godt, det tager 30 minutter.”.

Dette er naturligvis sat meget skarpt op, men det sker oftere end nødvendigt, og det er der flere grunde til. En grund er, at redaktøren ikke er med fra starten af processen. Udvikleren laver noget, der er super smart, og hvis udvikleren selv skal sige det, er koden virkelig smuk. Men udvikleren tænker ikke nødvendigvis på slutbrugeren. Det er ikke, fordi udvikleren er doven eller ikke ønsker, at kunden skal være glad for det, som udvikleren laver — Når koden er tæt på genial, skulle kunden jo gerne være glad. Det er fordi, det ikke er udviklerens bord. Udvikleren skal udvikle — Og hvad angår brugervenlighed? Der har vi UX og Design til at hjælpe — De er vilde med brugervenlighed!

I Episerver er det imidlertid ikke særligt tidskrævende eller trivielt at lave et CMS, der giver god mening for redaktøren at bruge.

Jeg vil i de kommende eksempler tage udgangspunkt i Alloy Demo-sitet, der følger med, når du henter EPiServer Visual Studio Extensions, som kan findes her https://marketplace.visualstudio.com/items?itemName=EPiServer.EpiserverCMSVisualStudioExtension).

Pagetypes og blocktypes skal give mening

Lad os begynde med Pagetypes og Blocktypes. Det kræver ikke ret meget af udvikleren at sørge for, at PageTypes eller BlockTypes (og andet content) fremstår med et klart og tydeligt formål, og det kan være til stor hjælp for redaktøren.

Las os tage udgangspunkt i en side, der indeholder en liste af nyheder. Vi kalder modellen for NewsCollectionPage.

For en udvikler giver det fin mening. Det er jo en side, der holder en collection af typen Article Page, som bruges til nyheder. Men for en redaktør fremstår det muligvis en anelse mere kryptisk. Jeg har igennem de sidste mange år set masser af eksempler på ovenstående, og jeg har muligvis også selv været skyld i et par af dem.

Men hvis vi nu tilføjer lidt til vores model:

[ContentType(DisplayName = “News list page”,

GUID = “8f916e31-cd05–49a5-bb27–52d7b8bf8304”,

Description = “This page can contain a selection of news stories”,

GroupName = “News”)]

[SiteImageUrl(Global.StaticGraphicsFolderPath + “news-thumb.png”)]

public class NewsCollectionPage : StandardPage

Så bliver det hele hurtigt meget mere behageligt at se på — Måske sidder der endda en designer, der kan bruge 30 minutter på at lave et thumbnail, der gør det ekstra lækkert. Det er små ting, der betyder meget for den oplevelse, slutbrugeren får.

WYSIwYG-interface gør redigering nemmere

Små visuelle elementer forøger altså brugervenligheden væsentligt for redaktøren. Der er en rigtig god chance for, at redaktøren er vant til at arbejde i en eller anden form for visuelt tekstredigeringsværktøj og derfor føler sig tryk og bekvem ved det. Dette skal udvikleren også huske, når der arbejdes med indhold. Episerver giver redaktøren mulighed for ikke at skulle bevæge sig for langt ud af sin comfort-zone, hvis udvikleren husker at tage forbehold for denne mulighed.

Episerver giver mulighed for on page editing, og det kræver utroligt lidt for udvikleren at sørge for, at denne feature kan benyttes.

NewsCollectionPage, har 3 felter — Title, Teaser og NewsPagesContentArea. Selv om vi selvfølgeligt husker at sortere og beskrive vores felter, så er redigeringen formentligt nemmere for redaktøren, hvis denne tilbydes et WYSIWYG-interface.

I modsætning til at arbejde i sidens Edit mode, der ofte kan være ”forurenet” med en masse felter, som redaktøren ikke har brug for. Som nedenstående eksempel viser.

Så når vi renderer vores felter i viewet, skal vi huske at bruge Episervers indbyggede funktionalitet. Vores NewsCollectionPage’s view ser sådan ud.

<h1 @Html.EditAttributes(x => x.CurrentPage.Headline)>@Model.CurrentPage.Headline</h1>

<div @Html.EditAttributes(x => x.CurrentPage.Teaser)>@Model.CurrentPage.Teaser</div>

@Html.PropertyFor(x => x.CurrentPage.NewsPagesContentArea)

På den måde ser redaktøren slutproduktet, mens teksten skrives.

begrænsninger er brugervenlige

Vi kan samtidig gøre systemet endnu mere brugervenligt for redaktøren ved at tilføje begrænsninger. Allerede nu ved vi, at vores News Pages Content Area kun må indeholde Content af typen Article page, så der er ingen grund til, at redaktøren skal kunne andet. Hvis redaktøren prøver og fejler, er det irriterende, men det er god vejledning og brugervenligt, hvis redaktøren prøver og får at vide i systemet, at det er Artikler, der skal bruges.

I Episerver har vi mulighed for at sætte nogle regler for vores properties. Så ved at huske at tilføje attributten AllowedTypes til vores NewsPageContentArea Porperty, så kommer vi uden om den problematik.

[Display(GroupName = SystemTabNames.Content, Order = 120, Name = “News Pages”, Description = “Drag and drop news stories into this Content area.”)]

[AllowedTypes(new[] { typeof(ArticlePage) })]

public virtual ContentArea NewsPagesContentArea { get; set; }

Når vi forsøger at tilføje en side, der ikke er af typen ArticlePage — så forsvinder content area-feltet.

Men forsøges der med en ArticlePage:

Så får vi dette meget fine resultat:

Dette kan så krydres op med en fin besked til redaktøren, der fortæller, hvorfor redaktøren ikke får lov til at tilføje siden til listen, fordi den er af en ”ulovlig” type.

VALIDERING mindsker fejl

Det handler om at minimere redaktørens mulighed for at lave fejl. Det giver naturligt nok en ret skidt oplevelse for en redaktør, hvis redaktøren kommer til at skrive et tal, hvor vi forventer en tekst, og derfor pludselig får en gul skærm og ikke kan sælge sit produkt i Mellemamerika, før der har været en udvikler inde over.

Det kan også være, at redaktøren ”ødelægger” den ellers flot opsatte side ved at tilføje en for lang tekst. Den lange tekst ser måske godt ud i den høje opløsning, redaktøren sidder med, men den ser virkeligt skidt ud hos de fleste kunder, da de typisk har en lav opløsning på skærmen. Det giver en dårlig oplevelse for alle parter, så lad os gøre hvad vi kan for at undgå det.

Lad os antage, at vi ikke vil have en alt for lang overskrift. Dette kan måske ødelægge den fine Mark-up, som står knivskarpt, efter vores frontendudvikler har knoklet.

Episerver stiller en lang række valideringsværktøjer til rådighed og giver dig mulighed for at lave dine egne regler også. Jeg vil ikke gå i dybden med dette men blot illustrerer, hvordan ovenstående scenario undgås.

Ved at tilføje StringLength-attributen til vores Headline property:

[Display(GroupName = SystemTabNames.Content, Order = 100, Name = “Headline”, Description = “This field is for the headline of the page”)]

[StringLength(50, ErrorMessage = “The Headline is more than 50 characters”)] public virtual string Headline { get; set; }

Når redaktøren så prøver at publicere en for lang overskrift, vises denne besked og publish forhindres.

omhu er nøglen

Dette er blot et par eksempler på nogle funktioner, der kan benyttes til at give slutbrugeren en positiv oplevelse, når udviklerens fine arbejde bliver leveret til dem.

Alle disse værktøjer bliver stillet til rådighed af Episerver som en out of the box-funktionalitet, der giver udvikleren rig mulighed for at udvide og bygge sine egne funktioner og moduler oven på.

Ansvaret for at huske at få disse ting implementeret ligger primært hos den opmærksomme udvikler, og i sidste ende er det langt mindre tidskrævende at huske disse ”småting”, end det er med et langt efterslæb af undrende spørgsmål.