I was talking to Tom and some other people at Matt’s coffee morning this morning, and I mentioned a tiny piece of interaction design I was fond of (that was pertinent to our conversation). Tom said ‘write that up so I can point to it‘, so that’s what I’m doing.

A long while ago, at an agency job, I was sketching out wireframes and interactions for a web-based feed reader. It was designed for users who possibly weren’t that used to RSS, and so it needed to guide them a bit through the best practices of interactions.

The list of articles looked a bit like this:

Pretty standard, although the important component was the unsubscribe button.

I put an unsubscribe button on every feed item.

I wanted to stress that if you weren’t enjoying a feed, you didn’t have to read it. Just bin it! You’ll be a lot happier. Clicking the unsubscribe button would do something like this:

to indicate the severity of your action. I felt that was reasonable – little button, big confirm dialogue. And then boom: the entire feed is gone.

It’s amazing how often you can mark an item as read, or archive an email, before committing to unsubscribing. I wanted to capture how ephemeral subscriptions could be. They weren’t commitments; they were just things you’re interested in.

I think the me-of-2015 would also ensure that there was a way of triggering this interaction based on patterns of behaviour. For instance, asking the user if they want to unsubscribe from a feed if they’ve marked it as read a surprisingly short time after they looked at it (indicating they hadn’t read an entry). And, similarly, checking a few weeks later that you didn’t want to subscribe back: frequently, I unsubscribe from things just because I need a break, or I don’t have the space – not because I want them gone forever.

It’s very easy to offer final, decisive actions; they’re very native to dialogue boxes, buttons, and digital systems. But some things are ephemeral, and it’s important to stress that in design. Just because I unsubscribe form a feed, or unfollow someone on Twitter, doesn’t mean it’s final: I might want it back one day; I might be taking a break from my higher-traffic friends. I wanted to try encouraging that.

And I wanted to remind users that there was an alternative to ‘inbox overload’: you could just have a break.

In these two stills, drawn a bit from memory, there’s a lot of gaps – and I’ve not sketched any of the possible animation or motion that would help convey what was going on. Still, that interaction – offering what feels like the nuclear option front and centre, reminding the user that it isn’t a nuclear option – I quite like that.

I’ve been playing a little with Toca Boca‘s latest iOS toy: Toca Builders.

As you’d expect from Toca Boca, it’s charming: a straightforward, paired down implementation of an idea, with unambiguous UI and lovely character design.

Builders is Toca’s take on a block construction toy for small children. Initially, it might seem a bit clunky, a Minecraft pastiche that’s not nearly so sophisticated as Mojang’s original. After all, it’s a tiny play area compared to Minecraft – six blocks of height and relatively small X-Y dimensions.

It’s the plural in the title that makes it so interesting, though: builders. This is not (just) a game in which the user is a builder; it is a game about six individual builders (pictured above). Each has their own different ability: most can both construct and desturct; almost all can control the colour of blocks; some are better at changing blocks after the fact, others at sketching with. They each control slightly differently – and they each manifest in the landscape. You can swap between builders with a simple or menu, or by tapping on any that you can see.

It’s the manifestation and personification of the four builders that suddenly clicked for me. As I played this, I realised what it really was: Minecraft through the eyes of Seymour Papert. Lego as LOGO.

Papert explained the LOGO turtle as an “object-for-thinking-with“. Not just a device to command, attached to a programming language; a device that you see the world through. Or as Papert says in Mindstorms, his wonderful book about the development and intent behind LOGO:

“objects in which there is an intersection of cultural presence, embedded knowledge, and the possibility for personal identification.”

He makes what I think is a clearer point later, though, and which I think Toca Builders captures perfectly:

Even the simplest Turtle work can open new opportunities for sharpening one’s thinking about thinking: Programming the Turtle starts by making one reflect on how one does oneself what one would like the Turtle to do. Thus teaching the Turtle to act or to ‘think’ can lead one to reflect on one’s own actions and thinking. And as children move on, they program the computer to make more complex decisions and find themselves engaged in reflecting on more complex aspects of their own thinking.

Papert is sometimes quite wordy. When I explain this to people, I tend to say: the value of the Turtle is that when you are stuck, you solve the problem by pretending to be the Turtle. This is especially valuable for young learners; as Papert points out later:

Children can identify with the Turtle, and are thus able to bring their knowledge of their bodies and how they move into their work of learning formal geomtetry

There are some lovely photos in Mindstorms of kids on a playing field, practicing Logo; one of them is being the Turtle, and the others are telling her what to do. The second you act out a program for yourself (or watch another child follow your instructions to the letter), you see how literal you need to be, or which line of code is ambiguous. You begin to see how the computer processes information (“thinks” being, unfortunately, an entirely inaccurate word).

This kind of embodied representation of computational logic is very rare. Often, the hard things in computer science are very abstract. I do not know how to “pretend to be the compiler”; I just have to trust input and output.

Toca Builders takes the abstract building of Minecraft – tools attached to a disembodied perspective (albeit one hindered by some degree of personhood – factors such as gravity, and so forth) – and embodies them to help younger children answer the question which tool would you use to place a block where you need to? Or sometimes backwards: which block shall we place next? It is not quite as freeform as Minecraft, but it actually forces the user to think a little harder about planning ahead, lining up his builders, and which builders go together well. Measure twice, cut once.

To that end, it’s much more like real-world building.

Papert was very clear about one particular point: the value of this is not to think in mechanical ways; it’s actually the opposite. By asking children to think in a mechanical way temporarily, they end up thinking about thinking more: they learn that there are many ways to approach a problem, and they can choose which way to think about things; which might be most appropriate.

And so Toca Builders is, in many ways, like all good construction toys: it’s about more than just building. It’s about planning, marshalling, making use of a limited set of tools to achieve creative goals. And all the while, helping the user understand those tools by making them appear in the world, taking up space in it, colliding with one another, and needing moving. All so that you can answer the question when you’re stuck: well, if you were Blox the Hammer, what would you do?

Some of what looks like clunkiness, then, is actually a subtle piece of design.

If you’re interested in the value of using computers to teach – not using computers to teach about computers, but using computers to teach about the world, then Mindstorms is a must-read. It’s easy to dismiss LOGO for its simplicity, and to forget the various paradigms it bends and breaks (more so than many programming languages) – and it’s remarkable to see just how long ago Papert and his collaborators were touching on ideas that are still fresh and vital today.