User interface en de evolutie van internet sites

[GuiCli]

op http://www.adaptivepath.com/publications/essays/archives/000519.php staat een interview met een van de mensen achter Flickr.

 

Fascinerend om te zien wat ooit de bedoeling was, en wat het uiteindelijk is geworden. Door goed te kijken naar wat de gebruikers willen, en naar de User Interface, hebben zij hun idee constant veranderd.

[Jeroen Bakker]

En als je het artikel uit hebt: elk artikel op de website van Adaptive Path is zéér de moeite waard!

[willemj]

Leuke club inderdaad Adaptive Path. De 'uitvinders' van Ajax (ze hebben in ieder geval het beestje de naam gegeven)

 

Geinspireerd door GMail/Ajax heb ik m'n safari bookshelf vol gezet met boeken over XML, webservices e.d. Erg leuk spul en ideaal het ontwikkelen van herbruikbare componenten. Van het weekend zitten spelen met XMLRPC in combinatie met O'Reillys meerkat en dan met name de API. Heb nu na wat knutselen een 'rss-reader on steroids' ;D

 

De voordelen van deze technologie zijn vrij duidelijk: een (potentieel) veel intuitievere user interface voor websites/applicaties en een gestandardiseerde interface tussen de presentatielaag (de webbrowser) en de business/verwerkingslaag (scripts op de server)

 

De overhead is één van de nadelen. Om een functie op de server vanuit de browser aan te roepen is aardig wat extra code nodig. De Javascript functie moet vertaald worden naar XMLRPC request, deze gaat via XMLHTTPRequest asynchroon naar de server. Op de server moet de request vertaald worden naar de juiste functie aanroep en het resultaat van de functie weer vertaald naar een XMLRPC response. In de browser gaat het feest dan verder met de vertaling naar een functie resultaat in Javascript. Op zich zijn deze stappen wel te automatiseren en is er waarschijnlijk ook al wel een library beschikbaar voor mijn favoriete taal Perl. Maar de overhead en het asynchrone karakter maakt het niet overzichtelijker, laat staan eenvoudig te testen/debuggen.

 

Waar wil ik nou heen met dit verhaal? Simpel: ik ben benieuwd of er meer HL'ers bezig zijn met deze technologie en hoe/waarom.

 

[djluc]

Ajax is inderdaad erg interessant. Ik ben er al een tijdje mee aan het testen. Ik heb ook een nieuw project waar ik het waarschijnlijk echt wil gaan implementeren. Het is al een techniek die redelijk bewezen is, dus er zijn nog maar weinig drempels voor we het kunnen gaan gebruiken.

 

Het verhaal van Flickr is, behalve de naam dan, interessant om te lezen. Het komt echt op me over als een groepje creatievelingen die gewoon maken wat ze leuk vinden en waar vraag naar is. Wat het uiteindelijk gaat worden? Ik denk dat deze uitstraling ze helpt om een groot publiek te trekken. Het komt niet over als een bedrijf wat geld wil verdienen.

[Anders Floor]

Waar wil ik nou heen met dit verhaal? Simpel: ik ben benieuwd of er meer HL'ers bezig zijn met deze technologie en hoe/waarom.

 

Ja, heb het gebruikt voor de Bureauwijzer:

http://www.ebase.nl/bureauwijzer/

Reden: wilde veel content op een makkelijke manier ontsluiten. Je moet niet alleen makkelijk binnen de antwoorden van een bureau kunnen bladeren, maar een antwoord ook snel kunnen vergelijken met dat van een ander bureau.

 

Het is wel leuk spul. Het heeft voor veel toepassingen niet zo gek veel voor- of nadelen boven Flash, dus de hosanna die links en rechts hoort vind ik wat overdreven.

 

Interessant wordt het met toepassingen als die van Backbase, waarbij je als ontwikkelaar niet meer zo diep onder de motorkap hoeft te duiken om er iets zinnigs mee te kunnen maken.

[Victor]

Ja, heb het gebruikt voor de Bureauwijzer:

http://www.ebase.nl/bureauwijzer/

