CJ Eller

Thinking about tools for thinking about thinking

There is the common concept in software called technical debt. It is the implied debt of additional work caused by choosing the easier solution rather than the better one that would take more time and resources to complete.

Just like there is technical debt, I wonder if there is also metaphor debt. Could using a easy hand-me down metaphor cause more problems in the long term than it solves in the short term?

Take computer interfaces. Brenda Laurel, a pioneer in the field, expressed the importance of metaphor in creating computer experiences. She even goes so far as to say that we could be held back by one of the metaphors that holds this field of study together *: * From Howard Rheingold's Tools for Thought: The History and Future of Mind-Expanding Technology

What metaphors haven't been used? Maybe the interface is a barrier. I think that it is more than a technological question. You can't expect to solve a problem by building better interfaces if the whole idea of interface is based on an incomplete metaphor.

We have to remember that what we think of as an interface is built on a metaphor. Take the general definition I found in a dictionary:

a surface forming a common boundary of two bodies, spaces, or phases.

This is usually associated with oil and water. It just so happens that we chose to extend the association to man's relation to machines. Now, interface design is the tinkering of that surface forming a common boundary between man and computer.

Brenda Laurel's comment makes one pause. Perhaps 'interface' is an incomplete metaphor. Perhaps it makes us think inefficiently about problems around software design and web development. Perhaps it leads us down unnecessary dead ends. What happens if we used a different metaphor?

But to call the whole thing 'metaphor debt is misleading. It is another form of technical debt. Because metaphor, like language, is a technology. Michael Nielsen labels it a 'cognitive technology'. I find his definition useful *: * “Thought as a Technology” (source)

An external artifact, designed by humans, which can be internalized, and used as a substrate for cognition. That technology is made up of many individual pieces – words and phrases, in the case of language – which become basic elements of cognition. These elements of cognition are things we can think with.

No wonder I was taught not to mix my metaphors. They are the things by which we can think, by which we can process things, by which we can live. Metaphors are powerful beyond our own comprehension.

I had never heard of a perfumer's organ until it was mentioned in a post by Paradise (source). Here is a brief definition *: * alchemologie, “Perfume Organs” (source)

A perfume organ is how a perfumer organizes her fragrant materials. separating the oils between top, middle and bottom.

An image is even more descriptive (here).

It fascinates me how certain crafts that focus on a certain sense can be laid out spatially. A perfume organ is a spatial representation of smells. It allows one not only to organize oils but to create new concoctions.

The perfumer's organ is aptly named. It looks like one. Each oil is a key on that organ. The successive combination of them make pleasant music – a perfume. And if you think about it, music is produced through a spatial representation of sound – an instrument. I navigate a fretboard like I would a perfumer's organ, looking for that successive combination of notes.

All of this makes me think of how we spatially organize our web experience. Tabs in a browser window on a laptop appears less impressive when compared to rows of vials in a perfumer's organ. What is it about a perfumer's organ that intuitively feels more effective? What could we learn from bringing such a metaphor to organizing ideas on the web?

I have been thinking lately about a part of an Alan Kay piece * * A 1977 piece for the Scientific American called “Microelectronics and the Personal Computer” (source). that goes something like this:

Children who have not yet lost much of their sense of wonder and fun have helped us to find an ethic about computing: Do not automate the work you are engaged in, only the materials. If you like to draw , do not automate drawing; rather, program your personal computer to give you a new set of paints. If you like to play music, do not build a ' player piano'; instead program yourself a new kind of instrument.

Do not automate the work but augment it.

This is capitulated over and over and over again by Kay and others. Take Douglas Engelbart's 1962 paper – “Augmenting Human Intellect: A Conceptual Framework”. There is a reason it wasn't called “Automating Human Intellect”. Or how about the grandaddy of them all. Vannevar Bush's “As We May Think”. There is a reason it wasn't called “As We May Automate Thinking So We Don't Have To”. The work of these forerunners rarely emphasized the automation side of computers.

But let us be clear that the automating computers do is indeed useful. Without this function, we would be swamped by swaths of calculations and mundane tasks. But that is simply the start.

What the visions of these men reached for is giving ourselves a new set of paints, a new kind of instrument, a new form of expression, a new form of thought. That the computer could and should do this.

Lest we forget this amidst debates over technicalities. There are bigger fish to fry.

