Abstraction is something we refer to a lot in tech, but often without defining what we mean, or what the implications are. In this post I’d like to explore the notion of abstraction and how it relates to the experiences people have using software.
What is an abstraction?
An abstraction is a generalized definition of something. In tech we typically talk of abstractions in relation to user interfaces (which can be programmatic or graphical – we interact with them using code or by clicking, tapping etc). That clear things up? We can do better lol. Let’s use an example.
I ask someone to make me a cup of tea – this is an abstraction!
A less abstracted version might look like this:
- Walk into the kitchen
- Fill the kettle with water (optional instructions on using the tap)
- Switch the kettle on
- Get a tea bag from the cupboard and put it in the cup
- When the kettle is boiled, pour the water into the cup
By just asking for the cup of tea, I’m assuming the person knows what that is and how to make it. With this implicit knowledge shared between us, I can use the shorthand version of the request. If the person had never seen tea, or used a kettle, I’d need even more detail.
Abstractions in coding
OK but what does this have to do with computers? Well, computers do what humans ask them to by executing code that we write. The machines execute instructions that are expressed as sequences of numbers. But writing sequences of numbers is not the most fun or efficient way to spend your time! So people developed the idea that we could write code in a way that’s closer to natural human language, and get another program to translate that code into something the machines can run.
In these higher level languages we write instructions that are more abstract than the code the machine eventually runs. We ask it to make us a cup of tea instead of the more specific alternative. The history of computing has been characterized by similar waves of abstraction, and this has greatly accelerated the pace of innovation.
The development of web applications has been hugely powered in recent years by the growth of APIs. An API (Application Programming Interface) lets you access a web service by making requests through a well-defined interface. You can make a request to send an email to a customer just by providing the email content instead of having to implement a messaging platform yourself. These interfaces don’t just save you time, they let you focus on the unique aspects of your project. Whole companies have grown out of this model.
Abstractions in user interfaces
We’ve been talking about abstraction in how we use code to get computers to do what we want, but abstraction also applies to other ways of interacting with them. Whenever you use a website or app, you interact with the controls in a way that makes a computer do something don’t you? So this is another type of abstraction.
⚠️ Second analogy alert: I can drive a car without knowing how the engine works. I just need to understand the inputs and outputs that get the car to do what I want. The controls inside the car (the steering wheel, the accelerator, the brake etc) make up the interface that I use to control it. There’s a whole lot going on under the hood that I don’t need to know about in order to drive it.
Applications can enable people to carry out all sorts of tasks – including making other applications. IDEs (Integrated Development Environments) help developers to build software by writing code in an editor that integrates with other utilities. We can even build software graphically – we sometimes call this no code development. Contrary to popular assumptions, even software developers use no code tools some of the time.
Abstractions can be a help or a hindrance
OK so this all sounds lovely, we can make things happen without having to bother with the detail of how they are implemented. But wait a minute, what if someone makes the tea in a way I don’t like? Maybe they put milk in it and I don’t want milk. Maybe they put something else in it and I can’t even tell what it is. Or maybe someone asks me to make a cup of tea and I have no idea how to do it because I’ve always just asked someone else to do it.
When we design user interfaces, we have to decide what level of detail to expose to the user about the tasks the application is performing for them. So we’re making a guess about what it’s valuable for them to know about. If we get this right, we can create something that is empowering to the user in supporting whatever they are trying to do. If we get it wrong, we can accidentally take away valuable control and understanding from them.
What do you want to enable?
So how do we choose the right abstractions? It’s hard! And it can change over time – we’ve grappled with this on Glitch, where we try to help people build the web. Sometimes in tech we can get bogged down in who we think the user is, but in many cases, the same affordances enable everyone. It can help to focus more on the tasks you want the user to be able to accomplish, and what level of detail you think they might need to do this effectively.
With developer software in particular there can be a risk of taking too much control away from the user. This is why some tools have escape hatches where you can access advanced configuration settings, but that aren’t exposed to everyone, with sensible defaults in place for folk who don’t want that level of control. Providing the loss of control isn’t problematic, people will typically choose the easiest path – there’s no such thing as too easy!
Tools that successfully empower a broad range of people – by creating an accessible experience, with the option for additional control – are sometimes described as low barrier / high ceiling. You don’t need a ton of expertise or effort to engage, but you can interact at an advanced level if you want to, making the potential of what you can achieve greater.
I would say that low barrier / high ceiling software is exceptionally rare, but perhaps I’ve just not been looking in the right places. What examples have you seen?
Top comments (0)