Online Solutions
Onbegrensde mogelijkheden
Wanneer je betrokken bent bij de ontwikkeling van een online project wil iedereen graag iets moois maken. Of het nou een website voor de werving van nieuwe toptalenten is, of een applicatie voor internetbankieren, elk bedrijf wil trots zijn op zijn product. Dit zie je dan ook terug in elke stap van het ontwikkelproces. De ontwerpers van het visueel en interactie ontwerp maken de mooiste, modernste en meest bruikbare ontwerpen naar de laatste trends en inzichten. Wanneer dit design vervolgens in het ontwikkeltraject terecht komt, heeft iedereen zin er een mooi eindproduct van de maken, met ronde hoeken, transparantie, schaduwen om een dieptegevoel te creeeren, geavanceerde invoermethodes enzovoort.
Bedrijven willen echter niet alleen dat hun nieuwe online product er flitsend uit ziet, maar ook dat hun product of dienst door zoveel mogelijk mensen gebruikt kan worden. Daarom is een een veelgehoorde wens dat het goed moet werken in alle browsers. Aangezien elke browser tegenwoordig goed kan omgaan met nieuwe standaarden en technieken, wordt het ontworpen online product in alle situaties weergegeven zoals het hoort… Toch?
De praktijk…
Helaas is de realiteit vaak anders. Inbegrepen in de eis om alle browsers te ondersteunen vinden we ook verouderde browsers die her en der nog in gebruik zijn in het bedrijfsleven. Omdat het soms kostbaar is (of lijkt) om alle systemen te voorzien van de nieuwste browsers, worden voornamelijk oudere versies van Internet Explorer (tot aan versie 6) nog door een deel vande doelgroep gebruikt.
Wanneer een nieuw ontwerp rekent op de modernste technieken en weergaveopties, terwijl de business vraagt om ondersteuning van browsers van meer dan tien jaar oud, ontstaat een schijnbaar onwerkbare situatie. Het is eenvoudigweg niet realistisch om te verwachten dat een ontwerp in elke browser op de pixel af identiek op het beeld verschijnt. Voor recente browsers lukt dit aardig, maar met name oudere versies van de producten van Microsoft hebben nogal een ‘ unieke’ manier van websites presenteren. Vroeger liepen zij in mogelijkheden voorop, maar weken mede hierdoor ook enorm af van de geldende standaarden. Het kost daarom onevenredig veel tijd om een nieuw design zowel in moderne browsers als de oudere browsers identiek te maken.
Hoe kunnen we deze situatie beter te maken?
Leg uit aan iedereen die je tegen komt dat webtechnologie zich enorm snel ontwikkelt. Dat het onrealistisch is om te verwachten dat oudere browsers precies hetzelfde resultaat kunnen geven voor een website als de nieuwste browserversies. Dat Internet Explorer 6 bijvoorbeeld niet eens meer ondersteund wordt door zijn eigen fabrikant, dus waarom moet dat voor een spiksplinternieuwe site dan nog wel?
Wanneer iedereen om je heen begrijpt hoe de browser-wereld in elkaar steekt, zal het ook makkelijker zijn om een projectresultaat te behalen dat mooi, modern en goed werkt in de nieuwste browsers. Terwijl voor dat ene procent van de markt dat niet in staat is om een nieuwe browser te gebruiken, een aangepaste, functioneel volledig werkende versie gepresenteerd kan worden, die past bij het tijdperk van de betreffende browser. Door verwachtingen bij te sturen en deze te baseren op een realistisch beeld van de markt en de techniek, zal iedereen uiteindelijk tevreden zijn met de behaalde resultaten.
About the author
+Sjoerd Kranendonk is Hippo CMS Consultant, webdeveloper en bruggenbouwer bij Capgemini. Volgens familie en vrienden 'doet hij iets met internet' voor grote klanten. Voor klanten slaat hij de brug tussen Online wens en realisatie. Liefst wel met fijne gebruikersinteracties en mooie plaatjes natuurlijk.
- More at
Titel is een goede binnenkomer, helemaal mee eens! Artikel kan nog wel een leuke link of twee gebruiken imho.
“Wat kunnen we er aan doen?”, ik merk dat het helpt om per “afwijkende” browser in een vroeg stadium een spec op te nemen dat/wat die browser moet supporten. Die specs krijgen dan ook hun eigen kostenschattingen in uren of euri: de taal van de business
Uiteraard moet je dit in vroeg stadium afvangen en duidelijk maken. Dat hoort bij mijn laatste stuk, de verspreiding van de kennis en bewsutwording bij niet-techies hoe het echt zit. Wanneer je van meet af aan duidelijk maakt dat er duidelijk identificeerbaar meerwerk is aan het ondersteunen van afwijkingen van de standaard dan zal de business daarin zelf zijn conclusies kunnen trekken (op basis van tijd/geld/roi afwegingen).
Niks verouderde browsers, sléchte browsers. En die sterven gelukkig langzaam uit. En daarmee gelukkig ook de slecht gebouwde websites.
“eis om alle browsers te ondersteunen” is een eis die business niet hoort te stellen. De business geeft aan ‘WAT’ de deskundigen zeggen op basis daarvan ‘HOE’.
De website-bouwers hebben zich zelden gestoord aan geldende Internet-standaarden (W3C). Niet weinig geholpen door de IE-bouwers.
Waren websites netjes conform standaarden gebouwd dan waren ze voor het overgrote deel ‘backwards compatible’ voor nieuwere browsers.
Dan had je wellicht wat multimedia-gimmicks gemist. Die veel gebruikers tóch al uitzetten. Niets zo amateuristisch als ‘U hebt de Silverlight-plugin nodig’ of een volledig Flash-driven website.
Dus gewoon W3C-proof netjes ‘AnyBrowser’een website bouwen. Dát is de vereiste spec.
En wég met die verouderde MS-browsers. Die doorgaans sterk onveilig zijn.
Enne ….. deze webpagina voldoet óók al niet aan de standaarden – zie http://validator.w3.org/
Waarom niet?
Peter, bedankt voor je aanvullingen en kritische blik!
Dat browsers langzaam uitsterven, is natuurlijk juist de oorzaak van ons probleem.
Waneer de business de vraag/eis neerlegt dat de site door iedereen toegankelijk moet zijn, is het aan de experts om door te vragen wie bedoeld wordt met iedereen (accessibility, talen, desknots (mobiel,tablet, enz) en daarbinnen weer in hoeverre minimaal en wat wenselijk is.
De bouwers van Internet Explorer hebben zcih lange tijd enoog in het land der blinden gevoeld, met een overrompelend marktaandeel dat inmiddels gelukkig gekanteld is naar een meer nederige houding en de wil om ook aan de standaarden van het W3C te voldoen.
Ik ben het ermee eens dat je zoveel mogelijk volgens de geldende standaarden moet bouwen, en anders mag in elk geval niets misgaan, maar bij oudere browsers een simpelere versie weergeven kan wel een optie zijn.
Ook speelt soms een rol dat er doorontwikkeld wordt of gebruik wordt gemaakt van een bestaand platform (zoals dit blog) waarbij je natuurlijk de abitie moet hebben het te verbeteren (die hebben we) maar dit moet je er niet van weerhouden je kerntaak (in ons geval bloggen) uit te voeren.
Je gaat hier veel te kort door de bocht. De vraag van de business is immers een wat: “mijn site moet werken voor 95% van mijn klanten” en btw, 15% draait < IE8.
Het idee dat webstandaarden heilig zijn is ook onzin. Een standaard is een hulpmiddel maar geen doel.
Als 97.5% van mijn gebruikers aantoonbaar flash beschikbaar heeft, waarom zou ik die tech uitsluiten? Omdat er een anti flash lobby is en het cool klinkt als developer om als een schaapje mee te blèren in hoe crappy het allemaal is?
Wat heb ik aan een standaard, als die standaard bij 40% van mijn bezoekers een halfslachtige visual/UX oplevert? Ja je kan roepen dat je standaards doet. Jeuh.
Leuk stuk Sjoerd! Bij mij komen inderdaad dezelfde gedachten omhoog als bij Peter. De slechte browsers sterven uit.
Met de auto-update functies in chrome, firefox, opera, etc. voorkomt men achterstand en wordt het hoge adoptie-niveau behouden. Ik voorzie een rooskleurige toekomst waarin wij Onliners aanzienlijk makkelijker zullen kunnen werken met betrekking tot compatibiliteit. Ik ga er alvast van dromen!
Tot die tijd is het belangrijk dat gebruikers van verouderde browsers zich ervan bewust worden dat zij (open deur) moeten updaten. Het is immers ook in hun belang omdat verouderde browsers grote veiligheidsrisico’s met zich meedragen. Tevens een argument voor de aanbiedende partij is dat deze veiligheidsrisico’s ook voor hen kunnen bestaan bij het ondersteunen van te oude browsers. Denk hierbij aan de veiligheid bij betaalprocessen.
Als je veiligheid van je bankprocessen af moet hangen van de versie van de browser van de gebruiker dan is er iets serieus mis lijkt me?
Daarnaast vraag ik me af in hoeverre nieuwe browsers meer of minder gevoelig zijn voor man in the browser attacks bijv. Zijn daar ergens stats van dat jij weet?
Ik doelde in dit geval meer op de doorsnee webshops met betaalfunctie dan op bankprocessen. Ik kan me inderdaad niet voorstellen dat dit bij bankprocessen een issue zou moeten zijn.
Met betrekking tot de man in the browser attacks voorspel ik een afname. Vooral doordat de nieuwste browsers vanuit een sandbox opereren. Maar ik heb geen stats om dit te ondersteunen.
De standards zijn goed om de basis van een site te bouwen. Daarna is het aan de business om te bepalen waar het afsnee punt ligt. Welke browser ondersteuning nog gerechtvaardigd is. Op een high traffic site kan 2% nog 50.000 pageviews IE6 gebruikers betekenen.
Case: een MKBnieuws site met de nadruk op klein-bedrijf laat 8% IE6 gebruikers zien. Hardware wordt traag vervangen, gebruikers zijn niet handig in upgraden, dus een te substantieel deel moet nog wat aardigs kunnen zien.
Dat betekent niet dat de gebruikers van oudere browsers dezelfde ervaring moeten hebben als die van de nieuwere. Maar wel een werkbare ervaring. Pixelperfectness hoeft niet. Werkbaarheid wel. Je kan bijna spreken van accessibility op browser niveau.
Devs zijn, hoe vervelend het ook mag zijn, niet de beslissers over dit soort zaken. De commercie bepaalt wat de support moet zijn.
Dank voor je reactie! Zeer zinnig, en juist omdat de commercie (business) bepaalt wat ze willen ondersteunen, is het de taak van de techneuten om daarin goed voor te lichten.
Als je je aan de standaards houdt dan werkt het op 100% van de browsers en andere platforms. Ook fijn voor visueel gehandicapten.
En de browser van de gebruiker is inderdaad een stukje van de veiligheidsketen.
“Als je je aan de standaards houdt dan werkt het op 100% van de browsers”
Euh….. nee.
Volgens mij lopen hier twee dingen door elkaar. Standaarden en toegankelijkheid.
Als je een website volgens de standaarden bouwt, zul je wel minder verschillen tussen de rendering in diverse browsers zien. Maar als je je bijvoorbeeld houdt aan standaard CSS 2 is hiervan nog niet alles identiek in IE6 en Chrome16. Daar moeten dus mogelijk uitzonderingen geschreven worden voor IE6 en dat kan kostbaar zijn. Of pragmatische keuzes voor een afwijkende maar werkbare weergave.
Toegankelijkheid of accessibility hangt hier wel mee samen omdat het doel is zoveel mogelijk mensen toegang te verschaffen tot jouw informatie. Het is dus in je belang dat dat doel ook voor de 2% IE6 gebruikers en 1% screen-reader gebruikers bereikt wordt. de preciese grenzen en doelstellingen hangen natuurlijk helemaal van de business af.
Volgens mij kun je de discussie beter houden over identiek op de pixel af. Dat is een concept vanuit de gedrukte media wat helemaal niet op het web thuis hoort. Wanneer je je aanpast aan het medium, waar kleine verschillen per browser, OS, schermresolutie, etc., gewoon bij horen, dan is de vervolgens de stap te maken naar graceful degradation en hoef je browsers niet meer zo hard te onderscheiden in wel en niet ondersteund.
Ahh agreed! Dit is hoe Yahoo het doet:
http://yuilibrary.com/yui/docs/tutorials/gbs/
Vaak een goed startpunt, zeker voor high-traffic sites imo.
De thread begint waarachtig op een discussie M$ vs. SGML te lijken. ;-J
Dat is omdat er nog steeds een cult is die vind dat een afgesproken standaard een belangrijkere standaard is, dan hetgeen voor de meeste gebruikers standaard is
En dat is dus waar volgens mij de wrijving evt. zit. Je hebt een idee van hoe het hoort en er is wat in de praktijk nodig is. Daar probeer je balans in te vinden toch? Duurzame code die wel (zoals Wim zegt) op een nette manier met oudere browsers om gaat.
We moeten ons niet blind staren op de cutting edge, maar werken met oog voor de toekomst EN het verleden
Pingback: Sloop de oude browser | Capgemini Online Solutions
Pingback: Verschillen in browsers aanpakken: Modernizr.js vs conditionele html class?