CJ Eller

Thinking about tools for thinking about thinking

With the ways that we consume information, it begs a particular question. Do we genuinely process what comes from these inputs? Countless storage and retrieval software declare that we can – web annotation, visualization tools, all-in-one workspaces, bookmark services. Take Dropbox's mission:

We’re here to unleash the world’s creative energy by designing a more enlightened way of working.

That is an emphatic 'yes'. But even with all of these methods making knowledge storage and retrieval easier, the question remains. Sure, you create a more enlightened way of working, but does that software help people understand what it is they are storing and retrieving?

Far from a 21st century concern, this question has been asked time and time again. One passage that comes to mind is almost five centuries old. 16th century philosopher Michel de Montaigne voiced his concern in an essay titled, well, roughly translated to, Of Pedantry. He points out the following:

We only labour to stuff the memory and leave the conscience and the understanding unfurnished and void. Like birds who fly abroad to forage for grain, and bring it home in the beak, without tasting it themselves, to feed their young; so our pedants go picking knowledge here and there, out of books, and hold it at the tongue’s end, only to spit it out and distribute it abroad.

So then we can ask ourselves a variation of the question. Are these software tools only stuffing our memory and leaving the conscience and the understanding unfurnished and void? Are these solutions no better than spitting out grain for others while we have not fully tasted the grain ourselves?

What can be done differently to furnish our conscience and understanding of the knowledge we take in and distribute?

It is fascinating to see where publicly displaying one's lack of knowledge can lead. The true etymology of “blog” was brought to my attention by Bix. Jorn Barger's 1999 FAQ on “Weblog resources” first coined it as such:

A weblog (sometimes called a blog or a newspage or a filter) is a webpage where a weblogger (sometimes called a blogger, or a pre-surfer) 'logs' all the other webpages she finds interesting.

What struck me about the definition here is the task – web logging. The posture resides on setting out first. Being the first to navigate. Being first to surf. All to help others maneuver more easily across the web.

55 years prior to Barger, Vannevar Bush intuited a similar kind of work in “As We May Think”:

There is a new profession of trail blazers, those who find delight in the task of establishing useful trails through the enormous mass of the common record.

Though using different language, the trail blazer of Bush is doing the same thing as the web logger of Barger. Both help others traverse large bodies of information by creating referable resources.

And I don't think it is a coincidence that we are still doing this now. Logging is the way we not only retain knowledge but create entire domains of knowledge from which others can build upon. It reminds me of what Bush thought the (web) trails of such people could mean to others:

The inheritance from the master becomes, not only his additions to the world's record, but for his disciples the entire scaffolding by which they were erected.

Who knows what scaffolding we could be erecting for people. So let us thoughtfully blaze our trails and log our web.

Where does the “log” in “blog” come from?

Before the web, everything about a ship's journey was kept in a log book – speed, weather, condition, progress to its destination. Without keeping track of these things, patterns could not be ascertained. Are we going in circles? Will the ship make it without repair? Does bad weather appear imminent? All of which could be investigated through a log. It served as an external memory device, a second anchor of sorts lest our mind go adrift.

The web is our sea. Immense, confusing, all consuming. It is easy to be caught in its tide, to lose one's self. No wonder we need a web log in order to record where we've been, what we read, what we thought. Because how could we remember all the things that run through our lives, especially on the web?

I think of this in light of an acute observation from Bix:

One thing I've noticed lately is that if I save links to blog about rather than links to “read later” (and they are right when they ask how often it seems like we are saving links to forget to read), I end up not only reading more of them but also creating a record of having done so.

Saving links to blog about rather than to read later ensures we make a lasting record of them. I now have a record of reading Bix's post on July 30th of 2019. All of my surrounding thoughts on his post are here and can be referred to. Connecting the prior and subsequent blog posts, we can get a deeper sense of time, of place, of identity.

Instead of being adrift, we notice we are on a journey.

Italo Calvino once wrote about the Odyssey being about remembering the journey. That is what Odysseus was trying to do as he trekked back to Ithaca and as he recounted his travels. To remember where he came from and where he was going. That is what we do when we blog. I will leave the last word to Bix:

How to remember? We blog about it.

This question was the bane of one's existence in English class, especially if you did not do the reading. Class discussion separated the wheat from the chaff. Some people were great at spinning up explanations to make it appear as though the read. Others were not as lucky.

But the question has a more universal application. Today we have the ability to share content at the click of a button. With that comes suspicion over whether a person has read the article she's sharing. Does she know what the article is actually proposing? Did she do the reading?

Not doing the reading has impact – an unfulfilling class experience, a muddied culture. We all need to be on the same page if we are to move forward.

This is where annotation comes in. It offers a window into the mind of the reader. As Ann Blair put it in this New York Times article,

