Skifte beite? Gresset er grønnere hos oss
Sammen sprenger vi grenser for hva web kan være. Vi ser spesielt etter: Tekstforfattere, prosjektledere, designere og interaksjonsdesignere.
Ikke kast ut kundene dine med dårlig skjemadesign 4
Her om dagen skulle jeg bestille meg et hotellrom for konferansen Eye-tracking to evaluate User experience, i Frankfurt (desverre ingen nettside). Jeg pekte nettleseren på hotels.com, fant et fint hotell til en bra pris og forsøkte å booke rommet mitt. Alt så strålende ut, men:
Etternavnet mitt er kort, bare tre bokstaver, men det er faktisk det jeg heter. I tillegg har man ca 210 millioner mennesker som heter Li og enda flere som har to- til trebokstavers etternavn.
Heldigvis for hotels.com er ikke Bruce Lee blant oss lengre, for dette ville han mest sannsynligvis tatt tak i.
Skjemaet sjekker også om det finnes æ, ø eller å i adressen, slik at mine venner som bor i Bøgata heller ikke vil kunne bestille hotellrom.
Skjemavalidering er en fin ting, men det må brukes med fornuft. I tilfellet over går hotels.com garantert glipp av mange kunder hver eneste dag, fordi skjemavalideringen ikke holder mål. Her er noen tips for hva man bør tenke på i forbindelse med skjemautforming og validering.
- Hvilke felt skal være obligatoriske? En del skjemaer har satt alle felt som obligatoriske – er dette egentlig nødvendig? Hvilken informasjon er du avhengig av å få fra brukerne dine? Et eksempel kan være telefonnummer – noen skjemaer har felt for hjemmetelefon, mobiltelefon og jobbtelefon. For min del er det bare mobiltelefon som er aktuelt å fylle ut, og så lenge man bare får ett nummer inn i systemene sine bør vel det være tilstrekkelig?
- Kan dataene som fylles ut ha forskjellige formater? Kontonummer kan for eksempel skrives på flere måter; enten som 1234.12.12345 eller som 12341212345. Hva med å bygge en validering som aksepterer begge deler?
- Aksepter ulike språk og bokstaver! For hotels.com er tydeligvis æ, ø og å ikke godkjente data. Dette er pussig.
- Tillat mellomrom! Jeg har sett flere eksempler på at et mellomrom i et felt gjør at valideringen ikke blir godkjent. For eksempel vil “1.4.2007 ” være ugyldig, mens “1.4.2007″ er gyldig. Dette er umulig for en bruker å se fordi mellomrommene er usynlige.
Dreyer Media, 12.03.2007 12:51
Dette har forsåvidt vært et problem i mange år, og jeg skjønner virkelig ikke hva folk tenker når dem lager slike skjemaer.
En ting er å lage et skjema som har mer eller mindre null validering. Det er ille, men det er i det minste brukervennlig for forbrukeren. En annen ting er å lage et skjema som validerer etter dine egne vaner. F.eks som du nevner, hvordan kontonummeret skrives.
Mange skriver mobilnummer slik: 12345678. Andre skriver det slik: 123 45 678! Hvordan kan det sies at en av dem er feil?
Mitt tips til webutviklere. Jobb hardere med skjemaene deres. Og det er sjeldent mer enn en engangsjobb, for har du først laget det en gang kan du lage deg et lite bibliotek å bruke det opp igjen!
Asbjørn Ulsberg, 13.03.2007 10:08
Jo Å hadde vel fått litt problemer med dette skjemaet. Ikke at noen heter dét i Norge, men noen kan hete det, og det må utviklerne ta hensyn til.
TD, 26.03.2007 02:51
Alt for mange utviklere setter grenser som de selv synes er fornuftige (eller ikke), når de egentlig burde sette grenser som reflekterer hva systemet takler eller trenger for å fungere optimalt.
Noen setter til og med grenser i databasen for hvor mange tegn et felt kan inneholde. Dette er tull. Hva vet vel vi om ingen i verden har et navn som er lenger enn 50 tegn? De som tror det burde ta en tur til Portugal. Visst nok var dette nødvendig før i tiden for å spare plass, men det er den minste bekymringen for en utvikler nå til dags.
Pingback: → En guide til feilmeldinger i webløsninger – Stammen.no