Reden: wilde veel content op een makkelijke manier ontsluiten. Je moet niet alleen makkelijk binnen de antwoorden van een bureau kunnen bladeren, maar een antwoord ook snel kunnen vergelijken met dat van een ander bureau.

 

Dat laatste vind ik nogal onhandig, je bekijkt toch alle vragen per bedrijf? Als je midden in de vragenlijst naar het profiel van een ander bedrijf wilt gaan, begin je niet bij de eerste vraag. Verder werkt het wel aardig goed.

[Jeroen Bakker]

Zie ook Higherlevel.nl WieWatWaar (tools > wiewatwaar) :)

[willemj]

Ik heb wie wat waar een tijdje geleden al in m'n javascript debugger gehad, suf dat ik hem in deze context niet even noem. Maar het gebruik is wel erg basic: er wordt een blok HTML van de server gevraagd en op de juiste plek in de pagina gezet.

 

Anders bureauwijzer gaat al een stapje verder. De informatie die van de server komt heeft structuur en daar wordt wat mee gedaan. Mooi gebruikt!

 

Oplossingen als Backbase zijn inderdaad cool maar je legt je wel vast op hun framework (heb de code niet gezien maar kan bijna niet anders) In een ander draadje geef je aardig af op CMS systemen. Met dit soort frameworks/libraries loop je hetzelfde risico helaas.

 

Het heeft voor veel toepassingen niet zo gek veel voor- of nadelen boven Flash, dus de hosanna die links en rechts hoort vind ik wat overdreven.

Die hosanna komt waarschijnlijk van ontwikkelaars die geen Flash gebruiken :) Val zelf in die groep en kan dus geen voor- of nadelen noemen. Dus 'hosanna!' wat is dit spul cool.

 

Ben twee dagen bijna fulltime bezig geweest met het experimenteren van Ajax. Het resultaat is een javascript library waarmee je in een paar regels code een (XMLRPC) functie op je server aanroept. Inclusief logging voor testen en foutafhandeling. Hiermee hoef je dus niet meer onder de motorkap! Ik zoek wat mensen voor testen en peer-review dus als je zin hebt Anders of anderen stuur even een PM of email.

 

Het is al een techniek die redelijk bewezen is, dus er zijn nog maar weinig drempels voor we het kunnen gaan gebruiken.

Met nadruk op redelijk. Tijdens het ontwikkelen ben ik tegen een vervelende bug aangelopen. Zie mozilla bug report. Korte samengevat: je code werkt niet als de server waar je verbinding mee probeert te maken niet reageert of niet bereikbaar is. In de meeste gevallen gaat het wel goed maar goede code heeft volgens mij de eigenschap dat het ook (goed) laat weten wanneer iets fout gaat. Dat laatste is in Firefox dus wat lastig... Maar ben bezig om er om heen te werken.

 

Maar ondanks frameworks en bugs een enorm potentieel om vernieuwende websites te bouwen. Ben benieuwd wat andere innovatieve developers hier mee gaan doen. Mijn hoofdje loopt in ieder geval over van toepassingen ;D

[cd-r80Minute]

Het is een techniek die al jaren bestaat hoor. Dat adaptive de term AJAX in het leven heeft geroepen is me echt een raadsel, marketing ;) . M

 

Maar zoals het nu bestaat is het niet reeel om het als volwaardige navigatie structuur voor een website te gebruiken. De BACK ./ < VORIGE button zal hierdoor dus ook niet meer werken.

[willemj]

Het is een techniek die al jaren bestaat hoor.

Asynchroon data opvragen kan inderdaad al sinds er (hidden) frames en javascript bestaan, maar dat is nogal een geklooi. Maar met het XMLHttpRequest object wordt het allemal een stuk eenvoudiger. Het component bestaat inderdaad al sinds IE 5.0 (ca 2000), in Mozilla sinds 2001 maar pas sinds de laatste versie ook in Opera. Het is dus zeker geen oude technologie en het huidige gebruik is zeker nieuw (en innoverend)

 

Dat adaptive de term AJAX in het leven heeft geroepen is me echt een raadsel, marketing ;)

