Paper prototyping HTML layout

TL;DR

Paper prototyping is good. It saves you time. So why not extend the principle to other areas of your build, like your layout, and save more time?

On the last few projects at work we have trialled paper prototyping. For the uninitiated, paper prototyping involves using pencils and paper to sketch out user interface ideas and quickly iterate on those ideas, getting closer to the final UI much earlier in the project. On the whole it has worked very well, and from a developer perspective a lot of UI issues which often only get considered during the build are resolved before a single development key has been stroked.

So on our latest project, I brought the concept of paper prototyping to another area of development which, like UI, can be ambiguous, contentious and time consuming. The HTML structure of a site. This post is a quick how to for paper-prototyping your next HTML layout.

How to paper prototype your HTML

Ingredients

1. Print outs of key pages of the final site design.
2. Tracing paper
   - If speaking to a designer ask for a "layout pad" for added kudos
3. A lightbox (not required). 
4. More than one developer.

Method

1. Place your printed site design on the lightbox.

2. Place a sheet from your layout pad over the top of your site design.

3. Now start sketching and debating your proposed layouts with your fellow devs.

4. Rinse and repeat.

Sounds simple? It is. A fellow developer and I sat over the lightbox, drawing out our ideas, suggesting layouts and annotating them with simple style attributes to remind us of our initial thoughts on CSS when we came to develop the front end, for example, "float this left", "container with fixed width". Some ideas were quickly dismissed, while others were explore. Some even made it in to the final layout. In under half an hour we had a pretty solid layout which would have taken possibly half a day (if not longer) with just one of us sat in Visual Studio. 

Here are some pictures showing the paper prototypes of the layout my colleague and I created as we thought through and discussed the available options for a recent project. 

Attempt 1

Attempt 2

Attempt 3 with design print out beneath.

Ok, but what's in it for me?

This really was just an experiment to see if we could extend the principles of paper prototyping to other areas of the development process to reduce the time spent developing. 

By getting out from behind the keyboard, picking up a pencil and discussing ideas, we got to a solid layout in a comparatively short space of time, collaborating and sharing ideas along the way. 

I would urge other developers to give it a try. Even without the lightbox, just sit around the table and discuss how you would lay a site out. You may even save time and produce a finished site quicker.

A testement to this methods success is that since comitting the initial paper protoptype in to the project's MVC layout, it has only been altered a few times. 

Creating a better developer test

Hate is a strong word. Its a word that should be used sparingly. A word only wheeled out in times of desperation. A word reserved for the things in life you would prefer never to see again.

I hate developer tests. Let me be unequivocal here for a moment. I really hate developer tests. As a developer of 13 or so years I have sat my fair share of these things, some better than others, but I doubt any of them were the deciding factor in me getting the job or not.

Haters gonna hate

One of my main gripes is that most developer tests prove nothing. 

"What is the name of the Nuget scaffolding package for Asp.Net MVC3?"
"List the events in page life cycle."
"List all templates of the Repeater control"

If you can answer the three questions above, congratulations, you can obviously Google with the best of them. Every developer test will have a few questions like those above. Questions like this prove nothing. So you can remember that there is a SeparatorTemplate in a repeater. What has this told your prospective employer? Precisely nothing. Having Google has abstracted away this requirement in a developer. When it took 30 mins to scour the weighty tomes on the office shelf for an answer to a technical question, the ability to recall obscure facts and figures was essential. As developers in 2013 we all have access to all the information, all the time. The need for us to remember dusty corners of our chosen frameworks has gone. Get over it.

More important than CODE?!

It a well known phenomenon that the bar for developer tests is low. But why is this the case? Is it perhaps because a developer's ability to write code is secondary? When hiring a developer, there are criteria that should be ranked higher than their ability to code. What could be more important than your code? Your ability to explain your code? Your ability to share your ideas with your colleagues? Are you excited by new developments in your chosen field? Your fit with the wider organisation culture? Your ability to plan your workload and prioritise? While a developers ability to write code is clearly a core skill, it is not the only one which should be considered when hiring. 

Take a sad song and make it better

I was recently asked to write a developer test as my organisation is looking to expand the current team and the existing test needed a little refresh. I wanted my developer test to not only test if the candidate could write code, but if the could read code and understand requirements. I also wanted my developer test to contain a variety of questions from simple programming ones - to make sure they understand general programming constructs like object-orientation - to tasks which our developers do everyday, like writing a LINQ query to filter a list of objects, or writing some JQuery to wire up click handlers. I included a few bug spotting questions to test candidates code reading abilities.

Finally, there was a section asking candidates to write a web page, showing a list of orders and the products contained within each order. A very low bar indeed, but this simple task tells me if the prospective candidate can structure their code, and write code which is reusable. Their ability to read and understand (albeit simple) instructions is also tested as well as their attention to detail.

Below are two sample questions to give a flavour of what I ended up with.

Define a Orange as a c# object. Include any object hierarchy and properties you see fit.

The following code contains some bugs. Please list below the code snippet any bugs you can see.

Hopefully my developer test will test more that just the candidates ability to retain information. Hopefully it will tell me more about the prospective candidates than other tests full of obscure framework related questions. Hopefully it will go some way to recruiting a better developer. Hopefully.