web – Leapfroglog

Prototyping in the browser

When you are designing a web site or web app I think you should prototype in the browser. Why? You might as well ask why prototype at all. Answer: To enable continuous testing and refinement of your design. Since you are designing for the web it makes sense to do this testing and refinement with an artefact composed of the web’s material.

There are many ways to do prototyping. A common way is to make wireframes and then make them ‘clickable’. But when I am designing a web site or a web app and I get to the point where it is time to do wireframes I often prefer to go straight to the browser.

Before this step I have sketched out all the screens on paper of course. I have done multiple sketches of each page. I’ve had them critiqued by team members and I have reworked them.

Drawing pictures of web pages

But then I open my drawing program—Sketch, in my case—and my heart sinks. Not because Sketch sucks. Sketch is great. But it somehow feels wrong to draw pictures of web pages on my screen. I find it cumbersome. My drawing program does not behave like a browser. That is to say in stead of defining a bunch of rules for elements and having the browser figure out how to render them on a page together I need to follow those rules myself in my head as I put each element in its place.

And don’t get me started on how wireframes are supposed to be without visual design. That is nonsense. If you are using contrast, repetition, alignment and proximity, you are doing layout. That is visual design. I can’t stand wireframes with a bad visual hierarchy.

If I persevere, and I have a set of wireframes in my drawing program, they are static. I can’t use them. I then need to export them to some other often clunky program to make the pictures clickable. Which always results in a poor resemblance of the actual experience. (I use Marvel. It’s okay but it is hardly a joy to use. For mobile apps I still use it, for web sites I prefer not to.)

Prototyping in the browser

When I prototype in the browser I don’t have to deal with these issues. I am doing layout in a way that is native to the medium. And once I have some pages set up they are immediately usable. So I can hand it to someone, a team member or a test participant, and let them play with it.

That is why, for web sites and web apps, I skip wireframes altogether and prototype in the browser. I do not know how common this is in the industry nowadays. So I thought I would share my approach here. It may be of use to some.

It used to be the case that it was quite a bit of hassle to get up and running with a browser prototype so naturally opening a drawing package seemed more attractive. Not so anymore. Tools have come a long way. Case in point: My setup nowadays involves zero screwing around on the command line.

CodeKit

The core of it is a paid-for Mac app called CodeKit, a so-called task manager. It allows you to install a front-end development framework I like called Zurb Foundation with a couple of clicks and has a built in web server so you can play with your prototype on any device on your local network. As you make changes to the code of your prototype it gets automatically updated on all your devices. No more manual refreshing. Saves a huge amount of time.

I know you can do most of what CodeKit does for you with stuff like Grunt but that involves tedious configuration and working the command line. This is fine when you’re a developer, but not fine when you are a designer. I want to be up and running as fast as possible. CodeKit allows me to do that and has some other features built in that are ideal for prototyping which I will talk about more below. Long story short: CodeKit has saved me a huge amount of time and is well worth the money.

Okay so on with the show. Yes, this whole prototyping in the browser thing involves ‘coding’. But honestly, if you can’t write some HTML and CSS you really shouldn’t be doing design for the web in the first place. I don’t care if you consider yourself a UX designer and somehow above all this lowly technical stuff. You are not. Nobody is saying you should become a frontend developer but you need to have an acquaintance with the materials your product is made of. Follow a few courses on Codecadamy or something. There really isn’t an excuse anymore these days for not knowing this stuff. If you want to level up, learn SASS.

Zurb Foundation

I like Zurb Foundation because it offers a coherent and comprehensive library of elements which covers almost all the common patterns found in web sites and apps. It offers a grid and some default typography styles as well. All of it doesn’t look flashy at all which is how I like it when I am prototyping. A prototype at this stage does not require personality yet. Just a clear visual hierarchy. Working with Foundation is almost like playing with LEGO. You just click together the stuff you need. It’s painless and looks and works great.

I hardly do any styling but the few changes I do want to make I can easily add to Foundation’s app.scss using SASS. I usually have a few styles in there for tweaking some margins on particular elements, for example a footer. But I try to focus on the structure and behaviour of my pages and for that I am mostly doing HTML.

GitHub

Testing locally I already mentioned. For that, CodeKit has you covered. Of course, you want to be able to share your prototype with others. For this I like to use GitHub and their Pages feature. Once again, using their desktop client, this involves zero command line work. You just add the folder with your CodeKit project as a new repository and sync it with GitHub. Then you need to add a branch named ‘gh-pages’ and do ‘update from master’. Presto, your prototype is now on the web for anyone with the URL to see and use. Perfect if you’re working in a distributed team.