Raadsel kun je oplossen door te lezen; van de site van adaptive path: 'The name is shorthand for Asynchronous JavaScript + XML'. Gewoon een handige afkorting die goed omschrijft waar het over gaat.

 

Maar zoals het nu bestaat is het niet reeel om het als volwaardige navigatie structuur voor een website te gebruiken. De BACK ./ < VORIGE button zal hierdoor dus ook niet meer werken.

Je hebt blijkbaar totaal geen idee waar je over praat. De terug knop in gmail werkt uitstekend. Ik krijg zelfs een waarschuwing dat m'n mail nog niet verzonden is als ik hem gebruik en of ik die mail af wil maken of niet. Iedere techniek heeft de potentie om een site verrijken of, in de handen van een prutser, onbruikbaar te maken.

[cd-r80Minute]

Je hebt blijkbaar totaal geen idee waar je over praat. De terug knop in gmail werkt uitstekend. Ik krijg zelfs een waarschuwing dat m'n mail nog niet verzonden is als ik hem gebruik en of ik die mail af wil maken of niet. Iedere techniek heeft de potentie om een site verrijken of, in de handen van een prutser, onbruikbaar te maken.

 

Ik weet precies waar ik over praat, de back button werkt niet aangezien er geen nieuwe pagina word geopent. Een browser VORIGE | VOORUIT doet het alleen als er een nieuwe pagina word geopent of in een (i)frame

[willemj]

Ik weet precies waar ik over praat, de back button werkt niet aangezien er geen nieuwe pagina word geopent. Een browser VORIGE | VOORUIT doet het alleen als er een nieuwe pagina word geopent of in een (i)frame

 

Even verder lezen dan je neus lang is, ik schrijf dus net dat de terug knop uitstekend werk in gmail (Ajax voorbeeld bij uitstek) en zelfs meer functionaliteit heeft door waarschuwingen te geven. Daarnaast heb ik nog nergens gelezen dat wanneer je Ajax toepast je geen nieuwe pagina mag laden.

[cd-r80Minute]

Ik weet precies waar ik over praat, de back button werkt niet aangezien er geen nieuwe pagina word geopent. Een browser VORIGE | VOORUIT doet het alleen als er een nieuwe pagina word geopent of in een (i)frame

 

Even verder lezen dan je neus lang is, ik schrijf dus net dat de terug knop uitstekend werk in gmail (Ajax voorbeeld bij uitstek) en zelfs meer functionaliteit heeft door waarschuwingen te geven. Daarnaast heb ik nog nergens gelezen dat wanneer je Ajax toepast je geen nieuwe pagina mag laden.

Ik neem aan dat je weet wat een browser is. En dus ook begrijpt dat de vorige / volgende knop alleen werkt wanneer er fysiek een nieuwe pagina word geladen (zonder ajax) met ajax werken die knoppen niet meer.

 

Zoek maar eens op google, en je zal zien dat ik gelijk heb.

[willemj]

Wikipedia over Ajax, kijk even onder 'Pros en cons'. Even lezen hoe Google dit oplost en dan even doorklikken naar de dojo toolkit en als je nog iets dieper zoekt komt je uit bij een back button pattern. Ja je heb gelijk als je Ajax puur sang toepast en niet even verder kijkt naar oplossingen dan werkt de back button niet meer. Maar het kan dus wel gewoon.

[willemj]

Er is hier trouwens al een draadje over geweest met als titel single page interfaces Om de discussie weer wat aan te wakkeren een samenvatting:

 

Indexeert Google je site nog?

Ja en nee. De content die niet in de pagina staat maar dynamisch via bv. Ajax opgehaald wordt ziet Goole nooit. Door de content al in de pagina te zetten en vervolgens dynamisch te be-/verwerken ziet Google wel gewoon je content.

 

De 'wie-wat-waar' van HL zou bijvoorbeeld al de adresgegevens al op een pagina kunnen zetten, in eerste instantie alles verbergen en via Ajax een lijst opvragen van adressen die getoond moeten worden al naar gelang de gemaakte keuzes. Nadeel hiervan is het openen van de pagina lang kan duren. Alle adressen moeten immers geladen worden.

 

