Ajax/RIA kosten & baten

[Anoniem: 14124]

De laatste tijd worden we een beetje overspoeld met Ajax en RIA, maar de kosten die daarbij horen, en de voordelen ervan zijn vaak abstract en varieren vaak per project. De voordelen liggen vaak aan de kant van gebruiksvriendelijkheid maar hoe kan je de de kosten die gemaakt worden bij een traject met een van de genoemde methodieken verantwoorden.

Alles draait om "a better user experience", maar dan heb je eigenlijk ook wel de voordelen te pakken. We hebben dan ook nog de nadelen, als beperkte accessability waar de ene persoon/klant zwaarder aan weegt als de andere en de hoge initiele kosten voor studie, r&d, en evt. de bouw van een solide basis voor verdere ontwikkeling.

De discussie is dan ook hoe verantwoord jij die kosten tov de baten. Momenteel is de techniek redelijk volwassen maar veel toepassingen zijn er nog niet. Echte scenario's voor bedrijven zijn er ook niet. Levert het ons bedrijf geld op, wat betekend het voor de toekomst, wat moeten we investeren, wat zijn de nadelen en voordelen, wat betekend dit voor projectaanpak, wat betekend dit voor de klant. Als je gaat kijken naar wat een bedrijf er echt aan heeft is dat weinig, het is meer de klant die er wat aan heeft qua user experience, en de techneut die lekker mag pielen. Een klant legt voor een statische applicatie waarschijnlijk net zo makkelijk geld neer. Kun je Ajax/RIA wel verantwoorden?

[ Voor 24% gewijzigd door Anoniem: 14124 op 30-05-2005 22:04 ]

[Not Pingu]

Ik zou eigenlijk niet weten waarom er nou perse hogere kosten aan vastzitten. Natuurlijk moet de nodige kennis opgedaan worden, maar dat gold ook voor de huidige manier van webapplicatie-ontwerp, en dat heeft niemand er toen van weerhouden.

Feit is dat het WWW-pagemodel grote nadelen heeft en het feit dat RIA's dat pagemodel omzeilen, biedt ontwikkelaars veel meer mogelijkheden mbt. het creeeren van interactie en het finetunen van de 'workflow' van een applicatie. Meer mogelijkheden voor navigatie, minder laadtijden om van site-onderdeel naar site-onderdeel te komen, en dat alles in een veel mooier jasje dat designers de mogelijkheid biedt om visuele concepten veel meer naar voren te laten komen.

In B2C situaties zullen klanten sneller geneigd zijn tot het doen van een aankoop. Bij zakelijke applicaties bestaat het voordeel uit hogere productiviteit van werknemers.

Het klopt dat er nog erg weinig cases zijn die aantonen wat een RIA nou echt kan. Er zijn een aantal RIA's in omloop (zie bijv. stedentrips.pharosreizen.nl of bepaalde rekentooltjes op de site van Ohra). Wat er imho nodig is, is een RIA die heel veel mensen gebruiken. Bijv. Amazon die overschakelt op een RIA-site. Webapplicaties verkochten zichzelf omdat iedereen met Hotmail werkte en daar tevreden over was.


Op school zijn we momenteel bezig met een onderzoeksproject naar RIA's, en we gaan deze week ons rapport daarover opleveren. Mocht iemand hier interesse in hebben, mail me.

[ Voor 8% gewijzigd door Not Pingu op 30-05-2005 22:47 ]

[Sappie]

Ik denk dat het een doel moet zijn van / must is voor een internetbureau om hun producten constant te verbeteren om bij te blijven met / voor te lopen op de concurrentie. Dit constante verbeteren moet in mijn ogen betrekking hebben op producten die niet specifiek gemaakt worden voor één bepaalde klant (tenzij er grote bedragen mee gemoeid zijn). Het zou juist betrekking moeten hebben op producten die voor het gros van de klanten interessant zijn. Een belangrijk product is uiteraard een CMS, wat elk zichzelf serieus nemend internetbureau wel zou moeten kunnen leveren. Waar het imo bij veel CMS'en aan schort is de usability. Het gebruik van AJAX / RIA zou dat gebrek aan usability, mits verantwoord gebruikt, voor een groot deel op kunnen heffen.

In mijn ogen is het dus een kwestie van constant verbeteren, waarbij "nieuwe" technieken niet over het hoofd mogen worden gezien. Vanzelfsprekend worden de techneuten gaandeweg steeds meer begaan in deze "nieuwe" technieken, waardoor ze in de toekomst waarschijnlijk net zo makkelijk een mooie RIA maken als een statische applicatie. (zoals je zegt.. de technologie is redelijk volwassen maar veel toepassingen zijn er nog niet)

offtopic:
wat betekent

[ Voor 5% gewijzigd door Sappie op 30-05-2005 22:49 ]

[Anoniem: 24491]

Gunp01nt schreef op maandag 30 mei 2005 @ 22:46:
Wat er imho nodig is, is een RIA die heel veel mensen gebruiken. Bijv. Amazon die overschakelt op een RIA-site. Webapplicaties verkochten zichzelf omdat iedereen met Hotmail werkte en daar tevreden over was.

Ik kan zo al wat voorbeelden noemen: gmail, maps.google.com, en omdat je toch amazon aanhaalde, http://www.amazon.com/gp/...tGroupID=loose%5fdiamonds

Allemaal apps die behoorlijk boven het niveau van hotmail uitsteken, ik denk ook niet dat hotmail de aanstichter is geweest, maar vooral google.

[ Voor 6% gewijzigd door Anoniem: 24491 op 30-05-2005 23:08 ]

[alienfruit]

Ik moet zeggen dat die Amazon pagina er erg snel en makkelijk werkt
Zulke dingen visueel oplossen is natuurlijk altijd beter, maar dit werkt erg leuk! Bookmark

[XangadiX]

Hmja, ik denk dat het een boel moeilijke woorden en gebakken lucht om niks is. Wat is nu eigenlijk een RIA? wat is het niet? en zijn er niet al honderden toepassingen te noemen die het predicaat RIA verdienen die het helemaal niet zijn, of juist wel, maar al gebouwt werden voordat het woord in zwang raakte?

Natuurlijk is het noodzakelijk dat een webbedrijf bezig blijft met het verbeteren van haar techniek en waar mogelijk probeert te innoveren; maar de meeste lectuur omtrend deze zaken komt uit de marketing en sales hoek en staat volledig los van de daadwerkelijke betekenis

Ik denk dat de vorm de inhoud moet volgen. Een RIA voor het publiceren van een stuk tekst is volstrekt zinloos, en de meeste bedrijven hebben niet meer te vertellen dan een simpele HTML site; de bedrijven die dat wel hebben, hebben vaak ook al oplossingen voor hun inhoud gevonden, wat een RIA ook overbodig maakt. Dat resulteerd er in dat er een boel rotzooi online komt met het predicaat RIA zonder dat iemand zich bedenkt of het niet simpeler had gekunt. En dat had vaak gekunt.

Nogmaals, vorm volgt inhoud, waarom meteen naar ingewikkelde toepassingen grijpen als simpelere toepassingen voldoen. De andere kant van het verhaal is wel, dat het page-model als zodanig zijn langste tijd gehad heeft. Maar als we dan toch buiten de doos denken dan heeft het hele 'z-indexing' model zijn langste tijd wel gehad. Ik bedoel dat we al bijna 40 jaar werken met een 'desktop' enviroment (waaraan ook het page-model schatplichtig is) en het is nu niet zo dat dat het meest voor de hand liggende model is om data in te ordenen.

RIA is mijns insziens 'just the next quote on the block', het slaat niet op een nieuwe manier van denken maar op een nieuwe manier van toepassen van oude informatie. Innovatie ligt juist in het verzinnen van iets nieuws en dat toepassen, niet in de zoveelste schil om datgene wat we al hebben.

[Anoniem: 14124]

