Kravspesifikasjon – den umulige kunsten å beskrive noe som ikke finnes

Publisert 30. november, 2009 av Marius

Kravspesifikasjonen er dokumentet som fullstendig beskriver det som ikke ennå finnes, på en måte som gjør at ingen kan misforstå den. Den perfekte kravspesifikasjonen – gitt at noe sånt faktisk kan lages – er så utfyllende, entydig, gjennomtenkt og forståelig at hvem som helst skal kunne lage det den beskriver. Kravspesfikasjonen er jo også ofte laget for nettopp det: at man kan innhente tilbud fra flere leverandører og sammenligne det som effektivt skal være samme leveranse ut fra pris; siden alle leverandørene skal levere det samme er det bare prisen som skiller.

Sammenlign dette med hvordan prosjekter faktisk fungerer: etterhvert som man begynner å lage noe, lærer man hvor lite man egentlig visste om problemområdet. Etterhvert som brukere begynner å klikke på knapper ser man hva de egentlig trenger. Prosjekter er en læringsprosess, og kunnskapen man får underveis i prosjektet har enorm verdi. En «god» kravspesfikasjon eksisterer i en verden der dette ikke skjer, der lærdom man får underveis i prosjektet håndteres gjennom avviksprosesser (bare smak på det ordet…). En god kravspesifikasjon lar deg sette apekatter til å gjennomføre, men hvem vil egentlig jobbe sammen med apekatter (bortsett fra dyrepassere)?

Det finnes en rekke alternativer til den tradisjonelle kravspesifikasjonen når man skal lage programvare; de fleste har en ting til felles: tillit. Uten tillit mellom den som kjøper og den som leverer kan ikke engang den beste kravspesifikasjonen redde prosjektet. Og videre: om vi forutsetter et tillitsforhold mellom partene, trenger vi da den tradisjonelle kravspesfikasjonen?

En annerledes tilnærming

Jeg skal ikke gå i dybden på alternativene til kravspesifikasjonen her, det er antakelig mer enn nok stoff for en annen artikkel. Men en tidligere kollega av meg har skrevet en ganske annerledes måte å spesifisere et websystem som jeg synes var veldig interessant. Børre Austmann jobber i Human-Etisk Forbund (HEF), og ble for noen år siden med i en arbeidsgruppe for å utvikle et system HEF ønsket å lage for håndtering av deltakere i Humanistisk konfirmasjon og andre seremonier.

Etter å ha laget en omfattende og detaljert rapport til HEFs hovedstyre, fikk gruppen grønt lys for å gå videre, men samtidig signaler om at fremtidige innspill ikke måtte være så omfattende og detaljerte. Børre satte seg da ned og skrev et scenario fra år 2009 – altså noen år fram i tid – som beskrev hvordan noen oppdiktete personer forholdt seg til Humanistisk konfirmasjon.

Lene er 14 år, og har bestemt seg for Humanistisk konfirmasjon. Om påmeldingen beskriver scenariet blant annet:

I august åpner Lene på nytt nettsidene for å fylle ut påmeldingsskjemaet som hun finner på en link fra Grenland lokallags hjemmeside. Skjemaet er flersidig og oversiktlig. Første side er spørsmål om Lene – navn, fødselsdag, adresse, hennes mobil og epost, skole og klasse hun går i. Hun kan også velge om hun vil ha skjemaet på bokmål eller nynorsk. Hun velger bokmål. Språket i skjemaet og all korrespondanse vil være på det målføret hun har valgt.

HEF brukte dette scenariet som grunnlag til å innhente tilbud fra forskjellige leverandører, og fikk som tilbakemelding fra dem at dette var en spennende og annerledes måte å jobbe på.

Det elektroniske påmeldingsskjemaet kom allerede fire måneder senere. I dag melder nær 99% av konfirmantene seg til Humanistisk konfirmasjon på nett. HEFs ansatte i fylkene sparer til sammen massevis av timer i året på at manuelle prosesser er automatisert, timer de kan bruke på andre ting. Men det viktigste er kanskje at samarbeidet mellom HEF og leverandøren deres fortsatt er basert på tillit, og at begge parter er fornøyd med og stolt av det de har laget.

Scenario = brukerhistorier?