Zoals Little Monkey opmerkt zijn twee versies: één de zoekengines (en mensen met oude browsers) en één voor de 'normale' gebruiker ook een optie.

 

Een tussenweg is een oplossing waarbij de pagina 'klassiek' getoond wordt; een lijst met de eerste 20 adressen en volgende/vorige knoppen. Op het moment dat Javascript en de overige benodigdheden voor Ajax aanwezig zijn worden de adressen en navigatie verborgen en wordt de 'single page interface' geladen.

 

Usability en 'vast geroeste' bezoekers

Er is een aardige discussie of 'single page interfaces' mensen niet verwarren. Er is geen conclusie dus lees het draadje.

 

Wegvallen F5 (ververs), terug- en vooruitknoppen

Zonder er rekening te houden bij het ontwerp van een single page interface kunnen deze knoppen hun functionaliteit verliezen of erger nog de bruikbaarheid ondermijnen. Maar met een beetje handigheid en wat techniek hoeft dit niet. Met verborgen (i)frames zoals Google die gebruikt, een goede scheiding tussen verschillende paginas en het bijhouden van instellingen van de pagina blijven deze functies werken zoals de gebruiker het verwacht.

 

Bijkomende voordelen

HTML of Javascript waarvan je niet wilt dat de bezoeker ze ziet kun je verbergen door ze dynamisch in de pagina in te voegen. Heel beperkte beveiliging maar toch :)

 

Door het scheiden van de code in dataverwerking en weergave in HTML kan de code nu zowel op de server in 'normale' cgi scripts gebruikt worden als in Javascript in de browser. Het schrijven van twee versies kost dus zeker niet 2x zoveel tijd. De overhead die ik noemde in een eerdere post is nu overigens bijna volledig weggeautomatiseerd.

 

De genoemde library met documentatie, testcode en demonstratie versie komt binnenkort beschikbaar onder GPL/BSD licentie. Heb al getest onder Windows met IE 5.0, IE 6.0, Opera 8.0, Firefox 1.0.4 en onder BSD Firefox 0.9.

[Alef Arendsen]

Ik heb niet de complete discussie gelezen, maar wilde toch even reageren.

 

In een aantal projecten passen wij inmiddels veelvuldig Ajax toe. We doen dit middels DWR (http://www.getahead.ltd.uk/dwr/) en Spring. DWR is eigenlijk RPC (remote procedure calling - het aanroepen van remote methods) voor JavaScript. Zoals er voor Java to Java communicatie RMI is, is er nu voor Java to JavaScript communicatie DWR. Dit was eerder ook al mogelijk met behulp van een applet en Netscape LiveConnect (ik weet niet helemaal of die naam correct is), maar daar had je dus een applet voor nodig.

 

DWR icm Spring werkt super. We gebruiken het in een aantal applicaties voornamelijk om dynamische validaties en lookups te doen (het simpele werk dus), maar het biedt een enorme verbetering van de user experience.

 

Ik heb een klein beetje ervaring met BackBase en kan zeggen dat de technologie er goed is, vooral voor de wat meer back-office process-oriented applicaties. Voor informatieve sites houd ik het op dit moment liever bij HTML en een klein beetje Ajax.

 

 

gr.

 

alef

 

[willemj]

Net even op de site van DWR zitten kijken en dat is feitelijk het idee dat ik nu aan het uitwerken ben. Ben ik het wiel weer opnieuw aan het uitvinden ::)

 

Ik gebruik XMLRPC om client en server aan elkaar te koppelen. Doel is om eenzelfde soort functionaliteit te krijgen als DWR voor Java maar dan taal onafhankelijk. Met andere woorden functie maken op de server en zonder al te veel werk die functie beschikbaar krijgen in de browser. Maakt dan niet uit of het Java, Perl of PHP is.

 

We gebruiken het in een aantal applicaties voornamelijk om dynamische validaties en lookups te doen (het simpele werk dus), maar het biedt een enorme verbetering van de user experience.

Denk dat daar ook de kracht voor nu ligt. Uit het voorgaande draadje en het feit dat Funda z'n experiment behoorlijk heeft aangepast blijkt wel dat de gemiddelde website bezoeker niet toe is aan grote veranderingen.