Vi diskuterer i UX-afdelingen her på arbejdspladsen om, hvorvidt svævende stater er nødvendige for et brugergrænseflade. Vi er lidt opdelt . Her er de to argumenter:

Mod (startede diskussionen):

Jeg har personligt haft en tilbøjelighed til ikke at have svævertilstande … for mig, det tilføjer visuel støj uden virkelig nogen fordel undtagen under meget begrænsede omstændigheder. Kommer fra mobilverdenen, er der ikke sådan noget som en rollover-tilstand, og jeg har aldrig gået glip af dette eller ønsket, at det er tilgængeligt for basale artikler. PC-software brugte ikke rollovers, men jeg testede bare det, og jeg ser, at de nu bruges stærkt. Men jeg slog op nogle Mac YouTube Lion-videoer, og de ser ikke ud til at bruge svævende tilstande.

For (første svar):

Det korte svar er, ja, vi skal have svævetilstand på hver knap i vores grænseflade. Og jeg udvider det typisk til alt klikbart (listebokselementer, links (selvom det kommer gratis) og andre brugerdefinerede elementer som whiteboard-noder eller tabelceller). Jeg vil også børste på ideen og vil typisk tvinge svævende stater til at blive tilføjet, hvis de ikke allerede er.

Det er sjovt, fordi det bare er noget, der er så standard nu, at det aldrig bliver sat spørgsmålstegn ved. De fleste undersøgelser, jeg kan grave op, har at gøre med, hvad den rigtige svæverbehandling er, snarere end at teste, om svæver skal bruges. Du har ret i, at det ikke blev brugt tidligere, men det var mere en UI-teknologimangel. Det er bestemt muligt, at brugerne bare forventer det, og så teknikken er blevet et de facto krav. Desuden har ikke at have svæve tendens til at komme på tværs som forældet. Af disse grunde kombineret med det faktum, at jeg ikke tror, at svævende tilstande har nogen negativ indvirkning på anvendelighed, er det derfor, jeg vil sige, at vi altid skal bruge svæve.

Jeg er ikke sikker på, at jeg helt kan se den visuelle støjkomponent. Jeg skubber altid designere til at gøre svævninger meget subtile (som 60-80% af den valgte tilstand). Når de er gjort korrekt, giver de visuel feedback til brugeren om, at kontrollen gør noget. Det hjælper også grænsefladen med at kommunikere med brugeren – det er som om det fortæller brugeren, at applikationen lytter.

Her er min tilføjelse til samtalen (jeg er pro hover stater):

Jeg synes, der er en iboende nødvendighed af svævende tilstande på især ikke-traditionelle brugergrænsefladeelementer. Med sendeknapper, links og listeelementer tror jeg, at der er en forventning og antagelse om, at de kan klikkes. Andre ting som lærred / trækbare elementer er ikke “naturlige” UI-elementer, så brugerne ville ikke nødvendigvis vide, at der er underliggende handlinger forbundet med disse objekter.

Markørændringer (skifter fra normal til markør) er nok af en identifikator for mig at vide, at noget er klikbart, men de fleste mennesker forstår ikke denne skelnen. Det er ikke visuelt nok, fordi det er en subtil ændring i form. Medmindre du er nulstillet på pilehovedet, vil du næppe Vær opmærksom på det.

Hover-stater tilbyder på den anden side højere visuel stimulering, fordi [jeg vil hævde, at] hjernen naturligt reagerer på ændringer i farve hurtigere end den gør på ændringer i form.

Jeg vil gerne høre alles meninger med hensyn til svævende stater. Bruger du dem? Hvornår finder du dem nødvendige? Eller er de bare visuel støj?

Kommentarer

  • Hvilken slags indhold diskuterer du om at medtage i disse svævertilstande? Bare visuel feedback fra svæveflyet? Værktøjstip, eller ønsker du at medtage faktisk hardt dataindhold, som du ikke ville ‘ ikke kunne få adgang til på andre måder?
  • Bare den visuelle feedback generelt.

Svar

Jeg stemmer “ja”! Det er sandt, at svæve begivenheder ikke burde være afhængig af, fordi berøringsenheder er så populære. Imidlertid ser Jon ud til at spørge om visuelle svævertilstande på knapper, hvilket er lidt anderledes.

Visuelle svævertilstande har råd til “clickablity” . Du behøver ikke at klikke på noget for at finde ud af det hvis det er “en knap. Brugere på bærbare computere og desktops forventer, at” klikbare “ting reagerer på svævningen, og at have en knap” lyser op “er et nyttigt spor.

Tænk på det som en form for progressiv forbedring . Det er nyttigt for dem, der kan bruge det og uskadeligt for dem, der ikke kan!

