Sven stelt dat de scheiding van content en vorm momenteel nog wat ontbreekt, althans, dat denk ik. Het is nog al een lang ding — an sich niets mis mee, zelf produceer ik ook geregeld enorme lappen tekst — zonder dat er een duidelijke stelling of conclusie uit lijkt te komen. Ik heb ook het idee dat hij bepaalde onderdelen van HTML niet kent; als ik zijn pleidooi goed begrijp, zoekt hij naar een oplossing die er al is.

Op een paar punten denk ik dat Sven er compleet naast zit; laat ik dat maar eens met wat quotes en antwoorden proberen duidelijk te maken.

Wie ingevoerd is in CMS, SEO, RSS, SOAP en REST en andere cryptische afkortingen kijkt naar het internet als een berg min of meer geordende informatie. De betekenis van die informatie is door computers bijna niet te vatten, maar voor de menselijke gebruiker erg relevant. Juist voor die menselijke gebruiker is het ook belangrijk dat die informatie op een verteerbare vorm wordt gepresenteerd. Alleen, die presentatie komt steeds meer los te staan van de inhoud, omdat het gedicteerd wordt door bijvoorbeeld corporate design guidelines, of gebruiksvriendelijkheid, overzichtelijkheid en technische mogelijkheden.

Tot zover ga ik nog met Sven mee. Een computer heeft inderdaad geen menselijk inzicht en zal dus nooit kunnen begrijpen waar bepaalde content over gaat. Althans, niet tot we “echte” AI hebben, en als dat er al komt duurt dat nog wel even.

Aan de andere kant ordenen we de informatie op basis van de inhoud. Zoekmachines zoeken naar woorden, eigenschappen van plaatjes, meta-informatie en verbanden tussen de informatie (bijv. links). Hypertext Links geven natuurlijk zelf al een bepaalde ordening aan.

Ik zie hyperlinks meer als pure verwijzing, zonder al te veel ordening. Het is een koppeling, een “zie ook:”. Zoekmachines kunnen eventueel aan de hoeveelheid links een waarde gaan hangen (“als 100 mensen naar een pagina linken, dan zal die wel interessanter zijn dan wanneer 1 persoon dat doet”), maar dan nog zegt dat an sich niets over relevantie. Ik kan in dit verhaal linken naar een plaatje van een sneeuwpop, maar die sneeuwpop heeft dan niet ineens automagisch iets met HTML te maken, of vice versa.

Maar niet alleen zoekmachines willen ‘pure’ content. De app en de widget winnen flink terrein, en willen ook gevoed worden door “pure” content. De opmaak is immers onderdeel van de betreffende applicatie. Ook het verschijnsel mashup wil graag van verschillende bronnen pure content combineren en op een nieuwe manier presenteren.

Ik zou niet zo zeer van “pure” content willen spreken, maar van “logisch geordende content”. Ik zie “pure content” meer als, pak hem beet, plain text, zonder enige vorm van ordening. Zoekmachines kunnen daar misschien wel iets mee, maar op het moment dat ik het ga structureren wordt er ineens veel meer mogelijk. Dat geldt nog sterker voor mashups.

Nee zeker niet, en ik maak me hier dan ook erg schuldig aan Jip-en-Janneke-taal. Maar kijkend naar de lingua franca van het internet, (X)HTML, dan valt toch op dat je heel wat in die HTML-code moet zetten om de pagina later te kunnen opmaken middels CSS. Denk aan alle DIV’s en SPAN’s en de overmaat aan stijlattributen die stiekem toch de HTML-code in sluipen. Een zoekmachine moet deze rompslomp wel doorploegen om tot de kern van de zaak te komen.

En dus is het aan degene die die markup maakt om daar niet al te veel overbodige rommel tussen te zetten. Ik denk dat deze zin een reden was voor Fred om me op het artikel te wijzen, aangezien ik het daar gisteren nog over had.

Ook is het ook nog eens zo dat je HTML vaak niet helemaal vrij kunt opmaken aan de hand van de informatie, omdat het anders moeilijk te stylen is. Denk aan tables, list menus en vooral ongepaste zaken als HR’s. HTML beschrijft eigenlijk de opmaak van een rapport van het CERN. Op informatieniveau is er geen onderscheid tussen ‘ordered lists’ en ‘unordered lists’, maar bijvoorbeeld een paragraph is weer heel ‘non-descript’. Een paragraph zou bijvoorbeeld een of meer kernwoorden moeten kunnen hebben. Makkelijk voor quickscans en zoekmachines. Begrippen als samenvatting, voetnoot, referentie zouden mooie toevoegingen zijn aan HTML. En ook de regels waarmee je HTML samenstelt met gebruikmaking van deze tags zouden wat beter gedefinieerd moeten worden.

Met deze paragraaf heb ik tamelijk veel moeite. Sven stelt dat je een hele bult onnodige, of in ieder geval onsemantische, HTML moet gebruiken om een document van (CSS) stijlen te kunnen voorzien.

Geen idee waar hij dat vandaan haalt, maar kloppen doet het niet.

Je kunt, vandaag de dag, best een document in HTML opzetten dat geen enkele “overbodige” rommel op het gebied van presentatie bevat, zeker als je eens kijkt wat HTML5 je te bieden heeft.

De reden dat je op zoveel pagina’s zoveel extra rommel tegenkomt, is dat er op die pagina’s allerlei zaken staan die eigenlijk niets met de content te maken hebben. Denk aan navigatie, en dan vooral “extra” navigatie die je — meestal — in sidebars tegenkomt. Denk aan advertenties. Denk aan lijstjes met “recente artikelen” en “recente reacties”.

Een andere reden dat veel documenten vol staan met allerlei extra rommel, is simpele gemakszucht of onkunde van de maker. Je hoeft niet een hele pagina uit 80 tabellen op te trekken, maar als je niet thuis bent in CSS dan is dat wel de enige manier om de presentatie die je voor ogen hebt daadwerkelijk te realiseren.

Dat ligt echter niet aan de eventuele tekortkomingen van HTML, CSS of zelfs maar de browsers.

Dat een paragraph “non-descript” is, is logisch: het is een paragraaf in een tekst; die staat of valt over het algemeen met de paragrafen ervoor en erna. En waarom zou er geen verschil zijn, op informatieniveau, tussen unordered en ordered lists? Wat voor informatie zou daar aan toegevoegd of afgehaald moeten worden?

RSS doet het eigenlijk veel beter, zij het heel beperkt. Daar is de content puur ingedeeld op basis van de inhoud zonder enige concessie aan de presentatie (behalve wellicht presentatievolgorde).

