Op Barcamp Antwerpen gaf Tijs Vrolix een presentatie getiteld “10 reasons why now is the perfect time to get serious about the mobile web”. Je kan de slides van deze presentatie bekijken op SlideShare). Het was een erg interessante presentatie, die me tot nieuwe gedachten heeft geleid omtrent een strategie voor het mobiele web.
Eerst even een schets van mobile development vandaag.
Het probleem met het mobiele web is dat er duizend en één verschillende devices en browsers zijn. Als je wil dat je mobiele website op elk platform werkt, ga je ervoor moeten zorgen dat je alle devices kan testen.
Je gaat een heleboel verschillende types GSM’s aankopen, sukkelen met mobiele abonnementen (of erger: de SIM kaart telkens verwisselen). Je gaat helemaal gefrustreerd worden door de browser inconsistenties, en nog veel meer door het onkunnen van de oudere apparaten.
Er is het Symbian platform, er is de iPhone, er zijn Blackberries en er is Android. Dan heb je nog de high end telefoons van Nokia, en de tig verschillende versies van Windows Mobile. En dan hebben we het nog maar enkel over smartphones gehad. Als we even tellen heb je dan al minstens 6 emulators en fysieke devices nodig.
Dan krijg je een testing setup die er ongeveer zo uit ziet:
(En dat was dan nog voor een project dat slechts op 4 platformen moest werken)
Het goede nieuws: er is beterschap op komst.
De nieuwere toestellen evolueren bijna eenduidig in dezelfde richting: een device dat het internet toont zoals het bedoeld was.
Deze evolutie is vooral te danken aan het gebruik van de open source browser Webkit. Deze browser wordt omarmd door zowel Apple, Google, RIM (Blackberry) en Palm.
Een andere grote factor in die eenduidigheid is schermresolutie en form factor: bijna alle toestellen zijn, met de iPhone als grote voortrekker, een stuk glas van 3,5”, met een resolutie van 320px op 480px of hoger.
Kijk even naar deze grafiek, uit een onderzoek van Morgan Stanley:
Klik voor een grotere versie.
De iPhone en Android tesamen zijn verantwoordelijk voor bijna drie kwart van de pageviews; terwijl ze slechts 13% van de markt bezetten.
Internet op mobiele telefoons bestaat al een tijdje, maar eigenlijk gebruikte bijna niemand het. Heel kort door de bocht, het mobiele internet 3 jaar geleden: zakenmannen die e-mails binnenhalen op hun dure Blackberry of HTC.
Nu zijn er betaalbare smartphones waarop het internet bruikbaar geworden is, en mensen internetten er ook effectief op. Je neefje loopt rond met een Android telefoon en zijn zus heeft een iPhone.
Ook een factor: we hebben een goed netwerk in België: er is nagenoeg overal EDGE en 3G coverage. De netwerken worden elk jaar beter. Providers pushen het mobiele internet.
Ik zei in het begin van dit artikel: “Het probleem met het mobiele web is dat er duizend en één verschillende devices en browsers zijn.”.
Dit probleem is zichzelf aan het oplossen.
Er zijn voor mij namelijk nog maar 2 soorten smartphones over:
Toestellen in staat om het internet weer te geven zoals je dat kan op een desktop
Toestellen niet in staat om het internet weer te geven zoals je dat kan op een desktop
En mobile development wordt:
De eerste categorie toestellen krijgt de normale site
De tweede categorie toestellen krijgt de normale site in tekstvorm: enkel HTML, geen CSS, geen Javascript
Deze scheiding maken noem ik de forward thinking strategie voor het mobiele web. In deze strategie ga ik er van uit dat devices evolueren naar wat de iPhone nu is, en dat we binnenkort allemaal een smartphone hebben. Ik ga er ook van uit dat diegene die geen smartphone hebben, ook niet geïnteresseerd zijn in mobiel internetten.
Weg dus met dertien versies van een mobiele website te bouwen: bouw één versie, volgens de webstandaarden, en serveer een tekst-only versie aan de toestellen die minder kunnen.
(Ik ben er eigenlijk zelfs van overtuigd dat een HTML only een betere gebruikservaring zorgt op, zeg maar, een Nokia N95, of een HTC Diamond)
Net zoals in accessibility de praktijk om twee versies van een site te maken (één gewone, en één “toegankelijke”) achterhaald is geworden door betere standaarden en betere webbouwers - zo zal het idee om twee versies van een site te maken (één gewone, en één mobiele) nutteloos gemaakt worden door betere browsers, grotere schermen op mobieltjes, en beter onderlegde webbouwers.
Dit klopt: de praktijk om twee versies van een website te maken is achterhaald. We volgen de webstandaarden, en de sites die we maken werken de facto op de mobiele toestellen.
Maar: mobiel kan nog zoveel meer zijn dan een normale website.
Met de evolutie in de mobiele wereld in het achterhoofd, is het ondertussen realistisch geworden om een mobiele website te maken die effectief meerwaarde biedt.
Een mobiele versie van je site zal makkelijker lezen:
Je kan de focus leggen die mobiel relevanter zijn. Op de homepage van de mobiele Netlash website staat bijvoorbeeld een rechtstreekse link naar Google Maps, voor mensen die ons kantoor zoeken. En er staat een link waarmee je rechtstreeks kunt bellen, zonder het nummer in te moeten tikken.
Ik geloof, net als Tijs, dat 2010 effectief het jaar van het mobiele web wordt.
In onze webapplicaties - zeker diegene met eencommunity - worden er heel wat mails verzonden, om de mails herkenbaar te maken zijn deze opgemaakt met behulp van HTML en CSS.
Enkele mailclients (zoals bijvoorbeeld GMail) strippen deze CSS uit de HTML, hierdoor krijg je dus minder leesbare mails, de oplossing hiervoor is om de CSS voor ieder element in het style-attrribute te plaatsen. Hier zijn wel een aantal nadelen aan verbonden.
Onderhoudbaarheid, wat als iedere link een andere kleur moet krijgen?
Veel werk voor de designer, elk element moet voorzien worden van specifiek styling.
Wat als de inhoud niet vaststaat, maar door de gebruiker via het CMS ingegeven is?
Wel, nu is er een handige PHP-class die de CSS-styling gaat omzetten naar inline-styling.
De meeste mensen en bedrijven die websites bouwen zijn er een beetje ingerold - vanuit een ander beroep of een andere expertise. (Ikzelf ben, in een ver verleden, afgestudeerd als boekhouder...) Normaal eigenlijk, want in de jaren '90 bestonden er geen opleidingen tot webbouwer.
De twee belangrijkste instromen kwamen vanuit twee tegenovergestelde richtingen: langs de ene kant de designers, die ervaring hadden in vormgeven voor drukwerk of voor andere digitale media; langs de andere kant de developers, die ervaring hadden in het programmeren.
Die erfenis slepen veel webbureau's nog altijd mee. Ofwel hebben ze een zware technische insteek (en huren ze dan free-lance designers in), ofwel vertrekken ze vanuit de vormgeving (en gebruiken standaard technologie om dat te laten werken).
Ik ben er van overtuigd dat een website bouwen een geïntegreerd proces is, waar verschillende expertises samen moeten werken naar een goed eindresultaat. (Over die webdesign profielen heb ik het vroeger al gehad.)
Een goede website is een samenspel tussen technologie, design, usability en marketing. Die vier factoren zijn even belangrijk en moeten alle vier evenveel gewicht krijgen. En elk van die vier vraagt een eigen specialisatie. (Die vaak tegengesteld is - zoals het bon mot gaat: designers zijn van Venus, developers zijn van Mars.)
Het is juist uit de discussie tussen die vier, soms zelfs de ruzie, dat er iets moois komt.
Dit is het model waarbinnen we bij Netlash werken:
Centraal in elk project staat onze klant. Meestal werken we daar samen met de marketing manager, of communicatieverantwoordelijke. (In KMO's, waar we ook heel veel voor werken, is dat vaak de zaakvoerder zelf.)
We vertrekken altijd van de bestaande marketingstrategie van onze klant. Het is onze klant (of zijn marketing manager) die het beste het bedrijf, de doelstellingen, de doelgroepen en de strategie van het bedrijf kent.
Daarnaast zijn er drie soorten Netlash-medewerkers betrokken bij het project, elk met hun eigen expertise: een webdeveloper, een webdesigner en een informatie-architect. (Zie: Wie is wie bij Netlash.)
De developer zorgt voor de juiste technische uitvoering; de designer voor een vormgeving die de doelstellingen van de site ondersteunt. Ondertussen zet de informatie-architect de krijtlijnen van het concept uit, én bewaakt hij tijdens het hele proces de bruikbaarheid (hij is als het ware de 'verdediger' van de eindgebruikers van de site).
Dit wordt gecoördineerd door een project manager: die verzorgt de communicatie tussen het team en de klant, en is verantwoordelijk voor de bewaking van scope, timing en budget.
Elk van die mensen is cross-disciplinair. Een moeilijk woord, om te zeggen dat ze ook over het muurtje durven kijken. Iedereen moet minstens vlekkeloos html/css kunnen hanteren - of ze nu developer, designer of IA zijn. Naast hun eigen expertise moeten ze ook feeling hebben voor de andere aspecten: ik verwacht van een programmeur dat hij mee nadenkt over de bruikbaarheid, en dat de informatie-architect een bepaald gevoel voor esthetiek heeft.
Het is juist door die verschillende experten bij elkaar te zetten en ze nauw met elkaar te laten communiceren (in een aangename omgeving) dat er een evenwichtig en effectief eindresultaat komt.
Zo'n geïntegreerd webbureau zal volgens mij altijd voorsprong hebben op losse samenwerkingsverbanden (op voorwaarde dat het klein genoeg blijft om zijn flexibiliteit, snelheid en innovatie te bewaren).
Op 16 en 17 februari ging in Parijs de eerste internationale Symfony conferentie, Symfony Live 2010, door. Symfony is een web PHP framework dat als doel heeft om complexe webapplicaties sneller te bouwen en het onderhoud van deze applicaties beter en gemakkelijker te maken.
Bij Netlash maken we geen gebruik van symfony, maar ik heb de laatste maanden wel een sterke persoonlijke interesse voor dit framework. En het is heel interessant om de evoluties en denkpatronen te volgen in andere communities.
De conferentie was goed georganiseerd en ging door in een mooie conferentiezaal in het Cité Universitaire. Het was een groot succes met 350 aanwezigen. Er waren heel wat interessante presentaties over Doctrine, het gebruik van Zend Framework componenten en het gebruik van Git als Version Control System. Ik heb wel een beetje de technische voorbeelden en 'best practices' gemist over Symfony zelf. De presentaties die hierover gingen misten een beetje diepgang.
Het hoogtepunt van deze tweedaagse was de preview release van Symfony 2. Het meest opmerkelijke hierbij is het (nog meer) opzij schuiven van eigen ontwikkelde stukken code en het gebruik maken van onderdelen uit het Zend Framework (Zend_Log en Zend_Cache). Hiermee volgt Symfony verder z'n visie "Don't reinvent the wheel". Deze presentatie van Fabien Potencier kan je bekijken op Slideshare:
Al bij al een heel gezellige conferentie die heel duidelijk de mooie community rond Symfony in de verf zette. Alle presentaties en de reacties van de aanwezigen kan je nalezen op Joind.in.
Voor het versturen van e-mails in een privé-project had ik een functie nodig die een HTML-mail kon omvormen naar een plain text mail. Meestal wordt dit gedaan door simpelweg de PHP functie strip_tags op de HTML-mail los te laten. Dit geeft echter problemen als je bijvoorbeeld -style- tags in je code staan hebt. De strip_tags functie zal de begin- en eindtags wel 'strippen' maar zal alles ertussen laten staan. En een plain text mail met p { font-size: 12px; } en dergelijke in is nu niet echt proper. Daarom heb ik dus de functie getPlainText gemaakt.
// replace break rules with a linefeed and make sure a paragraph also ends with a new line Hier gaan we dus -br- tags vervangen door enters. En aangezien paragrafen ook moeten gescheiden worden van elkaar en meerdere paragrafen in de html op 1 regel kunnen staan zorgen we ervoor dat deze al in html vorm op verschillende lijnen staan.
// remove tabs De tabs die door indentatie in de html-code staan mogen in de plain-text versie ook verwijderd worden.
// remove the head- and style-tags and all their contents De reden waarom deze functie geschreven is. De strip_tags functie van php zal enkel de start- en eind-tags van deze elementen verwijderen, waardoor alles dat tussen deze tags staat behouden blijft. Door een preg_replace te doen van deze html-tags en hun inhoud is dit probleem opgelost.
// replace links with the inner html of the link with the url between () Indien je de parameter $includeAHrefs niet overschrijft met de waarde false zal deze regel de links in de html vervangen door de html die binnen de link staat met daarachter de url tussen haakjes. Dit zorgt ervoor dat links in je html-document niet verloren gaan, wat wel het geval is bij strip_tags.
// replace images with their alternative content Hetzelfde voor de afbeeldingen. Deze regels zal de afbeelding vervangen door de alt parameter van het img-element.
// strip tags En nu pas laten we de strip tags functie los op de tekst.
// replace 'line feed' characters with the 'carriage return/line feed' character pair We vervangen de line feeds of "\n" karakters door het carriage return line feed paar zodat volgende regel kan uitgevoerd worden.
// replace double, triple, ... line feeds to one new line Deze regel zorgt ervoor dat de overbodige witregels in de tekst vervangen worden door 1 witregel.
// decode html entities Deze regel zal html entiteiten zoals é vervangen door hun plain text waarden (in dit geval dus é) door middel van de Spoon functie htmlentitiesDecode. Voor meer info over Spoon kan je terecht op spoon-library.be. Als je niet met Spoon werkt kan je hier natuurlijk ook altijd de standaard php functie html_entity_decode gebruiken.
Een voorbeeld:
Als voorbeeld wou ik de Netlash nieuwsbrief van 21 januari even door deze functie halen.
We hebben hier bij Netlash wel al een aantal webprojecten afgewerkt. Door de jaren heen is er een bepaalde systematiek uitgekristaliseerd - een manier van werken, een stappenplan, waarvan we ondertussen weten dat dit de goede manier is om een website tot stand te laten komen.
In dit artikel wil ik deze methodiek met jullie delen, en jullie feedback daarop vragen (want alles kan altijd beter, niet?).
De stappen die we nemen zijn er met een goede reden. Zie het bouwen van een website als het beklimmen van een berg. Ja, je kan zonder zekeringen helemaal naar boven klimmen. Maar toch zal je beter op regelmatige intervallen een haak in de bergwand slaan om je musketon vast te maken. Als je niet gevallen bent, bij het naar boven klimmen, heb je inderdaad een hele hoop extra en overbodig werk gehad met die musketons. Maar als je wel mistrapt en valt, zorgen de borgen ervoor dat je maar een kleine afstand opnieuw moet omhoogklimmen - en niet de dodelijke val over de volledige diepte meemaakt.
Vandaar dit proces. Een aantal van de stappen lijken overbodig, maar ze zorgen wel voor een constante kwaliteitsgarantie over projecten heen.
0. Voorbereiding
Na de eerste prospectiegesprekken wordt de prospect meestal onze klant. We starten met een beetje administratie: zorgen dat de afspraken rond facturatie goed gemaakt zijn, en een duidelijke planning. Op de stappen die hieronder volgen wordt een datum gekleefd, zodat zowel onze klant als wijzelf duidelijk weten wanneer wat van ons verwacht wordt.
Tegelijkertijd sturen we al een eerste vragenlijst door (voer voor een andere blogpost) rond inhoud en vorm.
1. Analyse
De eerste echte stap is heel eenvoudig samen te vatten: 'goed nadenken'.
Mijn vader zei me altijd: "Beter twee keer meten en maar één keer zagen - da's efficiënter". Wel, da's ook zo bij het bouwen van websites.
Dit is vooral praten. Praten met onze klant: hoe zit zijn bedrijf of organisatie in elkaar, wat zijn de doelgroepen, wat is de doelstelling van de site?
We doen dit in eerste instantie met een echte kick-off meeting. Daarin overlopen we met onze klant nog eens de zaken uit de voorbereidingsfase - en vragen we hem de pieren uit zijn neus over zijn bedrijf of organisatie.
Typisch verzamelen we al die informatie in een mindmap; zo kunnen we onze gedachten op een gestructureerde manier ordenen.
Hier worden ook de functionele vereisten van de website verzameld: wat moet de site doen, op welke manier? Je kan dit gerust een functionele analyse noemen.
2. Informatie-architectuur
Die verzamelde informatie - hoe geordend of chaotisch ook - gaan we structureren, hiërarcheren, labelen. Dit heet informatie-architectuur.
We bouwen al een eerste ruwe versie van de site in html - wat wij een structuurdocument noemen. Dit is een lege versie van de site: zonder layout, zonder functionaliteit, vaak ook zonder afgewerkte teksten.
We zouden dit op papier (of in Powerpoint of in Visio of ...) kunnen doen (en vaak doen we dat ook eerst); maar een klikbare versie legt de flow doorheen de site bloot. Als je effectief van pagina naar pagina kan klikken via werkende links, voel je hoe de site in elkaar zit, en waar de 'kleine haperingskes' zitten.
Je voelt hoe het klikt.
Dit is een iteratief proces: op basis van de informatie die we verzamelden, maken we een eerste voorstel, en zetten dat online voor onze klant. We vragen feedback, sturen bij, leveren een nieuw voorstel op, vragen feedback... tot het goed zit.
Dit is de belangrijkste fase in het hele proces.
Vergelijk het met het bouwen van een huis: vooraleer je begint te metselen, teken je toch eerst een plan? Dit structuurdocument is het architectuurplan van de website.
Na goedkeuring van het structuurdocument starten we met de layout-fase.
We vertrekken hiervoor vanuit de wensen van de klant. In de voorbereidende fase vroegen we hem een like/dislike lijst: een lijst van andere websites die hij visueel goed vind (en waarom) of niet goed vind (en waarom).
Daarnaast gebruiken we ook het aangeleverde huisstijlmateriaal. We hebben al het volledige spectrum meegemaakt: van 'er is helemaal niets, doe maar' tot 'hier is onze 260 pagina's tellende huisstijlgids'.
Onze designers beginnen altijd met schetsen, op papier. Ze baseren zich daarbij op het bovenstaande structuurdocument:
Die eerste ruwe schetsen worden verder verfijnd en uitgewerkt:
Daarna beginnen we aan het eerste ontwerp in Photoshop. We starten daarvoor met een binnenpagina - wat wij het 'werkpaard' noemen. (Het 'werkpaard' is die pagina die zonder extra ondersteuning al het harde werk moet doen: overbrengen van betekenis.)
Deze fase (eerste echte ontwerp in Photoshop) dient om de stijl van de site vast te leggen. Het is niet de bedoeling om hier alle details al vast te leggen. Wel om onze klant een gevoel te geven van hoe de site er zal uitzien. Vertrekkend van dit eerste ontwerp zullen de webdesigners dan extrapoleren naar andere pagina's.
Het gaat dus over de grote layout-lijnen. Vandaar dat we niet met de homepagina starten - de binnenpagina, de inhoudspagina zal veel meer van deze layout-lijnen blootleggen.
Ook dit is een iteratief proces: we leveren een eerste voorstel, vragen feedback, sturen bij...
Als die algemene stijl goedgekeurd is, werken we ook de andere pagina's uit: de homepagina, een blogpagina, een contactformulier...
4. Slice
Deze goedgekeurde Photoshop documenten worden uitgewerkt in html/css templates.
Ze worden opgemaakt volgens onze interne normen, en klaargezet om geïntegreerd te worden in ons CMS.
5. Development
Ondertussen zijn de webdevelopers al druk bezig om de functionaliteit die op maat moet geprogrammeerd worden uit te werken. Ze baseren zich daarbij op de functionele analyse uit stap 1 en het structuurdocument uit stap 2.
We hebben al heel veel veelgevraagde functionaliteiten uitgewerkt als standaard modules voor Fork CMS; maar tegelijkertijd geloven we dat elke site maatwerk vraagt.
Die maat-functionaliteit wordt dus uitgewerkt in nieuwe Fork-modules.
6. Integratie
De structuur, het design, en het programmeerwerk worden geïntegreerd in het Content Management Systeem, Fork dus.
Als we ons werk in de vorige stappen goed gedaan hebben, staat hier een werkende website die voor 90% goed zit.
7. Testen
Het spreekt vanzelf dat we dit uitgebreid testen; we leveren ook een testversie op aan onze klant zodat ook hij kan testen.
Onze klant moet uiteraard niet testen of het werkt (dat is onze job) - wel of alles er in zit, of alles op de juiste plaats zit, of we alles goed begrepen hebben...
Maar zoals gezegd, door de stapsgewijze aanpak waarbij de klant op elk moment mee stuurt, zal dit een quasi afgewerkte site zijn.
8. Content
Als alles aan beide kanten uitvoerig getest is, leveren we de site op.
Dat is het moment waarop onze klant inhoud in het CMS kan plaatsen. Ik 'eis' meestal van mijn klanten dat ze effectief zelf in het CMS werken - zo leren ze het kennen, en als er nog vragen of kleine wijzigingen opduiken dan kan dit nu, en niet als de site live is en de ganse wereld zit mee te kijken.
Op dat moment kan de klant niet alleen de teksten aanpassen, maar ook de beelden.
De website wordt op de definitieve server geplaatst (en nog eens getest, om verrassingen te voorkomen), maar voorlopig onder een niet-definitieve URL.
9. Live
Als alle inhoud geplaatst is, kan de website live gaan. We koppelen dan de definitieve URL aan de server.
Vanaf dat moment kan de klant die site volledig zelf beheren. Om het met een overdrijving te zeggen: na afloop van het proces wil ik die klant niet meer zien. Dit is uiteraard niet waar; maar voor dagelijkse aanpassingen moeten onze klanten volledig zelfstandig met het Content Management Systeem kunnen werken. (Als voor elke dt-fout een klant naar zijn webbureau terug moet, creëert dit alleen maar frustratie. Het webbureau moet dit inplannen, de klant wil dit onmiddellijk; het webbureau moet dit factureren, de klant wil dat gratis... Vandaar is een flexibel en uitgebreid CMS levensnoodzakelijk.)
Uiteraard ondersteunen we op elk moment onze klant; en staan we klaar voor functionele wijzigingen of uitbreidingen van de site - dan start dit proces opnieuw.
We volgen elk project op met een support-periode: een aantal weken na oplevering dat we die site met de loep mee volgen - zodat we snel kunnen ingrijpen mochten er bugs opduiken of als er kleine wijzigingen nodig zouden zijn.
Als onze klant dat wil (meestal enkel bij grotere projecten), bouwen we dit structureel in met een onderhoudscontract.
Dit zijn dus de stappen die we volgen bij het uitbouwen van onze websites. Nogmaals in een grafiek gegoten:
De verschillende stappen na elkaar in een slideshow tonen het onstaansproces van zo'n site:
We hebben ondertussen geleerd dat de stappen in dit proces nodig zijn. Als we er één overslaan, betekent dit heel vaak problemen of frustratie verder op de lijn.
Dit betekent niet dat we een maand afgezonderd in een hokje gaan zitten met een koude pizza en een fles cola - onze klant stuurt op elk moment mee. We spelen als het ware ping-pong met hem.
Het gevolg is dat we net zo veeleisend zijn voor onze klanten als we zijn voor onszelf. Maar dat is de enige manier om tot een goed eindresultaat te komen.
Zo, da's de korte samenvatting van ons webdesign proces. Hebben jullie feedback? Hoe verloopt het bij jullie? Hoe zouden jullie dit proces verbeteren?
Op 
In onze webapplicaties - zeker diegene met 
Onze sector is een jonge sector. Het web zelf is amper twintig jaar oud; in België hebben we een 
Op 16 en 17 februari ging in Parijs de eerste internationale Symfony conferentie, 
Voor het 
We hebben hier bij Netlash wel al 
