Goed stappenplan, lekker concreet. Wat ik echter mis (vanuit het oogpunt van loyaliteit) is de loyaliteit van de aanbieder. Ik ben loyaal aan mensen die loyaal aan mij zijn. M.a.w. ik kan allerlei al dan niet oprechte instrumenten inzetten om 'quasi-loyaliteit' te bevorderen en te belonen, maar zonder blijk van mijn loyaliteit aan de klant zal dat niet erg lang beklijven. Waaruit blijkt mijn loyaliteit: als ik de klant ook trouw blijf als hij even niets afneemt, als hij even moeite heeft met betalen, als ik kan voorzien dat hij in de problemen gaat komen door veranderende omstandigheden en ik daarop anticipeer i.p.v. de hulpvraag af te wachten. Dat kan ik natuurlijk niet voor iedereen volhouden. Daarom is het belangrijk de relatie niet op korte termijn verkopen te waarderen, maar op langetermijn klantwaarde.
Ik vind het een geweldige uitslag. Het is vooral opmerkelijk dat twee niet-commerciële reclames bovenaan eindigen. Zeitgeist?
@mijzelf Er is een probleem met de link naar de validator. Je kunt hem wel volgen, maar moet dan nog een keer op Revalidate klikken.
Cross-browser check is één ding, maar een webpagina zou toch in ieder geval aan een HTML-standaard moeten voldoen, anders weet je überhaupt niet wat verschillende browsers en browser-updates ermee gaan doen. www.marine.nl voldoet in ieder geval niet: een test bij de W3C Markup Validation Service levert 39 fouten: [url=http://validator.w3.org/check?uri=http%3A%2F%2Fwww.marine.nl%2Findex.html&charset=%28detect+automatically%29&doctype=Inline&group=0]Invalid Markup Validation...[/url]. 'This page is not Valid XHTML 1.0 Strict!', terwijl in de HTML-source toch wel degelijk staat dat het dat wel zou zijn. Waarschijnlijk is deze site slachtoffer van het feit dat browsers zich steeds meer aan standaarden gaan houden. Wacht maar tot IE8 uitkomt: dat wordt pas echt lachen.
De Chinese zoekmachine Baidu is inmiddels de derde zoekmachine in grootte, achter Google en Yahoo, maar nog voor Windows Live Search, zie: [url=http://www.webwereld.nl/articles/48241/live]Baidu groter dan Microsoft Live Search[/url], [url=http://www.jeroen.com/woordenboek/baidu]Wat is Baidu[/url]. En dan staat China nog maar relatief aan het begin van de adoptiecurve. Er staat ons nog heel wat te wachten vanuit het oosten.
Er is nog een ander probleem: het target-attribuut wordt in de HTML-standaarden afgeraden. In HTML 4.01 (1997/1999) en XHTML 1.0 (2000/2002) (Strict) komt het niet meer voor . Als je de afgeraden aspecten wilt gebruiken, moet je HTML 4.01 of XHTML 1.0 Transitional gebruiken. XHTML 1.1 (2001/2007) kent geen Transitional versie. Citaat uit de HTML 4.01 DTD: "This is the HTML 4.01 Transitional DTD, which includes presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required." Reden is waarschijnlijk dat het openen van een nieuw venster niet als eigenschap van een tekst wordt beschouwd, maar als functie van de applicatie. Dit moet dan dus met Javascript worden opgelost. Als je wilt meegaan met de ontwikkeling van standaarden heb je dus maar 2 keuzes: - geen nieuw venster openen - Javascript gebruiken om een nieuw venster te openen, waarmee je de gebruiker in zijn keuzes beperkt.
Komende jaren bedoel je, de 35 afleveringen worden over twee winterseizoenen uitgesmeerd. Ik vind dat best moedig, om te proberen de aandacht van de kijkers twee jaar vast te houden.
@Marco: Je hebt een punt al je aangeeft dat ik me teveel op de techniek richt. Heeft waarschijnlijk met mijn ICT-achtergrond te maken. @Ton: Open API's - helemaal mee eens. Dat is een manier om in het netwerk van de gebruiker te komen. Maar dan heb je nog niet zoveel bijgedragen aan de experience van de gebruiker. Daarvoor maak je rondom je dienst of product coole, gave, vette toepassingen, gadgets, widgets, snipplets, games, videos etc die gebruikers in hun space, desktop of whatever willen opnemen. En dan is de keuze van technologie mogelijk wel belangrijk.
Adobe AIR is mijns inziens onderdeel van een tweetal trends: enerzijds de gebruiker die op het web geen kale informatie meer zoekt, maar een experience, en anderzijds de gebruiker die wil dat zijn applicaties altijd en overal, op alle mogelijke apparaten beschikbaar zijn. Deze beweging begon met Flash, Ajax en Mozilla XUL. Die gaven webdevelopers de mogelijkheid om gebruikers een meer interactieve ervaring te geven. Nadelen: Flash was niet open, Ajax niet multimediaal en Mozilla XUL werd alleen voor client-applicaties gebruikt (uitzondering: Ajax13.com maakt een online office suite op basis van Mozilla XUL). Daarnaast konden deze applicaties niet offline gebruikt worden en waren ze sterk afhankelijk van de browser, waardoor ze ook niet vanzelf op alle apparaten goed werken. De volgende stap wordt nu gezet: Google komt met Gears, een toolkit voor offline Ajax, die al wordt toegepast door Zoho.com voor zijn online office applicaties. Microsoft komt met Silverlight, een multi-device, multimediaal, multi-browser, multi-OS platform voor interactieve applicaties. Sun komt met JavaFX (vanzelf ook multi-multi) en Adobe dus met AIR. Al deze platforms moeten leiden tot een 'rich user experience', die ik als gebruiker kan aanspreken vanaf elk willekeurig apparaat, of ik nu online ben of niet, en waarbij de software via de browser wordt gedistribueerd. Mijn verwachting is dat de markt opnieuw verdeeld gaat worden. Het is niet vanzelfsprekend dat Adobe - dat nu leidend is met Flash - ook leidend blijft. Microsoft heeft met Silverlight een belangrijke troef, zeker nu Novell het ook overzet naar Linux. Voor marketeers zitten m.i. aan deze ontwikkeling twee uitdagingen: - welke technologie moet je kiezen voor je eigen webplatform? ofwel: heeft de gebruiker voorkeur voor een bepaalde technologie? - als gebruikers netwerken en communities vormen via applicaties van dit soort platforms, wat moet je dan doen om bij die netwerken aan te haken. Ofwel: het AdWords-model is gebaseerd op webpagina's, maar wat gebeurt daar straks mee.
De vorige Flight Sim was ook leuk: [url=http://www.isoma.net/games/goggles.html]Goggles[/url]
Zomaar een overzichtje gegoogled: [url=http://www.vacature.com/scripts/Actueel/display-article.asp?ID=3347&artCount=12&startPos=1&artsLoaded=1]Werkers van het web[/url]. (ik denk dat ze nog een web developer nodig hebben die ervoor zorgt dat deze pagina ook in IE6 goed getoond wordt).
@Bas Ik ben het met je eens vwb de complexiteit van het NGI-model. Het is erg gedetailleerd. Als startpunt geef ik (binnen ICT dan) daarom de voorkeur aan het model van het CIO-platform [url=http://www.cio-platform.nl/documenten/070605ciohrmdef.pdf](HRM functieprofielen ICT)[/url]. Ik ben vauit de opleidingskant erg benieuwd naar wat er uit deze discussie gaat komen.
@Leonard: Het voordeel van dit soort standaardiseringen is inkoop. Vraag aan een uitzendbureau, detacheerder, wervingsbureau, opleider een offerte voor resp. het uitzenden, inhuren, werven of opleiden van medewerkers, en eis dat ze de gestandaardiseerde functiebeschrijvingen als uitgangspunt nemen. Dan kun je de offertes tenminste vergelijken. Je kunt natuurlijk ook eisen dat ze zich aan jouw eigen functiebeschrijvingen houden, maar omdat dat voor iedere klant opnieuw gedaan moet worden is het gevaar reëel dat dat slechts cosmetisch wordt uitgevoerd (met copy/paste).
Ik zou voor de technische functies ook kijken naar het werk van het CIO-platform ([url=http://www.cio-platform.nl/documenten/070605ciohrmdef.pdf]HRM functieprofielen ICT[/url]) en de NGI ([url=http://www.ngi.nl/onderdeel/default.aspx?o=3045&p=255]Functiebeschrijvingen[/url], [url=http://www.sdu.nl/catalogus/ICT/9789044003437.jsp]Taken, Rollen, Functies en Competenties in de informatica[/url]). Zijn er m.b.t. het werkveld van internetbureaus overlappen in te beschrijven functies? Is de methodiek toepasbaar? Belangrijk aspect van beide methoden is dat ze de beschrijvingen generiek houden: wat doet iemand, en niet waarmee (de context). Een PHP Developer is dan net als een ASP.NET developer een Systeemontwikkelaar. In de nadere specificaties kan worden opgegeven: waarmee (PHP), welk niveau (junior), wat voor soort bedrijf (internationaal) etc.