Dit vind ik een heel vreemde gedachte. In RSS is alle content in feite een grote lap platte tekst, zonder enige vorm van semantiek of duiding. Pas als je binnen die RSS gebruik gaat maken van HTML, komt dat onderscheid er. RSS ziet er misschien gestructureerder uit dan HTML, maar ook daarin kun je prima specificeren wie de auteur is, wanneer het artikel geplaatst is, enzovoorts.

Mijn pleidooi gaat dan ook over een pure markuptaal die aangeeft wat tekst betekent in een document. Headings horen daarbij, maar vooral allerlei geannoteerde tekst en plaatjes, en de verbanden tussen al de content onderdelen.

Goed idee. Laten we die headers gaan aanduiden met elementen als “header”. Weet je wat, ik wil koppen een beetje hierarchische informatie meegeven; laat ik H1 gebruiken voor een header van het hoogste niveau, H2 voor een sub-header, H3 voor iets dat daar weer onder valt, enzovoorts.

Verder wil ik bepaalde stukken tekst nadruk kunnen geven; laat ik dat “emphasis” noemen en daar een element EM voor gebruiken. Weet je wat? Ik wil sommige zinsnedes nog meer nadruk geven, een “strong emphasis” dus, oftewel STRONG.

Plaatjes konden in HTML al, maar ik wil dat iets kunnen uitbreiden: ik wil er een titel of bijschrift kunnen zetten. Weet je wat? Ik gebruik daar FIGURE voor.

Laat ik daar vooral niet stoppen: ik wil ook stukjes tekst in de zijlijn kunnen toelichten. Dat noem ik… ach, laat ik ASIDE gebruiken. En die voetnoten kan ik mooi in een FOOTER kwijt.

Ik kan nog wel even doorgaan, maar ik denk dat het punt wel duidelijk is: in HTML, en zeker in HTML5, kun je al redelijk wat betekenis aan onderdelen van je document geven. Is het perfect? Nee, maar in plaats van HTML weggooien en met iets heel nieuws komen, zonder te vertellen wat dat “iets heel nieuws” nou precies zou moeten zijn, lijkt het me handiger om voort te borduren op wat we nu hebben, waar mensen nu bekend mee zijn, en waar al gigantisch veel programmatuur voor bestaat.

De goed verstaander leest hier ’semantic web’.

Ah, Semantic Web, het wachten was op die term.

Nou kun je dat vandaag de dag best zelf realiseren. Bouw maar een pagina die uitsluitend bestaat uit Javascript en dat Javascript haalt vervolgens een XML bestand op met louter semantische structuren en gaat vervolgens je hele pagina opbouwen.

Gelukkig ziet Sven zelf ook al in dat dat onhaalbaar is. De goede verstaander haalt er bovendien uit dat je niet zomaar iets kunt verzinnen: er bestaat ook nog zoiets als “de rest van de wereld”, en tenzij jouw idee bijzonder goed is en/of jij een hele grote speler bent (neem een Google, Microsoft), de rest van de wereld niet meegaat.

Daarom zijn er ook commissies als de W3C en WHATWG, waarin mensen uit verschillende hoeken van het web proberen afspraken te maken over precies de zaken waar Sven ook al over denkt.

Is dat er dan niet allemaal al lang?

Ja.

HTML5 implementeert al heel wat meer semantiek dan de voorgaande versies. MicroFormats vullen dat aan. En als je met een zinnig voorstel komt en mensen er enthousiast voor kunt krijgen, kun je er vandaag nog je eigen toevoeging aan maken.

Laat ik maar eens een wilde stelling poneren: het Semantic Web bestaat allang.

Ja en nee. Om bij het voorbeeld van HTML te blijven is het zo dat ik een pagina in mijn browser open en dus informatie opvraag. Ik open dus een HTML-bestand en die gaat vervolgens op eigen houtje de bijbehorende opmaak regelen door het laden van CSS en script files. Vaak gelukkig aan de hand van wat ik voor browser heb, maar meestal levert dit een hutspotprak content en vorm op.

Hoe vaker ik deze paragraaf lees, hoe meer pijn in mijn hoofd ik ga krijgen.