“The note is the record a historian has of past reading,” said Ann Blair, a professor of history at Harvard and one of the conference organizers. “What is reading, after all? Even if you look introspectively, it’s hard to really know what you’re taking away at any given time. But notes give us hope of getting close to an intellectual process.”

So when we want to share a piece of writing on the web, I wonder if it better to share one's notes. Then there is a glimpse of an intellectual process. We can see that you have done the reading. That is a jumping off point.

Because then a worthwhile conversation can happen.

All of our digital notes are kept seen within this rectangular surface called a computer. We comb through them via a tiny window called a screen. But even using the word 'combing' seems disingenuous. That implies a social and spatial environment we walk through, scan, and analyze stacks of written word.

Far from the case.

The artist David Hockney once said that photograph “is all right if you don't mind looking at the world from the point of view of a paralyzed Cyclops.” I wonder if that is what rummaging through digital notes feels like sometimes – from the point of view of a paralyzed Cyclops. Folder structures are a flatland representation. We fumble over search bars and hyperlinks, yearning for an approximation of the real thing.

Perhaps that is what makes crate digging for vinyl records so appealing – a truly social and spatial experience of searching through knowledge, both knowing and not knowing what you might find.

But the web can capture that. Designer Ian McDonald saw this as one of the crowning virtues of the early web:

I think Theseus would have enjoyed the World Wide Web in 1997; the adventure and excitement that it fostered. Its labyrinthine shape full of passages, turns, tunnels, and the unknown. Websites often eschewed the formal navigation systems we have come to rely on and expect in favour of more open-ended or casual solutions. Moving around a site—much like moving around the Web in general—was a journey that embraced the forking, wandering naturing of hypertext and allowed the user—with varying degrees of agency—to choose their own path through cyberspace, the hero of their own self-authored epic.

But McDonald saw the homogenization of design made traversing the web bland.

Today’s active web design is enraptured with menus as a primary means to navigate a website. All user actions are predefined, and the journey through the material is as prescripted as possible in an effort to achieve maximum linearity.

We are once again turned into paralyzed Cyclopses, limited by linearity. It makes one wonder how to embrace what the web as it is rather than what it is not. Why replicate past structures when something entirely different beckons. What can we do with it?

For such a scathing interpretation of the camera, Hockney did some of his most inventive work in photography. These pieces represent not a single Cyclops but a composite of Cyclopses. With so many singular perspectives you start to see a grander picture.

Sounds like the web on a good day.

Write a letter a day for 15 years straight.

That is a rough estimate of how many letters Thomas Jefferson made copies of by 1803.

His method? The polygraph – a series of mechanical linkages that connected to another pen. When you wrote, the second pen would copy your movements. Jefferson deemed the device “the finest invention of the present age.”

That is worth noting. One of the most accomplished polymaths in the 18th century championed a duplicating device as the invention of his age. Why? Hillel Schwartz fills out the context for his choice:

a prolific correspondent who, after the American Revolution, [Jefferson] was wont to keep close records of his letters. Twice, Jefferson's papers had been lost, once in a fire, again in 1780 during a British raid on Richmond. Sensitive to the precariousness of originals, Jefferson tried any device that might redeem the hours he spent entering into journals a précis of each letter he wrote. In 1803 he endorsed the [polygraph] [...]

“I only lament that it had not been invented thirty years sooner.”

This coming from a man whose daily routine consisted of “drudging at the writing table” from sunrise to one or two o' clock – at least seven hours if not more. No wonder he wanted to redeem those hours however he could. For all those words, both from Jefferson and his interlocutors, to be preserved. The polygraph allowed for the redemption he sought.

Think of that in light of the writing we do on the web. From blog posts to status updates to papers to memos to email threads to comments. Our output rivals Jefferson's in scope.

But do we think about preserving those blog posts or emails in some shape or form? Do we think about what will happen to this writing if we do nothing about it? Do we expect it to stay around forever like some eternal library?

There is a lot of talk about publishing on the web, of getting your writing out there.

What time is spent talking about how we redeem those hours?

The act of copying, whether from the printer or the browser, is now a pedestrian task. We forget how such a phenomena was less than obvious years ago. That is why looking at its history is so fruitful.

Here is a notable anecdote from Hillel Schwartz's The Culture of the Copy:

The speed, volume, and sheer habit of copying photochemically, as prevalent in Nazi Berlin an Conservative London as in New Deal Washington, encouraged the illusion that to copy was to comprehend. Did the American researcher who returned with 80,000 microfilmed documents after a summer's descent upon Europe around 1935 ever read those documents, or had duplicative edacity become self-deception? Medieval monks had gained at least a familiarity with scripture when copying texts at 4700-5500 characters a day. Office copyists in 1917, held to a standard of two typewritten lines (100 characters) per minute, reproduced perhaps 48,000 characters each day and scarcely remembered what passed before their eyes.

