Sun (onlangs nog overgenomen door 's werelds grootste database-specialist Oracle), het bedrijf achter MySQL, biedt hiertoe 4 mogelijke certificaten, met name:

• Sun Certified MySQL Associate (SCMA)
• Sun Certified MySQL Developer (SCMDEV)
• Sun Certified MySQL Database Administrator (SCMDBA)
• Sun Certified MySQL Cluster Database Administrator (SCMCDBA)

Gezien we bij Netlash steengoeie web-applicaties bouwen, werd uiteraard geopteerd voor het MySQL Developer certificaat, wat bestaat uit 2 examens. De eerste optie (Associate) bevat 1 examen en is eigenlijk eerder een veredelde initiatie. Nummer 3 (Database Administrator) bestaat ook uit 2 examens, maar is dan weer gericht op db-admins. De laatste (Cluster Database Administrator) is een verderzetting van het 3e certificaat, waarvoor 1 extra examen wordt afgenomen.

Studiemateriaal

De heilige graal bij deze onderneming werd - hoe kan het ook anders - het boek "MySQL 5.0 Certification Study Guide", geschreven en gepubliceerd door mensen uit het team van MySQL zelf en specifiek bedoeld voor dit certificaat. Hoe groot mijn ego en zelfvertrouwen ook is: vooraleer ik 2 maal 154 vooruit schuif voor beide examens ben ik toch liever wat voorbereid.

Het boek is in elk geval een must voor elke MySQL ontwikkelaar. Vergelijkbaar met het voorbereidend boek voor het Zend-examen, was dit boek opnieuw eerder een naslagwerk dan een boek om MySQL te "leren". Je wordt dus wel degelijk verondersteld enige ervaring te hebben met MySQL. Veel nieuwigheden heb ik nu echter ook niet bijgeleerd, al geef ik toe dat ik bij momenten een Aha-Erlebnis beleefde. De ervaring zat vooral in de kleine details zoals: "maak een auto-incremented column unsigned - de auto-increment gaat toch niet negatief, dus ga je beter voor de hogere positieve limiet."

De examens

Maar toen werd het tijd voor het echte werk: de 2 examens. Eerst maakte ik nog even de overweging of ik al wel meteen beide examens wou doen of deze toch liever op verschillende data deed: ik had namelijk nog enkele hoofdstukken te gaan in het boek. Gezien de eerstvolgende mogelijke afspraak pas ten vroegste 3 weken later kon plaatsvinden, besloot ik er echter ineens volledig voor te gaan en schreef me voor beiden in via Prometric. Tegelijk beloofde het dan ook meteen een lange nacht te worden om nog snel de rest van het boek te doorworstelen, maar dan zou het in elk geval nog vers in mijn hoofd zitten.

En toen was het tijd voor de grote test. De 1u45 "plezier" per examen bleken in realiteit slechts 1u30 te zijn, waarin je - tijdens deze examentijd - nog wordt verwacht de algemene voorwaarden te lezen en te accepteren. Mocht jij dus toevallig die eenzaat zijn die EULA's wel leest, doe dit dan best al even op voorhand, want op het examen tikt de timer lustig verder.

Dit anderhalf uur bleek echter nog steeds meer dan voldoende tijd. De vragen in het examen zijn verzorgd op een 2-tal kleine foutjes na en heel duidelijk uitgeschreven. Op geen enkel moment zal een vraag verwarrend overkomen en het gehalte aan instinkers valt heel goed mee.

Persoonlijk vond ik het examen iets té theoretisch. Daar waar we bij het Zend-examen commentaar hadden dat het handboek ervoor eigenlijk te weinig nauw aanleunt bij het examen, leunt dit boek er juist wel te dicht bij aan: nagenoeg alle vragen lijken rechtstreeks uit het boek te komen. Je moet uiteraard heel goed snappen waarover alles gaat, maar hopen ervaring heb je naar mijn mening ook niet nodig.

Conclusión!

Vanaf heden ga ik dus ook onder de titel "Sun Certified MySQL Developer" door het leven. De eerste momenten klonk het wat raar wanneer mensen me zo nariepen op straat, maar ondertussen lijk ik stilaan gewoon te worden aan al deze nieuwe fans.

Maar even serieus: ik behaalde op examen 1 een score van 80% en op nummer 2 werd dit 72%. Gezien voor beide examens de limiet op 60% ligt, ben ik dus geslaagd! Het bewijs van de vele inspanning en toewijding is nu ook officiëel, wat uiteraard een grote voldoening met zich meebrengt, maar tegelijk is dit voor onze klanten opnieuw een extra garantie van onze kunde, geaccrediteerd door dé autoriteit op dit vlak.

Op naar een volgend avontuur!

Sun Certified MySQL Developer geschreven door Matthias in: opleiding

Tags: certified, mysql, sun certified mysql developer, webdevelopment

AnySurfer is een kwaliteitslabel voor websites die voor iedereen toegankelijk zijn — ook voor mensen met een functiebeperking.

Het Anysurfer Certified project is een project waarbij webbureaus die de expertise hebben om websites/webapplicaties te bouwen worden opgeleid om websites te bouwen die voor alle bezoekers toegankelijk zijn, ook voor bezoekers met een beperking. Daarnaast kunnen deze websites het kwaliteitslabel halen.

De opleiding

Het eerste deel van de opleiding bestond vooral uit een uitgebreide demo van Bart Simons. Bart is sinds zijn geboorte blind en is dus de perfecte man om ons op een goede manier duidelijk te maken waarop wij moeten letten om websites voor mensen met een beperking toegankelijk te maken.

Bart gebruikt een normale browser, met daarin javascript en flash geactiveerd. De extra tools die hij gebruikt zijn een screenreader en een brailleregel. Tijdens de demo - om het voor ons toegankelijk te maken - heeft hij gelukkig de snelheid van voorlezen op ongeveer de helft van zijn gewoonlijke snelheid gezet, en zelfs dat was voor ons soms heel snel.

Bart toonde aan de hand van enkele goede en slechte websites aan hoe een gebruiker met een beperking een website ervaart. Ik denk dat deze demo voor de meeste mensen de beste manier was om aan te tonen dat je door je verstand te gebruiken en enkele kleine extra aanpassingen de site op een heel eenvoudige manier toegankelijk kan maken.

Na de lunch gaf Roel uitleg bij de vernieuwde checklist (gebasseerd op WCAG 2.0). Er werd bij alle punten voldoende uitleg en/of voorbeelden gegeven.

Roel, zelf kleurenblind, is iemand die gebeten is door het toegankelijkheids-virus. En met veel passie en kennis over ieder punt uitleg kon geven. Aangezien Roel ook zelf websites ontwikkelt kan hij zich makkelijk verplaatsen in de rol van webdeveloper/webdesigner.

Besluit

Heel wat zaken die in de checklist zijn opgenomen zijn een kwestie van gezond verstand en worden al gedaan bij Netlash. Het is ook een kwestie van het gebruiken van standaarden.

Met een heel klein beetje moeite of extra zaken die we default gaan implementeren in Fork kunnen we ervoor zorgen dat onze websites toegankelijk zijn zonder veel extra werk.

Het is ook dat punt dat Roel terecht aanbracht. Een toegankelijke website is niet hetzelfde als "veel extra werk". Bovendien zijn heel wat zaken op de checklist ook een voordeel voor de SEO van je website.

Naast de richtlijnen die specifiek weggelegd zijn voor de designer en developer is een grote verantwoordelijkheid weggelegd voor de redacteurs van de website. Zij moeten zich evengoed bewust zijn van deze richtlijnen en bij het ingeven van content hiermee rekening houden.

Persoonlijk denk ik dat de opleiding een must is voor iedereen die werkt als designer of developer, maar evengoed voor redacteuren en vertegenwoordigers van webbureaus.

Anysurfer Certified geschreven door Tijs in: opleiding

Tags: accessibility, anysurfer, opleiding, toegankelijk

Om beter te kunnen inschatten hoe de kleurcombinatie die we willen gebruiken zich zal gedragen in de ruimte maken we schetsen. De combinatie van de antracietkleurige gepolijste betonvloer, het grijs van het plafond en de metalen steunen, het wit/rode meubilair en de rode wand van de balie hebben we hier eens tegenover elkaar gezet.

Een schets vertelt natuurlijk niet alles, maar 't geeft toch al een idee: er mag best wat meer rood in.

Nieuw kantoor: schets geschreven door Dirk Sabbe in: netlash

Tags: kantoor, netlash, nieuw, schets

Ook bij Netlash maken we meer en meer mobiele websites. Uiteraard konden we met onze eigen site niet achterblijven.

Gezien we allemaal enthousiaste iPhone gebruikers zijn, besloten we een eerste vingeroefening specifiek voor de iPhone uit te werken.

De website werkt ook op andere  GSM's met een browser gebaseerd op Webkit, zoals bvb. de HTC Hero, die op  Google's Android OS draait.

Ons standpunt rond mobiele websites is nog niet veranderd: we geloven nog steeds dat websites (die in een mobiele browser draaien) een grotere toekomst tegemoet gaan dan native applicaties. En we zijn er nog steeds van overtuigd dat we 'device-independent' moeten werken — websites moeten draaien op elk toestel. Maar vooraleer we een volledig onafhankelijke mobiele website bouwden, wilden we al eens een eerste test doen met een website specifiek voor iPhone.

Hieronder vind je een paar screenshots. Klik voor de grote versie.

De Netlash mobiele website geschreven door Bart in: webdesign

Tags: mobiel, mobiele sites, netlash

De aannemers op de werf van ons nieuwe kantoor komen op kruissnelheid. Vandaag waren ze in de weer met de isolatie van de vloer en de vloerverwarming. Eind deze maand moet ons deel van de ruimte voorzien zijn van de definitieve gepolijste betonnen vloer.

Vóór het bouwverlof staan de tussenwanden en kunnen we eindelijk in't echt zien wat de ruimte gaat worden. In het najaar volgt dan de verhuis. Eerst zorgen dat de bouw correct verloopt.

Hier vind je de originele, grote versie van de foto.

Nieuw kantoor geschreven door Dirk in: webdesign

Tags: ctrl dock, kantoor, loods 22, muide, netlash, werf

De nieuwe naamkaartjes voor Netlash nemen de drukkerij bij Peeters & Peeters over.

Netlash bij de drukker geschreven door Johan in: netlash

Tags: drukwerk, naamkaartjes, netwerken

Da's een beetje een omgekeerde redenering. Het klopt dat er heel veel mensen op Facebook zitten; maar er zitten nog meer mensen op het web in het algemeen. Het is niet omdat je een Facebook fanpagina of groep hebt (Niet zeker welk van beide je wilt? Lees dan zeker het artikel Facebook: groep of fanpagina op het blog van partner Talking Heads.) dat er plots heel veel vrienden of fans zullen opduiken - of zelfs maar dat er veel bezoekers zullen zijn. Net hetzelfde als bij een website: het is niet omdat je een site hebt, dat er veel bezoekers zullen komen.

De mechanismen om bezoekers naar je Facebook pagina te krijgen zijn anders dan die van een gewone website; en het klopt dat sociale netwerken een groot deel van die mechanismen ingebouwd en vergemakkelijkt hebben (het "deel met je vrienden" aspect). 

Maar zowel voor een website als voor een Facebook pagina zal je tijd/energie/geld (ze zijn soms onderling inwisselbaar) moeten stoppen in het opbouwen van een publiek.

Bovendien is er nog een ander, groter gevaar. Sociale netwerken zijn net als de newest hottest club in town. Vandaag is deze ene club zeer 'in', en wil iedereen naar die club gaan. Maar morgen gaat iedereen naar die club, en is hij plots niet meer 'in' - en begint iedereen naar de volgende uit te kijken. Dit is exact wat er met MySpace gebeurd is. Een drietal jaar geleden was MySpace dé plaats om aanwezig te zijn; momenteel is dit in België zo dood als een pier, en is iedereen overgeschakeld naar Facebook of Netlog.

Het blijft dan ook een strategisch risico om al je eieren in één mand te leggen en je volledige online bedrijfsaanwezigheid op een sociaal netwerk te zetten - een sociaal netwerk waarvan je de levensduur, populariteit of zelfs maar de functionaliteiten niet zelf onder controle hebt.

Wat uiteraard niet wil zeggen dat je de kracht en aantrekking van sociale netwerken dient te negeren.

De visie van Netlash is dan ook: bouw je eigen website uit als een centrale hub, en gebruik andere online middelen, zoals sociale netwerken, maar ook e-mail marketing en campagne-websites als aandrijvers van duurzame trafiek.

De kracht van sociale netwerken als Facebook, Netlog, Twitter en LinkedIn is inderdaad net dat daar het sociale aspect ingebouwd zit; mensen kunnen heel makkelijk informatie doorsturen naar hun netwerk.

In mijn ogen is het dan ook belangrijk om twee dingen te doen:

1. Een aanwezigheid op de relevante sociale netwerken te hebben.
2. Een integratie op je eigen website te hebben van de relevante sociale netwerken.

Je moet zeker als bedrijf aanwezig zijn op sociale netwerken. Uiteraard maak je daar een keuze in: het is onmogelijk om op elk netwerk even actief aanwezig te zijn. Identificeer dié plaatsen waar jouw doelgroep aanwezig is. Zorg dat je minstens je profiel daar geclaimed hebt - en draag er zorg voor dat alles in jouw profiel doorlinkt naar je eigen website. Op de minder belangrijke netwerken zorg je voor automatische inhoud: laat daar de technologie voor jou werken, gebruik bijvoorbeeld de automatische import van RSS-feeds vanuit je eigen blog. Op de belangrijkste netwerken zorg je voor een eigen stem, met communicatie die afgestemd is op dat netwerk en op die doelgroep. 

(Zoals steeds is het daar belangrijk om de ROI van je online strategie af te wegen. Elke aanwezigheid zal inspanningen kosten; elke gepersonaliseerde aanwezigheid zal nog meer inspanningen kosten. Je moet afwegen of je bedrijf daar de nodige middelen voor kan vrijmaken, en of die kost opweegt ten opzichte van het rendement.)

Zo zorg je voor een instroom vanuit sociale netwerken naar je eigen website; en maak je maximaal gebruik van de sociale mogelijkheden van die netwerken.

Omgekeerd bouw je best ook de mogelijkheden van die sociale netwerken in je eigen website in. Je moet faciliteren dat bezoekers de inhoud die op je eigen website verschijnt kunnen doorsturen naar hun eigen netwerken; zodat ze die niet zelf moeten gaan transporteren. 

Zo creëer je een feedback loop tussen je eigen website en de rest van het internet.

De tijd dat een website een afgezonderd, op zichzelf staand eiland op het wilde internet was, is definitief voorbij. Het membraan tussen jouw site en het internet moet zo transparant mogelijk worden.

Maar tegelijkertijd moet je realistisch zijn en beseffen dat jouw eigen website het centrum van je online strategie moet blijven.

Een eigen website of een pagina op Facebook als bedrijf? geschreven door Bart in: strategie

Tags: facebook, website, webstrategie

Vandaar dat we samen met onze klant Broken Frontier een eerste iPad app uitgewerkt hebben: The Frontiersman.

Uit het persbericht: "The Frontiersman is het eerste digitale magazine over comics op de iPad. The Frontiersman is een publicatie van comics nieuwssite Broken Frontier en werd ontwikkeld in samenwerking met webbureau Netlash. The Frontiersman verschijnt wekelijks op dinsdag. The Frontiersman covert alle aspecten van de comics universe, van mainstream tot onafhankelijke uitgevers, van digitale comics tot comics op het grote scherm. Wij brengen een gezonde mix van van interviews, diepgaande artikels en exclusieve previews van top artiesten."

We zien dit als een eerste verkenning van de mogelijkheden van de iPad, en willen hierop verder gaan.

Een paar links voor jullie:

• De website van Broken Frontier: www.brokenfrontier.com.
• De link naar de iPad app in de iTunes store: The Frontiersman.
• Zelf aan het nadenken over publiceren op de iPad? Contacteer ons, we denken graag mee.

Voor de comics liefhebbers onder jullie: de eerste editie van The Frontiersman heeft interviews met Mark Millar en John Romita, Jr. over Kick-Ass, Paul Gravett over Tove Jansson’s Moomin exhibition, en Jonathan Hickman over S.H.I.E.L.D. Je kan het magazine ook downloaden als pdf op de website van Broken Frontier.

iPad app geschreven door Bart in: webdevelopment

Tags: app, development, ipad

Tot nu toe kwam gemiddeld om de 2,5 maand een nieuwe webster ons team versterken. Dat ritme wordt blijkbaar aangehouden.

Op dit moment zijn we op zoek naar een extra Online Project Manager. Bekijk hier de vacature.

Vacature Project Manager geschreven door Bart in: webdesign

Tags: project manager, vacature

Dit examen is een erkende PHP-onderscheiding die wordt uitgereikt door Zend - The PHP Company. Het test de kennis van PHP en de real-life ervaring van de kandidaat. Op dit moment zijn er in België 75 mensen die zichzelf PHP5 Zend Certified Engineer mogen noemen.

Omdat niemand graag onvoorbereid naar zo'n examen gaat hebben we eerst wat meer informatie ingewonnen en een test-examen afgelegd. De manier van vraagstellen tijdens het test-examen is dezelfde als die op het uiteindelijke examen, namelijk 70 vragen waarvoor je 90 minuten de tijd krijgt.

Er zijn verschillende soorten vragen:

• meerkeuze met 1 correct antwoord
• meerkeuze met meerdere correcte antwoorden (het aantal staat steeds vermeld)
• invulvragen

De eerste kennismaking met het test-examen was voor mezelf zeer aangenaam. Na een kleine 45 minuten was ik klaar en behaalde ik een mooie score: Excellent.

Na deze eerste kennismaking met het test-examen hebben we (Davy, Matthias, Tijs) besloten om er volledig voor te gaan. De juiste zaken (practice-exam-vouchers, boek en exam-vouchers) werden aangekocht. Met deze zaken in handen zijn we begonnen ons verder voor te bereiden.

Voorbereiding

Als we het boek mogen geloven dan is het boek de ideale voorbereiding op het examen. Het boek behandelt alle topics die terugkomen in de test-examens, van de basis van PHP over OOP tot Security. Het boek is zeker geen beginnerstutorial, in een aantal hoofdstukken gaat men heel specifiek te werk.

Om heel eerlijk te zijn heb ik uit het boek heel weinig bijgeleerd — dat is ook niet de bedoeling van het boek — het was eerder een herhaling en bevestiging van wat ik al wist.

Om onszelf toch voor een deadline te stellen hadden we het examen vastgelegd op 2 april. Door de deadline werd de druk om goed voorbereid te zijn nét iets hoger. Na het boek volledig doorgenomen te hebben, deden we allemaal nog een aantal tests. Hierdoor kan je zien op welke topics je harder moet werken. Voor mij was het pijnpunt "Streams & Network-programming".

Test-examens

De test-examens zijn van een redelijk niveau. Er zijn een aantal vragen die gemakkelijk onder de noemer instinkers kunnen gecatalogeerd worden. Bijvoorbeeld een stuk code met daarin een syntax-error, maar bij de antwoorden staat het resultaat dat de code zou reproduceren indien er geen syntax-error was.

Sommige vragen gaan dan weer over een specifieke functie, een eenvoudig voorbeeld: Welke functie gebruik je om de waardes binnen een array op te tellen?¹

Het examen

Op vrijdag 2 april zijn we dus afgezakt naar het examencentrum van DevoTeam. Na enkele omzwervingen in Brussel hebben we uiteindelijk het correcte gebouw gevonden (recht over de ingang van paleis 11 aan de heizel - Google Maps).

Uiteraard waren we daar — zoals het hoort — te vroeg, en kregen we dus de kans om in de lobby nog een beetje te herhalen. Om 09u30 hebben we onszelf aangemeld, maar er waren wat problemen met hun intern netwerk, dus ons examen zou iets later plaatsvinden.

Maar na een uurtje konden we toch beginnen. We werden aangemeld op een computer en zijn gestart met het examen.

Het werd een zenuwslopende sessie, de vragen waren toch een pak specifieker dan verwacht. Net zoals de test-examens krijg je 90 minuten om de 70 vragen te beantwoorden.

Ikzelf heb eerst alle vragen waarvan ik zeker was opgelost, de vragen waar ik minder zeker van was heb ik gemarkeerd for review. Na de 70 vragen krijg je een overzicht met daarop aangeduid welke vragen je nog moet beantwoorden (incomplete) en vragen die je gemarkeerd hebt. Ik heb eerst de onbeantwoorden vragen nagekeken en opgelost. Erna heb ik de vragen die ik gemarkeerd heb nog eens goed nagekeken.

Als laatste heb ik dan alle vragen nog eens nagekeken, daarna heb ik met een klein hartje op de knop "End Exam" geklikt. Een aantal hartkloppingen later krijg je het resultaat te zien. In tegenstelling tot de test-examens krijg je geen feedback per topic maar enkel de melding of je al dan niet geslaagd bent.

Besluit

We zijn alledrie geslaagd.

• Davy
• Matthias
• Tijs

Maar ikzelf heb er toch een aantal bedenkingen bij. Naar mijn mening zijn de vragen op het examen een pak specifieker en dus moeilijker dan de test-examens. Enkel het boek instuderen zal je zeker geen garantie bieden om te slagen. Je hebt echt real-life ervaring nodig en je moet een verdomd goede kennis hebben van heel specifieke functies.

Maar goed, we zijn alledrie geslaagd en kunnen dus met trots zeggen dat er sinds 2 april 3 Zend Certified Engineers bij Netlash werken.

Tips

Wil je zelf ook deelnemen aan het examen, dan kunnen onderstaande tip zeker van pas komen:

• Zorg ervoor dat je ervaring hebt en dit op alle topics van het boek. Een website maken voor je nonkel zal niet genoeg zijn.
• Denk niet dat het enkel over code gaat, bekijk dus zeker en vast eens php.ini en begrijp wat daarin staat.
• Zorg dat je het concept van by-value en by-reference goed beheerst.

¹: array_sum

Zend Certified Engineers geschreven door Tijs in: opleiding

Tags: certified, php, zce, zend certified engineer

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)

