work blog - onderhond.com http://www.onderhond.com/blog/work 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 underdog@operamail.com (Niels Matthijs) <![CDATA[Future-Proof Mixins/A Clean Solution]]>http://www.onderhond.com/features/css-techniques/less-mixins-future-adaptation

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]]>http://www.onderhond.com/blog/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 ...

Language

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.

Conclusion

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]]>http://www.onderhond.com/features/blog-updates/september-2014-updates

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]]>http://www.onderhond.com/blog/logical-order-checkbox-parable

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.

conclusion

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]]>http://www.onderhond.com/blog/on-messing-up

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

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.

conclusion

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]]>http://www.onderhond.com/features/blog-updates/movies-top-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]]>http://www.onderhond.com/features/blog-updates/rip-comments

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]]>http://www.onderhond.com/blog/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.

conclusion

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]]>http://www.onderhond.com/blog/component-complexity-pt1

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.

conclusion

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]]>http://www.onderhond.com/features/blog-updates/movies-top-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]]>http://www.onderhond.com/features/blog-updates/movies-top-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]]>http://www.onderhond.com/blog/design-theory-vs-reality

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.

conclusion

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
<![CDATA[the film shuffle/a yearly update]]>http://www.onderhond.com/features/blog-updates/top-150-update-2014

And so the year is coming to an end. Not just a moment to look back and filter the best films I watched this past year, but also a time to rethink what I consider the best films ever made. I've updated my top list of favorite movies accordingly. A total of 20 new films made the cut, which means another 20 fell off the bottom. No worries though, I'll keep expanding my list in 2014 so I'm pretty sure they'll pop up again.

Below is a list of the new entries and their respective victims. I'm still missing two reviews (Primer and Renaissance), so those will get top priority. After that it's back to expanding the list.

The full list of 150 entries can be found at its usual spot.

IN OUT
Heruta Sukeruta (013) [Helter Skelter] Eraserhead (067)
Petaru Dansu (042) [Pedaldance] Takeshis' (072)
Yi Dai Zong Shi (044) [The Grandmasters] Oretachi no Sekai (097) [This World Of Ours]
Gravity (068) Rubber's Lover (108)
Luan Qing Chun (073) [Beautiful Crazy] 964 Pinocchio (113)
Boku to Tsuma no 1778 no Monogatari (093) [1778 Stories Of Me And My Wife] Mah Nakorn (114) [Citizen Dog]
Ikiterumono wa Inainoka (095) [Isn't Anyone Alive?] Tian Bian Yi Duo Yun (119) [The Wayward Cloud]
Sumagura: Omae no Mirai o Hakobe (098) [Smuggler] Sennen Joyu (120) [Millennium Actress]
Sekai de Ichiban Utsukushii Yoru (099) [The Most Beautiful Night In The World] Yokai Daisenso (125) [The Big Spook War]
Autoreiji (111) [Outrage] Gerry (130)
Monsutazu Kurabu (115) [Monster's Club] Gangu Shuriya (132) [Toy Reanimator]
Kotonoha no Niwa (117) [The Garden Of Words] [Rec] (133)
Kantoku: Banzai! (126) [Glory To The Filmmaker!] About Love (134)
Upstream Color (130) Haze (138)
My Blueberry Nights (137) Kimyo na Sakasu (140) [Strange Circus]
Renaissance (no review)(139) Tokyo Ken (141) [Tokyo Fist]
Primer (no review) (142) Braindead (no review) (147)
District 9 (145) Balada Triste de Trompeta (148) [The Last Circus]
Where the Wild Things Are (148) Gau Ngao Gau (149) [Dog Bite Dog]
Memorizu (150) [Memories] Akiresu to Kame (150) [Achilles and the Tortoise]

]]>
Tue, 31 Dec 2013 12:29:42 +0100
<![CDATA[ie7 support dropped/it's official]]>http://www.onderhond.com/features/blog-updates/ie7-support-dropped

Time flies, though sometimes it should be allowed to fly a bit faster. It's about two years ago that I officially dropped support for IE6. Back then I figured IE7 would be quick to follow. I guess I figured wrong though. It took the damn brat two years to finally disappear from my browser stats radar, but now it is finally gone for good.

Should you be one of the very few still visiting this site with IE7, you probably already know that support has been very limited since the last redesign. This sites basically "works" in IE7, that's just about as much effort I put into it. From now on though, I won't even check in the old browser of yonder when I make changes to the design or structure of the site.

So who's up next? Why IE8 of course. Still jumping between 0.5% and 3% (check the new graph on the homepage), I can only hope it will go down faster as IE7. The outlook is rather grim though, as IE8 is the top IE version on XP (which, for some insane reason, is still a popular OS), which means people on XP can't upgrade to a more recent IE. Then again, there's always Firefox, Opera and Chrome.

If you're still using IE8 (or you know people who do), please redeem yourself and help me win my quest. The world will be a better place (and my site will be that little bit leaner for everyone).

]]>
Mon, 30 Dec 2013 11:40:08 +0100
<![CDATA[mobile-first vs mobile-second/a nuance]]>http://www.onderhond.com/blog/mobile-first-alternative

After a surprisingly short transition period, the mobile-first css approach has become the de facto way of implementing responsive designs. Unless you're retrofitting a responsive design on an existing site, there really is no question about how to structure your css. But lingering underneath the reassuring cloak of best practise comfort there is a little nuance that is lost on some. There are basically two ways to approach a mobile-first css setup and only one of them is sane.

why mobile-first

Mobile-first css development is good a way to reduce performance issues on mobile. Instead of coding the desktop (largest view) design first and overriding the necessary properties for smaller viewports, you start with the smallest viewport and go from there. Mobile browsers are capable of ignoring all css that isn't necessary for them (as long as it's contained by a proper media query), so they get a significantly smaller set of css rules to apply and reapply (when javascript is doing its dom magic).

The result is a smaller css file, less code overhead and better performance on machines that only need a small chuck of the entire set of css rules to render their design (even though the css file is still loaded in its entirety, less rules need to evaluated).

mobile-first to the letter

When going the strict mobile-first route, you start by looking at the smallest viewport design and implement that outside of the scope of media queries. Then for each responsive change, you create a media query and add the necessary code to get to the new design. The result looks something like this:

/* mobile-first */ .class {border:1px solid #000;} @media (min-width:960px) { .class {border:none} }

It sure beats a desktop-first approach where the mobile browser would have to evaluate two rules instead of one, but what irks me about this setup is the fact that we need to reset the border to its default state on desktop. Even though the desktop styling needs no border styling rules at all, we've written two to make the design work on desktop. That's pretty silly.

Not only does it feel like overkill, it also impacts the readability of the code.

mobile-second

It's actually quite easy to fix this. Rather then look at the mobile design first, why not look at all the design variants at the same time and filter out the common elements. These are the rules that may exist outside the scope of any media query. Then add the custom styles for each responsive view in a second stage, beginning from the smallest view. The example above would look like this:

/* option 2 */ @media (max-width:959px) { .class {border:1px solid #000;} }

As the smallest viewport design is the only one who needs a border, we just apply it to this viewport in the mobile view and leave the desktop be.

conclusion

The problem with the mobile-first approach is most apparent when smaller viewport designs apply styles that have to be reverted to the default (browser) styles on larger viewports. It creates ugly overhead that hinders overall readability of the css.

You can be more lenient in cases where different viewports need explicit stylings (instead of no border at all, imagine a red border on the desktop view in the first example), especially if this saves you extra media query declarations, but that doesn't change the fact that it's better to start with looking at common stylings instead of staring blindly at the smallest viewport design first.

small disclaimer: whenever I'm talking about "mobile" and "desktop" views in this article, I'm referring to the smallest/biggest viewport designs available, not necessarily to the device on which a site is rendered. These terms are remnants of the days when mobile = 320px and desktop = 1024px. Sadly they have become somewhat of an industry standard, but at least people understand them (and they limit the use of overly verbose descriptions like "smallest responsive view"). It's a semantic discussion that's probably better suited for a different article.

]]>
Wed, 27 Nov 2013 14:10:34 +0100