Warning: strtolower() expects parameter 1 to be string, array given in /nfs/c06/h02/mnt/184288/domains/markboulton.co.uk/html/_app/core/private_api/_cache.php on line 337

Warning: strtolower() expects parameter 1 to be string, array given in /nfs/c06/h02/mnt/184288/domains/markboulton.co.uk/html/_app/core/private_api/_cache.php on line 341
| Journal | The Personal Disquiet of Mark Boulton

The Personal Disquiet of

Mark Boulton

Blog Category: work


I get the content in Word, copy into the various boxes in the CMS and then see how it looks. Normally I spot a few typos, or it doesn’t appear where I want it to, then I have to go back and find the article again – which isn’t so bad, it’s normally at the top. The real pain is when I have to add another link to that list over there. (whispers) Normally I ask James (a developer) to do that for me, though as I can’t do it.

This was a conversation I had with a person recently about how they use their CMS. A real-life content person. I say content person, not ‘creator’ as you may have noticed she doesn’t write the content. She just ‘gets it’. She’s a piece in the publishing workflow. A cog in a machine. And our tools are failing her and are only going to get worse.

In that workflow, there is a bit that’s a clear trend amongst the people I’ve spoken to about this.

then see how it looks.

And that’s the thing, right there.

Since we’ve been using computers to make websites we’ve tried to make them like print. Of course, early on, that was fair enough. It was familiar. We knew the rules and tried to make the web like it. Even now, with the realisation that the web has changed – or rather, we’re being honest to the way the web is. It never really changed, we just tried to make it something it wasn’t – we’re still enforcing a print-like mental model on it. Not necessarily us designers and developers, though. This is coming from people who write and manage content. Just like printing out an email before they send it, they will want to preview a website to see how it looks.

The problem is this: The question content people ask when finishing adding content to a CMS is ‘how does this look?’. And this is not a question a CMS can answer any more – even with a preview. How we use the web today has meant that the answer to that questions is, ‘in what?’.


Let me first off define what I see WYSIWYG. WYSIWYG is not a limited toolbar for adding semantic value to your document. The kind of toolbar you find on Medium, or on Basecamp. As you can see they are similar. They are used for applying semantics to document structure; giving words emphasis, making unordered lists, or numbered lists, making words headlines. However, they’re not there for the user to get creative. They do not change the colour of a word.

When I think WYSIWYG, I think of the Word toolbar. This type of WYSIWYG is for adding tables, images, forms, type and colour. It’s a toolkit to create pages of content. Just like desktop publishing. And that’s the dangerous thing. Content creators are used to having these tools at their disposal so they can craft their document. Why? Because writing isn’t done in a CMS, it’s done elsewhere.

Times -are changing- have changed

It’s been a turbulent few years for web designers and developers. We’ve had to relearn what we’ve created and finally acknowledge – through the timeliness of Responsive Design – that the web is a fluid and chaotic place, and we should be embracing it and not making it like print. We’ve learnt to deal with the loss of control. The problem is, though, our content people are still thinking of pages. They’re still thinking of previewing. Of designing for the desktop. They’re writing in Word and fine with it.

So, that’s the challenge. How can we help people – just as we have – relearn how the web is now?

Just like when people have a content management problem, a lot of people are turning to technology for the answers. And just like content management problems, my experience is software can’t fix it. Because it’s a people problem, not a software problem.

The three places of content management

There are three spaces * for content people – not creators, because not all content people create loads of content. Some just manage it – push it from here to there. Those places are:

  1. A space for writing. For writing and structuring.
  2. A space for management. For adding meta data, workflow, configuration and managing roles and people.
  3. The website space. Basically your website. A place where you begin the access user journey. Or preview your content. Generally the starting points for lots of little administration tasks.
  • There are other spaces, too. The developer space, where the site is administered and created, managed and evolved. Sometimes this is through an administration interface, but not always. Sometimes it’s just through an API.

The problem I see is that the CMS tries to deal with all three spaces equally well. And as such, generally fails to deliver an optimal experience because it’s trying to do too much. What if your content management system was actually three distinct applications designed to work together? Just a thought.

But, back to WYSIWYG.

The issue with WYSIWYG for me is that by using them the content person is considering the content as what they see. But content is more than that. Especially if it has meta data, and is split up and compiled from here and there. A ‘page’ maybe a dynamic template pulling in content from a dozen places. How do you change meta data there?

If we consider the majority use-cases of correcting typos, restructuring slightly, or small on the fly editing, then the smaller toolbars for adding semantic value are useful. But for most use cases, a WYSIWYG is not useful for content people. It’s just familiar.

Inline-access, not inline-editing

One of the other pain points of a complex dynamic website, where ‘pages’ are created with bits of content from all over the place is ‘where the hell do I go to find that bit of content to edit it?’. That is a painful moment in a content person’s daily life. Normally, after watching them, they go off deep into search, or ask someone else who knows better. Accessing these smaller nuggets of logic-based content is problematic. This is why inline-editing and WYSIWYG is coming to the fore – addressing the use case in the live environment.

Why is this a problem?