De som har jobbet med brukerhistorier kjenner dere kanskje igjen i denne måten å spesifisere på. Brukerhistorier er kjent fra smidig utvikling, og gir en måte for kunden å beskrive bruksområder av et system som skal lages. Extremeprogramming.com definerer blant annet brukerhistorier slik:

[User stories] are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.

I extreme programming bruker man brukerhistorier som grunnlag for akseptansetester, og er dermed en del av estimeringsprosessen: brukerhistorien konkretiseres i form av akseptansekriterier, som relativt entydig brukes for å oppnå enighet mellom kunden og leverandøren om at leveransen er ferdig. Scenariene som er beskrevet her er både lenger enn og har en mer litterær/emosjonell form og en lavere detaljeringsgrad enn en brukerhistorie.

Til slutt, siste avsnitt fra scenariet, der Lene (konfirmanten) og Reidar (fylkessekretæren) ser tilbake på seremonien:

Av kurslederen fikk hun en rose, en klem og kursbevis da hennes navn ble ropt opp. Rosa og klemmen sto det ingenting om i konfirmantbasen – men det var fra denne Reidar hadde kjørt ut kursbeviset hennes på fylkeskontorets skriver – rett fra nettet noen dager før, mens han sjøl løste sudokuen i Telemark Arbeiderblad.

Et case study i bruk av «sosiale medier» fra Norge

Publisert 23. november, 2009 av Karl Philip

På SEM-konferansen 2009 presenterte jeg hvordan valgprat.no gikk fra 0 til 17330 inngående lenker på 6 måneder (oppdatert 4. okt 2009 – last ned presentasjon) .

Valgprat-prosjektet er et eksempel på at Jack Welch sitt syn på strategi fungerer i praksis; «Velg en retning og implementer som et helvete». Jeg har tidligere skrevet et innlegg om hvordan Valgprat-ideen oppsto og hvordan Christian og jeg utviklet tjenesten på fritiden. Nå skal jeg fokusere på resultatene og hvordan vi promoterte valgprat.no i ulike (sosiale) medier.

Resultater

Det viktigste vi oppnådde med Valgprat.no var å bidra til å øke fokuset på politiske bloggere og gi politiske blogger flere lesere.

I tillegg oppnådde vi en rekke målbare resultater i valgperioden:

Mellom 5000 og 7000 besøk per dag.
Nesten 5000 innsamlede e-postadresser
399 registrerte politiske blogger organisert på parti
En rekke artikler i aviser og tidsskrifter
Bred omtale på politiske blogger
2249 «followers» på Twitter
Omtale på nettstedene til flere av de politiske partiene
Omtale på Stortingets nettsted

Brorparten av besøkene kom fra samarbeidet med Aftenposten, men e-post, Twitter, Facebook, Google og ulike politiske blogger bidro med besøk.

Til gjengjeld bidro Valgprat.no med en sterk økning i antall lesere til de 10 viktigste politiske bloggene (viktighetsgraden regnet ut med den hemmelige(!) Valgprat-algoritemen) i Norge:

Blogg	Antall klikk
1. Liberalen.no	14 581
2. Vampus.no	2 302
3. Jan Simonsen	50 013 (!)
4. Kjetil Løseth	0 (registrert sent i valget)
5. Vox Populi	1 088
6. Bård Vegar Solhjell	1 532
7. Tromp	1 318
8. Tore O.	2 212
9. Mali Steiro Tronsmoen	1 037
10. Heikki.no	978

I dette innlegget skal jeg løfte litt på lokket og fortelle litt hvordan vi bygde opp interessen rundt valgprat.no ved hjelp av ulike verktøy og metoder – uten markedsbudsjett. Jeg håper at våre erfaringer kan være nyttige for andre som ønsker å dra nytte av «sosiale medier».

1. Markedsføringen må være innbakt i produktet

De fleste markedsførere bommer stort når de definerer sin egen rolle i 2009. Mange tror at markedsføring handler om å fordele markedsbudsjettet på ulike markedsaktiviteter. Det er feil!

Markedsføring handler ikke først og fremst om reklame, det handler om å bygge markedsføringen inn i produktet og i hvilken grad man evner å spre ideene. Dette betyr at produktutviklere og designere har en stadig viktigere rolle når det gjelder markedsføring! Gode ideer må dyrkes frem ved å skape en bedriftskultur hvor det er lov å feile. Sosiale medier gjør det enklere å spre ideene.

