Är svävande tillstånd nödvändiga?

Jag röstar ”ja”! Det är sant att sväva händelser inte borde vara beroende av att beröringsenheter är så populära. Jon verkar dock fråga om visuella svävarlägen på knapparna, vilket är något annorlunda.

Visuell svävarstatus har ”clickablity” . Du borde inte behöva klicka på något för att ta reda på det om det är en knapp. Användare på bärbara datorer och stationära datorer förväntar sig att ”klickbara” saker reagerar på svävaren, och att ha en knapp ”tänds” är en användbar ledtråd.

Tänk på det som en form av progressiv förbättring . Det är användbart för dem som kan använda det och ofarligt för dem som inte kan!

Kommentarer

• Faktum är att jag ’ skulle gå så långt som att säga att på ett skrivbord surfmiljö, kan användaren nästan tro att det är något fel om ingenting annat än markören ändras – vi har blivit så vana att hålla muspekaren.
• Det var mitt starkaste argument / tanke. Vi ’ har blivit så vana vid att det ’ är konstigt att inte ha det.
• Bra poäng om progressiv förbättring. Jag ’ d lägger dock till en sak till "You shouldn't have to click something to find out if it's a button."; du borde inte ’ inte behöva sväva över något för att ta reda på om det ’ sa-knappen.
• Jag skulle också säga att lägga till visuella svävarstatus på knappar ger användaren positiv feedback för sin handling eller en känsla av en mental utmärkelse.
• Efter att ha gått från Windows 7 som starkt förlitade sig på svävarstatus och använde ofta konturer eller paneler för att indikera knappar, till Windows 8 som ofta varken i ” Metro ” stilgränssnitt, jag ’ har hittat Win 8 otroligt frustrerande att använda ibland. Det kan vara vad MS vill att designers ska koda för Win 8, men IMX är det ’ är helt felaktigt att göra det.

Jag försöker undvika svävande tillstånd i design så mycket som möjligt. Den främsta anledningen till det är att de är meningslösa på pekdon.

Även om det här verkar som om det inte gäller när du inte designar för mobilen, använder många sina surfplattor eller andra pekdon för att surfa på samma webbplatser eller använd samma applikationer som du traditionellt bara skulle använda på en dator med en mus.

Genom att begränsa dig själv för att inte använda svävningshändelser gör du inte bara upplevelsen bra oavsett vilken enhet du använder, men du gör det också lättare att skapa en touch-specifik inbyggd applikation senare.

Kommentarer

• Hover-tillstånd är fortfarande användbara på mobila webbplatser. CSS :hover behandlas effektivt som :active när det visas på en mobil enhet. Detta ger visuell feedback om att användaren ’ s finger träffade målet. Den här feedbacken är mycket mer användbar på mobila mönster på grund av parallax. När din siktlinje avviker från den vinkelräta linjen till skärmen ökar chanserna för felavtryckning.
• @JoJo svävarstatus är inte ’ t kan upptäckas på mobilen , och knackning motsvarar att klicka på en dator.
• John, enligt min erfarenhet av att se webbplatser som jag ’ har utformat för stationära datorer på mobilen tror jag att JoJo har rätt när han säger att svävartillståndet [ibland] fungerar som det aktiva tillståndet. Jag säger ibland för att det ’ är lite fiffigt och inte ’ t alltid.
• @Jon I ’ jag argumenterar inte för hur det översätts, jag ’ jag argumenterar för hur det är vettigt att översätta. Om svävaren blir aktiv, hur väljer du? Dubbelklicka? Det bryter hela beröringsparadigmet.
• @JoJo inte alltid, jag ’ tror inte att Chrome på Android avfyrar svävarläget alls, och Safari ’ s svävande tillstånd är ofta besvärligt

Med framväxten av beröring är ett viktigt sätt att interagera med programvara, jag skulle vilja säga att svävarbaserade interaktioner nu överförs till ”trevligt att ha förbättringar” men borde aldrig vara ett krav för att interagera med programvaran.

