Er svevetilstander nødvendige?

Jeg stemmer «ja»! Det er sant at svevende hendelser ikke burde være avhengig av fordi berøringsenheter er så populære. Imidlertid ser Jon ut til å spørre om visuelle svevstilstander på knappene, noe som er litt annerledes.

Visuelle hover-stater har råd til «clickablity» . Du trenger ikke å klikke på noe for å finne ut hvis det er en knapp. Brukere på bærbare datamaskiner og stasjonære datamaskiner forventer at «klikkbare» ting skal reagere mens du holder musepekeren, og å ha en knapp «lyser opp» er en nyttig ledetråd.

Tenk på det som en form for progressiv forbedring . Det er nyttig for de som kan bruke det, og ufarlig for de som ikke kan!

Kommentarer

• Jeg ‘ vil faktisk si at på et skrivebord i surfemiljø, kan brukeren nesten tro at det er noe galt hvis ingenting annet enn markøren endres – vi har blitt så vant til å sveve endringene.
• Det var mitt sterkeste argument / tanke. Vi ‘ har blitt så vant til at det ‘ ville være rart å ikke ha det.
• Bra poeng på progressiv forbedring. Jeg ‘ d legger til en ting til "You shouldn't have to click something to find out if it's a button." skjønt; du bør ikke ‘ t må sveve over noe for å finne ut om det ‘ sa-knappen.
• Jeg vil også si at å legge til visuelle hover-tilstander på knappene gir brukeren positiv tilbakemelding for sin handling eller en følelse av en mental pris.
• Etter å ha gått fra Windows 7 som stod sterkt på hover-stater og brukte ofte omriss eller paneler for å indikere knapper, til Windows 8, som ofte ikke gjør verken i » Metro » stilgrensesnitt, jeg ‘ har funnet Win 8 utrolig frustrerende å bruke til tider. Det kan være det MS vil at designere skal kode for Win 8, men IMX det ‘ er tydelig feil å gjøre det.

Jeg prøver å unngå svevende tilstander i design så mye som mulig. Den primære grunnen til det er at de er meningsløse på berøringsenheter.

Selv om dette kan virke som om det ikke gjelder når du ikke designer for mobil, bruker mange nettbrettene eller andre berøringsenheter til å bla gjennom de samme nettstedene eller bruk de samme applikasjonene som du tradisjonelt bare bruker på en datamaskin med en mus.

Ved å begrense deg selv for ikke å bruke svevende hendelser, gjør du ikke bare opplevelsen god uansett hvilken enhet du bruker, men du gjør det også lettere å lage et berøringsspesifikt innfødt program senere.

Kommentarer

• Hover-tilstander er fremdeles nyttige på mobile nettsteder. CSS :hover blir effektivt behandlet som :active når det vises på en mobil enhet. Dette gir visuell tilbakemelding om at brukeren ‘ s finger traff målet. Denne tilbakemeldingen er mye mer nyttig på mobildesign på grunn av parallaks. Når synsfeltet ditt avviker fra den vinkelrette linjen til skjermen, øker sjansene for feil trykk.
• @JoJo hover states er ikke ‘ t som kan oppdages på mobil , og tapping tilsvarer å klikke på en datamaskin.
• John, etter min erfaring med å se på nettsteder som jeg ‘ har designet for stasjonære datamaskiner, tror jeg at JoJo har rett i å si at svevetilstanden [noen ganger] fungerer som den aktive tilstanden. Jeg sier noen ganger fordi det ‘ er litt fink og ikke alltid ‘.
• @Jon I ‘ Jeg krangler ikke om hvordan det oversettes, jeg ‘ diskuterer hvordan det er fornuftig å oversette. Hvis svever blir aktiv, hvordan velger du? Dobbeltklikk? Det bryter hele berøringsparadigmet.
• @JoJo ikke alltid, jeg tror ikke ‘ Jeg tror ikke at Chrome på Android utløser svevetilstanden, og Safari ‘ s svevetilstand er ofte vanskelig

Med fremveksten av berøring er en viktig måte å samhandle med programvare på, jeg vil si at svevebaserte interaksjoner nå er henvist til «hyggelig å ha forbedringer», men det burde aldri være et krav å samhandle med programvaren.