I seg selv var Valgprat.no ikke annet enn en aggregeringstjeneste som gjorde det enklere å få oversikt over politiske blogger. Det var kombinasjonen av produktet og at noen få mennesker(johnei, cjno og philiplund) våget å implementere, som gjorde at ideen ble realisert og at ideen spredde seg(og at samtlige involverte byttet jobb eller tittel…). Uten Aftenposten så hadde Valgprat.no aldri fått noe signifikant oppmerksomhet. Uten Valgprat.no, så hadde politiske blogger aldri fått flere lesere under valget. Uten Valgprat.no så hadde Aftenposten vært nesten «usynlige» i sosiale medier. Poenget er at når det gjelder sosiale medier, så må man våge å feile. Man må se etter vinn-vinn scenarier og implementere som et helvete. Det er slik man bygger verdifull erfaringer som man kan dra nytte i fremtiden. Det finnes ingen eksperter på «sosiale medier».

Spørsmålet du må stille deg er: «Hva kan jeg gjøre med mitt produkt for å gjøre det mer interessant?»

2. Identifisér folk som er interessert

Når produktet/tjenesten er delvis definert og du har kommet igang, så flyttes fokus til å identifisere folk som er interessert. Du må bygge tillit og videreutvikle tjenesten ved å lytte og respondere. Spørsmålet du må stille deg: «Hvor finner jeg folk som er interessert i meg og mitt produkt?»

Noen steder er «no-brainere». Jeg jobber meg gjerne nedover listen.

Venner, gode kollegaer og bekjente er ofte interessert i det du driver med. Spør folk om hjelp. Informer dem med oppdateringer, men ikke overkommuniser (beklager til de som opplevde at jeg var litt for ivrig på twitter, facebook og linkedin når det gjaldt valgprat). Hvis ideene dine ikke får respons fra dine nærmeste, så vil du slite når du skal nå ukjente mennesker.
Folk som besøker nettstedet ditt vet hvem du er og er i utgangspunktet interessert. Sørg for å gjøre nettstedet ditt attraktivt og gjør det enkelt for folk å bruke og dele. Kutt bort unødvendig informasjon, gjør det enkelt å finne informasjon, bruk video og engasjer de besøkende.
Folk som søker i søkemotorene etter ord som er viktige for deg bør være viktig for deg. Hvis du ikke klarer å treffe de som aktivt søker etter deg, så vil du få problemer med å nå folk som leser avisen. Gjør alt du kan for å gjøre nettstedet og produktet ditt attraktivt for Google. I Valgprat-sammenheng jobbet vi aktivt med å få bloggere til å lenke til oss.
Interessegrupper som politiske partiene er interessert i politiske bloggere. Vi tok kontakt med informasjonsansvarlig i de ulike partiene og spurte dem om de hadde en oversikt over politiske bloggere fra sitt parti. Vi informerte dem ikke, vi spurte om hjelp. Folk flest er interessert i å bidra. Husk å vis takknemlighet fra folk som bidrar. Da får du ofte enda mer hjelp!
Journalister er stort sett interesserte i nye ting. Identifiser journalister som skriver om relevante temaer. Ta kontakt med dem, vis interesse for det de skriver om, ros dem for gode artikler, tips dem om relevante saker. Hjelp dem å gjøre jobben sin. Noen kaller dette PR. Jeg kaller det å vise interesse for andre.
Folk som prater om deg. Tidlig i valgkampen opprettet vi en Twitter-konto for å idenfisere folk som kunne være interesserte i politisk prat. Et naturlig startpunkt var å følge etter folk som fulgte etter politiske partier og kjente politkere. Å følge etter folk i stor skala er på kanten til å spam(det er en sperre på 2000), så man må trå meget varsomt. Når du følger etter en person på twitter, mottar personen en e-post fra twitter om at noen har blitt «follower» av dem. De fleste blir nysgjerrige og stikker innom profilen til de som følger etter en. Hvis de er interessert, så følger de etter din profil og du får et ekstra besøk på nettsiden din. Per 4.okt 2009, hadde Twitter-profilen til Valgprat ca. 2387 followers. Før og under valgkampen brukte vi Twitter flittig til å innhente kommentar, promotere ulike politiske bloggere og som en viral kanal i forbindelse med bloggvalget.

Hvis du ikke klarer å kommunisere med disse gruppene, så kan du glemme å kommunisere med folk som i utgangspunktet ikke er interessert! Det finnes en sjanse for at du oppnår målene dine uten å gjøre noe annet.

