Thread by @girba

Personal computing was conceived to be personal. Personal, as in experiencing computation the way it fits you. Your context should come first and dictate what is interesting. The experience should follow.

1/

For example, consider where you are reading this tweet. Or where you are writing a reply to it. It's not unlikely that you are doing it exactly in the same way many other millions of people are doing it: using the generic interface that Twitter offers.

2/

Of course, this is convenient. At the same time, it might not match your actual needs. For example, say you like writing longer threads. Longer threads imply more consideration and possibly longer time to write. And, you may want to handle multiple drafts in parallel.

3/

Also, when you compose, you might want to do it in an isolated environment where you do not get exposed to the immediacy of the new 10 notifications that just appeared.

4/

The default UI incentivises the opposite behavior. It wants you to act now. If you want a thread, it's one thread. And the writing experience is secondary to the rest of the UI.

This does not necessarily make the UI bad. It just makes it not suitable for your needs.

5/

The needs I described are still generic. Actual needs are much more contextual. You want the tool to match those needs. Not the other way around.

Think of this: if you have an idea, why do you go to a service to deposit it? Why is the experience not coming to where you are?

6/

In a beautiful #TEDTalk from 2013, Iwan Baan talked about how people both adapt to their environment and adapt the environment to their own needs and perspectives.

ted.com/talks/iwan_baa…

7/

One example is how people adapted to living in an unfinished 45-story office building and how they transformed it into a small city.

He goes on to show many pictures of how people "essentially create a home that's completely adapted to the conditions of the site".

8/

When people are provided with a building skeleton, they fill with with beautiful contextual experiences. This stands in contrast with generic "cookie-cutter housing solutions".

9/

The main message is delivered at the very end as a quote by Zita Cobb:
"There's this plague of sameness which is killing the human joy"

I encourage you to watch the talk:
ted.com/talks/iwan_baa…

10/

This is in line with the lessons from Chrisopher Alexander who distilled a language of architecture patterns. The goal: create buildings that make use feel a quality that can only be felt but cannot be named.

11/

A pattern is a building block that can take many shapes. He defined it as a three-party rule: problem, solution and ... context. Context is essential because beauty is always contextual.

12/

Interestingly, context plays a central role in programming, too.

Consider this experiment. Take screenshots of development environments opened on two different systems, ideally from different domains. Stay at an arms length so that you cannot quite read the text...

13/

Can you say which is which? If you are using a typical development environment, you cannot (light theme vs dark theme does not count).

"There's this plague of sameness which is killing the human joy"

14/

A development environment is the gateway to the inside of a system. At the same time, we can also observe a lack of joy associated with working with legacy systems.

https://twitter.com/girba/status/1292307167551381506?s=20

"There's this plague of sameness which is killing the human joy"

15/

In 1996, Richard Gabriel put forward the idea of software habitability. Indeed, as developers spend a good deal of their active life inside software systems, it only makes sense to make the inside of those systems suitable for human inhabitance. A beautiful perspective.

16/

Software is an enormously exciting medium.

Yet, software does not look like anything. The editor that you use to type code in might make you believe software is that text. That's deeply misleading.

Software is shapeless.

17/

For software to be habitable, we need a suitable shape. That's what the environment does: it provides the interface through which we experience the inside of systems.

This interface can be powerful, but not any interface would do.

18/

Before we go further, let's take a closer look at Richard Gabriel's words:

"Habitability is the characteristic of code that enables ... people ... to understand its construction and intentions and to change it comfortably and confidently."

dreamsongs.com/Files/Patterns…

19/

He goes on to describe habitability by relating it to Christopher Alexander's "organic order". "Software needs to be habitable because it always has to change," he says. Therefore, it needs to grow together with the people inside (and likely the other way around).

20/

Now, the main argument revolves around code. Indeed, that matches the perspective taken for so long in our field. This perspective led to different languages, paradigms, patterns. A much needed perspective, indeed. Just not sufficient.

21/

Yet, somewhere towards the end of the essay we find this intriguing paranthesis:

"What is important is that it be easy ... to come up to speed with the code ... A language (and an accompanying environment) is poorly designed that doesn’t recognize this fact"

22/

The environment!

We strived for a long time to make code habitable by reshaping code, only for the results to be remain elusive. It's time to revisit our assumptions.

The environment is not an optional paranthesis. It is essential.

23/

The environment is, to this day, perceived as an interchangeable commodity: a glorified editor surrounded by an index of resources and few other bells and whistles. All software is presented in the same way, the only variance being what we read. The how never really changes.

24/

Just like with Alexander's building patterns, context is key when it comes to software environments, too, albeit for a slightly different reason. On the one hand, indeed, software is highly contextual. On the other hand, software is typically larger than fits in our brain.

25/

Presenting a system generically, as it was typed and as it runs might work in the small, but it fails in the large simply because it is too much for us to grasp more than a few screens at a time. When that happens, it feels uncomfortable. Unhabitable.

26/

To make systems habitable we need to compress their inner workings in a way that's comfortable for us. As software is highly contextual, we need presentations that match that context. But, to make it comfortable, we need presentations that match our context, too.

27/

Habitability is born when the experience matches our perspective exactly in that moment. That perspective might change in time and the environment should accompany us, as if with empathy. The environment must become our own.

28/

The environment is not an app.

"Apps are an old, old, bad idea" Alan Kay


29/

The environment must be a langauge. A language made out of operators that can be combined in many ways to match our context as we wish it. We should never have to adapt to the environment. The environment should adapt to us.

30/