I should be writing code at the moment. But something a lot of people don't understand about writing code is there are definitely shades of breathing to it. You don't just inhale or just exhale. There's much stepping in and back. (source)

Imagine if you were painting with a delay. You would apply strokes to the canvas but they would only show after you pressed a button. Why would that get tedious? Because the feedback loop between you painting and seeing what you painted is too much. Latency gets in the way.

I wonder about this with programming. There is no feedback loop when you write code in a text editor. Nothing happens besides syntactical notifications from your IDE. Only when you feel ready to test it out do you run your code. This is where you can see your handiwork in action. Or not. Because there are many errors. So let's fix them. But not in real time silly. Go back to the text editor. Adjust the code. Now run the code again. Repeat.

This is a far cry from many other art-forms besides painting *. * Besides maybe cooking. You can spend a long time with a recipe only to find out it tastes awful after cooking it. But even with cooking we have the ability to taste and adjust our recipe as we go along.I came to programming from music of all places – dropping out a PhD program for classical guitar performance and going into IT. With a guitar the feedback loop was fairly closed. I would prepare my left hand and play a chord. If something was off I could adjust and play the chord again. Little to no latency.

But of course there are a lot of other things going on in that moment. I am reading sheet music, sensing how my fingers interact with the strings, hearing the resulting chord, feeling the reverberations through my body. There are so many latent capabilities that are being acted upon in that instance. Aural, visual, kinesthetic, spatial.

I wonder if the experience of coding pales in comparison because it does not act upon these human capabilities. Perhaps it is why people have trouble getting into programming in the first place, why the plea for everyone to learn to code falls short. It makes no difference if we close the feedback loop with better live programming. There is still something about programming that causes latency *. * Read Bret Victor's “Learnable Programming” if you haven't already. It explores these topics in a much better way than I. (source)

It's amazing that with all the advances on the web, we still consider mailing lists as a core, essential part of reaching out to people. Probably because email is such an important part of our lives as a citizen of the internet.

I second Triptych's statement. The more I learn about how email works, the more I realize how it serves as a foundation for understanding the web. Not only for the past and present. Email could help us understand the future too.

This occurred to me recently when learning about ActivityPub, a decentralized protocol used by social networks like Mastodon and Pleroma (and Write.as!!!). Many sources compare ActivityPub to email *. * “ActivityPub enables a decentralized social web, where a network of servers interact with each other on behalf of individual users/clients, very much like email operates at a macro level.” -Darius Kazemi, “Decentralized Social Interactions with ActivityPub” (source) The comparison went so far as to make one subreddit user remark with the following:

I can't figure out what advantages ActivityPub has over email. It seems to just be a way of sending messages to one or more recipients. Email already does this. Couldn't you just stash that blob of JSON in an email body? That way, no new servers would need to be set up; everyone already has an email address. (source)

It makes me wonder how recent developments like the decentralized web are echoes of foundational technologies/protocols like email. If we better understand the past then perhaps we could better understand where we want to go. A form of “retrospective futurism” * * A term coined by Howard Rheingold to describe his book Tools for Thought, “an exercise in retrospective futurism; that is, I wrote it in the early 1980s, attempting to look at what the mid 1990s would be like.” – looking back in order to look forward.

One of the best parts of a composition notebook is the margins.

Sometimes you have a stray thought. It is not fully developed and yet you want to write it down. Why have it take up a precious line? Put it in the margins.

Sometimes you want to support a thought with a quick aside. But that would be break the flow of your writing. No matter. Put it in the margins.

The margins are a beautiful place to put asides. Unlike footnotes, they allow you to have the text and the aside close together. No jumping around from top to bottom to top to bottom to top *. * “The goal is to present related but not necessary information such as asides or citations as close as possible to the text that references them. At the same time, this secondary information should stay out of the way of the eye, not interfering with the progression of ideas in the main text.” – Dave Liepmann on 'marginnotes' (source)

The margins in Write.as are a blank canvas from which to try such things. All that is required is a little CSS. It might gunk up your text as you include them but let's be frank – the reader will only see the end product.

So I went into the 'Customize' settings for my Write.as blog and went down to 'Custom CSS'.

Here is what I added * : * All of this CSS is from Tufte CSS, a wonderful project. (source) I understand that some of the CSS might be superfluous but I am a novice and terrified of taking out one thing that will truly make the cascading style sheets cascade.