Copying as comprehension – when copying by hand, the notion seems valid. But once a wider buffer entered between the copier and the copied, memory blurs. It is startling to read about this happening with photocopiers.

Now imagine what is comprehended when blindly manipulating symbols on a screen. Ctrl + Alt + C takes such little thought that sometimes we copy more than what we wanted. We archive articles to read later with the click of a button. But how often does it feel like archiving articles to forget to read?

I wonder whether the gulf between copying and comprehension is salvageable. Do we resort to copying by hand? In today's world that seems quixotic. Perhaps we hybridize our copying methods – some by hand, some by typing, some by Ctrl + Alt + C, some by highlighting?

This appears to occupy a reasonable outlook – optimistic enough to believe that copying and comprehension is salvageable but pessimistic enough to disagree on one “killer app” solving the problem.

We want to add more friction to our software – to take out the ease of use that can spiral into addictive or abusive behavior. Even with all good intentions in the world, this friction can miss the mark.

Take a commenting system for this blog. An email based system, kind of like a Letter to the Editor, seemed suitable. One of its virtues was the friction it added. Someone had to open up her email, write a thoughtful response, and then click send. These steps would hopefully slow people down.

But if you look at my inbox here, it is nothing but spam. What I thought would add enough friction to prevent spam did not stop it at all. The stuff kept coming and coming. Why?

It was then I realized that I was thinking about friction the wrong way. For a person like you or me, the process of opening our email and writing an email and sending an email is enough friction.

But what about for a web scraper? Easy as can be. Once a bot has my email, it can send me all kinds of spam. The tables turn. Email is susceptible to all kinds of automated attacks. An industry for email security exists for a reason.

Friction makes sense when we are talking about a human. It disappears in light of humans augmented by automated processes. People design programs to go around systems that have built in resistance. Is that not the double-edged sword of programming? Sure, it makes things easier for us normal citizens, but it also allows bad actors to do things much easier as well.

When designing a system for friction, we also have to keep in mind how a person could run through our system with a program. How easy are the processes to automate? And what does that mean if the process is automated? Thankfully for my commenting system, the spam does not harm anyone. Nobody sees the posts and if they do, it is an amusing word soup. In any other context, however, it could prove harmful.

But not all of it is negative. People can write programs to automate your system to do normal tasks. That is what makes web API's so wonderful. And besides, friction can be added to API's via authentication and request limits.

So even though we are designing friction for people, we must extend the definition of “people”. Because it is not only people clicking through the instructions you laid out for them. It it also people who can program, who understand the processes laid out and can reverse engineer them, who know how to remove friction to get what they want. Not all of that is bad. We just have to keep it in mind.

What if you were the only subscriber for a blog? Nobody else would read that blog but you.

I have been thinking about this with Write.as' email subscription feature. Only you would receive an email when a new post popped up.

Why do this? For it would be idiotic for you to receive notifications about posts you published in the first place. Indeed, but what if you were not publishing the posts directly? Maybe you have a web app that generates a post with data coming from an event elsewhere.

Write.as becomes an event listener of sorts. A blog could be a collection of posts generated from a form, a collection of messages from a Slack channel, a collection of various text based things. All of which would be notified via email and accessible from your Write.as blog.

And I think that is where the term “blog” becomes fuzzy amidst these kind of use cases. “Collection” works much better (and is used within Write.as' API documentation). A collection can be, well, a collection of whatever posts you like. Not just blog posts. Not just essays. Not just poetry. It does not have to be a blog. Your collection can be an inbox, an event log, an inventory, whatever you'd like.

Here's to more use cases.

When you go to purchase a car, the features are finely laid out. Everything from the engine to the electronics are advertised and listed.

But what if this wasn't the case? Imagine having to lift up the hood to find out about the littlest detail about an engine. Imagine having to take apart the center console to figure out if there was AM/FM radio included. It would be a mess. You don't want to tinker. All you want to do is look at the specs.

Sometimes looking at the web feels this way. Don't get me wrong, developer tools in browsers are incredible. But do I need to peel away all of these layers of source code to find a couple lines of custom CSS for a blog? Why can't some aspects be more accessible?

I write this in light of finding an awesome Write.as blog that has an equally awesome commenting system (here). How did he get that to work? I inspected with developer tools to no avail. Then I recalled that the Write.as API returns the custom CSS and JavaScript of a blog if you ask for it. A couple keystrokes in the command line later and the question was answered.

This instance got me thinking about how important having those little specs at hand are. Now that I know what it is, I can modify that custom JavaScript and use it for comments on my Write.as blog. But this also made me realize that playing with the API is not something everyone wants to do – another form of tinkering really. And that is completely understandable.

So I wonder if creating a utility for easily grabbing these custom CSS and JavaScript specs for Write.as blogs would be of some utility. It would allow people to look within the network of other Write.as blogs and see how others have put in custom code to make their blogs unique.

Less looking under the hood and more transparency of specs.