Jeg dupliserer ofte tilstanden: sveve for: fokus, da dette er en nyttig måte å indikere fokus for en tastatur bare bruker (som kreves for å oppfylle WCAG2 Det indikerer at et element er interaktivt på en eller annen måte uten å måtte ha en klikkhendelse som vil utløse en handling brukeren ikke har bestemt seg for å starte ennå. Du kan bare style for: fokus uten: sveve, men etter min mening er intensjonen med de to handlingene den samme og skal ha samme visuelle effekt der det er praktisk.

Jeg er også enig i Sams synspunkt at hover-tilstander kan betraktes som progressiv forbedring . Jeg vil bare presisere det litt.

Fra et mobil først perspektiv svinger stater ikke egentlig noe formål. Så brukergrensesnittet hadde bedre råd til klikkbare oppførsel for klikkbare objekter uten svevende tilstand (dvs. knappene skal se ut som knapper).

Hvis du kan støtte dette begrepet på en mobilenhet, vil det samme begrepet bli støttet på stasjonære / bærbare enheter også før sveverstatusene blir introdusert.

Inkludert en svevertilstand på enheter som støtter svever – bærbare datamaskiner, stasjonære datamaskiner osv. – vil bekrefte brukerens allerede eksisterende oppfatning om at et spesifikt brukergrensesnittelement faktisk er klikkbart.

Så, for å oppsummere:

1. Bygg brukergrensesnittelementer som er klikkbare slik at de har klikkbar oppførsel for alle enheter.
2. Bruk svevstilstander på enheter som støtter svever til støtter ytterligere forestillingen om at et element er klikkbart.

+1 til Sam for å nevne progressiv forbedring.

Jeg vil anbefale å bruke hover-tilstander hvis de gir noe brukbarhet som forbedrer brukergrensesnittet, men de burde aldri være nødvendige for å fullføre en oppgave.

For eksempel ved å bruke dem på en produktlisteside for å gi litt informasjon om varen når du svever over bildet, før brukeren navigerer over. Denne informasjonen bør da også være tilgjengelig på selve produktsiden. ødelegger ikke opplevelse av berøringsskjermbrukeren, men gir litt ekstra nytte for de som ser . 🙂

Bare fordi du designer for både stasjonær og mobil betyr ikke designen samme. Interaksjon som mobilbrukere kan være vant til, er kanskje ikke tydelig for stasjonære brukere.

For eksempel hvite kort med et oppsett på høyre side. For mobilbrukere er dette åpenbart noe du kan trykke på. For stasjonære brukere, ikke så mye (spesielt hvis kortet er bredere på skrivebordet), men når de holder markøren og ser en svevetilstand, er det plutselig åpenbart at det kan klikkes.

Spesielt nå som animasjonen blir mer og mer vanlig, en svevetilstand er en grunnleggende animasjon som gir brukerne tilbakemeldinger om at de gjør det de hadde tenkt å gjøre.

Å ikke bruke en svevetilstand til skrivebordet er lat og gjør folk triste.

Jeg tror ikke :hover tilstander er essensielle; UI-elementer på skrivebordet har klart seg uten dem for alltid, og objekter som er tydelig designet for å ha råd til å klikke (for eksempel «Legg ut svaret ditt» -knappen her på UX.SE) tester fint etter min egen erfaring. Det «for ikke å si det» er ikke nyttig ; bare at det ikke er viktig.

Jeg gjør det, men vurder :focus og spesielt :active sier viktig; sistnevnte er spesielt en som jeg ser ignorert på altfor mange nettsteder. En klar aktiv tilstand hjelper brukeren å vite at knappeklikket ble registrert umiddelbart ( som er ekstremt viktig for å hjelpe brukerne til å føle at de manipulerer direkte et objekt i brukergrensesnittet ). Systemkontroller som knapper og menyer har alle gjort den tilstanden også forventet, noe som gjør glemmen enda mer utilgivelig.

Jeg vil foreslå at svingtilstander gir positiv tilbakemelding til brukerens forventning om at det aktuelle elementet er interaktivt, og dermed fjerner potensialet for mer negative følelser av tvil og tvetydighet. .

Designs leverer et antall signaler om at et element er interaktivt – form, størrelse, posisjon, farge, en understreking osv. Ulike brukere vil ha forskjellige signaler s, og kanskje den kumulative effekten av et annet antall signaler, å oppfatte (og være trygg på at) elementet er interaktivt. Å endre et element på sveve er en mulighet til å levere flere signaler.

De fleste (hvis ikke alle) nettlesere leverer pekepinner på svev som standard ved å endre markør til en peker. Selvfølgelig har vi kontroll over dette og kan fjerne svevetilstanden ved å fjerne denne effekten. Men jeg forestiller meg at for de fleste av oss (ta et øyeblikk å forestille seg det) vil dette introdusere betydelig tvil i vår nettleseropplevelse. Nettlesere (og deretter designere) har satt en slik presedens for ytterligere signaler på sveve at ikke å levere signaler ville være en betydelig motsigelse til tidligere antatte signaler om at elementet er interaktivt.

Fjerning av nettleserens standard cue er dermed et nyttig eksempel på verdien av svevetilstand. For meg blir spørsmålet ikke om visuelle signaler om interaktivitet på svever er verdifulle, men hvilke og hvor mange signaler som er optimale.

Det er noen nyttige kjente presedenser, men svaret på dette spørsmålet vil avhenge av applikasjonen og målgruppen.

Jeg vil foreslå sveve når det ikke er noe ikon i knappen. Hvis antar at det er et ikon fargerikt i knappen den gangen, er det ikke viktig å gi svevetilstand til knappen. Eks: registrer deg ved hjelp av Google-knappen.

Hover er et must for alle nettsteder som ønsker god respons på nettet. Jeg har brukt noen nettsteder som droppet hover-statusen på den bærbare datamaskinen min, og det var veldig frustrerende.Enhver god designer vet at folk på nett er i et rush for å finne det de vil ha, og om en knapp ikke vil fortelle deg om den er en eller ikke, og du må åpne den i en ny fane for å finne ut – det er en stor feil!

Riktig, svever er ikke nødvendig for mobil. Men du kan alltid deaktivere dem for mobil. Dessuten, la oss ikke glemme at knappene for mobil trenger å være mye større enn knappene på nettet. Og opprettet de ikke på to forskjellige stilark uansett?

Kommentarer

• For nettsteder som bytter markørstil til en hånd (eller tilsvarende), er den sveveeffekten jeg handler på.
• Jeg tror det fortsatt må vises svevende, bare en hånd forvirrer brukeren, ettersom vi vil at nettet skal fungere så naturtro som mulig, og når vi klikker på ting hvis det virkelige livet – de gjenspeiler. Fra et strateg ‘ synspunkt, vil du også at nettstedet ditt skal føles tryggere og det ‘ er at de fleste svindelnettsteder bryr seg ikke ‘ t å installere hover-effekten – derfor når brukere ikke ‘ ikke ser effekten de begynner å føle seg rare inni.