Spørsmålet du må stille deg: «Hvor finner jeg folk som er interessert i meg og mitt produkt?»

3. Lytt til «stammen» din

Når man har identifisert folk som er interessert, flyttes fokus over til å lytte og respondere. Alle nettsider har «en stamme» av mennesker som er interessert. Det er disse menneskene du må tilfredsstille og hjelpe – ikke massene. Det er ikke stammestørrelsen som teller, men kvaliteten på kommunikasjonen med stammen og din evne til å få folk til å spre ditt budskap på en effektiv måte.

Da vi lanserte første versjon av Valgprat.no, tok vi en ringerunde/e-postrunde til utvalgte bloggere. Vi fikk gode, kritiske tilbakemeldinger og gikk tilbake til tegnebrettet og gjorde en del endringer. Underveis i Valgkampen var vi svært opptatt av hva folk sa om valgprat og relaterte temaer. Vi deltok aktivt i diskusjonen både ved hjelp av Valgprat-bloggen og på de ulike politiske bloggene. Vi fulgte med hva folk sa om Valgprat.no på twitter og vi responderte etter beste evne. Vi svarte også på mange mail fra engasjerte politiske bloggere og vi har lært mye underveis.

Spørsmålet du må stille deg: «Hva sier de som bryr seg om bryr seg om din bedrift/produkt om deg?»

4. Bruk e-post aktivt – ikke Spam

Obamas presidentkampanje viste oss hvor viktig e-postinnsamling er i en vellykket internettstrategi. Helt fra starten av valgprat var vi opptatt av å samle inn e-postadresser – ikke for å spamme folk med irrelevant informasjon, men for å kunne forsiktig kommunisere relevant informasjon til folk som er interesserte. Balansegangen er vanskelig, men åpningsrate og klikkrate gir en indikasjon på hvorvidt du har beveget deg over grensen til spam. På slutten av presentasjonen fra SEM-konferansen kan du se eksempler på e-postutsendelse med klikkrate på over 90% (en av de siste slidene).

Vi samlet inn e-postadresser på valgprat før vi lanserte tjenesten. Vi sendte ut lanseringsmailer da vi lanserte tjenesten. I tillegg sendte vi ut en e-post med informasjon om samarbeidet med Aftenposten. Etter åpningen, krevde vi at alle som registrerte bloggene sine, måtte verifisere bloggen ved å oppgi e-postadressen sin. Dette gjorde vi, først og fremst for kvalitetssikre bloggene, men også for å kunne kommunisere relevant informasjon til alle norges politiske bloggere. Hvem vet hva dette betyr i neste valg?

Spørsmålene du må stille deg: «Hva er «de interesserte» interessert i å motta på mail? og «Hvor få e-poster kan du sende ut og allikevel nå målene dine?»

5. Andre teknikker og taktikker

Det er mye snakk om «sosiale medier» og nettstedeiere slenger ut «Del på Facebook» ikoner for deretter å si at de er aktive i «sosiale medier» . Det er helt greit å slenge ut ikoner, men det er ende viktigere å finne ut hva som får folk til å dele. Når du har funnet ut det, så er det essensielt å bruke teknikker som badger (Valgprat sin funker ikke i alle nettlesere), hendelsesutløste e-poster og «del på twitter/facebook» på en intelligent måte til å spre budskapet og til å tiltrekke lenker. Hendelseutløste handlinger er nøkkelen for å lykkes. Når folk aktivt utfører en handling, så må du sørge for at handlingen leder til at de gjør noe mer! «Involvement breads commitment» kalles det gjerne. Det trenger ikke å være mye, men led dem inn i en handling som bidrar til å spre budskapet. Facebook er geniale på dette området. Når du gjør noe i Facebook, så oppfordres du alltid til å gjøre noe mer som involverer vennene dine. Nå r

Mot slutten av valgkampen, lanserte vi bloggvalget. Ideen oppsto fordi vi ønsket å engasjere bloggerne og deres lesere i verdens første «bloggvalg». Dessverre kom vi sent i gang, så vi fikk ikke maks effekt av bloggvalget. Når en person hadde avgitt sin stemme, så takket vi, samtidig som vi oppfordret stemmegiveren til å fortelle sine venner på Twitter og på Facebook hvem de stemte på. Dessverre glemte vi å legge lenke til Bloggvalget de første 24 timene etter at vi startet valget. Det medførte at vi gikk glipp av den viktige virale effekten i begynnelsen av bloggvalget. 4000 stemmer er allikevel et helt OK resultat. For å unngå valgfusk, krevde vi at velgerne måtte bekrefte sin deltakelse ved å oppgi e-postadresser.

