work blog - My work blog is dedicated to articles about my job and the web in general. Read about XHTML, CSS, semantics and dig into my insane theoretic mumblings. en-us (Niels Matthijs) <![CDATA[The Lost Art of Switchboarding/A HTML Savior]]>

It's been a while since I've written anything front-end related. In part that's because I've been doing a lot of second-rate css work, but the main reasons is that I've been refocussing some of my energy to get more acquainted with cmses (Drupal in particular). The era of the lone htmler is ending and to make sure that html quality levels are still guaranteed there's little else to do than familiarize oneself with the theming layer of a cms. And I must say, it's been an interesting journey leading to some worthwhile insights.


I've been working on two separate projects, one made in Drupal 7, the other one made in Drupal 8. While 8 is definitely more front-end dev friendly, I pretty much ended up using the same methodology to output the desired html. The approach I ended up with also taught me a thing or two about how I wanted to structure my css work in future projects. For a while now I've been meaning to rethink the way I handle css, the Drupal work actually showed me a proper way to go forward with that.

To better explain what I'm getting at, I'll be using the telephone switchboard operator analogy, since that's what I felt like I was doing most of the time. For those of you who don't know what a switchboard operator did (way back in the day), the operators connected calls between people. The caller dialled a number, got connected to the operator, told her who he wanted to talk to and by switching the necessary wires the operator made the connection with the recipient.

Essentially, a switchboard operator functions as a mid-layer between two different systems that connect to each other in a many-to-many relationship.


A system like Drupal, which has been around for 15 years or so, has a lot of history that its carrying with it. Things get fixed between versions and many improvements are made with each increment, but in the end what happens in the Drupal back-end has little or no connection to the front-end it should eventually produce.

There are many ways to solve a problem in Drupal and each of those solutions renders its own html output. There are views, blocks, content types, panels, fields and layouts all intertwining to create a mashup of unlegible, impractical html code. And I'm sure I've only scratched the tip of the iceberg so far. In the end though, all a front-ender wants is a list, a container, a content type or whatever component is needed. For years, that's been the constant struggle between front-end and back-end developers, but as it turns out it's mostly unnecessary friction.

Drupal 7 and 8 gives you ample tools to separate the front-end from the back-end. Drupal 8 does a way better job with Twig imports and extends (greatly improving your DRY rating), but it's not exactly impossible to achieve with 7 either. In the end all you have to do is write the different front-end output options using the correct variables and use whatever view/block/panel id you have to connect it to the wanted output option.

/* switchboarding code */ {% if view_id='1' %} {% set viewOuput='list' %}{% endif %} {% if view_id='2' %} {% set viewOuput='container' %}{% endif %} /* html output */ {% if viewOutput== 'list' %} /* list code */ {% elseif viewOutput== 'container' %} /* container code */ {% endif %}


The past few years I've been battling a similar problem when writing css code. Design and semantics don't always match. Sometimes instances of the same semantic element are styled differently, sometimes different semantic elements are styled exactly the same. It's a big issue that we've been facing ever since we first started writing css, eventually leading to the hollowing of semantic html and resulting into the success of various css frameworks.

Solutions like less and sass provide us with the means to keep our html sane and our css clean though. Just write your html the best way imaginable, write abstract mixins/classes for your designs and couple them together in a layer in between. It's a bit different from the Drupal example in the sense that it will generate more css than necessary (compared to the css you need when you litter your html with senseless classes), but that's a trade-off worth examining I think.

So far I haven't had the time to try this out for real, but preliminary tests seem to indicate there's little standing in the way of working with css in this way (probably just some organizational challenges).


Even though we've been trying to decouple back-end, html, css and javascript for the past 20 years or so, we've never made much effort to do so properly. In the end people have always focused on doing their part as well as possible, demanding from others to adapt to fit their needs. Looking at the switchboarding principle, it allows us to move forward in a way where everybody could feel comfortable doing their job without compromising on the quality. And if anything, the middle layer could serve as an extra layer of documentation that makes the code that much more understandable.

From what I've experienced so far, it's pretty easy to accomplish and doesn't require excessive skills, nor does it make a project excessively more complex. Food for thought.

Tue, 29 Sep 2015 13:04:54 +0200
<![CDATA[On Spartan/And Community Fan Fiction]]>

Last week Microsoft finally released an alpha of its brand new browser. Currently known as Spartan (a code name that could very well be part of its final title), it's Microsoft's long-awaited departure from Internet Explorer (IE). While much can be said about the elaborate browser switch, there was something in the inevitable press coverage and ensuing discussions that greatly disappointed me. Something I think we as a community of front-end professionals should be more aware of.

A Quick Internet Explorer Recap

Up until a few years ago, the majority of people associated the IE logo with "the internet", not even realizing that it was just an app like any other and alternatives could be used. Wanted to access the world wide web? Just click the blue E with the swirl. IE was the only browser they knew and for a while (early 2000s) IE was effectively the only browser that mattered.

The result was disastrous. Microsoft became sloppy and failed to keep their browser (IE6 at that time) in shape, dragging their feet for nearly 5 years before they finally came with a significant update. In the meantime Firefox was gaining ground and when Chrome finally arrived Microsoft was hopelessly behind. IE became the bane of every web developer out there and that negative image started to spread. When Microsoft finally arrived with IE7, it was too little, too late.

