Turning the Blob inside out

Idiosyncratic apps come between you and your data...

Note: this article’s intro has been restructured a little, to reflect some changes in my thinking since it was first published.

Firstly I’d like to welcome all my new subscribers! I hope you’ll find the ideas here fun or thought-provoking at least, and maybe even inspiring. My last article generated a lot of interest and feedback, some of which has motivated this follow-up article.

In the previous article, I explained how we can recover freedom and empowerment over our own data by smashing the “app trap” - via an OS without apps. We learned how apps come between us and our data and carve up our different types of data as well as our identities. We are also familiar with how Big Tech run on the principles of “surveillance capitalism” and “data is the new oil”.

This article discusses the Blob! How apps are idiosyncratic, techie things that we can… simply turn inside-out!

---

The word “Blob”, although it sounds like my humorous jab at techies, is in fact a technical term - used by techies of open source to have a jab at uncooperative big corporations who provide inscrutable, closed, proprietary and legally-bound software.

I’m re-purposing it for a similar phenomenon: the way that apps are all closed, idiosyncratic and unpredictable.

Say you have two apps, a calendar and a to-do list. What is the “Blob trap” that these two apps have you in?

---

The Blob app trap

Apps are techie things, coming from a world closed off to most folk. Even if the app is open source, as a non-techie it’s just as inscrutable as a closed, proprietary one.

With the Blob you have to put up with each app’s particular way of letting you interact with your precious data. Each app often does the same things in different ways:

When you hit the “new to-do” button in that app, you get some fields to fill in. When you hit the “new event” button of the calendar app, you get some fields to fill in, but you can be almost certain that, from the button all the way to how the fields interact and how the end result looks, everything will be subtly, or dramatically, different. You won’t be able to move things around in the same way. Renaming will be done differently, etc. But it’s not just lists and tables that will behave differently. For example, many apps have calendars and maps of their own. And no two calendars or maps will ever look or work quite the same.

These differences will be determined by the combination of techies’ preferences and marketing motivations within each app development company at any time. And each update brings with it the dread of what the marketing department or the latest techie trends will try to force upon you this month. Will they take away functionality you’ve got used to, or have come to depend upon? They often do.

Also, of course, don’t even think to ask for functionality that suits you, not them.

Note that both desktop applications and browser tabs are exactly the same. All web pages suck in huge programs to mediate your access to any data you create.

So, in summary, your data is only accessible through an inscrutable, idiosyncratic and volatile Blob!

---

App functionality

Now, we’re building the OS with no apps, so we won’t have these problems! Without apps, our data is first class and under our complete control. We can live the virtual part of our lives free and empowered, in a planet-spanning, shared space.

But, of course, those apps did provide us with various functions that we will still need.

There are two parts to the functionality that those apps gave us:

1. the app’s internal logic

2. the app’s user interface

The internal logic looks after how your data evolves, ensuring it stays correct and reflects what you want.

The user interface is the manner of your interaction with the screen elements via touch or keyboard input.

A to-do list’s user interface shows you your list of jobs, then when you tap the last job “done”, the internal logic spots that the whole list is done which in turn causes the user interface to render the list title a bit softer, or with a strike-through. The internal logic around the list may push “done” items below the ones in the list that are still-to-do. If a single to-do item has a “due date and time”, then the internal logic can mark that item “due” when it’s past that time. The user interface can then give an alert to the user.

These two parts are handled in the Object Network by, respectively:

1. internal animation in all data objects

2. the user object

---

Internal animation

Every data object of a given type has a predictable “internal animation” or behaviour for that type.

Now, instead of a monolithic homogeneous blob of techie logic code managing everything, each object is self-animating in expected ways:

The to-do list object looks at its to-do objects and can see that all of them are now “done”, so it sets itself to “done”. The to-do list object sees a to-do object is now “done”, but not placed at the bottom, so it moves it inside itself. A single to-do object looks at its own “due time”, compares that to the clock and sees it’s past due, so sets itself to “due”.

These behaviours are built in to each object of any given type. And you can expect them to work if an object is visibly of some type. No more functionality surprises. And an object’s data or current state is always visible first; its behaviour is tucked away inside it. Just like in the real world.

---

The user object

There’s an object that represents YOU! It’s called the user object. The user object takes what you do on the inputs - touch or keyboard - and manifests them in the virtual space. Conversely, what the user object “sees” in the space is rendered onto the screen for you to see. It’s basically an avatar.

If you - your user object - is “looking” at the to-do list, it shows the list and all of the to-do items, with “done” ticks. If the whole list is “done”, it renders it softer or with a strike-through. When a single to-do is saying it’s “due”, the user object in turn pings you.

How the user object shows you stuff is, again, the same for each type of object it’s “looking at” in the world. And how it takes your inputs will be similarly consistent, across all objects of each type in the space you’re in. So no more render or interaction surprises.

Note that there are other objects like the user object, that bring state into the virtual world from the real world, such as clocks and cameras and compasses.

---

Customising behaviours and interfaces

In the previous article, on the subject of the solution to the Blob, in order to keep things short and snappy I went right to the spreadsheet-like programming language that can be used to write your own internal object behaviours and animations. There will be occasions where you want to extend or override the built-in behaviour of an object, and that’s how that’s done.

Also, of course, you may want a custom user interface so that you can tell the user object how you’d like to see things. This can be achieved with - no surprise here - a “user interface” object!

With these two customisation tools, you can also create completely new types of object with completely new behaviours, interactions and animations.

---

Invert the Blob!

We’re actually turning everything inside out: all of the apps’ functions are now inside our data objects:

This is how spreadsheets work: you see the data of a cell first, and the formula animating it is hidden inside.

In the virtual world of the Object Network, just like in the real world, when you see something of a certain type, you can have reasonable expectations for how that object will behave and interact with you.

And “you” are all “objects” in this world, too (but the “reasonable expectations” thing may be less applicable there!)

---

What do you think? Drop your thoughts into the comments below.