Allereerst: dat HTML-bestand doet helemaal NIKS. Niet op eigen houtje, niet op andermans houtje, HTML is gewoon een kwak content, met links naar CSS-bestanden (die de presentatie kunnen beinvloeden) en Javascript-bestanden (die interactie kunnen toevoegen, en soms ook nog een stukje presentatie meenemen.

Die bestanden worden door de browser opgehaald. En inderdaad, niet elke browser kan met alles even goed overweg — Internet Explorer, bijvoorbeeld, maar je kunt ook denken aan text-only browsers als Lynx, die de CSS- en Javascript-bestanden dan ook links laat liggen.

Die hutspotprak? Geen idee wat daarmee bedoeld wordt.

Eigenlijk zou je browser twee dingen moeten ophalen: de content en een presentatievoorschrift (CSS/Javascript to the limit zeg maar). Maar technisch gebeurt er natuurlijk iets heel anders: het voorschrift gaat als eerste aan de slag en peutert de content uit elkaar om het op de juiste manier weer te geven.

Laten we het nog iets verder uitkristalliseren: je browser zou allereerst het belangrijkste moeten ophalen: de content. Die zal over het algemeen in HTML gegoten zijn. Verder kan daar nog opmaak aanhangen, in het ideale geval volledig afgesplitst naar een CSS-bestand. Voor de interactie gebruiken we Javascript, wat ook weer naar een apart bestand gaat. Nog een stap verder: plaatjes zetten we ook in een apart bestand.

Bij het eventuele ophalen van die bestanden laten we de browser — al dan niet met enige invloed van de gebruiker — beslissen welke bestanden-ie wel en niet aankan, en welke bestanden er dus wel of niet moeten worden opgehaald.

Oh, wacht, dat is precies wat er vandaag de dag al gebeurt.

Helemaal geldt dit voor mashups: daar wordt content immers van meerdere bronnen opgehaald en met elkaar in verband gebracht. In de browser is dus eigenlijk het presentatievoorschrift de baas, maar we klikken op basis van een link die iets zegt over de content.

Tenzij ik me vergis, is een mashup een stukje programmatuur dat de functionaliteit van twee verschillende sites (of web-applicaties) combineert, en aan de hand daarvan zelf die gecombineerde content uitvoert.

Dat kan eventueel in de browser gebeuren, maar over het algemeen zal dat server-side gebeuren.

Wat dat met links te maken heeft, ontgaat me een beetje, tenzij Sven het hier niet over hyperlinks heeft.

Lastig dilemma. Ik denk dat we daarom de definitie van een hyperlink moeten verbreden. Een hyperlink geeft niet alleen de locatie van content aan maar ook hoe het bij voorkeur gepresenteerd moet worden.

Dat bestaat al. Aan een A-element, waarmee je hyperlinks maakt, kun je al een relatie hangen. En een beschrijving van het soort informatie waar de link naar wijst. En een taal waarin die content is geschreven.

Ook in LINK-elementen kun je dat soort metadata meegeven.

(Dat gebeurt nu eigenlijk ook: www.nu.nl vs. m.nu.nl zeg maar, maar dat is niet helemaal waar ik naar toe wil). Ik zou willen pleiten voor een protocol header waarin een link naar het presentatievoorschrift van voorkeur staat. De opvragende applicatie hoeft er natuurlijk niets mee te doen, met dat presentatievoorschrift, maar als deze dat wel doet dan kan hij ermee aan de slag. Het gaat er om dat content en presentatie los van elkaar staan, dus ik vind dat er in de content geen verwijzingen moeten zijn naar het presentatievoorschrift. De opgevraagde pagina bestaat uit pure content.

En wat gebeurt er dan als je die content “direct” opvraagt, zonder een link-met-presentatievoorschrift? Wat zijn de implicaties voor links naar “externe” content, dus als ik naar content op iemand anders’ site link? Moet ik daar wel invloed over hebben?

Het lijkt me veel logischer om “presentatievoorschriften” direct aan de content te koppelen — zoals het nu dus gebeurt — dan om die te laten afhangen van links naar die content.

Makkelijk voor mashups, maar ook voor dataspaces en zeker voor widgets, gadgets en apps. En bedenk eens wat dit voor de snelheid van browsers kan doen, want de content zonder alle opmaak kan wel eens een heel stuk lichter zijn. Presentatievoorschriften lenen zich immers heel goed voor cachen, dus die hoef je niet telkens opnieuw binnen te halen. Eerlijkheidshalve is het natuurlijk wel zo dat de eerste keer dat je een pagina met een bepaald presentatievoorschrift binnenhaalt, dat wel wat langer kan duren.

Hier haalt Sven volgens mij weer wat dingen door elkaar, en hij lijkt bepaalde eigenschappen van het huidige web niet te begrijpen.

CSS (en andere externe bestanden) zijn ook prima te cachen, dus na de eerste pageview op een site ben je al lichter aan het browsen. De enige overhead die je hebt, is wat er om die content heen staat; de navigatie en overige meuk die je steeds meer tegenkomt.

Het zou leuk zijn als je in HTML een soort van include kon gebruiken om die zaken ook naar een apart bestand af te splitsen. Je hoeft dan niet alle sidebars, extra headers, advertenties enzovoorts op te halen omdat je toevallig een tweede pagina wilt zien.

Nadeel van die methode is dat het extra requests naar de webserver oplevert, wat het opvragen van de totale pagina langzamer maakt; het voordeel dat je haalt uit het uit de content strippen van die extra code wordt zo weer teniet gedaan. Een ander nadeel is dat het weer allerlei interessante beveiligingsproblemen kan opleveren, die we vandaag de dag al met Javascript hebben.

Met een beetje werk en fantasie zou je overigens wel een splitsing kunnen maken, via Javascript en/of iframes, en dat wordt ook al gedaan. Vooral webapps staan bol van AJAX, wat niet veel anders is dan “na het laden van de pagina extra informatie ophalen om die pagina aan te vullen of te veranderen”.

Voor een site die vooral om content draait, levert dat in de meeste gevallen meer problemen op dan dat er opgelost worden. Het is ook niet zo vreemd dat je het bijna nergens tegenkomt.

Ik vind het model heel elegant en dat is een uitspraak die je misschien alleen van programmeurs zult horen. De meeste normale mensen kunnen niks met elegante data. Ontwikkelaars echter wel, die kunnen veel sneller schakelen tussen presentatiemethoden en veel makkelijker content aggregeren.

En die ontwikkelaars kunnen dat ook al, zolang de data maar gestructureerd wordt gehouden. Of die structuur nou HTML, XML, JSON of iets anders is, maakt dan per saldo niet eens zoveel uit. Elke zichzelf respecterende programmeertaal heeft tegenwoordig standaard-functionaliteit (of libraries) voor het werken met DOM, XML en HTML, en elke pagina waarvan de code klopt is dan te gebruiken als databron.

Ook kun je de vormgever en de author nog onafhankelijker van elkaar laten opereren. Dat is fijn voor beiden, want ten opzichte van elkaar zijn ze eigenlijk heel restrictief: de “dit zinnetje moet korter want ik heb geen ruimte” discussie wil je minimaliseren.

Die discussie verandert niets door het dumpen van HTML, want die discussie is inherent aan het medium. Een ontwerper zal er rekening mee moeten houden dat de content misschien anders is — of anders gezien wordt — dan in zijn Photoshop-mockup. Ontwerpen voor het web is nou eenmaal iets anders dan ontwerpen voor papier.

Dat is ook een groot voordeel, trouwens, want daarmee wordt informatie ineens geschikt voor een bredere groep gebruikers. In plaats van dat een slechtziende een andere versie van de content moet zoeken, kan hij simpelweg het lettertype in zijn browser groter zetten. Ja, dan zal er het nodige gaan schuiven, maar dat zal die slechtziende worst zijn.

Bovendien: veel van die verschuifproblemen zijn te ondervangen.

Het tweerichtingskarakter van het internet (Web 2.0 zo je wilt) is er ook mee gediend. Wil iemand bijdragen dan hoeft hij of zij zich alleen maar druk te maken over de inhoud van zijn/haar bijdrage. Laat het opmaken maar aan de machine over. Op die manier verzamel je veel beter hanteerbare content. Dit is niet het sterkste argument, geef ik toe, want dit gebeurt al in hoge mate, maar het toevoegen van geolocatie en sensorische informatie wordt wel steeds belangrijker dus ook de upstream mechanismen van het web verdienen heroverweging.

Waarom? Wat heeft het meesturen eventuele extra meta-informatie — want daarover heb je het als je over geolocatie en dergelijke begint — te maken met de uitvoer? Dat gebeurt op een heel ander niveau! De gebruiker hoeft helemaal niets op te maken of te coderen, dat doet de applicatie, tenzij de maker van de applicatie verdomde lui is.

Dit is niet zozeer “niet het sterkste argument”, dit is gewoon een non-argument.

Sommige uitgevers zullen nu hun billen bij elkaar knijpen, want als dit ooit een feit zou worden dan is herpubliceren van hun dure content nog gemakkelijker geworden. Ik ben van mening dat dit eigenlijk een achterhoede gevecht is van die uitgevers. Het zijn op dit moment toch al huilebalken, maar veel aan hun modellen veranderen willen ze niet en daar is Darwin vrij meedogenloos voor. Maar als doekje voor het bloeden: je zou best een presentatievoorschrift kunnen bedenken die als enige de content kan interpreteren door middel van encryptie. DRM zeg maar.

Whu-… Wat? DRM? En die dan gaan laten afhangen van wat er aan de kant van de consument gebeurt?

Allereerst: als je jezelf afhankelijk gaat maken van DRM heb je bij voorbaat al verloren.

Verder: als je al besluit dat je van DRM gebruik gaat maken, dan regel je dat op het moment dat de content nog verstuurd moet worden, niet op het moment dat de gebruiker het al in handen heeft. Server-side, dus.

Ik ben echt reuze benieuwd hoe Sven dat hele DRM-verhaal ongeveer voor zich ziet, want ik zie geen enkele manier om dat op een open web mogelijk te maken. Noch zie ik daar de noodzaak toe.

Anderzijds denk ik dat in de toekomst content wel eens heel goedkoop kan worden. Veel publiek zal meningen, nieuws en allerlei andere bijdragen leveren, vaak om niet.

Die toekomst is al een paar jaar aan de gang, hoor…

Ik vind natuurlijk dat journalisten werk doen van een andere orde, en daar zou zeker ook een prijs voor moeten zijn. Maar journalisten verzamelen informatie, onderzoeken, ordenen en aggregeren het. Misschien gaan we wel juist betalen om het te vinden, te verzamelen, te interpreteren en om het goed in verband te zien. (Of juist negeren en weigeren het te zien al naargelang je politieke voorkeur).

Dat is iets waar momenteel inderdaad heel druk over gedacht en gespeculeerd wordt. Allereerst de vraag of journalisten daadwerkelijk een toegevoegde waarde hebben (ik neig naar een voorzichtig “ja”) en bovenal hoe groot die waarde is en hoe dat allemaal betaald moet gaan worden.

Micropayments werden al jaren geleden aangedragen als De Toekomst, maar dat is nog niet echt van de grond gekomen. Mocht dat wel gaan gebeuren: HTTP is er sinds versie 1.1 al op voorbereid in de vorm van status header 402 (“Payment Required”).

Ondenkbaar? Abonnees van kabel TV zijn best bereid te betalen voor uitzending gemist-programma’s, ook als je het in een veel minder aantrekkelijke presentatievorm elders gratis kunt kijken. Knoop het in je oren!

[Citation needed]. Van TV weet ik verder vrij weinig af, maar voor zover ik weet worden mensen aangetrokken door drie dingen: Gemak, Beschikbaarheid en Prijs. Prijs speelt daar een belangrijke rol in, anders zouden er niet zo gigantisch veel films worden gedownload; dat is immers meer werk om naar een mindere kwaliteit te gaan zitten kijken.

Los daarvan: het staat volledig los van een discussie over het al dan niet vervangen (of aanvullen) van HTML. Of een presentatievorm al dan niet aantrekkelijk is hoeft absoluut niet af te hangen van het medium en de technologie erachter, dat is een zaak voor de ontwerpers en usability-mensen.

En toen moest ik ook nog iets concluderen

Svens artikel springt een beetje van de hak op de tak, wat het lastig maakt om het te begrijpen. Hij begint over HTML, maar betrekt daar wel allerlei zaken bij die er soms maar zijdelings mee te maken hebben, of die in ieder geval geen enkel verband houden met het al dan niet laten vallen van HTML.

Niet dat al die zaken onbelangrijk zijn, maar ze zijn ondergeschikt aan een veel grotere, en lastiger op te lossen kwestie: het doeltreffend ordenen en presenteren van informatie is moeilijk. Goede markup is moeilijk. Goede CSS is moeilijk. Consistentie in die drie vlakken is moeilijk.

Niets daarvan wordt opgelost door HTML te vervangen. Een hoop problemen die Sven in HTML ziet, zijn allang opgelost, althans in theorie. Semantische opmaak is vandaag al mogelijk, en het stelt je in staat om met een minimum aan overbodige opmaak toch een document met CSS van een gewenste stijl te voorzien. Het wachten is tot iedereen dat ook daadwerkelijk doet, en daar zit hem het probleem: de aanbieders.

Zolang grote partijen, maar ook “simpele thuisgebruikers”, het medium op een “verkeerde” manier gebruiken — door gebrek aan kennis of gemakzucht — komt dat semantische web er nooit voor de volle honderd procent. Dat hoeft niet eens een probleem te zijn, zolang content maar op andere manieren te verkrijgen is, en ook dat is al mogelijk, en gebeurt op grote schaal middels allerlei API’s.

HTML kan blijven!

Is het dumpen van HTML de enige manier om tot een semantisch web te komen? werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• Vacature: webontikkelaar ASP/MySQL/CSS/XHTML in Delft
• Zo, eindelijk de nieuwe nieuwe lay eens een keer online…
• 1999 heeft gebeld en wil zijn tag soup HTML terug
• WordPress 2.7, Firefox 3.1 en de nieuwe DNZM-lay

Delicious (vroeger heette dat nog gewoon Del.icio.us) is een social bookmarking site. Je kunt links plempen, er tags aan hangen, en de links van andere mensen bekijken. Prachtig allemaal, maar intussen draait het ergens bij Yahoo!, en dat sociale gedeelte ervan heb ik nooit echt gebruikt.

Toen ik dus Scuttle tegenkwam was de keuze snel gemaakt. Of nou ja, nadat ik Scuttle even ergens had geïnstalleerd en ontdekte dat het voor mij alle functionaliteit van Delicious biedt. In ieder geval: al

Wat ook grappig is, trouwens, hoewel voor mij iets minder interessant, is dat Scuttle ook de API van Delicious redelijk nabootst. Een programma als Cocoalicious kan dus perfect van je nieuwe bookmarkstek gebruikmaken. Helemaal top.

Oh, en ik kan nu eindelijk tags met spaties erin gebruiken. Dat is iets dat Delicious nog steeds niet doet, en dat ga ik zeker niet missen.

Kortom: Scuttle is wat mij betreft een aanrader.

Operatie “Exit Walled Gardens”: Delicious.com werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• Operatie “Exit Walled Gardens”: Google Reader
• Repeat after me: dat hele Cloud Computing geneuzel heeft niets met betrouwbaarheid en onafhankelijkheid te maken.
• Waarom “walled gardens” slecht voor u zijn
• Wat hebben Twitter, Microsoft, WordPress en grids met elkaar te maken?

Het gros van de reacties is er eentje van de volgende drie:

• OMG OMG OMG Microsoft kan wel opdoeken OMG OMG OMG want alles dat Google aanraakt verandert in goud OMG OMG OMG where do I sign up, kortom, men gaat ervan uit dat Google een succesvol OS neerzet, dat als eerste een gigantische deuk in de Windows-hegemonie gaat slaan.

• OMG OMG OMG Wie denken die lui van Google dat ze zijn OMG OMG OMG (Linux|Windows|Mac) forevah, bitches OMG OMG OMG dit wordt niks, oftewel de mensen die zeker weten dat dit gaat floppen, omdat Google geen OS neer kan zetten, omdat Netbooks geen interessante markt zijn, of omdat niemand een deuk in de Windows-hegemonie kan slaan.

• Meh.

Ikzelf val ongeveer in het derde kamp. Nee, dit is geen exacte wetenschap, en er zijn meer dan drie mogelijke reacties, etc etc. Het gaat maar even om het idee.

Er zijn allerlei redenen aan te voeren waarom een Linux-kernel met een custom grafisch schilletje en een browser wel of niet kan werken. Ik denk dat de meeste van die redenen, zowel de voors als de tegens, wel kloppen. De groep die overstapt naar Chrome OS zal voornamelijk bestaan uit hard-core geeks en mensen die dit met een netbook meegeleverd gaan krijgen — met Asus en Acer als hardware-partners kun je daarop wachten, en dan heb je het wel gehad. De overgrote meerderheid blijft op Windows of MacOS X zitten, een minderheidje blijft met een “normale” Linux werken.

Even voor de goede orde: zowel Google’s Android als Palms WebOS zijn gebaseerd op Linux met een kek schilletje. Nieuw is het dus allerminst.

Veel interessanter vond ik de post van Ben Parr op Mashable:

Getting you to spend more time on the web is why Google based its OS on Chrome. You can expect that Microsoft and Apple will incorporate the best features of Chrome OS in their future iterations. That’s exactly what Google wants (and by the way, since Chrome OS is open-source, Google’s making it easy).

As long as you’re on the web, Google wins. So we need to stop framing the Google-Microsoft battle in the context of “Chrome OS vs. Windows,” because Google will not win a straight up battle. And guess what? That’s not Google’s goal. We need to frame it in the larger context of the Google Revenue Equation and how much time we spend on the web.

— The Google Revenue Equation, and Why Google’s Building Chrome OS

Voor wie de post zelf niet wil lezen (foei, ik link er verdorie niet voor niks naartoe!): het zal Google een rotzorg hoe en waarmee je browst, als je maar browst. En zo af en toe op een advertentie klikt, waarvan een groot deel van Google is. De meeste mensen weten immers helegaar niet wat een browser is, en het zal ze een kouwe rotzorg zijn ook. Datzelfde geldt grofweg voor besturingssystemen.

Het draait dus gewoon om het geld. Who would’ve thought.

Ik vind dit tot nu toe een van de meest plausibele verklaringen over dat hele Chrome OS. Wat mij betreft kunnen we over naar de orde van de dag, op zijn minst tot Google dat spul ook daadwerkelijk klaar heeft.

De beste post over Google Chrome OS tot nu toe, zo ongeveer werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• Repeat after me: dat hele Cloud Computing geneuzel heeft niets met betrouwbaarheid en onafhankelijkheid te maken.
• De piknijd van Microsoft
• Fijne Microsoft-advertorial op Nu.nl
• De Microhoo!-soap blijft bezig

Het idee is dat als de gegevens van de overheid open zijn, ontwikkelaars en andere partijen die kunnen hergebruiken en dingen kunnen maken waar andere mensen behoefte aan hebben. – Alper.nl

Op zijn blog licht hij e.e.a. toe, compleet met voorbeelden. Verplicht leesvoer wat mij betreft.

Overheidsgegevens opener en vriendelijker werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• Is het dumpen van HTML de enige manier om tot een semantisch web te komen?
• 1999 heeft gebeld en wil zijn tag soup HTML terug
• Linkdump: De echte analoge kloof
• De beste post over Google Chrome OS tot nu toe, zo ongeveer

1. “Whoa, fuck!”
2. “Nee, man, serieus, meent-ie dit?”
3. “Whoa, fuck!”

Ongeveer in die volgorde.

Het punt is: Frank is verre van dom, en verre van onbekend met het fenomeen internet. Als je daadwerkelijk Franks post leest — iets waar ik vanmorgen pas aan toekwam — komt daar een iets ander verhaal uit: hij loopt niet zozeer jodelend weg met het idee dat werknemers email verruilen voor berichten op Facebook, hij bespreekt een soort Twitter-voor-intern-gebruik.

Kleine update: Ernst-Jan heeft intussen in het artikel intussen verduidelijkt dat Franks goedkeuring vooral over Yammer ging.

Oh, zeg dat dan meteen. Probleem opgelost, derhalve?

Nou, nee. Frank mag dan verkeerd aangehaald zijn, feit blijft wel dat steeds meer informatie inderdaad “het bedrijf” verlaat, en dan niet op de — door Ernst-Jan al genoemde — slingerende USB-stick, maar willens en wetens en tot op zekere hoogte met de zegen van de baas.

Even terzijde: “slingerende USB-stick” zou wat mij betreft reden zijn voor direct en oneervol ontslag, zo niet standrechtelijke executie — gewoon om heel erg duidelijk te maken dat je zo, godnogantoe, niet met gevoelige data omgaat.

Information wants to be free, man!

Tot op zekere hoogte is het natuurlijk prima dat informatie het bedrijf verlaat, en ik zou nog iets verder dan Ernst-Jan willen gaan: dat hele sharing is caring gedoe is niet beperkt zich tot Web 2.0. Het is een verandering van insteek die je op steeds meer plaatsen terugziet: het gaat niet meer alleen om het — al dan niet tastbare — product dat je aanbiedt, het gaat om de value die je toevoegt.

Verlichte zielen zien teruglopende CD-verkoop niet als probleem, ze richting zich op concerten en andere zaken die meer dan beleving — concerten, bijvoorbeeld — te maken hebben dan met een stukje plastic met een boekje erbij.
Ze beschouwen het gratis ende voor niets ter beschikking stellen van een schat aan informatie, op blogs en dergelijke, niet als zeker teken van vroeg inzettende seniliteit, maar als methode om de wereld te laten zien dat je het meent, dat je expertise in huis hebt, dat je iets toe te voegen hebt.

Mensen als Seth Godin, Steve Pavlina en, welja, Maxime Verhagen — en met hen nog een heel legertje — vertellen juist aan de buitenwereld waar ze mee bezig zijn en wat ze bezig houdt, en dat is een prima manier om jezelf tot brand te bombarderen. Prachtige doe-het-zelf marketing, en het voelt nog lekker authentiek aan, ook.

Sharing is niet alleen caring, het is ook een manier om te laten zien wie je bent en waar je voor staat, wat je in andere mensen verwacht en wat van mensen van jou mogen verwachten. Ook zakelijk.

Goed, dat is dus niet het probleem, dat levert bij mij geen “whoa fuck” op. Wat dan wel?

Het idee dat dat sharing-gebeuren op de Facebooks en Twitters zou moeten gebeuren, of liever gezegd, dat een bedrijf zoiets als gezond beschouwt. Dat is het namelijk absoluut niet, om één hele simpele reden: betrouwbaarheid.

Is mijn meuk bij X veilig ondergebracht?

Dat lijkt een vrij duidelijke en voor de hand liggende vraag, maar het lijkt erop dat-ie toch te weinig gesteld wordt. Een flinke kluit mensen vertrouwt er vrij blindelings op dat de teksten, foto’s, video’s en dergelijke goed door de gebruikte dienst worden opgeslagen en gebackupt. Niet alleen dat, maar ze lijken er ook vrij zeker van te zijn dat de aanbieder alle rekeningen kan betalen, en ondanks een gebrek aan elke vorm van business plan — ja, Twitter, ik kijk naar jou — toch op magische wijze blijft bestaan.

Heus?

Nee, echt, heus?

Laten we eens kijken naar wat er de afgelopen tijd zoal is gebeurd, qua magisch blijven bestaan en nooit fouten maken:

• Na 6 jaar blijkbaar zonder backup gewerkt te hebben, ging Journalspace begin dit jaar spectaculair ten onder. Jaren van content in één keer weg. Intussen lijkt de site een doorstart te hebben gemaakt — dit maal op WordPress MU + BuddyPress, en hopelijk met backup.
• Nog geen maand later blijkt ook Ma.gnolia geen goeie backup te hebben.
• De laatste tijd lijkt het goed te gaan, maar 2008 was het jaar van de Twitter Fail Whale. Twitter lag zo vaak plat dat het eigenlijk niet grappig meer was. Tenminste…
• Wat zegt u? Dit soort fuckups komt alleen bij kleine startups voor? Nee hoor: een weekje geleden pleurde er bij Facebook iets om, waardoor foto’s urenlang weg waren. Gelukkig had Facebook wel een werkende backup.
• Zelfs de Almachtige Google is niet immuun voor een beetje faal op zijn tijd. Eind vorige maand knalde Gmail er door een menselijk foutje voor een paar uur uit, en dat was niet de eerste keer.

En dat zijn er dan een paar die ik zo even kan opnoemen. Wat vooral interessant is om op te merken: de kleinere startups overleven een dergelijke fuckup niet altijd.

Jason Scott verwoordt het allemaal heel fraai in Fuck The Cloud:

If you want to take advantage of the froth [...] then do so, but recognize that these are not Services. These are not dependable enterprises. These are parties. And parties are fun and parties and cool and you meet neat people at parties but parties are not a home.

Maar de “is het betrouwbaar”-vraag gaat verder dan backups en kundige mensen.

Oh ja, en dat walled-garden-geneuzel…

Ik heb het daar al eerder over gehad, dus dat ga ik hier niet allemaal herhalen; het enige dat er sinds die post veranderd is, is dat er een enorme rel is geweest over de gebruikersvoorwaarden van Facebook, toen Facebook besloot dat alles wat je daar neerzette, voor altijd en eeuwig eigendom van Facebook zou worden, amen. Dat werd vrij rap weer teruggedraaid, maar het feit dat het ook maar een minuutje in de voorwaarden heeft gestaan zegt eigenlijk al genoeg. Blij Hoofd Zuckerberg kan honderd keer zeggen dat Facebook heus geen evil trekjes heeft, maar daden spreken nog net iets harder dan woorden.

Goed, dus je stalt je shit ergens op een site die niet door domme pech incompetentie in vlammen opgaat, maar je geeft nog steeds het nodige op. Mocht je er, om wat voor reden, vanaf willen, dan ben je proper fucked, want een export-procedure is nog steeds een vies woord, alle claims over openheid en uitwisselen en regenbogen en eenhoons ten spijt.

Frank geeft dat trouwens zelf ook aan in de post waar het allemaal mee begon. Ik weet niet in hoeverre hij het zelf doorheeft, maar die ene opmerking onderstreept precies waar ik me zo druk over maak:

We zagen Yammer als een klein experiment waarvan we vanzelf wel zouden zien of aanslaat of niet. [...] Maar op dit moment zijn er 34 van de 40 medewerkers actief op Yammer. Overstappen zou weer een hele operatie zijn en we zijn de conversaties dan ook kwijt.

Holy fucking hell, nee, dat is een geweldig idee: laat ik me bedrijfsmatig vastleggen op een stuk software waar ik geen enkele invloed over heb. “Nu is het zonde als de kennis die in de email zit alleen tussen de collega’s blijft,” dat was één van de redenen om dit te proberen. Mocht Yammer morgen de rotmoord steken of besluiten om een ziljoen dollar voor hun diensten te gaan vragen, blijft die kennis niet tussen collega’s, dan is die kennis gewoon weg, pleite, foetsie, jammer maar helaas.

Toch een beetje whoa, fuck, dus.

Ben ik een zeikerd? Zeker. Zit ik Frank hier voor de lol te dissen? Absoluut niet; zoals ik aan het begin van dit veel te lange lulverhaal al schreef komt Frank allesbehalve dom over, ik respecteer de man om wat hij allemaal heeft gedaan en geschreven. Ik vind alleen dit geen slimme zet. Het idee is prima, het feit dat hij een belangrijk stuk van zijn interne communicatie ophangt aan een willekeurig bedrijfje is dat in mijn ogen niet.

Ja, maar… wat dán?

Ook dat heb ik al vaker geroepen: doe het zelf. Niet als in “schrijf elk stuk software zelf”, dat is het wiel opnieuw uitvinden en dus zonde van de tijd. Maar zorg ervoor dat je zelf de volledige controle houdt. Zet ergens een servertje neer en gooi daar Laconica of Repeat after me: dat hele Cloud Computing geneuzel heeft niets met betrouwbaarheid en onafhankelijkheid te maken. werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• Gaat Google Buzz de wereld overnemen?
• Waarom “walled gardens” slecht voor u zijn
• Het enige dat Facebook nu nog hoeft te doen is de naam naar “Big Brother” veranderen
• When Twitter is down…

De reden, kort samengevat: Comm had 5000 vriendjes op Facebook; dat is toevallig het maximumaantal vriendjes dat je kunt hebben, dus nieuwe aanvragen kon hij niet goedkeuren. Prima, dan maak je een fan page of iets dergelijks, en dan stuur je de mensen daar naartoe. Dat was ook precies wat Joel deed. Hij werd vervolgens geblokkeerd omdat hij teveel en te snel berichten stuurde.

In Scobles geval was er tenminste nog iets aan de hand: die probeerde een scriptje van Plaxo uit, en scripts zijn verboten. Comm verrichte handwerk als workaround voor een nogal willekeurige en onzinnige limiet in Facebook, en nam de moeite om voor iedereen een apart berichtje te typen.

Goed, het kan best zijn dat Comm door een geautomatiseerd stukje spampreventie te grazen is genomen, maar dat maakt het hele verhaal niet minder vervelend; een beetje controle op de scriptjes is geen overbodige luxe, want Scoble en Comm zijn absoluut geen unieke gevallen. Ze zijn toevallig erg zichtbaar omdat veel mensen ze volgen, en ironisch genoeg zijn het behoorlijke promotors van Facebook en dergelijke.

Hoewel Comms account intussen weer is geactiveerd, heeft hij wel de waarschuwing gekregen dat hij vooral niet te snel of te veel berichten moet sturen, en dat een volgende blokkade onherroepelijk is.

Nog los van het feit dat een enthousiaste, evangeliserende gebruiker blokkeren omdat hij op een normale manier gebruik maakt van je site — nota bene om een onzinnige beperking op je site te ondervangen — nogal stom is, maakt het ook weer pijnlijk duidelijk waarom het een bijzonder slecht idee is om jezelf afhankelijk te maken van een dergelijke partij. En ondanks dat Facebook stappen heeft genomen om het op allerlei sites mogelijk te maken om met je Facebook-gegevens in te loggen, is het nog steeds niet mogelijk om je (eigen) gegevens te exporteren.

Initiatieven als DataPortability zullen, vrees ik, ook nooit echt voet aan de grond krijgen bij de Facebooks van deze wereld; die hebben er immers alle belang bij om de oogballen op hun netwerk — en dus advertenties — te houden. De enige reden die ze zouden kunnen hebben om je toe te staan je gegevens te exporteren, is een financiële: dat ik eerder al maakte:

Het grootste bezwaar vind ik dat je niet meer de baas over je eigen gegevens bent. Je foto’s in één keer van Flickr exporteren? Kan niet. Al je tweets naar één plek trekken? Vergeet het maar. Je social gebeuren op Facebook naar een ander netwerk verplaatsen? No can do. Tenzij je bereid bent je data op te geven, of een ontiegelijke bult handwerk in een verhuizing te steken, leg je jezelf vrijwillig aan de ketting bij één partij.

Ja, ik heb een account op Facebook (en op Hyves, Netlog en Virb), maar ik zal daar nooit een uitgebreide online presence van maken. Ik wil zeker weten dat mijn naam daar niet door de één of andere eikel gekaapt wordt, maar ik ga zeker geen uitgebreide moeite doen om mijn gegevens onder te brengen bij een partij die vervolgens die gegevens zonder al te veel waarschuwing kan verwijderen, en die mij niet in staat stelt om die gegevens eenvoudig te exporteren.

Wat mij betreft draait Web 3.0 om het teruggeven van de controle aan de gebruikers.

Waarom “walled gardens” slecht voor u zijn werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• Repeat after me: dat hele Cloud Computing geneuzel heeft niets met betrouwbaarheid en onafhankelijkheid te maken.
• Het enige dat Facebook nu nog hoeft te doen is de naam naar “Big Brother” veranderen
• Gaat Google Buzz de wereld overnemen?
• Is Twitter gevaarlijk of “mostly harmless”?

• De Palm Pre lijkt een heel interessant beest te gaan worden. In eerste instantie zijn alle apps widgets (HTML/CSS/JS) maar dan wel lokaal, in tegenstelling tot de begindagen van de iPhone. Later is een “echte” SDK niet uit te sluiten, het ding draait Linux onder de motorkap en daar moet genoeg mee kunnen.

• Over iPhone gesproken: ik heb er (beperkt) mee kunnen spelen, en eerlijk gezegd ben ik niet onverdeeld enthousiast. Komt ongetwijfeld later nog wel een post over, waar ik die Pre dan ook in meeneem.

• Via Fontanel pikte ik een beknopt doch interessant (en niet te vergeten gelikt) leeswerkje tegen dat niet op uw desktop mag ontbreken. Gaat over typografie in ontwerp, en ook grids komen ter sprake.

• Ik kreeg van een vriendin voor mijn verjaardag (dank u) een coupon van Moo.com, alwaar je allerlei tastbare spullen (kaartjes, stickers) van je foto’s kunt laten maken. Ik heb er wat van mijn Flickr-foto’s voor gebruikt, en volgens het “uw spul is verzonden”-mailtje dat ik vanmiddag kreeg kan ik binnen een week vertellen hoe het is geworden. Arigato, Yora!

• Google is bezig met een Quick Search Box voor de Mac. Heeft vagelijk iets weg van QuickSilver, maar dan anders (en op dit moment minder interessant voor mij). Spotlight-integratie is wel sweet, dus dit wordt waarschijnlijk binnen no-time de vervanger voor het ding in Google Desktop.

• Goddank voor Den Luien Mensch is er ook vegetarische pizza, natuurlijk.

Dat gezegd hebbende ga ik even een trein opzoeken. Prettig weekend!

Vrijdagavondverzamelpost werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• De beste post over Google Chrome OS tot nu toe, zo ongeveer
• Repeat after me: dat hele Cloud Computing geneuzel heeft niets met betrouwbaarheid en onafhankelijkheid te maken.
• De Moo mini-cards zijn binnen!
• De piknijd van Microsoft

Waar ik iets meer problemen mee heb, en waar ook geen excuus voor is, is hun widget; een klein dingetje dat je op je Google startpagina kan zetten en waarin je kunt zien hoeveel minuten en berichtjes je die maand nog overhebt… handig!

Dat wil zeggen… als het werkt. En dat doet het vaak genoeg niet. Het duurt nogal even voor het ding doorheeft dat mijn nieuwe maand is ingegaan, en ik krijg dus ook regelmatig die onzin zoals hiernaast te zien.

Anno 2008 vind ik het voor een giga-bedrijf als T-Mobile eigenlijk niet te verkopen dat ze zo’n klein stukje database-query niet betrouwbaar kunnen laten verschijnen. Dat het niet helemaal real-time is, is nog tot daar aan toe — hoewel, waarom eigenlijk niet? — maar dat het zeer regelmatig gewoon ronduit niet werkt vind ik foute boel.

Goed, lang niet zo erg als als die hongerige kindertjes in Afrika, om maar wat te noemen, maar het irriteert me wel.

_Het reageerding staat open voor uw grootste irritaties…_

Enorm leuk, al die widgets, maar het moet wel werken werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• Nou ja, dan roep ik ook maar eens wat over de iPad
• Repeat after me: dat hele Cloud Computing geneuzel heeft niets met betrouwbaarheid en onafhankelijkheid te maken.
• En toen was ik dus veranderd van telco…
• Orange kiest voor de gemakkelijke weg

Waar het op neerkomt: met de overname streeft Microsoft een onhaalbaar doel na: het onttronen van Google als absolute marktleider in zoek-land. Dat lukt ze niet, en de energie en centen die ze eraan verspillen zouden ze beter kunnen gebruiken voor andere dingen.

Hetzelfde geldt volgens Tim ook voor Yahoo!: outsource die zoektoestand aan Google, en richt je op de dingen waar Yahoo! het wel goed doet, content bijvoorbeeld.

O’Reilly gaat dan verder met zijn idee over Web 2.0. Hij ziet dat vooral als het small pieces loosely joined-model, zoals je dat ook in Unix terugziet: kleine onderdeeltjes (programma’s of stukjes informatie) die afzonderlijk één taak zo goed mogelijk doen, en gemakkelijk samen kunnen werken. De gebruiker kan zelf een samenstelling maken. Uiteindelijk kun je met al die losse stukjes allerlei ingewikkelde en moeilijke dingen doen, zonder dat je voor elke taak een groot en uitgebreid stuk software nodig hebt. Het is een soort puzzel waarbij je zelf de stukjes mag uitkiezen, en je zelf mag verzinnen hoe je al die stukjes in elkaar laat passen.

De kans dat ze in Redmond nu zoiets hebben van “oh, goh, goed idee, laten we dat maar gaan doen!” is natuurlijk nul. Microsoft is meer aanhanger van de “grote pakketten voor zoveel mogelijk taken”-strategie, waarbij al die grote pakketten bij voorkeur van Microsoft zijn. Vandaar dat ze achter Yahoo! aan zitten: wat hun betreft is Google gewoon de zoveelste tegenstander, die overgenomen of om zeep geholpen moet worden.

Ik betwijfel — niet als enige — of ze dat gaat lukken. We leven niet meer in de jaren tachtig en negentig, toen ze hun monopolie opbouwden; tegenwoordig is er een redelijk volwassen internet en heeft Microsoft concurrentie uit hoeken die destijds niet eens bestonden. Zolang ze dat niet doorhebben en daarnaar gaan handelen, zullen ze tegen windmolens blijven vechten.

En dat is een strijd die je altijd verliest.

De piknijd van Microsoft werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• Woensdagmiddagverzamelpost
• De beste post over Google Chrome OS tot nu toe, zo ongeveer
• De Microhoo!-soap blijft bezig
• Yahoo! wordt definitief NIET opgevroten door Microsoft

Met een beetje goede wil wordt-ie door een geschikt persoon gelezen en kunnen we met zijn allen jaren later terugblikken op het succesverhaal waarin DNZM een bescheiden rol heeft gespeeld. Of zoiets. In ieder geval:

Wij hebben het druk!

Zite is een klein bedrijf met een focus op de reclame- en grafische markt. Wij leveren technische diensten aan deze creatieve sector. Onze andere klanten variëren van UPC, Chivasso, Robeco en Citrix tot aan de bakker op de hoek (Maison Kelder). Wil jij aan dit soort projecten werken waarin je in ieder project de uitdaging kunt vinden?

Kun je overweg met ASP, MySQL en ben jij in staat om met een perfect validerende XHTML code een WOW!-reactie bij onze klanten op te roepen? Dan zoeken wij jou!

Als webontwikkelaar werk je samen of zelfstandig aan kleine tot grote opdrachten in een klein team in ons kantoor in Delft.

Je zult online applicaties en sites opzetten met of zonder beheersysteem waarbij je soms het intern ontwikkelde beheersysteem Inzite CMS als basis gebruikt, maar bij complexere opdrachten met niets begint.

Wij zoeken jou als je contacten kunt onderhouden met de klant en met oplossingen, gericht op de klant, op de proppen komen.

Je zult gebruik maken van Adobe CS3, en programmeren in ASP, MySQL en CSS/XHTML.

Vereisten:

• Een HBO werk- en denkniveau;
• Minimaal een jaar aantoonbare ervaring met ASP, MySQL, HTML, Javascript en CSS Stylesheets.

Pre’s:

• Ervaring met het maken van functionele ontwerpen, web- en grafische userinterfaces;
• Kennis van usability;
• Ervaring met Photoshop/Fireworks en Flash;
• Gevoel voor detail, vormgeving en presentatie;
• Een klantgerichte instelling.

Wat hebben wij jou te bieden? Je komt te werken in een creatieve, informele omgeving in hartje Delft met uitzicht op de Trekvliet en natuurlijk leuke collega’s waarmee op mooie dagen een lunchterrasje gepakt wordt op de Beestenmarkt. Lijkt dit je wat? Loop dan eens langs, bel ons of stuur een e-mail en informeer naar de mogelijkheden. Ook parttime werknemers zijn welkom!

Voel jij je aangesproken? Stuur je C.V. en motivatie naar werkenbij@zite.nl Bellen kan natuurlijk ook! Bel 015 256 4938 en vraag naar Menno van Duijn

Acquisitie naar aanleiding van deze vacature wordt niet op prijs gesteld.

Vacature: webontikkelaar ASP/MySQL/CSS/XHTML in Delft werd gepubliceerd op Doe Niet Zo Moeilijk! - Weblog van een relaxed persoon

Mogelijk gerelateerd:

• Is het dumpen van HTML de enige manier om tot een semantisch web te komen?
• Zo, eindelijk de nieuwe nieuwe lay eens een keer online…
• 1999 heeft gebeld en wil zijn tag soup HTML terug
• WordPress 2.7, Firefox 3.1 en de nieuwe DNZM-lay