Ondanks dat de achterliggende technologie al enige tijd bestaat vind ik Ajax persoonlijk geen gebakken lucht. De naam is ruk, maar de gedachtegang erachter is heel sterk. Echter het blijft bij een gedachtengang, en een visie. Het is moeilijk te verkopen, want de kosten voor een Ajax applicatie zijn niet in een enkele zin samen te vatten, maar ze zijn er wel, het is behoorlijk lastige materie waar een hoop bij komt kijken. Hetzelfde zou je op zich al weer kunnen zeggen voor een website, wat levert de website de klant aan geld op, dat is vooraf niet (altijd) duidelijk. Dus je zou meer naar de voor en nadelen moeten kijken.

Als je gaat kijken naar de voordelen, en nu kijk ik naar een administratie interface bijvoorbeeld, kom je op:

- snellere responses
- verlaging serverload
- meer interactie met de gebruiker
- herbruikbaarheid interface
- het wow! effect
- validatie van gegevens zonder postback
- realtime bewerkingen op data

Je gaat min of meer naar een thick client model toe.

Als je gaan kijken naar de nadelen

- initieel hoge kosten
- lage accessability
- slechte ondersteuning aan developer tools
- crossbrowser ontwikkeling
- memory leak behandeling complex

[ Voor 10% gewijzigd door Anoniem: 14124 op 31-05-2005 08:35 ]

[faabman]

Ik zie het RIA / ajax verhaal eigenlijk als techniek om bestaande desktopapplicaties via het web te ontsluiten zonder daarbij in te hoeven leveren in de bruikbaarheid van de applicatie. Toegankelijkheid is naar mijn idee geen belangrijk item voor webapplicaties en is dus ook geen minpunt. Daarnaast vraag ik me af of de kosten nu zo denderend hoog zijn. Als je een eigen raamwerk ontwikkeld waarbij je uit gaat van een beperkt aantal browsers (i.e. / mozilla en voor op de werkvloer alleen i.e.) dan heb je eenmalig een extra investering en daarna ben je klaar.

Met dat raamwerk bedoel ik dus eigenlijk iets wat lijkt op backbase, waarbij je custom attributes meegeeft aan je html elementen waardoor je niet alles in de scripts hoeft te "hard"-coden. De methodes van validatie die je normaal bij je postback gebruikt kun je nu in een eerder stadium aanroepen (misschien dat desktopdevelopers hierdoor zelfs in het voordeel zijn)...

[Orphix]

Als iemand die meer aan de /14 kant zit merk ik bij projecten die ik maak dat ik vaak de kennis voor client-side niet echt paraat heb. Tuurlijk wat javascript voor validatie lukt me nog wel, maar bijvoorbeeld die Amazon page die hierboven staat werkt echt goed maar voordat ik heb uitgedokterd hoe het precies werkt ben ik wel een tijd verder.

Zoals met heel veel ontwikkelingen in de development wereld zit een groot gedeelte van de kosten in het ontbreken van de juiste tools. Als ASP.NET programmeur is het gewoon erg makkelijk om continu een post-back te doen naar de server, ipv via XML-RPC data ophalen en client-side verwerken. Aangezien bij concepten als Ajax (voor zover ik erover heb gelezen) er een sterke binding is tussen design, client-interface en de serversoftware komt er veel meer teamscommunicatie bij kijken. Het is een concept wat op meerdere niveaus zich nestelt. Dat maakt de totale kosten ook groter.

