Building A Web App Part 2: Specification
This post continues on from the last, so I suggest you start there if you want to follow this series; making a simple web application to ask a user what about the built environment interests them and suggest some Slack channels they can join accordingly. In this article we’re going to continue not writing any code, but that’s because we want to firm up our idea a bit, before we just go blindly creating.
Behaviour Driven Development
Behaviour Driven Development is an incredibly useful tool. It’s something that I employ on a daily basis to ensure that I only deliver what I have to; and that what I do does what the user was expecting. The premise is simple: Express your application as a series of behaviours and test against them- if it passes all the tests, then it must meet the requirements.
BDD, as it’s called in the biz, was an evolution of Test Driven Development; which set out to test each and every line of code by defining what it did before it did it. The problem was that it focused on the implementation instead of the result. BDD admits that all the user cares about is the behaviour of the application; it doesn’t matter to them if it’s done by an elegant bit of code, or an elaborate system involving pulleys and penguins.
In the last post I discovered that the sole feature we needed to implement for this prototype was: “Ask users about their interests and suggest channel names accordingly.” Although not strictly a requirement, it’s helpful to express the feature formally in a language called Gherkin. Not only does it discipline you into fully considering the problem, but it matches the procedure used in the testing tools:
- In order to meet people with similar interests
- As a user
- I want to find channels that match my interests
Thus, my scenario is:
- Given a list of interests
- When a user selects interests
- Then a list of appropriate channels should be shown.
So we know what the our web app is going to do, but we haven’t really touched on what it’s going to look like. That’s what wireframing is about; a wireframe is a sketch of what the interface could look like. Remember we’re aiming to fail fast, so that means we don’t want anything elaborate.
Let’s turn to our single feature/scenario description. To achieve that I need:
- A list of interests
- Each interest must be ‘selectable’
- A list of channels
Let’s keep it simple (stupid); we can do this all on one page without hurting ourselves. You can use a pen and paper to wireframe, or one of the variety of fun digital tools for this. I normally do it by hand, but for this post I’m using Wireframe.cc to save you from my terrible handwriting:
Hopefully it’s fairly obvious: The user is presented with a cloud of interests. Clicking on an interest toggles whether or not it is selected (it colours to indicate selection). As interests are selected the list below the interest cloud starts to populate with channel names matching the user’s interests.
I know what you’re thinking. Two articles in and there’s still no code; what sort of guide is this?! The problem with writing things down, is that it makes everything sound formal and long winded. But I invite you to think about how this would have gone if we’d just been in a meeting room with a whiteboard. At this point code is the most expensive thing we can create (even if it is just a small prototype). If I sit down with you and hash out the behaviours you want to achieve and draw out a sketch of the user interface, we could iterate through a dozen ideas in 10 minutes. So bare with me.