“This fancy pattern hurts UX far more than it improves it.”

Adam Silver 

(Skrivit för Smashing Magazine, A List Apart och CSS Tricks. Jobbat med ex. GOV.UK, Just Eat, Tesco och BBC – vilket, om någon inte känner till ovanstående, är ett sjukt CV)

Problem #1: tar alltid upp plats

Är alltid i vägen för content. Än värre på mindre skärmar/upplösningar där ytan är än mer begränsad.

Problem #2: de skymmer innehåll

Hänger ihop med #1. De lägger sig ovanför övrigt innehåll.

Problem #3: kan gå sönder vid inzoomning

När man zoomar kan storleken på header/meny öka och på så vis tränga bort övrigt content. Eller så försvinner dom, förvrängs/”felalignar” eller kapas. 

Kan ev undvikas på vissa sätt men till kostnad av ganska mycket programmeringstid.

Problem #4: de verkar närmare än de är

Sticky menyer/headers är alltid visuellt tillgängliga men i verkligheten är de ofta väldigt långt bort för användare av tangentbord som navigerar med tabtangenten; eller de som på annat sätt navigerar webben.

Problem #5: de skymmer länkar och andra fokuserbara element

Besökare som navigerar tillbaka upp på sidan med tangentbord kan hamna i ett läge där fokus är skymt bakom sticky meny/header.

Problem #6: svåra att komma åt

Om sticky header/meny är högre än innehållet och viewport så kan man inte komma åt det nedersta på menyn i vissa webbläsare. Även om innehållet är högre än header/menyn så måste man fortfarande scrolla ner till botten på content för att se menyn.