Bart zei in 2008 in De Illusie van het Mobiele Web:

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.

Vooruit denken bij het ontwikkelen van een mobiele website geschreven door Johan in: webdesign

Tags: development, iphone, mobile, strategie

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.

Je kan de class terugvinden op: http://classes.verkoyen.eu/css_to_inline_styles, daar staat ook de nodige documentatie en een voorbeeld van hoe je de class kan gebruiken.

Combineer dit met de functie die Annelies eerder schreef en je bent klaar om jouw gebruikers de beste mail te sturen.

Convert CSS naar inline styles geschreven door Tijs in: webdevelopment

Tags: css to inline styles, email nieuwsbrief, php

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).

Wat is jullie mening?

Het geïntegreerde webbureau geschreven door Bart in: webdesign

Tags: integratie, webbureau, webdesign

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.

Symfony Live 2010 geschreven door Bert in: opleiding

Tags: conferentie, symfony

De functie:

De uitleg:

// 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.

Bekijk achtereenvolgens eens de originele nieuwsbrief, de plain text inhoud gemaakt met strip_tags en de plain text inhoud gemaakt met getPlainText.

Opmerkingen:

Zodat jullie ze niet meer moeten geven, enkele opmerkingen:

• Niet alle html karakters worden goed vervangen.
• Afhankelijk van de html code zullen er hier en daar toch nog meerdere witregels staan.
• Het beste resultaat wordt natuurlijk nog altijd verkregen als je zelf de plain inhoud van je nieuwsbrief maakt.

