Lenker stilet som knapper #2008
-
Det er et gjentagende mønster at man stiler lenker som knapper. Jeg ser for meg at dette kan komme av flere ting:
Definisjoner
Eksempel på dette er https://runer.fremtind.io/ hvor det nesten ikke finnes lenker, og alle knapper egentlig er lenker. I designet gir det mening at disse er knapper, og det er kun av tekniske årsaker at disse oppfører seg som lenker. Et annet eksempel fra BM sine løsninger er f.eks. tilganger, hvor man på siden får knapper for å legge til tilganger. Dette er egentlig lenker, som leder til en annen side som håndterer skjemaet. Utfordringene dette kan skape er at oppførselen for en knapp og en lenke er forskjellige. Eksempelvis kan man trykke på en knapp med "space", mens på en lenke må man bruke "enter". Dette kan skape problemer for brukere som avhenger av tastaturnavigasjon og forventer en oppførsel basert på utseende. Jeg ser for meg flere måter å angripe denne problemstillingen:
2 og 3 underbygger tankegangen om at vi fristiller elementer som Her ønsker jeg input fra både designere og utviklere. Både for hvordan dette passer i designspråket, det tekniske, men også hvordan vi kan bli bedre på å bestemme hva som skal være en lenke eller en knapp. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
Jeg synes 2 er det mest fornuftige alternativet, siden jeg også synes at man skal unngå å normalisere dette mønsteret for mye (så 1,5? 😅). Jeg mener mønstret kan ha god verdi som en løsning på casen "call to action som tar deg til en ny side," men jo mer man vanner ut forskjellen mellom knapp og lenke jo større er sjansene for at det vil skape dårlige brukeropplevelser, siden elementene oppfører seg forskjellig. Om man skal ha en egen komponent bør den ha meget klare retningslinjer for når den skal brukes. Hvis det føles naturlig i design å bruke en knapp er det kanskje en god anledning til å tenke over om det kan være en knapp i kode? Hvorfor oppfattes dette som en handling? Hvorfor oppfattes noe annet som en lenke? Hvorfor er det eventuelt noe annet i kode, og trenger det å være det? Er det et teknisk valg som gjør at det oppfører seg som en lenke, eller er det en teknisk nødvendighet?
Dette er strengt tatt en hack 🤓 Hash i adressen betyr i utgangspunktet at man navigerer til et annet sted på siden, men det kan brukes av javascript-verktøy til å endre innholdet på siden i stedet. tl;dr: Det er relativt få steder dette mønsteret trengs, men i de tilfellene bør det være greit. Man bør imidlertid ikke gjøre det så lett å velge mønsteret at det blir brukt steder der en faktisk knapp (eller lenke stylet som lenke) kunne vært brukt i stedet. |
Beta Was this translation helpful? Give feedback.
-
Fra interaksjonsdesign-perspektiv: Knapper er verb, lenker er substantiv. Knappeformen (sammen med knappetekst) forteller deg at du kan gjennomføre en handling, mens lenker og andre navigasjonselementer vil ta deg til et sted (hvor det finnes mer å lese og kanskje flere handlinger å ta stilling til). Noen calls-to-action, eks. "start sparing nå!" -> side som informerer deg om ulike sparemuligheter, er egentlig misbruk av disse konvensjonene. Men i de fleste tilfeller så blir knappe-stilen brukt helt riktig. Det er slik vi typisk bruker knapper vs. lenker i Fremtind-applikasjoner, og også relativt typisk for andre nettsider og apper. Jeg ser utfordringen i å forene dette med semantisk HTML, hvor BUTTON-elementet først og fremst er noe som opptrer i kontekst av FORM (skjema) og A-elementet er ... en veldig stor bøtte av mening. Jeg syns både alternativ 2 og 3 funker bra til å bygge bro mellom semantikken i det visuelle språket og semantikken til HTML. |
Beta Was this translation helpful? Give feedback.
-
Løsning 2 viste seg bli et behov for meg her tidligere, så laget #2272 og tenker løse det nå på kort sikt. Tenker det er en fin balanse å bare utvide klassen med riktig reset, men ellers ikke legge mer til rette for det i APIet f. eks. til |
Beta Was this translation helpful? Give feedback.
Løsning 2 viste seg bli et behov for meg her tidligere, så laget #2272 og tenker løse det nå på kort sikt. Tenker det er en fin balanse å bare utvide klassen med riktig reset, men ellers ikke legge mer til rette for det i APIet f. eks. til
<Button />
.