Don’t be intimidated by using GitHub. Their on-boarding is pretty impressive nowadays. You’ll be up and running in no time. Using version control, even if it is just you working on the prototype, adds some much needed structure and control over changes. And when you are collaborating on your prototype with team members it is indispensable.

But in most cases I am the only one building the prototype so I just work on the master branch and once every while I update the gh-pages branch from master and sync it and I am done. If you use Slack you can add a GitHub bot to a channel and have your team members receive an automatic update every time you change the prototype.

The Kit Language

If your project is of any size beyond the very small you will likely have repeating elements in your design. Headers, footers, recurring widgets and so on. CodeKit has recently added support for something called the Kit Language. This adds support for imports and variables to regular HTML. It is absolutely great for prototyping. For each repeating element you create a ‘partial’ and import it wherever you need it. Variables are great for changing the contents of such repeating elements. CodeKit compiles it all into plain static HTML for you so your prototype runs anywhere.

The Kit Language really was the missing piece of the puzzle for me. With it in place I am very comfortable recommending this way of working to anyone.

So that’s my setup: CodeKit, Zurb Foundation and GitHub. Together they make for a very pleasant and productive way to do prototyping in the browser. I don’t imagine myself going back to drawing pictures of web pages anytime soon.

Blank banners — see me speak at TWAB 2008

In 1966 Provo took to the streets of Amsterdam with blank protest banners.¹ The use of rousing slogans had been outlawed by the city’s mayor. The ‘protesters’ were arrested. Provo achieved their goal of making the authorities look silly by playing at protesting.

They took existing rules and decided to play within them, to see how far they could push the limits of those rules. They were not allowed to use actual slogans, so they decided to use unwritten banners. They made use of the ambiguous nature of play: They were protesting, but at the same time not protesting. There were no forbidden slogans on their banners, but at the same time, the slogans were ever so present through their absence.

The police were not willing to take on Provo’s ludic attitude. They refused to step into their magic circle and play at opposing them. In stead they broke the rules, arrested them for real, and by doing so, lost—at least in the public’s eye.

This example—and hopefully a few others—I will discuss at The Web and Beyond 2008: Mobility. In 20 minutes or so, I hope to inspire designers to think about what the near future’s blank banners could be. My session is titled ‘Mobile components for playful cultural resistance’ (an unwieldy title in desperate need of improvement) and will probably be in Dutch.

The conference is organised by Chi Nederland and will take place May 22 in the beautiful Beurs van Berlage in Amsterdam. Keynote speakers include Ben Cerveny, Jyri Engeström and Adam Greenfield. It looks like this will be a very special conference indeed.

Image source: Gramschap.

Provo was a Dutch counterculture movement in the mid-1960s that focused on provoking violent responses from authorities using non-violent bait. Read more about them at Wikipedia. [↩]

Google Reader improvements

I hadn’t touched Google Reader since taking a brief look at its initial launch in October 2005. I’m now using it as my primary reader, having grown tired of Rojo‘s poor performance and frequent interface overhauls. There’s a few things that have really improved since that first release. I’ll sum them up briefly here:

Uncluttered, simple interface. They’ve gone back to basics and mimic a plain desktop application UI. Hardly any superfluous web 2.0 features demand your attention.
Trends page (I’ve bookmarked a few articles on this); which allows you to look at the feeds you’ve been reading the most but, more importantly, allow you to weed out the ones you never look at or have died. Essential for someone who has over 200 feeds to track.
Multi-folder organising, not quite free tagging (which is a shame) but still nice for the folksonomically inclined.
When scrolling through a list of expanded new feed items, Reader automatically marks items you’ve scrolled past as read. Which greatly reduces the excise other web-based readers force on their users when wanting to mark a feed as read.
Performance is acceptable to good. It’s not as fast as Gmail, but vastly superior to Rojo for instance, despite the considerable use of AJAX.
There is an unofficial Mac OS X notifier that uses Growl.

Most of these features are not included in one or both of the previous two web-based readers I used for a length of time (Bloglines and Rojo). Google have really come up with something nice here. I wonder when it’ll move out of the lab.

Why am I not using a desktop based reader? I’d like to (NetNewsWire‘s great for instance), just as I’d love to use a proper desktop email client, but my multi-platform, multi-machine personal and professional use doesn’t allow me too. I work on at least two separate PCs at work (a desktop and a laptop) and have a cute little iBook that I use at home. This all means I am a real web OS user. Firefox as browser (with Google Browser Sync to keep it the same across all installs), Google Reader for RSS, Gmail for email and (until recently) Google Calendar for, well, my calendar. Is it coincidence I seem to prefer Google products for these things? Probably not, Google seems to be doing a very good job at these kind of productivity applications (just as Yahoo! seem to be leading the way in social applications).