Browser Testing: Et stamtræ
En opgave driver webprofessionelle at distrahere mere end næsten alle andre: at teste om deres design fungerer lige så godt i en lang række browsere og på forskellige enheder.
Listen over browsere og platforme til at kontrollere mod bliver længere, og som designere bliver vores temperament kortere; IE6 vil sandsynligvis fungere i mareridt i mange år fremover!
Men at gøre vores arbejde i en stadigt voksende række situationer bliver stadig vigtigere.
Denne artikel fremhæver de mest almindelige problemer, der opstår ved testning med "de sædvanlige mistænkte" og forklarer, hvorfor en taktikændring snart kan være nødvendig. Hele dit perspektiv på kompatibilitetstest kunne ændre sig.
The Fantastic Five
Tilbage under browserkrigen måtte designere lide gennem konstant bickering mellem Internet Explorer og dets rival (nogle ting ændres aldrig). Vendepunktet kom, da nyere browsere forpligtede sig til at understøtte webstandarder, som gradvist eroderede Internet Explorer's dominans på browsermarkedet.
Tiderne ændrer sig. Den stigende relevans af mobile browserenheder og nye renderingsmotorer har ført til et ønske blandt designere at bremse behovet for at teste på alle tænkelige enheder.
Designere anvender nu at spille et nummer spil, normalt ved at teste deres arbejde i de fem eller seks mest almindelige browsere og derefter hævde dækning af resten. Selvom det ligner en let løsning, præsenterer den nogle få problemer, for i modsætning til i print passer en størrelse helt sikkert ikke til alle.
Selvom markedet er domineret af fem browsere, bør designere ikke se bort fra den orange "Andre" skive. Besøgende på andre browsere skal stadig indkvarteres.
Nøglen til nøjagtigt at præsentere dit websites dejlige design til slutbrugeren er renderingsmotoren. Man kan antage, at hvis du testede et websted i den mest populære browser for hver af Trident, Gecko, Commit og Presto-gengivelsesmotorerne, så kunne du sikkert ignorere andre enheder, der deler de samme motorer, fordi du ville have dækket de fleste brugere .
Jeg er generelt enig i, at testning i disse browsere alene ville fange problemer, der er synlige for brugeren, men testning i et bredere udvalg af browsere, enheder og systemer har sine fordele. Det er værd at undersøge potentielle problemer og beslutte, om yderligere test er påkrævet for at give de besøgende den bedst mulige oplevelse.
Trident (Internet Explorer), Gecko (Firefox), Webkit (Chrome og Safari) og Presto (Opera).
Ud over Breaking Point
Et indlysende problem i disse dage er enhed (eller plug-in) afhængighed, som påvirker browsere ikke kun på browser niveau, men på rendering niveau. Apple trofaste er helt sikkert klar over iPhone og iPad's problemer med Flash - og fordi Adobe og Apple begyndte at boo'ing hinanden, hører vi stadig om det.
Mens Flash faktisk håndterer den generelle gengivelse af indhold i sig selv, ville testning kun i de mest populære browsere ikke nødvendigvis vise problemer med det. Mens almindelige teknologier (både åbne og lukkede) er i fare for udelukkelse, kan udvidelsen af din testbase være kritisk.
Flash går uden for browseren, men ikke alle browsere kan gøre brug af teknologien.
Et andet problem er versionerne af rendering motorer. Selvom den nyeste og største browser er nøglen til at udnytte nye teknologier, kræver den fortsatte brug af ældre versioner (især de forskellige djævel-inkarnerede versioner af Internet Explorer), at vi begrænser os ikke kun til de nyeste bygger af en renderer, men også til dem, der stadig kan fungere i miljøer, hvor opgradering af software ville være uegnet eller umuligt.
Selv i kompatibilitetsmodus er det ikke muligt at teste i de nuværende browsere gamle versioner af browsere, der bruger tidligere versioner af gengivelsesmotorerne.
Internet Explorer 6.0 bruger en ældre og buggier-version af Trident-skrivebordsbrowserens renderingsmotor.
Gendannelsesproblemer kan også forekomme, hvis der er forskelle mellem enhed og platform, der bruges. Det siger sig selv, at testning af dit websted på en række mobiltelefoner og lommesurfere kan føre dig til randen af sindssyge, især i betragtning af, hvordan forskellige ting kan forekomme.
Design for sådan en lille skærm kan være en ganske opgave, især fordi konventioner for mobile enheder stadig er i deres barndom. Men dette problem gælder også desktop platforme. Det er ikke ualmindeligt at se mindre gengivelsesproblemer opskæres mellem Windows og Mac versioner af Firefox, for eksempel-en bekymrende tanke faktisk.
En Liste Apart bekymrer sig så meget om at gøre forskelle, at den har et separat design til mobile enheder.
En anden vigtig komponent, der kan afvige fra browser til browser, er JavaScript-motoren. I de tidlige dage var det eneste spørgsmål om JavaScript, om det skulle bruges.
I disse dage har browsere med samme visuelle renderingsmotor ofte forskellige JavaScript-motorer (Chrome og Safari er et perfekt eksempel). Brug af flere browsere til at benchmarke dit websites evne til at gøre disse smukke jQuery-scripts er lige så vigtigt, især hvis dit design har en masse funktionel interaktivitet.
Chrome-eksperimenter viser fremvisningens ydeevne for Googles browser.
Og endelig et emne, der får nogle mennesker til at juble og andre stønner: tilgængelighed! I mange menneskers øjne er tilgængelighed og den måde, en browser gør på et websted, ikke relateret. Men det er værd at bemærke, at når folk besøger dit websted, kan deres tilgængelighed software tvinge dem til at bruge en bestemt browser, en der understøtter computerens skærmlæser eller deres tilgængelighed enhed.
I sådanne tilfælde kan mindretalsbrowsere overses helt. Husk at dit design også skal fungere for disse mennesker, hvis behov ofte bliver glemt.
Opera kan have en lille markedsandel, men dens stemmeindstillinger kan være en livredder for dem med særlige behov.
Den langsigtede kur
På grund af alle tilgængelighedsbehovet kan forskellige JavaScript-motorer, tværplatformsproblemer, skærmforskelle, teknologiafhængigheder som Flash og mobilrevolutionen, undskyldes for at modvirke, hvor meget test er nødvendig. Du skal stadig se på målgruppens behov for at se, om udvidelse af din nuværende test-arbejdsgang vil give langsigtede resultater.
Tag dig tid til at kommunikere med dine besøgende. Måske kan du køre en afstemning, spørger hvilke browsere og enheder de er på, og undersøge derefter dine statistikker for at se, om de har nævnt måder, du kunne forbedre eller udvide interaktionen på dit websted.
Du kan måske finde ud af, at du har brug for et mobildesign, eller måske er der entusiasme for en iPhone-app, eller du kan bare få flere fejlrapporter til minoritetsbrowsere. Opmuntrende feedback er afgørende i den evolutionære proces af design.
Statistikpakker kan give en klar ide om, hvilke enheder der er blevet brugt til at besøge dit websted.
At nå kunderne i en stadig bredere skala er noget, hver website ejer bør overveje i forbindelse med brugervenlighed. God kommunikation skaber en følelsesmæssig forbindelse med besøgende; de føler, at deres interesse bliver valideret og deres tid brugt, og det kan gøre klik til kunder.
Opholder sig på toppen af tingene på teststadiet, så går det ud over at fastsætte visuelle fejl. Et større testfelt kan føre til nye funktioner og unikke måder at navigere på hjemmesiden. En belønning kunne være et dybere bånd med dit websteds faste besøgende og fans.
Start dine motorer
Hvordan du vil udvide testprocessen er uden for denne artikels anvendelsesområde, men den enkleste måde at forbedre dit website udseende og brugeroplevelsen er ved at sikre, at alt ser ud til at præsentere på skærmen.
Nedenfor er en liste over en bred vifte af browsere, både mobil og desktop, som kan hjælpe dig med at udvide din horisont som du tester. Mens nogle vil gøre dit design det samme, skal disse browsere hjælpe dig med at fastslå omfanget af de tests, du skal udføre.
Flere browsere vil uden tvivl blive oprettet (og nogle kan allerede eksistere), så overvej også fremtiden.
Både desktop og mobile platforme har en bred vifte af renderingsmotorer.
Mens browsere bygget med Trident, Gecko, Webkit og Presto er inkluderet (sammen med deres ældre varianter Tasman, Mozilla og KHTML), er andre renderingsmotorer med en brugerbase ikke medtaget her på grund af det meget begrænsede udvalg af enheder, der understøtter dem.
Enheder og browsere med unikke gengivelsesmotorer (tekst, visuel og mobil), som ikke er nævnt her, kan testes individuelt og kunne potentielt øge kompatibiliteten af dit design.
Jeg anbefaler de browsere, der fremhæves nedenfor for hver platform. Med undtagelse af Mac, der bruger Tasman, bruger alle disse Trident renderingsmotoren:
Alle disse anvendelser af desktop-gengivelsesmaskinen Gecko (tidligere Mozilla):
Alle disse bruger Webkit-renderingsmotoren (eller KHTML-gaffelen i Konquerors tilfælde):
Fordi Presto er en proprietær platform, er det ikke overraskende, at det er begrænset til Opera-projekter:
Over regnbuen
Måske er dit websted helt fri for fejl. Måske ser det godt ud i enhver situation. Men hvis du overvejer den store skala af kravene til kompatibilitet på tværs af platforme, gør ikke længere de store fem et præcist billede af webbrugere som helhed.
Hvis du kun tager en ting fra denne artikel, så forstår du værdien af at bruge mere tid på at analysere dine besøgendes behov, fordi det vil hjælpe dig med at revurdere testfasen for at omfatte et bredere udvalg af scenarier.
Brug ekstra tid på at gå over browsere for hver gengivelsesmaskine, og glem ikke om følgende: Andre operativsystemer, som måske har forskelle; andre typer enheder (f.eks. mobiler), hvilket kan gøre meget anderledes; unikke JavaScript renderers, som har konsekvenser for hastighed; ældre versioner af webbrowsere; og generelt er det bredere omfang, der er nødvendigt som kode, udviklet og ændrer selve web.
Resumé
I en verden, hvor folk er villige til at investere tid, indsats og penge til at gøre deres hjemmesider så venlige som muligt ved catering til søgemaskiner og sociale medier, så du sikrer, at dit design fungerer (i stedet for at fokusere på perfektion af pixel - husk, er internettet ikke print) kan være mere værdifulde for de hundredvis eller tusinder af mennesker, der har adgang til dit websted på forskellige måder.
Det kan helt sikkert betyde forskellen mellem at tiltrække kunder og have frustrerede "Hej og farvel" besøgende.
Skrevet udelukkende til WDD af Alexander Dawson
Hvordan går det med at teste dine omhyggeligt udformede designs, så de udfører fleksibelt? Har du planer om at optimere din test-arbejdsgang, så den er mindre restriktiv? Kan din hjemmeside tilskynde til mere tilbagemelding fra besøgende om dens design?