What are the fundamental principles behind making good websites?
There really should be some decent answers to this question. I think one of them is "equivalence". Explaining this will need a bit of a run-up.
"Principles" are about the underpinnings of our approach to something. Rather than just saying what to do or how to do it, they should tell us about why, and help us to see where the what and how might come from.
All other things being equal, when everything else is stripped away, what still holds true? What's the big idea?
Should be simple, right?A
This thinking began while I was a developer at the BBC, but it never made it into the BBC's central standards or official record of 'the way things are done'. This is mainly because those things don't exist.
At the same time, I always felt like I never fully completed the thinking, and although I've spoken about "web principles" and "equivalence" to many people, I've never written it all down. I started feeling a bit like the bloke from Zen and The Art of Motorcycle Maintenance, trying to work out what "quality" means and going entirely nuts in the process. So I left it.
But the reference to the BBC in all of this is quite important, because the BBC's philosophical purposes are, many will agree, deeply connected to idea of the web.
The BBC purposes were particularly inspiring to me as a developer, not least because they seemed not to have yet been applied to the ideas behind web development. I thought those purposes could and should be directly relevant, because they were what led me both to web and to the BBC itself. They had to be tied together somehow.
Just "impartiality is is the hallmark of BBC Journalism1", there has to be something that runs through the veins of the builders of bbc.co.uk.
A BBC journalist has a well-known and direct purpose, and it can be summed up in a single word: 'impartiality'.
There are entire reports and books written about the extent to which the BBC delivers on this principle. BBC output is rightly famous across the world for this one core value.
It's probably possible to argue that the reason why BBC journalism is so highly respected, and why it has such enormous global reach, is that it has this fundamental idea of its own reason for existing. At any moment, any person producing content for BBC News can stop and clearly ask themselves whether what they are doing is in line with this. If they can't answer it immediately, there is a solid and well-grounded framework for helping them to check their work is going the right way. This framework is far closer and more tangible to them than the Reithian purposes, although they trace back to them. This framework is what sets them apart, and is the reason why they are the best at what they do.
In FM&T, we have no similar set of principles. We find it very difficult to immediately answer questions about why we do what we do, other than to talk about the often arbitrary specifics of a given project, or to talk about overarching Reithian values, or to say that whatever it is that we do, we want 75% of people to consume it.
If there are principles of web development, in the broadest sense, then what are they?
First of all, we need to have an idea of what they might look like
- what our ultimate aim is, and why it is our aim
- what techniques we will use to move towards this aim, and why these techniques work
- how we will approach these techniques, and why this is the way to approach them
In other words, the principles come in three simple parts, and we need all of them for it all to make sense:
- Purpose
- Methods
- Approach
Etc.
Who is this all for, and what's the point?
Broadly speaking, lots of people at the BBC understand these ideas pretty deeply already. This is because they work here, and are skilled and knowledgeable web people. So what benefit is there to writing a big long document about these things for people who live and breathe web standards? Isn't this just preaching to the converted? Not necessarily.
For one thing, not everyone lives and breathes this stuff in the same way. And for another thing, thinking from a 'principles' point of view can sometimes be very useful in its own right. It can be helpful to break things down and then break them down further, and then ask why they're like that.
All in all, thinking about fundamentals is something we don't do very much at the BBC, or in the wider web profession for that matter. Instead, we're all focussed on getting things done and on solving the problems we face, because we have to. While we're at it, many of us pick up the rules of the game by osmosis, or through individual experience. There are dozens of books and blogs on the techniques involved in web design, but more often than not, even where authors go back to the fundamentals to set the scene for the advanced techniques to follow, the ultimate principles are rarely touched on.
Elsewhere, the lack of agreed principles is hugely inefficient, because we end up going over the same ground again and again. The erstwhile BBC Standards and Guidelines process regularly suffered in this way: the number of times working groups needlessly discussed things that had common threads running through them added up to a lot of time.
Thinking about the principles behind things forces you to see if there are any principles behind them. If you can identify them and agree on them in some way, then you can draw a line and move on. If there are ever moments when you're not sure what you think about something, you can fall back on your principles, to save you time and make sure you don't do something wrong.
Other professions have principles. In medicine there's "Primum non nocere", or "first do no harm", which seems a pretty good fundamental principle for a doctor.
The problem with the fundamentals of our profession is that we don't explicitly discuss them, and we don't really have a way to explain them to other people. As a result of this, although lots of people do understand these ideas pretty deeply, there's plenty of room for people not to. Looking around, this is obvious. If the principles were used universally, then the BBC site would be a shining example of perfection from top to bottom. It's not. So the question is: what would it take to bring everyone up to the same level? What's missing?
A first step to the answer is to realise that appreciation of 'the web principles' is often a lot like an unspoken instinct, something that's implied when developers talk about subjects like semantic markup, CSS, unobtrusiveness, and 'accessibility'. The central importance of these ideas is in many ways taken as read, and for this reason there's a danger that the reasons behind them get lost, particularly when talking to people outside our discipline. Some of those people work closely with us, and need to know what we're on about so that we all have a better chance of doing good work. Others have lots of power to set the direction of the work we do, so it's vital that they understand our priorities.
The central principle: Equivalence
Everything we do has one thing in common: it is produced by the BBC, and it should be in line with the BBC Purpose. This purpose is, as well as some more recent additions, "to enrich the life of every person in the UK with programmes that inform, educate and entertain." Whatever it is we're here to do, at the bottom of it all is the need to deliver this promise, and to live up to the stuff on the backs of our ID cards: Trust, Quality, General Goodness.
Not to put too fine a point on it, it's hard to deliver these things with CSS alone. Rather than being singularly responsible for everything, what a developer does is enable the BBC to deliver its purpose on the web. If the BBC decides to enrich the life of every person in the UK by giving them BBC iPlayer, or allowing them to read the news or learn French, it's our job to make sure they can do it. The important part for us as designers and developers is the part in the BBC Purpose that says "every person".
While it's not possible for every person to have an identical experience of the BBC website, everyone must experience equivalent BBC-level quality.
One of the clever things about the web is that it can be consumed in many different ways. This presents us with a challenge though: all features, applications and other things that bbc.co.uk decides to offer must be proposed, designed and built so that all users, regardless of the way they visit, can achieve the fundamental goal of that feature, application or other thing. The goal is more important than the way people reach it, because it's the goal that holds the promise from the BBC.
There is more than one way to consume television. Black and white TV sets show modern colour broadcasts, and the key thing to notice is that owners of black and white TV sets can still achieve the fundamental goal of Newsnight, which in turn delivers part of the purpose of the BBC.
Each BBC offering's fundamental goal - its ultimate purpose when all else is stripped away - needs to be defined in advance, so that the approach to delivering that goal can be planned properly. Rather than building a particular solution to a problem and only then offering an 'alternative version' when we find that not everyone can make use of it, we have to decide what the purpose of an offering is, and then build the most universal solution to deliver that. Alternative versions built afterwards very rarely achieve equivalent quality to the original. Equivalent quality is what we are after, because that's what we're promising.
We need to plan from the outset to create a solid foundation for everything we do, a foundation that just works. Once we've done that, we can add to it. We can progressively enhance the foundation to offer richer experiences which the majority of users will then encounter, transparently. If anyone can't use the advanced features for any reason, they can easily find a way to equivalent quality by directly accessing the foundation, which is guaranteed to always be there and which we made sure from the beginning delivered on the original goal, and the BBC purpose. The methods used during this process of progressive enhancement are a different part of the web principles.
How to do Equivalence: Separation... ( NB. and other methods)
'Separation of concerns' is a principle that unites the main technical aspects of web development. It's a simultaneously ensures efficiency, flexibility, and interoperability; it allows content and applications to be shared and repurposed, both by the BBC and by our audiences. Separation is the fundamental principle behind progressive enhancement, and at the core of software engineering. In short, it's one of the things that good developers do a lot of when their doing their best work.
Equivalence can only be achieved if the 'more advanced layers' are added so that the 'underlying layers' work independently. Content is the most important layer, and it must be separated from the presentation and behaviour layers of a webpage in such a way that users experience equivalent BBC-level quality even when those layers are not available for any reason.
The principle is true in different ways as we peel back the layers within the layers. The content layer only makes sense independently if it is marked up semantically, with the meaning of the content conceptually separated from the code itself. Further separation is needed to ensure flexibility and maintainability: the class and id attribute values which allow the layers to be linked must be chosen independently of those layers, relying on what elements really are rather than what they look or behave like. Functional names like "submenu" replace "topleft_thing" in a good developer's code. Thinking about and understanding separation is the key to realising why semantic HTML is an important thing, and why CSS is a better way to make pages look like Photoshop mockups than tables-based markup.
Similarly, software must be engineered so that applications and individual features of them work independently, so that they can be easily maintained, extended and repurposed. This means flexible, well-managed separation, with service-oriented architectures and APIs to link them together. The same principle applies almost everywhere, and it needs to be understood if we are to be in a position to do great work.
The final principle: Consistency
This last idea is not something that's far from limited to the web, and so it could be considered a kind of over-arching principle. It is that everything we do has to be for a reason that can be demonstrated, and that there must be consistency in our approaches to common problems. If one side of website creation is the art of experimentation and creativity, then this is the science side, of looking for evidence and then co-operating and communicating with others about it.
There are many pitfalls when we try to practically use the ideas of progressive enhancement and separation to deliver equivalence. Semantic HTML and CSS and JavaScript, beautiful and clean and clear though they are in theory, cause a lot of unpredictable headaches when put together in the real world of designs, users and browsers.
But there are usually ways round most of these headaches. Trade-offs are arrived at and solutions are found, either by accident or hard work, and best-practice ripples though the web community. Headaches turn into brilliant new ways to look at things, and the state of the art moves forward.
But when we decide that a particular approach is best, and perhaps make it into a standard within the BBC, then it must be on the basis of real evidence. Without evidence, a standard is just an unsupported hypothesis. We shouldn't be spending time and money building things on the basis of guesses and opinions, unless there's really no alternative.
When we lack evidence, but find that we have to act anyway, we must actively admit that we are working according to our best guesses and considered opinions, and then work towards demonstrating that those are genuine. When we've done all this work, and found good ways to do difficult things, then we need to share our findings. If we solve a problem, then we should not have to solve it again, and nor should anyone else.
So, what does it all mean?
Note that just because you have principles, it doesn't mean that everything you do has to abide by them no matter what. From time to time there might be strong reasons to go against your principles: financial, legal, BBC politics... etc. But with the Web Principles, at least we have something that can act as a balance or starting point to these trade-offs...
Blah.
An example
The Braille version of a novel is a separate object from the printed book, and that's probably because Braille needs more space than print, and a different type of paper than Braille does. There's nowhere near as many Braille titles as non-Braille titles in the world; a quick search on Amazon.com results in 223 books in Braille, considerably less choice than they offer for everyone else.
This may be a pretty obvious point to some, but the web lets us do an amazing thing: it lets us do the equivalent of printing ink on top of Braille, so that both versions are in the same volume, for no extra cost. If books were made like this, Braille users would be able to buy any book from a bookshop and read it just like anyone else, right away. If you went blind tomorrow (or you already are) then you'd probably want that to be actually possible.
Genuine barriers to books, TV and web content do exist, and they always will. But given than on the web we can actually make things universal, it is our duty, as a principle, to make sure the alternatives we offer are equivalent to the 'original'. The way to deliver this is to ensure that they are created from the outset as parts of each other.