For the next couple of years Microsoft would work hard to make Internet Explorer competitive again. They actually did a pretty good job, but the damage was done. Even though their market share remained respectable, the IE brand was tarnished and the slow update cycle of users (often companies) created too many extra hurdles for developers who wanted to build modern websites. And so Spartan was born.

My Browser Is Bigger Than Yours

Between 2005 and 2010 our industry changed a lot. Amidst the rekindled love for web standard, the birth of html5 and the rise of Apple and Google, webkit rose up to become the promised land of frond-end development. An open-source rendering engine backed by Apple and Google that pushed the web forward, what more could you ask for? If you wanted to hang with the cool kids, team webkit was the one you had to support.

People like to pick sides. The Beatles vs The Rolling Stones, Nintendo vs Sega, Apple vs Google ... if there are least two dominating brands within the same field you can be sure you won't find too many "oh, but they're both great"s flying around. Instead people pick a team and they start rooting for all they're worth. There's really no difference with picking a favorite sports team, it's just a little nerdier.

To be clear, here's nothing inherently wrong with that. When kept in check it's good mindless fun and it keeps people occupied. It can even be helpful, as the overwhelming support for webkit demonstrated. But when people start talking trash and turn into hooligans, things can turn sour real quick. There's a fine line between playfully throwing jabs between opposite sides and willfully wanting to destroy a brand's reputation.

The War Is Over

Reading various articles about Spartan (both from inside and outside the community) and browsing through a couple of comment threads made me realize that many people are still stuck in their pre-2010 mindset. Oblivious to what has changed over the past 5 years, they keep blabbering about Internet Explorer needing to ditch their own rendering engine and adopt webkit instead. They keep dissing IE for being slow and behind the times. They keep talking about IE's long tail as if other browsers aren't experiencing very similar problems. The worst comments even brought up IE6's lack of transparent PNG support. Talk about old sores.

The reality is that IE has caught up with the rest. No, it's not the ultimate browser out there, but so aren't its alternatives. Chrome has become a RAM hog and its rapid upgrade cycle has made it more unstable than it needs to be. Opera is notoriously bad with plugins and crashes more than it should. Firefox has become sluggish and is fighting for relevance and Safari has littered webkit with Mac-only fixes while still struggling to deliver decent position:fixed support.

The sad thing is that most people, even within the web development community, seem to be ignoring these problems. They're still just anti-IE and bashing away as if it was 2005. Now I'm not feeling sad for Microsoft, they pretty much deserved what happened to them and a company that large really doesn't need my pity. But to see other browsers vendors left largely uncriticized for the crap they're pulling is not good at all. It's the exact same lenience that led to the disaster that was IE6 and it made our job that much worse.


The moral of the story is that people don't seem to learn from past mistakes. All the webkit crew did was band together to eradicate a bad browser, but instead of understanding what went wrong they just picked sides and settled into their roles. It's this exact lack of critical thinking that made IE6 into a death trap.

To see these sentiments live on in the tech press is not all that strange, after all they only mimic the vibes they pick up from a particular field. But to see it still happening inside the web development community is shameful at best, lazy, unprofessional and irresponsible at worst. Not that people can't pick a favorite browser and engage in some jolly banter with the opposite sides, but there's a time and place for that. In the end it's necessary to keep an open mind and to be able to pass fair judgement, not in the least because the browser is one of the most essential tools of our field.

Current-day browsers all have their strengths and weaknesses. They deserve praise for doing a good job and they deserve to be criticized when they're dropping the ball. It's important we give them a fair shot because in the end, we're the ones that have to deal with them.

Thu, 02 Apr 2015 11:34:28 +0200
<![CDATA[The Big Film Shuffle/2015 Update]]>

After compiling my top 10 of the best films I watched this past year, it's time to get down to some serious business. The yearly update of my list of all-time favorites takes a bit more time and effort, but it's a necessary evil as new films are always waiting for a chance to storm the list, just as somewhat disappointing rewatches are pushed back down the ladder.

There are 16 new entries this year, that means another 16 films have dropped from the tables. Five of the new entries are awaiting review, so I'll give priority to those first. After that it's back to the regular schedule of expanding the list 10 films at a time. A full top 250 by the end of 2015 sounds a little improbable right now, but it's at least a nice goal to have.

The new list of 200 entries can be found at its usual spot.

Miss Zombie (049) Kantoku Banzai! (126) [Glory to the Filmmaker!]
Shi Hun (055) [Soul] Tian Bian Yi Duo Yun (153) [The Wayward Cloud]
Moi-bi-woo-seu (064) [Moebius] 964 Pinocchio (155)
Kaze Tachinu (076) [The Wind Rises] Himizu (159)
Jigoku de Naze Warui (077) [Why Don't You Play in Hell?] Kimyo na Sakasu (160) [Strange Circus]
Mogura no Uta - Sennyu Sosakan: Reiji (095) [The Mole Song: Undercover Agent Reiji] Cheuat Gon Chim (164) [The Meat Grinder]
Geung Si (138) [Rigor Mortis] Gangu Shuriya (173) [Toy Reanimator]
Grand Budapest Hotel, The (147) Mah Nakorn (174) [Citizen Dog]
Hwal (169) [The Bow] Metropia (175)
Jin Yi Wei (170) [14 Blades] Nihon Bundan: Heru Doraiba (176) [Helldriver]
Delicatessen (no review) (172) Oretachi no Sekai (177) [This World of Ours]
Meikyu Monogatari (no review) (190) [Neo-Tokyo] Nintama Rantaro (180) [Ninja Kids!!!]
Eraserhead (191) Yokai Daisenso (186) [The Great Yokai War]
Fifth Element, The (no review) (194) Yume no Ginga (187) [Labyrinth of Dreams]
Trainspotting (no review) (195) Rokugatsu no Hebi (192) [A Snake of June]
Punch-Drunk Love (no review) (199) Wu Qingyuan (196) [The Go Master]
Mon, 29 Dec 2014 11:14:13 +0100
<![CDATA[Future-Proof Mixins/A Clean Solution]]>

People love to complain about the mess that is css and javascript, but sometimes true beauty and elegance can be found within. In this particular case, I'll be talking less (not exactly core css of course, but something I assume most people are familiar with by now).

The biggest challenge in web design is building something that can stand the test of time. And by that I don't mean building a site that's so exquisitely beautiful and user-friendly that people won't need to touch it for the coming years, I'm talking about building a site that is so robust that future changes are easy to implement. A site that supports changes on page level as well as section level as well as site level. A site that remains slick and beautiful, even after 5 revisions and 3 redesigns.

A while ago I came across a nice construction in less that fortifies such a desire. It's a little trick that many of you will probably already know, still I feel confident that it's worth revisiting if only for the cheer beauty of the solution. Now, imagine you need to write a mixin for a button style. Typical stuff, some rounded corners, maybe a little gradient, a box shadow if it's an older design ... but it's the same button style that needs to be applied throughout the entire site. Your mixin will probably look something like this:

/* less */ .button {... padding:0.75em 1em; font-size:18px; ....}

This will need some extra work if it has to be applied to <a> as well as <button> and <input> elements but that's not really the point. The thing that will happen is that at one point, that one button isn't going to be good enough any more. Suddenly you'll want a button that looks exactly the same, only BIGGER. A real call to action.

Now, this wouldn't have been much of a problem if you'd known this from the start, you could have ended up with something like this:

/* less */ .button {... padding:0.75em 1em; ....} .buttonNormal {.button; font-size:18px;} .buttonBig {.button; font-size:24px;}

It's a decent enough solution, but not something you'd want to use midway a project as you'd have to run through your entire css code all over again in order to replace every instance of the .button mixin.

/* less */ .button {... padding:0.75em 1em; font-size:18px; ....} .buttonBig {.button; font-size:24px;}

This works too. Just make a new mixin for the cta button, this way you won't have to touch your existing code, but it's still an extra mixin that is sure to make things more confusing along the way (read: in three years time). Luckily, less can also do this:

/* less */ .button(@fSize:18px) {... padding:0.75em 1em; font-size:@fSize; ....}

Just promote the property you want to change to a variable with a default value (= the value you've been using all along). You won't need to change anything to your existing code, there's no need for extra mixins and you can start using the same mixin you've been using all along, only with an extra parameter if need be. You made something extremely flexible from something extremely rigid without breaking anything.

If only css and javascript had more mechanisms like this, our jobs would be a lot easier.

Thu, 11 Dec 2014 14:35:14 +0100
<![CDATA[Sour. Me Fish. Like! Like, BBQ/HTML Is Easy]]>

This may sound a little strange coming from a guy who spent the last 5 or 6 years submerging himself in the world of semantics, tags and attributes, but I have a little secret to share with everyone: html is really easy. You don't have to be some kind of abstract-loving, purism-craving brainiac to make a decently marked-up html page. Some very limited knowledge of the core concepts of html coupled with some basic training will get you a long way, and yet ...


Before I go on about the specifics html, let's talk language in general. Just consider the following three sentences:

  1. 1. I absolutely adore grilled salmon with a lemon on the side.
  2. 2. I like salmon on grill with little piece of lemon.
  3. 3. Sour. Me Fish. Like! Like, BBQ

I think it's pretty obvious that the first sentence is preferable. The second one has some grammatical issues and lacks the semantic depth and clarity of the first one, but it's still perfectly understandable. The third sentence is just one big mess. Sure enough, work really hard and you can try to make something of that last sentence, but I think we can agree that nobody wants to be associated with this level of skill.

Now, if English isn't your mother tongue speaking at the level of sentence 2 is acceptable. It isn't perfect, but it's good enough to make yourself unambiguously clear. Similarly, if html isn't your core skill perfection shouldn't be a goal, but you still want to reach an acceptable level of output.

Aim For 75

If you truly immerse yourself in the finer points of html you can talk hours on end about semantic grey areas. Is it div, article or section and where to draw the line? Enough food for discussion right there. Getting the whole wai-aria deal implemented to the letter or enriching all your data with the correct html5 microdata values and attributes can also be tricky business. And what about the most logical way to structure your page? Is it really meaningful to place the entire site header at the top of your document? Ask 10 different people and you'll quickly see there is plenty of room for personal differentiation.

But I'm not going to talk about getting your html "done, finished, over, hands-off!" ready. Instead, I'll be talking about writing sound, fair and usable html code. The kind of html code that wouldn't be too hard to improve if you've been staring at W3C documents for the greater part of the past decade, but is good enough to start working with considering the budget and constraints of a project. The kind of html code you'd give an 7.5/10 if you were to grade it.

Getting there isn't all that hard, as long as you keep the following core concepts in mind.

Pillar 1: Semantics

As you may know, html5 added quite a few elements to the html vocabulary. But even with all these extra elements, html remains a very limited language. In total there are about 120 tags, that's it. On top of that there are a few attributes to learn, but these too are extremely limited.

If 120 elements still sounds a little daunting, let me assure you that you could probably make do with 20 or so different tags when building an average html page.

  • Use <html>/<body>/<link>/<script> for your html page frame.
  • Use <div> for structure, ignore the other elements.
  • Use <p> for paragraphs of text, nothing else.
  • Use <ul>/<li> for lists, leave <ol> alone.
  • Use <a> for links. Not that you have much choice.
  • Use <hX> for headings.
  • Use <img> for images.
  • Use <table>/<tr>/<td> for tables.
  • Use <form>/<button> for forms and submits.
  • Use <input>/<select>/<textarea> for form input

With the elements above you should be able to handle most pages in the wild. Of course it won't yield perfect html, but it will suffice. The other elements all have their function and will add plenty of extra semantic value to your pages, but you can worry about that later.

Pillar 2: Targetability

This is basically your class and id management. Two simple rules will guide you through this process.

  • Make sure instances of the same component can be targeted throughout the site.
  • Make sure each component on a specific page can be targeted.

To accomplish that, simply:

  • add a body class for each page template.
  • use the same class for every component instance across a site.
  • add an extra class for each functional/visual component variation.

This will leave you with a html structure that can be manipulated both on global site level and on a very detailed component/page level. That's all the leverage you'll ever really need.

Pillar 3: Structure

Structure is probably the hardest part to grasp for people not used to writing html. This is a bit more abstract, but the basic premise is once again extremely simple though:

Group everything that belongs together.

What do I mean by grouping? Just put divs around elements that belong together. Have a heading and two meta data elements? Group the meta data. Do you have body content too? Group the heading and meta data to separate it from the body content. Have social links to go with that? Just group those in a div.footer element. Worry that you'll end up with too many divs in your code? Stop doing that, nobody cares.

The point is, if elements have a logical connection, just throw a structural element around them. This structural element will group the parts that belong together and it will separate the elements that don't. It may be a little abstract at first, but you'll get the hang of it soon enough.


If dealing with html is your daily job the rules above don't really apply. Extra semantic meaning, saner structures and better source order will all add to the overall quality of a website. So will all microdata and wai-aria decorations. I'm not saying these things are not important, but if you're just starting out with html or html isn't your core skill, the extra hurdles will only detract from the core principles of html.

So why the rant? Well, when I look at the standard output of most cmses (and even custom back-end development) today the output is still light years removed from reaching that basic quality level that's needed to do some proper front-end work. They are at the level of sentence 3. They may claim to output html, but in reality what they output doesn't make the slightest sense. They don't care about the language that html is supposed to be, instead they only see abstract hooks for css and javascript.

There is plenty room for purism in html and that should be dealt with when working against strict deadlines and limited budgets, but there's still a base level of quality that should be met even if time is sparse. If you can't reach that level, you're probably not fit for the job and web design isn't the field you should be working in. And don't blame it on html being too difficult, because it's probably the easiest part of building a website and mastering the basics shouldn't take you much longer than a week or so.

Wed, 03 Dec 2014 13:47:58 +0100
<![CDATA[september 2014 updates/more movies and small design tweaks]]>

The past few weeks I've been tinkering with my design again. The most obvious change is the switch from a black site menu bar to a white one. It's the first time in the 7+ years I'm running this site that I've opted for a dark on light design for my site menu. The reason is mostly due to a growing irritation with the scrolling center part of the site. With a fixed left/right column and only the middle part scrolling, the effect became a little too claustrophobic, hopefully that's a bit better now. I've also removed the pictures from the article list on the blog section, making the page quicker to load and less cluttered.

The movie section has undergone some small updates too. Unreviewed films are now "censored", making it just a tad more exciting to complete the list. I've also added 10 new films, so the list has now grown to 200 movies in total. A nice round number that will take me well into November/December to complete. With 6 more films to review, it might even be the final update to the list this year. Finally some small changes were made to the informative part of each film, making for a tighter design.

Small changes, but hopefully they make the site a bit lighter and less cluttered. The updated movie list is at its usual spot, so check it out!

Wed, 10 Sep 2014 11:54:20 +0200
<![CDATA[The Checkbox Parable/Logical Order Vs Visual Order]]>

Even though a lot has changed (both good and bad) since I started working as a front-end developer, there have been a few constants in my line of work that have persisted no matter how much I wrote or talked about them. I'm not a quitter though, so I've prepared yet another article in an attempt to try and bare the core of what makes an html developer tick. What exactly it is that makes us choose one particular html structure over another.

visual order vs logical order

At first glance there might be a strong bond between visual and logical order, but upon closer inspection you'll find that our eyes behave very differently from our brains. Our eyes don't always follow a logical path (top left to bottom right for us Westerners) when scanning for information and they often manage to skip ahead based on what attracts them or what they have learned from previous experiences.

For example, when browsing through a site our eyes will start to skip the site header after a while because they know from previous pages that they're not going to find anything of interest there, instead the eyes skip immediately to the content section of a new page. Then there are also color and alignment impulses that help our eyes to focus, whereas a logical order might dictate a different structure.

These alignment impulses is what I'm going to talk about here, as they perfectly illustrate the way we deal with checkboxes (or radio buttons is you want) on our websites. It's a perfect example of how the mind of someone who writes html works (or should work).

the checkbox

Checkboxes don't pose a big challenge these days, not for developers nor for designers. Just line up the checkboxes to the left, then add the labels to the right and when a label spans multiple lines make sure it doesn't wrap around the checkbox. It's easy as can be.

At least, that's how our eyes interpret it. By lining up the checkbox elements to the left they are a lot easier to spot (useful for quickly checking which ones are active). If we'd put the checkbox elements behind the labels they would be a lot harder to find, so to the left they go. But from a logical perspective, putting the checkbox first makes no sense at all.

Instead of thinking like a blind user (who probably has a screenreader that couples the label to the input element for him), just imagine going through the html code from top to bottom. If you'd match the html to the visual structure, you'd be putting the checkbox first in the html structure. So basically, you'd get a checkbox without the slightest idea of what its label is going to be. There is no context at all that tells you what this checkbox is about. Only when continuing you'd get to read the label. Should you then want to activate the checkbox, you'd be required to hop back before you could check the checkbox. It's like asking someone to reply "yes" or "no" without posing the question first. Silly, no?

So from a logical point of view, the label comes first, followed by the checkbox. And in short, that's what I try to take into account when I write html code. It's css that's supposed to bridge the gap between logical and visual structures, where html makes sure everything is presented in a logical order. As for the practical side, a position absolute and some padding will do the trick, or you can be all modern and flexbox both elements in the right visual order, but that's a css thing, not a html thing.


Don't get me wrong, I fully understand that this is quite the purist example. If you put the label after the checkbox, nobody will die and your site won't be much harder to use by the people visiting it, but to me this example perfectly illustrates the difference between what you see in a design and what you code in html. Other popular examples include "see all" links laid out next to the heading of a list or "back to top" links laid out in the same spot. Share buttons above an article or images that appear above headings are other popular examples.

Sticking to logical html structures can put some extra stress on the css and unless you're confident enough I wouldn't recommend going all the way, all the time, but it's good to keep things like this in mind whenever you're writing html code. Just read it from top to bottom and consider whether it makes sense without a visual design, because that's what html is all about.

Wed, 20 Aug 2014 12:45:47 +0200
<![CDATA[On messing up/and missing deadlines]]>

Last week an interesting question was launched on the Smashing Magazine's Twitter account: "What's the biggest mistake you've done in design/web development or your career so far?". The perfect trigger for some soul searching that ignited a little (yet stubborn) nibble I've been wanting to blog about for some time now, so here goes.

don't worry, be happy

Everybody makes mistakes, that's only natural. As anyone with a basic level of life experience will tell you, don't get too worked up when it happens to you, just look at it as an opportunity to learn from your mistakes. And front-end being the cesspool that it is, opportunities will be creeping up on you all the time.

I've made mistakes that nobody ever noticed. I've also made mistakes that reared their ugly heads on a level 5 page with a total page view count of 10 that some content editor published without double checking. Then I've made mistakes that cost a lot of money to fix. Even some mistakes that persisted throughout the project and made every new change tougher than it needed to be. I have a million options to choose from really, but singling out one single action didn't feel like it would adequately answer the question

the big picture

Looking at all the projects I've worked on over the years, big or small, there's been one nasty constant. A mistake that creeps up on you at least once a project and puts an indelible mark on all future work. And it has everything to do with not sticking to the optimal workflow. Once you start to compromise on workflow, you start to compromise on quality and that's usually the beginning of the end.

A website requires a lot of planning. Strategy, architecture, design, front-end, copy and back-end all cross each other's path. Things are bound to go wrong at some point, deadlines are bound to be missed. We don't like to admit it, certainly not up front, but whatever timing you make, you can be certain you're going to miss at least one deadline.


Deadlines are important. I am one of those people who appreciate the pressure a deadline puts on a project. Missing a deadline is generally not okay and people should do their utmost best to make their deadlines, but putting everything at risk to meet a deadline is quite possible the worst thing you can do. And that's where it often goes wrong. Rather than inform a client that a deadline cannot be met, "solutions" are proposed to try and get a project on track again.

My advice: if those solutions impact the ability to do your job well in any way, fight it as hard as you can. Intermediary deliveries, reduced development time, extra features without extended deadlines, mid-development change requests, parallel development that isn't feasible ... do everything in your might to avoid these situations. If you don't you'll end up cursing them afterwards. Situations like these are sure to result in shortcuts and quick fixes, unfinished work or lack in detail, jeopardizing the project as a whole.


Deadlines are rarely 'hard', even when everyone (including the client) is pretending they are. I've been in so many situations where we were failing to meet a deadline, changed things around to make it work, fucked it up and had the deadline moved when it turned out we weren't going to make it either way. It's usually a lot safer to push the deadline back a little or go for reduced functionality (and fix it post-launch) than to take the gamble.

When making a website, there's little or no option for "turning back" or "refactoring" once the website is live (of course there is in theory, but it never happens). That means that whatever you fuck up during the process remains that way until after 4 years your client decides it's time for an entirely new website. Many of the "solutions" proposed to meet a deadline will turn out to be more costly in the long run and will end up decreasing the quality to often unacceptable levels. You can't always stop it (people are stubborn), but being part of the development team means you have the obligation to fight these decisions and to warn people of the dangers. It's often an uphill battle, but even if you only win a few it will make your job a lot nicer along the way.

Tue, 05 Aug 2014 11:20:32 +0200
<![CDATA[movie list updated/180]]>

As predicted, it took a while before I got around to adding the next batch of films. But slow and steady progress is progress too and almost three months after the last update I'm happy to announce 10 new films to add to my list of all-time film favorites, making for a total of 180 films.

It's pretty much an Asia exclusive this time around, the two European film that made the cut are Leconte's La Fille sur le Pont and Tarek's Metropia. Apart from that we have three re-entries (Mah Nakorn, Gangu Shurya and Oretachi no Sekai), two animes and some interesting horror additions. In total 4 new films are waiting to be reviewed, while the first review should be ready by next week. So the next update shouldn't be too far ahead.

The updated list is at its usual spot, so check it out!

Thu, 15 May 2014 12:03:57 +0200
<![CDATA[rip comments/the end of an era]]>

Yesterday I took one of the hardest decisions in my six years running this blog. Even though I'm a big supporter of commenting and I still stand by every word I wrote back then, I killed off my comment system. Here's why.

The problems arose a few months back. Due to a changes in Mollom's API (a system to block spam messages) there was a sudden increase in spam comments that were slipping through my filters. The spam bots picked it up right away and they started to target my blog. This resulted in some server trouble, which prompted the server admins to disable comments on their side of the fence.

We invested a little time in the problem but weren't able to solve it right away. I would've been glad to put in some extra effort but there's also another reality I had to face. I don't mind the 1000 spam comments fired at my blog every day, most are stopped by the spam filters anyway, the real problem is the lack of actual comments being made.

Unless you implement systems like Facebook comments or Disqus, people are less inclined to comment nowadays. And even then you need a pretty popular site to generate even a little buzz in the comment section. I could've given it a try, but I'd rather not have these crappy systems on my blog. So that left me with only one option: remove the comment section.

I went for the cold turkey option and removed all traces of comments on my blog, even on older articles. While they still live in the database (so they could be revived at a later time), I chose to remove them everywhere to improve page load and general performance (less css, less html, less database calls).

I would like to give a final thanks to all the people who commented here over the years. It's sad to see this functionality go as I still consider interaction to be one of the most important cornerstones of the web, but you can't fight reality forever. At least I'm still here on my own blog platform (another thing that's dying quickly these days), something I plan to keep on doing for a long time to come.

Thu, 27 Mar 2014 11:26:21 +0100
<![CDATA[component complexity pt2/html variants]]>

After last week's short introduction on component complexity, it's time to get down to business. First off, I'll give a quick run-down of the example I'll be using throughout the rest of the series, after that I'll be looking at the way html can vary within the scope of a single component. To keep things sane I'll try to keep my examples as clear and concise as possible, though I'll be hinting at some additional real-world variations that will only add to the complexity.

example component: the article

I'm going to make it easy on myself and just refer to the Smashing Magazine article I've written back in 2012. It gives a perfect run-down of the component we'll be using here. In short: the article component is a typical (and common) content type, used for displaying articles, blog posts, news items and whatnot. Typical for content types is that they appear in several different guises. Usually there's a detail page with the full article, but you'll also find smaller teasers throughout the website linking through to the detail page. From an html perspective it's all the same component though.

html variants

There is no straight mapping between a single html component and its html output. All variations of an html component will be built from the same html structure, but actual html output may differ depending on several factors. These variations are important as they will impact design, css and possibly even javascript, so it's important to be aware of all the different possibilities.

Just imagine a pager. Some pagers feature prev/next links, some feature first/last links, others feature no extra navigation links at all. All these instances are variations of the same component, but the html output will different (the first/prev/next/last links will no doubt feature different classes and the html will either be there or will be completely absent). Some other examples include headings (ranging from h1 to h6), navigation lists (either marked up with the nav or div element) or input fields (with or without informative text), but the list is virtually endless.

Not all changes in the html output are html variations though. When the difference is an additional (existing) html structure initiated by content (just think of an extra item in a navigation list) this does nothing to change the structure of the output. It simply represents a loop of a specific html structure within the component.

Html variations are pretty common and you should expect each component to have at least a couple of them.

html variations for article

Two main variations exist. First of all you have the views. On the detail page you'll find the full view of the article, but on higher-level pages you'll find various teaser views. These views can range from heading-only to semi-expanded views with a teaser image and abstract. For this article's sake, we'll stick to two views only (detail and teaser).

/* detail view */ <article class="article detail"> <header> <h1>article heading</h1> <div class="meta">...</div> </header> <div class="main">...</div> <footer> <div class="share">...</div> </footer> </article> /* teaser view */ <article class="article teaser"> <header> <h1>article heading</h1> <div class="meta">...</div> <div class="abstract">...</div> </header> </article>

The detail view has a main and footer section for body text and sharing options, the teaser view obviously lacks these elements, but features an abstract text section in the header of the component. But that's not all, the teaser view as it is written now lacks a link (as that's its sole purpose of existence: linking through to the detail view).

There are two options there, either we use a block level link (so the entire teaser is linked), or we just link the heading of the view. Both options yield different html

/* block-linked teaser */ <article class="article teaser"> <a href="#"> <header>...</header> </a> </article> /* heading-linked teaser*/ <article class="article teaser"> <header> <h1><a href="#">article heading</a></h1> ... </header> </article>

so why is this important

The problem with these structural html changes is that they impact css and javascript work and they might even carry some design impact too (in case of the different link options). A block-linked view has different hover and focus states compared to the heading-linked view, the block-linked view impacts the use of child selectors and the styling of the different base views might be wildly different, so all these different variations will impact the work needed to style and design them.

Looking back, this gives us three different variations: one detail view, one block-linked teaser view and one heading-linked teaser view.


In real life, there are usually four to five different views per content type (one detail and three or four teaser views). Combined with the link options this can lead to up to nine different variations already, and we've just started this series. It's important to limit the views to an acceptable minimum and pick one single link method from the start. Leaving the option open will have a disastrous impact on the amount of use cases you'll have to cater for in a later stadium.

Next up: the visual and functional variations of components.

Thu, 20 Mar 2014 12:26:20 +0100
<![CDATA[component complexity pt1/an introduction]]>

The past 3 or 4 years everyone has been racking their brain to break through the responsive web design wall, I've been worrying about something else. To be honest, from an html point of view responsive design isn't even all that interesting. Shuffle some structural elements around so the css guy has less trouble positioning everything and that's about it. Instead I've been tinkering with component-based html concepts, something I've written about extensively in the past.

Component-based html makes sense when working on large (multi-site) projects and easily extends to the entire workflow, from architecture and design to css, javascript and back-end. Once you decide to go the html components route, everyone has to go along with it. One thing I didn't predict up front was that the biggest problem I was going to hit had everything to do with its main selling point: the perceived simplicity of (html) components. A component is little more than a small(ish) piece of html code that looks cute and manageable from afar, but in reality even the tiniest block of code can become an unmanageable beast in less than a blink of an eye.

from page to components

Once you decide to go down the component route you can't permit yourself to do a half-arsed job. If you work with components, your delivery is exactly that: components. Pages are pretty much demoted to an afterthought in the process, a reality check to verify whether your components continue to work when put together. So instead of wireframing and designing pages, you wireframe and design components. You css and javascript these components, you cross-check them by building a few standard pages and when everything is in order you deliver the components to the back-end developer.

This is absolutely essential, as working with pages will never allow you to incorporate all the different variations. Give a page wireframe to a designer and he'll design the page. Give it to the csser and he'll css that same page. Send it in for a quality check and the page will be checked. The components may have disappeared from view, but they still exist at html and back-end level. At first you might not be too worried, until the customer starts to play around with his set of components, enabling and disabling all kinds of variables and inserting some bits and pieces of content in the most unexpected places. That's when the trouble starts.

five types of variation

Because I think this subject deserves some in-depth writing I decided to make a little series out of it. Instead of just listing all the possible types of variations and tack on a quick conclusion, I'll run through all the variations individually, working with a real-world example to try and prove my point. At the end of this series I'll dedicate a separate article to the conclusion, hopefully illustrating how a simple component turned into a downright monster.

In total I found five different (yet very common) types of variations. Ways to alter a single component that could result in problems later on (which means they should be checked through all levels of the process, from wireframe to back-end implementation). If you don't keep an eye out, you'll end up with an exponential growth that results in 30-300 variations in no-time. Many of those will look and behave similarly, but when these variations are hidden from view you'll be sure to miss some, resulting in more bug reports and more after-project care than your sanity can handle.


So there we go. I'm still deciding on which component to work with (though I suppose I'll take something similar to the story component that I detailed in the Smashing Magazine article, as that is an easy component to understand and one that turns sour real quick if not handled correctly), but expect new entries in this series to pop up at regular intervals.

Next up: html variations.

Mon, 03 Mar 2014 12:21:29 +0100
<![CDATA[movie list updated/170]]>

Just two weeks ago I expanded my list of favorite films to 160, with the Braindead review already behind me I can add another 10 films. This time though I will have a lot more work getting everything reviewed as there are quite a few previously unreviewed films entering the list.

In total six older gems (all yearning to be reviewed) are making their way into my list of favorite films. There are two re-entries in the form of About Love and [rec] and two previously reviewed films that finally made the list (Frontière[s] and Cheuat Gon Chim). There's also a bigger variety in nationalities as Japan only delivers two films (Kurenai no Buta and Daiteiden no Yoru Ni) this time around. More than enough reason to check it out I think.

The updated list is waiting for you. Enjoy!

Thu, 13 Feb 2014 11:46:25 +0100
<![CDATA[movie list updated/160]]>

It's that time again! Ten new films were added to my list of all-time favourite, largely dominated by older entries that failed to make the cut after one of my yearly updates. That made it an easy update for me as most of the review and entry work had already been done. It also means that the next batch of 10 is right around the corner and can be expected within a month or so.

Shamo and Himizu are new to the list, though I already reviewed both films on this blog before. The only missing review is that of Braindead. While it popped up in my list at the end of last year, the big New Year shuffle prevented me from actually watching it. So there you go, another step towards a list of 200 favorites (which is a rough goal for the end of 2014).

You can check the updated list here. Enjoy!

Fri, 31 Jan 2014 11:46:32 +0100
<![CDATA[design theory vs reality/a plea]]>

Should you still doubt it, I'm not the graphical designer. type. I can manage html and css, some basic javascript if needed, but don't present me with a blank canvas because I'll choke. Still, as an everyday (an avid) user of the web I can comment on design choices and even challenge design theories, so that's what I'm going to do here. At the same time, this article will be a plea to my designer colleagues to get their act together.

In my opinion 2013 has not been a very good year, design-wise. More then ever I've been bothered by design decisions that actively hinder the speed and comfort at which I can consume a website. And when design becomes a hurdle, I think it's fair to call it bad design. While I read up on the theory behind such choices (and can understand why they are applied), it's clear that there exists a large gap between theory and reality that's being ignored by some of these designers.

1. custom fonts

Custom fonts are probably the worst thing that could happen to the current web. At least, in their current state and implementation. Not only do they present extra page weight that I personally don't care about, most of the custom fonts I've encountered actually hinder legibility.

As a Windows user, it's actually quite easy to see which designers work on Macs and which use Windows. Font rendering between the two OSes is wildly different and most fonts are ill-equipped to deal with those differences. You know all those thin fonts that look so damn sexy on Macs? They look like famished stick figures on Windows. They are blocky and ugly, some characters looking more like torn-up war victims than actual readable characters.

Font theory sure is interesting to read, but it is based on an assumption that a font renders a certain (exact) way. I've often compared font rendering between Windows and Mac and the differences can be staggering. Even browsers have a different way to render fonts. I know everyone is tired of Arial and Helvetica, but picking fonts that look cool on a Mac and leaving 90% of the desktop market looking at massacred text is definitely not a good alternative. If you're opting to use custom fonts, make sure to test them cross-OS and cross-browser first.

2. huge type

Mike Anderson (sorry for singling you out) wrote a pretty in-depth article outlining the reasons why he prefers huge type. It has almost become a de facto standard for blogs these days to use 16-18px as base font size. While his reasons make sense (and contain some long-standing design principles), I feel many of his arguments are based on wrong analogies and optimal situations.

Mike starts off by stating that he wants his site to be read like a book. While that's a fair goal, the web is so vastly different from print that it's a pretty impossible analogy to make. With a book your eyes move from top to bottom, from page to page. On a website your eyes go from left to right, but the upwards/downwards motion is often handled by mouse/touch input. Maybe it's just me, but I never read to the bottom of my screen before I scroll to the next part of an article, instead I scroll almost continuously, keeping my eyes centred on the screen.

Now, this isn't too big a problem if you somehow have smooth scrolling enabled. But I don't. I use a scroll wheel to scroll. When I scroll text jump X amounts of pixels, which is far from easy on the eyes. So even though line lengths, line heights and huge fonts may all contribute to easy reading in books, it doesn't necessarily amount to the same results on the web. The bigger the fonts and the more they breathe, the more I have to scroll. Hence the small type on my blog as it doesn't take more than one or two scrolls to read the entire article on a desktop.

It's not only that though, once you scroll a few times you end up looking at a sea of white, showing hardly two full paragraphs at once on a screen. I often feel dwarfed and lost reading blog posts like that, as if I'm sitting too close to a TV screen to see the full picture. I also miss the context of where I am in the article. Books have pages and physical attributes to help you with that, but online, there's only a scrollbar and that's only if your browser still displays those.


My conclusion is pretty simple: design for your audience. Designing in a browser solves a few issues, but people use many different devices, browsers and OSes. Design theories are good (and necessary), but when they don't match other people's situation they are actually quite worthless, sometimes even counter-productive.

If you design on Mac, please check how your designs look and behave on a Windows machine. Check out how they work on Android and WP. You may look down upon these OSes, but they still present the majority of the users out there, and if you're not careful you're giving them a horrible experience. Which, in returns, reflects directly upon your skills as a graphical web designer.

Thu, 09 Jan 2014 13:18:42 +0100