As I said before, it’s hiding the truth. That being, the content is more than you can see. Instead of inline editing of the content, why not just make the start of that journey a little easier? Why not provide a way of quickly getting to exactly that bit of content with a link? There we will see all of the stuff that is the content but not the words: the display logic, taxonomies, meta data etc. But if we want to change a type, we can do that with our little toolbar.

Not one tool, but many. Not one way, but many.

Structured content is the right way to go. It makes our content portable and malleable. In fact, it makes it much more useful. Slapping a WYSIWYG on top of a form field is not the way to go. That’s not structured. Live WYSIWYG is not the way to go for large-scale websites because it reinforces that content is just what you see. When, in fact, a piece of content could have a whole bunch of other headlines and summaries that would only be displayed in certain contexts, along with meta data and rules. We need access to ALL THE CONTENT and provide simple, little tools to let people make typo changes and apply semantic structure and the like once they’re looking at the content in a staging environment.

‘How does this look?’

should change to:

‘How does this read?’

Device agnostic. Screen size independent and devoid of design. Let’s help content people focus on what the words and pictures are, rather than what the words and pictures look like.

Filed in: Design, Work. on September 3rd, 2013

I'm not a Craftsman

My uncle is a quiet man. He smokes a pipe with a wry smile. Like he knows something you don’t. For years he restored traction engines; huge, victorian, steam-driven machines. He did it for the love of it. I have wondered if he did to escape. Like a lot of men that age, he spent a lot of time in his shed on his own, surrounded by the smell of oil, grease and pipe tobacco. A dusty pile of tabloid newspapers in the corner. Slowly whittling away on a small piece of metal, making some grommet or flange or something.

Sounds romantic doesn’t it?

Now, how many times have you heard web designers and developers talk this way about their work? For me, it’s been increasingly. And personally I find it concerning. For starters, it’s a designer-centric way of working. It’s a selfish exploit to pour love into your work. If you’re working commercially, who pays for that time? You? Well, that’s bad. The client? Well, that’s ok if they see the value. But many don’t.

Giving your work love is not just about giving it time. But, time can often be better spent than whittling away on some nubbin’ or grommet just because you think that’s where you can give the work your love. Your craft.

Over the past few years, I’ve spent more time on projects not whittling. Whittling happens in the very latter stages of work and I really don’t find myself in that place very often. Mostly that’s because the clients I work for have a myriad of big, sticky problems that need working out before you start ‘crafting a user interface’, whatever that means. I’m more often than not in a place where my own job, as a designer, is to not make something I love. But to make something appropriate. Something that does the job well. Something that responds to a hypothesis and serves a need. Not necessarily something loved and beautiful. And that’s ok.

Craft is an emotional word not appropriate to describe the job of designing. It’s too self-centred. Too mired in arts and crafts and puts a difficult-to-measure parameter into the minds of clients.

‘I want a beautifully crafted interface from a passionate designer’

Translates to:

‘I want a self-centred designer to spend way too long on the shiny than actually solving the problem or having the difficult discussions’.

If my uncle was restoring traction engines for a living, he would’ve been out of business. Craft is love. And love takes time. And time is scarce and probably best spent elsewhere.

Filed in: Design, Personal, Work. on July 16th, 2013

The First Website

Twenty years ago today, CERN published a statement that made the World Wide Web freely available. To mark this anniversary, CERN – together with Mark Boulton Design – are starting a project to restore the first website and the associated assets of the World Wide Web project.

I first started using the internet in about 1988. I had a mate whose dad worked for IBM so he had an early PC connected – via the phone line – to a rather sophisticated little modem. The internet wasn’t the web back then, it was a mix of bulletin boards, rudimentary email clients and IRC. You may think that it was a primitive, but in reality, the prospect of near live discussions and collaborations with people all over the world was pretty incredible. As friends do, we lost touch, and my connection to the internet was lost with it. I did other things: failed my A-levels, learnt martial arts, chased girls, learnt the guitar and went to art college. My connection with internet picked up again in 1994. And, oh boy, was it a different place entirely. In just a few short years, the web went from idea to proposal to freely available. And the world was changed forever.

As web designers and developers, we spend a lot of time trying to explain the difference on the web. “It’s not TV, it’s certainly not print” (oh, no, it’s definitely not that). The web is its own thing. But unlike other media – ones which have physical artefacts, which get left behind to rot, to be found and stuck on a shelf in a museum – the web doesn’t have that. Pixels don’t decay, they just disappear. Forever.

Preserving our digital heritage is as important as preserving our physical heritage. There are a few people and organisations in the world who get this: The Long Now Foundation and Archive.org, to name a couple, but I’m not sure that’s enough. The need to preserve must come from our desire to learn from the past. I have two young children and I want them to experience the early web and understand how it came to be. To understand that the early web wasn’t that rudimentary but incredibly advanced in many ways. Currently, it’s impossible to do that. And, together with CERN, that’s what we’re hoping to provide.

From today, we’ve started work on the project objectives. The talented web team at CERN have already reinstated the first URL and uploaded a version of the website from about 1992. The restoration has begun.

To keep up to date on the project you can read the project blog where we’ll be posting updates on progress. You can also follow on Twitter @thefirstwebsite.

Read the announcement from CERN and two opinion pieces from Robert Cailliau and Vint Cerf

Filed in: www, Design, Mark Boulton Design, Work. on April 30th, 2013