Prototyping in the browser

When you are design­ing a web site or web app I think you should pro­to­type in the brows­er. Why? You might as well ask why pro­to­type at all. Answer: To enable con­tin­u­ous test­ing and refine­ment of your design. Since you are design­ing for the web it makes sense to do this test­ing and refine­ment with an arte­fact com­posed of the web’s mate­r­i­al.

There are many ways to do pro­to­typ­ing. A com­mon way is to make wire­frames and then make them ‘click­able’. But when I am design­ing a web site or a web app and I get to the point where it is time to do wire­frames I often pre­fer to go straight to the brows­er.

Before this step I have sketched out all the screens on paper of course. I have done mul­ti­ple sketch­es of each page. I’ve had them cri­tiqued by team mem­bers and I have reworked them.

Drawing pictures of web pages

But then I open my draw­ing pro­gram—Sketch, in my case—and my heart sinks. Not because Sketch sucks. Sketch is great. But it some­how feels wrong to draw pic­tures of web pages on my screen. I find it cum­ber­some. My draw­ing pro­gram does not behave like a brows­er. That is to say in stead of defin­ing a bunch of rules for ele­ments and hav­ing the brows­er fig­ure out how to ren­der them on a page togeth­er I need to fol­low those rules myself in my head as I put each ele­ment in its place.

And don’t get me start­ed on how wire­frames are sup­posed to be with­out visu­al design. That is non­sense. If you are using con­trast, rep­e­ti­tion, align­ment and prox­im­i­ty, you are doing lay­out. That is visu­al design. I can’t stand wire­frames with a bad visu­al hier­ar­chy.

If I per­se­vere, and I have a set of wire­frames in my draw­ing pro­gram, they are sta­t­ic. I can’t use them. I then need to export them to some oth­er often clunky pro­gram to make the pic­tures click­able. Which always results in a poor resem­blance of the actu­al expe­ri­ence. (I use Mar­vel. It’s okay but it is hard­ly a joy to use. For mobile apps I still use it, for web sites I pre­fer not to.)

Prototyping in the browser

When I pro­to­type in the brows­er I don’t have to deal with these issues. I am doing lay­out in a way that is native to the medi­um. And once I have some pages set up they are imme­di­ate­ly usable. So I can hand it to some­one, a team mem­ber or a test par­tic­i­pant, and let them play with it.

That is why, for web sites and web apps, I skip wire­frames alto­geth­er and pro­to­type in the brows­er. I do not know how com­mon this is in the indus­try nowa­days. 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 has­sle to get up and run­ning with a brows­er pro­to­type so nat­u­ral­ly open­ing a draw­ing pack­age seemed more attrac­tive. Not so any­more. Tools have come a long way. Case in point: My set­up nowa­days involves zero screw­ing around on the com­mand line.

CodeKit

The core of it is a paid-for Mac app called CodeK­it, a so-called task man­ag­er. It allows you to install a front-end devel­op­ment frame­work I like called Zurb Foun­da­tion with a cou­ple of clicks and has a built in web serv­er so you can play with your pro­to­type on any device on your local net­work. As you make changes to the code of your pro­to­type it gets auto­mat­i­cal­ly updat­ed on all your devices. No more man­u­al refresh­ing. Saves a huge amount of time.

I know you can do most of what CodeK­it does for you with stuff like Grunt but that involves tedious con­fig­u­ra­tion and work­ing the com­mand line. This is fine when you’re a devel­op­er, but not fine when you are a design­er. I want to be up and run­ning as fast as pos­si­ble. CodeK­it allows me to do that and has some oth­er fea­tures built in that are ide­al for pro­to­typ­ing which I will talk about more below. Long sto­ry short: CodeK­it has saved me a huge amount of time and is well worth the mon­ey.

Okay so on with the show. Yes, this whole pro­to­typ­ing in the brows­er thing involves ‘cod­ing’. But hon­est­ly, if you can’t write some HTML and CSS you real­ly shouldn’t be doing design for the web in the first place. I don’t care if you con­sid­er your­self a UX design­er and some­how above all this low­ly tech­ni­cal stuff. You are not. Nobody is say­ing you should become a fron­tend devel­op­er but you need to have an acquain­tance with the mate­ri­als your prod­uct is made of. Fol­low a few cours­es on Codecadamy or some­thing. There real­ly isn’t an excuse any­more these days for not know­ing this stuff. If you want to lev­el up, learn SASS.