Topplister er også en teknikk som gir resultater. I Bloggvalget 2009, ga vi folk muligheten til å stemme frem sin favoritter blant politiske bloggere. Erling Folkvord vant forøvrig bloggvalget og vi gleder oss allerede til neste valg!

Spørsmålet du må stille deg: «Når en kunde har reagert i forhold til deg, hva kan du gjøre for å engasjere kunden litt til og hva skal til for å få kunden til å fortelle sine vener?»

Kilder og inspirasjon:

Purple Cow (Seth Godin)
Tribes (Seth Godin)
Winning (Jack Welch)
Getting Real (37 Signals)
The Warren Buffet Way (Robert Hagstrøm)

Skjemavalidering med JavaScript

Publisert 16. november, 2009 av Christian

Selvom du ikke er utvikler håper jeg at dette innlegget vil vise deg at skjemavalidering ikke trenger å være vanskelig å få på plass. Når du har lært det du trenger å vite om feilmeldinger, så kan du tipse utviklerne i ditt prosjekt om de mer tekniske aspektene ved feilmeldinger. Det er også konkrete eksempler nedover i inlegget som du kan prøve, så ikke la deg skremme av at du ikke kan JavaScript, det er veldig lite av det her.

Validatious – et JavaScript valideringsbibliotek

I dette innlegget viser jeg bruk av Validatious, et lite bibliotek for å validere skjemaer med JavaScript. Jeg skrev og slapp Validatious som et open source bibliotek i fjor etter å ha jobbet med skjemavalidering i en rekke prosjekter. Validatious kan brukes uavhengig av hvilket JavaScript-rammeverk du ellers bruker (det vil altså fungere med jQuery, Prototype og andre).

Validatious har funksjonalitet for å snappe opp valideringsregler fra klassenavn i HTML. Sammen med CSS for å style feilmeldinger og et lite script for å konfigurere oppførsel kan du komme langt selvom du ikke er noen JavaScript-ekspert.

Validatious gir mekanikken, ikke designet

Målet med Validatious var å samle logikken bak skjemavalidering på en plass, ikke å lage en ferdig pakke for feilmeldinger – hvordan disse skal kommuniseres er prosjektavhengig. Validatious gir deg ikke noe design og har ingen preferanser på hvordan skjemaene dine ser ut, så disse tingene trenger du fortsatt å bruke tid på å tenke ut. Validatious gjør det derimot enkelt å få på plass validering på klientsiden.

Et eksempel

Last ned Validatious og sett opp følgende testfil:



  
    
    Skjemavalidering med Validatious

Legg merke til det andre scriptet: Standard-feilmeldingene i Validatious er på engelsk, så vi må laste inn en egen fil med norske meldinger. Denne fila kan du hente her. Senere skal vi se hvordan vi kan ta bedre kontroll over feilmeldingene.

Med litt rask CSS ser dette skjemaet omtrent ut som dette:

Skjemaets utgangspunkt

Det er to måter å bruke Validatious til å validere skjemaer:

Ved å kode validering med JavaScript
Ved å legge til klassenavn og andre attributter i HTML-en for skjemaet

For de fleste brukstilfeller kan du lage en godt tilpasset løsning kun ved å endre på HTML-en din og skrive CSS for å style meldingene. Dette er strategien vi går for i dette innlegget. Det finnes en god del dokumentasjon av hvordan du kan gjøre disse tingene fra JavaScript på validatious.org.

Legg validering på et skjema

Følgende er et utsnitt av skjemaet jeg bruker som eksempel, det er stylet til å ligne registreringen til Yahoo! som ble fremhevet som best practice i Philips innlegg:


  Om deg
  
    
      Fornavn
      
    
    
      Etternavn
      
    
    
      E-post
      
    
  
  [SNIP]

Et relativt simpelt skjema. For å legge validering på dette skjemaet med Validatious er det to ting som må til:

Skjemaet må markeres som validerbart med class="validate"
Feltene må tilordnes valideringsregler via class-attributtet

