Sinds gisteren in de winkels. Hoera!
31626 items (21775 unread) in 36 feeds
Familie
(625 unread)
NetlashCollegas
(2305 unread)
NetlashStagiairs
(326 unread)
Fun
(13888 unread)
Eén van de grote problemen bij designwerk is dat je eigenlijk enkel kan schalen door te groeien. Een goed artikel van teehan+lax (je weet wel, van die iPad en iPhone PSDs) legt uit waarom ze niet meer mee doen aan een uurtarief.
Under this model companies have a billing capacity, which is a formula to determine the revenue your company can make in a year. Cost plus billing assumes labour is the primary unit of value in the system. You can only bill as many hours as you have. This means professional services firms can only ever add people or increase their rate to grow.
Lees hier het artikel.

Dit is een brief die de advocaten van de NMBS stuurden naar iemand die op zijn website linkt naar een andere pagina dan de homepage van de NMBS. Gevonden op Facebook:
Een brief van de advocaten van de nmbs naar iemand die op zijn website uitlegt hoe je een schadevergoeding moet vragen voor trein-vertragingen.
Daarbij legt hij uit waar je de formulieren op de site van de nmbs moet downloaden. De NMBS vindt dit niet leuk en dreigt met juridische actie.
Daarnaast kreeg student Yeri Tiete vorige week een brief binnen van de NMBS waarin zij eisten zijn service, iRail.be te stoppen.
Lorin Parys van Flanders DC verwoordt het mooi in de krant:
De NMBS zal nu ongetwijfeld uitleggen dat ze zelf ook een routeplanner aan het bouwen zijn. En dat is nu net het probleem. Niet alleen is dat rijkelijk laat, het is ook volstrekt onnodig. Als elke organisatie zelf zijn eigen toepassing maakt, kunnen applicatiebouwers niet langer databases van verschillende organisaties in één toepassing combineren. En daar ligt nu net de winst voor de consument. Niemand is geïnteresseerd in het nemen van een trein. Wat ik echt wil, is een film gaan bekijken in de stad. En al wat ik wil weten, is hoe ik snel van bij mij thuis naar de dichtstbijzijnde filmzaal geraak. De applicatie die ik dus zoek, combineert de info van De Lijn, het Vlaams Verkeerscentrum, de MIVB, de NMBS en Kinepolis. En alles wat een ontwikkelaar van een toepassing daarvoor nodig heeft zijn de zogenaamde meta-data. De informatie in zijn onbewerkte vorm.
Liefste overheidsbedrijven, omdat jullie jullie data achter slot en grendel houden, kan ik niet op mijn GSM zien wanneer ik welke trein en bus moet nemen. Ondertussen lukt dit al wel vlot in verschillende delen van de VS en UK. België mag niet achterlopen.
Jullie hebben alle data. Het openstellen van data gaat jullie niet minder winst opleveren, maar juist meer. Als mensen een makkelijke manier hebben om te zien dat ze maar bus 32 moeten nemen en dan 4 minuten in het station moeten wachten op de IC-trein Gent-Oostende, dan zijn ze minder geneigd om koning auto te nemen.
Waarom betalen we in België zoveel belastingen? Voor onze sociale zekerheid, maar ook voor de kwaliteitsvolle voorzieningen. Er zijn weinig landen met zo’n sporennetwerk als België. Jullie zitten op dit moment financieel in nauwe schoentjes, maar van die 3 miljard die jullie per jaar krijgen van de overheid, moet het toch mogelijk zijn om een API te bouwen met alle treinuren? En indien dat niet mogelijk is, stuur dan om te beginnen geen cease & desists te sturen naar mensen die jullie helpen.
Omgekeerde wereld, vind ik dat.
Flickriver is snel door iemand zijn Flickr scrollen. Een fijne user experience als u het mij vraagt. Bijvoorbeeld: mijn Flickr.
Die Seth Godin, ik heb hem lange tijd gemeden omdat hij nogal in herhaling viel, maar deze is er toch wel knal op.
Een nieuwe file comparison tool voor de Mac: Kaleidoscope. Fijne website, maar een beetje teveel geblaat voor een applicatie die bijna niets doet. Als je files vergelijkt met elkaar, is de kans groot dat je er ook veranderingen in wilt brengen. Een stukje tekst makkelijk van A naar B transporteren? Gaat niet.
Ik gebruik persoonlijk Deltawalker, lelijker en trager, maar tjokvol features die je eigenlijk wel nodig hebt.
Met al die advertenties heeft het wat weg van Smashing Magazine, NetTuts en meer van die brolwebsites; maar CSS tricks is effectief een goed geschreven website. Zie bijvoorbeeld het recente artikel Efficiently rendering CSS. Ook de screencasts zijn zeker de moeite waard voor de beginnende CSS’er.
Niets nieuws, maar desalniettemin een goede presentatie over het ontwerpen van iPhone en iPad applicaties. Door Martin van nclud. Via Tijs Vrolix zijn bits.
Niets nieuws, maar desalniettemin een goede presentatie over het ontwerpen van iPhone en iPad applicaties. Door Martin van nclud. Via Tijs Vrolix zijn bits.
Headliner bij Bright: Open source Facebook haalt veel startgeld op. In de reacties, één of andere domkop: “Het lijk me niet moeilijk om zoiets te programmeren, maar promotie is een ander verhaal…. ” [sic]. Deze jongen raad ik dit artikel aan.
De jongens van Diaspora zelf kunnen best eens dit lezen.
Om de mensen die denken dat ontwerp draait om prentjes tekenen en lettertypes uitkiezen eens met hun beide voeten op de grond te zetten: 93 pagina’s usability findings over de iPad, door Nielsen Norman Group. Een gratis download.
Kijk hier eens naar. Hier kan ik dus echt niet bij: een stuk software dat minder kost dan een broodje in de Panos, en dan wordt er bij vermeld dat het een beetje prijzig is.
Je kent de situatie wel: je ontwerp is eindelijk af, maar nu moet je het bestand doorsturen naar de developer. Je begint alles netjes in mapjes te zetten en komt erg veel lege layers tegen. Oplossing: in plaats van alles manueel te verwijderen, draai dit script.
(Om te installeren op Mac: plaats het bestand in /Applications/Adobe Photoshop CS4/Presets/Scripts)
Tim Bray over HTML5. Webapplicaties geschreven in HTML hebben inherente voordelen…
The discovery, in the early Web browsers, that reasonably-typeset text which embedded simple forms and hyperlinks, and came equipped with a “Back” button, hit the biggest 80/20 point ever in the history of User Interfaces, couldn’t have been predicted by anybody; but it’s as true today as ever.
…maar een echte applicatie schrijven is niet evident:
(…) building a really hot HTML5 application that takes advantage of the nice new features is not exactly easy. Even assuming that you’re using one of the dozens of clever toolkits, it’s still not a slam-dunk. In fact, compared to the level of support and tooling you get from XCode on the Apple side or the various pieces of Android IDE-ware, HTML5 development is a major pain in the ass.
One of my favorite phrases in the business world is full-service solutions provider. A quick search on Google finds at least 47,000 companies using that one. That’s full-service generic. There’s more. Cost effective end-to-end solutions brings you about 95,000 results. Provider of value-added services nets you more than 600,000 matches. Exactly which services are sold as not adding value?
Who writes this stuff? Worse, who reads it and approves it? What does it say when tens of thousands of companies are saying the same things about themselves?
Een column van Jason Fried over belabberde corporate teksten.
Ik weet nog heel goed dat ik de kneepjes van het vak geleerd heb door Web design with Web Standards, Transcending CSS en The Zen of CSS Design te lezen. Vandaag zie ik twee boeken passeren die me wel interessant lijken: iPhone App Development: the missing manual en HTML5 for Web Designers.
Omdat het te lang geleden is.
Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers — ESPECIALLY interruptions by coworkers — all knock you out of the zone. If you take a 1 minute interruption by a coworker asking you a question, and this knocks out your concentration enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble. If you’re in a noisy bullpen environment like the type that caffinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.
In navolging van Web-enabled not web, een kerel met gelijkaardige gedachten.
To single one out, try the ABC app on iPad. Much credit to ABC, but I doubt they have the best iPad developers out there. Yet their version one application is awesome, and a much better experience than their website.
Ik heb een hele tijd een Twitter account gehad. Ik vond dat wel leuk indertijd. Ik zag het als een soort dagboek van gedachten. Maar ook: een tool om interessante links met elkaar te delen. En om vragen te stellen. Van die vragen waarvan je weet dat iémand van die 800 mensen het wel gaat weten. Wie is de beste elektricien van Gent? Welk restaurant zoek ik best eens op?
En als je dan eens een groot bericht op je blog geschreven had, dan zette je het op Twitter, en meteen reactie. “Goeie post @wolfr!” - of: “nice http://bit.ly/x2020-900x”. Euhm ja, tof dat je het leuk vindt. Mag ik nu ook nog weten waarom?
Ik denk dat ik na een tijdje zo’n 5000 tweets had. Ik werd wakker en ik las op mijn telefoon de laatste nieuwtjes uit de VS. Om ze daarna bij een koffie op het werk te lezen in longform, met de RSS-lezer. Buiten een sigaretje roken? iPhone open en tweets lezen. Veel volgers. “Vriendjes”. Mijn eerste freelanceklanten: allemaal via Twitter.
En dan heb ik Twitter gedood. “Delete account?” - yes please.
Ik heb een hele tijd een World of Warcraft account gehad. Ik vond dat wel leuk indertijd. Een karakter ontwikkelen en door een online wereld lopen. Telkens nieuwe mensen “leren kennen”. Een gilde opstarten. Met 20 man door de gekste kerkers tuimelen en bazen verslaan. In de steden pronken met je laatste epics. Opkijken naar die kerel met zijn legendary zwaardenset (#).
Maar dan log je eens in op een dood moment om 3 uur ‘s nachts, en die kerel is ook online. En de volgende keer log je in om 7u ‘s ochtends voor het werk om je veilingen te checken. En die kerel is weeral online.
In World of Warcraft kan je een commando uitvoeren, dat commando heet “/played”, en als je dat uitvoert, zegt het spel hoeveel je het al gespeeld hebt. Op een bepaald moment stond er bij één van mijn mannetjes 80 dagen. En dan nog een mannetje met 30 dagen. Je hoeft geen wiskundegenie te zijn om te berekenen dat over een periode van een jaar dit 1/3 van je tijd is. Stel dat een mens 8u slaapt per dag, is dat dus de helft van je wakkere tijd. Elke dag.
Dan heb ik mijn World of Warcraft account gedood. “Delete account?” - yes please.
Waarom één van de grootste webdesignblogs (en organisator van talrijke webdesignconferenties) slecht CSS-advies geeft op hun website.
Waarom het hoofd van de MFA in Interaction Design haar — overigens zeer mooie — website niet werkt in Internet Explorer 8.
Waarom zowel de homepagina’s De Standaard als De Morgen vergeven zijn van afgrijselijke reclame.
Een nieuwe versie van de beste FTP client voor Mac OS. Met alvast deze interessante feature: “With the new Transmit Disk feature, you can now mount any of your favorites in the Finder itself, even if Transmit’s not running.” Bekijk het hier.
Twee jaar geleden schreef ik mijn gedachten neer over webapplicaties:
“I don’t intend to deliver the message that web applications are bad applications. I believe web applications are (were) a needed evolutionary step to building applications that integrate the web tightly in the way they work. We must take the good points of web applications to enhance existing desktop applications: (…)”
Het hoofdpunt van dat bericht was: “Don’t lock me up in my browser!”. Waarom gaan die verdomde webapps zo traag? Waarom heb ik hier geen toegang tot feature X die over heel mijn systeem beschikbaar is?
Vandaag is het niet anders. Ik was zojuist naar een muziekvideo aan het kijken, en ik had weer net hetzelfde gevoel: webapplicaties zijn een kreupele versie van desktop apps. Met VLC kan ik mijn video zetten waar ik wil op mijn scherm, en kan ik de video pauzeren met een shortcut.
Sterker nog: ik kan met de VLC remote applicatie vanuit mijn luie zetel mijn computer bedienen. En dan zijn er die handige features: float on top, een screenshot nemen van een frame, ondertitels, vertraagd of versneld afspelen, volume dat tenminste gekoppeld is aan je systeemvolume. Dingen die je misschien niet elke dag nodig hebt, maar als je ze nodig hebt, zijn ze er wel.
Alle dingen die ik opnoem kan ik niet met die flash embed van the XX. Ik kan die video vandaag slechts op 1 manier: een kreupele manier1.
Eerst was een browser een manier om statische informatie te bekijken: dan werd die informatie telkens dynamischer, om maar te zeggen – in 1994 was het enige dat mogelijk was een tekst zonder beelden online zetten. Nu speel je Ultima Online in je browser.
Google wilt van je browser een OS maken (video). Dat is allemaal een mooi idee, naar de toekomst toe, maar op dit moment voelt Google Docs gebruiken zo (grootte cirkel = snelheidsgevoel):

Ooit al eens een grote Excel file met duizenden kolommen en rijen geïmporteerd? Apple Numbers geeft een kleine krimp. Google Docs doet je browser bijna crashen, Firefox begint 2 Gigabyte RAM te zuipen om alles bij te kunnen houden, en jij zit daar dan maar te wachten.
Ik háát wachten op computers.
Het is dezelfde indruk die ik heb als ik een Java applicatie gebruik:

Ik ben geen programmeur, maar ik heb wel een goed vermoeden wat er allemaal achter de schermen gebeurt als ik een actie in een applicatie uitvoer. De simplistische grafische voorstelling hierboven is niet wat er effectief gebeurt als jij een knopje indrukt: dit is mijn indruk van het snelheidsverlies als je berekeningen door een Javascript engine sleurt.
Deze week speelde ik Ultima Online in mijn browser: dat is wel redelijk impressionant. Aan de andere kant kan je ook, op dit eigenste moment, World of Warcraft spelen, dat ook van het internet gebruikt maakt om veel impressionantere dingen te doen. Eenieder die al eens in een raid met 39 andere mensen Ragnaros heeft neergehaald weet wat ik bedoel. I digress.
En zo’n spel gebruikt die dikke videokaart die in je Mac/PC zit optimaal; continue 60fps en geen graphics die uit de jaren ‘90 zijn weggelopen. Heb ik al gezegd dat ik er niet tegen kan als een programma traag draait? En zeker niet als de reden is omdat er ergens iets in het proces voor een grote handicap zorgt.
Ik heb een fucking krachtige computer. Een dual core processor van 3.06 Ghz; 8 gigabyte ram. Een terrabyte om data in op te slaan. Dit is geen stoeferij: dit is de computer die je hebt als je nu naar de winkel stapt met 1250 euro voor een nieuwe computer. Als je een custom-made PC bouwt gaan je specs waarschijnlijk nog een pak impressionanter zijn. SSD-schijven anyone?
Marco zegt:
If you’re waiting a little longer than usual for a popular website to render its Dashboard or show you an encyclopedia page or tell you which of your old high-school friends have gotten fat, you’re probably waiting for some hard drives in a server somewhere.
Nearly every slowdown of modern computer usage is caused by a very fast computer that’s sitting around doing nothing while it waits for its hard drive to move its heads.
En die krachtige computer wordt dus helemaal niet gebruikt hé. Of wordt wel gebruikt, maar op een niet-optimale manier. Waarom kan ik op een resolutie van 2560×1440 fullscreen een 3D applicatie draaien zonder snelheidsverlies, en kan mijn PC geen 10 000 rijen renderen als het door Firefox moet?
Ik snap niet waarom ik 280 Slides zou gebruiken in plaats van KeyNote.
Ik snap niet waarom ik Mockingbird zou gebruiken in plaats van Balsamiq Mockups (dat trouwens eigenlijk ook niet performant is: hier Java niet de boosdoener, maar Adobe AIR).
De enige reden om die apps te gebruiken in plaats van hun desktop versies zijn de inherente voordelen van het internet. Neme het voorbeeld van een presentatie:
Dat zijn natuurlijk allemaal voordelen waar niets tegen in te brengen valt. Zolang er niets mis gaat2.
Ooit gaan web apps op een acceptabele snelheid draaien. Maar moeten we daarom eerst vijf jaar kreupele performance ondergaan om daar te komen?
Ik ben pro web-enabled applicaties. Die niet in je browser draaien, maar apart, en die gebruik maken van het internet om betere functionaliteit aan te bieden. Die geschreven zijn in een taal die optimaal werkt op het apparaat in kwestie. Een beetje zoals al het native apps vs. webapps verhaal op de iPhone en iPad. Ik denk dat iedereen hier akkoord kan gaan: native wint.
Zijgedachte: misschien ben ik gewoon een beetje verwend. We mogen godverdomme blij zijn met dat internet. Ingenieurs bij Google en Apple zijn wellicht elke dag bezig met dingen sneller te maken.

Een gratis applicatie voor de iPad (iTunes link), gemaakt door Nike, waarmee voetbaltrainers de resultaten en vorderingen van hun team kunnen testen. Gek wat er allemaal gemaakt wordt! Zie ook: iPad voor deejays.
Geen slechte blog om in de RSS-lezer te steken: DailyJS. Met jQuery plugin roundups, uitleg over Javascript de taal, en berichtgeving rond het belangrijkste frameworknieuws.
(Nota: dit bericht werd eigenlijk twee weken geleden geschreven, maar vond terug in mijn drafts; alsnog de moeite om te publiceren)
Dinsdag komt op mijn werk een iPad aan. Een iPad.
Als interface nerd kijk ik er zwaar naar uit om daar eens een paar uur mee te spelen en alle details te bekijken. Wees maar zeker dat er mooie details in gaan zitten.
Als je een iPhone hebt, moet je iPhone eens locken en unlocken. Kijk tijdens het unlocken naar de linkerbovenkant van je scherm. Als je carriernaam linksboven langer is dan het aantal karakters dat beschikbaar is (e.g. Mobile Vikings), schuift de naam van links naar rechts over de beschikbare ruimte zodat je de naam in zijn volledigheid kan lezen.
Of ga eens naar de klok/alarm applicatie, en klik dan op timer. Zet het aantal uren op 0, en dan op 1. En je merkt dat het woord “hours” uitfade, en infade naar “hour”. Want het is 0 hours; en 1 hour.
De el cheapo interface oplossing is telkens “hour(s)” te zetten. Dus 0 hour(s) en 1 hour(s). Maar Apple zorgt ervoor dat het detail klopt. Hun interfaces staan verder dan alle andere dingen die ik al gezien heb.
Mijn vader zei vandaag tegen mij, “Ja, die nieuwe HTCs, die staan toch even ver als de iPhone”. Ik vind dat dus niet hé. Een slimme mens zei: “Als je een Nexus One hebt, dan is dat de beste smartphone die je ooit gehad hebt, en denk je dat je een revolutie in handen hebt. Als je overschakelt van iPhone naar Nexus One heb je het gevoel dat je een middelmatige versie van een iPhone vast hebt.”
Maar goed. Genoeg over dat. Ik wou het hebben over dit:

Als ik eens kijk naar de websites die ik min of meer dagelijks gebruik zie ik dat:
Voor de iPad werd aangekondigd was er de video over de Mag+. Er was de demo van een Sports Illustrated op een tablet device. Dat heeft een heel tijdje een “wauw”-gevoel bij mij opgebracht. Mijn god - dit is de toekomst.
Maar nu heb ik mijn gedachten geordend en nu weet ik het eindelijk. Die demo’s zijn eigenlijk maar afgeleiden van de zingende, dansende websites.
Wat maakt de Mag+ beter dan in Safari naar NYTimes.com surfen? Het grafische aspect? De nieuwe interface die je moet leren?
Dan is er nog het gebrek aan advertenties in de demo. Tech demo’s houden natuurlijk weinig rekening met de echte wereld waarin adverteerders de publishing industry rechthouden. Maar ook de showoff van hun laatste werk (Popular Science magazine voor iPad) bevat niet echt reclame.
Hoe is dat winstgevend? Gaan ze 19 euro per “digitaal magazine” aanrekenen om uit hun productiekosten te raken?
Wat mensen vaak vergeten is dat die zingende, dansende websites ook 3 keer zo veel kosten, en je ze maar een keer kan gebruiken. Flauwe vergelijking: als je doel is om de kamer te verlichten, dan zijn de zingende dansende flash websites vuurwerk, en is een site zoals Rands een spaarlamp.
Nee, de waarde van een krant zit nog altijd in op een goede manier nieuws te brengen; de waarde van een magazine op een goede manier verhalen brengen. Alle grafische spielerei er nog aan toe.
In afwachting van “the definite iPad review after actually having used an iPad“: een beetje lectuur.
Beeld: Scrabble voor rijke mensen
Je gaat nooit apps kunnen maken die de kwaliteit van Apple apps evenaren; het web is niet zo cool want je kan er geen funky dingen op doen; maar eigenlijk zijn die fancy digitale magazines toch maar brol (en zo zijn we weer full circle).
Verder schrijft Alex Payne weeral slimme dingen; kunnen kleintjes ook met iPads werken, moet je eens naar 2:50 skippen in deze video om eens goed te lachen, en kan je hier terecht om eens te kijken wat voor interfaces mensen aan het bouwen zijn voor hun apps.
CSS related, leer deze code alvast uit je hoofd: <link rel=”stylesheet” media=”all and (orientation:portrait)” href=”portrait.css”>. Alsook: de beschikbare lettertypes op zowel iPhone als iPad.
Ah ja, en ik heb vandaag 5 seconden een iPad aangeraakt op kantoor (als je goed kijkt die je een hard werkende jongeman in de achtergrond). Bart schreef neer waarom hij denkt dat de iPad een succes gaat zijn.
De iPad is al een succes (uhm, 300 000 verkocht (ref#) na een paar dagen, dat is dus wel 0.1% van de Amerikaanse bevolking hé [Nota: dank voor de correctie]); of ik het de moeite vind voor mezelf, dat weten we binnenkort.
Over and out.
Joe Clark maakt netjes een punt over de mensen die zagen dat de iPad geen open platform is:
This was the weekend those of us with high standards lost their remaining residue of patience for ideologues who hyperbolize about open systems without actually creating something people want to use.
Khoi Vinh deelt zijn financiële cijfers.
Charts, schmarts. Let’s talk turkey, then: how about the money? Well it’s pretty easy to multiply the cost of Basic Maths by the number of copies sold (and subtracting the discount for the holiday sale) and arrive at a round figure of US$22,000 banked so far.
Ik ben niet bezorgd dat ik straks geen mooie boekenkast meer heb; in tegendeel, ik ben blij dat ik niet meer oneindig veel Billy’s in elkaar moet steken.
Ik ben wel bezorgd dat ik een dik boek koop (bijvoorbeeld het boek waar ik nu in bezig ben: Infinite Jest), er een stukje in lees, en mijn device weer aan de kant leg. De volgende keer dat ik het boek wil lezen — misschien twee jaar later — heb ik een ander device, met andere standaarden, en mag ik weer eens gaan betalen voor iets dat ik nota bene al heb gekocht.
Dit is dezelfde reden waarom ik geen muziek via iTunes koop.
That’s why I always get excited when the opportunity presents itself to work on a project together with another designer. You get to bounce ideas off of each other, you’re no longer alone to defend a valid suggestion you made to the client and if one designer is stuck somewhere, there’s a big chance the other one has the solution within 5 minutes, can point you in the right direction or says something that gives you that lightbulb moment you needed to continue working. (#)
Dit is waarom ik in een team samenwerk; er zijn niet alleen designers om ideeën op af te botsen, maar ook een informatiearchitect, en developers. Als er een probleem waar jij niet uit geraakt, weet die andere mens het wel.
We hebben een regel op kantoor, de “20 minuten” regel: als je een probleem hebt (dat je wellicht zelf kan oplossen), zoek het eerst zelf uit. Pas na 20 minuten mag je iemand anders te storen. Meestal heb je tegen dan het probleem gevonden, maar indien niet spendeer je geen uren aan de oplossing te vinden: je hebt genoeg mensen klaar staan om je te helpen.
Steeds meer sites gebruiken custom fonts met behulp van @font-face, bijvoorbeeld dive into mark; en Bobulate (mooi!).
De typograaf in mij zegt: “Fijn, eindelijk iets anders dan Arial en Verdana en Georgia!”. De usabilitymens zegt: de font rendering van Windows suckt. En dat is een probleem, want:
“By the way, the font you’ve picked is anti-alised in an extremely ugly manner on my Win7 laptop. If I triple the font size it starts looking OK.” (#)
De stelregel blijft voorlopig: als je custom fonts gebruikt, zorg dan dat je die gebruikt voor grote tekst. Hoofdingen, introparagrafen van 18px of groter; maar vooral niet voor broodtekst.
Soms kom je van die websites tegen die je terugbrengen naar die oude verwondering van door blijven klikken en klikken op dezelfde website. Van die sites met échte artikels en geen twee lijntjes brol bijeen gecopy-paste dat ik evengoed op delicious popular terug had kunnen vinden.
De site van de Russische design studio Art Lebedev is er zo één: lees bijvoorbeeld dit artikel over typesetting, of “design is war”; bekijk hun werk (van product design naar iPhone interfaces tot toiletten); of de winkel.
Fantastisch vind ik dat.
The phrase ‘I don’t have time for’ should never be said. We all get the same amount of time every day. If you can’t do something it’s not about the quantity of time. It’s really about how important the task is to you. I’m sure if you were having a heart attack, you’d magically find time to go to the hospital. That time would come from something else you’d planned to do, but now seems less important. This is how time works all the time. What people really mean when they say ‘I don’t have time’ is this thing is not important enough to earn my time. It’s a polite way to tell people they’re not worth your time.
Scott Berkun in the Cult of Busy. Ik ga volmondig akkoord.
I can’t tell you how many Subversion users have told me the following story: “We tried to branch our code, and that worked fine. But when it came time to merge back, it was a complete nightmare and we had to practically reapply every change by hand, and we swore never again and we developed a new way of developing software using if statements instead of branches.”
Joel Spolsky (die gezegd had dat hij niet meer ging bloggen?) in zijn laatste blogpost over version control.
Tim Bray verwoordt heel mooi wat ik haat aan mijn Jesus Phone:
The iPhone vision of the mobile Internet’s future omits controversy, sex, and freedom, but includes strict limits on who can know what and who can say what. It’s a sterile Disney-fied walled garden surrounded by sharp-toothed lawyers. The people who create the apps serve at the landlord’s pleasure and fear his anger.
Mijn visie op mobile web development, uitgelegd op het Netlash blog.
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.
Kort gezegd: hoe kan ik mezelf veel shit besparen, onzinnig werk vermijden, en een futureproof mobiele website maken. (Antwoord: concentreer u op Webkit)
Kodak 66X Instamatic Camera
Ik was aan het nadenken over persoonlijke evolutie; hoe je een betere ontwerper wordt. Als webdesigner loop je een beetje het risico je grafische inzichten te verliezen. Zeker als je, zoals mij, meer dan de helft van je tijd eigenlijk bezig bent met front end development, en niet met ontwerp.
Eén van de dingen waar ik een betere ontwerper van ben geworden is door mij simpelweg een fototoestel aan te schaffen. Naar een concert van Florence of van Blackbox gaan en die camera meezeulen. Soms als ik stap ben met mijn maten, of op een geek event zoals een Jong Tuig of Barcamp.
En dan thuis komen, en Lightroom openen. En alle foto’s die er een beetje mee door kunnen proberen rechttrekken. Als het echt mooi is, of wat er op staat is gewoon goed, dan zwier ik het op Flickr (trouwens de enige site waar ik een abonnement op heb; er zouden meer sites geld moeten vragen. Maar dat is een andere discussie).
Wees maar zeker dat dat helpt als een klant u een foto doorstuurt die onderbelicht is. En met Lightroom kunnen werken, leidt er toe dat die functies die je nog vreemd waren in Photoshop opeens duidelijk zijn. Aha, dat exposure menu dient daarvoor. En nu weet ik wat witbalans is. En kan ik de kleuren van een foto rechtrekken. Hoezee!
Kijk eens naar deze video:
Ik heb daar echt zwaar bewondering voor. De manier hoe alles gepresenteerd wordt, die overgangen, de kleine muziekjes er op gemonteerd.
Of die video’s van 50 people, 1 question: met een digitale spiegelreflex gefilmd, vermoed ik. Schone depth of field, en wat jazz erop gemonteerd. Prachtig. Ik word er zowaard lyrisch van.
Misschien moet ik maar eens wat spelen met Motion, of Final Cut. Of bij de Adobe Suite blijven met Premiere. En After Effects.
Ik moet dan wel beeldmateriaal hebben. De Flip camera die ik heb is wel een leuk dingetje, maar er gaat nooit iets kwalitatief uitkomen. Eén van die dikke camera’s (e.g. Canon 5D Mark II) kopen is budgettair een brug te ver. Heeft iemand ideeën rond een goedkopere oplossing om beelden te schieten?
Want ik wed dat ik het na een half jaar toch allemaal beu ben.
Maar, als ik dan later eens een javascriptanimatie schrijf, of zit te spelen met het <canvas> (zie: MDC), dan komt daar een betere animatie uit. Want dan heb ik weer iets bijgeleerd over overgangen, en flow, en bewegend beeld.
Alles hangt uiteindelijk aan elkaar.
Dit moet je gewoon gezien hebben. Er wordt volledig afgeweken van de klassieke websitestructuur: een groot open canvas om op te werken.
De flashjongens doen zo’n zaken al jaren; maar dit is een goed voorbeeld van hoe het wel moet. Mooi, toegankelijk, met kopieerbare tekst, leesbaar en linkable.
Qua interactieontwerp kan dit tellen. Bijvoorbeeld de manier waarop de navigatiepijlen je muis volgen. Ik ben overtuigd; en ik denk dat dit een hint is naar wat we de komende maanden gaan zien qua editorial design op het web.
Ik wou net een comment geven op een post van Dipfico, en ik zag de invulvelden van het reactieformulier niet staan.
Ik kijk even met Firebug en uiteraard: de kleur is #EEE, ofte “heel licht grijs”. Ik surf hier op een Macbook Pro met het scherm op 80% brightness. Het is op dit moment niet gekleurcalibreerd, denk ik.
En dat is de situatie van de meeste mensen. Een laptopscherm, een glazen scherm, een crappy scherm. Daar moet je rekening mee houden bij een ontwerp.
Ik hou wel van #AAA voor randjes van input fields. Net genoeg contrast. Niet voor niets de default kleur in Mac OS en Windows (XP).
Als ontwerper krijg je soms de vraag om iets te ontwerpen waar je niet helemaal achter staat. Denk aan een politieke partij, of een religieus instituut. Een campagnewebsite voor een campagne die je helemaal niets vindt. Een wasmachineproducent die gelooft de recessie te overwinnen met een online community waar iedereen zijn waspoedertips kan delen.
Moet je redeneren: ik zorg voor een kickass grafisch ontwerp, dat is mijn job, en verder doet het er eigenlijk niet toe voor wie ik werk?
Of is het eerder: al het werk dat ik doe heeft invloed op mijn volgend werk. Ik doe dit werk niet, want ik sta er niet achter. Ook al loop ik hier een duizend euro mis.
Karl Gillis had het er in zijn presentatie op Barcamp Antwerpen over: nee kunnen zeggen is belangrijk.
Ik ben er nog niet uit. Waar ik wel al uit ben is dat ik zoveel mogelijk wil werken voor projecten waar ik heel erg in geloof.
Misschien moet ik maar eens een keer nee zeggen.
Toen ik in San Fransisco was, kon ik op de telefoon zien wanneer de bus aankwam en waar ik moest afstappen.
In België moet ik naar de website van De Lijn gaan, en dan een heel formulier doorlopen, om dan aan de halte te komen en te zien dat de uren van de bus hélemaal anders zijn dan die op de website.
Google zegt: “Today we’ve added biking directions and extensive bike trail data to Google Maps for the U.S.”.
Soms hé, soms wou ik dat in Amerika woonde.
Na onlangs de Catalog in de kijker gezet te hebben, is het nu tijd voor een andere blog van mij. Voor de muziekliefhebbers is er The Popular Alternative: een Tumblr over muziekjes die ik wel de moeite vind.
Carnegie Mellon University Professor, Jesse Schell, dives into a world of game development which will emerge from the popular “Facebook Games” era.
De video vind u hier. Een interessante visie, ergens leuk, ergens ook heel erg droevig.
Ik ben geen goede verkoper. Ik ben daar, denk ik, een beetje te eerlijk voor. Ik kan geen onwaarheden (of eerder: halve waarheden) vertellen. Ik moet altijd de beide kanten van het verhaal illustreren. Wellicht ook de kant die me financieel minder uit komt.
Als een klant een formulier vraagt, dan zeg ik dat hij dat in Google Docs kan zetten, en dan kan embedden op de website. Alle resultaten komen live binnen in een Google Docs spreadsheet. Waar je dan met één eenvoudige klik nog eens grafieken van kan trekken ook. Die je dan met een klik verder kan embedden op een website, of de link krijgen om te delen met andere geïnteresseerden. Super.
Het is wellicht voordeliger voor mij om te zeggen dat ik een formulier kan bouwen. En daar dan een aantal uur werk voor aanrekenen. En zitten knoeien met validatie van velden, databases en andere dingen die al duizend keer gedaan zijn, en telkens weer opnieuw worden gedaan. Het wiel heruitvinden meneer. Dat doen we zo graag, als developers, ook al knikken we instemmend als het gaat over codeherbruikbaarheid en data portability.
Wel, mijn beste, dat Google Docs formulier trek je met gemak naar een CSV, dan hoef je weer geen exportfunctionaliteit meer te schrijven, en als er een extra veldje bijmoet in een bestaand formulier, dat is ook geen probleem. Alleszins geen probleem waar weer veel tijd en euro’s aan moeten verspild worden.
Maar pas op: hoe mooi en hoe goed de functionaliteiten van de Google docs form zijn, deze form werkt op 1 manier en niet op een andere. Je kan zo’n embedded form voor een heel aantal zaken gebruiken, maar vanaf je ook maar iets buiten de lijntjes wil kleuren, ben je eraan voor de moeite.
Bijvoorbeeld, je wilt niet dat er staat ‘powered by Google Docs’. Je wil de kleur en de stijl helemaal zelf kunnen bepalen. Je wil een formulier in 3 talen waar de output wel naar dezelfde spreadsheet gaat. Je wil een wekelijkse mail ontvangen met nieuwe data. Of je wil die data gebruiken om te koppelen aan andere data.
Al die zaken vereisen maatwerk. Maatwerk door een vakman. En dan moet je beginnen prullen. Dan moet je je vaardigheden als webdesigner -en developer uit de kast halen en ervoor zorgen dat het werkt, op sommige vlakken iets minder goed als die Google Docs, op andere vlakken dan weer veel beter. Maar wel exact wat de klant wil. Mooi ingepast in de website, in het systeem, in de workflow in kwestie.
Maar hoe maak je dan duidelijk dat dit gekke formulier 7 uur werk in beslag neemt, terwijl je daarvoor op een half uurtje een docs formulier had gemaakt? Voor een niet zo technische klant is een formulier van Google Docs of een custom formulier hetzelfde. Tot die uitzondering moet gebeuren. Dan zit jij vast met je Google Docs formulier; maar de vakman met zijn maatwerk kan nog alle kanten uit.
Ik vind het persoonlijk moeilijk om dat uit te leggen. Dat je een geprefabriceerd systeem kan gebruiken en snel resultaten kan hebben. Of dat je het zelf kan maken, en dat dat even gaat duren, en dat dat wel wat geld gaat kosten. De voor- en de nadelen.
Maar ik vind wel dat je dat moet communiceren. Eerlijk en geduldig. Dat duurt het langst. Maar het is wellicht ook het beste voor iedereen.
Collega Bert wees me vandaag op deze goede Git GUI tool: GitX. Op mijn Flickr een screenshot van de Compass repository.
T’is al van een paar weken geleden, maar moest je het gemist hebben, deze code swarm video is zeker de moeite. De moeite… voor nerds die veel te veel met version control bezig zijn!
Ik probeer een artikel van Paul Graham te lezen. Het is een lang artikel, een vlotte 8 pagina’s lang als je het zou uitprinten.
Zijn website staat links uitgelijnd. Ik zit echter in het midden voor mijn scherm. En na een tijdje begint mijn nek pijn te doen door het in een hoogst onnatuurlijke positie te lezen.
Ter illustratie, een wazige donkere GSM-foto:

Ik ga nog eens twee keer nadenken voor ik ooit nog een links website uitlijn. Wellicht is dit ook wel een beetje een luxeprobleem. Wreed content van dat scherm.
Open Safari en kijk eens naar SublimeVideo. En met de laatste Webkit nightlies heb je zelfs fullscreen video. Met op de planning Firefox-ondersteuning. Performante HD video. Mooi zo.
Hopelijk komen Apple, Google en Mozilla binnenkort overeen welke codec er nu gebruikt gaat worden (ref.). En dan moeten we ons binnenkort niets meer aantrekken van al die blue boxes.
O ja, er is ook nog Internet Explorer. Fuck.
Ik ging iets slim schrijven over dat iPad. En ik ging referreren naar de post van Alex Payne; en de goeie ideeën oplijsten zoals de iPad gebruiken op een stand om gitaartabs op te tonen; of in de keuken als receptenboek. Jeremy Keith heeft die post ondertussen al geschreven.
Hoe meer ik erover nadenk, hoe genialer dat ding gaat zijn. En niet alleen voor mijn moeder.
Een goede video om kennis te maken met de nieuwe UI-paradigma’s van de iPad.
Het situatie-afhankelijk keyboard vind ik een zeer interessant gegeven. Ik spendeer zelf heel veel tijd met het memoriseren van keyboard shortcuts om sneller te kunnen werken. Ik vraag me af hoe een custom keyboard voor Photoshop eruit zou zien.
Leuk om te weten is dat als je één van de nieuwe HTML5 input types gebruikt in je websites, bvb. <input type="email" />, je software keyboard lichtjes verandert als je dat veld invult. Op de iPhone verschijnt er bvb. een @-teken op het eerste toetsenbordscherm. Ik veronderstel dat dit ook zo gaat zijn op de iPad.
Deze blog somt een beetje mijn gevoelens op bij al het social media-geweld. Eentje over een concert dat iedereen lijkt te bekijken door een kleine lens. En een privémoment dat je eigenlijk gewoon niét deelt en voor jezelf houdt.
Bijvoorbeeld, voor een <div> met een achtergrond die zwart is en 70% opacity heeft:
/* Background */
background: rgba(0,0,0,0.7);
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#70000000,endColorstr=#70000000);
De syntax voor de filter vind u op MSDN. Lees zeker ook de syntax van de colorStrings.
T’is maar dat u het weet, maar alle zaken waar nu zo wauw over gedaan wordt in de moderne browsers zitten al 8 jaar in Internet Explorer. Soms op een brakke manier (zie: de shadow filter; font rendering), soms met een relatief goede implementatie.
Een kleine waarschuwing: over het algemeen worden filters afgeraden wegens performanceredenen. Dus een beetje opletten dat het de bedoel niet vertraagt. Situationeel een handigheidje dus.
Geniet nog van uw namiddag.
Vorig jaar schreef ik 2008 in Review – ik beschreef het als een experiment in magazinestijl-ontwerp voor het web. Daar is nu een opvolger voor: 2009 in review.
Voor mij is dit een leuke manier om terug te blikken op het voorbije jaar. Ik kan me eens volledig uitleven op ontwerpvlak; en het is een uitgelezen kans om technisch eens een aantal dingen te proberen die anders niet aan bod komen. De webmensen onder u zijn wellicht geïnteresseerd in de technische notes:
# 2009_REVIEW technical notes
## SCREEN VERSION
2009 in review uses:
* jQuery 1.4
* jQuery color, a plugin for jQuery for color transitions
* jQuery easing, a plugin for jQuery that adds easing
functions to the jQuery animate object
* jQuery sound, a plugin for jQuery that adds an easy API for playing sounds
The CSS is written in Sass, using Compass 0.10
* It includes modified files from Winston as a base.
* Any grids are built off Blueprint, included in Compass by default.
* Using the compressed output style, it automatically gets minified
### MOBILE VERSION
A check is done to see if the client is a mobile device.
This is accomplished using browser.php to check for user agent string.
If the client is a mobile device, custom stylesheets controlled by mobile.sass,
are loaded accordingly.
### LINKS
* Sass: http://sass-lang.com/
* Compass: http://github.com/chriseppstein/compass
* jQuery sound: http://bit.ly/5opkil
* jQuery easing: http://gsgd.co.uk/sandbox/jquery/easing/
* jQuery color: http://plugins.jquery.com/project/color
* Browser PHP class: http://tinyurl.com/crs4ah
* Winston: http://winston.wolfslittlestore.be
Thanks for your interest!
-W.
Moest u de link bovenaan gemist hebben: lees 2009 in Review hier. Reacties zijn meer dan welkom hieronder. Veel leesplezier!

Ik zoek illustraties in deze vintage, line drawing, 60s stijl. Wie kent er goede resources? Stuur me een mailtje als je er kent!
Aha, het jQuery team heeft een nieuwe versie uitgebracht. Nettuts+ legt in jQuery 1.4 Released: The 15 New Features you Must Know uit wat je moet weten.
Voor ontwerpers die af en toe een beetje javascriptanimaties schrijven zijn Per Property-easing (4) en Delay an Animation Queue (7) geweldige nieuwe features. Hoera voor het jQuery team!
De officiële info vind u hier.
Gisteren schreef ik een artikel over onderhoudbaarheid en performantie in CSS. Dit onderwerp ligt me nauw aan het hart, dus vandaag: het vervolg!
Dus. Waar waren we? CSS is van nature een ongestructureerde taal.
Gelukkig is HTML van nature wél een gestructureerde taal.
Neem nu volgend stukje HTML:
<div id="navigation">
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">Over Wolf's Little Store</a></li>
<li><a href="#">Freelance</a></li>
</ul>
</div>
Hier zit een duidelijke structuur in: een <div> met id="sidebar", die een ongeordende lijst bevat. Elk lijstitem bevat dan weer eens een link. Stel dat we dit eruit willen laten zien als een simpele navigatie door middel van CSS. Je zou waarschijnlijk iets schrijven dat lijkt op:
#navigation {
padding: 20px;
}
#navigation ul {
background: #EEE;
}
#navigation li {
border: 1px solid #DDD:
}
#navigation a {
display: block;
padding: 5px 10px;
}
Deze CSS kan je nog uitbreiden met vanalles, maar ik hou bewust het voorbeeld simpel. Quizvraag! Wat is er hetzelfde in elke regel?
Antwoord: elke regel is een declaratie die van toepassing is op #navigation. Een goeie truuk om je CSS te structureren, die ik van Bramus geleerd heb, is het volgende:
#navigation {
padding: 20px;
}
#navigation ul {
background: #EEE;
}
#navigation li {
border: 1px solid #DDD:
}
#navigation a {
display: block;
padding: 5px 10px;
color: red;
}
Door de indentatie maken we de structuur duidelijk: #navigation, met daarin een <ul>, met daarin <li>, en dan <a>.
Stel dat we nu een nieuw stukje aan onze website bouwen, het contentvlak. We breiden onze HTML uit:
<div id="navigation">
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">Over Wolf's Little Store</a></li>
<li><a href="#">Freelance</a></li>
</ul>
</div>
<div id="content">
<h1 id="titel_artikel">Titel artikel</h1>
<p>Inhoud lorem ipsum dolor <a href="#">sit</a> amet...</p>
</div>
En dus ook onze CSS:
#navigation {
padding: 20px;
}
#navigation ul {
background: #EEE;
}
#navigation li {
border: 1px solid #DDD:
}
#navigation a {
display: block;
padding: 5px 10px;
}
#content {
padding: 20px;
}
#content ul {
background: #EEE;
}
#content h1 {
font-family: Helvetica, Arial, sans-serif;
}
#content a {
color: black;
}
Door de techniek van indentatie kan je op het zicht zien: er zijn 2 hoofdblokken, #navigation en #content. Beide hebben specifieke regels.
Wat belangrijk is, is dat als ik iets aanpas in #content, dat dat geen invloed heeft op #navigation. Een principe dat programmeurs toepassen in objectgeoriënteerd programmeren.
De oplettende lezer ziet hier al meteen een optimalisatie. Zoals ik gisteren zei: er zijn eigenlijk twee factoren die het verschil maken tussen goede CSS en een rommeltje.
Er is de ene kant, die noem ik onderhoudbaar:
En de andere kant noem ik performant:
De performance kant is de kant die we kunnen optimaliseren. We kunnen deze CSS namelijk kleiner maken:
#navigation,
#content {
padding: 20px;
}
#navigation ul,
#content ul {
background: #EEE;
}
#navigation li {
border: 1px solid #DDD:
}
#navigation a {
display: block;
padding: 5px 10px;
}
#content h2 {
font-family: Helvetica, Arial, sans-serif;
}
#content a {
color: black;
}
In theorie is dit juist, echter is dit weer zwaar in strijd met de onderhoudbaarheid. Dat #navigation en #content allebei een padding van 20 pixels is louter toevallig.
Ja maar Wolf, je hebt gisteren gezegd, als je dezelfde waardes op 2 plaatsen moet aanpassen, is dat niet goed.
Klopt. Maar deze situatie is anders: er is geen relatie tussen #content en #navigation. Als het ontwerp van de website verandert, ga je voor #content moeten bekijken of de padding nog klopt. En je gaat voor #navigation moeten kijken of de padding nog klopt.
Dit is geen goed idee. Voor je het weet heb je een CSS file waar regel 4 verwijst naar iets dat invloed heeft op regel 921.
En als je dan nog eens browser-specifieke code schrijft in verschillende files wordt het helemaal leuk. En dan loop je tegen een deadline aan, en krijg je opeens een paar bug reports binnen. Van een site die nota bene live staat. Van een site waar toevallig die dag een grote budgetteringsvergadering over is. Oeps.
Mijn held in software is Joel. Joel heeft ooit voor Microsoft gewerkt en heeft al zoveel slimme dingen op het internet gezet dat ik uiteindelijk zijn boek heb gekocht. En het op enkele nachten heb uitgelezen.
Maak niet de fout dat dit een boek voor programmeurs is! Iedereen die voor een bedrijf werkt dat websites en/of webapplicaties maakt zou dit moeten lezen. Zelfs als je project manager bent, of informatiearchitect.
Dat terzijde. Eén van de bekendste artikelen, en meteen ook het beste artikel in het hele boek, is The Joel Test: 12 Steps to Better Code.
Stap vijf om betere code te schrijven is: Do you fix bugs before writing new code?
Er zijn verschillende soorten oorzaken van bugs. Voor het gedeelte waar we het nu over hebben, een degelijke frontend schrijven, zijn de meest voorkomende oorzaken:
Er zijn ongetwijfeld nog andere oorzaken van bugs. Maar, ik weet niet of het je opvalt, 3 van de 4 soorten oorzaken zijn de oorzaak van diegene die de code geschreven heeft.
Veel beter dan een bug oplossen is een bug voorkomen.
Hoe voorkom je deze bugs?
Rendering engine bugsHa. Hier heb je meteen al pech. Je kan deze bugs niet voorkomen. De rendering bug is er, en als je deze perfect normale CSS regel schrijft:
#sidebar {
float: left;
width: 200px;
margin-left: 20px;
}
Dan trigger je de double margin bug. Ik weet het, ik val in herhaling: ik heb deze bug gisteren al aangehaald. Waarom dit voorbeeld? Het is de gemakkelijkste IE bug.
Wat ik zeg klopt eigenlijk niet. Dit soort bugs kan je wél voorkomen. Maar dit soort bugs voorkomen verreist een uitgebreide kennis van alle rendering engines, hoe ze werken, wat er ondersteund wordt en wat niet, en alle quirks en speciale gevallen.
En dat kan je alleen maar leren door heel veel websites te maken en die bugs tegen te komen, en ze dan eigenhandig op te lossen. Eventueel met de hulp van het internet. Bijvoorbeeld door een vraag te stellen op Stack OverflowB, waar er meer dan genoeg mensen zitten die met plezier de allersimpelste CSS vragen voor jou beantwoorden.
Moet ik mijn websites dan bewust heel simpel vormgeven? Het antwoord is, zoals met zovele dingen in het leven, ja en nee. Je moet een balans vinden tussen de complexiteit van je vormgeving en de uiteindelijke uitvoering in HTML en CSS.
Een tabel om mijn punt te maken:
| # | Taak | Moeilijkheidsgraad |
|---|---|---|
| 1 | Slagschaduw op een vast beeld | Gemakkelijk |
| 2 | Slagschaduw op een <div> met vaste hoogte en breedte | Moeilijker dan 1 |
| 3 | Slagschaduw met 1-kanaalstransparantie (gif) op een <div> met vaste hoogte en breedte | Moeilijker dan 2 |
| 4 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met vaste hoogte en breedte | Moeilijker dan 3 |
| 5 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met dynamische hoogte en vaste breedte | Moeilijker dan 4 |
| 6 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met dynamische hoogte en breedte | Moeilijker dan 5 |
| 7 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met dynamische hoogte en breedte die potentieel dynamisch van hoogte en breedte kan veranderen via een Javascript animatie | Moeilijker dan 6 |
| 8 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met dynamische hoogte en breedte die potentieel dynamisch van hoogte en breedte kan veranderen via een Javascript animatie, en van opacity moet veranderen | Moeilijker dan 7 |
Moest je aan deze tabel nog een kolom Browser support toevoegen, en in elke cel zetten Werkt correct in A-grade browsers, dan wordt alles nog een graadje moeilijker. Moest je zeggen: werkt in Webkit based browsers, wordt alles opeens heel gemakkelijk.
De eerste methode om een slagschaduw te maken: je slaat een beeld op, geeft het beeld weer, en klaar is kees. Maar deze methode is in strijd met de onderhoudbaarheid, en ook met de performantie. Zeker als je meerdere beelden met telkens dezelfde schaduw hebt.
Opdracht 2 is ook gemakkelijk: je gebruikt het beeld als achtergrond. Ik ga niet in detail uitleggen wat je allemaal moet doen om 8 werkende te krijgen, maar als je daar geraakt, ben je volgende problemen teggengekomen, afhankelijk van welke oplossing je kiest:
Terug naar de vraagstelling: moet ik mijn websites dan bewust heel simpel vormgeven? Nee, als je weet wat je doet. Als je weet dat je binnen het budget en de tijd van een project oplossing 8 kunt uitvoeren, dan kan je met een gerust hart 8 zo vormgeven.
Dat veronderstelt natuurlijk wel dat jij het ontwerp gemaakt hebt dat je aan het coden bent. Dit is niet voor iedereen het geval. Dus tik die designer op zijn vingers als hij zaken doet die niet realistisch zijn.
Oplossing 8 is niet onmogelijk. Het kan. Maar een project heeft een budget. En een project heeft een deadline. Ik heb eens tegen een relatief technisch onderlegde klant volgende vraag gesteld: heb je graag dat ik een dag spendeer aan coole feature X of dat ik er vandaag voor zorg dat die fucking slagschaduw werkt in Internet Explorer 6?
Het antwoord was, uiteraard, werk aan coole feature X. Geluk kan soms toch in simpele dingen zitten.
Wrong referenceEen tigtal paragrafen terug gaf ik dit voorbeeld voor wrong reference-type bugs:
CSS code verwijst naar #lollipop, en in de HTML staat er #lollyPop
Phil Karlton, in de jaren stillekes van browserland verantwoordelijkvoor de architectuur achter wijlen Netscape, zei:
There are only two hard things in Computer Science: cache invalidation and naming things.
Over die cache invalidation kan ik niet meespreken — ik ben er zeker van dat er nu een paar programmeurs luidop aan het zuchten zijn, en zich een situatie herinneren waar cache invalidation hen uuuuren werk heeft gekost — maar wat betreft het naming gedeelte: een volmondige JA.
Soms is het duidelijk wat voor naam je iets moet geven. De inhoud gaat in #content. En de navigatie in #navigation. Dit zijn conventies die vele mensen gebruiken, die al jaren meegaan, die algemeen begrepen worden.
Meestal moet je rond de #content en de #navigation nog een wrapper steken om layoutredenen. Hier komt het naamgevingprobleem naar boven. Mijn wrappers van de hoofdinhoud heten meestal #main.
Wat voor een kutnaam is #main
Dat is een beetje als een stukje van je software “extras” noemen. Wie weet er nu waar je het over hebt als je #main gebruikt?
Wel. Er is geen oplossing voor het benoemen van dingen. Wat je wel kan doen om zoveel mogelijk misverstanden te vermijden, en zo dus bugs (of liever de oorzaak van bugs) te voorkomen is duidelijk afspreken binnen je team wat voor namen je gaat gebruiken.
Dit heb ik even gepikt van onze bedrijfswiki. Ik heb het zelf geschreven, en de basis is gelegd door meneer Dextro, dus dat mag.
Gebruik logische Engelstalige namen voor classes en id’s.
Vermijd zoveel mogelijk benamingen zoals #left en #right, deze hebben de neiging te veranderen en dan niet meer te kloppen achteraf e.g. #right staat dan links, en het geheel wordt verwarrend
Actieve elementen worden aangeduid met ‘selected’ op het li-element. Maak gebruik van descendant selectors in je CSS om deze aan te duiden (e.g.: #navigation li.selected, #subnavigation li.selected ).
Alle classes en ids in camelCase, de eerste letter een kleine letter
Als iedereen deze regels netjes volgt, dan komen er minder problemen voor. Natuurlijk gaat het gebeuren dat je een plugin gebruikt die geen camelCase classes en IDs gebruikt. En iemand gaat het nodig vinden zich totaal niet aan de regels te houden.
Maar! Hoe meer mensen deze regels volgen, hoe minder bugs. Hoe meer je team samenwerkt, hoe beter je op elkaar afgestemd geraakt. T’is een beetje zoals een voetbalploeg.
Syntax errorsOver syntax errors kan ik kort zijn: valideer je HTML en CSS regelmatig op syntax errors, zeker als je een groot stuk code hebt geschreven.
Over de HTML validator kan ik nog een uurtje doorgaan, maar dat leg ik even buiten de scope van dit artikel.
SpecifitySpecifity is één van die dingen in CSS waarvan je denkt dat iedereen weet hoe het werkt, en als je dan eens een vraag erover stelt, weet eigenlijk niemand hoe het werkt.
Als je specifity begrijptD, begrijp je ook waarom:
* { margin: 0; padding: 0; } E!important gebruiken als het niet nodig is een slecht idee isIk ga nog eens iets herhalen:
Er zijn ongetwijfeld nog andere oorzaken van bugs. Maar, ik weet niet of het je opvalt, 3 van de 4 soorten oorzaken zijn de oorzaak van diegene die de code geschreven heeft.
Ik zie je gedachten al verdwalen naar de slechtste CSS’er die je gekend hebt in je carrière.
Het is gemakkelijk om andere mensen de schuld te geven voor slechte code. Echter: verbeter de wereld, begin bij jezelf.
Met een deadline in het achterhoofd is het soms moeilijk om het grote plaatje in het oog te houden. Maar je schiet jezelf in de voet door geen nette code te schrijven, de regels van gestructureerde CSS conveniently even te vergeten.
Ik weet het, want ik heb genoeg projecten waar ik dagelijks inkom waar ik nu van denk: what the fuck were you thinking?. En dat zijn dan nog projecten waar ik helemaal alleen de CSS van geschreven heb.
(Ik spendeer zo nu en dan een uurtje aan het herschrijven van de CSS van grotere sites, en categoriseer mijn tijdsregistratie dan onder “IE6 bug”, maar niet tegen mijn baas vertellen hé.)
Misschien moet ik maar eens dieper ingaan op Sass/Compass, een CSS framework dat eigenhandig allerlei structurele CSS problemen oplost door CSS te beschouwen als een programmeertaal. Misschien.
Voetnota’s
Als je ooit al eens een grote site hebt onderhouden, ken je het volgende probleem wellicht: na een tijdje wordt je CSS file zo groot dat er niet veel structuur meer in zit. Ik onderhoud enkele grote sites waar 5000 lijnen CSS code geen uitzondering zijn. In dit artikel: tips om je CSS te structureren op een onderhoudbare manier, zonder de performantie van je websites uit het oog te verliezen.
Ik hoor de claims al: “5000 lijnen zegt u? Gek! Dat is toch veel te veel? Ik kan dat op minder hoor.” Die line counts zeggen natuurlijk niet echt veel, zeker als je coding style in achting neemt. Het hoe en waarom wordt in dit artikel uitgelegd. Volg even mee.
Sommige mensen schrijven hun code zo (inclusief mezelf):
#globalWarning {
background: #B5121B;
color: #FFF;
position: fixed;
top: 0;
left: 0;
font-weight: 700;
z-index: 3000;
}
Andere zo:
#globalWarning {
background: #B5121B; color: #FFF; position: fixed; top: 0; left: 0; font-weight: 700; z-index: 3000;
}
Of zelfs zo:
#globalWarning { background: #B5121B; color: #FFF; position: fixed; top: 0; left: 0; font-weight: 700; z-index: 3000; }
Als je elke regel op één lijn schrijft kom je uiteraard bij minder lijnen uit. Maar dat doet niet veel goeds aan de leesbaarheid van de code. Ook kan je de CSS file niet meer gemakkelijk naast je HTML file op hetzelfde scherm. Deze coding style heeft natuurlijk 1 groot voordeel: je CSS is kleiner omdat er minder bytes verspild worden aan whitespace characters. Hier komen we later in het artikel nog op terug (minifyen)
Er zijn eigenlijk twee factoren die het verschil maken tussen goede CSS en een rommeltje:
Dan is er de performance kant van de zaak:
Die performance kant van de zaak maakt op zich weinig uit als je een klein blogje draait waar je vrienden lezen wat je te schrijven hebt over je kat. Maar hoe groter je site, of hoe meer bezoekers je hebt, begint dit wel van belang te zijn. Waarom moet je hier tijd in steken? De redenen liggen voor de hand:
Naar het schijnt scoor je ook een beetje hoger in Google, maar daar zijn nog geen cijfers over C. Deze performance kant clasht met de zaken die je wil van je CSS: onderhoudbaarheid, structuur. Laat ik beginnen met een voorbeeld. Dit is de layout CSS voor een sidebar:
#sidebar {
width: 200px;
float: left;
margin-left: 20px;
}
De oplettende lezer die veel over browserbugs weet denkt bij het lezen van vorig stukje code “Jaja, double margin bug.”. Inderdaad beste lezer, deze code triggert naar alle waarschijnlijk de IE6 double margin bug D. Om deze op te lossen doen we zo:
#sidebar {
width: 200px;
float: left;
margin-left: 20px;
_margin-left: 10px;
}
Opgelost!
Of toch niet? Wat is er allemaal mis met bovenstaande code?
Deze code beter maken in enkele stappen:
#sidebar {
width: 200px;
float: left;
margin-left: 20px;
_display: inline;
}
Nu zijn we al af van (1) 2 values moeten aanpassen als de marge verandert. Nu probleem 2 nog… we maken gebruik van een fout in de CSS parser. Wat is hier fout aan? Stel dat er morgen een browser uitkomt die dezelfde fout in de CSS parser heeft, namelijk regels die beginnen met een underscore toch uitlezen, maar die de double margin bug niet heeft, dan klopt de marge niet meer.
Voor wie er nog is, het wordt interessanter dan dit. Ik wil je intelligentie niet beledigen; natuurlijk weet je wat de double margin bug is. En dat CSS hacks niet kosjer zijn. Dat je je Internet Explorer specifieke code in conditional comments moet zetten.
Dus laten we dat doen:
/* Code contents of file 1: screen.css (every browser) */
#sidebar {
width: 200px;
float: left;
margin-left: 20px;
}
/* File2: ie6.css (IE6 only) */
#sidebar {
display: inline;
}
Proper zo! Maar… met dit te doen, verliezen we een stukje van de onderhoudbaarheid. Neem nu volgende code:
#shazam {
opacity: 0.4;
}
Quizvraag: in welke browsers gaat dit werken? Het antwoord staat in de volgende paragraaf in witte tekst. Selecteren dus om het antwoord te zien.
A: Safari vanaf Safari 3, Firefox vanaf Firefox 2, Opera vanaf Opera 9
Opacity is eigenlijk een zeer goed voorbeeld om mijn punt verder uit te leggen. Er zijn heel veel verschillende manieren om opacity te verkrijgen en elke browser heeft zo wel zijn eigen manieren. De syntax voor opacity verschilt zelfs tussen IE7 en IE8. Meteen ook een reden om deze timesaver E te gebruiken.
Dit moet je schrijven voor cross browser opacity:
#shazam {
opacity: .75; /* Standard: FF gt 1.5, Opera, Safari */
filter: alpha(opacity=75); /* IE lt 8 */
-ms-filter: "alpha(opacity=75)"; /* IE 8 */
-khtml-opacity: .75; /* Safari 1.x */
-moz-opacity: .75; /* FF lt 1.5, Netscape */
}
Ja. Waar zijn die mensen die hun hand opstaken toen ze zeiden dat je IE specifieke CSS in je conditional comments moet steken?
Heb je dan ook specifieke stylesheets voor Firefox 1, Firefox 1.5, Netscape, Opera 7, Opera 8, enzovoort?
Ik heb deze opacity-regel van Snipplr F geplukt. De websites die ik maak bij Netlash en ook binnen mijn eigen bedrijfje, worden getest in alle A-grade browsersG. Laten we deze regel even herschrijven met A-grade support in het achterhoofd:
/* Code contents of file 1: screen.css (every browser) */
#shazam {
opacity: 0.75; /* Standard: FF gt 1.5, Opera, Safari */
}
/* Code contents of file 2: ie6.css (IE6) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
/* Code contents of file 3: ie7.css (IE7) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
/* Code contents of file 4: ie8.css (IE8) */
#shazam {
-ms-filter: "alpha(opacity=75)"; /* IE 8 */
}
4 declaraties over 4 verschillende files? Dat is niet meteen onderhoudbaar. Dat moet beter.
We kunnen al 1 van de files weghalen door onze timesaver te gebruiken. We verwijderen ie8.css, en we zorgen we dat de in de <head>-sectie van onze website het volgende staat:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
Goed. nog 3 files over:
/* Code contents of file 1: screen.css (every browser) */
#shazam {
opacity: 0.75; /* Standard: FF gt 1.5, Opera, Safari */
}
/* Code contents of file 2: ie6.css (IE6) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
/* Code contents of file 3: ie7.css (IE7) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
In deze code komt weer hetzelfde probleem als bij de eerste oplossing voor de double margin bug: we moeten 2 waarden aanpassen als er iets wijzigt. Als er beslist wordt de opacity te verhogen of te verlagen, moet iemand er aan denken dat dit deze regel herhaald wordt in ie6.css en ie7.css. Je mag nooit veronderstellen dat jij de enige bent die de code van een project gaat onderhouden (binnen de context van een commercieel project voor een klant in een team).
Als je ooit eens een paar uur bezig geweest met een bug uit andermans code te halen, om dan tot de conclusie te komen dat het geen bug was maar een stukje IE specifieke CSS dat niet geüpdatet is met een verandering, dan lijkt volgende code niet eens zo slecht:
#shazam {
opacity: 0.75;
_filter: alpha(opacity=75); /* IE6 */
:filter: alpha(opacity=75); /* IE7 */
}
De “underscore” hackH heeft ook een variant voor IE7: de “colon hack” I. Om IE6 en IE7 tegelijk te targeten kan je dan ook nog eens dit gebruiken:
#shazam {
opacity: 0.75;
*filter: alpha(opacity=75); /* IE6 and IE7 */
}
Maar zoals eerder gezegd: niet doen! Nog eens: stel dat er morgen een browser uitkomt die dezelfde fout in de CSS parser heeft, gaat die deze regels lezen. En dan ga je onvoorspelbare code krijgen. En als er iets is wat je niet wil in web development, is onvoorspelbare code.
Wat is er wél zeer goed aan bovenstaande notatie? Er is context. Je kan onmogelijk de value van opacity veranderen zonder te merken dat er onder de value ook nog een IE specifieke value staat. Of je bent echt aan het slapen. Hoe combineren we context met voorspelbare code? Ik doe het als volgt:
/* Code contents of file 1: screen.css (every browser) */
#shazam {
opacity: 0.75;
/* @see ie6.css and ie7.css for browser specific CSS for this rule */
}
/* Code contents of file 2: ie6.css (IE6) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
/* Code contents of file 2: ie7.css (IE7) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
Deze methode zorgt ervoor dat je CSS doet wat de initiële voorwaarden waren:
Echter, deze methode clasht met:
Dit is de commentaar bij de CSS van de verschillende knoppen in tagger.fm:
/*
Winston 0.3 buttons - for irregular background use
--------------------------------------------------
There are a three kinds of main buttons in this project:
To create a button use:
The standard markup is as follows:
***
EXAMPLE <a href="#" class="button">
<i> </i>
<span>Button text here</span>
<b> </b>
</a>
***
Silver gradient background, blue link text = .button
ICONS AVAILABLE:
With play icon on the right hand side
= .button .buttonIconLeft .buttonIconPlay
Silver gradient background, with dropdown icon
= .button .buttonIconRight .buttonIconDropdown
These buttons work on any background.
PNGs are substituted by GIFs in IE6
***
All of the button images are in a single sprite.
The graphics shown are defined via background positioning.
***
To position the buttons, use the button holders
EXAMPLE <div class="buttonHolder">
<a href="#" class="button">
<i> </i>
<span>Button text here</span>
<b> </b>
</a>
</div>
***
Default buttons will float to the left in a button holder.
To make them float to the right, substitute the holder class for buttonHolderRight
EXAMPLE <div class="buttonHolderRight">
<a href="#" class="button">
<i> </i>
<span>Button text here</span>
<b> </b>
</a>
</div>
***
The <b> and <i> elements are used to:
a) provide a hook for icons on the left hand side (b) and the right hand side (i)
b) prevent transparent graphics overlaying each other when using standard sliding doors
c) to easily adjust the side paddings
This example will produce a "play" button:
EXAMPLE <div class="buttonHolderRight buttonIconRight buttonIconPlay">
<a href="#" class="button">
<i> </i>
<span>Button text here</span>
<b> </b>
</a>
</div>
***
*/
Woeps. 1930 bytes ofte 1,8 kilobyte aan comments.
Ik moet nu wel zeggen dat dit mijn meest extreme voorbeeld van commentaar is. Maar dit dient om mijn punt te illustreren; onderhoudbaarheid clasht met performance.
Dat probleem valt ook op te lossen. Maar het is ingewikkelder. Zoals Yahoo dat zegt: je moet je CSS minifyen. Eén manier om dat te doen is met regular expressions. Een andere manier is je CSS door een compressor draaien, zoals de YUI compressor. Uiteindelijk zijn dat ook maar een hoop regular expressions.
Hoe je dit juist doet en hoe die regular expressions werken is buiten de scope van dit artikel.
Je maakt dus 2 versies van je CSS files: een werkversie, en een minified versie. Laad de minified versie in op de live website. Als je verderwerkt aan de website, werk je verder in de werkversie. En als je klaar bent, draai je je scripts, en zet je de files live. Klaar is kees.
Euhm. Niet echt. Als ik serieus aan één van mijn grotere projecten op het werk aan het werken ben dan zijn hier een aantal problemen:
Gelukkig is hier óók een oplossing voor.
Proficiat aan diegenen die al hier geraakt zijn in het artikel. We zijn er bijna.
Als je het live zetten van je sites automatiseert, kan je zorgen dat dit een stap is in het proces van een site live zetten.
De old school manier om veranderingen live te zetten is naar je FTP client gaan, naar de juiste map gaan, en de bestanden overschrijven.
(Ik veronderstel in alles dat je je website lokaalt ontwikkelt, via een lokale webserver, en een lokale database. En dat je version control gebruikt. Als je beide niet doet ben je slecht bezig. Niet enkel volgens mij, maar ook volgens Joel J.)
De betere manier is zorgen dat je je website live kan zetten met een druk op de knop. In de praktijk betekent dit: een script draaien dat:
En dat laatste bestaat nog niet in ons huidig proces. Stap 2 van de Joel test is “Can you make a build in one step?”. Het antwoord is voorlopig nee. Een tool zoals CapistranoK kan helpen met dit proces. En dat is een verbeterpunt dat ik zo snel mogelijk wil doorvoeren voor de grote sites die ik onderhoud.
Voor mijn privéprojecten gebruik ik Compass L en SassM. Compass bevat een compiler met opties. Voor je een site live zet kan je de opties in je compiler veranderen naar “compressed CSS”. Die haalt automatisch de comments en whitespace weg. In een ideale wereld kan ik Compass gebruiken voor al mijn werk.
Maar: hier komt weer regel 2 naar boven: “Je CSS is duidelijk en goed gedocumenteerd, zodat anderen die hierin werken niet verloren lopen en kunnen werken”. Helaas heeft Compass een stijle leercurve. En als er een stagair binnenkomt op Netlash moet die ook in mijn code kunnen werken. Al mijn collega’s moeten mijn code begrijpen en kunnen aanpassen. Ik kan geen 14 mensen verplichten een nieuwe taal te leren omdat dat mijn leven gemakkelijker maakt.
Zoals de mensen van pinboard.in dat zo mooi zeggenN: “A rule of thumb that has worked well for me is that if I’m excited to play around with something, it probably doesn’t belong in production.”
Dat was het voor vandaag. Proficiat aan diegenen die hier zijn geraakt, en deel zeker jullie maintenance ervaringen in de reacties. Over and out!
Voetnota’s
In Illustrator kan je makkelijk meerdere strokes toevoegen, in Photoshop kan je dit faken via deze techniek. Past wel bij ontwerp van het soort Pimp my Ride:

Ik linkte al eens naar Alex Payne, en de mens heeft ondertussen nog meer dingen geschreven waarvan ik vind dat u ze moet lezen: Don’t be hero, Criticism, Cheerleading and Negativity. Telkens een heldere uitleg.
En voor de TextMate gebruikers is er How I use TextMate.
De telefoon van Google, gepresenteerd via een Flash website die nog eens goed gemaakt is ook. Voor de interface ben ik niet helemaal gewonnen (vergeleken met de iPhone) en helemaal gewonnen (vergeleken met Windows Mobile). Helaas niet verkrijgbaar in België.

Vandaag ontdekt: een elegante kleine applicatie om te rekenen. Vul links iets in en rechts komt er en resultaat uit. Je kan gemakkelijk meerdere lijnen berekenen en de resultaten laten staan (zoals op uw goede oude Texas Instruments rekentoestel). En eigen formules ingeven om uw belastingen te berekenen. Of de gulden snede.
Er is natuurlijk Numbers en Excel, maar dit is zo eentje om op je tweede scherm open te laten staan. Sweet. Een trialversie downloaden kan bij de mensen van Acqualia.
Lieve mensen, je kan me nog altijd bereiken op allerlei manieren, maar niet meer via direct messages, @replies en dergelijke op Twitter. Prettige feestdagen!
Dankzij Birthday exporter, die je alle verjaardagen van je feestboekvriendjes teruggeeft in iCal formaat. Kan tegenvallen bij overdreven veel “vrienden” op Facebook. YMMV.
Ik heb veel te veel in InDesign gewerkt vorige week, als je dan iets ziet als dit dan is er maar één woord: respect! Ik heb er al over getwit maar deze mag wel in het permanente archief: Behind The New York Times Magazine’s Redesign.