Nog opmerkingen zijn uiteraard welkom :-)

Update (13/02/2010)

De nieuwe versie kan je hier vinden.
Het resultaat op de Netlash nieuwsbrief van 21 januari vind je hier.

Wat is er veranderd?

• hoofdingen worden nu aangeduidt door **
• lijst items worden aangeduidt met -
• na hoofdingen, paragrafen en lijst items worden er witregels geplaatst
• script elementen worden nu ook gestript zodat de functie niet enkel voor e-mail nieuwsbrieven geschikt is

Dit maakt het geheel nog beter leesbaar en zorgt voor een minimum aan opmaak.

(Deze blogpost is geschreven door Netlash webdevelopster Annelies, en verscheen eerst op haar persoonlijke blog.)

HTML naar plain text omvormen geschreven door Annelies in: webdevelopment

Tags: e-mail, email nieuwsbrief, plain text, strip, tags

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?

Het gaat over het verzamelen van informatie: de transfer van kennis die in het hoofd van onze klant zit, naar onze hoofden - om die dan te bevruchten met onze kennis van wat werkt online en wat niet.

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.

Het voorbeeld hierboven is dat van de vernieuwde bSeen website - je vind de twee iteraties van het structuurdocument hier.

3. Design

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.

(Bovendien is de homepagina al lang niet meer de belangrijkste pagina van een website.)

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.

Het eindresultaat van de bovenstaande staooeb voor de bSeen website kan je online bekijken.

10. Support

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?

Webdesign proces bij Netlash geschreven door Bart in: webdesign

Tags: kwaliteit, proces, webdesign

Queries optimaliseren, veel developers zien het als een straf. Het kan nochtans eenvoudig zijn, maar zoals bij alles moet je eerst begrijpen wat er gebeurt vooraleer je kan gaan ingrijpen.

Om te begrijpen hoe MySQL een query behandelt kan je het EXPLAIN-statement gebruiken. Met behulp van dit statement kom je heel wat te weten.

Een voorbeeld:

EXPLAIN SELECT d.id, d.profile_id, ...
FROM designs AS d
INNER JOIN templates AS t ON d.template_id = t.id
INNER JOIN profiles AS p ON d.profile_id = p.id 
WHERE d.active = 'Y' AND d.offline = 'N' AND d.template_id > 0 AND (d.date_expire IS NULL OR d.date_expire > NOW());

Als resultaat krijg je iets zoals hieronder:

In deze tabel zijn er verschillende kolommen met elk hun eigen betekenis, hieronder bespreken we de relevante kolommen. Meer informatie over alle kolommen kan je terugvinden op dev.mysql.com.

select_type

Het gebruikte SELECT-type. Mogelijke waardes zijn:

• SIMPLE

  Zoals het woord als zegt: een eenvoudige SELECT.

• PRIMARY

  Omringende SELECT-query.

• UNION

  Tweede of laatste SELECT in een query die gebruik maakt van UNION.

• DEPENDANT UNION

  Tweede of laatste SELECT in een query die gebruikt maakt van UNION en afhankelijk is van de omringende query.

• UNION RESULT

  Resultaat van de UNION.

• SUBQUERY

  Eerste SELECT in de subquery.