I dette tilfellet ønsker vi at alle feltene skal være påkrevd, og vi ønsker å sjekke at e-post er en gyldig e-postadresse:


  Om deg
  
    
      Fornavn
      
    
    
      Etternavn
      
    
    
      E-post
      
    
  
  [SNIP]

Med disse enkle endringene får vi validert skjemaet når vi trykker på registrer-knappen. Som du kan se vises det her én feilmelding per felt som feiler (selvom e-post har to regler som ikke er tilfredsstilt):

Skjema med feilmeldinger

Prøv eksempel #1

Legg forøvrig merke til at dersom du sender inn skjemaet tomt så vil du få feil på samtlige felter. Om du nå legger litt tekst i eksempelvis fornavn-feltet og tabber videre til neste felt vil du legge merke til at Validatious rydder vekk feilmeldingen umiddelbart. Dette kan du skru av om du ikke liker det. Dersom du hopper videre til e-post-feltet og skriver inn en tekst som ikke er en gyldig e-post-adresse vil du se at feilmeldingen ikke forsvinner, men oppdateres når du går ut av feltet.

Litt bling, takk

Skjemaet har validering, det er vel og bra, men feilmeldingene ligner ikke på Yahoos feilmeldinger. Det kan vi fikse greit. Det er mulig å ta fullstendig kontroll over hvordan feilmeldinger legges inn i HTML-dokumentet, men for å sette deg igang har Validatious en standardløsning. Du kan bruke et verktøy som Firebug for å se hva Validatious gjør, men jeg kan også fortelle deg det:

div-elementet rundt felt som feiler merkes med klassenavnet
"error"
Først i div-elementet legges det til en ul med
klassen "messages"
Inne i ovenfornevnte ul legges feilmeldingene inn i hvert
sitt li-element

I utgangspunktet viser Validatious som sagt én feilmelding per felt, men det er mulig å be den om å sette inn et gitt antall, eller alle.

Vi kan sprite opp feilmeldingene med litt CSS:

/* Feilmeldinger */
.error {
    background: url(error_arrow_bg.gif) -50px 0 no-repeat;
    position: relative;
}

.error label span {
    background: url(smileyliamandroundedcorners_v5.png) no-repeat;
    background-position: -1px -120px;
    color: #c00e0c;
}

.error .messages {
    color: #c00e0c;
    list-style: none;
    left: 435px;
    margin: 0;
    position: absolute;
    top: 1px;
}

Dette er en litt rask hack som ikke er spesielt godt sjekka i mange browsere, men fungerer for å illustrere poenget. Denne gangen ser feilmeldingene litt stiligere ut, og det er ikke mye arbeid vi har lagt ned i dette:

Design på feilmeldinger

Lek med skjema #2

Litt positiv feedback, takk

Etter at brukeren har vært gjennom den prøvende opplevelsen det er å få kjeft av websiden vår kan det være hyggelig å backe opp med litt positiv feedback når et felt som har hatt feil blir rettet. På samme måte som et felt blir merket med klassenavnet "error" når det inneholder feil er det mulig å få et felt merket med klassenavnet "success" i det øyeblikket det rettes opp. Dette kan vi bruke til å gi brukeren et hint om at vi nå er fornøyd. For å gjøre dette må vi først gi Validatious et hint om klassenavnet vi ønsker:

Denne legges til etter script-elementet som inkluderer Validatious. Deretter legger vi til noen linjer CSS:

.success {
    background: url(checkbullet.gif) 320px 0 no-repeat;
}

En kjapp liten tweak som kanskje eller kanskje ikke er det du er ute etter:

Positiv feedback

Lek med skjema #3

Instant feedback, takk

I Yahoos skjema får du umiddelbar feedback når du gjør noe gæernt. Det kan vi få til også her ved å legge til en ny one-liner i script-blokken som konfigurerer Validatious (den vi nettopp innførte). Den skal se sånn ut:

v2.Field.prototype.instant = true;

Med denne på plass vil du få feedback etter hvert felt. Om feltet er OK får du en grønn hake ved siden av det, er det problemer får du beskjed om hva som er feilen.

Instant feedback

Lek med skjema #4.

Bedre feilmeldinger