Jag duplicerar ofta: svävar-tillståndet för: fokus, eftersom detta är ett användbart sätt att indikera fokus för en tangentbord-endast användare (som krävs för att uppfylla WCAG2 Det indikerar att ett objekt är interaktivt på något sätt utan att behöva en klickhändelse som kommer att utlösa en åtgärd som användaren inte har beslutat att starta ännu. Du kan bara utforma för: fokusera utan: sväva, men enligt min mening är avsikten med de två åtgärderna densamma och bör ha samma visuella effekt när det är praktiskt.

Jag håller också med i Sams synvinkel att svävande tillstånd kan betraktas som progressiv förbättring . Jag vill bara klargöra det lite.

Från ett mobil först -perspektiv svävar stater inte riktigt något syfte. Så användargränssnittet hade bättre råd med klickbara beteenden för klickbara objekt utan svävarläge (dvs. knapparna ska se ut som knappar).

Om du kan stödja den uppfattningen på en mobil enhet kommer samma uppfattning att stödjas på stationära / bärbara enheter även innan svävarlägen införs.

Att inkludera ett svävarläge på enheter som stöder svävar – bärbara datorer, stationära datorer etc. – kommer att bekräfta användarens redan existerande uppfattning att ett specifikt gränssnittselement faktiskt är klickbart.

Så, för att sammanfatta:

1. Skapa användargränssnittselement som är klickbara så att de ger klickbart beteende för vilken enhet som helst.
2. Använd svävarstatus på enheter som stöder svävar till stödja ytterligare uppfattningen att ett element är klickbart.

+1 till Sam för att nämna progressiv förbättring.

Jag rekommenderar att du använder svävarstatus om de ger användbarhet som förbättrar användargränssnittet, men de skulle aldrig behöva behövas för att slutföra en uppgift.

Om du till exempel använder dem på en produktlistasida för att ge lite information om artikeln när du svävar över bilden innan användaren navigerar över. Den informationen bör då också finnas tillgänglig på själva produktsidan. påverkar inte erfarenhet av pekskärmsanvändaren, men lägger till ytterligare användbarhet för dem som ser ser det. 🙂

Bara för att du designar för både stationär och mobil betyder inte designen ska vara samma. Interaktion som mobilanvändare kan vara vana vid kanske inte är uppenbar för stationära användare.

Till exempel vita kort med en vakt på höger sida. För mobilanvändare är det uppenbarligen något du kan trycka på. För skrivbordsanvändare, inte lika mycket (speciellt om kortet är bredare på skrivbordet), men när de svävar och ser ett svävarläge är det plötsligt uppenbart att det är klickbart.

Särskilt nu den animeringen blir allt vanligare, ett svävarläge är en grundläggande animering som ger användarna feedback om att de gör vad de tänkte göra.

Att inte använda svävarläge för skrivbordet är lat och gör människor ledsna.

Jag tror inte :hover tillstånd är väsentliga; UI-element på skrivbordet har klarat sig utan dem för alltid och objekt som är tydligt utformade för att ha råd att klicka (som ”Lägg upp ditt svar” -knappen här på UX.SE) testar bra i min egen erfarenhet. Det är inte att säga det är inte användbart ; bara att det inte är nödvändigt.

Jag anser dock att :focus och särskilt :active säger väsentligt; sistnämnda är speciellt en som jag ser ignorerad på alldeles för många webbplatser. Ett tydligt aktivt tillstånd hjälper användaren att veta att knappklicket registrerades omedelbart ( vilket är oerhört viktigt för att användarna ska känna att de manipulerar direkt ett objekt i användargränssnittet ). Systemkontroller som knappar och menyer har alla gjort det tillståndet också förväntat, vilket gör att glömma dem ännu mer oförlåtligt.

Jag föreslår att svävande tillstånd ger positiv återkoppling till användarens förväntan att elementet i fråga är interaktivt och därmed tar bort potentialen för mer negativa känslor av tvivel och tvetydighet .

Designs levererar ett antal ledtrådar som ett element är interaktivt – form, storlek, position, färg, en understrykning osv. Olika användare kräver olika signaler s, och kanske den kumulativa effekten av ett annat antal signaler, att uppfatta (och känna sig säker på att) elementet är interaktivt. Att ändra ett element på svävaren är en möjlighet att leverera fler ledtrådar.

De flesta (om inte alla) webbläsare levererar ledtrådar som standard genom att ändra markören till en pekare. Naturligtvis har vi kontroll över detta och kan ta bort svävarläget genom att ta bort denna effekt. Men jag antar att för de flesta av oss (ta en stund att föreställa mig det) skulle detta införa betydande tvivel i vår surfupplevelse. Webbläsare (och sedan designers) har skapat ett sådant prejudikat för ytterligare ledtrådar att sväva att inte leverera ledtrådar skulle vara en signifikant motsägelse mot tidigare upplevda ledtrådar om att elementet är interaktivt.

Borttagning av webbläsarens standard cue är således ett användbart exempel på värdet av svävarstatus. För mig blir frågan således inte om visuella signaler om interaktivitet på svävar är värdefulla, utan vilka och hur många signaler som är optimala.

Det finns några användbara bekanta prejudikat, men svaret på den här frågan beror på applikationen och målgruppen.

Jag föreslår sväva när det inte finns någon ikon i knappen. Om vi antar att det finns en ikon som är färgglad i knappen den tiden är det inte nödvändigt att ge svävarläge till knappen. Ex: registrera dig med Google-knappen.

Hover är ett måste för alla webbplatser som vill ha bra svar online. Jag har använt vissa webbplatser som drog svävarstatusen på min bärbara dator, och det var väldigt frustrerande.Varje bra designer vet att människor online har bråttom för att hitta vad de vill ha, och om en knapp inte kommer att berätta om den är en eller inte och du måste öppna den i en ny flik för att ta reda på det – det är en stor misslyckande!

Korrekt, svävarna krävs inte för mobilen. Men du kan alltid inaktivera dem för mobilen. Låt oss dessutom inte glömma att knapparna för mobilen behöver vara mycket större än de för online. Och skapade de inte på två olika stilark ändå?

Kommentarer

• För webbplatser som byter markörstil till en hand (eller motsvarande) är den svävande effekt jag agerar på.
• Jag tror att det fortfarande måste visa svävar, bara en hand förvirrar användaren, eftersom vi vill att webben ska fungera så verklighetstrogen som möjligt, och när vi klickar på saker om det verkliga livet – de speglar. Från en strateg ’ synvinkel vill du att din webbplats ska kännas säkrare och att ’ faktum att de flesta bluffwebbplatser bryr sig inte ’ för att installera svävareffekten – därför när användare inte ’ t ser effekten de börjar känna sig udda inuti. / li>