Zurb Foundation

I like Zurb Foun­da­tion because it offers a coher­ent and com­pre­hen­sive library of ele­ments which cov­ers almost all the com­mon pat­terns found in web sites and apps. It offers a grid and some default typog­ra­phy styles as well. All of it doesn’t look flashy at all which is how I like it when I am pro­to­typ­ing. A pro­to­type at this stage does not require per­son­al­i­ty yet. Just a clear visu­al hier­ar­chy. Work­ing with Foun­da­tion is almost like play­ing with LEGO. You just click togeth­er the stuff you need. It’s pain­less and looks and works great.

I hard­ly do any styling but the few changes I do want to make I can eas­i­ly add to Foundation’s app.scss using SASS. I usu­al­ly have a few styles in there for tweak­ing some mar­gins on par­tic­u­lar ele­ments, for exam­ple a foot­er. But I try to focus on the struc­ture and behav­iour of my pages and for that I am most­ly doing HTML.

GitHub

Test­ing local­ly I already men­tioned. For that, CodeK­it has you cov­ered. Of course, you want to be able to share your pro­to­type with oth­ers. For this I like to use GitHub and their Pages fea­ture. Once again, using their desk­top client, this involves zero com­mand line work. You just add the fold­er with your CodeK­it project as a new repos­i­to­ry and sync it with GitHub. Then you need to add a branch named ‘gh-pages’ and do ‘update from mas­ter’. Presto, your pro­to­type is now on the web for any­one with the URL to see and use. Per­fect if you’re work­ing in a dis­trib­uted team.

Don’t be intim­i­dat­ed by using GitHub. Their on-board­ing is pret­ty impres­sive nowa­days. You’ll be up and run­ning in no time. Using ver­sion con­trol, even if it is just you work­ing on the pro­to­type, adds some much need­ed struc­ture and con­trol over changes. And when you are col­lab­o­rat­ing on your pro­to­type with team mem­bers it is indis­pens­able.

But in most cas­es I am the only one build­ing the pro­to­type so I just work on the mas­ter branch and once every while I update the gh-pages branch from mas­ter and sync it and I am done. If you use Slack you can add a GitHub bot to a chan­nel and have your team mem­bers receive an auto­mat­ic update every time you change the pro­to­type.

The Kit Language

If your project is of any size beyond the very small you will like­ly have repeat­ing ele­ments in your design. Head­ers, foot­ers, recur­ring wid­gets and so on. CodeK­it has recent­ly added sup­port for some­thing called the Kit Lan­guage. This adds sup­port for imports and vari­ables to reg­u­lar HTML. It is absolute­ly great for pro­to­typ­ing. For each repeat­ing ele­ment you cre­ate a ‘par­tial’ and import it wher­ev­er you need it. Vari­ables are great for chang­ing the con­tents of such repeat­ing ele­ments. CodeK­it com­piles it all into plain sta­t­ic HTML for you so your pro­to­type runs any­where.

The Kit Lan­guage real­ly was the miss­ing piece of the puz­zle for me. With it in place I am very com­fort­able rec­om­mend­ing this way of work­ing to any­one.

So that’s my set­up: CodeK­it, Zurb Foun­da­tion and GitHub. Togeth­er they make for a very pleas­ant and pro­duc­tive way to do pro­to­typ­ing in the brows­er. I don’t imag­ine myself going back to draw­ing pic­tures of web pages any­time soon.

Blank banners — see me speak at TWAB 2008

Provo protesting with blank banner

In 1966 Pro­vo took to the streets of Ams­ter­dam with blank protest ban­ners.1 The use of rous­ing slo­gans had been out­lawed by the city’s may­or. The ‘pro­test­ers’ were arrest­ed. Pro­vo achieved their goal of mak­ing the author­i­ties look sil­ly by play­ing at protest­ing.