Validatious tilbyr et sett med gode standardmeldinger, men standardmeldinger kan svært sjelden konkurrere med tilpassede feilmeldinger. La oss si at vi ikke var så fornøyde med feilmeldingen som dukker når vi taster inn en e-postadresse som ikke er gyldig. Vi kan da gi en bedre melding på to måter. Den enkleste er å gi input-elementet et title-attributt som gir en tilpasset melding:


  E-post

Med dette kan vi se at vår tilpassede feilmelding brukes i stedet for de innebygde meldingene. Lek med skjema. Hvorvidt dette er en god feilmelding er kanskje en annen diskusjon, men jeg er bare utvikler – vi vet ikke sånt.

Dersom vi bare ønsket å hjelpe Validatious med feltnavnet kan vi gjøre dette også. Standardmeldingen som genereres for manglende fornavn er «Fornavn er påkrevd». «Fornavn» snappes opp fra labelen foran feltet. Ved å gi denne et
title-attributt kan vi bruke et annet feltnavn i feilmelding enn det som vises i labelen:


  Fornavn

Lek med skjema.

Lær mer

Vi har sett basic bruk av Validatious, men den kan mer enn dette:

Sjekk at minst ett av en gruppe felter er fylt ut
Velg fra en samling ferdigbygde
valideringsregler
Valider komplekse
regler med JavaScript
Sørg for at kun enkelte knapper validerer skjemaet (ikke valider på
«tilbake»-knappen i en prosess o.l.)

Og masse mer. Sjekk validatious.org for mer informasjon eller ta kontakt om du har spørsmål og eller kommentarer (gjerne via kommentarene nedenfor).

Dersom det er interesse for det følger jeg gjerne opp med et nytt inlegg ved en senere anledning der jeg kan vise validering av mer komplekse skjemaer samt bruk av eksempelvis jQuery for å lage enda mer bling – type animerte feilmeldinger eller lignende.

Disclaimer: Skjemavalidering med JavaScript

Det er viktig å forstå at input av sikkerhetsgrunner alltid må verifiseres på serveren uavhengig om du også gjør det på klienten. Dette innlegget handler om å bedre interaksjonen i skjemaer i en webløsning ved å bruke JavaScript til å
validere input «on-the-fly». Formålet er å gjøre bruk av tjenesten din til en mer lystbetont øvelse, ikke validere input for sikkerhet.

En guide til feilmeldinger i webløsninger

Publisert 9. november, 2009 av Karl Philip

Allikevel glemmes feilmeldinger i de fleste webprosjekter. I dette innlegget skal beskrive prinsippene for gode feilmeldinger, samt vise relevante eksempler .

4 prinsipper for gode feilmeldinger:

Løs problemene før de oppstår
Fortell kunden på en høflig måte at det har skjedd noe feil
Fortell kunden hvor feilen har oppstått
Fortell kunden hvordan de kommer seg videre

1. Løs problemene før de oppstår

Hvis du klarer å identifisere potensielt farlige situasjoner i trafikken før de oppstår, så unngår du ulykker. Dette gjelder også på nett. Skjemaer bør lages på en måte som forhindrer kunden å gjøre feil. Gi brukeren visuelle hint på hva de skal legge inn i tekstboksene. Eksempler på slike visuelle hint er størrelsen på input bokser og knapper som «deaktiviseres» når noen klikker på dem for å unngå dobbeltklikking. I tillegg kan hjelpetekster ved siden av input bokser eller i tilknytning til «action knapper» gjøre susen.

I eksempelet nedenfor ser du hvordan Storebrand forhindrer brukeren i å bestille forsikring hvis de ikke er kvalifisert til å tegne forsikring. Storebrand behandler stort sett på en utmerket måte(noen dårlige unntak finnes hos Storebrand).

Storebrand svarer på relevante spørsmål i skjemaet

Eksempel 1: God håndtering. Se hjelpetekstene. Hentet fra Storebrand.no

En av mine største tabber da jeg jobbet i Norwegian var avgjørelsen knyttet til brukernavn/passord. I eksempelet nedenfor er det ekstremt vanskelig å vite hva Norwegian legger i «brukernavn-begrepet». For de av oss som jobbet med bestillingsløsningen i 2004, så vet vi at brukernavn hos Norwegian alltid er e-postadresse for personer som registrerte seg etter oktober 2004. Istedenfor å tvinge folk til å bruke «glemt brukernavn-lenken», så bør Norwegian heller løse problemet før det oppstår!