Kommentarer

  • Faktisk går jeg ‘ så langt som at sige det på et skrivebord i browsermiljø, kan brugeren næsten tro, at der er noget galt, hvis intet andet end markøren ændres – vi er blevet så vant til at holde markøren over ændringer.
  • Det var mit stærkeste argument / tanke. Vi ‘ er blevet så vant til, at det ‘ ville være underligt at ikke have det.
  • Godt punkt om progressiv forbedring. Jeg ‘ tilføjer dog en ting til "You shouldn't have to click something to find out if it's a button." dog; du skal ikke ‘ ikke skal holde markøren over noget for at finde ud af, om det ‘ en knap.
  • Jeg vil også sige, at tilføjelse af visuelle svævertilstande på knapper giver brugeren positiv feedback for sin handling eller en følelse af en mental pris.
  • Efter at være gået fra Windows 7, der var stærkt afhængig af svævertilstande og brugte ofte konturer eller paneler til at angive knapper til Windows 8, som ofte ikke hverken i ” Metro ” stilgrænseflade, jeg ‘ har fundet Win 8 utrolig frustrerende at bruge til tider. Det kan være, hvad MS vil have designere til at kode for Win 8, men IMX er det ‘ klart forkert at gøre det.

Svar

Jeg prøver at undgå svævende tilstande i design så meget som muligt. Den primære årsag til det er, at de er meningsløse på berøringsenheder.

Selvom dette kan virke som om det ikke gælder, når du ikke designer til mobil, bruger mange deres tablets eller andre berøringsenheder til gennemse de samme websteder eller brug de samme applikationer, som du traditionelt kun bruger på en computer med en mus.

Ved at begrænse dig selv for ikke at bruge svævende begivenheder, gør du ikke kun oplevelsen god uanset hvilken enhed du bruger, men du gør det også lettere at oprette en berøringsspecifik indfødt applikation senere.

Kommentarer

  • Hover-tilstande er stadig nyttige på mobile websteder. CSS :hover behandles effektivt som :active når det vises på en mobilenhed. Dette giver visuel feedback om, at brugerens ‘ finger rammer målet. Denne feedback er meget mere nyttig på mobildesign på grund af parallax. Når din synsfelt afviger fra den vinkelrette linje til skærmen, øges chancerne for forkert tapning.
  • @JoJo svæver stater er ikke ‘ kan ikke findes på mobil , og aflytning svarer til at klikke på en computer.
  • John, i min erfaring med at se websteder, som jeg ‘ har designet til desktop på mobil, tror jeg, at JoJo har ret i at sige, at svævertilstanden [undertiden] fungerer som den aktive tilstand. Jeg siger nogle gange, fordi det ‘ er lidt finicky og ikke ‘ ikke altid vises.
  • @Jon I ‘ Jeg argumenterer ikke for, hvordan det oversættes, jeg ‘ argumenterer for, hvordan det giver mening at oversætte. Hvis svæver bliver aktiv, hvordan vælger du? Dobbeltklik? Det bryder hele berøringsparadigmet.
  • @JoJo ikke altid, jeg ‘ tror ikke, at Chrome på Android overhovedet affyrer svævetilstanden, og Safari ‘ s svævende tilstand er ofte akavet

Svar

Med fremkomsten af touch er en vigtig måde at interagere med software på, jeg vil sige, at svæverbaserede interaktioner nu henvises til “rart at have forbedringer”, men det burde aldrig være et krav om at interagere med softwaren.

Svar