Man kan addera en inre scrollbar till menyn men multipla scroll är svåra att hantera (https://baymard.com/blog/inline-scroll-areas). 

Problem #7: interna sidankare känns trasiga när de klickas på

Vissa sticky innehåller länkar som tar besökaren längre ner (eller upp) på sidan, sk. ankarlänkar.

Med en stickyfunktionalitet så är det inte säkert att man förflyttar sig vid klick och därför kan interfacet känns trasigt.

Vad ska du göra istället?

1. Håll sidor korta: Sticky menyer/headers är ett symptom av (väldigt) långa sidor, åtgärda grundorsaken. Har du inte långa sidor så behövs inte heller sticky header/meny.
2. Låt besökare skrolla(!): Det är en myt att skrollning är ett problem (och helt seriöst så började dom diskussionerna ebba ut redan för +10 år sedan). Även på telefoner så är toppen av sidan oftast en “flick” eller två ifrån (normalt sett kan man alltid trycka på “top bar:en” för att bli skickad tillbaka till toppen, i de flesta webbläsare).
3. Lägg in relevanta länkar, i kontext: Exempelvis kan du lägga in länkar i löptext (det är trots allt själva definitionen av World Wide Web), lägga till formulär i slutet av en artikel eller kasta ut en CTA (länkad banner/knapp) här och var.

Många gånger är man frestad att inaktivera en submitknapp för att man tänker sig att man då eliminerar fel eller åtminstone inte visar fel längs vägen (“error prevention is better than a well-designed error”). Men här är några saker man kan tänka på om man tänker så.

#1: Vi får ingen feedback

När fel görs i ett formulär utan feedback så behöver användaren scanna av varje fält, hitta ett eventuellt fel och sen komma på hur de ska lösa det. Kontra en validering på submit som tydligt markerar ut vart felet är och varför det blir fel.

#2: De kan få interfacet att kännas br0ken

Om användaren tycker att deras svar är okej så känns UI söndrigt “Hallå, jag har ju fyllt i allt?!”. Och om det finns flera fel och ett av dessa åtgärdas så fortsätter knappen att vara inaktiverad.

#3: Svåra att se

Inaktiverade knappar har generellt sett låg kontrast för att signalera att de är inaktiva. Detta gör dom svåra att läsa/se, speciellt för användare med synnedsättningar.

#4: Är inte fokuserbara (focusable)

Användare som navigerar med tangentbordet kan inte tabba till knappen. Och användare med dålig syn kan inte se knappen. En tydlig väg framåt saknas därför för dessa användare.

#5: De är missvisande

Inaktiverade knappar har generellt sett låg kontrast för att signalera att de är inaktiva. Men detta är inte alltid tydligt. Så vissa användare kommer ändå att försöka klicka på dom.

#6: Användare kanske inte märker att knappen blir aktiverad

Detta beror på att knappen kanske är “utanför skärmen” pga upplösning/skärmstorlek eller storlek på formuläret. Och om knappen är synlig så är användaren snarare fokuserad på att fylla i fälten, inte på att knappen byter status.

Att inaktivera submitknappen hindrar inte användare att göra fel. Men den kan hindra dom från att förstå att de gjort ett och hur de löser det.

Varför krångla med att låsa in data i pdf-filer på webben när det enklaste och mest tillgängliga sättet är HTML?

HTML är ett märkspråk som tillsammans med TCP/IP och HTTP utgör den grundläggande standarden för WWW (World Wide Web); webbsidor skrivs i allmänhet som HTML och överförs över Internet med HTTP. Inget är helt enkelt mer lämpligt att ha på webben än HTML.

Det är en märklig företeelse att man även i modern tid envisas med att uppmana besökare att ladda ner pdf:er, ofta med mer data än vad som presenteras på sajten, när dagens webb har alla möjligheter att presentera data snyggt och smart.

Det är ännu märkligare om man väger in hur otroligt mycket av trafiken som kommer från mobiltelefoner och ”icke-persondatorer”. Mobiltelefoner som har ganska undermålig hantering av pdf-filer (Apple-produkter framförallt) och som försvårar att ta till sig informationen avsevärt. Inte särskilt användarvänligt någonstans.

Det finns egentligen bara en stark anledning till pdf: layout/arkdesign om pdf:en också ska bli exakt som man vill i print. Exempelvis om en säljare behöver skriva ut pdf. Finns detta behov är pdf ett bra komplement men då allra helst skapad on-demand direkt från PIM så man inte riskerar att visa gammal data.

Dock ska man ha med sig att om filen ska skapas dynamiskt så är det betydligt svårare att med kod sätta en snygg layout än vad man kan göra i InDesign, pga. diverse begränsningar beroende på de bibliotek man använder för att generera pdf:en. Det är också en enorm fördel om kund inte har helt orimliga (och helt ärligt väldigt konstiga) krav på exempelvis att allting ska få plats på ett A4-ark. Hanteras dynamisk data så öppnar det i de flesta fall dörren för variabla längder på ex. textdata osv. Har man några tusen pdf:er som genereras så kan man knappast inte ta hänsyn till om någon text är längre än den andra – det gäller istället att designa för fler sidor om så krävs. Inte minst om man blandar in andra språk, som tyska och finska.

Att låsa in data i PDF bör som minst ifrågasättas. Många gånger kanske man väljer att ha det ändå men då har det funnits en tanke bakom och man har svaret på “varför”. Det skulle kunna vara ”Vår säljorganisation vägrar att utvecklas och kräver att kunna gå in på sajten och skriva ut produktblad. Vad ska de annars faxa till varandra?” eller ”vi vet med hundra procents säkerhet att minst hälften av samtliga besökare surfar in hit för att ladda hem en pdf, vilket de är tvugna att ha pga x”.

Alla professionella sajtbyggare versionshanterar sin kod. Det innebär att all kod finns lagrad i ett så kallat repository. Fördelarna är många. Exempelvis kan vi se historik på varje enskild fil och kodrad, vi kan se vem som har skrivit vad, när och hur. Vi kan bygga nya funktioner i separata instanser som sedan kan läggas in när de är klara. Det gör det också väldigt enkelt för oss att sätta upp sajten i olika miljöer, såväl staging/utvecklingsserver och på våra lokala maskiner.

Fördelar med att inte själv uppdatera sin sajt och eventuella tillägg:

• Vår versionshantering hamnar inte i osynk. Osynk gör att nästa insats från vår sida kommer att ta längre tid då vi behöver replikera de ändringar som gjorts, se till att allt fungerar och slå samman detta med repositoryt.
• Vi har möjlighet att testa uppdateringarna i flera miljöer som inte är live/”produktionssajt”. Det är nämligen inte ovanligt att saker kan gå sönder. Speciellt tillägg kan vara klurigt då dessa utvecklas helt separat och oftast av andra personer än de som utvecklar plattformen. Det kan även röra sig om att utfasning av vissa funktioner gjorts vilket gör att vi kan behöva koda om sättet något fungerar eller presenteras på.
• När vi säkerställt att sajten och alla funktioner fungerar kan vi enkelt bokföra ändringarna och skjuta upp uppdateringen live på bara några sekunder

Nackdelar med att själv uppdatera sin sajt och eventuella tillägg:

• Dyrare om vi behöver hjälpa till med något
• Sajten kan gå sönder i produktionsmiljö

För regelbundna uppdateringar föreslås ett samarbets-/förvaltningsavtal där man kan uppdatera vid givna tidpunkter/år. Exempelvis efter major release cycle på plattformen.

Fotnot: detta gäller även för nyinstallation av funktionalitet. I vissa fall med WordPress som plattform har vi varit med om installation av tillägg som man tror är bra och gör nytta med inte insett att tidigare tillägg har jobbat ihop med custom-kod för bättre nytta.

Exempel på projekt där saker gått sönder:

Sajt uppdaterades från 5.7 till 6.0 vilket innehöll en del breaking changes vilket gjorde att sajterna spottade ut felmeddelanden. Vilket krävdes att vi skrev om viss funktionalitet för att lösa problemet.

• Kund hade låtit bli att uppdatera/underhålla sajten under många år samt ignorerat mail från Loopia (som hostade sajten) om att kunderna måste uppgradera PHP-version, annars kommer de till slut tvingas upp.
• Loopia har som policy att bara stödja de tre senaste PHP-versionerna (major) då äldre versioner än så har nått EOL. Sajten var byggd långt innan och fungerade bara upp till PHP 7.4.
• Sajten innehöll bärande tillägg och tema (templates) som byggdes i en tid då det inte krävdes licens för uppdateringar. När detta sedan ändrades saknades så aktiv licens och tillägg/tema kunde därför inte heller hämta in information om att det fanns uppdateringar. Och detta upptäcktes inte under 5-7 års tid = otroligt många uppdateringar.
• När Loopia sedan tvingade upp lägsta PHP-versionen från 7.4 till 8.0 så var det så många saker som blivit föråldrade att sidan helt slutade att fungera (= helt vit sida utan innehåll).
• Lösningen tog extra lång tid eftersom vi fick ställa ner mjukvaruversioner i en testmiljö för att se vad som gått fel, därefter hitta på en rimlig lösning (vilket blev att ta bort tillägg och tema och bygga om sajten med nytt tema) och sedan uppgradera systemversioner successivt.

• Begränsningar i vad som går att göra i CMS och shoppdelen utifrån kommunikations- och designperspektiv
• Extremt undermåligt när det rör annat content än produktkatalog. CMS och DAM/Mediabibliotek är långt bakom konkurrenterna
• Vill gärna ha LESS
• Eventuellt begränsningar i system vad gäller generering av övrigt säljmaterial kontra ex möjligheterna i Pimcore

“For decades, a common behavior for this kind of navigation is to open the menu on mouse hover. And for decades, a common user’s complaint about this pattern has been the absolute lack of certainty and control about how and when the sub-navigation opens and closes.”

Vitaly Friedman, Smashing Magazine (author, co-author and editor of all Smashing books and front-end/UX consultant working with European Parliament etc)

“I’ve built a bunch of websites and learned a lot more about usability, accessibility, and content strategy. Now, I find hover-triggered menus lacking on all those fronts.”

Mark Root-Wiley https://css-tricks.com/in-praise-of-the-unambiguous-click-menu/

Redan 2011 skrev UX Movement om detta fenomen https://uxmovement.com/navigation/why-hover-menus-do-users-more-harm-than-good/

Tyvärr är hover ganska vanligt men det bästa sättet att säkerställa att menyn fungerar över enheter, traditionella skärmar till tocuhskärmar, är click-to-open.

Man undviker då mycket frustration som kommer med hover, exempelvis:

Inkonsekvent UX på pekskärmar och för de som navigerar med tangentbord

Hovermenyer fungerar inte på pekskärmar. Det kan eventuellt lösas med kod för att upptäcka pekskärmar och växla till click-to-open. Men eftersom gränsen alltmer suddas ut mellan “vanliga” skärmar och skärmar med touch, kan dessa lösningar bli föråldrade. Här behöver man också ha med i beräkningen att lägga ut separata knappar för att öppna undermeny eftersom huvudmenyvalet i sig är en länk till just den sidan.

En del föredrar, eller kanske bara har möjlighet, att navigera mha tangentbordet. Normalt sett behöver man då tabba sig igenom alla länkar genom alla undermenyer fram till den länk du vill besöka (med klick hoppar man över underlänkar emn kan fälla ut med ENTER och tabba sig igenom om man vill).

Detta leder oss vidare till:

Frågor om vad som är klickbart

Med hovermenyer vet användare inte alltid om den överordnade länken är klickbar eller inte förrän de försöker klicka. Det är motsatsen till intuitivt. Ur exempelvis struktur- och SEO-pespektiv är det bra om den överordnade sidan finns och går att nå.

Övrig tillgänglighet 

Hover-menyer kan ge problem för användare som använder skärmläsare eller navigerar via tangentbord.

Narrow hover tunnel/The Buzz Wire Maze

Hover-tunnel är vägen en muspekare måste följa för att navigera medan menyn är öppen. Om detta är för smalt så är det svårt för besökaren att navigera rätt utan att den stänger sig. Tänk här också på personer med motoriska hinder eller personer som surfar med webbläsaren i zoomat läge.

Öppnad av misstag

En hovermeny är benägen att öppnas oavsiktligt om man navigerar över den på väg till något annat ställe på sidan. Eller för den delen stängs oavsiktligt för att man exempelvis råkar stöta till musen. Detta är än värre när det rör stora menyner och megamenyer där det tar lång tid att ta in allt innehåll i undermenyerna och räkna ut vart man ska navigera.

Inkonsekvent/otydlig

Är det överordnade objektet en länk eller inte?  Detta leder till mycket förvirring. Vissa hoppar rakt förbi användbara sidor på toppnivå, förutsatt att dessa objekt inte är länkar. Ännu andra antar att länkarna på toppnivån är sidor och försöker klicka på dem och blir frustrerade om så inte är fallet.

Aktivering av misstag

Att hovra är inte en avsikt att aktivera. Det är på sin höjd ett förslag att användaren kan aktivera något. Tekniskt sett hovrar användaren alltid. Detta är anledningen till att hovringstillstånd är fördelaktiga för användaren, till exempel byte av muspekare (webbläsare gör detta som standard) eller färg och linjering på länkar.

Med hover kan en användare av misstag öppna en meny trots att de aldrig tänkt det och när detta händer döljer det innehållet bakom och stör upplevelsen.

Om en användare avser att klicka på en länk på en sida kan användaren navigera iväg av misstag om menyn öppnas precis innan du klickar på den länken. Det låter sällsynt men är vanligare än man tror

Mixed input devices

Vi har bärbara och stationära datorer med pekskärm. Du kan också använda en mus eller styrplatta med ex. en iPad. Det är inte bara möjligt att använda touch på en stor skärm, och en mus på en liten skärm, dina besökare kan använda båda samtidigt. 

https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

Klickfunktion är vad vi förväntar oss i de flesta andra sammanhang:

• Använder du en touch/pekenhet? Hover finns inte

• Använder du en applikationsmeny(t.ex. Arkiv, Redigera)? Dessa klickas fram

• Använder du något annat än en mus? Att trycka på ENTER eller aktivera en länk med någon typ av växlingskontroll (switch/toggle) motsvarar mer att klicka än att :focus motsvarar :hover.

Oavsett din enhet eller inmatningsläge är ett ”klick” en mer universell och solid interaktion. Även med fördelen att klick/tap, alltså dator vs. telefon fungerar med samma beteende. Eftersom att klicka eller peka (tap) är en tydlig avsikt finns det ingen oavsiktlig aktivering/avaktivering.

“Avoid using hover to expand dropdown lists. Hover is difficult for some users and won’t work on touch screens. Dropdowns should expand on click or with keyboard navigation.”

U.S. Web Design System’s(USWDS) navigation patterns

“What it really boils down to is user intent. The purpose of a hover state is to indicate something is clickable(underlined text)… The purpose of a click is to actually do something, to take an explicit action. Opening a dropdown is an explicit action and should only happen on click.”

Bootstrap (reasons)

 

“Maybe you don’t even need submenus at all!” 

UK.gov design system

Deras menyer är endast länklistor, med on-page grids med länkar och dragspel accordions för att låta besökaren navigera.

Andra saker man kan göra/tänka på när man designar informationsarkitektur och menysystem:

• Om < 4 objekt, undvik “dropdowns” och lägg ut det direkt (sparar användarinteraktioner).
• Använd innehållsförteckning och/eller ämnessidor för att undvika “dropdowns”.
• Multipla menyer på olika platser. Noggrant uttänkta och viktade efter vad det är, vad besökarna vill ha (mest) osv. Ex “VD-meny”, sidfotmeny och gärna kombinerat med föregående punkt.

https://medium.com/simple-human/why-hover-menus-are-problematic-b21d6c7de91c

Det har visat sig vara ett synnerligen ineffektivt sätt att presentera information.

https://shouldiuseacarousel.com/

Besökare har i regel inte tid eller tålamod att vänta, ”undra vad som kommer härnäst”, det innebär att alla bilder efter den första har väldigt låg effekt – de flesta ser dom aldrig. 

• En studie av sliders på University of Notre Dames sajt, visade att av 3,7 miljoner besök så var det 1% som klickade, 89 % av dessa interaktioner var på den första bilden. Förvisso en studie med några år på nacken men inget pekar på att beteendet skulle ha ändrats.

I de allra flesta fall scrollar besökare efter direkta/riktade ingångar som möter deras behov för tillfället. Det är alltså mer effektivt, tillgängligt och tydligt att lägga ut innehållet efter varandra än att gömma undan. En god innehållsprioritering signalerar också att företaget/sajten har en tydlig webbstrategi, en karusell vittnar om det motsatta och det är ett tydligt sätt att visa på hur flera viljors önskan att just deras innehåll är bäst. 

Carousels are effective at being able to tell people in Marketing/Senior Management that their latest idea is now on the Home Page.

They are next to useless for users and often“skipped” because they look like advertisements. Hence they are a good technique for getting useless information on a Home Page(see first sentence of this post).

In summary, use them to put content that users will ignore on your Home Page. Or, if you prefer, don’t use them. Ever. Btw these views are not my own, but are based upon observing thousands of tests with users.

Lee Duddell

Svenska företaget Conversionista gjorde ett eye-tracking-A/B-test och fann att en statisk bild fick mycket större uppmärksamhet än en slider. Man sammanfattar med ”vår studie visar att användare i stor utsträckning ignorerar roterande toppbilder och att de inte heller interagerar med dem, även om de är klickbara.” Blair Keen på Adobe testade att ta bort deras slider och fick som resultat en försäljningsökning på 23 %.

• Om det går långsamt för vissa så rör det sig för snabbt för andra. Ett störningsmoment kan uppstå om man läser eller tittar på något som sedan försvinner utan att man själv initierat det. Detta förutsätter så klart att bildspelet går på någon form av autoplay, undviker man det så är det bättre men då krävs å andra sidan stort jobb för att få besökaren att vilja klicka vidare till nästa slide.

• En slider bör, om används, vara noggrant kodad så att den inte drar ner sajtens SEO eller användarupplevelse med exempelvis multipla h1-element*, dålig prestanda, begränsad responsiv funktionalitet, avsaknad av navigation och play/pause m.m (se även https://uxmovement.com/navigation/big-usability-mistakes-designers-make-on-carousels/). Det kan med andra ord vara svårt att hitta en färdigkodad som är tillräckligt bra eller för den delen bli dyrt att utveckla.

• https://uxplanet.org/designing-a-user-friendly-homepage-carousel-f664c9f2b50e

* Up for discussion: uppgifter gör gällande att numera är sökmotorer mer tillåtande med flera h1:or på samma sida

https://medium.com/@sherpadesignco/carousels-are-killing-your-conversion-rate-heres-how-to-fix-that-b57e31f8f508

https://www.nngroup.com/articles/auto-forwarding/

Homepage Sliders: Bad For SEO, Bad For Usability

https://cxl.com/blog/dont-use-automatic-image-sliders-or-carousels/

https://www.widerfunnel.com/blog/rotating-offers-the-scourge-of-home-page-design/

Carousel Sliders: Good Practice Or Bad For SEO?

Why You Should NOT Use a Carousel On Your Website

https://humanebydesign.com/principles/finite/

”Interna länkar skall öppnas i samma fönster medan externa länkar skall öppnas i ett nytt fönster.”

Utan att fördjupa sig mer inom området är detta devisen många går efter. För oss är svaret inte så enkelt. Särskilt om man vill skapa en bra upplevelse för sina användare.

Det diskuteras mycket kring vad som är mest lämpligt. Stor del av den forskning som gjorts är daterad och mycket har hänt sedan dess. Smarta telefoners intåg har ändrat vårt sätt att surfa på webben. Webbläsarna har sedan länge en funktion för att öppna länkar i en flik istället för i ett helt nytt fönster. Sajter bör, och även i vissa fall skall, vara tillgänglighetsanpassade, vilket också är en aspekt att ta hänsyn till.

En av de största problemen när man väljer att öppna länkar i ett nytt fönster/flik är att man tappar webbläsarens funktion för att gå bakåt och ställer krav på att användaren uppmärksammat detta. Bakåtknappen (via musklick, backsteg/backspace eller annat) är en av de mest använda funktionerna för att navigera på webben och därför är det viktigt att tänka till innan du väljer bort den. Möjligheten att öppna en extern länk i en ny flik istället för ett nytt fönster underlättar visserligen för användaren. Detta eftersom de enklare ser att något nytt öppnats och att det blivit enklare att komma tillbaka till där de kom från. Dock är det främst en sanning för de som sitter på desktop. Flik-funktionen är inte alls lika enkel för de användare som surfar via mobiltelefoner eller andra mindre skärmar eftersom flikar på en mobiltelefon brukar fungera som nya fönster på grund av platsbrist.

När det kommer till tillgänglighet är rekommendationerna tydliga – man bör undvika så långt som möjligt att öppna upp länkar i nya flikar/fönster (w3.org – WCAG 2.0 G200, CSS-tricks – When to use target=”_blank”). Detta då det försvårar navigeringen på din sajt och användarna riskerar att göra fel.

”In general, it is better not to open new windows and tabs since they can be disorienting for people, especially people who have difficulty perceiving visual content.”

https://www.w3.org/TR/WCAG20-TECHS/G200.html

Rädslan för att tappa besökare

Vi har genom åren fått höra att många är rädda för tappa användare om de öppnar en extern länk i samma fönster/flik. Men har man en väl fungerande bakåtknapp skall det inte vara några problem för användaren att enkelt komma tillbaka till din sajt. Det kan snarare vara svårare för användaren att ta sig tillbaka till rätt fönster/flik när länken öppnats i ett nytt fönster/flik. Detta gäller särskilt när användaren surfar via sin mobil.

Istället för att hålla fast i den gamla devisen utgår vi istället ifrån användarupplevelsen för den specifika situationen för att kunna avgöra vad som är bäst. I grunden håller vi oss till att både interna och externa länkar skall öppnas i samma fönster/flik. Vi vill inte bryta ett användarflöde bara för att vi är rädda att förlora dem till andra sajter. Att störa flödet kan dessutom betyda att vi riskerar att göra användarna frustrerade eftersom det krånglar till det för dem. Vi vill att användarna skall gilla oss. Det är heller inte alltid så att din sajt kan hjälpa användaren att uppnå sitt mål, utan ibland är du bara en del i resan mot målet. Du behöver därför inte försöka äga användarna utan våga släppa iväg dem. Nöjda användare kommer tillbaka. Det du istället behöver fokusera på är att skapa bättre innehåll som får besökarna att vilja stanna längre.

Undantag?

Det finns flera indikationer för då det kanske lämpar sig att öppna upp innehåll i ett nytt fönster/ny flik, men fokus måste alltid vara på att tänka till kring själva användarflödet. Exempel på indikatorer är:

• Användaren är inne i ett specifikt användarflöde. Exempelvis då besökaren klickat på ”Hjälp” eller är i ett utcheckningssteg och vill läsa mer om fraktvillkoren.
• Då man riskerar att förlora information som användare fyllt i, såsom filtrering i produktsök eller andra typer av formulär.
• Då användaren är inloggad i ett system och kan riskera att tappa inloggning eller kontroll av huvudsaklig uppgift. Bra är då att märka upp externa länkar (som öppnas in nytt fönster/flik). Se sista stycket.

Det finns i de allra flesta fall andra lösningar att komma runt problematiken, helt beroende på vad det gäller så klart. I vissa fall kan ett alternativ som låter oss dölja/visa mer innehåll på samma sida vara en godtagbar lösning, som dessutom kan ge oss ett bättre resultat i slutändan. I andra fall kan ett nytt tänk kring innehåll, layout och funktionalitet lösa så eventuella bekymmer kring detta sällan uppstår.

Vi surfar på webben på sitt egna sätt. Bestämmer man som redaktör eller utvecklare att en länk ska öppnas i nytt fönster/flik så får inte de besökare som vill vara kvar i samma fönster/flik (vilket följer deras egna surfbeteende) oftast något val. Låter man det däremot vara orört så kan de som vill följa länken i samma fönster/flik medan de som öppnar i nytt alltid kan göra det genom exempelvis [högerklick]+”Öppna länk på ny flik” eller det lite snabbare ctrl/cmd +[klick] (motsvaras av långt tryck på touch-enheter). Att öppna en länk i samma fönster är standard, att ändra en standard bör vara noga övervägt.

Bra att tänka om du har länkar som öppnar i nytt fönster/flik är att, i den mån det går, förtydliga att de öppnas i nytt fönster/flik. Man kan exempelvis skriva ut det i en parantes i länken eller använda sig av en lämplig ikon.

Fler lästips!

w3.org

webbstrategiforalla.se/hygienfaktor-inte-oppna-i-nytt-fonster/

webbriktlinjer.se

UX gurus Nielsen Norman Group summerar”Video content is helpful only if users have control over it, understand what’s contained within it, and have an alternate way to access it.” 

Det finns inget standardbeteende för hur besökare agerar när de påträffar en video på en sajt. Några kollar direkt, några kollar innehållet runt omkring först och ser videon först därefter. Vissa är inte intresserade av eller har möjlighet att kolla (3G-nät, surf i offentlig miljö, under möte eller liknande). Samma persons beteende kan variera från sajt till sajt och/eller från uppgift till uppgift. Därför kan man aldrig garantera att någon kommer att se eller är intresserad av videons innehåll. 

I sammanhanget har videos en stor nackdel – besökaren tar in innehållet sekventiellt. De behöver alltså vänta in innehållet i den ordning det presenteras utan att veta om det som kommer är relevant för deras behov. Därför kräver videos mer av besökarens tid än motsvarande innehåll i text. Text stödjer nämligen att snabbt kunna scanna av information, vilket är det primära sättet som de allra flesta interagerar med information på webben.

https://www.nngroup.com/articles/video-usability/

Autoplay

“Autoplay is a bad idea not just for accessibility but for usability and general sanity while browsing.”

http://www.punkchip.com/autoplay-is-bad-for-all-users/

UX-studier (bl.a. av NN Group) visar att besökare inte uppskattar att bli överraskade av video eller ljud som börjar spelas utan deras medgivande. Det kan förvirra eller distrahera besökaren och kan inkräkta på sättet de konsumerar sajtens innehåll.

För besökare som inte vill se en autospelade video krävs en stor kognitiv och extra insats för att hitta ett sätt att stänga av eller hitta en mute-knapp. 

Enligt en poll av Consumer world 2016 så upplever 92 % av användarna autoplay som störigt och 76 % försöker stänga av ljudet så fort som möjligt. Kan de inte stänga av ljudet lämnar de flesta besökare sajten. Läs mer här: https://www.boia.org/blog/why-autoplay-is-an-accessibility-no-no

Vi ser även indikationer, om än med sämre forskningsstöd, att personer över 35 har mer ont av autoplay än yngre personer. Det kan alltså vara lurigare om sajtens målgrupp är äldre personer.

Både NN Group och Bokardos publicering av “Principles of UI Design” trycker på uttrycket “Keep users in control”. Människor är som mest bekväma är de känner att de har kontroll på sig själva och sin omgivning. Därför ska man försöka att inte tvinga folk till oplanerade interaktioner och försöka guida så pass att de vet vad som väntar. Uppmärksamhet är dyrt i en värld med ständiga avbrott och distraktioner. Således kan resultaten förbättras om man respekterar uppmärksamheten och låter besökaren fokusera på att exempelvis läsa klart en produkttext eller liknande utan för mycket distraktioner.

Genom att implementera autoplay på videos gör du en hel del antaganden. Du förutsätter bland annat att alla dina besökare:

1. använder en webbläsare och hårdvara som klarar av att spela upp videon smärtfritt
2. har en bra uppkoppling och eventuellt inte heller behöver bry sig om hur mycket surf de gör åt
   1. Uppkoppling är intressant då ett inte alls otänkbart scenario är att någon försöker komma åt ex. produktinformation eller kontaktuppgifter ute i skogen och mark (eller i Marbäck) – där möts man ofta av halvknackig 3G, även i södra Sverige. Än värre utomlands.
   2. Surfdatamängd är kanske inte ett lika stort problem i Sverige, bortsett om du vänder dig mot tonåringar, som det är utomlands där det fortfarande kan vara dyrt med surfdata. Det är lätt att tro att det mest är ett problem i afrikanska länder där 1 GB surf kan kosta upp emot 300 kr. Men andra exempel är Grekland och Kanada (~120 kr/1 GB) och USA, Schweiz och Österrike på ~80 kr/1 Gb. Källa: https://www.visualcapitalist.com/cost-of-mobile-data-worldwide/ . Notera att många operativsystemstillverkare har stängt av autoplayfunktionalitet pga just surfdata och“as well as for the sanity of user browsing”. Glöm dock inte att många kan surfa med“telefonen som modem”.
3. är intresserade eller blir intresserade av din video
4. inte lyssnar (om ljud är påslaget) eller kollar på något annat samtidigt
5. att personen befinner sig på en plats och i ett sammanhang där det funkar att se en video (och eventuellt lyssna på ljud)

Om något av dessa antaganden visar sig vara fel så är det hög sannolikhet att besökaren lämnar sajten snabbt och chansen at de ska komma tillbaka minskar troligtvis (bortsett från ett ev. irritationsmoment så är det många gånger enklare att stänga fliken/fönstret än att leta upp en paus/stopp-knapp). Man ser högre bounce rates och det kan även påverka saker som sökranking m.m.

Prestanda och dataförbrukning

I Sverige har vi det ganska bra. De flesta (om inte alla numera) bredbandsabonnemang ger obegränsad med surf. Vad gäller mobila abonnemang så har vi relativt mycket surf för liten peng. Men så ser det inte ut utomlands och vi behöver inte åka särskilt långt, egna erfarenheter talar om hyfsade skillnader bara genom att åka till Tyskland eller Storbritannien, både i hastighet och kostnad. Se listan ovanför för mobil surfkostnad i andra länder. 

Och som ovan: Notera att många operativsystemstillverkare har stängt av autoplayfunktionalitet pga just surfdata och“as well as for the sanity of user browsing”. Glöm dock inte att många kan surfa med“telefonen som modem”.

Men något vi inte är fullt så bra på i Sverige är vettig täckning. Se listan ovanför igen. Många gånger finns fördelarna i en snabb och lätt sajt i åtkomsten även när täckningen är lite sämre. Mätningar visar att besökare förväntar sig att en sidladdning ska gå på max 3-4 s, tar det längre tid så klickar man bort. Kanske är det då konkurrenten som tar affären istället.

En inbäddad video kommer att öka på laddningstid, en autoplayad video än mer. Dåliga laddingstider ger inte bara otåliga användare som i många fall stänger ner sidan, testar konkurrenten eller gör något annat. Det är också en stor faktor i din SEO-ranking. Läs mer nedan.

An auto-playing video is bandwidth intensive. A good 30-second video can take up to 10 megabytes worth of bandwidth consumption. That’s more bandwidth than taken up by 100s of images and HTML script texts on your website. In case your website observes a traffic surge or your customer’s Internet isn’t par excellent in speed, it can easily divert your customer’s attention to other alternatives, leaving you eventually at a loss.

https://www.branex.ca/blog/autoplaying-homepage-video-on-landing-pages/

Strömförbrukning? Ja, detta är också en faktor att väga in, speciellt när vi pratar besökare från mobila enheter så som telefoner och läsplattor.

https://webbriktlinjer.se/riktlinjer/54-optimera-webbplatsen-for-basta-prestanda/

https://www.searchenginewatch.com/2017/05/19/how-video-impacts-mobile-web-performance-and-ux-part-2-autoplay-and-audio/

Tillgänglighet, funktionsnedsättning och funktionshinder

“Cirka en av fem personer har en funktionsnedsättning. Ännu fler har det periodvis i livet.” – webbriktlinjer.se

Personer med koncentrationssvårigheter, ADHD, ev. epilepsi m.m. vill med stor sannolikhet gärna ha kontroll över vad om sker. Överlag bör man som sagt vara försiktig med distraktioner om man vill förbättra tillgängligheten på sin sajt. 

Ponera att du surfar webben med hjälp av skärmläsare och besöker en sajt med video autoplay och ljud påslaget. Tänk sedan att du behöver lyssna igenom sidan för att hitta kontrollerna för att pausa/mute:a video – men du kan inte höra skärmläsaren för att ljudet på filmen spelas. W3:s WCAG 2.0 är tydligt https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-dis-audio.html . Notera att detta även kan påverka människor som har svårt för att ta till sig text när ljud spelas.

Either of the following checks are true:

• Media content does not play automatically.
• The user is pre-warned that media will automatically play and there is a control to stop or pause.

Guidelines från BBC https://www.bbc.co.uk/accessibility/forproducts/guides/mobile/autoplay

Se även: https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-pause.html

https://webbriktlinjer.se/riktlinjer/133-orsaka-inte-epileptiska-anfall-genom-blinkande/

Mer info för devs: https://developer.mozilla.org/en-US/docs/Web/Accessibility/Seizure_disorders

Relevans

Hur är detta relevant? Många gånger har man hört “ja men vi skiter i dom”, “det rör ju inte oss” eller “det är inte vår målgrupp”. Så kan det ju vara, men ofta vet vi ju inte exakt vilka besökare vi har, det mesta är gissningar med olika bra pricksäkerhet. 

Det finns många olika funktionsnedsättningar. Ganska många av dem, till exempel dyslexi och färgblindhet, märker omgivningen vanligtvis ingenting av. Därför är det lätt att underskatta hur många människor som berörs av tillgänglighet och funktionshinder.

– webbriktlinjer.se

Bra att ha i bakhuvudet om man bygger webb i allmänhet är att:

Rörelse och motorik

• 20 procent av Sveriges befolkning är över 65 års ålder, och andelen kommer att öka.
• 515 000 personer över 16 år har en rörelsenedsättning. Nästan hälften av dem är över 75 år.
• Det finns många tillfälliga problem som gör att det är svårt att röra sig eller använda en dator; en hel del olyckor sker i samband med idrott och vintertid blir fallolyckorna fler på grund av halka.

Läsa och skriva

• Omkring 25 % av den vuxna befolkningen har problem med att läsa. *
• 5–8 % beräknas ha dyslexi.
• Varje år drabbas upp till 10 000 personer av afasi. En tredjedel av dessa är i yrkesverksam ålder. 

Syn

• Mer än hälften av befolkningen över 16 år behöver läsglasögon.
• Sett till antalet inskrivna på landets syncentraler räknas omkring 120 000 som synskadade.
• Åtminstone 30 000 är gravt synnedsatta eller helt blinda.
• Några procent av befolkningen är färgblinda.

Hörsel

• 1,5 miljoner hör dåligt. Mer än hälften av dessa är över 65 år.
• Fler än 700 000 personer uppskattas behöva hörapparat, men bara knappt 500 000 har en apparat.
• Åtminstone 15 000 personer är gravt hörselskadade eller har blivit döva i vuxen ålder.
• Åtminstone 10 000 är barndomsdöva, och det föds åtminstone 70 döva barn per år.
• Åtminstone 30 000 personer är i behov av teckenspråk eller liknande stöd.

Neuropsykiatriskt

• 5 % av alla barn och 2,5 % av alla vuxna uppskattas ha adhd.
• 1–2 % av befolkningen har en autismspektrumdiagnos.
• Dåligt utformade IT-system skapar den här typen av svårigheter hos många individer som inte har någon funktionsnedsättning i andra situationer.

Källor:

https://www.funka.com/design-for-alla/statistik/

https://webbriktlinjer.se/tillganglighet/statistik/

* Här kan man tänka sig att många skulle ha lättare för att ta in information via film. Absolut, det är till och med bra för tillgängligheten! Men den kanske inte behöver ha autoplay?

Ang dövhet:“Uppgifterna om hur många döva personer det finns är egentligen föråldrade – de kommer från offentliga utredningar som gjordes 2004 respektive 1989. Med tanke på att befolkningen har ökat sedan dess är det sannolikt att det nu finns fler döva. Men vi väljer att vara försiktiga, och presenterar därför de lägre siffrorna här.”

Värt att notera (speciellt om vi jobbar med myndigheter, offentlig sektor osv) https://webbriktlinjer.se/tillganglighet/juridiska-krav/ 

Konvertering

Det finns mycket som pekar på att autoplayade videos har en sämre konverteringsgrad. Se nedanstående artiklar:

So yes, it is polite to leave your audience alone while they navigate your site. Draw a ton of attention to your video on your page to make sure they don’t miss it, do what you can to convince them to press play, and then give them their space. 

https://wistia.com/learn/marketing/to-autoplay-or-not-to-autoplay

There’s one exception, and that’s when your users intent to view a video when they arrive on your page. YouTube is a great example of this. If a user clicks a YouTube link, the video is going to play as soon as it has loaded. This is because that user knows what YouTube is and knows what goes on there. They expect a video, and thus by autoplaying that video, the barrier to use is lowered.

This is really only valid for dedicated video hosting pages.[…] As long as a user intends to view a video when they land on your page, then autoplay is fine. Every other circumstance, just disable it.

https://growtraffic.com/blog/2015/05/autoplaying-videos-hurt-help-conversions

Do. Not. Autoplay.(Or Thou Shalt Be Smited!)

Is your goal to get people to bounce off your page in record time, even before you’ve had the chance to get them to your call to action? Because this is the best way to do it. Think about it for a second. How annoying is it when you’re innocently searching for some information online and all of a sudden you hear this voice coming out of nowhere so you’ve got to scramble around to find where it’s coming from so you can stop it and just keep reading in peace? The answer: really freaking annoying. The thing is, if you’ve got a prominent video, a pleasant site design, and promising lead-in text, the visitor will want to watch your video to get the information you’re offering. All you have to do is not force it on them.(Because apparently we’re all control freaks who hate surprises.)

https://klientboost.com/cro/landing-page-videos/

Setting your video to autoplay is equivalent to shoving your message down your visitors’ throats. Yes, they arrived at your post-click landing page looking for a solution to their problem. But give them the opportunity to digest your information at their control(pressing play) and not annoying them with your autoplay video. If you feel that autoplay is appropriate, try using a silent full-screen contextual video instead. These videos act as a replacement for your post-click landing page’s image, establish a context for your offer, and help you tell a compelling story.

https://instapage.com/blog/landing-page-video-rules-to-follow

Well, it turns out that neither of our experts recommend autoplay video as a way to drive conversion. Nochimowski explained:

• This can be perceived as aggressive to the user.

Garg added,“I believe that anything which is pushed on users irritates them and make them suspicious about your product or service.”

https://unbounce.com/landing-pages/autoplay-landing-page-best-practices/

https://www.singlegrain.com/video-marketing/7-ways-video-helps-inbound-marketing/

Ovanstående artiklar har också goda förslag till alternativ till autoplay för bättre konvertering, ex. hur man kan tänka med CTA:s och liknande. De är skruvade åt “landing page”-hållet men vad är inte en landing page egentligen? Jag tycker att flera av teknikerna kan funka lika bra oavsett vart du är (med vissa modifiering kanske).

Övrig take-away är att videos helst ska vara max 30 sekunder (eller åtminstone inte längre än två minuter) för bästa effekt och det är också då användare har som störst fokus. Lägg dessutom rejält extra krut på de första fem sekunderna.

SEO

Does Google penalize a website when that website has an autoplaying video embedded on the page?

The answer, according to Google’s John Mueller back about a year ago – early March 2017 – is no. User Merlinox asked John if Google penalizes autoplaying video. John’s response was“Not at the moment. Should we?(I don’t like them either :-/).” 

Dock är det inte ovanligt att bounce rate:n går upp och på så vis ger en impact i rankingen.

https://moz.com/community/q/does-autoplay-video-effect-seo

Prestandaförlusten i att ladda in en video, sidan tar längre tid att ladda, kan också påverka din SEO negativt. En autoplayad video laddar således också mer och gör din sida slö. Även om sökmotorerna kanske inte benchmarkar sidan med en simulerad dålig uppkoppling så kan de jämföra den med konkurrenters sidor och på så vis dra ner betyget. Detta enligt uppgift även om videon i sig är inbäddad från Youtube (Googleägt), om vi pratar Googles söktjänst. https://www.seoblog.com/autoplaying-videos-hurt-rankings/

“Autoplaying is wasteful for everyone involved because a page visit does not always demonstrate intent to watch. One notable exception is YouTube, where visiting a watch page is definitely intent to watch. Keep in mind that only home pages are crawled by HTTP Archive. So my theory is the top sites choose not to autoplay in order to keepbounce rates low and conversions high.”

-Rick Viscomi, a leader of the HTTP Archive project and Developer Advocate at Google

https://www.searchenginewatch.com/2017/05/19/how-video-impacts-mobile-web-performance-and-ux-part-2-autoplay-and-audio/

Se även denna artikel som sammanfattar prestanda, uppmärksamhet och SEO bra. “Eftersom sökmotorer premierar webbplatser med en god användarupplevelse leder ökad prestanda även till bättre sökmotoroptimering.”

https://webbriktlinjer.se/riktlinjer/54-optimera-webbplatsen-for-basta-prestanda/

Skillnaden på sajt vs. sociala medietjänster

“Men jag får ju autoplayade klipp i flödet på Facebook hela tiden” kan man höra ibland. Här finns dock flera skillnader att ta i beaktning.

Syfte och mål hos både plattform och användare exempelvis. Ett mål från Facebook är troligtvis att få dig att spendera så mycket tid det bara går på deras plattform och på den tiden hinna exponera så mycket reklam för dig som bara möjligt (det är så de tjänar pengar). Ditt syfte kan visserligen variera, kanske är det ren nöjesverksamhet men troligtvis är du i alla fall inte där primärt för att förkovra dig i djup kunskap om en tjänst eller produkt som sedan ligger till underlag för ett köpbeslut. Dvs. SM-plattformen tycker att det är okej att distrahera så mycket de bara kan för att behålla dig längre och du köper det för att dina behov/mål just nu är att slösurfa och gärna blir distraherad med fler roliga klipp (av samma anledning som man kan komma på sig själv att ha kollat youtubeklipp till 04 på morgonen – down the rabbit hole).  De tjänar också så otroligt mycket pengar på det att de anser att det är okej att fortsätta köra autoplay även om majoriteten av användarna upplever det som obra.

Det finns fler mekanismer involverade, exempelvis vet vi att det är ganska svårt att avsluta sitt konto på exempelvis Facebook för att plattformen gör så mycket mer – hela ditt kontaktnät med vänner och bekanta, messaging och intressegrupper är stora anledningar till att du återkommer. Men en företagssajt har kanske inte lika mycket som gör att du känner ett behov av att återkomma, speciellt inte om det finns gott om konkurrens. 

En spännande detalj är att den sajt med allra mest autoplayade videos, Youtube, har ett flöde utan autoplay.

Det finns möjlighet att stänga av autoplayfunktionalitet på de stora sociala medieplattformarna*. Detta går även att få till i webbläsare, kan rent av hända att det är inställt som standard på vissa, men är lite klurigare och kanske inte lika intuitivt. Webben är into the wild medan Sociala Media är appar, slutna ekosystem om man så vill, med user/account settings på given plats på ett annat sätt kan jag resonera.

* Instagram har inte funktionen rakt av men de har istället en inställning för tajt surfdata vilket bland annat ställer ner kvalitén på innehållet som konsumeras och i vissa fall (troligtvis) kan bromsa autoplay.

https://www.brid.tv/everything-you-need-to-know-about-the-video-autoplay-feature/

Social Media Accessibility: Turning Off Autoplay (2020)

Begränsningar i implementationer

I de allra flesta fall rekommenderar vi att använda sig av Youtube* för att strömma video. På sajter, genom att bädda in videoklipp. Detta har stora fördelar med SEO (Google äger Youtube och du får på så vis också en dubbelindexering av klippet), att du får en katalog på youtube (folk kan hitta till ditt material inom plattformen) och att du slipper hosta videon själv. 

Om du hostar själv påverkar utökad bandbreddsåtgång och utrymme serverkostnader. Prestanda m.m. blir med största sannolikhet inte lika bra som Youtube. För att inte tala om utvecklingskostnad för att koda en helt okej videospelare – där är Youtubes produkt extremt svårslagen.

Youtube tillåter inbäddning med autoplay-funktion men sedan en policyändring 2017 måste videoklippen också vara mute:ade för att det ska fungera. Med några undandtag så som om de har känt av tidigare interaktioner med domänen, om på desktop “Media Engagemnet Index”-värdet har passerats eller om användaren har lagt till sajten på sin hemskärm på telefonen eller installerat sajten som PWA på desktop (läs mer i länken under).

Argumenten för ändringen är enligt Google(översatt från engelska):

Webbläsare (med de största företagen i ryggen, Apple, Google, Microsoft, Mozilla reds. anm.) går mot striktare autoplaypolicys för att förbättra användarupplevelsen, minimera incitament att installera ad-blockers och reducera dataförbrukning på dyra eller belastade nätverk. Dessa ändringar är ämnade för att ge större “playback”-kontroll till användare […] (man bekräftar alltså det NN Group och Bokardo tryckt på, se ovan)

https://developers.google.com/web/updates/2017/09/autoplay-policy-changes

* i vissa fall Vimeo

Fler källor:

https://www.boia.org/blog/why-autoplay-is-an-accessibility-no-no

https://abilitynet.org.uk/news-blogs/why-autoplay-accessibility-issue

http://bokardo.com/principles-of-user-interface-design/

Examples of Bad UX Design on Websites

https://seoblog.com/autoplaying-videos-hurt-rankings/

https://www.advisorwebsites.com/blog/blog/general/hate-videos-autoplay

http://www.punkchip.com/autoplay-is-still-bad-for-all-users/ 

Turning Off AutoPlay

Summering:

• Autoplay tar kontroll från besökaren vilket är negativt ur usabilitysynpunkt
• Kan vara svårhanterat av personer med funktionsnedsättning, tillfällig som permanent
• Kan leda till sämre konvertering och sämre SEO
  • Bounce rates ökar m.m.
• Besökaren kanske inte alls är på din sajt med syftet att kolla på film vilket kan leda till irritation och är det svårt att pausa/stänga av är att stänga sajten den lättaste vägen ut
• Är man en frekvent besökare av din sajt blir det jobbigt att stänga av vid varje upprepat besök.
• Äter prestanda, både på server och sajt men det ställer även krav på besökarens hårdvara och uppkoppling
• Att spela upp med ljud är det största “big no-no”:et så krävs ljud för att ta till sig budskapet så finns egentligen inte autoplay som alternativ.
• Sociala medier är inte helt lätt att jämföra med en vanlig sajt då det finns flera aspekter att ta hänsyn till. Mål och syfte för både plattform och dig som användare. Hur mycket cash de gör på videoinnehåll. Hur stort ekosystemet är, vilket gör det svårt att inte återkomma.

Förslag

En tanke är att vi kanske sätter ett gemensamt förhållningssätt till videos och autoplay utifrån våra affärer och kunders affärer (en kortare, saklig diskussion med Team Webb, Team sälj och Team Inbound, eller representanter därifrån efter att folk fått chans att läsa på?) Så att vi kan vara enade i vår argumentation och diskussion med kund. Även om vi kanske inte håller med personligen fullt ut. Själv känner jag att det är svårt att känna sig ensam med tankar om detta, även om jag vet att några håller med och några är emot. Med ovanstående hoppas jag att alla kan få lite kött på benen och inspiration att formulera egna tankar kring ämnet. 

Initialt tänkte jag att det handlar mycket om mitt område och att det förväntas att jag svarar på/för den, men här ser vi att det är en fråga som även är multidiciplinär på så vis att den rör UX/UI/tillgänglighet, strategi, front-end, backend, SEO och inbound/konvertering m.m. Dessutom med nyansskillnader beroende på om vi bygger ett socialt nätverk eller stängt ekosystem/app kontra tjänster åt offentlig sektor eller PRO (bygger vi åt myndigheter/offentlig sektor finns lagstöd, från EU, åt ovan förda argument).