Hva er et brukernavn hos Norwegian?

Eksempel 2: Dårlig håndtering. Hva er "brukernavn"? Hentet fra Norwegian.no

2. Fortell kunden at det har skjedd noe feil

Hvis en feil oppstår, så må du på en høflig og forsiktig måte fortelle kunden at en feil har oppstått. Ikke skrem kunden med skumle feilmeldinger og ikke legg skylden på kunden. Norwegian forteller kunden at en feil har oppstått øverst på siden når man har glemt å fylle ut påkrevd information (selv om jeg er noe usikker på hvilke felter som er påkrevd. Noen felter er tomme og hvite). Når en feil oppstår, så hjelper det også hvis markøren automatisk går til feltet hvor det kreves en endring.

Tydelig oversikt over feil fra Norwegian

Eksempel 3: God håndtering. Høflig melding om at en feil har oppstått. Hentet fra Norwegian.no

Hos Expert, så er det vanskelig å se at det har oppstått en feil med mindre man ser nederst i skjemaet og legger merke til den lille ekstra rammen rundt feltet der feilen oppstår.

Har det skjedd noe feil hos Expert?

Eksempel 4: Dårlig håndtering. Har det oppstått en feil? Hentet fra Expert.no

3. Fortell kunden hvor feilen har oppstått

Yahoo er dyktige på feilmeldinger og skjemaene deres kan i mange tilfeller regnes som best practice. I eksempelet nedenfor ser du at Yahoo forteller brukeren når noe er riktig utfylt (grønn markør) og når noe er galt(rød markør). De viser hvor hver feil er, og hvorfor feilen har oppstått.

Best practice fra Yahoo!

Eksempel 5: God håndtering. Det er tydelig hvor feilene har oppstått. Hentet fra Yahoo.no

Haugenbok har solgt mye bøker opp gjennom tidene, men de bryter mot prinsipp 3. De forteller brukeren at en feil har oppstått, men det er ingen visuelle hint i selve skjemaet om hvor feilen har hendt.

Ingen visuelle signaler i skjemaet hos Haugenbok

Eksempel 6: Dårlig håndtering. Det har skjedd en feil, men det finnes ingen visuelle hint på hvor feilen har oppstått. Hentet fra Haugenbok

4. Fortell kunden hvordan de kommer seg videre

Eksempelet nedenfor er i overkant «rødt», men Lands’ End forteller tydelig at noe har skjedd, hvor feilene har skjedd og hva kunden må gjøre for å komme videre. I tillegg tilbyr Landsend online chat og en Call me funksjon. Undersøkelser viser at 76% ønsker å chatte når problemer oppstår i en bestillingsprosess, hvorfor ikke tilby kunden litt chattehjelp før de blir frustrerte?

Genialt fra Landsend

Eksempel 3. Høflige meldinger og online chat. Hentet fra Landsend.com

Hvem har ansvaret for gode feilmeldinger?

Feilmeldinger er et delt ansvar. Designeren må designe dem, utvikler må implementere dem og prosjektleder/prosjekteier må sørge for at feilmeldingene blir implementert korrekt. I tillegg må noen som ser helhetsbildet, skrive kundevennlige og forstålige tekster. Hvis ingen stiller krav, så blir feilmeldinger glemt. Det har jeg erfart i flere prosjekter. Jeg oppfordrer derfor folk til å stille krav. Ta ansvar – gjør noe med det!

Fremtiden & avanserte verktøy

I fremtiden ser jeg for meg at smarte webskjemaer også vil inkludere lyd og bilde på samme måte som feilmeldinger i bilen varsles med en lampe som lyser og en pipelyd. I det øyeblikket et problem oppstår vil bedrifter kunne velge mellom en rekke hjelpemidler, f.eks. automatisk oppkobling mot telefon eller chat. Evt. kan man velge å vise en kort introduksjonsvideo av hvordan man kan løse feilen.

På webanalyse-fronten finnes en rekke verktøy som gjør det enkelt å forbedre både skjemaer og feilmeldinger. De mest kjente er Tealeaf, Clicktale og Userfly. Disse verktøyene gjør det mulig å se hvordan kunder faktisk fyller ut skjemaer og hvordan feil oppstår. Med disse verktøyene dukker også personvern diskusjonen opp. I hvilken grad bør det være lov å overvåke kunders atferd på nettet?