• DEPENDANT SUBQUERY

  Eerste SELECT in de subquery en afhankelijk van de omringende query.

• DERIVED

  Afgeleide tabel (maw: er staat een subquery in de FROM-clause).

• UNCACHEABLE SUBQUERY

  Subquery waarvan iedere rij moet worden geherevalueerd.

• UNCACHEABLE UNION

  Tweede of laatste SELECT in een query die gebruikt maakt van een UNION in de subquery.

table

De gebruikte tabel.

type

Het type van JOIN, er zijn verschillende waardes mogelijk.

De verschillende types worden hieronder aflopend gesorteerd. De volgorde van de MySQL manual wordt gerespecteerd, en deze omschrijft de volgorde als 'gesorteerd van het beste type naar het slechtste'. In de praktijk is deze volgorde niet van 'snel naar traag', gezien dit alles afhangt van wat je exact verwacht van je query.

• system

  Indien de tabel maar 1 rij bevat.

• const

  Je vergelijkt met een constante en is daarom snel.

  SELECT * FROM table WHERE id = 1;

• eq_ref

  Er is maar 1 rij uit deze tabel die past bij (de combinatie van) de vorige rijen. Hier gaat het dus om een PRIMARY KEY of UNIQUE index in de tabel die wordt gejoined.

  SELECT t1.*, t2.* FROM table1 AS t1 INNER JOIN table2 AS t2 ON t2.id = t1.fk;

• ref

  Bij (de combinatie van) de vorige rijen kunnen meerdere rijen van deze kolom matchen omdat de kolom waarop de tabellen gejoind worden geen unieke waarden bevat.

  SELECT * FROM table1 AS t1 INNER JOIN table2 AS t2 ON t2.not_unique = t1.fk;

• fulltext

  In tegenstelling tot bovenstaande query-types wordt hier niet gezocht op een exacte waarde in je dataset, maar wordt een match gedaan op de volledige inhoud van je rij om te bekijken of de waarde voorkomt en hoe vaak deze voorkomt.

  Hierbij worden intern ook enkele speciale handelingen uitgevoerd: zo worden bijvoorbeeld zoekwoorden die in meer dan 50% van de rijen voorkomen of taal-specifieke stopwoorden (zoals some, then, …) niet meegerekend.

  Met 'IN NATURAL LANGUAGE MODE' zal het nodig zijn een FULLTEXT index aan te maken op de columns die je wenst te doorzoeken.
  Bij 'IN BOOLEAN MODE' is dit niet nodig (opzoeken zal hierdoor wel trager gaan), en kunnen ook speciale operators meegegeven worden om heel specifiek te gaan zoeken. Deze zal uiteraard om deze reden ook nog trager zijn dan de NATURAL LANGUAGE MODE omdat dit een veel complexere operatie kan worden.

  SELECT * FROM table WHERE MATCH(column) AGAINST('search');

• ref_or_null

  Idem als 'ref', maar hier wordt ook gecontroleerd op null-waarden.

  SELECT * FROM table1 AS t1 LEFT OUTER JOIN table2 AS t2 ON t2.not_unique = t1.fk;

• index_merge

  Dit type geldt voor queries waarbij het resultaat de uitkomst is van meerdere verschillende selecties (typisch bij OR). Intern worden deze verschillende selecties apart uitgevoerd en de resultaten hiervan worden gecombineerd weergegeven als omvattende resultset die voldoet aan de volledige expressie.

  SELECT * FROM table WHERE column1 = X OR column2 = Y;

• unique_subquery

  De kolommen die gematcht worden zijn het resultaat van een subquery die unieke kolommen geeft.

  SELECT * FROM table1 WHERE column IN (SELECT id FROM table2);

• index_subquery

  Dit type is gelijk aan unique_subquery, behalve dat in plaats van een subquery met unieke waarden, deze werkt met niet-unieke kolommen.

  SELECT * FROM table1 WHERE column IN (SELECT not_unique FROM table2);

• range

  Enkel rijen binnen een bepaalde range van een index moeten worden onderzocht, de gebruikte index kan je terugvinden in de key-kolom.

  SELECT * FROM table WHERE id BETWEEN 10 AND 20;
  SELECT * FROM table WHERE id IN (10, 11, 12);

• index

  Idem als ALL (zie onder), maar enkel de index moet onderzocht worden.

  SELECT * FROM table WHERE id = 1;

• ALL

  De volledige tabel moet onderzocht worden. Indien dit voorvalt los je dit best op.

possible_keys

Een oplijsting van de indexen die MySQL kan gebruiken. Dit wil niet zeggen dat er één zal gebruikt worden.

Indien deze kolom leeg is, dan zijn er geen bruikbare indexen gevonden. Het kan dan nuttig zijn om op basis van de WHERE-clause een toepasselijke index te maken.

key

Hier kan je zien welke key (index) gebruikt is.

ref

Hier kan je zien welke kolom vergeleken werd met de gebruikte index.

rows

Het (geschatte) aantal rijen dat MySQL zal onderzoeken.

Als je gebruik maakt van JOINS dan moet je de resultaten in deze kolom met elkaar vermeningvuldigen, zo bekom je het totale aantal rijen. Het spreekt vanzelf dat een lager totaal een snellere query oplevert.

extra