They took exist­ing rules and decid­ed to play with­in them, to see how far they could push the lim­its of those rules. They were not allowed to use actu­al slo­gans, so they decid­ed to use unwrit­ten ban­ners. They made use of the ambigu­ous nature of play: They were protest­ing, but at the same time not protest­ing. There were no for­bid­den slo­gans on their ban­ners, but at the same time, the slo­gans were ever so present through their absence.

The police were not will­ing to take on Provo’s ludic atti­tude. They refused to step into their mag­ic cir­cle and play at oppos­ing them. In stead they broke the rules, arrest­ed them for real, and by doing so, lost—at least in the public’s eye.

This example—and hope­ful­ly a few others—I will dis­cuss at The Web and Beyond 2008: Mobil­i­ty. In 20 min­utes or so, I hope to inspire design­ers to think about what the near future’s blank ban­ners could be. My ses­sion is titled ‘Mobile com­po­nents for play­ful cul­tur­al resis­tance’ (an unwieldy title in des­per­ate need of improve­ment) and will prob­a­bly be in Dutch.

The con­fer­ence is organ­ised by Chi Ned­er­land and will take place May 22 in the beau­ti­ful Beurs van Berlage in Ams­ter­dam. Keynote speak­ers include Ben Cer­ve­ny, Jyri Engeström and Adam Green­field. It looks like this will be a very spe­cial con­fer­ence indeed.

Image source: Gram­schap.

  1. Pro­vo was a Dutch coun­ter­cul­ture move­ment in the mid-1960s that focused on pro­vok­ing vio­lent respons­es from author­i­ties using non-vio­lent bait. Read more about them at Wikipedia. []

Google Reader improvements

The new Google Reader trends page

I hadn’t touched Google Read­er since tak­ing a brief look at its ini­tial launch in Octo­ber 2005. I’m now using it as my pri­ma­ry read­er, hav­ing grown tired of Rojo’s poor per­for­mance and fre­quent inter­face over­hauls. There’s a few things that have real­ly improved since that first release. I’ll sum them up briefly here:

  • Unclut­tered, sim­ple inter­face. They’ve gone back to basics and mim­ic a plain desk­top appli­ca­tion UI. Hard­ly any super­flu­ous web 2.0 fea­tures demand your atten­tion.
  • Trends page (I’ve book­marked a few arti­cles on this); which allows you to look at the feeds you’ve been read­ing the most but, more impor­tant­ly, allow you to weed out the ones you nev­er look at or have died. Essen­tial for some­one who has over 200 feeds to track.
  • Mul­ti-fold­er organ­is­ing, not quite free tag­ging (which is a shame) but still nice for the folk­so­nom­i­cal­ly inclined.
  • When scrolling through a list of expand­ed new feed items, Read­er auto­mat­i­cal­ly marks items you’ve scrolled past as read. Which great­ly reduces the excise oth­er web-based read­ers force on their users when want­i­ng to mark a feed as read.
  • Per­for­mance is accept­able to good. It’s not as fast as Gmail, but vast­ly supe­ri­or to Rojo for instance, despite the con­sid­er­able use of AJAX.
  • There is an unof­fi­cial Mac OS X noti­fi­er that uses Growl.

Most of these fea­tures are not includ­ed in one or both of the pre­vi­ous two web-based read­ers I used for a length of time (Blog­lines and Rojo). Google have real­ly come up with some­thing nice here. I won­der when it’ll move out of the lab.

Why am I not using a desk­top based read­er? I’d like to (Net­NewsWire’s great for instance), just as I’d love to use a prop­er desk­top email client, but my mul­ti-plat­form, mul­ti-machine per­son­al and pro­fes­sion­al use doesn’t allow me too. I work on at least two sep­a­rate PCs at work (a desk­top and a lap­top) and have a cute lit­tle iBook that I use at home. This all means I am a real web OS user. Fire­fox as brows­er (with Google Brows­er Sync to keep it the same across all installs), Google Read­er for RSS, Gmail for email and (until recent­ly) Google Cal­en­dar for, well, my cal­en­dar. Is it coin­ci­dence I seem to pre­fer Google prod­ucts for these things? Prob­a­bly not, Google seems to be doing a very good job at these kind of pro­duc­tiv­i­ty appli­ca­tions (just as Yahoo! seem to be lead­ing the way in social appli­ca­tions).