Voor ASP.NET omgevingen merk je trouwens wel steeds meer dat 3rd party componenten meer client-side functionaliteit aanbieden, die ook voor de typische applicatie ontwikkelaar makkelijk te gebruiken is. (zie bv http://www.telerik.com)

[Not Pingu]

XangadiX schreef op dinsdag 31 mei 2005 @ 02:03:
Hmja, ik denk dat het een boel moeilijke woorden en gebakken lucht om niks is. Wat is nu eigenlijk een RIA? wat is het niet? en zijn er niet al honderden toepassingen te noemen die het predicaat RIA verdienen die het helemaal niet zijn, of juist wel, maar al gebouwt werden voordat het woord in zwang raakte?

Iedereen die veel met webapplicaties bezig is, weet dat er een groot aantal toepassingen zijn die op het web moeilijk te realiseren zijn. Je weet ook dat ontwerpers vaak de neiging hebben om een webapplicatie erg in te delen in pagina's waardoor je je suf navigeert om alle instellingen en functies te bereiken.

Ook is het 'palet' van HTML erg beperkt, dingen als drag & drop, sliders en andere interactiemogelijkheden die we al gewend zijn van desktopapplicaties, ontbreken op het web.

Iets is een RIA als het bijv.:
-Functionaliteit van webforms uitbreidt (maar wel op significante wijze)
-Het HTML-pagemodel doorbreekt en een zgn. single page interface implementeert waar je op dezelfde pagina blijft en via overlappende forms en menu's alsnog alle functionaliteit binnen handbereik hebt
- Asynchroon data ophaalt zonder de pagina te moeten verversen, zo kan de gebruiker door blijven werken terwijl een bepaald paneel wordt geladen. In tegenstelling tot HTML waar je niks kunt doen tijdens een page refresh.

Voorbeelden gaan van guided-selling applicaties (zie bijv. de Vodafone Handyfinder of de stedentrip-planner op Pharos Reizen) tot aan allerlei management dashboards of beursinformatie-monitors. En dat gedistribueerd via het internet, dus instant updates, geen installatie vereist, centraal beheer van data en gebruikers,...

[Anoniem: 14124]

Gunp01nt schreef op dinsdag 31 mei 2005 @ 15:39:
Ook is het 'palet' van HTML erg beperkt, dingen als drag & drop, sliders en andere interactiemogelijkheden die we al gewend zijn van desktopapplicaties, ontbreken op het web.

Deze zijn gewoon beschikbaar hoor Er zijn diverse implementaties beschikbaar. Ik ga wel mee met een generic drag n drop. De bugs qua positionering in Mozilla zitten er nog steeds in, en dat maakt de ontwikkeling lastig.

Voor Ajax zijn er maar bar weinig echte volledige applicaties. Wat kleine case studies daargelaten is het gewoon behoorlijk complexe materie, mede door een gebrek aan tooling.

[Sappie]

Anoniem: 14124 schreef op dinsdag 31 mei 2005 @ 16:01:
Voor Ajax zijn er maar bar weinig echte volledige applicaties. Wat kleine case studies daargelaten is het gewoon behoorlijk complexe materie, mede door een gebrek aan tooling.

Ajax is in mijn ogen niet bijzonder moeilijk.. ok je zal wat ervaring moet hebben / krijgen met javascript, maar dat is redelijk eenvoudig te leren en er zijn genoeg tutorials over.. vraag me af wat er in jouw ogen zo complex is?

Dan heb ik het natuurlijk nog niet gehad over de ingewikkelde server-side technieken die er eventueel bij kunnen komen kijken, maar met wat eenvoudig php oid kom je vaak al een heel eind.

[Thunder]

Anoniem: 14124 schreef op dinsdag 31 mei 2005 @ 16:01:
[...]

Voor Ajax zijn er maar bar weinig echte volledige applicaties. Wat kleine case studies daargelaten is het gewoon behoorlijk complexe materie, mede door een gebrek aan tooling.

Mijn excuses voor mijn onwetendheid maar wat bedoel je precies met volledige applicaties? Want ik zag hier die Amazon app staan en ik als relatieve webdev n00b vond dat toch wel een mooi voorbeeld van een volledige Ajax applicatie.

[faabman]

Ik denk dat je even iets verder moet kijken dan alleen de technieken die onder het kopje AJAX worden gevangen. Wil je bijvoorbeeld een compleet CRM systeem van met de looks en feels van een desktop toepassing naar je webbrowser halen dan ben je niet alleen met ajax bezig, maar ook met een hoop andere technieken...

Overigens denk ik dat de discussie misschien iets meer richting RIA moet gaan en dat AJAX moet worden gezien als een techniek om RIAs te maken zonder gebruik te maken van Flash oid.

[ripexx]

Anoniem: 14124 schreef op maandag 30 mei 2005 @ 22:00:
De laatste tijd worden we een beetje overspoeld met Ajax en RIA, maar de kosten die daarbij horen, en de voordelen ervan zijn vaak abstract en varieren vaak per project. De voordelen liggen vaak aan de kant van gebruiksvriendelijkheid maar hoe kan je de de kosten die gemaakt worden bij een traject met een van de genoemde methodieken verantwoorden.

* ripexx werkt bij een bedrijf wat al enkele jaren gebruik maakt van RIA. Wel IE only en men maakt gebruik van rmeote scripting om het Ajax effect te bereiken. Met name de formulier elementen, toolbars waren de eerste voorbeelden. Later zijn daar geavanceerde zoek controls, dynamisch tabellen etc ook bij gekomen. De voordelen zijn dus met name op het gebied van user experience en usability.

Alles draait om "a better user experience", maar dan heb je eigenlijk ook wel de voordelen te pakken. We hebben dan ook nog de nadelen, als beperkte accessability waar de ene persoon/klant zwaarder aan weegt als de andere en de hoge initiele kosten voor studie, r&d, en evt. de bouw van een solide basis voor verdere ontwikkeling.

Voor de gemiddelde professionele omgeving is een eis als Windows 2000 en hoger en IE en hoger geen probleem. Wil je verder gaan met usability dan kom je in de IE hoek al snel aan ActiveX object om zo bijvoorbeeld word documenten rechtstreeks in je web applicatie te kunnen slepen.

De discussie is dan ook hoe verantwoord jij die kosten tov de baten. Momenteel is de techniek redelijk volwassen maar veel toepassingen zijn er nog niet. Echte scenario's voor bedrijven zijn er ook niet. Levert het ons bedrijf geld op, wat betekend het voor de toekomst, wat moeten we investeren, wat zijn de nadelen en voordelen, wat betekend dit voor projectaanpak, wat betekend dit voor de klant. Als je gaat kijken naar wat een bedrijf er echt aan heeft is dat weinig, het is meer de klant die er wat aan heeft qua user experience, en de techneut die lekker mag pielen. Een klant legt voor een statische applicatie waarschijnlijk net zo makkelijk geld neer. Kun je Ajax/RIA wel verantwoorden?

De vraag is natuurlijk waar je op in gaat zetten. Als je werkt aan een webbassed ERP of CRM pakket dan is dit wel mogelijk. Webbassed heeft veel voordelen boven het traditionele client server model. Een goed doordacht product kan zeer uitgebreid getest worden en dan zeer eenvoudig uitgerold worden.

Alleen is het de vraag of je voor een CMS het terug kan verdienen. Als je kijkt naar backbase dan zie je dat er een framework is wat vrij snel kan worden geimplementeerd. Alleen is het dan de vraag of je dit weer terug kan verdienen. Een grote applicatie waarbij het gaat om orders van enkele tonnen is dit issue veel minder.

Het grootste nadeel van de meeste webbased applicaties is dat ze traag worden. Door de grote hoeveelheid JS die nodig is om alle onderdelen dynamisch te laten werken is het veelal zwaar aan de client. Tov native (compiled) code is JS traag.

Webbrowsers zijn initiel niet ontworpen om applicaties in te hosten, maar bedoeld om "HTML" weer te geven. Dit in tegen stelling tot een client server omgeving waar juist het OS ontworpen in om applicatie in te draaien. IE heeft door verschillende toevoegingen, hacks wel meer mogelijkheden dan de mozilla lijn. De default dialog van IE is hier een voorbeeld van. Je wil de user in de UI dwingen om een keuze te maken. FF ondersteund nu native XMLHttpRequest terwijl IE dit nog via een ActiveX object moet doen. Als een bedrijf policies heeft welke elke vorm van ActiveX verbiedt wordt het al lastig en bij de grote multinationals zijn de IT afdelingen niet echt makkelijk.

Daarnaast zie je wel dat aan de server kant er steeds beter wordt ingespeeld op webbassed applicatie IIS 6.0 en de verschillende Java applicatie servers bieden al veel meer ondersteuning voor webapplicaties.

Wat je dus moet afvragen is of RAI ontwikkeling voor jouw type applicatie wel loont. Bij het bedrijf waar ik werk loont het wel maar het heeft dan ook enkele jaren ontwikkelingstijd nodig gehad om volwassen te worden. We zijn geheel afgesatp van client server en volledig webbassed gegaan. En je ziet nu ook dat onze concurrenten dit ook doen. Alleen proberen zijn nog veelal beide type te ondersteunen waardoor een van de twee toch een beetje in het verdom hoekje komt te staan.

offtopic:
Dit is trouwens een zeer interessant topic

[crisp]

ripexx schreef op dinsdag 31 mei 2005 @ 22:00:
[...]
Het grootste nadeel van de meeste webbased applicaties is dat ze traag worden. Door de grote hoeveelheid JS die nodig is om alle onderdelen dynamisch te laten werken is het veelal zwaar aan de client. Tov native (compiled) code is JS traag.

Zolang je geen 100 lemmings wilt laten rondhuppelen is JS snel zat voor zo'n beetje alles wat je in een rich GUI zou willen doen. Mensen die zeggen dat JS (te) traag is weten zelf vaak niet hoe ze snelle code kunnen schrijven
Eerlijk waar; de kwaliteit van een gemiddeld stuk javascript code op het internet (ook 'Ajax'-implementaties - hate the name too btw) is bedroevend, en zelfs de betere code is vaak nog voor heel wat verbetering vatbaar - zeker performancewise.
JS heeft gewoon een imagoprobleem; het word gezien als iets dat een webontwikkelaar er wel 'even bij kan doen' zonder de tijd te krijgen zich er echt in te verdiepen. Juist op het vlak van browserimplementaties zijn er echter veel zaken waar je rekening mee moet houden, anders krijg je inderdaad lompe en trage scripts...

FF ondersteund nu native XMLHttpRequest...

nu? Mozilla ondersteund het al sinds 2001 ofzo (ik gebruikte het 3 jaar geleden al voor de GoT Tracker)

[ Voor 7% gewijzigd door crisp op 31-05-2005 22:36 ]

[Not Pingu]

Thunder schreef op dinsdag 31 mei 2005 @ 16:22:
[...]

Mijn excuses voor mijn onwetendheid maar wat bedoel je precies met volledige applicaties? Want ik zag hier die Amazon app staan en ik als relatieve webdev n00b vond dat toch wel een mooi voorbeeld van een volledige Ajax applicatie.

Dan kun je enerzijds denken aan grote informatiesystemen, maar anderzijds ook aan programma's die niet zozeer groot zijn, maar veel functionaliteit hebben, zoals Word ofzo. Wil je Word-achtige functionaliteit naar het web brengen, dan moet je vaak heel veel aan functionaliteit en gebruikersgemak inleveren (zie ook de talloze HTML-editors gebaseerd op DesignMode).

Veel mensen denken bij 'functionaliteit' niet verder dan: "Kun je tekst bold maken? Kun je tabellen en afbeeldingen invoegen? Nou, dan heeft het toch dezelfde functionaliteit als Word?". Maar het gaat verder, GMail laat bijvoorbeeld zien dat semi-realtime spellingscontrole best te doen is. Ook het opzoeken van contacten (typ een gedeelte van een emailadres in en je krijgt een paneeltje met alle overeenkomende zoekresultaten) is een vorm van functionaliteit en gebruikersgemak die in desktopapplicaties heel gewoon is, maar die je op het web heel weinig tegenkomt.

[Rhapsody]

Maar hoe zit eht dan met dataverkeer?

Er is toch sprake van een reuqest onderwater. Bij complexe applicaties zullen deze requests oplopen, en het verkeer dus ook?

[Not Pingu]

ripexx schreef op dinsdag 31 mei 2005 @ 22:00:
Webbrowsers zijn initiel niet ontworpen om applicaties in te hosten, maar bedoeld om "HTML" weer te geven. Dit in tegen stelling tot een client server omgeving waar juist het OS ontworpen in om applicatie in te draaien. IE heeft door verschillende toevoegingen, hacks wel meer mogelijkheden dan de mozilla lijn. De default dialog van IE is hier een voorbeeld van. Je wil de user in de UI dwingen om een keuze te maken. FF ondersteund nu native XMLHttpRequest terwijl IE dit nog via een ActiveX object moet doen.

Je ziet nu ook dat er steeds meer gekeken wordt naar het aanbieden van applicaties buiten een browser om. Macromedia heeft Central, waarmee Flash buiten de browser zit, maar waarmee developers toch een distributiemiddel hebben om hun applicaties te verspreiden. Dat is nl. waar de browser vaak nog wel hard voor nodig is.

Ook Microsoft biedt een oplossing die geen browser nodig heeft, nl. de interface-declaratietaal XAML. Die code kan gewoon door het OS geparsed worden in elke gewenste context, net alsof je een XML stream consumeert.

Je ziet dat developers de grenzen steeds meer gaan verleggen, en de afhankelijkheid van de browser is steeds meer een bottleneck. Op dat gebied heeft Flash een aantal voordelen als interfface-platform, omdat de plugin browseronafhankelijk en cross-platform is en geen problemen geeft met crossbrowser compatibiliteit. Dat is best een verademing als je dat geklooi met HTML, CSS en Javascript gewend bent.

[Not Pingu]

Rhapsody schreef op dinsdag 31 mei 2005 @ 22:38:
Maar hoe zit eht dan met dataverkeer?

Er is toch sprake van een reuqest onderwater. Bij complexe applicaties zullen deze requests oplopen, en het verkeer dus ook?

In vergelijking met HTML-gebaseerde websites (daarbij is een page-reload de manier om data te verzenden, je krijgt dan wel een hoop overhead want de hele interface enzo komen ook weer mee) valt dat wel mee. Je hebt de eerdergenoemde overhead niet, en als je kijkt naar de snelheid van internetverbindingen van tegenwoordig zul je het soms niet eens merken.

Google Maps en GMail zijn daar een goed voorbeeld van: je merkt het bijna niet, maar terwijl je dat gebruikt vindt er ontzettend veel communicatie met de server plaats. Maar wel zo dat jouw bezigheden niet onderbroken worden door een page-reload die gelijk de controle uit handen neemt.

[Rhapsody]

Gunp01nt schreef op dinsdag 31 mei 2005 @ 22:39:
[...]


Je ziet nu ook dat er steeds meer gekeken wordt naar het aanbieden van applicaties buiten een browser om. Macromedia heeft Central, waarmee Flash buiten de browser zit, maar waarmee developers toch een distributiemiddel hebben om hun applicaties te verspreiden. Dat is nl. waar de browser vaak nog wel hard voor nodig is.

Ook Microsoft biedt een oplossing die geen browser nodig heeft, nl. de interface-declaratietaal XAML. Die code kan gewoon door het OS geparsed worden in elke gewenste context, net alsof je een XML stream consumeert.

Je ziet dat developers de grenzen steeds meer gaan verleggen, en de afhankelijkheid van de browser is steeds meer een bottleneck. Op dat gebied heeft Flash een aantal voordelen als interfface-platform, omdat de plugin browseronafhankelijk en cross-platform is en geen problemen geeft met crossbrowser compatibiliteit. Dat is best een verademing als je dat geklooi met HTML, CSS en Javascript gewend bent.

Daarintegen is het wel zo dat Flash weer als nadeel heeft dat de browserknoppen niet werken binnen de applicatie. Als je op vorige klikt ga je naar de vorige WEBpagina en niet naar de vorige Flash-ding (ben absoluut geen flash kenner trouwens, maar heb het er niet zo op)

Gunp01nt schreef op dinsdag 31 mei 2005 @ 22:41:
[...]


In vergelijking met HTML-gebaseerde websites (daarbij is een page-reload de manier om data te verzenden, je krijgt dan wel een hoop overhead want de hele interface enzo komen ook weer mee) valt dat wel mee. Je hebt de eerdergenoemde overhead niet, en als je kijkt naar de snelheid van internetverbindingen van tegenwoordig zul je het soms niet eens merken.

Google Maps en GMail zijn daar een goed voorbeeld van: je merkt het bijna niet, maar terwijl je dat gebruikt vindt er ontzettend veel communicatie met de server plaats. Maar wel zo dat jouw bezigheden niet onderbroken worden door een page-reload die gelijk de controle uit handen neemt.

Ja daar moet ik je gelijk in geven. Ik ben nog betrekkelijk nieuw met dit soort nieuwe technieken, of combinatie van bestaande technieken. Maar goed ik ben lerende Krijg dezwe week, als het goed is een mooi rapport van Gunp01nt

[ Voor 28% gewijzigd door Rhapsody op 31-05-2005 22:44 ]

[BtM909]

Rhapsody schreef op dinsdag 31 mei 2005 @ 22:38:
Maar hoe zit eht dan met dataverkeer?

Er is toch sprake van een reuqest onderwater. Bij complexe applicaties zullen deze requests oplopen, en het verkeer dus ook?

Ja, maar je probeert het voordeel te behalen door minder traditionele 'postbacks' te doen (process-time van de server af te snoepen) en je hoeft je hele source (je client frame-work) niet elke keer opnieuw te laden

[Rhapsody]

BtM909 schreef op dinsdag 31 mei 2005 @ 22:48:
[...]

Ja, maar je probeert het voordeel te behalen door minder traditionele 'postbacks' te doen (process-time van de server af te snoepen) en je hoeft je hele source (je client frame-work) niet elke keer opnieuw te laden

daar had ik inderdaad niet bij stilgestaan.

Zeker ook op gebruikersvlak is deze manier heel erg handig.

[Not Pingu]

Rhapsody schreef op dinsdag 31 mei 2005 @ 22:42:
[...]

Daarintegen is het wel zo dat Flash weer als nadeel heeft dat de browserknoppen niet werken binnen de applicatie. Als je op vorige klikt ga je naar de vorige WEBpagina en niet naar de vorige Flash-ding (ben absoluut geen flash kenner trouwens, maar heb het er niet zo op)

Maar je moet dan ook niet denken aan websites. Voor puur het overbrengen van grotendeels statische informatie werkt HTML en dat pagina-navigeren harstikke goed omdat het dicht bij het concept van een boek aan komt.

Voor applicaties is dat niet handig. Om maar weer hotmail te nemen (slecht voorbeeld misschien), als je daar een attachment wilt downloaden moet je 2 pagina's doorlopen voordat je bij je attachment bent. Terwijl datzelfde attachment in Outlook direct te bereiken is met een knopje ergens. Je bladert niet twee schermen door om ergens te komen. Dat is het punt met webapplicaties, daar wordt vaak alle functionaliteit teveel verspreid over pagina's. Je wilt dat allemaal vanaf 1 scherm kunnen bereiken. Niet dat je het allemaal in beeld wilt hebben, maar je wilt het dan wel met een pull-down menu ofzo makkelijk bij de hand hebben.

Flash is ook niet bedoeld om websites in te maken. Dat dat vaak gedaan wordt, moet je niet verkeerd interpreteren.

[Rhapsody]

aha ok. Bedankt voor je uitleg.
Soms is het verschil tussen een Website en een Webapplicatie een beetje vaag.. voor mij dan.

Tot zover ik het allemaal begrijp ben ik het hier met de meeste wel eens. Er wordt (of werd) te weinig nagedacht over hoe de gebruiker het programma zou gebruiken. (zoals 2 pagina's doorlopen voor het bereiken van je doel -> het downloaden van de attachment)

[ Voor 58% gewijzigd door Rhapsody op 31-05-2005 23:13 ]

[ripexx]

crisp schreef op dinsdag 31 mei 2005 @ 22:30:
[...]
Zolang je geen 100 lemmings wilt laten rondhuppelen is JS snel zat voor zo'n beetje alles wat je in een rich GUI zou willen doen. Mensen die zeggen dat JS (te) traag is weten zelf vaak niet hoe ze snelle code kunnen schrijven
Eerlijk waar; de kwaliteit van een gemiddeld stuk javascript code op het internet (ook 'Ajax'-implementaties - hate the name too btw) is bedroevend, en zelfs de betere code is vaak nog voor heel wat verbetering vatbaar - zeker performancewise.
JS heeft gewoon een imagoprobleem; het word gezien als iets dat een webontwikkelaar er wel 'even bij kan doen' zonder de tijd te krijgen zich er echt in te verdiepen. Juist op het vlak van browserimplementaties zijn er echter veel zaken waar je rekening mee moet houden, anders krijg je inderdaad lompe en trage scripts...
[...]
nu? Mozilla ondersteund het al sinds 2001 ofzo (ik gebruikte het 3 jaar geleden al voor de GoT Tracker)

Hmm dat verhaal van XMLHttpRequest ken ik niet, my bad

Het probleem waar je in de praktijk tegen aanloopt is dat je niet zomaar even wat code gaat herschrijven. En in ons geval gaat het om veel, heel veel regels code. Daarnaast maken we gebruik van zaken die niet altijd even snel zijn. Voorbeeld: XML island in IE, laad een HTML file als XML in en parse dan client side. Dit is dus traag.. alleen de voordelen in onze applicatie zijn dusdanig tbv beheer en eigen aanpassingen. Daarnaast stamt een groot deel van de code al vanaf 2000 en 2001. Dat gooi je niet zomaar om. Vandaar dat ik het ook zeer knap van T.net vond om zo'n groot stuk code te herschrijven. Verder zit er ook nog een hoop VB legacy in welke nu gelukkig bijna geheel verdwenen is.

[ripexx]

Gunp01nt schreef op dinsdag 31 mei 2005 @ 22:39:
[...]
Je ziet dat developers de grenzen steeds meer gaan verleggen, en de afhankelijkheid van de browser is steeds meer een bottleneck. Op dat gebied heeft Flash een aantal voordelen als interfface-platform, omdat de plugin browseronafhankelijk en cross-platform is en geen problemen geeft met crossbrowser compatibiliteit. Dat is best een verademing als je dat geklooi met HTML, CSS en Javascript gewend bent.

Alleen schrijf je niet ff een compleet ERP pakket in flash, ook al is JS en Actionscript op veel vlakken vergelijkbaar. Ook school je niet zomaar even wat programmeurs om. Dan komt het financiele aspect pas echt kijken. Al hoewel je op termijn er wel weer winst uit zal halen zal er dan ook wel weer een nieuwe techniek zijn.

Wat in met basis html, JS en wat frames mogelijk is en voornamelijk werd gebruikt kan nu nog steeds alleen zijn er veel meer mogelijkheden bij gekomen.

[Rhapsody]

in /14 loopt een topic [Alg] Welke tools heb jij gemaakt - deel II, daarin was er iemand die hier mee bezig was: http://www.ria-info.com/test.html
Dat soort dingen zijn natuurlijk wel eenvoudig te gebruiken en toe te passen.

Of zie ik dat verkeerD?

[Not Pingu]

ripexx schreef op dinsdag 31 mei 2005 @ 23:23:
[...]

Alleen schrijf je niet ff een compleet ERP pakket in flash, ook al is JS en Actionscript op veel vlakken vergelijkbaar. Ook school je niet zomaar even wat programmeurs om. Dan komt het financiele aspect pas echt kijken. Al hoewel je op termijn er wel weer winst uit zal halen zal er dan ook wel weer een nieuwe techniek zijn.

Wat in met basis html, JS en wat frames mogelijk is en voornamelijk werd gebruikt kan nu nog steeds alleen zijn er veel meer mogelijkheden bij gekomen.

Tsja, je kunt niet in de eeuwigheid op dezelfde kennis gaan teren. Behoeften vanuit de markt nemen toe, zeker naarmate er meer RIA's komen. GMail gebruikers zien nu al hoeveel beter het kan in vergelijking met alle andere webmail aanbieders (los van de 2 gig aan schijfruimte). Macromedia heeft trouwens een vrij interessant voorbeeld op haar site staan, een Flash-gebaseerde applicatie waarmee beursdata gevolgd kan worden. Je kunt data realtime sorteren in datagridjes of naar keuze laten weergeven in grafieken, diagrammen en weet ik wat.

Dat niveau van functionaliteit zie je bijna nergens. Tenminste niet dat je met een druk op de knop kunt switchen, je kunt Excel data natuurlijk wel omzetten naar grafieken, maar dat is niet vergelijkbaar. Er zijn gewoon een hoop dingen makkelijker te doen. Waar men eerst niet op het idee gekomen zou zijn om eraan te beginnen, liggen nu een aantal mogelijkheden binnen handbereik. Als mensen zien wat er mogelijk is in applicaties, gaat er vanzelf vraag naar meer ontstaan.

[Anoniem: 14124]

Ik zie complete uitleg terugkomen, die heel aardig is bedoeld, maar wat eigenlijk niet de intentie was van mijn aanzet tot discussie. Ik ben zelf dagelijks ermee bezig en ben meer als bekend met de techniek kant van het verhaal

Ik poogde meer een discussie neer te zetten in de vorm van, als je bij iemand komt en je wilt Ajax verkopen of het nu bij de klant is of bij je bedrijf, wat verkoop je dan. Er zal behalve gebruiksvriendelijheid ergens een afweging gemaakt moeten worden tussen de kosten van een Ajax implementatie en de wat het kan opleveren.

Ik kijk nu ook niet naar de losse snippets die je hier en daar tevoorschijn ziet komen, en gebruik maken van Ajax, maar ik kijk hierbij verder en doel min of meer op complete pakketten die men gaat bouwen met Ajax. Dus Ajax niet als losse stukken componenten, maar Ajax als volledige basis in een applicatie De wow! factor is niet alles, hij is leuk voor de developer om ermee te spelen, maar is totaal afhankelijk van de functionaliteit, complexiteit qua gebruik en doelstelling van het eindprodukt. Ook hier geldt dat je moet kijken waar je het wel gebruikt, en niet gebruikt.

Ik doelde dus meer op de commerciele kant van het verhaal, en de plek van Ajax in dagelijkse applicaties als de kosten in de praktijk bij schatting toch hoog uitvallen door gebrek aan kennis, tooling en een gigantische hoeveelheid aan valkuilen waarbij memory management de grootste is.

[ Voor 12% gewijzigd door Anoniem: 14124 op 31-05-2005 23:52 ]

[faabman]

Ik denk dat we eerst moeten bepalen voor welke toepassing we ajax willen verkopen. Praten we over een website of een webapplicatie. En praten we over een volledige conversie of over een enkele om te bouwen module.

Nu ik mij eerste zinnetjes nalees bedenk ik dat je helemaal, zeker in eerste instantie en misschien wel helemaal niet met je opdrachtgever over ajax moet praten. Je moet praten over rich internet applications en de voordelen daarvan *. Pas nadat je je opdrachtgever daarin mee hebt kun je gaan praten over de technieken die je daarvoor gebruikt (en daarover is al eerder een topic voorbij gekomen).

* en het belangrijkste voordeel van een RIA is imo het creeeren van een ervaring die gelijk is aan de ervaring die je hebt bij een desktop applicatie met de verdere voordelen van een webapplicatie...

[ripexx]

Om terug te komen op het punt van Gordijnstok. Maak de vergelijking eens tussen windows versies. Zie hoe er met usability wordt gespeeld. En kijk dan eens niet als de tweaker maar als je opa of oma.

Een goed product staat of valt bij een goed UI. En daar hoort dus van alles bij, zoals drag en drop, geen refreshes etc etc. Maar wie probeer je te overtuigen.

De manager/gebruiker -> geef een spetternde demo. Laat zien wat je in huis hebt en hoe eenvoudige en gebruiks vriendelijk het is. Alle verhalen over 100 en 1 verschillende opties, mogelijkheden en wat nog meer is niet interessant. De maanger wil weten wordt het product gebruik en heb je eventueel nog wat management info voor me. Dus in het geval van een CMS zijn goed betrouwbare statistieken belangrijk. Want als ik niet zie hoeveel leads er uit mijn website komen heefthet investeren in een CMS geen nut. En dat geldt dus ook voor een ERP pakket.

Je moet geen beheerders of programmeurs moeten overtuigen. Dat wordt een spelletje van wie heeft de langste en is alleen maar slecht voor je naam

Als men in je eigen bedrijf niet weet wat de markt wil dan is het bijn aeen onbegonnen zaak. Of men ziet in hoe belangrijk de user experience is of niet en als men dat wel in ziet is dat just een USP.

Verder is complexiteit iets voor developers en een managers of beslisser intresseert het helemaal niets of je er nu 1 of 5 jaar aan gewerkt hebt. Het product moet gewoon doen waar het voor aangeschaft is. Key issue is luisteren naar de wensen van je klanten en daar op inspelen. Wat willen key users, wat wil de manager en wat wil diegene die over het geld gaat (DMU)

Verder als je AJAX wil verkopen moet je naar AEX gaan Who cares hoe het heel.
^^^ Heel kort door debocht het sales proces Maar de essentie moge duidelijk zijn.

faabman schreef op dinsdag 31 mei 2005 @ 23:59:
Ik denk dat we eerst moeten bepalen voor welke toepassing we ajax willen verkopen. Praten we over een website of een webapplicatie. En praten we over een volledige conversie of over een enkele om te bouwen module.

Nu ik mij eerste zinnetjes nalees bedenk ik dat je helemaal, zeker in eerste instantie en misschien wel helemaal niet met je opdrachtgever over ajax moet praten.

Dat bedoel ik

Je moet praten over rich internet applications en de voordelen daarvan *. Pas nadat je je opdrachtgever daarin mee hebt kun je gaan praten over de technieken die je daarvoor gebruikt (en daarover is al eerder een topic voorbij gekomen).

Laat zoveel mogelijk termen en vergelijkingen achterwege want daar wordt je later op terug gepakt Want een halfuur later is men AJAX en RIA vergeten.

* en het belangrijkste voordeel van een RIA is imo het creeeren van een ervaring die gelijk is aan de ervaring die je hebt bij een desktop applicatie met de verdere voordelen van een webapplicatie...

Oftwel user experience

[ Voor 25% gewijzigd door ripexx op 01-06-2005 00:05 ]

[Tubby]

Feit is eigelijk dat de functionaliteit van Ajax (maar ook bv flex) moeilijk te verkopen is naar de klant als hard product of eis. De verbeterde gebruikerservaring is iets wat zo van tafel geveegd wordt op het moment dat het budget besproken wordt.

[ripexx]

Tubby schreef op woensdag 01 juni 2005 @ 00:04:
Feit is eigelijk dat de functionaliteit van Ajax (maar ook bv flex) moeilijk te verkopen is naar de klant als hard product of eis. De verbeterde gebruikerservaring is iets wat zo van tafel geveegd wordt op het moment dat het budget besproken wordt.

Oja, vertaal dat eens naar productiviteit Dan kijk men er in eens geheel anders tegenaan. Als je wil verkopen moet je meegaan en dus USP benadrukken en die vertalen naar de wensen van de klant.

[Rhapsody]

ripexx schreef op woensdag 01 juni 2005 @ 00:08:
[...]

Oja, vertaal dat eens naar productiviteit Dan kijk men er in eens geheel anders tegenaan. Als je wil verkopen moet je meegaan en dus USP benadrukken en die vertalen naar de wensen van de klant.

Maar bedrijven zijn vaak een beetje huiverig voor het gebruiken van nieuwe dingen.
Zeker als het hogere kosten met zich mee brengt. Het moeet zich dus eerst bewijzen, maar om het te kunnen bewijzen moet er eerst iemand de stap durven nemen.

[Not Pingu]

Anoniem: 14124 schreef op dinsdag 31 mei 2005 @ 23:49:
Ik poogde meer een discussie neer te zetten in de vorm van, als je bij iemand komt en je wilt Ajax verkopen of het nu bij de klant is of bij je bedrijf, wat verkoop je dan. Er zal behalve gebruiksvriendelijheid ergens een afweging gemaakt moeten worden tussen de kosten van een Ajax implementatie en de wat het kan opleveren.

Het is idd belangrijk om te kijken of een RIA zin heeft voor een klant, of het iets kan toevoegen. Maar als jij laat zien dat je door gebruik van sliders, weetikveel wat voor UI-elementen, invoer in een formulier drastisch kan versnellen, of als je kunt laten zien dat je met een full-out RIA een bedrijfsproces kunt vergemakkelijken of versnellen, dan heb je iets waar een klant wellicht in geinteresseerd is. Helemaal als je ze zelf achter een RIA zet en laat zien dat ze bepaalde taken veel sneller kunnen uitvoeren.

Koppel daaraan het voordeel (voor B2C casussen) dat je veel meer mogelijkheden hebt op het grafische vlak en je applicatie dus zowel functioneler als aantrekkelijker kan maken voor consumenten. Beargumenteer dat dat leidt tot meer verkopen omdat minder bezoekers uit pure frustratie de site sluiten, en je hebt imho wel een aantal goeie verkoopargumenten.


@Faabman:
Het gaat natuurlijk niet over websites, misschien zelfs niet over webapplicaties. Maar bijv. intelligente(re) formulieren zoals bijv. de premiebereken-dingen op de site van Ohra zijn ook al RIA's, en als klein onderdeel van een site voegen ze al een hoop toe.

[ripexx]

Rhapsody schreef op woensdag 01 juni 2005 @ 12:12:
[...]

Maar bedrijven zijn vaak een beetje huiverig voor het gebruiken van nieuwe dingen.
Zeker als het hogere kosten met zich mee brengt. Het moeet zich dus eerst bewijzen, maar om het te kunnen bewijzen moet er eerst iemand de stap durven nemen.

Nou, dit is echt niet nieuw meer en de techniek heeft zich al velemalen bewezen. Veel groteren enterprise applicaties hebben al RIA onderdelen. Kijk maar eens naar webbassed versie van Siebel of SAP.

[Pelle]

Slightly offtopic:

Van http://www.webwereld.nl/articles/35565

Ajax-techniek Backbase vrij beschikbaar

Backbase stelt zijn versie van de ajax-techniek vrijelijk ter beschikking voor niet-commerciële doeleinden. Het bedrijf wil meer bekendheid voor ajax.

Hmm, interessant

[BtM909]

Pelle schreef op vrijdag 03 juni 2005 @ 10:43:
Slightly offtopic:

Van http://www.webwereld.nl/articles/35565


[...]


Hmm, interessant

quote van de webstek:

Tonight Backbase will launch the Backbase Community Edition, which can be used free of charge for non-commercial purposes. Please check back tonight, or sign up to be notified:

[BlueAce]

Voor deze opmerking ben ik door vrienden en bekenden wel eens uitgemaakt voor conservatieve lul, maar ik zie AJAX net als Flash: leuke toevoeging (ook aan de usability), meer niet. Een volledige RIA structuur heeft gewoon simpelweg geen nut op het web zoals het nu in elkaar zit en zoals het vertrouwd is. Wellicht NOG niet, maar ook dat valt te betwijfelen.

Ik zie bijvoorbeeld www.backbase.com en mijn onderkaak ligt op de vloer, maar is de site nou echt zoveel beter door de niet-bestaande refresh? Nee, dat vind ik absoluut niet. Daarom zijn er dus geen redenen voor mij om een "complete rich structure" (CRS?) uberhaupt te verkopen. Ik sta er niet achter.

Wat ik wel aan de man wil brengen zijn usability verbeteringen in de vorm van RIA. Maar zoals hier al eerder gezegd wordt: ze vinden het allemaal prachtig en prijzen je de hemel in (ook bij hun relaties, trust me) maar als het neerkomt op de prijs is het een hoop gemekker. Je moet het uit hun perspectief bekijken: waarom voor iets betalen dat ook simpeler kan voor minder geld? Klanten (tenminste: de mijne, en ik geef toe dat het niet de meest internet-bewuste personen zijn) kunnen zich de voordelen van de verbeterde usability nog niet voorstellen. Ze zien liever de bezoekers een klein sprongetje maken dan dat ze zelf de sprong wagen

Ik denk dus dat RIA is weggelegd voor de bewuste afnemers op dit moment, de 'mainstream' heeft er niks mee.

[BtM909]

BlueAce schreef op vrijdag 03 juni 2005 @ 11:32:
, maar ik zie AJAX net als Flash: leuke toevoeging (ook aan de usability), meer niet. Een volledige RIA structuur heeft gewoon simpelweg geen nut op het web zoals het nu in elkaar zit en zoals het vertrouwd is. Wellicht NOG niet, maar ook dat valt te betwijfelen.

conservatieve lul

Anywee, met flash maak je tegenwoordig ook al serieuze webapplicaties hoor. Is het niet een kwestie van: wat de boer niet kent.....

Ik denk dat als je een goede framework hebt (en backbase biedt dat wellicht), dat je straks niet meer met de klant praat over usability, maar het zelf al dan niet toepast. Ik merk overigens nog steeds dat er nu nog teveel custom moet worden gebouwd en dat kan lastig te verkopen zijn.

Is de backbase framework dusdanig makkelijk in gebruik, ja dan is het een kwestie van toepassen wanneer ik dat nodig acht (het bijvoorbeeld voortvloeit uit de type website die moet worden gemaakt).

[Anoniem: 14124]

BlueAce schreef op vrijdag 03 juni 2005 @ 11:32:
Ik denk dus dat RIA is weggelegd voor de bewuste afnemers op dit moment, de 'mainstream' heeft er niks mee.

Het is ook niet haalbaar voor de mainstream gebruiker. Het kost teveel tijd, is te complex, heeft teveel valkuilen, en vereist meer dan gemiddelde ervaring in een combinatie van meerdere technieken die per stuk al veel tijd kosten om te doorgronden.

Het zal qua frontend denk ik ook niet al teveel nut hebben, maar wel in backends. Op plaatsen waar veel crud operaties worden uitgevoerd of veel data wordt getoond haal je zeker veel winst.

[Anoniem: 2935]

BlueAce schreef op vrijdag 03 juni 2005 @ 11:32:
Voor deze opmerking ben ik door vrienden en bekenden wel eens uitgemaakt voor conservatieve lul, maar ik zie AJAX net als Flash: leuke toevoeging (ook aan de usability), meer niet. Een volledige RIA structuur heeft gewoon simpelweg geen nut op het web zoals het nu in elkaar zit en zoals het vertrouwd is. Wellicht NOG niet, maar ook dat valt te betwijfelen.

Ik zie bijvoorbeeld www.backbase.com en mijn onderkaak ligt op de vloer, maar is de site nou echt zoveel beter door de niet-bestaande refresh? Nee, dat vind ik absoluut niet. Daarom zijn er dus geen redenen voor mij om een "complete rich structure" (CRS?) uberhaupt te verkopen. Ik sta er niet achter.

Grappig dat je dat zegt, want ondanks dat ik bij Backbase werk ben ik het eigenlijk met je eens. Voor een corporate site als backbase.com zou ik normaal gesproken geen RIA aanraden, simpelweg omdat het niet nodig is. Het heeft te weinig toegevoegde waarde. Dat wij het dan wel doen is omdat het natuurlijk een beetje raar zou staan als we niet van ons eigen product gebruik zouden maken (iets wat ons bij de vorige site werd verweten).

Maar om nou te zeggen dat het nooit nuttig kan zijn is wat overdreven. Goede RIA's hebben wel degelijk (meetbaar) hun nut bewezen door zaken als verhoogde productiviteit (intranets), verhoogde conversie (premie-berekening --> offerte-aanvragen) en usability (dynamische formulieren).

Voor mij is het zwakste punt van de huidige RIA's nog steeds het interactie-ontwerp. De ontwerpers weten over het algemeen maar zelden echt de toegevoegde functionaliteiten van de gebruikte technieken om te zetten in één van de punten die ik hierboven heb genoemd. Dat is gelukkig echter een kwestie van tijd.

[BlueAce]

Zo te zien zijn we het er dus allemaal over eens dat RIA nog niet 'bestemd' is voor de mainstream. Zowel voor afnemer als uitvoerder als gebruiker. Maar wellicht dat projecten zoals Backbase en Ruby on Rails daar verandering in kunnen brengen.

BtM909 schreef op vrijdag 03 juni 2005 @ 12:09:
[...]

conservatieve lul

Anywee, met flash maak je tegenwoordig ook al serieuze webapplicaties hoor. Is het niet een kwestie van: wat de boer niet kent.....

Ik eet inderdaad nooit update-afhankelijke non-portfolio-achtige Flash sites Als je begrijpt wat ik bedoel...

Anoniem: 14124 schreef op vrijdag 03 juni 2005 @ 13:02:
[...]Het zal qua frontend denk ik ook niet al teveel nut hebben, maar wel in backends. Op plaatsen waar veel crud operaties worden uitgevoerd of veel data wordt getoond haal je zeker veel winst.

Op plekken waar je informatie-verhandeling het meest gevoelig is heeft het zeker nut. Denk aan www.basecamphq.com.

Anoniem: 2935 schreef op vrijdag 03 juni 2005 @ 13:43:
[...]

Grappig dat je dat zegt, want ondanks dat ik bij Backbase werk ben ik het eigenlijk met je eens. Voor een corporate site als backbase.com zou ik normaal gesproken geen RIA aanraden, simpelweg omdat het niet nodig is. Het heeft te weinig toegevoegde waarde. Dat wij het dan wel doen is omdat het natuurlijk een beetje raar zou staan als we niet van ons eigen product gebruik zouden maken (iets wat ons bij de vorige site werd verweten).

Dat is inderdaad volkomen logisch, maar ironisch genoeg vind ik dat dus net over the top.

Maar om nou te zeggen dat het nooit nuttig kan zijn is wat overdreven. Goede RIA's hebben wel degelijk (meetbaar) hun nut bewezen door zaken als verhoogde productiviteit (intranets), verhoogde conversie (premie-berekening --> offerte-aanvragen) en usability (dynamische formulieren).

Tuurlijk, met je eens. Ik zie het nut van Google Maps bijvoorbeeld wel in, ik denk iedereen wel. Ik beweer ook niet dat het nooit zo is, mocht je dat denken uit mijn post

Voor mij is het zwakste punt van de huidige RIA's nog steeds het interactie-ontwerp. De ontwerpers weten over het algemeen maar zelden echt de toegevoegde functionaliteiten van de gebruikte technieken om te zetten in één van de punten die ik hierboven heb genoemd. Dat is gelukkig echter een kwestie van tijd.

De manusjes-van-alles gaan het druk krijgen binnenkort. Je bent niet alleen maar een designer, of alleen maar een programmeur, je bent een... tja... interaction manager.

[Anoniem: 14124]

Waarom manusjes van alles? Je kunt een Ajax app prima maken met een team van specialisten met elk hun eigen specialisatie Als ieder zorgt dat zijn/haar deel werkt volgens een technisch ontwerp levert het geen problemen op als het goed wordt gecoordineerd. Het heeft zelfs zijn voordelen betreft het testen.

[BlueAce]

Anoniem: 14124 schreef op zaterdag 04 juni 2005 @ 20:15:
Waarom manusjes van alles? Je kunt een Ajax app prima maken met een team van specialisten met elk hun eigen specialisatie Als ieder zorgt dat zijn/haar deel werkt volgens een technisch ontwerp levert het geen problemen op als het goed wordt gecoordineerd. Het heeft zelfs zijn voordelen betreft het testen.

In de ontwikkelingsstatus ja, tuurlijk, maar dat technische ontwerp moet wel eerst verzonnen worden Dat vereist een kennis van de mogelijkheden.

[alienfruit]

Denk je nou serieus dat een interface ontwerp of interactie ontwerp het ook maar enigzins interesseert of jij de programmeur het kan maken. Nou ik kan je vertellen dat dit niet zo is, dat is jou specialiteit dus jij zorgt maar dat het werkt

[BlueAce]

alienfruit schreef op maandag 06 juni 2005 @ 02:22:
Denk je nou serieus dat een interface ontwerp of interactie ontwerp het ook maar enigzins interesseert of jij de programmeur het kan maken. Nou ik kan je vertellen dat dit niet zo is, dat is jou specialiteit dus jij zorgt maar dat het werkt

Ik heb in het begin wel een paar ontwerpers lichtelijk pissed gemaakt, en ik ben zelf ook een paar keer pissed geworden. Daarom dus: een alleskenner werkt gewoon vele malen soepeler bij een project dat gewoon het randje opzoekt van wat mogelijk is qua interface en usability.

Wil niet zeggen dat het in een hecht team niet zou kunnen natuurlijk.

[ Voor 6% gewijzigd door BlueAce op 06-06-2005 12:26 ]

[Anoniem: 14124]

Ik ben het daar niet mee eens. Zowiezo niet omdat zulke personen niet bestaan, immers bestaat een dag uit een beperkt aantal uren en van alles wat er bij komt kijken, alles weten is niet mogelijk, laat staan het toepassen en er praktijkervaring in hebben. Er zijn zowiezo maar weinig frontend georienteerde developers die een fatsoenlijk technisch ontwerp kunnen maken.

[Anoniem: 2935]

Anoniem: 14124 schreef op maandag 06 juni 2005 @ 13:01:
Er zijn zowiezo maar weinig frontend georienteerde developers die een fatsoenlijk technisch ontwerp kunnen maken.

Behalve als je praat over een frontend-georienteerd technisch ontwerp.

[chris]

offtopic:
@Gordijnstok: het is sowieso, niet zowiezo.

Verder is dit een erg interessante linkt voor mensen die into Ajax zijn. Verder denk ik zelf dat Ajax niet heel veel kosten hoeft te hebben, in bijvoorbeeld Ruby on Rails zit het standaard redelijk ingebakken, en is het voor simpele CRUD dingen totaal geen werk om te gebruiken. Verder juich ik Ajax toe in bijvoorbeeld CMS'en, hier kan het tot een hogere productiviteit leiden, maar: je moet er natuurlijk wel van op aan kunnen dat de gebruikers een compatibele browser hebben. Dus voor normale sites vind ik ajax echt geen goed plan, maar bij sites waarbij je eisen kan stellen aan de gebruiker (Je moet IE > 5 of Mozilla gebruiken) kan het zeker een toevoeging zijn.

Ik denk wel dat er straks net zoals met Flash ook heel wat dingen fout gaan, zoals je nu mensen ziet die hun hele site in flash bouwen (wat in 90% van de gevallen echt een slecht idee is, in 10% van de gevallen supermooi).

[Anoniem: 14124]

Anoniem: 2935 schreef op maandag 06 juni 2005 @ 13:33:
Behalve als je praat over een frontend-georienteerd technisch ontwerp.

Dat klopt, als er al een frontend-georienteerd technisch ontwerp wordt gemaakt. Maar bij zaken als een uml of een erd (en dus niet frontend georienteerd) weet de gemiddelde web ontwikkelaar zich geen raad.

[ Voor 44% gewijzigd door Anoniem: 14124 op 06-06-2005 14:06 ]

[Anoniem: 14124]

Anoniem: 2935 schreef op vrijdag 03 juni 2005 @ 13:43:
Maar om nou te zeggen dat het nooit nuttig kan zijn is wat overdreven. Goede RIA's hebben wel degelijk (meetbaar) hun nut bewezen door zaken als verhoogde productiviteit (intranets), verhoogde conversie (premie-berekening --> offerte-aanvragen) en usability (dynamische formulieren).

Dit geloof ik meteen, maar ik probeer het hier intern ook tot een item op de agenda te maken om in het productbeleid een Ajax draai te geven. Heb jij nog enkele cases die roi/toc aantonen die ik kan gebruiken voor interne communicatie? Op het web kom ik alleen schattingen/meningen/veronderstellingen tegen en die zijn moeilijk te verkopen.

[Johny58]

Dit probleem heb ik dus ook. Ik ben momenteel bezig met een onderzoek/afstudeeropdracht/scriptie naar de voordelen van een RIA (eigenlijk specifiek of het intressant is voor een bedrijf om gebruik te gaan maken van Backbase) boven andere methoden om een presentatielaag te ontwikkelen voor systemen. Hierbij moet ik een advies uitbrengen aan een bedrijf waarbij ik uiteraard met feiten moet komen. Hoewel het duidelijk is dat RIA's erg intressant zijn en dat er duidelijk voordelen aan verbonden kunnen zijn, zijn er eigenlijk, voor zover ik het tot nu ben tegen gekomen, geen concrete resulaten beschikbaar over of het nu echt leidt tot een hogere mate van productiviteit of usability. Zoals Gordijnstok boven mij al zegt kom ik ook alleen maar "schattingen/meningen/veronderstellingen" tegen.

Dit dus in tegenstelling tot wat wat Blues zegt:

Anoniem: 2935 schreef op vrijdag 03 juni 2005 @ 13:43:
[...]
Goede RIA's hebben wel degelijk (meetbaar) hun nut bewezen.
[...]

Op wat vor een manier is dit te meten? Hoe kan ik in pure feiten een bedrijf ervan overtuigen dat het goed is om gebruik te gaan maken van een product als Backbase?

[ Voor 8% gewijzigd door Johny58 op 16-06-2005 11:03 ]

[Anoniem: 2935]

Johny58 schreef op donderdag 16 juni 2005 @ 10:40:
Op wat vor een manier is dit te meten? Hoe kan ik in pure feiten een bedrijf ervan overtuigen dat het goed is om gebruik te gaan maken van een product als Backbase?

• Hogere productiviteit - Zeker meetbaar, maar sterk afhankelijk van de doelstellingen (hoe snel wordt informatie gevonden, hoe snel kunnen bepaalde bewerkingen/taken worden uitgevoerd, etc.)
• Hogere conversie - Rich forms vs. HTML forms, conversie (hoeveel bezoekers gaan daadwerkelijk tot aankoop over) is heel goed meetbaar.
• Betere usability - Is wel meetbaar maar wel discutabel. Eigenlijk wordt dit alleen gemeten door user satisfaction te peilen d.m.v. vragenlijsten en scorekaarten.

Nee, ik heb geen rapporten van echte onderzoeken beschikbaar. Jullie weten allemaal hoe frigide er met dit soort informatie wordt omgesprongen in de business. Als je hier informatie over wilt moet dat via de standaard kanalen.

[Anoniem: 14124]

Anoniem: 2935 schreef op donderdag 16 juni 2005 @ 13:54:
[...]

• Hogere productiviteit - Zeker meetbaar, maar sterk afhankelijk van de doelstellingen (hoe snel wordt informatie gevonden, hoe snel kunnen bepaalde bewerkingen/taken worden uitgevoerd, etc.)
• Hogere conversie - Rich forms vs. HTML forms, conversie (hoeveel bezoekers gaan daadwerkelijk tot aankoop over) is heel goed meetbaar.
• Betere usability - Is wel meetbaar maar wel discutabel. Eigenlijk wordt dit alleen gemeten door user satisfaction te peilen d.m.v. vragenlijsten en scorekaarten.

Jullie weten allemaal hoe frigide er met dit soort informatie wordt omgesprongen in de business.

Ja helaas wel, maar zonder duidelijk redenen Het zou imo de verkoop van dit concept beter doen als dit soort informatie gewoon de wereld in kwam. Nu weet nog niemand wat de voordelen zijn en die drempel hou je zonder trigger van een potentiele klant

[ Voor 8% gewijzigd door Anoniem: 14124 op 16-06-2005 16:49 ]

[Anoniem: 12181]

Wellicht kunnen jullie iets met de volgende links?

IDC White Paper: Business Impact Of Rich Internet Applications, inclusief cijfermateriaal

http://www.webvertising.com/riapps/casestudies.html

Case studies bij Macromedia, vaak inclusief resultaten

Wall Street Journal: Rich Internet Applications Drive Online Retail Sales