In deze kolom kan je informatie vinden over hoe MySQL de query oplost. Mogelijke waardes zijn:
(enkel relevante waardes zijn vermeld, meer op: http://dev.mysql.com/doc/refman/5.1/en/using-explain.html)

• Distinct

  MySQL zoekt naar unieke waardes.

• Impossible WHERE noticed after reading const tables

  Indien de WHERE-clause altijd false oplevert.

• No tables

  Indien de query geen FROM-clause heeft.

• Using filesort

  Om de rijen correct te sorteren moet MySQL de gevonden resultaten opnieuw overlopen.

• Using index

  Er is een enkel een index gebruikt om de rijen te selecteren.

• Using temporary

  Om de query op te lossen moet een tijdelijke tabel gemaakt worden. Dit valt meestal voor indien je GROUP BY of ORDER BY gebruikt.

• Using where

  Om de query op te lossen is de WHERE-clause gebruikt. Indien dit niet voorkomt is er ofwel iets mis met je query of onderzoek je bewust alle rijen van de tabel.
  Let wel: dit kan een vertraging aanduiden als er veel data is.

Zoals je kan afleiden uit bovenstaande lijst vermijd je best 'Using filesort' en 'Using temporary', dit zijn de twee gevallen die een query traag maken.

Wat is een index?

Om een query te optimaliseren moeten we natuurlijk begrijpen wat een index is.

Zie een index als een inhoudsopgave van een boek. Door een inhoudsopgave kan je snel naar een bepaald onderwerp in het boek gaan zonder alle pagina's te moeten lezen.

MySQL gebruikt de index in een aantal situaties:

• zoeken van rijen
• elimineren van niet-relevante rijen, indien er meerdere mogelijke indexen zijn zal MySQL deze nemen met de minste rijen
• om verschillende tabellen te JOINEN
• minimum- en maximumwaardes ophalen
• sorteren van resultaten

Zonder indexen moet MySQL de volledige tabel gaan overlopen om resultaten te vinden, met een index hoeft MySQL enkel het relevante stuk te doorlopen.

Je kan nu denken dat je op iedere kolom en op elke mogelijke combinatie een index kan leggen. Dit is echter geen goed idee - en ook niet mogelijk - want een index wordt bij iedere INSERT, UPDATE, DELETE herberekend, waardoor deze statements dan weer trager worden. Hoe meer indexen hoe trager het geheel, hou dit dus ook in het achterhoofd bij het optimaliseren van een query.

Bij het maken van een index kan een type meegeven. Iedere type heeft zijn eigen eigenschappen.

• PRIMARY KEY

  De combinatie van velden is uniek doorheen de tabel, per tabel kan er maximaal 1 PRIMARY KEY zijn.

• UNIQUE

  De combinatie van velden is uniek doorheen de tabel.

• INDEX

  In tegenstelling tot een UNIQUE index hoeft de combinatie van velden niet uniek te zijn.

• FULLTEXT

  Een speciaal type van index dat gebruikt word voor full-text-searches. (enkel beschikbaar voor MyISAM-tabellen)

Je kan een index aanmaken met volgende MySQL-statement:

ALTER TABLE table1 ADD [type] (column, column);

Hoe kies je nu een juiste index?

Vooraleer je indexen begint aan te brengen moet je nadenken of het wel nut heeft. Is het een tabel met weinig data, dan kan het zijn dat de query sneller is als alle rijen worden overlopen. Is het een query die weinig gebruikt wordt? Dan kan je je beter concentreren op queries die veel worden uitgevoerd (bijvoorbeeld bij iedere klik).

Een klein rekenvoorbeeld: je hebt een query die 1 maal per dag word uitgevoerd en 10 seconden duurt, door middel van indexes kan je die terugbrengen naar 2 seconden, dan heb je 8seconden gewonnen.

Stel nu dat er een query is die 1000 keer per dag wordt uitgevoerd en die 1 seconden duurt en je kan optimaliseren tot 200ms dan win je 1000 x 800ms en dus in totaal 8000 seconden.

Opmerking: Dit is een theoretisch voorbeeld.

Een goede index zorgt ervoor dat MySQL de WHERE-clause zo snel mogelijk kan oplossen. Als je bijvoorbeeld e.active = 'Y' AND e.hidden = 'N' in je query hebt staan dan is het slim om een index op active en hidden te leggen.

Je kan eigenlijk volgende leidraad gebruiken: eerst de kolommen in de WHERE-clause, dan de kolommen in de SELECT-clause.

Opmerking: Dit is een leidraad, geen vaststaand feit.

Als we een aantal indexen leggen en onze eerste query terug uitvoeren komen we op volgend resultaat:

Andere voorbeelden om queries te optimaliseren

STRAIGHT_JOIN

Bij het uitvoeren van een query met JOINS over verschillende tabellen, maakt MySQL zelf een query plan. Dit bepaalt in welke volgorde de tabellen worden geprocessed en gejoined.

Dit zal more often than not de meest effeciënte manier van joinen zijn, echter niet altijd. Het kan natuurlijk altijd voorkomen dat juist die ene vaak gebruikte query doorheen een grote dataset door MySQL net niet goed genoeg geïnterpreteerd wordt, met een groot prestatieverlies als gevolg. Dit kan je oplossen met STRAIGHT_JOIN.

Door middel van SRAIGHT JOIN kan je zelf bepalen in welke volgorde je tabellen zullen worden gejoined, of eerder: MySQL zal je tabellen van links naar rechts joinen in plaats van zelf de volgorde te beslissen. Met dan zorgvuldig zelf de tabellen in de juiste volgorde neer te poten, kan je sommige queries efficiënter maken.

SELECT STRAIGHT_JOIN *
FROM table1 AS t1
INNER JOIN table2 AS t2 ON t1.col = t2.col;

Werken met DATETIME

In veel CMS-en is er de mogelijkheid om een publicatie-datum van een artikel aan te geven. Dit is een potientieel risico voor trage queries.

Omdat een tijdstip iedere seconde anders is, kan de query maximaal 1 seconde gecached worden.

SELECT e.*, m.*
FROM blog_entries AS e
INNER JOIN meta AS m ON e.meta_id = m.id
WHERE e.active = 'Y' AND e.hidden = 'N' AND e.date_publish < NOW()
ORDER BY e.date_publish DESC;

Het is overbodig om de gebruiker tot op de seconde te laten specifieren wanneer een een artikel moet getoond worden. Je kan er dus beter voor zorgen dat bij het opslaan de seconden op 00 staan. En je query herschrijven als volgt (uiteraard met het correcte tijdstip):

SELECT e.*, m.*
FROM blog_entries AS e
INNER JOIN meta AS m ON e.meta_id = m.id
WHERE e.active = 'Y' AND e.hidden = 'N' AND e.date_publish < "2009-11-03 13:37:00"
ORDER BY e.date_publish DESC;

Hierdoor kan je query maximaal 1 minuut gecached worden. Je zou natuurlijke en stap verder kunnen gaan en enkel kwartieren kunnen toelaten.

ORDER BY RAND()

Als we onze server-admins mogen geloven dan sterft er iedere keer je ORDER BY RAND() gebruikt een klein schattig konijntje. ORDER BY RAND() is een heel intensieve operatie bij grote tabellen.

Je kan dit beter oplossen in je code, bijvoorbeeld met de PHP-functie shuffle.

Heb je echter een slechts een kleine result-set nodig die random moet gegenereerd worden uit een grote hoeveelheid data, dan biedt shuffle natuurlijk ook geen goed resultaat, omdat je dan die grote hoeveelheid data (even) in het geheugen zal moeten dulden, terwijl je slechts een kleine hoeveelheid data hiervan nodig hebt. Hoe kan je dit beter?

// get the maximum ID
$max = 'SELECT MAX(id) FROM table;';
// do n queries, where n is the number of rows to retrieve
// this should be more effective then one ORDER BY RAND()-query
for ($i = 0; $ < [totaal-aantal-benodigde-random-rijen]; $i++) {
	get random row
	$results[$i] = 'SELECT  * FROM table LIMIT '. rand(0, $max) .', 1;';
}

Waarom is dit nu efficienter dan ORDER BY RAND()? Wel, voor iedere rij in de tabel moet bij ORDER BY RAND() een willekeurig getal worden gegenereerd, hierna moet er op al deze willekeurige getallen ook nog gesorteerd worden.

Disclaimer: zie deze blogpost niet als de heilige graal om je website met tienduizende bezoekers te gaan optimaliseren. Voor zo'n situaties kan je beroep doen op DB-admins, deze kunnen op basis van je applicatie en logs gaan kijken wat er specifiek moet geoptimaliseerd worden.

Bronnen: MySQL, Openminds, PHPhulp, #netlash, Learning MySQL, Web Database Application with PHP & MySQL.

MySQL EXPLAIN als hulp geschreven door Tijs, Matthias, Annelies, Davy, Dave in: webdevelopment

Tags: explain, mysql, performance, tips

Ik heb een bankverleden.

Vooraleer ik de ondernemers-sprong waagde en webwerker werd, was ik in loondienst bij een Grote Belgische Bank.

Ik werkte een tijd in een kantoor in Landegem, een klein dorpje ten zuiden van Gent. Eén van de eigenschappen van dat dorpje is dat er zowel een beschutte werkplaats, een MPI, als een aantal tehuizen voor mensen met een handicap gevestigd zijn.

Toegankelijkheid en mijn bankverleden

In dat bankkantoor leerde ik dagelijks omgaan met mensen met een functiebeperking; laat me zeggen dat de uitdaging om het online banking pakket toegankelijk te krijgen eind jaren negentig aanzienlijk waren.

Het maakte me bewust van de vragen en noden van die specifieke bevolkingsgroep - maar vooral: het deed me inzien dat je bij alles wat je doet inclusief moet werken en denken, en niet noodzakelijk vanuit je eigen wereldbeeld moet vertrekken.

Anysurfer en Netlash

Vandaar dat het verhaal van Anysurfer onmiddellijk bij me aansloeg. Voor veel mensen met een functiebeperking is het internet dé manier om makkelijk deel te nemen aan de alledaagse dingen uit ons leven (dingen als online shoppen, banksoftware gebruiken of de uurroosters van De Lijn raadplegen). Websites maken met aandacht voor de richtlijnen van Anysurfer strookte met mijn visie rond duurzaam ondernemen.

Het kwam uiteraard goed uit dat een toegankelijke website vaak tegelijkertijd ook een SEO-geoptimaliseerde en gebruiksvriendelijke website is.

Vandaar dat we besloten om zoveel mogelijk de regels van Anysurfer te volgen bij het bouwen van onze sites. Vandaar ook dat we ook met onze eigen Netlash website expliciet het Anysurfer label wilden halen.

Anysurfer en ABconcerts.be

We waren dan ook blij te horen dat onze partner en klant Ancienne Belgique ook nadenkt over toegankelijkheid voor bezoekers met een handicap. Meer nog, ruim 300 personen met een handicap genieten op donderdag 21 januari 2010 van een exclusief en gratis concert van Channel Zero in de AB in Brussel.

De AB wil met dit concert beklemtonen dat ook bezoekers met een handicap meer dan welkom zijn op hun evenementen. Niet enkel voor dit concert dus, maar een heel jaar door. Daarom heeft het AB-team samen met Team Netlash de nodige inspanningen gedaan hebben om de website ook in een nog toegankelijker versie uit te werken.

Naast de AB Website werkt AB ook volop aan de toegankelijkheid van de ticketingspagina's (tickets.abconcerts.be) voor personen met een functiebeperking. Door de technische complexiteit van dit gedeelte van de site zullen de pagina's in de loop van het voorjaar (2010) gewijzigd worden, conform de richtlijnen van Anysurfer.

Je kan de vernieuwde toegankelijke versie nu al bekijken (zie de link bovenaan links op de site), samen met de toegankelijkheidsverklaring.

Jullie feedback is uiteraard, zoals steeds, meer dan welkom.

Anysurfer geschreven door Bart in: webdesign

Tags: ab, accessibility, anysurfer, toegankelijk

Vorig jaar vroeg ik daarbovenop aan twintig experts wat hun voorspellingen voor 2009 waren. Dit jaar gingen we nog een stap verder: we vroegen openlijk aan iedereen die zich geroepen voelde om een bijdrage te leveren.

Een trendrapport dat gecrowdsourced wordt? Is zoiets mogelijk?

Ik wou het alleszins proberen.

60 verschillende stemmen, zo divers als mogelijk: van student tot internetmarketeer, van founder van een startup tot CEO van een gevestigd reclamebureau, van academicus tot minister. Met de nodige duwtjes hier en daar kreeg ik evenveel voorspellingen over online in 2010 binnen.

Het eindresultaat is iets minder voorspellend geworden, als wel een document over 'wat houdt de Vlaamse digirati op dit moment bezig'.

Voor wie de samenvatting wil:

De meesten zijn er van overtuigd dat in 2010 mobiel internet (16 vermeldingen) definitief mainstream wordt. Er zijn ook hoge verwachtingen over augmented reality (13 vermeldingen).

Terwijl velen zien dat sociale netwerken (9 vermeldingen) in het weefsel van onze maatschappij doordringen, en bedrijven massaal met sociale media aan de slag gaan (9 vermeldingen), zijn er toch heel wat bedenkingen over veiligheid en privacy (9 vermeldingen). Ondertussen moeten die sociale media geld beginnen opbrengen, en ligt de focus op ROI en conversie (7 vermeldingen). Sommigen zien alweer een social media fatigue (5 vermeldingen) optreden; anderen zien email vervangen worden door sociale media (5 vermeldingen).

De tablets en e-books (9 vermeldingen) worden een hype; zou dit met de aandacht voor 'groen' (9 vermeldingen) te maken hebben?

Nog drie buzzwords: alles moet real time (9 vermeldingen) zijn, liefst nog location based (6 vermeldingen) en in de cloud (5 vermeldingen).

Je kan het trendrapport hier downloaden in pdf-formaat: Online Trendrapport 2010 (.pdf, 16.3 Mb).

Maar je kan het hier ook rustig doorbladeren:

Voldoende inspiratie?

Volgend jaar verwacht ik alleszins jullie voorspellingen in mijn mailbox!

Online trendrapport 2010 : de voorspellingen geschreven door Bart in: trend

Tags: online, trend, trendrapport, trends, trendwatching, voorspellingen, web

Ik pretendeer zeker niet te weten waar media naar toe gaan, en hoe dat moet gebeuren. 

Toch probeerde ik om de grote trends weer te geven, en zo de discussie op gang te trekken. (Vergelijk het met de workshop 'Trends in e-business' die ik in 2004 voor Partena gaf.)

Hieronder vind je mijn presentatie:

Er zitten 5 hoofdstukjes in:

1. Content: Gaat het over kwaliteit of kwantiteit? En hoe krijgen beide begrippen een invulling online?
2. Distributie: Is dit nog steeds de controlerende factor online? En hoe is dit anders dan offline?
3. Informatie: Online hoef je je niet te beperken tot het format tekst+foto, maar kan je gebruik maken van de interactiviteit van internet.
4. Nieuws: De Nu-Nu-Nu generatie heeft andere verwachtingen van nieuws.
5. Community: Media kunnen waarde creëren door een stem, een filter, een kader te bieden in de overvloed aan informatie.

Geen wereldschokkende bevindingen uiteraard; en voor wie met internet dagelijks omgaat zelfs evidenties.

Edit: De Werktitel maakte een samenvatting van de presentatie.

Oude media versus nieuwe media geschreven door Bart in: marketing

Tags: media, visie

1. Inge Wiame, Business Development Manager Benelux - Netlog
   Presentation of the renewed Netlog platform
2. Tom Remans, Marketing Manager - Luon
   Client-case Solo : social media as part of an integrated marketing approach
3. Nico Henderijckx, Online Marketing Manager - Sony VAIO of Europe
   Client-case Sony VAIO: “VAIO of Europe - Social media approach
4. Charles Crouch, Lecturer Boston University
   Planning a social media campaign
5. Clo Willaerts, Marketing manager sanoma magazines
   How to make money with Social Media
6. Genevieve Tissot, Managing director BlueKiwi
   Client case social media platform
7. Kim Leunen, Account Manager S²Media
   Why you should join / Define your goals / How to Measurements & tools / Case - tips & tricks
8. Evan Van Lissum, Managing partner The Parking Lot
   Social branding : New kids on the blog
9. Bart de Waele, Co-founder Talking Heads
   Nike Running & Social Media
10. Didier Ongena, Director Microsoft Advertising

Meer info op www.socialmediaforum.be.

Ik zal er alleszins zijn - jullie ook?

Social Media Forum geschreven door Bart in: opleiding

Tags: event, forum, opleiding, social media

1. Begin met een goede briefing

Begin door een duidelijke beschrijvende briefing aan de klant te vragen. Stel eventueel zelf een vragenlijst op die de klant kan invullen. Probeer zoveel mogelijk concrete zaken te verzamelen. Wanneer de klant een vaag buikgevoel beschrijft, kan je vragen of hij dit kan illustreren met voorbeelden van andere sites, logo’s en stijlen.

Wanneer je voelt dat je weet welke richting de klant uit wil, kan het handig zijn zelf een kleine verzameling elementen bij elkaar te zoeken. Deze verzameling kan je gebruiken om later terug de stijl op te roepen die de klant voor ogen heeft.

2. Evalueer bestaande stijlelementen

Zorg dat de klant je al zijn oud materiaal stuurt en evalueer of zijn logo en kleuren passen bij de eerder beschreven stijl. Vraag zeker ook na of de klant goed fotomateriaal heeft. Unieke professionele foto’s kunnen vaak het verschil maken bij een ontwerp.

Kijk alle elementen na en controleer of alles bruikbaar is. Open alle vector bestanden om na te gaan of ze daadwerkelijk vector zijn. Bekijk de resolutie van eventuele foto’s en kijk de kleurprofielen na.

3. Visualiseer de inhoud en bepaal het doel

Bekijk de structuur die de informatie architect met de klant heeft gemaakt en overloop wat het doel is van elke pagina en element. Bepaal wat moet opvallen en wat minder moet opvallen vanuit het oogpunt van de bezoeker.

Het is de taak van de designer om ervoor te zorgen dat hij de bezoeker doorheen de pagina gidst, en alles ziet wat hij hoort te zien. Wanneer te veel elementen om aandacht vechten zal de bezoeker zijn weg doorheen de pagina niet vinden.

4. Maak minstens 4 voorstudies

Eens je het doel en de klemtonen van alle elementen weet, maak je best enkele schetsen. Het schetsen is een cruciale stap bij het ontwerpen. Het stimuleert de creativiteit en spaart veel tijd uit. Een viertal schetsen uitwerken per pagina is het absolute minimum.

Ontwerpen van 3 verschillende Netlash ontwerpers.

Stop echter niet te veel tijd in een schets. Schets eerder alles neer wat je te geest komt en visualiseer wat er zal werken en wat niet. Werk de beste schetsen uit in fijnere voorstudies om zo je idee bij te schaven.

5. Werk een eerste voorstel uit

Open je favoriete webdesign programma om je ontwerp vorm te geven en ga aan de slag om je visie om te zetten in pixels. Laat je ontwerp evolueren en laat je zeker niet limiteren door je schetsen.

Hou rekening met de beperkingen van browsers en schermresoluties en maak je ontwerp altijd op ware grootte. Probeer de inhoud zo realistisch mogelijk te houden, indien mogelijk zelfs de definitieve copy. Wanneer je die laatste knop en pixel juist geplaatst hebt, is het tijd om het document te sluiten. Neem een korte pauze of werk even iets anders af.

6. Knijp die ogen eens half dicht

Open nu je document en kijk wat je eerste indruk is. Vallen de elementen die moeten opvallen (zie stap 3) op? Neem wat afstand van je scherm en knijp je ogen dicht tot alles wat troebel is.

Zo kun je makkelijk evalueren of je ontwerp in balans is. Eventueel vraag je aan iemand om even je ontwerp te bekijken. Zorg wel dat je open staat voor hun kritiek! Het is soms niet prettig om negatieve kritiek te horen op een ontwerp waar je net enkele uren aan hebt gewerkt.

• Voldoet je ontwerp niet aan de verwachtigen en doelstellingen? Ga terug naar stap 1, passeer langs start en neem een Nalu.
• Voldoet je ontwerp wel aan de verwachtingen en doelstellingen? Ga dan naar stap 7.

7. Geniet van je rockstar moment

Proficiat! Je bent voor heel even een webdesign rockstar! Spring even op je bureau en doe een luchtgitaarsolo. Blijf echter niet te lang in je roes, je ontwerp moet nog gesliced en geïntegreerd worden zodat de hele wereld ervan kan genieten.

Het grafisch proces geschreven door Yoni in: webdesign

Tags: proces, vormgeving, webdesign

Dieter Rams was veertig jaar hoofd van het designteam van elektronicaproducent Braun. Hij was verantwoordelijk voor een belangrijke stroming in het industriële design van vorige eeuw.

Meer nog, hij beïnvloedde rechtstreeks één van de huidige iconografische designers, namelijk Jonathan Ive, hoofddesigner van Apple.

Hoe groot zijn invloed is kan je in onderstaande fotomontage zien (bovenaan werk van Rams, onderaan werk van Ive):

Dieter Rams is één van de mensen die ons hier bij Netlash richting geven.

Beschouw bijvoorbeeld volgende quote van hem:

“Good designers must always be avant-gardists, always one step ahead of the times. They should – and must – question everything generally thought to be obvious. They must have an intuition for people’s changing attitudes. For the reality in which they live, for their dreams, their desires, their worries, their needs, their living habits. They must also be able to assess realistically the opportunities and bounds of technology.”

Dit komt uit een speech uit 1980 die Rams aan de Braun advisory board gaf. Hierin geeft hij aan dat de mens, de gebruiker centraal moet staan - tegelijkertijd rekening houdend met de mogelijkheden en beperkingen van de technologie.

Hij formuleerde ook de 10 principes waaraan goed design volgens hem voldoet:

1. Good design is innovative.
2. Good design makes a product useful.
3. Good design is aesthetic.
4. Good design makes a product understandable.
5. Good design is unobtrusive.
6. Good design is honest.
7. Good design is long-lasting.
8. Good design is thorough down to the last detail.
9. Good design is environmentally friendly.
10. Good design is as little design as possible.
    

Het zijn principes die we hier ook in onze websites proberen te stoppen. Ik vertaal het even naar onze sector:

1. De concepten en ontwerpen van onze sites moeten voorlopen. We proberen trendsetters te zijn, in plaats van trendvolgers.
2. Bruikbaarheid is een obsessie.
3. Ook schoonheid maakt een integraal onderdeel uit van ons werk - er moet een goed evenwicht zijn tussen technologie, design en usability.
4. Een website legt de onderliggende eigenschappen van het bedrijf en het product bloot - en is geen 'opsmukken' of 'mooi maken'.
5. Design van een website mag niet in de weg zitten en moet vooral de inhoud ondersteunen.
6. Een goede site legt de inhoud bloot - en probeert geen valse verwachtingen te creëren.
7. Een goede site is duurzaam; hij wordt gebouwd met flexibele content in gedachten. Het CMS ondersteunt een veranderende omgeving en een veranderende site.
8. Consequentie is essentiëel bij een gebruiksvriendelijke website. Knoppen zijn knoppen, acties hebben dezelfde kleur, links zijn onderlijnd.
9. Milieuvriendelijkheid start met groene hosting.
10. Design ondersteunt de inhoud, is liefst zelfs 'nul-design'. Less is more.

Als afsluiter nog een video-interview met Dieter Rams:

Dieter Rams geschreven door Bart in: webdesign

Tags: design, usability, visie

Naast het intensievere werk voor de MySQL-server kan dit ook een vertraging op de site opleveren. De data moet namelijk opgehaald worden, verwerkt worden en getoond worden aan de bezoeker.

Bij wijze van voorbeeld: Stel je voor dat je een array hebt met daarin de ID's van de vrienden van de huidige ingelogde gebruiker. Wat de meeste developers nu doen is een loopje starten en in deze loop de waardes ophalen per friend-ID.

 // loop friends
foreach($friendIds as $id)
{
  // get friend data
  $friendData = $this->db->getRecord('SELECT p.nick, p.avatar, ...
                                      FROM profiles AS p
                                      WHERE p.id = '. $id .';');

  // code to generate output
  ...
}
?>
  

In het bovenstaande voorbeeld hebben we dus een groot aantal queries (lees n+1), namelijk:

• 1 om de ID's van de vrienden op te halen
• 1 per vriend om zijn specifieke data op te halen

Met behulp van de MySQL-functie IN()  kunnen we dit terug brengen naar 2 queries.

 // get all profiledata at once
$profileData = $this->db->retrieve('SELECT p.nick, p.avatar, ...
                                    FROM profiles AS p
                                    WHERE p.id IN ('. implode(',', $friendIds) .');');

// loop profiles
foreach($profileData as $friend)
{
  // code to generate output
  ...
}
?>
  

Zoals je nu kan zien hebben we 2 queries:

• 1 om de ID's van de vrienden op te halen
• 1 om de data voor al deze vrienden in één keer op te halen

Opmerking: Ik wil er wel de nadruk op leggen dat dit een fictief voorbeeld is. De code is dus ook niet terug te vinden in de vernoemde websites. In dit voorbeeld zou het nog nuttiger zijn om niet alleen de ID's op te halen maar meteen de data, maar dit terzijde.

Queries uitsparen met behulp van IN() geschreven door Tijs in: webdevelopment

Tags: mysql, optimalisatie, php, tips

Daaruit kozen zij de meest gebruiksvriendelijke non-profit en de meest gebruiksvriendelijke commerciële website. Het publiek mocht ook stemmen.

Nadat de website van Ancienne Belgique al de Site van het Jaar won, én beloond werd als beste Web 2.0 site bij de CMS Awards, verkoos de jury van de Usability Awards de AB website tot meest gebruiksvriendelijke commerciële website van België.

Mijn artikel van vorige week over de ROI van een website en deze award zijn geen toeval.

Usability is een obsessie bij Netlash. We zijn er van overtuigd dat de bruikbaarheid van een website rechtstreekse impact heeft op de businessdoelstellingen van een bedrijf of organisatie.

Elke site moet een gezond evenwicht vinden tussen design, technologie en usability. We geloven dat op het kruispunt tussen die drie de 'business' van Netlash zit, en we zijn er zeker van dat daar ook de 'business' van onze klanten zit.

Een goed evenwicht tussen de drie factoren zorgt voor een goede website.

En dat betekent dat géén van de twee andere (technologie of design) belangrijker mag zijn dan bruikbaarheid.

Een bruikbare site leidt daarna ook onvermijdelijk naar een rendabele website, met een hoge ROI.

Gebruiksvriendelijke website geschreven door Bart in: usability

Tags: ab, awards, gebruiksvriendelijk, usability

Nu is het tijd om terug te blikken, en af te rekenen: werkt de site, haalt die de doelstellingen, en vooral: draagt die bij tot de bottom line van AB?

David Zegers, Directeur Communicatie en Ontwikkeling van Ancienne Belgique, presenteerde onlangs op Muziek Digitaal de afrekening.

Zijn presentatie vind je hieronder:

Ik zal er een aantal cijfers uitlichten:

• er kwamen 24.010 geregistreerde profielen op één jaar tijd
• gemiddeld 1581 profielen loggen in per week
• gemiddeld 5.955 unieke bezoekers/dag (vroeger: 4.185)
• die bezoekers blijven langer on site en genereren meer paginaviews

De binnenkomende trafiek via verwijzende sites is met 58% gestegen; trafiek via zoekmachines steeg met 67% (van 281.137 naar 445.076 bezoekers).

Opvallend: in 2008 was Facebook de 16e verwijzende site; in 2009 staat Facebook op een duidelijke 1e plaats (met 3x meer bezoekers dan de tweede verwijzer, stubru.be).

De algemene conclusie van David na 1 jaar nieuwe website: een verhoogde kwantiteit en kwaliteit:

• AB bereikt meer publiek dan vorig jaar omwille van verhoogde online aanwezigheid (via community sites en zoekrobots)
• er is meer interactie met en tussen het publiek
• AB biedt meer inhoud dan vorig jaar
  

Dit verhoogde verkoopspotentieel zorgde voor een duidelijk hogere verkoop: in oktober 2009 waren er al meer tickets verkocht dan in totaal 2008 (207.000 tickets in 2008, 212.000 tickets tot en met oktober 2009).

Even kort door de bocht: dit is een (geëxtrapoleerde) meerverkoop van 22%.

Voor AB was de vernieuwing van de website dan ook een zinvolle en succesvolle operatie.

Het succes van de website is in mijn ogen overduidelijk het gevolg van een enthousiast AB-team dat de tools die we in de website inbouwden op een doordachte en consequente manier gebruikte.

We zijn blij dat we AB konden helpen met deze duidelijke Return on Investment van hun website.

ROI van een website geschreven door Bart in: community

Tags: ab, cijfers, community, conclusie

Elke webbouwer kreeg ongetwijfeld al eens de vraag of drang om een slideshow te voorzien. Daar dit in de meeste gevallen een relatief kleine, echter alomtegenwoordige feature is, kan al snel even gegoogled worden naar een kant en klaar stukje Javascript. In de bijna 10 miljoen resultaten zal je echter nooit dat script vinden dat exact doet wat je verwacht, op de manier waarop je het wenst.

Omdat we bij Netlash graag volledige controle hebben over onze software, schreven we dan ook zelf een kleine JQuery plugin die heel eenvoudig aan onze meeste noden voldoet. Omdat we het web ook elke dag een beetje beter proberen te maken, delen we deze uiteraard.

• Download het script
• Bekijk een demo

Demo

• VolgendeVorigeSlideshow met vorige/volgende, met links per image

  

• Versnelde slideshow in random volgorde

  

Hoe installeer je het script?

1. Download JQuery op jquery.com en include deze in je document:
   <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>
2. Download deze plugin en include deze in je document, na het includen van JQuery:
   <script type="text/javascript" src="http://www.netlash.com/path/to/downloaded/jquery.slideshow.js"></script>

Hoe gebruikt je het script?

1. Plaats een image op de plaats waar je de slideshow wenst te tonen:
   <img src="http://www.netlash.com/path/to/1st/image.jpg" class="slideshow" />
   de class die ik hier op plaatste dient om deze makkelijk te kunnen selecteren via JQuery
2. Geef in het rel-attribuut van je image alle paden van de files mee, comma-seperated:
   <img class="slideshow" rel="/path/to/1st/image.jpg,/path/to/2nd/image.jpg,/path/to/last/image.jpg" src="http://www.netlash.com/path/to/1st/image.jpg" />
3. Inititiëer de slideshow:
   <script type="text/javascript"> $('.slideshow').slideshow();</script>

Meer?

Omdat we graag voorzien zijn op "ietsje meer", kan via enkele extra parameters je slideshow wat aangepast/uitgebreid worden.

Beschikbare parameters zijn:

1. images, als array: geef de paths van je afbeeldingen op als parameter in plaats van als rel-attribuut in de HTML.
2. links, als array: de mogelijkheid om aan elke afbeelding en link te koppelen waarnaar bij een klik wordt genavigeerd.
3. fadeTime: de tijd (in milliseconden) tussen het in/uit-faden van de afbeeldingen.
4. fadeSpeed: de tijd (in milliseconden) dat de fade-animatie duurt.
5. hookPrevious: de JQuery selector die hier wordt doorgegeven wordt gebruikt voor manuele navigatie doorheen de slideshow in omgekeerde volgorde (vorige).
6. hookNext: de JQuery selector die hier wordt doorgegeven wordt gebruikt voor manuele navigatie doorheen de slideshow in normale volgorde (volgende).
7. hookSpecific: de JQuery selector die hier wordt doorgegeven wordt gebruikt voor manuele navigatie doorheen de slideshow voor een specifieke afbeelding..
8. random: geef aan of de afbeeldingen in de slideshow in willekeurige volgorde dienen verschijnen
9. preload: hoeveel images moeten gepreload worden voor de huidige getoonde afbeelding

Voordelen?

1. Indien de bezoeker geen Javascript enabled heeft zal nog steeds de standaard-afbeelding zichtbaar zijn.
2. De slideshow kan makkelijk gepositioneerd worden zoals gewenst.
3. Een eenvoudige slideshow kan snel opgezet worden.
4. De code is eenvoudig en makkelijk uitbreidbaar.
5. Makkelijk meerdere slideshows op 1 pagina, elk afzonderlijk of samen configureerbaar.

Javascript slideshow geschreven door Matthias in: webdevelopment

Tags: javascript, jquery, slideshow

The slow query log consists of all SQL statements that took more than long_query_time seconds to execute and required at least min_examined_row_limit rows to be examined.

Maar omdat alle trage queries hierin terechtkomen is het niet altijd makkelijk om uit te maken welke nu juist de queries zijn die je best aanpakt.

Via de mensen van Openminds had ik vernomen dat er een script was die deze log gaat parsen en je kan vertellen welke queries juist aandacht vragen.

Het script analyseert de log door te gaan kijken welke queries er meerdere keren voorkomen. Daarbij vervangen ze de variabele data zodat je een goed beeld krijgt.

Hoe installeer je het script:

• Download het script
• Open een terminal en verplaats het script naar /usr/bin met onderstaand commando:
  sudo mv path/to/download /usr/bin/mysql_slow_log_parser
• Maak het script uitvoerbaar met onderstaand commando:
  sudo chmod +x /usr/bin/mysql_slow_log_parser
• Gebruik het script:
  mysql_slow_log_parser path/to/slow_query.log

Kleine disclaimer: Wil je je database en queries tot in de puntjes optimaliseren? Neem dan een specialist onder de arm, zij kunnen je bijstaan met raad en daad. Een database-specialist weet beter dan welke tool ook hoe je database of queries kan optimaliseren

MySQL Slow Log Parser geschreven door Tijs in: webdevelopment

Tags: mysql, optimalisatie, slow query log, tips, tools

Uiteraard zijn er veel overeenkomsten, en zijn beide gebaseerd op dezelfde beginselen (typografie, gebruik van ritme, spatiëring, witruimte...).
Maar: het fundamentele verschil zit hem in de drager - papier is an sich statisch, en web is an sich dynamisch.

Dit verschil zorgt er voor dat je in mijn ogen een duidelijk andere aanpak moet hebben voor beide media.

Aangezien papier op zichzelf niet dynamisch is, moet je de dynamiek in de layout van de inhoud stoppen. De layout van een affiche, poster, flyer moet in volle hevigheid van het papier spatten.
Bij web is dat niet zo. Daar zit de dynamiek in het medium al ingebouwd: je kan klikken, je hebt mouse-over effecten, er zijn eventueel bewegende stukken (video, animatie, jQuery-effecten) ...
Als je dan ook in het design van je webpagina heel veel dynamiek zal steken, zal dit clashen met de intrinsieke interactiviteit van het web. Die layout zal 'in competitie' gaan met de webdynamiek - en dat eindigt in een wedstrijdje 'om ter luidst'.

Het web wordt door gebruikers voornamelijk en liefst gebruikt als informatie-, transactie- en interactiemedium (lean-forward t.o.v. lean-back). Een website of webapplicatie heeft dan ook als taak om zijn informatie (onder welke vorm ook) zoveel mogelijk te ondersteunen en naar voor te laten komen. Opnieuw een reden om de layout niet te 'luid' te laten zijn: grafiek voor het web moet vooral functionele grafiek zijn, en gemaakt zijn om de inhoud zo goed mogelijk weer te geven en te ondersteunen.

Websites en webapplicaties zijn ook 'multiple use' - als je wilt inspelen op de informatie-,  transactie- en interactiezucht van de eindgebruikers, maak je sites die meermaals kunnen gebruikt worden, en waar mensen ook geneigd zijn om die meermaals te gebruiken ('verslavende websites').
Een site met een groot 'visueel wow-effect' zal de eerste keer misschien aanspreken - maar bij vaker gebruik zal dit saai worden, en zelfs in de weg komen te staan van het effectieve gebruik (consumeren van informatie, transacties uitvoeren, interactie aangaan).

Door de nadruk te veel te gaan leggen op dat visuele wow-effect, creëer je eigenlijk een tijdelijke website, met een beperkte levensduur. En websites moeten in mijn ogen toch minstens 3 jaar kunnen meegaan...

Daarom ben ik er van overtuigd dat bij het maken van sites je vooral moet denken aan een 'nul-design', een design dat ondersteunend en in de achtergrond werkt - en wel om volgende redenen:

• dynamiek moet in de interactiviteit van het web zitten, en niet vechten met de dynamiek van het ontwerp
• goeie websites zijn informatie- of transactiewebsites, waar het design deze informatie of transactie ondersteunt, en niet de overhand heeft
• bij meermalig gebruik wordt een visueel overweldigende site saai en zelfs storend
• er zijn weinig tijdloze sites met een 'visueel wow-effect'; deze voelen vrij snel gedateerd aan.

Wat met campagnesites, die vooral bedoeld zijn om éénmalig het wow-effect op te wekken? Dat is het soort sites dat wij niét bouwen - vooral omdat we niet geloven dat deze duurzaam bijdragen tot de businessdoelstellingen van bedrijven op het web.

Wat denken jullie?

Het visuele wow-effect in webdesign geschreven door Bart in: webdesign

Tags: conversie, webdesign

Zoals ieder goed webbureau maken we bij Netlash gebruik van een version-control systeem. In ons geval is dit SVN.

Subversion (SVN) is een versiebeheersysteem en in 2000 opgezet door CollabNet Inc. Subversion is de opvolger van CVS, een alternatief versiebeheersysteem. Subversion is uitgebracht onder de Apache License, waardoor het open broncode programmatuur (opensourcesoftware) is.

Als je dit combineert met grote projecten dan krijg je een solide basis om wijzigingen vlot bij te houden en te releasen. Het live zetten van grote wijzigingen kan soms een pak tijd in beslag nemen als je bijvoorbeeld geen SSH-acces hebt en dus alle files manueel moet uploaden. Een oplossing is om alles te gaan overschrijven. Dit heeft als nadeel dat dit even kan duren.

Daarom is het handiger om enkel de gewijzigde files te gaan uploaden. Maar dan moet je zelf een lijst gaan bijhouden van de gewijzigde files, of een lijst compileren aan de hand van je SVN-logs. Om dit proces te versnellen heb ik een Apple-script geschreven dat enkel de gewijzigde files gaat exporteren (met behoud van de folder-structuur).

Omdat we deze oplossing natuurlijk niet enkel voor onszelf willen houden kan je hier het script downloaden.

Download het script

Hoe installeer je het script?

1. Download het script.
2. Verplaats het script naar de Userscripts-map (/Users//Library/Scripts).
3. Activeer het Script-menu indien nodig door /System/Library/CoreServices/Menu Extras/Script Menu.menu te openen.

Hoe gebruik je het script

1. Update die lokale repository.
2. Start het script door in die Script-menu "SVN Export changed files" te kiezen.
3. Selecteer de folder die je SVN-repository bevat.
4. Geef de start-revision op. (de revision die op dat moment live staat)
5. Geef de eind-revision op. (in de meeste geval de laatste revision)
6. Selecteer een map waar de gewijzigde files moeten komen.
7. Upload de files.

Opmerking: het script bevat geen error afhandeling en is een alpha. Feedback is dus steeds welkom.

SVN Export gewijzigde files geschreven door Tijs in: webdevelopment

Tags: applescript, export, gewijzigde files, svn, tools