Writing to help people understand technology
I worked with Doteveryone on developing the content and site for a project of theirs known as Explainers.
We wrote three ‘explainers’ to explain how different aspects of online technology work. The goal was not just to explain the internet; we also wanted to test a particular approach to talking about technology.
Doteveryone believed that aiming to teach people to understand a topic or issue, as opposed to just teaching simple digital skills, would have a greater impact on their technical abilities and confidence. It’s the difference between telling someone how to come up with a better password, and teaching them why they should be using strong passwords - as well as helping them think about the issues involved. When we needed to explain how, we’d link out to our preferred examples that already existed online.
A lot of explanation of technology to lay audiences can be patronisingly simple, oversimplified to the point of inaccuracy, or, worst of all, fear-mongering. We wanted to be informative and truthful about topics without making our readers afraid. We wouldn’t be afraid to present ideas that were complex - we’d just make sure we explained them as clearly as possible. And we wanted to communicate some of the ‘wow’ about the topics involved. The internet is big, and networks are fast, and technology can be amazing; so little writing about these topics lets that sink in. Scientist Brian Cox became a point of reference for our tone (seriously!): he strikes a balance between explaining complex topics but also letting you know his enthusiasm for them.
We focused on two questions to begin with - “what happens when I share a photo online?” and “what happens when I upload a photo?” We didn’t want to immediately leap to issues around computer security, primarily because it’s very hard to do without sounding frightening. And yet early user interviews and testing told us that people really did want to know more about security and privacy online - so we added that topic to the mix.
“Sharing” was a simple introduction to sharing content, what URLs are, how URLs are links and not copies, and introduced some ideas around permissions.
By contrast,“Uploading” was our most technically involved explainer. “What happens when I upload a photo?” is a surprisingly challenge question to answer clearly and correctly. It’s a great question to explore, though - it touches on most of the layers of the stack of the internet. We started by explaining that the internet is really a network of networks, and went on to cover how form data is sent, how DNS works, and why TCP/IP is magic.
That may sound very complex; part of the work was making it sound not one jot more complex than it needed to be. But even if we used clear language, it felt very important to answer questions truthfully. It’s entirely truthful about what happens when you attach a file and click upload.
We designed Explainers so that they got more complex as they went along. I used the analogy of a good TV science documentary - it might start in familiar ground, but go on to cover more challenging topics by the end. Viewers will often watch to the end, even if they didn’t full understand some of it - or they’ll stop watching when they feel overfaced. If we made sure our explainers got more complex as they went on, rather than front-loading difficult topics, it helped the reader climb the curve of mastery, rather than giving up before they got to things they were interested in. But we also wouldn’t mind if they did give up - they should take something away no matter how far they reached in the explainer.
We used imagery and illustration to explain specific points. One of our guidelines we settled on early was only ever using images as meaningful content (rather than as ‘magazine-style’ illustration of the main text). This confused some readers earlier on, who skipped our animations and images; some carefully placed captions and headings helped clarify matters. Early research revealed that people had a preference for clear, step-by-step illustration - so as well as making some imagery, I produced animatics to explain the more complex step-by-step processes we describe (packet-switching and TCP/IP). These were later turned into final animations by an animator.
“Security and Privacy” took the longest to get right. In part, that was down to trying to write about these topics without fear-mongering. But it was also down to the volume of content we had. We wanted to distinguish between security - which is like hygiene, in that it often just comes down to sensible best-practice - and privacy, which requires more thought on the part of the end-user about what they’re doing and what their goals are.
Our first pass at this turned out as a long page of linear content - perhaps too long. I spent an afternoon prototyping with Twine to see what it’d be like if it was far less linear - a series of nodes you could wander through depending on what you were most interested in. It turned out to be a good move, and we reworked the piece into something much more fragmented. Those fragments became a base for all the subsequent iteration on this explainer.
I had two main roles on the project. I built all the code for the project - primarily, straightforward markup, and an ultra-simple web server. I also acted as a domain expert, researching, exploring and explaining the topic.
I worked closely with Alex Lemon, Doteveryone’s content designer, who led on the content itself. A lot of our early work involved me telling a story (about, say, how TCP/IP works), whilst she took notes and asked me questions. Later, she would write the content from those notes - separating the fact-gathering from the process of writing. After the initial drafting process, we iterated the writing together. Alex grew the voice of the project from those first drafts, and kept hold of it through the rewriting process. The project was produced and run by Hilary Hall, and Ollie Sheldrick led on research.