.marginnote { float: right;
                       clear: right;
                       margin-right: -60%;
                       width: 50%;
                       margin-top: 0;
                       margin-bottom: 0;
                       font-size: 0.8rem;
                       line-height: 1.3;
                       vertical-align: baseline;
                       position: relative; }


.marginnote:before { font-family: et-book-roman-old-style;
                                   position: relative;
                                   vertical-align: baseline; }

blockquote .marginnote { margin-right: -82%;
                                           min-width: 59%;
                                           text-align: left; }
   

Then all you need to do is add a span element with the class of “marginnote” and you are off to the races. It takes some getting used to but makes sense after a bit.

If all you have is a hammer, everything looks like a nail.

The Law of the Instrument. Its jurisdiction reaches across all tools. Especially digital. There is one variation in particular that I would like to focus on:

If all you have is a text editor, everything looks like a blog post.

Write.as is a publishing platform with a minimal text editor. Nothing more and nothing less. With such freedom, one could imagine the possibilities. And there are people like Inquiry and Paradise and Triptych who are experimenting with the platform. From embedding code to making letters to other Write.as users. Genuinely inspiring stuff.

Can we do more like this? More interesting and useful stuff? New forms of writing? More than rehashing articles and blog posts? Can we go against the Law of the Instrument? I echo Matt Baer's tweet:

Create a tool that leaves things reasonably open, and people will inevitably find incredible new uses for it.

A letter arrives in the mail. It is from a friend who you had written to a month ago. She finally got back with a reply. Your heart skips a beat. Now look at your notifications on social media. Somebody favorited for your post. How do you feel? Is that feeling similar to when you received a letter in the mail?

I have been curious about this disparity ever since Inquiry posted about the joy of being referenced (source). There is something different to being written to in a long form composition. More intention. More connection. I cannot accidentally send a letter to you like I can accidentally favorite a Facebook status.

Which is why I go back to Write.as creator Matt Baer's description of the community forming in Read Write.as: “pen pals in a digital space” (source).

One part of Wikipedia's definition of 'Pen pals' to focus on: “Pen pals are usually strangers whose relationship is based primarily, or even solely, on their exchange of letters.” Does this sound familiar? We form relationships that are based primarily, or even solely, on the web.

But we do much more than exchange letters on the web. Statuses, photos, articles, podcasts, music. An advantage for sure. Sometimes, however, I wonder if the sometimes bloated nature of the medium can get in the way of true relationships forming.

Maybe all we need to start is an address to send to and a return address. All in the form of hyperlinks. What can we get from that?

I was driving to work the other morning and missed my turn. Right into the wrong parking lot. No matter. The parking lot I turned into looked like it connected to the correct one. Just find where the parking lots meet and drive right in.

But as I drove around the perimeter, I discovered that there was no connection. I had to drive back onto the road, turn around, and make the correct turn.

And what prevented me? A tiny curb dividing maybe a foot of grass from the lot on the opposite side. That was it.

This moment of frustration happens all the time with software. Why cant I easily import content from one place to another? Why isn't there an API that I can access my data with? There just seems to be a curb that divides our wishes and the software's wishes.

Inquiry wrote about “user exits”, a common term which I hadn't heard of until reading (source). It perfectly encapsulates what we need. The ability to “exit” the perimeter of constraints and customize software accordingly.

I think of ideal software as permeable. Not to a fault of course. Therein lies the true balancing act.

Take out the algorithm.

This is a popular suggestion for social network like Facebook and Twitter to implement. The logic implies that the black box is the problem and transparency the solution.

One example is the demand for social feeds to be solely chronological. A user would see everything that was posted by their friends and groups they follow. Nothing more and nothing less.

But that is the problem. A user would see everything. Whose to say that your post wont still be buried under the deluge? Whose to say that a tweet you wanted to see wont be lost forever? Taking out the algorithm still leaves you with a feed. Even making a feed chronological is choosing one algorithm over another.

We are left with the same problem that the forerunners of computing had to deal with. Management of information. Instead of ballistics data it's tweets and blog posts and photos and misinformation.

Perhaps it is an ongoing problem, one that is embedded in humanity. Something we cannot completely solve but can edge closer to truly understanding.