Ajax is hot. Het is momenteel een veel besproken begrip op het Internet. Met Ajax bedoel ik in dit verband niet de Amsterdamse voetbalclub of de Griekse held uit de Ilias. Het Ajax waar ik het in dit artikel over heb is een samensmelting van de woorden Asynchroon JavaScript en XML.
Met Google als lijstaanvoerder schieten de ajax toepassingen momenteel als paddestoelen uit de grond. Google Gmail1, Google Maps2 en Flickr3 hebben hun succes grotendeels te danken aan Ajax.
Modeketen Gap4 investeerde zelfs 10 miljoen dollar in een redesign van haar website5. Het doel was om het aantal klikken per bezoeker terug te brengen en zo het online winkelen op haar website makkelijker te maken. Vanuit technologisch en gebruiksvriendelijkheids perspectief is de site zijn concurrentie inmiddels mijlenver vooruit. Hoe men alles dit realiseerde? Met het wondermiddel Ajax natuurlijk!
Business 2.0 plaats Ajax zelfs bovenaan de lijst van zeven technologieën die de wereld zullen veranderen6.
Ajax de technologie
De term Ajax werd op 18 februari 2005 in het artikel “Ajax: A New Approach to Web Applications7” geïntroduceerd door Jesse James Garret. De nieuwe benadering houdt in dat webapplicaties steeds interactiever worden. De grens tussen desktop software en webapplicaties vervagen.
Als voorbeeld van een Ajax toepassing noemt Garret Google Suggest8. Terwijl je een zoekterm intikt krijg je tegelijkertijd een overzicht van andere interessante zoektermen.
Een ander voorbeeld dat hij noemt is Google Maps. Inzoomen, uitzoomen, naar links, rechts onder of boven alles gebeurt in een vloeiende beweging.
Volgens Garret maakt Ajax maakt gebruik van de volgende technieken:
- XHTML en CSS voor de presentatie volgens de standaarden van het W3C;
- Het Document Object Model voor het dynamisch tonen van informatie en voor interactie;
- XML en XSLT voor de opslag, aanpassing en transport van gegevens;
- Het XMLHttpRequest object9 voor asynchrone communicatie;
- JavaScript om alles aan elkaar te binden.
Robin Good denkt dat het grote succes toch vooral te danken is aan het XMLHttpRequest object10.
Zonder XMLHttpRequest kan je echter ook de interactiviteit van Google Maps evenaren. De interactieve kaart van Zwitserland11 is hiervan het mooiste voorbeeld. Qua interactiviteit evenaart het met gemak Google Maps. Het is echter volledig opgebouwd uit HTML en JavaScript12.
En zo zijn er vele discussies gaande over wat nu wel en wat nu geen Ajax geen is.
Peter-Paul Koch tot slot komt in het artikel “Ajax, promise or Hype13” tot de conclusie dat XML en XMLHttpRequest niet persé nodig zijn voor het maken van interactieve webapplicaties. XSLT voegt helemaal weinig toe ten opzichte van JavaScript. Het enige dat dus overblijft zijn XHTML, CSS en DOM (JavaScript).
Het leuke is, deze technieken bestaan al sinds 199814. In het boek “designing with web standards15” van Jeffrey Zeldman worden XHTML, CSS en DOM uitvoerig behandelt.
Volgens Zeldman kunnen we een webpagina opdelen in drie delen16:
- Structuur;
- Presentatie;
- Behavior.
Structuur
Het eerste aspect van webontwikkeling is de structuur. Dit is de virtuele ruggengraat van een website. Alle verdere facetten zullen gebaseerd zijn op een stevige structuur. De structuur wordt vormgegeven met XHTML.
Presentatie
Het tweede belangrijke aspect van een website is de presentatie ervan. Hoewel de structuur minstens even belangrijk is, willen de meeste mensen naar een mooie esthetisch verantwoorde interface kijken. De presentatie kunnen we opmaken met CSS.
Behavior
Het laatste deel van een web document is hoe een website zich gedraagt. Een site kan aan de hand van een standaard object model (het W3C DOM) dynamische effecten genereren. Dit DOM werkt met CSS, XHTML en ECMAScript 262 – de standaard versie van JavaScript.
De waarde van webstandaarden
Omdat de structuur, de presentatie en behavior van elkaar gescheiden zijn is het mogelijk om één ervan te wijzigen zonder consequenties te veroorzaken voor de andere. Zo kan er eenvoudig nieuwe inhoud aan een pagina worden toegevoegd, zonder het risico dat de lay-out kan beschadigd raken.
Zo kan je ook de lay-out wijzigen zonder de inhoud te schaden. Zijn er lezers die klagen dat een bepaalde fontgrootte te klein is? Eenvoudig een regel wijzigen in het CSS bestand en de hele site reflecteert de verandering. Nood aan een printer vriendelijke versie? Dan kan er een aparte style sheet aangemaakt worden die ervoor zal zorgen dat je paginas prachtig zullen afgedrukt worden, hoe verschillend het resultaat op het scherm ook mag zijn.
Bron: Webstandaarden: scheiding van structuur en opmaak17
De waarde van webstandaarden is inmiddels wel aangetoond. Toch blijft het raar dat er pas nu aandacht voor is. De technieken bestaan immers als meer dan zeven jaar! Waarom is er dan nu pas aandacht voor? Een bevredigend antwoord op deze vraag is niet te geven.
Waarom nu pas aandacht voor Ajax?
Ik heb wel de volgende hypothese. Het Internet is een volwassen medium en bedrijven eisen steeds meer kwaliteit. Hierdoor is het kaf van het koren gescheiden. De hobbyisten hebben het veld geruimd voor de professionals. De groei van een op tabellen gebaseerde lay-out naar en op webstandaarden gebaseerde lay-out is vooral evolutionair van aard en heeft vooral te maken met natuurlijke selectie. Het leren van JavaScript is veel moeilijker dan het leren van XHTML en CSS, maar nu steeds meer ontwikkelaars deze laatste twee onder de knie hebben is het tijd voor een nieuwe uitdaging. Google Maps heeft voor vele ontwikkelaars de ogen geopend. Deze zijn druk aan het ontwikkelen gegaan wat momenteel resulteert in een wildgroei aan interactieve Internet toepassingen.
Ajax en gebruiksvriendelijkheid
Hoewel Ajax vanuit technologisch perspectief misschien niet de best mogelijke benaming is, blijven we dit begrip verder wel hanteren voor het gemak van de discussie.
Uiteindelijk zijn het de eindgebruikers die bepalen of een technologie slaagt of niet. Ajax is nu vooral nog iets voor de vernieuwers en de vroege aanvaarders, om maar even in de termen van Rogers18 te spreken. Of het echter geaccepteerd zal worden door de grote meerderheid is volledig afhankelijk van de uiteindelijke voordelen voor de gebruiker. Met andere woorden “wat schiet ik er mee op”
Het einde van World Wide Wait
Internet wordt wel eens gekscherend het World Wide Wait19 genoemd. Vaak is wachten, wachten, wachten ook wel een heel passende benaming. Dat dit leidt tot heel veel frustratie leidt blijkt maar weer eens uit een discussie over de traagheid van de onlangs gelanceerde postbank site20.
De voorbeelden Google Gmail, Google Maps en Flickr hebben een ding met elkaar gemeen en dat is dat er van wachten haast geen sprake meer is. Dankzij Ajax lijkt er een einde te zijn gekomen aan dat eeuwige wachten21.
Traditioneel gezien kenmerkt Internet zich door haar start-stop-start-stop natuur van interactie. De gebruiker van een website voert een actie uit. Dit gaat naar de webserver toe en deze presenteert vervolgens het resultaat aan de bezoeker.
Ajax is als het ware een extra laag tussen de gebruiker en de server. Op een actie van de gebruiker vindt vrijwel onmiddellijk feedback plaats.
Foutenreductie dankzij Ajax
Allemaal hebben we wel eens een formulier ingevuld die, nadat we op de verzendknop klikten, ons vrolijk meedeelde dat we onze postcode niet juist hebben ingevoerd.
Waarom gebeurt dit? Vragen we ons af! Nu vullen we dit formulier weer in maar dan heeft de ontwikkelaar gebruik gemaakt van Ajax. We vullen weer onze postcode in maar voordat we op de verzend knop drukken waarschuwt de website ons al dat we een fout gemaakt hebben.
Dankzij de mogelijkheid van directe feedback kunnen fouten worden voorkomen.
Flow-ervaring dankzij Ajax
De zoekmachine A9.com22 is ook een mooi voorbeeld van wat allemaal mogelijk is. Door het eenvoudig aanvinken van een selectievakje zoek je in meerdere categorieën of laat je alle zoekresultaten van een categorie weg. De resultaten krijg je vrijwel onmiddellijk na het aanvinken van het selectievakje.
Het is de snelheid waarmee de website reageert op onze keuze dat Ajax zo geliefd bij de bezoekers maakt.
De Amerikaanse psycholoog Roger Miller stelde eens het volgende rijtje op23:
- 0,1 seconde gebruikers hebben het gevoel dat het systeem onmiddellijk reageert;
- 1 seconde gebruikers zijn nog geconcentreerd;
- 10 seconden. gebruikers gaan andere dingen doen.
De interactie met de website gaat zo soepel dat we als het ware in gemakkelijk in een flow-ervaring24 geraken. We vergeten onze omgeving en verliezen de tijd uit het oog. We gaan volledig op in het systeem. Het is gewoon leuk om met de website te spelen.
Het einde van Pogo-sticking
Het heen en weer gaan van de productenlijst en de detailpagina van het desbetreffende product wordt ook wel pogo-sticking genoemd. Jared Spool stuitte op dit fenomeen toen hij de invloed van productlijsten op de verkoop van van e-commerce sites onderzocht.
Dit heen-en-weer surfen doen mensen als de productenlijst niet voldoende informatie biedt. Ze moeten dan een stap verder de website in duiken. Als ze de gedetailleerde informatie hebben gevonden die ze zochten keren ze weer terug naar de productenlijst en kiezen een ander product uit zodat ze een vergelijking kunnen maken.
Bezoekers die op basis van de productlijst al voldoende informatie hebben gaan in 55% van de gevallen over tot aankoop. Bezoekers die heen-en-weer moeten surfen doen dit slechts in 11% van de gevallen25.
Met Ajax-technologie is het mogelijk om per product meer informatie aan te bieden zonder dat de gebruiker daarvoor naar een heel nieuwe pagina hoeft te gaan.
Stel ik wil een broek kopen bij de Gap.com. Ik klik op Men en dan Jeans. Vervolgens krijg ik een overzicht spijkerbroeken. Ik zie eentje die ik op zich wel leuk vindt. Ik kan nu op de “quick look” button klikken. Vervolgens verschijnt er een pop-up scherm in mijn beeld en zie ik de spijkerbroek in het groot. Ik kan de kleur kiezen en zie een overzicht van de maten. Het is toch niet helemaal wat ik zocht. Ik sluit het pop-venster weer af en selecteer een andere spijkerbroek. Zo kan ik zeer snel alle producten even vergelijken voordat ik mijn keuze maak. Ajax maakt dus een einde aan pogo-sticking.
Ajax en toegankelijkheid
Een veel gehoord argument tegen Ajax is dat de website daardoor niet toegankelijk is. In het voorbeeld van Gap.com is dat ook het geval. Indien de browser geen JavaScript ondersteunt werkt de site niet. Maar dit is eerder een keuze van de bouwer dan van een beperking van de technologie.
Het mooiste voorbeeld is misschien nog wel Google Suggest. Je tikt een zoekterm in en krijgt een overzicht van allerlei andere interessante zoektermen. Schakel je echter JavaScript uit dan werkt de zoekmachine nog steeds alleen krijg je nu niet dat extra overzichtje.
Een perfect voorbeeld van hoe je Ajax moet zien. Het is die Jus waardoor het vlees net even lekkerder smaakt. Maar net zoals het vlees de basis is voor het gerecht zo is toegankelijkheid de basis voor een webapplicatie.
Bronnen
- Google Gmail
- Google Maps
- Flickr
- Gap.com
- New Approach From Gap to Cut Down on Clicks
- Seven Technologies That Change Everything
- Ajax: A New Approach to Web Applications
- Google Suggest
- Dynamic HTML and XML: The XMLHttpRequest Object
- What Is Ajax And What Is It Good For
- Interactieve kaart Zwitserland
- DHTML 05
- Ajax, promise or hype?
- History of the Web Standards Project
- Amazon.com: Designing with Web Standards
- Zeldman video keynote
- Drievuldigheid van Webstandaarden
- Innovatietheorie van Rogers
- World Wide Wait: Information From Answers.com
- Postbank lanceert nieuwe site
- Ajax: How To Weave A Faster Web
- A9.com Home Page
- Response Times: The Three Important Limits
- Flow (psychology) – Wikipedia, the free encyclopedia
- Are the Product Lists on Your Site Reducing Sales? (Pas op PDF!)
17 reacties op "Ajax ontrafeld"
Complimenten voor dit artikel!!!
Maar ik, als AJAX-leek vraag mijzelf het volgende af:
Als je allerlei gegevens op één scherm wilt/kan tonen, moet dan alle data bij het opbouwen van de pagina worden opgehaald? (database, afbeeldingen etc. etc.)
Moet je geen rekening houden met performance?
Volgens mij is het niet zo dat je alle gegevens uit de database hoeft te halen om dan vervolgens te bepalen wat je wel en niet wilt laten zien.
Kijk maar eens naar [url=http://www.a9.com]A9.com[/url] ik zoek op het web naar usability en krijg al snel enkele resultaten. Als ik ook wil zien wat wikipedia over usability schrijft vink ik eenvoudig dit vakje aan. Ik moet even wachten en zie dan ook het resultaat in wikipedia. Pas als ik het vakje aanvink wordt deze data geladen. Als ik nu het vinkje uitschakel zijn de wikipedia resultaten weer weg. Vink ik het weer aan dan heb ik ze weer onmiddellijk in beeld (het systeem onthoud dus de resultaten)
OK. Maar in dat geval kan je een streep zetten door “Het einde van World Wide Wait”.
Immers moet je wachten totdat het item is geladen.
Puur theoretisch gezien moet de bezoeker inderdaad wachten. Waar het om gaat is of deze dat ook zo ervaart.
In het artikel noem ik het rijtje van Roger Miller.
* 0,1 seconde gebruikers hebben het gevoel dat het systeem onmiddellijk reageert;
* 1 seconde gebruikers zijn nog geconcentreerd;
* 10 seconden. gebruikers gaan andere dingen doen.
Om A9.com maar weer even als voorbeeld te nemen. Zodra je een extra categorie toevoegt, zie je vrijwel onmiddelijk (onder de 0,1 seconde) een melding loading. Vrij snel (onder 1 seconde) zie je dan de zoekresultaten.
Het World Wide Wait concept gaat over het “gevoel” te moeten wachten. Doordat er met Ajax constant interactie is zal dat gevoel te moeten wachten snel afnemen.
Op zich een positieve ontwikkeling. Ik hoorde links en rechts weleens vage verhalen over AJAX en had er nooit eerder echt veel onderzoek naar gedaan. Je kan stellen dat je met AJAX inderdaad constant interactie zou kunnen hebben, alhoewel ik me afvraag in hoeverre dit voor alle bedrijven mogelijk is. Wat er feitenlijk gebeurd is dat er bij een actie van de gebruiker wel database-communicatie is, maar deze dit niet merkt in de vorm van nog niet opgebouwde pagina’s. Voor een groot bedrijf als google met een groot serverpark is het appeltje eitje om contstant database verzoeken te krijgen en af te handelen. Wat ik me dus afvraag is of een kleiner bedrijf met minder zware servers bij veel requests, deze zelfde requests wel aankunnen.
Een leuk voorbeeld is een zoekmachine die bij het intypen van 1 letter als een aantal resultaten laat zien. Bij elke letter die de gebruiker typt, wordt er een query gedaan. Dit lijkt me een erg belastende taak.
De denkwijze van Ajax is leuk en aardig. De technieken ervoor bestaan dat misschien al wel sinds 1999. Maar ze zijn er in de eerste instantie niet voor gemaakt. En dat merk je.
Voorbeeld: als programmeur erger ik me kapot dat ik niet eens mijn eigen gegenereerde broncode kan bekijken.
Ander voorbeeld: het javascript commando wat ajax definieert is verschillend per browser.
Ik geloof niet in Ajax met de huidige technieken. Belangrijker is dat ik de toegevoegde waarde niet zie. Ik vind veel sites die ajax gebruiken onbetrouwbaar overkomen. Inclusief gmail. Er gebeuren dingen die ik niet verwacht; dit wil ik niet.
De term ajax vind ik nog wel het ergste. Ik stel voor dat we het dhtml gaan noemen.
Erik,
Wat is de reden dat je de broncode niet kan bekijken? Hier ben ik eigenlijk wel nieuwsgierig na, ben verder niet uitermate bekend met Ajax.
Ik kan je mening delen dat je niet in Ajax geloofd met de huidige technieken, ik vind de manier waarop, aardig omslachtig.
Echter, de betrouwbaarheid van websites hangt naar mijn mening niet samen met de achterliggende technieken die er worden gebruikt. Flash is momenteel ook razend populair, en daarmee kan je nog veel ‘leukere’ trukjes uithalen. Nu ben ik geen groot voorstander van flash-applicaties, maar daarbij gebeuren ook wel dingen die ik soms niet verwacht, maar desondanks als positief worden ervaren door mij. Dit lijkt me dan meer een punt voor een Functioneel ontwerper om de aandacht goed op te richten.
Zitten er feitelijk ook verschillen dan tussen DHTML en AJAX? Ik weet dat je met DHTML ook leuke dingen kan doen, maar wat verschillen deze van Ajax?
Het verschil tussen “plain old” dhtml en ajax technieken is volgens mij dat bij ajax de nadruk erg op de eerste a ligt (asynchronous). Door toepassing van die stoere xmlhttprequest kan continue data worden verzonden tussen client en server, ipv te wachten tot een nieuw http req wordt gedaan.
@ Erwin: ik heb wat ervaring met ontwikkeling van een internet applicatie waarbij veel ajax tech werd gebruikt. Na weken/ maanden werk werd besloten een van de meest ajax-rijke features zowel in php als in javascript uit te voeren. Bij elke bewerking van de gebruiker werd zoveel van de MySQL server gevraagd dat de applicatie zijn snelheid verloor bij meer dan een paarhonderd gebruikers. Dit is natuurlijk niet een probleem van ajax, maar wel van de grote complicaties die kunnen optreden bij het gebruik ervan, het is zeker niet makkelijk.
Overigens, ik programmeer niet maar ben betrokken bij usability review van de applicatie, dus let ook erg op hoe intuitief de omgang met de app is.
Een apart artikel over de gemiddelde ajax app usability zou zeker geen kwaad kunnen 😉
En hoe zit het met Ajax en zoekmachines? Kan een zoekmachine overweg met een pagina die met AJAX is gebouwd of loopt een zoekmachine hier vast en wordt je site niet verder geindexeerd. Wie weet daar meer over?
Volgens het artikel [url=http://weblogs.asp.net/mschwarz/archive/2005/08/06/421761.aspx]AJAX and the Search Engine Problems[/url] kunnen zoekmachines niet goed overweg met Ajax applicaties en moeten daarom twee versies gemaakt worden.
Volgens mij hangt dit er maar helemaal vanaf in hoeverre je gebruikt maakt van Ajax. Het maakt nogal uit of je hele toepassing met Ajax draait of dat je alleen maar gebruik maakt van veld-validatie in formulieren bijvoorbeeld.
Wikipedia beschrijft [url=”http://en.wikipedia.org/wiki/AJAX#Search_engine_.2F_deeplinking”]drie manieren[/url] om ajax toepassingen indexbaar te maken.
Hallo Stefan,
Mijn complimenten voor je uitgebreide artikel over Ajax. Een van de eerst bruikbare die ik tegenkwam toen ik in Google hierop zocht. Je hebt er veel werk van gemaakt. Ik hoop dat dit artikel “voor eeuwig” op deze plek blijft staan, want ik wil er zeker naar gaan verwijzen! Gelukkig zie ik dat je gebruik maakt van Creative Commons. De link naar de interactieve kaaart van Zwitserland is niet helemaal goed… Andere voorbeelden zijn:
[url]http://www.writeboard.com/[/url]
[url]http://www.tadalist.com/[/url]
[url]http://www.calendarhub.com/[/url]
en zo zullen er steeds meer bijkomen! Nu kun je als programmeur wel gaan klagen dat je het niks vindt, als eindgebruiker zie ik het als een fantastische ontwikkeling!
Het wordt alleen maaar mooier…
Ga je ook nog een artikel wijden aan de term: web 2.0 ?
Hallo Willem,
bedankt voor je positieve reactie.
De link naar de interactieve kaart van zwitserland heb ik inmiddels aangepast.
Over web 2.0, momenteel ben ik nog bezig met een artikel over een ander onderwerp maar wellicht daarna.
Ik wil trouwens ook nog even vermelden dat jezelf ook artikelen kunt insturen, hier is usabilityweb immers ook voor bedoeld.
Meer fraaie toepassingen zijn te vinden op http://www.backbase.com
Een leuke post Sean McGrath over Ajax, [url=http://smallbusiness.itworld.com/4413/nls_ebix_ajax060411/page_1.html]
Why using AJAX on the microwave may be a bad idea[/url].
Hij gebruikt de beeldspraak van een magnetron. Deze bevat vele functies en mogelijkheden. Deze worden echter niet gebruikt. De temperatuur staat standaard op hoog. Het eten gaat erin voor een aantal seconden en als het resultaat niet bevalt herhaalt hij dit proces. Net zolang tot het resultaat hem bevalt.
Iets soortgelijks doet hij ook moet zoekmachines. Je vult een woord in, wacht op de resultaten en klikt op het eerste resultaat dat het meeste de aandacht de trekt. Bevalt dit niet begin je weer opnieuw. Net zolang tot je een bevredigend resultaat hebt. Niets geen geavanceerde zoekopties gebruiken.
Waar het op neer komt. De kracht van veel internetapplicaties zit hem in de simpelheid. Een verkeerd gebruik van Ajax kan onnodige complexiteit toevoegen (complexiteit die rationeel misschien wel klopt, geavanceerde zoekopties zijn toch best handig, maar die tegen beter weten in niet worden gebruikt)
Leuk artikel met veel handige links!
De opmerking dat de interactive kaart van Zwitserland niet met XMLHttpRequest gemaakt zou zijn, begrijp ik niet, het artikel in ref 12 heeft het daar wel degelijk over.
Verder is het zo, dat als er andere technieken gebruikt worden dan XMLHttpRequest om onderhuids met de server te communiceren (verborgen IFrames bijvoorbeeld), dan noemen de meeste profs dat nog steeds Ajax, en je hebt nog steeds Javascript nodig om de pagin’s dynamisch te updaten. Zonder Javascript is de Zwitserse kaart echt onmogelijk. DHTML is meestal synoniem met HTML + Javascript…
Iedreen die vandaag nog Javascript af zet, schiet zichzelf in de voet. Het grootste probleem dat nog opgelost moet worden is de toegankelijkheid voor screenreaders e.d.
Is mij net verteld dat je bij het gebruik van Ajax wel moet beschikken over de meeste recente pc (pentium 4) om een beetje acceptable respons te krijgen met natuurlijk een breedband verbinden. Klopt dat?
Uitstekend artikel.
Bestrijkt het gehele spectrum, en trekt juiste conclusies.
AJAX wordt de hemel in geprezen als “de toekomst”, maar in feite is het slechts een extensie op bestaande basis, en een nieuwe naam voor iets wat al bestond. Het is bovenal geen vervanging voor server side intelligence.
Doordat sommigen geneigd zijn een site (c.q. zichzelf) te “verkopen” op basis van AJAX features, heeft het IMHO teveel de focus.
Overigens ook vermeldenswaardig is dat AJAX wel een nieuwe security threat met zich mee brengt: een programmeur kan gauw geneigd zijn om server side maar aan te nemen dat alles al door AJAX is geverifieerd/gevalideerd, en daardoor zijn server side code niet genoeg beveiligen. Verificatie/validatie moet dus zowel client side als server side gebeuren!
Plaats je reactie
Velden met een * zijn verplicht in te vullen