Twee weken geleden was er de touch magazine demo van Sports Illustrated. Zij zijn blijkbaar niet de enigen die met gelijkaardige concepten bezig zijn.
Blijkbaar moest er eerst een Kindle en een iPhone zijn om tot dit te komen. Maar het ziet er wel machtig uit. De demo is zeer leuk uitgevoerd, rustig, stijlvol. Een beetje in de stijl van Helvetica de film.
Jeff Croft stelt zich volgende vraag: klanten vragen steeds meer om applicaties in plaats van websites. De CMS-oplossingen die over het algemeen gebruikt worden (EE, Wordpress, custom CMS) zijn allemaal gericht op content-heavy websites en niet op applicaties. Werken design-heavy agencies zoals Happy Cog dan met een externe partner? Hebben ze ergens in een kast een leger backend developers verstopt?
De discussie in de comments is zeker interessant: Martin Ringlein van nclud zegt dat ze net hun eerste developer aangenomen hebben. Andere bedrijven, zoals het bekende Britse ClearLeft, werken duidelijk met vaste partners (OmniTI).
Waarom deze post? Ik ben geïnteresseerd in het Belgische landschap. Om te beginnen: bij Netlash doen we alle development in-house, met uitzondering van Flash. De drie designers zijn telkens ook front-end developers (met variaties in Javascript kennis). Er zijn zeven backend developers (wederom met variaties in Javascript kennis); m.a.w. er zijn meer dan dubbel zoveel developers dan designers. Als een Flash-oplossing de beste oplossing is voor een specifieke functionaliteit (e.g. een muziekspeler, video) doen we beroep op een klein Flash development bedrijf.
Naar de buitenwereld komen we naar buiten als een webdesign -en developmentbedrijf; echter wordt dat development stuk vaak vergeten. Is het omdat het makkelijker is om alles gewoonweg webdesign te noemen? Hoe zit het bij onze concullega’s bij Internet Architects, Design is Dead en andere?
Applicatie die me voorbije week het meest tijd heeft bespaard: Deltawalker. Een fijne tool om files en folders met elkaar te vergelijken.
Soortgelijke functionaliteit zit standaard in Zend Studio en ik vermoed ook Eclipse, maar den dezen zweert nog altijd bij TextMate. Ik schrijf dan ook zelden PHP.
Bedankt Bramus voor de tip!
Of je het nu wilt of niet, als webdesigner komt er een punt dat je een HTML nieuwsbrief moet ontwerpen. David Greiner van Campaign Monitor geeft je in het laatste artikel van 24ways goede tips. Check zeker de tip onder de hoofding “links”.
De kleur van het jaar 2010 is turkoois, ofte PANTONE® 15-5519 Turquoise. Het is maar dat u het weet als u geen inspiratie meer heeft.
Panic, makers van Transmit en Coda, hebben nu een blog, en die ziet er op zijn zachtst gezegd geweldig uit.
Collega’s These Days zoeken met een originele hacking challenge nieuwe collega’s. Fijn tijdverdrijf. Als je denkt dat je genoeg front end developer skills hebt mag je ook altijd eens aankloppen bij Netlash.
Aan het sukkelen met een Internet Explorer 8 bug, de wanhoop nabij, bijna klaar om iemand neer te schieten? Wanhoop niet, uw vriend is volgende meta-tag:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
Je kan argumenteren dat je zo de IE8 features niet gebruikt, ik zeg: ik werk aan een groot aantal websites en kan die onmogelijk opnieuw testen in alle browsers telkens ik een verandering doorvoer. Meer tijd om de sites beter te maken, in plaats van lullige crossbrowser-fixes door te voeren.
Vanaf nu standaard in al mijn HTML.
Pas op. Deze post lezen kan ernstige gevolgen hebben op uw vrije tijd.
Je hebt het klassieke forum waar je je registreert, waar je een nickname hebt en profiel, en een hele rits aan fora en subfora, met daarin topics en posts. Deze forums draaien op software zoals phpBB of vBulletin.
Deze fora gaan vaak over één onderwerp, zoals Belgium Digital, dat over digitale fotografie gaat, of het psychedelic.be forum, een hangout voor moderne hippies allerhande. Ik spendeerde vroeger mijn tijd al wel eens op de Spelletjesgarnaal. Indertijd was dat een actief forum over PC en console games met een beetje randanimatie in de vorm van het zwamforum.
Onlangs heb ik Metafilter ontdekt, dat werkt als een forum, maar ook niet helemaal. Door heel specifieke regels wordt de kwaliteit hoog gehouden. Klassieke forums hebben al wel eens last van trolls, spammers, en ander gespuis die de pret bederven. Metafilter niet.
Eén van de regels is dat je vijf dollar moet betalen om een account op te zetten. Je kan alles lezen, maar je kan niet posten zonder account. Dit feit alleen houdt al een hele hoop idioten tegen.
Een andere regel, die ik onlangs opmerkte, is dat je op het Ask Metafilter-gedeelte (stel een vraag en krijg antwoord) slechts één vraag per week kan stellen. Met als gevolg dat je wel eens twee keer nadenkt over waar je vraag over gaat gaan, en niet het forum elke dag volzet met elke kleine vraag.
Ik zou het wel interessant vinden mocht Twitter zo’n regel introduceren, want het interesseert me echt niet wat er tussen uw broodje zit en dat er iemand koffie is gaan halen.
Op technisch vlak stelt Metafilter niet veel voor, maar de beslissingen die gemaakt worden om een zo goed mogelijke community te bouwen maken MF tot wat het is: een grandioos goed forum.
Niets te doen op deze zaterdagmiddag? Ik zou beginnen lezen bij de all time favorites van Ask Metafilter.
P.S. Het Metafilter.com gedeelte lijkt op een soort kottke.org gerund door een grote groep mensen, ben ik persoonlijk minder fan van.
Het is geen geheim dat ik graag nieuws -en krantenwebsites maak. Als ik naar de site van de New York Times ga ben ik altijd verbaasd over hoe ver ze daar staan tegenover andere kranten. Check bijvoorbeeld de Times Skimmer eens.
Maar waar ik eigenlijk over ging schrijven: Reuters heeft een nieuw design, en het is best de moeite om eens van naderbij te bekijken.
Moet ik nog vertellen dat de mannen van Mozilla de laatste dagen onverantwoord interessante dingen posten op hun blog over nieuwe CSS toevoegingen in Firefox 3.6? Indien wel, haast u naar hacks.mozilla.org!
Als je al eens het tidy algoritme gebruikt om je HTML op te schonen heb je ongetwijfeld al gemerkt dat tidy van deze code…
<li><a href="#">Item</a></li>
… het volgende maakt:
<li>
<a href="#">Item</a>
</li>
Bij lange menu’s kan dit wel eens leiden tot een excessief lang document en dat vinden wij niet zo leuk meneer! Daarom kan je, na het uitvoeren van Tidy, volgende regular expression toepassen om de menu item markup weer netjes op 1 lijn te zetten.
Vind het volgende:
<li>(\n)(\t*)(<a.*\>)(\n)(\t*)</li>
En vervang het door:
<li>$3</li>
Deze regex is gebaseerd op de Oniguruma syntax die gebruikt wordt in mijn favoriete editor Textmate. Nog een fijne middag!
Uit een vraag op Ask Metafilter over de ideale computer setup, budget niet belangrijk, uit 2003:
- Memory: Lots of it. As much as you can afford. 1 Gigabyte is a good spot - any more really won’t be noticed but it sure looks impressive in the specs.
- Hard drive: Similar to memory - as much as you can get. RAID setups can improve performance dramatically, so try and see if you can get it.
- Video: ATI’s got the edge right now with their Radeon 9800. It’s faster and quieter (always a plus) than the competetive NVIDIA FX5950.
- Optical drive: Get a DVD recorder that can do both DVD+R/RW and DVD-R/RW. 8x drives are bleeding edge right now, so try to get that.
- Keyboard/mouse: both Logitech and Microsoft have pretty sweet wireless units - can’t go wrong with either.
De wet van Moore, still going strong.
Ik vind dat iedereen die een beetje in muziek geïnteresseerd is dit weekend het volgende moet doen:
Stap 1: reserveer een uur in uw drukbezette agenda
Stap 2: zet u in een comfortabele stoel
Stap 3: Kijk naar Good Copy, Bad Copy
Ge gaat het u niet beklagen.
Christophe vraagt om vijf oppeppende liedjes op te lijsten. Nou, dan doen we dat.
Bekijk ook zeker eens het lijstje van Dirk (The Subs!)
Op een bepaald moment is Dustin Curtis de American Airlines website zo beu dat hij besluit een redesign te maken van één (1) pagina en daarover een blogpost te schrijven.
Andrew Wilkinson gelooft dat de Zappos website beter kan en doet min of meer hetzelfde: een redesign van de homepage.
Iets dichter bij huis: Tim Van Damme maakt een redesign van de iTunes Store.
Het is altijd leuk om als ontwerper een ontwerp te nemen en dat aan te passen naar jouw visie. Om geen rekening te hoeven houden met de normale omstandigheden waar je in moet werken: goedkeuring door de klant (of in het slechtste geval: een comité), implementatie, deadlines, technische limitaties, performance. Je kan dat allemaal negeren en grafisch je gang gaan tot je tevreden bent met het resultaat. Menig ontwerper spendeert zijn vrije dag met… ontwerpen. Omdat ze dat nu eenmaal graag doen. Inclusief mezelve.
De manier waarop Tim zijn design presenteert vind ik proper. Zeggen van Hey, ik was in een creatieve bui, ik denk dat dit beter kon, doe ermee wat je wil..
Met een zinnetje als Then, the other day, I checked out your new website and wanted to stab my eyes out with a sharp object. zet de jongeheer Andrew Wilkinson meteen een andere toon. Het hele artikel baadt in een geveinsde vriendelijkheid: eerst complimentjes geven, dan afbreken. Dustin Curtis doet net hetzelfde.
Ik werk nu wel in een klein bedrijf, maar het is duidelijk dat die twee laatste gasten nog nooit in een echt bedrijf hebben gewerkt.
Joshua Blankenship vat het fenomeen goed samen in zijn laatste artikel:
Setting aside the arrogance of an article centered on an unsolicited JPG of the easiest page of a site to tackle—he “spent a couple hours redesigning [their] front page”—I’m amazed that anyone purporting to be a professional interface designer would assume a night of Photoshop earns them the right to be smug.
Ik vraag mij af wat die twee ontwerpers wensen te bereiken met zulke arrogantie. Ja, het is wel heel makkelijk om iemand op zijn fouten te wijzen. En ja, ik ben er zeker van dat er mensen bij Zappos en bij American Airlines werken die er iets beter van willen maken. Betekent dat dat je, out of the blue, zonder enige context, kritiek moet geven op een bedrijf? Ik vind van niet.
Als ontwerper moet je de balans vinden tussen ontwerp en alle andere factoren die iets maken. Het is belangrijker dat de juiste tekst ergens staat dan dat die uitgelijnd staat. Het is belangrijker om een zinnige titel te hebben dan een titel die op 1 lijn past. En ja, dat is misschien lelijk. Maar mooi zijn is in de meeste gevallen helemaal niet belangrijk.
Ik verdenk de layouter van Monocle (het boekje) er van om teksten zo te bewerken dat ze mooi in de layout passen. Als ontwerpvoorbeeld is Monocle een monument. Van inhoud? Over het algemeen, nee, niet echt. Een paar snobs die in een wereld leven waar je de ene dag in de sauna zit in Abu Dhabi zit, de andere dag in een privéloft in Tokyo, cocktails drinkende en zwierderig het laatste Rolex model te bespreken. Dat even terzijde.
Mijn punt: voor een ontwerper bestaat het gevaar dat je niet verder kijkt dan de esthetiek van een website. Achter een website zit een organisatie, met in die organisatie mensen met elk hun noden en wensen — met elk een game plan om iets te doen met hun bedrijf. Al lijkt dat game plan heel soms op hun bedrijf kapotmaken.
En dan zit je daar als freelancer, en dan denk je, nou, ik heb geen werk, laat ik eens een blogpost maken waarin ik bedrijf X afbreek op een “constructieve” manier. En het ergste is dan nog dat zoiets duizenden keren wordt doorgelinkt, want het is entertainend, maar wie wil er nog met die gast samenwerken?
Ondertussen zijn er duizenden mensen doodcontent schoenen aan het kopen op Zappos, krijgen ze een mail met vriendelijke copy, een klantenservice waar alle andere bedrijven jaloers op zijn.
Het is bijna een boksmatch: zet aan één kant van de ring een usabilityman en aan de andere kant een ontwerper en dan krijg je Karl Gillis vs. Wolfr. Ugh!
Bijna zo zot als R.U.S.E. Wordt tabletop gaming een nieuw genre op zich? En welke ouders gaan hun kinderen een vijfduizend dollar kostend speeltje aanschaffen?
Androits specialiseert zich in Microsoft®.Net oplossingen en consultancy; van webapplicaties met ASP.Net tot rich client applications. Ik ontwierp deze website, maakte de HTML/CSS templates en integreerde deze in een Wordpress theme.
Ook een website zoals deze? Of ben je bezig met iPhone/Android projecten? Contacteer me op wolf@wolfslittlestore.be.