Jeg kopierer ofte tilstanden: svæver for: fokus, da dette er en nyttig måde at angive fokus for en bruger til kun tastaturet (som kræves for at opfylde WCAG2 Det angiver, at et element er interaktivt på en eller anden måde uden behov for en klikhændelse, der vil udløse en handling, som brugeren ikke har besluttet at starte endnu. Du kan bare style til: fokus uden: svæv, men efter min mening er hensigten med de to handlinger den samme og skal have den samme visuelle effekt, hvor det er praktisk.

Svar

Jeg er også enig i Sams synspunkt, at svævertilstande kan betragtes som progressiv forbedring . Jeg vil bare gerne præcisere det lidt.

Fra et mobil først perspektiv svæver stater ikke virkelig noget formål. Så brugergrænsefladen havde bedre råd til klikbare opførsler for klikbare objekter uden svævetilstand (dvs. knapper skulle se ud som knapper).

Hvis du kan understøtte denne opfattelse på en mobilenhed, understøttes den samme opfattelse også på stationære / bærbare enheder, selv før svævertilstande introduceres.

Inkludering af en svævetilstand på enheder, der understøtter svævninger – laptops, desktops osv. – vil bekræfte brugerens allerede eksisterende opfattelse af, at et specifikt UI-element faktisk er klikbart.

Så for at opsummere:

  1. Byg UI-elementer, der er klikbare, så de giver klikbar opførsel for enhver enhed.
  2. Brug svævetilstande på enheder, der understøtter svævning til understøtter yderligere forestillingen om, at et element er klikbart.

Svar

+1 til Sam for at nævne progressiv forbedring.

Jeg vil anbefale at bruge svævertilstande, hvis de giver noget nyttigt, der forbedrer brugergrænsefladen, men de burde aldrig være nødvendige for at udføre en opgave.

For eksempel ved at bruge dem på en produktlisteside til at give lidt information om varen, når de svæver over billedet, før brugeren navigerer over. Disse oplysninger skal derefter også være tilgængelige på selve produktsiden. forringer ikke oplevelse af berøringsskærmbrugeren, men tilføjer nogle yderligere anvendelighed for dem, der ser det. 🙂

Svar

Bare fordi du designer til både desktop og mobil betyder det ikke, at designene skal være samme. Interaktion, som mobilbrugere måske er vant til, kan ikke ses af desktopbrugere.

For eksempel hvide kort med et optegn i højre side. For mobile brugere er dette naturligvis noget, du kan trykke på. For desktopbrugere, ikke så meget (især hvis kortet er bredere på skrivebordet), men når de holder markøren og ser en svævende tilstand, er det pludselig tydeligt, at det kan klikkes.

Især nu den animation bliver mere og mere almindeligt, en svævertilstand er en grundlæggende animation, der giver brugerne feedback om, at de gør, hvad de havde til hensigt at gøre.

At ikke bruge en svævetilstand til skrivebordet er doven og gør folk triste.

Svar

Jeg tror ikke :hover stater er vigtige; UI-elementer på skrivebordet har klaret sig uden dem for evigt, og objekter, der tydeligt er designet til at give råd til at klikke (såsom “Send dit svar” -knappen her på UX.SE) tester fint i min egen oplevelse. Det “for ikke at sige det” er ikke nyttigt ; bare at det ikke er vigtigt.

Det gør jeg dog, betragter :focus og især :active siger væsentlige; sidstnævnte er især en, som jeg ser ignoreret på alt for mange websteder. En klar aktiv tilstand hjælper brugeren med at vide, at knappen klik blev registreret med det samme (, hvilket er ekstremt vigtigt for at hjælpe brugerne med at føle, at manipulerer direkte et objekt i brugergrænsefladen ). Systemkontroller såsom knapper og menuer har også gjort denne tilstand forventet, hvilket gør glemmen endnu mere utilgivelig.

Svar

Jeg vil foreslå, at svævetilstande giver positiv feedback til brugerens forventning om, at det pågældende element er interaktivt og derved fjerner potentialet for mere negative følelser af tvivl og tvetydighed .

Designs leverer et antal signaler, som et element er interaktivt – form, størrelse, position, farve, en understregning osv. Forskellige brugere har brug for forskellige signaler s, og måske den kumulative effekt af et andet antal signaler, at opfatte (og føle sig sikker på, at) elementet er interaktivt. Ændring af et element på svævningen er en mulighed for at levere flere signaler.

De fleste (hvis ikke alle) browsere leverer som standard markeringer ved at holde markøren ved at ændre markør til en markør. Selvfølgelig har vi kontrol over dette og kunne fjerne svævetilstanden ved at fjerne denne effekt. Men jeg forestiller mig, at det for de fleste af os (tage et øjeblik at forestille sig det) ville introducere betydelig tvivl i vores browseroplevelse. Browsere (og derefter designere) har skabt en sådan præcedens for yderligere signaler på svævningen, at ikke at levere signaler ville være en væsentlig modsætning til tidligere opfattede signaler om, at elementet er interaktivt.

Fjernelse af browserens standard cue er således et nyttigt eksempel på værdien af svævetilstanden. For mig bliver spørgsmålet således ikke, om visuelle signaler om interaktivitet på svæver er værdifulde, men hvilke og hvor mange signaler der er optimale.

Der er nogle nyttige velkendte præcedenser, men svaret på dette spørgsmål afhænger af applikationen og målgruppen.

Svar

Jeg vil foreslå hold markøren, når der ikke er noget ikon i knappen. Hvis vi antager, at der er et ikon, der er farverigt i knappen den gang, er det ikke vigtigt at give knappen til at holde markøren. Eks: Tilmeld dig ved hjælp af Google-knappen.

Svar

Hover er et must for alle websteder, der ønsker noget godt svar online. Jeg har brugt nogle websteder, der fjernede svæverstatus på min bærbare computer, og det var meget frustrerende.Enhver god designer ved, at folk online har travlt med at finde det, de vil have, og hvis en knap ikke fortæller dig, om den er en eller ej, og du skal åbne den i en ny fane for at finde ud af – det er en stor fiasko!

Korrekt, svævninger er ikke påkrævet for mobil. Men du kan altid deaktivere dem til mobil. Lad os desuden ikke glemme, at knapper til mobil skal være meget større end dem, der findes online. Og oprettede de ikke på to forskellige stilark alligevel?

Kommentarer

  • For websteder skifter markørstil til en hånd (eller tilsvarende) er den svævende effekt, jeg handler på.
  • Jeg tror, det skal stadig vises svævende, bare en hånd forvirrer brugeren, da vi ønsker, at internettet skal fungere så naturtro som muligt, og når vi klikker på ting, hvis det virkelige liv – de reflekterer. Fra en strateg ‘ synspunkt, vil du gerne have, at dit websted skal føles mere sikkert, og det ‘ er, at de fleste fiduswebsteder ikke ‘ t gider at installere svæveeffekten – derfor når brugere ikke ‘ t ser effekten, de begynder at føle sig underlige indeni. / li>

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *