How to keep up to date on Front-End Technologies – The Recipe

Here's a nice attempt in creating a list of useful resources for front-enders. Especially the links to sources are valuable, so be sure to follow a few of those sites. I'm not sure I like the term 'front-end leaders' though. While I do believe following the right people is very important, I don’t think it’s the most important thing. A great initiative nevertheless!

Links for 1369346735 is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!

A URL as a present – Love Nonsense

I tried to write a post about Mobilism this weekend but I was a bit hung over. So instead I created a *semantically correct, responsive illustration of twenty balls* as a thank you gift for Mike Kus. http://vvg.gr/dk

Links for 1369085748 is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!

Why?

In the beautifully designed Mobile Book you can find some illustrations by Mike Kus. The chapter about responsive design is illustrated by a work I particularly like. My wife liked it too, we didn’t like one of our walls in our hall, so we decided to paint the illustration on that wall. I ordered some stencils, painted the illustration onto the wall, cursed the inflexibility of the physical world, ordered some new, slightly smaller stencils, and finally repainted the illustration.

What

Now, I didn’t ask Mike for permission, I just painted his work onto my wall. So the least I could do was thank him for creating such a beautiful thing. I thought about sending him a book. But that’s boring. I thought about sending him a poster, but I don’t think these salads compare to the fantastic work he’s created. So when I read about the possibility of selling URLs, I realised that I could also give away a URL. I decided to create a semantically correct, responsive version of Mike’s illustration and give it to him. This is how it works: People with very old browsers will see a purely textual representation of the work while people with other less capable browsers will see the colours that have been used as well. Isn’t that nice?

Native web art

In one of his fantastic talks Bret Victor defines computer art as without behaviour, it’s not native. I changed that quote slightly to Without adaption, it’s not the Web. Anything on the web needs to adapt to the possibilities of the device and browser the visitor chose to use. If it doesn’t it’s not webby. Back to the illustration.

For people with big, modern browsers I used somewhat modern CSS to style the semantic HTML in such a way that it looks like the original illustration: Same layout, same order. For people with a smaller screen, the illustration is reflowed to fit within three columns. The illustration is laid out over two columns on the smallest screens. By my definition — since it adapts to its environment — this version of the work is webby. If you resize your browser window continuously, you are interacting with the work, and the work shows behaviour by reflowing the layout. So in Bret Victor’s terms, this is native computer art. Could it really be that this present is real, native web art?

Happy

I’m very happy that Mike actually likes the things I did to his work. He was excited about the painting, and he was excited about the semantically correct, responsive web version too. I was a bit concerned that he might not have liked it, you never know how people react. In that case I would have kept the painting on my wall, and I would still have given him the URL with its content. But I would not have written about it. And if he wanted to, he could have just deleted all of it. Just like physical art.

Specialists

Jan-Jaap works in a small company. In order to keep everybody busy they can’t work with hyper-specialists. Apart from their specialty everybody needs to be able to do something else. He gave the example of concept artists. There are many, many concept artists, but there is not that much work for them. So concept artists have to be able to do more than just make up wonderful stuff: they have to know how to build it too. This is a trend we see in web development too, where we start to expect designers to be able to write code too. It sounded like this is better accepted in the gaming world, but it could be that Jan-Jaap’s company is an exception.

Tools

During a 48 hour long game jam, they decided to use a certain tool that they had no experience with at all. They needed it because the result would be much better with it. His excellent tip was to not let the result of your work depend on your skill set. Learn new tools, new skills, if the skills you have are not sufficient or good enough for the medium you work for. This is a definite pet pieve of mine. I won’t mention a certain photo editing tool that’s still been used broadly to design websites with, because some people get upset if I do. But if you won’t listen to me, at least listen to Jan-Jaap and look around you for better software. It exists.

Progressive enhancement

He showed how you can create, and play a pinball game with just some simple, elementary forms like blocks and balls. It was perfectly playable. Working from the content out, from the essentials first, gave him the ability to keep working on it without depending on design details. These details are built on top of the basics, they can be added later. Of course I loved seeing progressive enhancement being used in a completely different field. It’s just a very clever principle to work with, not just on the web.

There were more similarities. It appears, for example, that endless discussions exist elsewhere too! Another similarity is the workflow: The gaming industry has moved from waterfall to more agile project management approaches too in the last few years. They too have clients who find it hard to adjust to this new way of working.

A very refreshing presentation. Great to see that others look for solutions in the same direction. It confirms my idea that we should look at what others are doing.

But first this: When I reread the article I noticed that one remark I made may sound a bit harsh. I wrote that I think that Ethan’s definition is a little outdated and unnecessarily restrictive. This is unnecessarily rude. His definition made perfect sense back when he introduced it, and back then it was not restrictive at all. On the contrary, the term responsive design changed the way our industry looks at the web. Finally. For this he has my eternal gratitude.

As Ethan mentioned in his comment, he currently uses a broader definition. Which is logical, we’ve been only designing responsive sites for a little over two years, we’re still learning. And one of the things we learned is that there are more features you can optimise for than just screen size. So, with this out of the way, let’s see if we can come up with a definition of the terms responsive web design and adaptive web design.

Attitudes

There were three different attitudes towards my question. The first one considers these terms to be somewhat the same. I used to have that attitude. Another one considers these terms to be jargon, and as such to be confusing an sich. These terms should simply be replaced with a sentence like making the best possible product. And then there’s the third attitude which considers a clear definition to be valuable and which thinks a distinction between these terms actually makes sense.

Attitude one: it’s all the same

This attitude exists because everybody has his own definition of the words responsive and adaptive, often meaning completely different things, and often meaning the exact opposite of their original definition. This is a clever solution for large agencies with many clients, I think. Instead of using clear, distinct meanings for these terms, we use them as a catch-all definition for a set of web design best-practices. In this case, I use them as a synonym for progressive enhancement and accessible design. Most commenters did not agree with this attitude, and I think I agree with them. But I do think that within a large organisation this might actually be a clever idea.

Attitude two: kill jargon

This attitude doesn’t care about these terms and considers it a waste of our time to discuss in length about them. It should really only be about providing an experience which takes advantage of all the features of the platform people are using […] whether it is based on web standards or technologies provided by the vendor, like Cyriel wrote. In other words: Stop wasting time about trivial matters, and start making good stuff. I definitely like this sentiment, but it’s not going to end the confusing use of these terms.

Attitude three: we need a clear definition.

There are some excellent reasons for using clear, distinct definitions. For example, David reminds us that our clients are starting to use that jargon, and we need to be sure that we are talking about the same thing with our clients. Or as Aaron puts it: I feel nomenclature is incredibly important to ensure accuracy in our communications. They both mention the confusion around the term HTML5 which has a different meaning for marketers and developers, which makes things unnecessarily complicated.

The definitions

A few commenters tried to come up with clear definitions. Simon came up with some fantastic, short definitions.

Responsive web design is about browser (viewport) sizes and Adaptive web design is about browser (use) context

I like that. Even though the term context is equally confusing as these two definitions. Maybe we could use features instead of context here.

And I think Aaron came up with a nice description of responsive: it’s concerned with layout, hierarchy, and creating an optimal reading experience regardless of device.

Proposed definition

Responsive web design is about browser (viewport) sizes. It’s concerned with layout, hierarchy, and creating an optimal reading experience regardless of device.

Adaptive web design is about browser (use) features. It’s concerned with responsive web design and with creating an optimal user experience depending on different devices.

I need your help with this one, especially with the definition of adaptive. I don’t think it’s good enough yet.

Conclusion

There is a difference between the terms responsive and adaptive and we have to be able to make a clear distinction. To prevent confusion with clients we should make sure that we are talking about the same thing when we use these terms. There are practical approaches possible, where the exact term used doesn’t really matter as long as we know we mean the same thing, but a more thorough solution is probably to use the right terms in the right moment.

Thanks all for your fantastic feedback. If you have some time left maybe you could help me out with finding the definite definition for both terms. Comments are open again.

The Sea of Ideas » No, HTML5 does not have a performance issue.

Excellent article about the so called performance issue of HTML5. This issue does not exist. If people insist that it does, you can point them to this link. http://vvg.gr/de

Links for 1368529536 is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!

Responsive web design

In his book, Ethan Marcotte — the person who coined the term — writes that responsive web design takes three core ingredients:

1. A flexible, grid based layout
2. Flexible images and media
3. Media queries

So basically, if we use the term as Ethan proposed it, responsive web design is about fluid layout for different screen sizes and related technical issues and solutions. I know many people use a much broader definition.

Adaptive web design

Around the same time that Ethan Marcotte published his book, Aaron Gustafson published another book called Adaptive Web Design. When I bought it, I thought it would be about the three points outlined above, about layout basically. But I didn’t really pay much attention to the subtitle of the book, which reads Crafting Rich Experiences with Progressive Enhancement. In this book, the term adaptive web design is used as an exact synonym for progressive enhancement.

Progressive enhancement

If I ask people what they mean when they use these terms I get as many different answers as there are people. Some reverse the terms and say that adaptive is just about layout and responsive is about everything. Others say responsive is about fluid grids, while adaptive is about media queries with fixed grids in them, both very limited definitions. And the opposite definition is used too, of course.

I don’t think there needs to be a difference between the terms. If it’s up to me, both responsive web design and adaptive web design are synonyms for progressive enhancement. I think Ethan’s definition is a little outdated and unnecessarily restrictive. I don’t think there’s a reason anymore to just talk about optimising layout, we should talk about optimising other features, and interactions too.

But what is it?

But, as is often the case, I could be wrong here. It could be that I haven’t thought about it long enough or that I don’t understand the reasons behind more restrictive definitions. I’d love to hear your opinion, since I’d love to be able to use these terms without causing confusion. Comments are open.

The drunkard’s search | 90 Percent Of Everything

An interesting little post by Harry Brignull about the drunkard's search: the idea that we search for solutions on the wrong, easiest places. http://vvg.gr/dc

Links for 1368447639 is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!

Device testing ⚒ Nerd

I've been wondering lately if we really should test on *as many* devices as possible. Shouldn't we better try to test on *as few* devices as possible instead? Here are some thoughts about this question. http://vvg.gr/da

Links for 1368401754 is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!

I know these things because I tested many sites on many different devices.

Do websites need to look perfect on every device?

We all know the classic website that answers the question: Do websites need to be experienced the same in every browser? The answer, of course, is nope. Back when this site was created, this was still a controversial idea to many, but now we all accept that websites can not be experienced the same everywhere. Of course we should do whatever we can to make it look acceptable, or even pretty, everywhere, but we also need to think about our budget. If we test our sites on all possible devices, with all possible browsers, and try to find fixes for all those crazy bugs those weird browsers have, our sites would never go live. I think it’s OK if some things look broken on some obscure gadgets.

So, should you not test?

Well, you should use as many devices as possible. By doing that, you understand these devices better. You understand how they work, how you interact with them, how websites look on them, etc. By testing websites in general on as many devices as you can find you understand the web better, and you understand how people see and consume your work better. This is not just important for developers and testers, I think it is even more important for designers to use as many devices as possible.

But I don’t think you should test all your work continuously on ten different configurations. And maybe I even start to believe it’s a waste of time to test on everything you can lay your hand on. I’ve written about testing and browser support before. Of course it would be nice if you could prevent obscure bugs on obscure devices from happening, but if you have the ability to fix these bugs once the site is live, why not let your visitors do the testing for you?

Experience

Of course, tools like LiveReload or Ghostlab make testing on devices much easier and probably even fast. And by using these tools, and by testing on as many devices as possible, you get to know the bugs and quirks of these devices. Which means that after a while you don’t have to test as much on all of them. Back in the IE6 days we would just type the necessary hacks just like we type sensible CSS, without thinking about it. This experience might grow when you test a lot.

So, it depends?

Today I read this tweet by David Hund who’s thinking about answering _all_ questions with “It depends…”. This was one of the reoccurring themes in the first edition of Mobilism. It all depends. When I read David’s tweet my intent was to write something with a clear and strong conclusion, like:

you should test on as few devices as possible.

And as much as I like that idea — and I even think it makes sense — I hate to admit that it depends.

Design lessons for programmers, curated by top designers | Hack Design

A great site for nerds who want to understand design better: This site will send you one design lesson a week. That's a nice pace, no hurry. But after a year you've followed more than 50 lessons, which is quite a lot. http://vvg.gr/cu

Links for Saturday, May the 11th in the year 2013 is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!

Soapbox Envy CSS is not an amoral monster.

Nice little rant/post about the fact that CSS is actually pretty good. http://undercaffeinated.tumblr.com/post/49878531442/css-is-not-an-amoral-monster

Links collected on Saturday, May the 11th in the year 2013 is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!

Responsive design is about more than just layout; it’s about designing for the Web, which means, mostly, for people with browsers. And that’s just about everything we know about the people who visit our websites: they are probably using a browser. All the rest we just don’t know.

Up until not so long ago, we used to base our designs on some rather general assumptions about screen size and input type. With the rise of devices with various screen sizes and alternative ways to interact, these assumptions have turned out to be unreliable. We need to upgrade the defaults that we use when we start designing our websites.

A Closer Look

People keep saying that the Web has changed. But has it really? Let’s take a look at all of the things that have actually changed.

Screen Sizes

In the 1990s, the Web was 640 pixels wide. In the early 2000s, it grew to 800 pixels. A few years later, we decided it should be 1024 pixels. But five years ago, all of a sudden, something strange happened. A device with a very small screen entered the market. Suddenly, our ideas about the size of the Web did not work anymore. Later on, tablets entered the market. People hold these things however they want. Today, the height of the viewport could be bigger than the width! But is that new? Not really.

Screen sizes, shown in a non-flexible medium. (Photo and work: Aram Bartholl)

We never really knew what size the window of our visitors would be. We just assumed it was at least the random pixel width that we felt comfortable with. These numbers were always arbitrary, and there were always people who could not see the entire website. We simply ignored them.

“Everyone Has a Mouse”

We’ve always assumed that everyone uses a mouse. Even though we knew that this was not always true, most designs completely ignored alternative ways of interacting. People who had to use a keyboard, for whatever reason, had a very hard time interacting with our websites.

But because most people did use a mouse, and because back then many designers thought that designing only for the majority was OK, we created websites that were unusable for a lot of people. And this turned out to be a growing number. Many mouseover interactions are completely dysfunctional on a touch device. Because people love these devices, and even managers and designers use them, they are harder to ignore.

“Everyone Has Broadband Internet”

Another thing we always assumed was that everyone had a super-fast Internet connection, at least as fast as our own. And if they didn’t already have it, they’d have it soon. This was again mostly true; speeds were increasing. But today, more and more people use crappy, unreliable 3G connections all the time. If you’ve ever travelled on a train in The Netherlands, you know what I mean. And if you’ve ever had to rely on the mythical “free hotel Wi-Fi,” then you know for sure that the assumption about the ever-increasing speed of our Internet connections is just not true. This is a big change in our thinking; we really should consider these users. This will have a major impact on what our designs look like.

“Everyone’s Computer Gets Faster Every Year”

It used to be true that computers would get faster and faster. If you waited half a year before buying a computer, you would get one that was twice as fast, for the same price. This was true of new desktop computers, but mobile devices have priorities other than processor speed. The most important thing for a phone, for instance, is battery life: you really don’t want to have to charge it after every phone call.

And there’s another trend: instead of creating ever-faster devices, many manufacturers are starting to sell ever-cheaper devices. Many people care about price and battery life more than about processor speed. This is also not new: what happened to your old computers? You probably sold them or gave them away. People keep using old stuff. Not everyone has the same hardware as we designers do.

“All Monitors Are Calibrated”

Well, we always knew this to be untrue, right? Only the monitors of visual professionals are calibrated. Most other monitors don’t display colors accurately, and many monitors are downright crappy. Most mobile phones that I’ve tested have pretty decent screens, until you start using them outside, in the sunshine. If you’re lucky, you can read the content, but you definitely cannot see the subtle gradients in low-contrast designs.

I haven’t even mentioned “modern” black and white screens. These, too, are not new. People have always used crappy monitors, and people with bad eyesight have always visited your websites. It’s just that more and more people are seeing a subpar color palette. Instead of buying a state of the art monitor, buying a cheap monitor and several low-end devices to test your work on might be a better investment.

All of these things are not new. In 2002, John Allsopp wrote the monumental article “A Dao of Web Design.” People such as Jeremy Keith and Roger Johansson have written about all of these facts for years and years. And yet, somehow, we’ve always managed to actively ignore them. But we really can’t anymore. The Web actually did change in the last five years, with new devices, new browsers and many, many cool new features. We need new defaults. The old ways of creating websites just don’t work anymore.

This Is Responsive, the excellent resource about responsive design by Brad Frost.

In the past few years, we’ve been actively researching new ways to deal with all of these different screen sizes. But apart from responsive design, there are many more challenges in today’s ever-growing pile of devices. We have to find new patterns of interaction: we need interfaces that work on any device. Maybe we have to reconsider that enormous photo carousel on the home page, now that we know that not everyone has a cheap and fast connection. New defaults are emerging, and I’ve collected a few for you here.

The things in this article are not new. Many clever people have written about them in many articles and many books. But these ideas, like all good stories, have to be repeated many times so that people understand and remember them.

New Default: Activate

I initially titled this section “New Default: Touch.” But I came to realize that “touch” has a different meaning for everyone. Some people, like me, think of a single tap when we hear the word. Others think about swiping and complex gestures. That’s why I settled on the heading “New Defaults: Activate.” All devices, no matter what kind of input they offer, let the user activate something in some way.

With a mouse, it’s a click; with a touch device, it’s a tap; on a keyboard, it’s the “Enter” key. There are ways to activate things by voice, and by waving your arms in the air. And many devices offer more than one way to interact. The only thing that all of these devices have in common is the action of activating. Most of them are capable of doing many other things, too, but all of them can activate stuff.

Only recently have we really started thinking about alternative methods of user input. We used to assume that everyone uses a mouse. Hiding content and showing it on mouseover was considered to be a decent design pattern. And it used to work for most people — until all of these wonderful touch devices entered the market. What should a device without a mouse do when content can be revealed only with a mouse? Different devices have different solutions. Let’s look at a simple drop-down menu.

See a live example of this navigation pattern.

When you hover over a menu item, a submenu appears. But apart from hovering over an item, you can also simply click on it to follow the link. Now, what should happen when you tap on the item with a touch device? Should the submenus appear, or should the link activate? Or both? Or should something else happen? On iOS, something else happens. The first time you tap a link like that, the submenu appears; in other words, the hover event fires. You have to tap a second time to actually follow the link. This is confusing, and not many people will tap a second time. On Android, the submenu appears and the link is followed simultaneously. I don’t have to explain to you that this is confusing.

It’s very well possible to think of complex solutions whereby you define different interactions for different input devices. But the better solution, I think, is to make sure that the default interaction, the activate event, just works for everybody. If you really need to, you could choose to enhance this default experience for certain users.

For instance, if you are certain that someone is using a mouse, you could enable some mouseover interactions. Or if you’re sure that someone has fat fingers, you could make small buttons a bit bigger. But only do so in addition to the default activate interaction, and only if there’s no doubt about it, and only if the enhancement would really make things better. Those are quite a few ifs, and some of them, such as the mouse usage, are very hard to detect — especially on devices that offer more than one way to interact, such as a laptop with an optional mouse, touch pad, camera, microphone, keyboard and touchscreen. Give it some serious thought. Do you really need to optimize for a mouse?

New Default: Small Screens

Growing is easy. Most things grow. Babies grow, trees grow, curious minds grow. They don’t grow by themselves, but you don’t need much energy to make things bigger. This is just what things do when they live. While shrinking things is definitely possible, it’s also much harder. You could, for instance, compress a car to a fraction of its original size. A compressed car does have a certain aesthetic appeal to it, but it is definitely not as useful as it was before. The same goes for websites. Shrinking a desktop website does not always result in a pleasant experience on a small screen.

Cedro di Versailles by Italian artist Giuseppe Penone clearly shows that things grow. On the other hand, the work Papalote Goliad by American artist John Chamberlain shows that shrinking can be aesthetically appealing but may result in less useful results.

To build a responsive website that works on all kinds of screens, designing for a small screen first is easiest. It forces you to focus on what’s really important: if it doesn’t fit in this small square, it is probably not terribly important. It forces you to think better about hierarchy, about the right order of components on the page.

The same principle that we follow for interactions — whereby we design the activate event first and enhance it later — applies to graphic design. We should start designing the things that we know everyone will see. That’s the content. No matter how big or small a screen is and no matter how minimal the feature set of a browser, it will be able to show letters. Because this is about the only thing we know for certain — since color is absent on most Kindles, most of the latest CSS doesn’t work on old browsers, and layout is of minor importance on small screens — starting with the text is logical.

I wrote an in-depth article about defining breakpoints on the basis of typography, so I won’t repeat every detail here. But the basic idea is that you start by designing the relationship between the different font sizes. Almost everyone, no matter what device they have, will be able to see this. When the typography is done, you would start designing the layout for bigger screens; you can think of this as an enhancement for people with bigger screens. And after that, when the different layouts are done, you could add the paint. And by paint, I mean color, gradients, borders, etc.

I’ve presented this as a very strict way of working; in real life, of course, things are not as rigid. I’m not talking about “activate only” or “small screen only.” When I say to start with typography, I don’t mean that you aren’t allowed to think about paint at the same time. Rather, I’m trying to find the things that all of these different devices, with all of their different screen sizes and all of their different features, have in common. It just seems logical to first design this shared core thoroughly. The strange thing is that this core is often overlooked: Web professionals tend to view their own creations with top-of-the-line devices with up-to-date browsers. They see only the enhancements. The shared core with the basic experience is often invisible.

New Default: Content

The way we designed our websites until recently was by putting a header with the logo and navigation at the top, putting the subnavigation on the left, putting some widgets on the right, and putting the footer at the bottom. When all of that was done, we’d cram the content into the little space that was left in the middle. All of the things we created first — the navigation, the widgets, the footer — they all helped the visitor to leave the page. But the visitor probably wanted to be there! That was weird. It was as if we were not so confident in our own content and tried our best to come up with something else that our guests might like.

But rather than pollute the page with all kinds of links to get people out of there, we should really focus on that thing in the middle. Make sure it works. Make sure it looks good. Make sure it’s readable. Make sure people will understand it and find it useful. Perhaps even delight them with it!

Once you’re done with the content, you can start to ask yourself whether this content needs a header. Or a logo. Or subnavigation. Does it need navigation at all? And does it really need all of those widgets? The answer to that last question is “No.” I’ve never understood what those widgets are for. I have never seen a useful widget. I have never seen a widget that’s better than white space.

Compare a typical news website’s attention to widgets with Medium’s complete focus on content.

By starting with the content first, you can come up with some very interesting solutions. For instance, does the logo really need to be at the top of every page? It could very well go in the footer on many websites; such as in digital style guides or on pages for registered users. Many links that we used to put in the subnavigation might work better in relevant spots in the main content.

For instance, the option to add extra luggage to a flight booking might be most effective right there in the overview of the flight, instead of in the middle of a list of links somewhere on the left of the page. And when looking at the hierarchy of a page, does the main navigation look more important than the main content? Most of the time it shouldn’t be, and I usually consider the navigation to be footer content. A simple “skip” link at the top of the page could either take the visitor to the navigation or fetch the navigation and show it at the top of the page.

In this era of responsive Web design, we need many new clever solutions. As we’ve seen here, our old defaults don’t work anymore. We need to reconsider how we work with interaction, how we approach design and how we shape our content. But we need to think about one other very important thing, and that is where our content comes from.

New Default: The API

Luke Wroblewski wrote a fantastic article about designing an application for the command line first, and then enhancing it for different needs. This is not just a nerdy idea, but a very practical idea, too. If you are able to design and develop your own application, you could test the functionality relatively easily before even starting to think about what it will look like on different devices. This requires designers to work with developers to design a feature that at first works only from the command line. If the feature does not work as expected, then you merely have to change the API, rather than also a bunch of visual designs. Once the API works as you want it to, enhancing it for all of the devices and screen sizes that you want to support becomes easier.

Most of the time, you wouldn’t design the entire API of the application that you’re building. Most companies would choose a content management system (CMS) of sorts or a specialized tool to help them achieve what they want to do. I’ve always been amazed that CMSes are so often chosen only by technical people and business people. This causes many problems during the design process.

Developers and business people have different goals than designers. Developers want stuff that is easy to develop on. Business people want stuff that’s cheap. But designers want to make the best and most beautiful things possible. These goals can easily conflict.

I’m not saying that designers alone should choose the system, but they should definitely be a part of the decision-making process. I’m convinced that the selection of CMSes will improve. And I’m convinced that CMS makers will start to improve their products once designers get involved. Right now, all CMSes I know of deliver hostile cruft unless you tweak them extensively.

But it works the other way around, too. If designers are involved in the selection process, they will have a say in the choice of tool and will understand how it works, what’s possible, what’s easy and what’s hard. This will result in designs that are based in part on the tool, not just on imagination. This is an important part of the design process that has not yet been optimized. Right now, the command line and the systems that deliver the content we design for are the domain of the developers, and designers have nothing to do with them. That is a pity. Just as you would want to take advantage of the knowledge of developers in the design process, you would want to take advantage of the knowledge of designers in the development process.

Progressive Enhancement

If you review the sections above, you’ll see that what I’ve described is nothing other than progressive enhancement. You start with the content, then design the content and optimize it for different screen sizes and devices, and after that you can further optimize for very specific features such as mouse usage and fat fingers. Many Web developers build websites according to this principle. They transform the beautiful Photoshop documents that they receive into all of the different layers described above.

This can work out fine if the developer has a good sense of design and a delicate attention to detail. But if they don’t — which is often the case — this can easily result in crappy usability and ugly details. I’m not saying that designers shouldn’t use Photoshop anymore. If that’s your tool, go ahead and use it. But do remember that you’re designing the layers of the Web, not the layers in Photoshop. There’s much more to the Web than a single beautiful image. People will see our creations in innumerable ways. We design for all of these people — remember that. We don’t just design for the CEO with a laptop. We also design for the people on the train and the people with “free hotel Wi-Fi.”

Tools

I’ve mentioned Photoshop a few times because it’s still widely misused for designing websites. One reason we have a hard time with progressive enhancement in the design process is due to a lack of good Web design tools. The tools we use are built to wow; they mostly help you to create the “paint,” not to design the core. Fortunately, more tools are popping up with very specific functions in the design process. These are micro-tools such as the International Measure Slider, which helps you to define breakpoints in your grid; tools such as Gridset, which helps you to create grids for different screen sizes; and excellent tools that help you to define typography. By incorporating these tools into our design workflow, we might start making better stuff.

Conclusion

The Web has always been a weird, borderless, flexible medium. In the last couple of years, we’ve started to realize that designing for this medium is fundamentally different from the design work we’ve done previously. The fixed dimensions and the singular ways of interacting that formed the basis of all types of media that we’ve worked with for centuries just don’t work on the Web. This truly is a unique medium.

We have to find new defaults, new starting points for our design process. I’ve explained some of these new defaults here, but of course there are many more. The way we work with forms, for instance, could probably use a whole series of articles by itself. Some new starting points are well established by now, but I’m sure many more will be invented in the near future. I am curious to hear about new patterns and new defaults that you have discovered and have used successfully in your projects.

Men gaat er van uit dat de mensen die de wireframes maken alles weten. Ze moeten verstand hebben van interactie, van content, van hiërarchie, van layout, van design en van techniek. Alle keuzes die ze maken zijn bepalend voor hoe de websites er uiteindelijk uit gaat zien en hoe de website gaat werken. Ik ken veel interactie-ontwerpers, en ze zijn bijna allemaal buitengewoon intelligent en getalenteerd. Maar alwetend zijn ze geen van allen. Zo veel verantwoordelijkheid neerleggen bij één enkel persoon, en de kennis van alle anderen negeren is — simpel gezegd — dom.

Kleurplaten

Een paar jaar geleden ging een oud-collega van mij, een interactie-ontwerper, ergens anders werken. Voor zijn vertrek nam hij zijn portfolio nog even met mij door: aan de linkerkant zijn wireframes, rechts het uiteindelijke resultaat. Het leken wel kleurplaten uit de kleurboekjes van mijn dochtertje. Door deze werkwijze was de rol van de visual designer verworden tot een simpele inkleurder. Een stylist. Met de vakkennis van designers over verhoudingen, proporties, layout — maar ook de eigen ervaring met het web — werd niks gedaan. Het was de taak van de designer om een zo mooi mogelijk plaatje te maken, niet om actief mee te denken over de beste oplossing. Die was namelijk al verzonnen.

Technisch onmogelijk

Ik moest ooit eens HTML templates maken van een set ontwerpen in Photoshop. Een blik op de — overigens prachtige — plaatjes was genoeg om te zien dat het technisch onmogelijk was om hier HTML van te maken. Sommige dingen werken nu eenmaal wél in fotobewerkingssoftware maar niet op het web. Het probleem was alleen dat de klant de plaatjes al had goedgekeurd en verwachtte dat alles er exact zo uit zou komen te zien. Ik ben nog met ze in gesprek gegaan maar ze waren onverbiddelijk. Ik heb de grenzen van het mogelijke moeten overschrijden om aan deze onzinnige eis te voldoen. Het resultaat was een brei van bizar complexe HTML en CSS gedrenkt in een smerige poel van JavaScript. Met andere woorden, het was een zooitje. Het zag er wel precies zo uit als gewenst. In alle browsers. Ik hoef waarschijnlijk niet uit te leggen dat de developers die aan de slag moesten met mijn werk niet zo blij waren. Ze hebben er letterlijk twee jaar over gedaan om van die rotzooi iets werkends te maken. Belachelijk.

Lopende band

In de watervalmethode moet elke deliverable eerst afgevinkt worden voordat er verder gewerkt kan worden. Dit werkt prima in een fabriek, maar in een specialistisch gebied als web design levert het slechte producten op waar iedereen gefrustreerd over is: de klant is ontevreden met het uiteindelijke resultaat omdat het lang niet zo mooi is als de photoshop-documenten, de designer is om dezelfde reden niet blij en de developers zijn ongelukkig omdat zij overal de schuld van krijgen terwijl ze totaal geen invloed hadden op de totstandkoming van het ontwerp. Krankzinnig. Ronduit idioot. En toch wordt er nog steeds zo gewerkt. Nee, ik weet ook niet waarom.

Dat moet anders

De oplossing klinkt eenvoudig. Laat iedereen gewoon samenwerken. Betrek de developers, de designers, de interactie-ontwerpers en de klant bij de design fase. Laat iedereen meedenken. Layouts worden beter door de bemoeienis van designers, de contentstructuur wordt beter door de invloed van developers, typografie wordt realistischer doordat de front-ender wél weet wat er wel en niet kan. Gebruik naast de talenten van iedereen ook betere tools, tools die geschikt zijn voor het web. Ontwerp een site dus niet in z’n geheel in fotobewerkingssoftware maar werk vanaf het begin direct in de browser. Photoshop is perfect om foto’s mee te bewerken. Het is totaal niet geschikt om de flexibele natuur van het web mee vorm te geven.

Dit klinkt allemaal eenvoudig. Gewoon samenwerken, gewoon andere tools gaan gebruiken. Maar slechte gewoontes afleren is lastig. Het heeft tijd nodig. En we moeten er veel over lezen. Gelukkig wordt er aardig veel over geblogd, en gelukkig heeft collega columnist Stephen Hay een fantastisch boek geschreven over dit onderwerp. Hij legt prachtig uit waar onze werkwijze vandaan komt, en wat er allemaal aan schort. Hij komt ook met geniale tips en oplossingen om tot betere ontwerpen te komen. Laat je niet afschrikken door de soms extreem nerdy werkwijze die hij propageert. Als het te technisch is, lees vooral door, het boek staat vól met prachtige inzichten. Maar wees ook niet te bang voor de nerdy tools die hij gebruikt. Het zijn momenteel de enige echt geschikte tools om echt goede websites mee te maken. Helaas.

This year’s killer feature? You can now use fonts on a computer. My twitter feed exploded with joy. AMAZING! WE CAN NOW USE FONTS ON OUR COMPUTERS!

And another one. You can now edit the corner radius of a rectangle path. With a computer. Really. And people were celebrating.

Sometimes people amaze me.

Maybe, instead of paying a monthly extortion fee and being manipulated, you could spend a few months worth of Adobe rent on some of the new, design tools, like Sketch (which lets you edit the corner radius of a rectangle path, for a one time fee of 50 dollars) or Acorn (which probably does that too).

UPDATE: Cyriel pointed me in the direction of the killer feature. I’m sold.

Specialists

There seems to be a trend to devaluate the value of good specialists. I think we shouldn’t blame the specialists but take a good, critical look at the process instead. This thinking about specialisms was triggered by a meeting I had with some colleagues where I didn’t understand most of what was said.

Books

I did read some — highly recommended — books too. A quote in a small book about typography by Tim Brown made me realise again that every specialist must understand the value of their profession in the bigger scheme of things.

Stephen Hay wrote a book about the responsive design workflow. I could have quoted the whole book, but instead I wrote this very positive review. You should just buy it, it’s absolutely worth it.

Right now I’m enjoying the new book by Peter Gasston about the modern web. A quote in the introduction made me think about the fact that not all new hardware is getting faster, which is a new but important trend.

Stories

The incredible Bret Victor released a video of one of his talks in which he argues that many of the applications we use to create computer art don’t create computer art. The create emulations of older art forms. An incredible talk, as always. I changed one of his quotes a bit so I could easily make the same statement about web design tools. Which is a pet pieve of mine.

Just like the lack of interest in progressive enhancement. I just can’t stop talking about it. I even spoil fascinating stories about my grandparents with moralising endings about progressive enhancement. Just like my grandparents used to do with their god. I’m getting old, hahaha.

Nonsense

So instead of idling, I’ve been writing useful stuff. But the writing I’m most happy about is what I did on my resurrected blog Love Nonsense. I wrote a small welcome back message about the state of Nothing, and I wrote a longer piece about the beauty of QR-codes, thanks to a wonderful present some friends gave me.

The Daily Nerd

I did not update the Daily Nerd at all last week. I did read some interesting articles, but instead of collecting them here, I tweeted them right away. If you don’t mind a mix of Dutch and English tweets, and you want to read what I link to, you might want to follow me on twitter, since this site will not be updated as much anymore. Definitely not on a daily basis. I found out that I enjoy writing longer blogposts more than writing small comments.

It’s been a busy holiday is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!

The thing on our wall that she was taking pictures of is a work of art, called RIJKS VASILIS. A while ago I came home and it was just there, without any explanation. A big triangle, pointing towards the words RIJKS VASILIS. The triangle consist of 28 QR-codes that direct you towards some lovely works of art, and to one picture of a salad. To truly understand this work, you have to know that I hate QR-codes and that I love the new website of the Rijksmuseum. This work is made by my beloved friends Robert-Jan Verkade, Marrije Schaake and Maaike de Laat with the help of my even more beloved wife Katrien Vermeulen. I’ve tried to figure out why exactly they made it elsewhere.

It’s a weird object. While I think QR-codes are among the most ugly inventions ever made by humans, this thing is actually nice to look at. The repeating pattern is nice, but the geometric shape is a bit clumsy, which makes it human: The codes are all the same size, but the borders around them are of various widths. And then, the distance between them varies too. Compulsive people should probably not look at it for too long, but others might agree with me that exact symmetry and perfection are boring: even without a QR-scanner this is a fascinating thing to look at.

There is a website of this work, with all the QR-codes on it, so you can enjoy the works too. The website lacks the sloppiness, but does have some wonderful things to think about. For instance, I love opening the URL in the browser on my phone. And not because it looks so nice. The only way to actually see the pictures behind the QR-codes is by using an app on another phone. And I don’t have another phone. But I do have my memory so I just look at the codes and imagine looking at The Nachtwacht. Or that weird Japanese print of a giant cucumber with a cricket on it. Or the inspiring painting of the household of Jan Steen. Who would have ever thought that, to amuse myself, I would be looking at QR-codes.

Finally the weather is getting better here in The Netherlands, so my daughter and I were playing outside, on the doorstep. Suddenly my daughter cried out with joy! Close to us a van was parked with a QR-code printed on it. Would it be a beautiful painting of a swan? Would it be that marvellous statuette of a rabbit? Would it be the salad or one of the amazing old Japanese prints? She still doesn’t get it. Why would anyone, ever, want to point towards a crappy contractor’s site?

The last post I wrote on this blog was about Nothing, and after that post, nothing happened here. On the site one nothing a day, more than 400 nothings have been published since, though. It is by far the most active project I’ve ever made. And the most lazy project: It updates itself while I procrastinate. Or while I do useful stuff. I still think it’s a wonderful site and every night still get a bit excited when I click on yet another fresh, random nothing.

A while ago I was curious about all the different colours that were generated in the past year. So I created this page with just the colours, not the letters. The function I wrote to pick a random colour is not so random. Several patterns can be found by resizing the browser window, or by scrolling the page. Colours are clearly not chosen randomly and there are dark and light periods, and maybe even more and less saturated periods too. We could investigate why exactly this happens. Or we could just enjoy resizing our browser window in an endless procrastination loop.

I hope this post will inspire me to write more about my dear nonsense.

That’s actually more complex question than you might think. In the past it was always the case that computers got faster every year. The price of a computer didn’t change that much, but the speed doubled every six months or so. For a very long time, this was an actual fact. But with phones things are a bit different. For a phone it’s most important that the battery lasts all day. More important than speed. You don’t want to recharge it after every website you visit.

Batteries are improving, chips get more energy efficient, so phones do get faster, just like computers used to do. But there’s another trend: phones get cheaper too. Five years ago, a smart phone might cost you 1000 euros, right now you can buy a new phone with similar specs for 100 euros or less. It could very well be that in a while you can buy phones for 5 euro, why not. This should have a major impact on web design: our websites have to work on the fastest new computers with the fastest possible internet connections. And at the same time they have to work on equally new, cheap smartphones with a flaky 3G connection.

Performance is getting more and more important than it already was. It should really be an integral part of the whole design process.

Without behaviour, it’s not native

In the beginning of this talk he explains that the programs mostly used for computer art are not good enough. With Photoshop you can make beautiful images, but they are static, it’s an emulation of what we had before: paper. Programs like After Effects are great for making animations, but this too is an emulation of what we had before: TV. You can look at it, but it won’t react to what you do. So he proposes a different tool which enables the artist to create stuff that reacts to input. It gives the artist the possibility to react to input from the public. If people laugh, you can repeat a certain joke, for instance. This is of course not possible with tools like Photoshop and After Effects.

The web

I was surprised to see that different fields of work have issues with Adobe products too, for similar reasons. Somehow Adobe is very good at selling products that are not really innovative, and somehow people keep using them, and thus are limited in their creativity. It’s easy to make a comparison between computer arts and the web by changing Bret’s quote to this:

Without adaption, it’s not the Web

Photoshop is an excellent tool to create an image of one single state of a website, but you can’t design a website with it. Websites react to the environment. If it’s viewed on a small device it will look different than when it’s viewed on a big screen. It can react differently to input from a mouse than input from a fat finger. Fonts will differ on various operating systems and browsers. Interactions will vary depending on the availability of features, like JavaScript or geoLocation. You could create flat, dead impressions of all these possible states in Photoshop, or you could use a different tool.

Again, tools

Unfortunately, there are no good all purpose web design tools yet. There are micro tools like the International Measure Slider that help you in defining breakpoints for your grid. There are tools like Gridset that help you with creating grids for different screen sizes. There are excellent tools that help you define typography. And there are new graphics editors like Acorn. For a fraction of the price of Photoshop you can design better websites with the use of these tools. Especially when you get rid of your fear of code.

Five Simple Steps – Combining Typefaces

Today I finished reading the new Pocket Guide called Combining Typefaces by Tim Brown. An excellent book. I learnt an awful lot about typography while reading it. I'm not a pro now, but I think I understand the basics and I know where to look for further information. I highly recommend this book to all web designers and developers.

book design typography

More or less arbitrary designations is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!

scottjehl/css-inapplicable-load · GitHub

A very interesting test case by Scott Jehl. What so browsers do with linked stylesheets that are not immediately needed? Like media="(min-width: 45em)" in a small window.

css performance browsers

We can’t infer intent is published on The Daily Nerd.
The Daily Nerd by Vasilis van Gemert is licensed under the Creative Commons Attribution 3.0 Unported license. Use it in another way? You can always ask.
Are you happy with the Daily Nerd? Buy an original Daily Nerd t-shirt!