diego's weblog

there and back again

Category Archives: software

2 idiots, 1 keyboard (or: How I Learned to Stop Worrying and Love Mr. Robot)

I’d rename it “The Three Stooges in Half-Wits at Work” if not for the fact that there are four of them. We could say the sandwich idiot doesn’t count, though, but he does a good job with his line (“Is that a videogame?”) while extra points go to the “facepalm” solution of disconnecting a terminal to stop someone from hacking a server. It’s so simple! Why didn’t I think of that before!?!?!

Mr. Robot would have to go 100 seasons before it starts to balance out the stupidity that shows like NCIS, CSI and countless others have perpetrated on brains re: programming/ops/etc.

Alternative for writers that insist in not doing simple things like talking to the computer guy that makes your studio not implode: keep the stupid, but make it hilariously, over the top funny, like so:

We’ll count it even if it’s unintentional. That’s how nice we computer people are.

PS: and, btw, this, this, is why no one gets to complain about Mr. Robot’s shortcomings.

not evenly distributed, indeed

The future is already here – it’s just not very evenly distributed.

— William Gibson (multiple sources)

The speed at which digital content grows (and at which non-digital content has been digitized) has quickly outpaced the ability of systems to aid us in processing it in a meaningful way, which is why we are stuck living in a land of Lost Files, Trending Topics and Viral Videos.

Most of those systems use centuries-old organizational concepts like Folders and Libraries, or rigid hierarchical structures that are perfectly reasonable when everything exists on paper, but that are grossly inadequate, not to mention wasteful and outdated, in the digital world. When immersed in the digital information is infinitely malleable, easily changeable, and can be referenced with a degree of precision and at scales that are simply impossible to replicate in the physical world, and we should be leveraging those capabilities far more than we do today outside of new services.

Doing this effectively would require many changes across the stack, from protocols, to interfaces, to storage mechanisms, maybe formats. This certainly sounds pretty disruptive, but is it really? Or is there a precedent for this type of change?

What We Can Learn From The Natives

“Digital native” systems like social networks and other tools and services created in the last decade continue to evolve at an increasingly rapid pace around completely new mechanisms of information creation and consumption, so a good question to ask is whether it is those services that will simply take over as the primary way in which we interact with information.

Social media, services, and apps are “native” in that they are generally unbounded by the constraints of old physical based paradigms — they simply could not exist before the arrival of the Internet, high speed networks, or powerful, portable personal computing devices. They leverage (to varying degrees) a few of the ideas I’ve mentioned in earlier posts: context, typically in the form of time and/or geographical location, an understanding of how people interact and relate to each other, a strong sense of time and semantics around the data they consume and create.

Twitter, Facebook, and others, include the concept of time as a sorting mechanism and, at best, as another way to filter search. While this type of functionality is part of what we are discussing, it is not all that what we are talking about, and just like “time” is not the only variable that we need to consider, neither will social media replace all other types of media. Each social media service is focused on specific functionality, needs, and wants. Each has its own unique ‘social contract.’

Social media is but one example of the kind of qualitative jumps in functionality and capabilities that are possible when we leverage context, even in small ways. They are proof positive that people respond to these ideas, but they are also limited — specific expressions of the use of context within small islands of functionality of the larger world of data and information that we interact with.

Back on topic, the next question is, did ‘digital natives’ succeed in part because they embraced the old systems and structures? And if so, wouldn’t that mean that they are still relevant? The answer to both questions is: not really.

Post Hoc, Ergo Propter Hoc

Facebook and Twitter (to name just two) are examples of wildly successful new services that, when we look closely, have not succeeded because of the old hierarchical paradigms embedded into the foundations of computers and the Internet, but in spite of them. To be able to grow they have in fact left behind most of the recognizable elements on which the early Internet was built. Their server-side infrastructures are extremely complex and not even remotely close to what we’d have called a “website” barely a decade ago. On the client side, they are really full-fledged applications that don’t exist in the context of the Web as a mechanism for delivering content. New services use web browsers as multi-platform runtime environments, which is also why as they transition to mobile devices more of their usage happens in their own apps, in environments they fully control. They have achieved this thanks to massive investments, in the order of hundreds of millions or billions of dollars, and enormous effort.

This has also carried its cost for the rest of the Web in terms of interconnectivity. These services and systems are in the Web, but not of it. They relate to it through tightly controlled APIs, even as they happily import data from other services. In some respects, they behave like a black hole of data, and they are often criticized for it.

This is usually considered to be a business decision — a need to keep control of their data and thus control of the future, sometimes with ominous undertones attached, and perhaps they could do more to open up their ability to interface with other services in this regard.

But there is another factor that is often overlooked and that plays a role as or more important. These services’ information graphs, structures, and patterns of interaction are qualitatively different than, and far removed from, the basic mechanisms that the Web supports. For example, some of Facebook’s data streams can’t really be shared using the types of primitive mechanisms available through the hierarchical, fixed structures that form the shared foundation of the Internet: simple HTML, URLs, and open access. Whereas before you could attach a permalink to most pieces of content, some pieces of content within Facebook are intrinsically part of a stream of data that crumbles if you start to tease it apart or that requires you to be signed in to verify whether you have access to it or not, how it relates to other people and content on the site, etc. The same applies to other modern services. Wikipedia and Google both have managed to straddle this divide to some degree, Wikipedia retaining extremely simple output structures, and Google maintaining some ability to reference portions of their services through URLs, but this is quickly changing as Google+ is embedded more deeply throughout the core service.

Skype is an example of a system that creates a new layer of routing to deliver a service in a way that couldn’t be possible before, while still retaining the ability to connect to its “old world” equivalent (POTS) through hybrid elements in its infrastructure. Because Skype never ran on a web browser, we tend not to think of it as “part of the Web,” something we do for Facebook, Twitter, and others, but it’s a mere historical accident of when it was built and the capabilities of browsers at the time. Skype has as much of a social network as Facebook does, but because it deals mostly with real time communication we don’t think of putting them in the same category as we do Facebook, but there’s no real reason for that.

Bits are bits, communication is communication.

Old standards become overloaded and strained to cover every possible need or function *coughHTML5cough*. Fear drives this, fear that instead of helping new systems would end up being counterproductive, concerns of balkanization, incompatibilities, and so forth. Those concerns are misplaced.

The fact is that new services have to discard most of the internal models and technology stacks (and many external ones) that the Internet supposedly depends on. They have to frequently resort to a “low fidelity” version of what they offer to connect to the Web in terms it can “understand.” In the past we have called these systems and services “walled gardens.” When a bunch of these “walled gardens” are used by 10, 20, or 30% of the population of the planet, we’re not talking about gardens anymore. You can’t hold a billion plants and trees in your backyard.

The balkanization of the Internet has already happened.

New approaches are already here.

They’re just not evenly distributed yet.

scenario #1

“I just know I’ve seen it before.”

You’re meeting Mike, who waits patiently while you mumble this. Browsing, navigating through files, searching. Something you were looking at just yesterday, something that would be useful… You remember telling yourself this is important, then getting sidetracked following up on the last in the list of emails you needed to exchange to set the time for the meeting, switching between checking your spam folder for misplaced messages and your calendar for available times, then a phone call… but that doesn’t help… you know you won’t find it. You briefly consider checking the browser on your laptop, but the thought of wading through two-dozen-plus spinning tabs as they load data you don’t need while trying to find something you can’t even describe precisely doesn’t sound like an inviting prospect. You give up.

The meeting moves on. You start to take some notes. Suddenly, a notification pops up but it goes away too quickly for you to see it. You don’t know what it is, so you load the app, disrupting the conversation and your note-taking. It’s a shipment tracking notification. You close the app and go back to your notes, now stuck at mid-sentence.

The flow of the conversation moves to a blog post Mike forwarded to you recently, but you can’t remember seeing it. You find the email, eventually, but after clicking on the link in the results page the window is blank and the page doesn’t finish loading. You wait five seconds. Ten. You give up, close the tab, and keep going.

Hours later, you are at home, reading through the news of the day, and you suddenly remember that blog post again. While it’s loading, you get an alert. Twin beeps. You glance at it. Meeting with Mike, 8 pm, it says. A second later, the phone beeps.

Meeting with Mike, 8 pm.

Two rooms away, you hear your tablet, beeping. You don’t need to go look at it. You know what it says.

Meeting with Mike, 8 pm.

It turns out that the time you set in the calendar entry when you originally created it was incorrect, the fixed one was a duplicate, and all your calendars are now happily notifying you of an upcoming meeting that actually happened hours ago. You dismiss the alert on your laptop, but this doesn’t do much for the alerts on your other devices.

In fact, an hour or so later, when you start using the tablet, the alert is still be there, even though it’s two hours after when the meeting should have happened. Now you’d like to finish reading what you had started earlier in the day, but the list of “cloud tabs” seems endless, and when you finally find what you want to read, you can’t remember exactly where you were in the article. You don’t want to read it all again, not now. You mark it to “read later” … and give up.

Oh, well. Maybe there’s something good on TV that you can watch on the phone.

they’re moving to agile any day now

Great story: the most obsolete infrastructure money could buy. If you know the meaning of words/acronyms like RCS, VAX, VMS, Xenix, Kermit and many others and have been waiting anxiously for a chance to see them use in actual sentences once more, here’s your chance. Choice quotes:

[…] on my first day I found that X was running what was supposedly largest VAXcluster remaining in the world, for doing their production builds. Yes, dozens of VAXen running VMS, working as a cross-compile farm, producing x86 code. You might wonder a bit about the viability of the VAX as computing platform in the year 2005. Especially for something as cpu-bound as compiling. But don’t worry, one of my new coworkers had as their current task evaluating whether this should be migrated to VMS/Alpha or to VMS/VAX running under a VAX emulator on x86-64


After a couple of months of twiddling my thumbs and mostly reading up on all this mysterious infrastructure, a huge package arrived addressed to this compiler project. […]

Why it’s the server that we’ll use for compiling one of the compiler suites once we get the source code! A Intel System/86 with a genuine 80286 CPU, running Intel Xenix 286 3.5. The best way to interface with all this computing power is over a 9600 bps serial port. Luckily the previous owners were kind enough to pre-install Kermit on the spacious 40MB hard drive of the machine, and I didn’t need to track down a floppy drive or a Xenix 286 Kermit or rz/sz binary. God, what primitive pieces of crap that machine and OS were.

Go read it, and try to avoid laughing, crying, shuddering, or shaking your head (possibly all at the same time).

who adapts to whom?

graffitiTen years ago, the PalmPilot trained millions of people to write in primitive scribbles so the device could “understand handwriting.” Today, social networks asks that you partition the entire world into “Friends” and “Not Friends.” Note-taking software may require you use tags to organize information. Others give you folders. Others, both. 

The idea that we should adapt to how machines work or how they model data isn’t new. In fact it goes all the way back to what we could call the “origin document” of the modern information age (if there was one): “As We May Think” by Vannevar Bush.

It starts off with promise. Early on, talking about access to information, Bush puts forward the view that we should build systems that “work like the human mind:”

“The real heart of the matter of selection, however, goes deeper than a lag in the adoption of mechanisms by libraries, or a lack of development of devices for their use. Our ineptitude in getting at the record is largely caused by the artificiality of systems of indexing. When data of any sort are placed in storage, they are filed alphabetically or numerically, and information is found (when it is) by tracing it down from subclass to subclass. It can be in only one place, unless duplicates are used; one has to have rules as to which path will locate it, and the rules are cumbersome. Having found one item, moreover, one has to emerge from the system and re-enter on a new path.

The human mind does not work that way. It operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accordance with some intricate web of trails carried by the cells of the brain. It has other characteristics, of course; trails that are not frequently followed are prone to fade, items are not fully permanent, memory is transitory. Yet the speed of action, the intricacy of trails, the detail of mental pictures, is awe-inspiring beyond all else in nature.

Man cannot hope fully to duplicate this mental process artificially, but he certainly ought to be able to learn from it. In minor ways he may even improve, for his records have relative permanency. The first idea, however, to be drawn from the analogy concerns selection. Selection by association, rather than indexing, may yet be mechanized. One cannot hope thus to equal the speed and flexibility with which the mind follows an associative trail, but it should be possible to beat the mind decisively in regard to the permanence and clarity of the items resurrected from storage.

By now it’s already clear that he’s not talking about something that adapts well to the human mind, but that attempts to mimic it, or, rather, mimic a specific reductionist view of the process of recall that mixes up a mental process (association) with a physical one (‘some intricate web of trails carried by the cells in the brain’). Bush then builds on this idea of trails to propose a system. He moves on to describe his memex in some detail:

There is, of course, provision for consultation of the record by the usual scheme of indexing. If the user wishes to consult a certain book, he taps its code on the keyboard, and the title page of the book promptly appears before him, projected onto one of his viewing positions.


All this is conventional, except for the projection forward of present-day mechanisms and gadgetry. It affords an immediate step, however, to associative indexing, the basic idea of which is a provision whereby any item may be caused at will to select immediately and automatically another. This is the essential feature of the memex. The process of tying two items together is the important thing.

When the user is building a trail, he names it, inserts the name in his code book, and taps it out on his keyboard. Before him are the two items to be joined, projected onto adjacent viewing positions. At the bottom of each there are a number of blank code spaces, and a pointer is set to indicate one of these on each item. The user taps a single key, and the items are permanently joined. In each code space appears the code word. Out of view, but also in the code space, is inserted a set of dots for photocell viewing; and on each item these dots by their positions designate the index number of the other item.

Thereafter, at any time, when one of these items is in view, the other can be instantly recalled merely by tapping a button below the corresponding code space. Moreover, when numerous items have been thus joined together to form a trail, they can be reviewed in turn, rapidly or slowly, by deflecting a lever like that used for turning the pages of a book. It is exactly as though the physical items had been gathered together from widely separated sources and bound together to form a new book. It is more than this, for any item can be joined into numerous trails.


And his trails do not fade. Several years later, his talk with a friend turns to the queer ways in which a people resist innovations, even of vital interest. He has an example, in the fact that the outraged Europeans still failed to adopt the Turkish bow. In fact he has a trail on it. A touch brings up the code book. Tapping a few keys projects the head of the trail. A lever runs through it at will, stopping at interesting items, going off on side excursions. It is an interesting trail, pertinent to the discussion. So he sets a reproducer in action, photographs the whole trail out, and passes it to his friend for insertion in his own memex, there to be linked into the more general trail.

Considering that he wrote this in 1945 and that his entire system design was based on analog technology, it’s fascinating to imagine how foreign the idea of “linking” two documents must have sounded to his contemporaries, not to mention the notion that you could (in essence) copy and share a whole section of documents. He also describes a feature that we haven’t even achieved today: the ability to extract a section of a sequence of hyperlinked documents from our set and have it seamlessly join into someone else’s document collection.

Even as Bush starts with the idea of associative memory, he immediately turns to relying on indexes and code spaces and code words. Partially this is due to the boundaries of the technology in which he was operating, but even within them he could have suggested, for example, that the codes be imprinted automatically by the machine to associate the documents by time of access. The subtle requirements of machines on how we operated was present even for him. For example, earlier he discusses speech recognition:

“To make the record, we now push a pencil or tap a typewriter. Then comes the process of digestion and correction, followed by an intricate process of typesetting, printing, and distribution. To consider the first stage of the procedure, will the author of the future cease writing by hand or typewriter and talk directly to the record? He does so indirectly, by talking to a stenographer or a wax cylinder; but the elements are all present if he wishes to have his talk directly produce a typed record. All he needs to do is to take advantage of existing mechanisms and to alter his language.”

(Emphasis added)


“Our present languages are not especially adapted to this sort of mechanization, it is true. It is strange that the inventors of universal languages have not seized upon the idea of producing one which better fitted the technique for transmitting and recording speech. Mechanization may yet force the issue, especially in the scientific field; whereupon scientific jargon would become still less intelligible to the layman.”

Translation: we must change how we speak so the machine can understand us.

Technology has advanced, but we still try to adapt people to software rather than the other way around.  Often this is required to adapt to technological limitations, but it is also frequently done to provide a “better” way of doing things, or even out of sheer inertia.

In the meantime, we haven’t spent enough time trying to get fundamental platforms and technologies to adapt to people’s patterns. It’s time for that to change.

the ‘engagement’ trap

Continuing to connect the dots between some of what I’ve been writing about people vs users and map vs territory, today’s topic is “engagement” and its kin as stats that we often hear about or discuss, and, in my view, frequently misuse. I’ll discuss common problems that emerge as a result, and some alternatives.

mice cage engagement trapTo measure how an app or service is doing, we often set our sights on, say, “engagement.” Maybe this is carefully defined, maybe it’s not, either way the effects of reductionism are already present. People aren’t just clicks, or ‘time spent’. “Engagement” could result from enjoyment, but it can also result, as it often does, from cheap or underhanded manipulation of our baser instincts.

As I mentioned before, software agents are ‘users’ as well as far as software is concerned. This level of abstraction makes it easier to stop thinking of ‘users’ as people. Bots are also users, which only becomes a problem if someone chooses to care. Maybe mice could be users too. You can get them to click a button all day long any number of ways. The mice will be really “engaged.” The charts are going to look great… for the most part.


Abstractions are both useful and undeniably necessary. Overusing them, however, is dangerous. Using them incorrectly, without context, even more so.( This is along the lines of “The only thing worse than no documentation is bad documentation”). It’s something common, talking about “engagement” when what we’re talking about is getting people to spend as much time as possible and click on as many links as possible and post as many things as possible.

The example of using mice may sound like a cheap analogy, but I’m serious. I’m not focusing on whether triggering addictive behaviors is a good idea, or arguing about dopamine rushes or the like. That’s a worthy discussion to have, but I’m focusing on a different aspect.

Like a Turing test for sites, if you can manipulate your stats (in this case, “engagement”) by having small rodents perform a task in a box, then you are doing it wrong.

One example: you report that user ‘engagement,’ which you define as average number of full page loads per user per month, is 10. Great. But that could be achieved any number of ways: MySpace’s signup page was at one point a crazy number of pages, which was either the result of bad design/engineering or something done to artificially inflate its pageview numbers. So maybe the user signs up and in the process they have to load 10 pages. Then they never return. OR  maybe they sign up and  then return every 3 days and read a new page. “Engagement” is the same, but the second example shows a qualitatively different result. Oh, but that’s why we measure “user retention” and “return visits”! someone may say. All too frequently, though, these three metrics aren’t cross referenced which again makes them meaningless since the ‘users’ that dominate each area may be different sets. Averages are used without looking at the standard deviation, which makes also them close to meaningless. We separate users in ‘cohorts’ that are different across different stat sets. Since a ‘user’ is at best an account, while we have soft ways of extrapolating when multiple accounts are really one person, we don’t usually look at that. Bots are users too, unless they’re so well known or so high in traffic that you can’t get away with ignoring them.

But there’s more!

When you use an abstraction like “user” it’s also easier to go down the wrong path. Getting a “user” to “discover content” by inserting “targeted paid results” Is much better than to describe how you’re getting your grandmother to unwittingly click on a piece of advertising that looks much like the real content she wanted to look at but says “advertisement” in 5-point font. While you may or may not think (like I do) that this is morally wrong, my larger point is that it is the wrong thing to do for the business too.

You’re essentially depending on people not understanding what they’re doing, or being manipulated, and therefore, you’re kidding yourself. When you start thinking of motivation, you may also realize that as long as you don’t have the equivalent for your company of the card “As a CEO of Trinket software I want to keep shareholders happy by delivering X product with Y revenue and Z profits” you’re just kidding yourself. Making goals explicit, from the small and tactical to the large and strategic, is critical.

Even the best companies take years to refine how they analyze their business, massive amounts of work to patch together a set of abstractions that start to reflect what the business is really like.

What’s the alternative?

No credit for predicting rain,” is always present in my mind. Ben is talking about some specific situations, and he is not saying that  you always have to know the answer before you can ask the question or criticize/point out flaws. I have, however, adopted this mode of thinking when I’m going after something specific or whenever I’m questioning anything that has been longstanding. I always try to come up with alternatives, even I can’t lay out the alternative in detail right here, I can point in a direction. If I’m saying that X is wrong I generally try to have at least one alternative in mind.

So in this case, among other things, I’m calling bullshit on the vast majority of simple metrics used with abandon like “user engagement,” “time spent,” “user retention,” “churn.”  These measures require careful definition, proper parameters and boundaries, and  accurate correlation to high level goals. They require cross-referencing. They should always be labeled “handle with care: numbers in stats may be more meaningless than they appear.”

So, what, then, is a possible alternative? What is a better way? For example, while they may measure pageviews or time spent, what Amazon really cares about is sales of products. Typical metrics may be looked at in the service of that (e.g. we just did a release and avg pageviews are down with high standard deviation, did we screw up the release in some geographic region?). I’m sure that if they could retain the level of sales by serving a single page a day in some magical way, they’d take it.

In being able to clearly point at product sales Amazon is in the minority, but my argument is that every product and service has something equivalent, even if it is less tangible and harder to define, it can be defined and quantified in one or more ways.

If you are a communications app, you may want to know if people really ‘use’ your app. But you shouldn’t care about the number of messages sent. This invents causality where there is none. Just because a message was sent doesn’t mean it was read, it doesn’t mean it was, um, communication. Even if read and replied to, what qualifies are the type of “use” you envision? 5 messages per thread? 4? 100? Over what timeframe?

Is this harder to model and measure? You bet. But it’s necessary, and letting go of abstractions helps.

When you think of people and not users it’s easier to see why pageviews, clicks, “time spent” and many other types of metrics commonly discussed are pretty much smoke and mirrors. Most of us already know this, and we keep using them not because we think they’re great but because they’re readily accessible and our over-reliance of abstractions lets us get away with it.

Suppose the goal of your service is enabling group communication. You shouldn’t care about the number of messages sent, something frequently touted in press releases. This invents causality where there is none.

Regardless of number of messages, or pageviews, or clicks, or signups or any of this other stuff that is more readily measurable, what really matters is whether people are communicating or not, right?

So can say that, for this service, ‘engagement’ = ‘frequent group communication’. A definition of ‘person engagement’ (which would be different from ‘group engagement’) in this context could be a combination of a) frequency of participation in threads with a group of at least 2 other people (meaning, for example, correlated sequences of reply-response of at least 5 messages that involve at least 3 people including the originator) and b) frequency of thread generation, ie start a conversation that call out to others and then tapers off. If you’re looking for growth-related metrics you could look at things like frequency of invitation of others to join that then actually results in someone creating an account. This could be further enhanced by measuring whether the conversation more closely matches real communication patterns, like recurrent use of the names of the other people involved in the group, variance in vocabulary between participants, and many others.

Again, people not users: they don’t just “click” or “post”, they have intention, motivation. They may be showing off, they may be trying to share their happiness or grief. They may be just shallow and obsessed and repeating whatever they think is popular. They may be trying to help. And so on. And in their motivation and intent lies a key element that will either help the product or hurt it.

One person just blindly posts photos of celebrities, for two hours a day, and they have 5 “followers” and two “friends”. Another person has just two “friend” and no “followers” and sends just one joke everyday to the two friends, one of which is in the hospital and they exchange a couple of LULz and check in briefly. When you think of “users”, the first person could easily look “better” on paper than the other. But when you think of people, you realize that the second person and their friend are the ones that are really engaging in something meaningful enabled by your service. At least for me, the first case (which would rank higher in nearly any of the common metrics) would not be nearly as important and valuable as the second group. The second group will be more loyal, their interactions with the product more meaningful and lasting, and they will be better champions for your product.

These more meaningful metrics also enable us to focus on what matters. Do you want to help group 1 or group 2? They have different costs associated, and different growth dynamics. Common reductionist abstractions would either not give you enough information, or mislead you.

And that’s something we should all want to avoid. :)

affordances matter post #96482828

Great article: How The Ballpoint Pen Killed Cursive. Ok maybe the title tries to be a bit too flashy, given the topic — plus ballpoint pens aren’t murderers… I keep thinking that if cars were invented tomorrow we’d see headlines like “How Cars Killed The Horse,” or “The Death Of The Carriages: Gas vs. Grass.” Anyway.


[…M]y own writing morphed from Palmerian script into mostly print shortly after starting college. Like most gradual changes of habit, I can’t recall exactly why this happened, although I remember the change occurred at a time when I regularly had to copy down reams of notes for mathematics and engineering lectures.

During grade school I wrote largely using a fountain pen, but as I started high school I switched to ballpoint. Not sure why, but probably cost had something to do with it. By the middle of the first year I was writing mostly print. I didn’t even notice I was doing it our “literature” teacher started berating me, and then threatening to fail me if I didn’t write cursive. It should be noted that the following year when requesting books for the class to read she scoffed at my suggestion, The Lord of the Rings. “Some fantasy garbage,” she said. Everyone laughed and moved on. So, yeah, she wasn’t very enlightened.

The result of this pressure was that by the end my handwriting was a complete mess, a print-cursive hybrid that even I had trouble reading at times. Over time I switched over to more readable print, but by them I was doing most of my writing on keyboards anyway, and that was that.

Back then I wondered why I switched to print. My younger self decided that the reason was some form of underhanded rebellion at the backwardness of cursive (note: the nerd rebellion: That book was great, but I’ll write that book report any way I want to!). I remember thinking that writing print hurt but I was damned if I was going to relent.

At times in later years I would occasionally wonder about that switch form cursive to print, thinking that perhaps technical drawings (drafting — hand-drawn plans for engines, houses, and the like), math, physics, etc, had played a roled too. I hadn’t thought about this for years until the article this morning. Now I’ve got a much better explanation: It wasn’t writing in print that hurt; print was in fact the least uncomfortable writing style for the new device: the ballpoint pen. From the article:

Fountain pens want to connect letters. Ballpoint pens need to be convinced to write, need to be pushed into the paper rather than merely touch it. The No.2 pencils I used for math notes weren’t much of a break either, requiring pressure similar to that of a ballpoint pen.


[…] the type of pen grip taught in contemporary grade school is the same grip that’s been used for generations, long before everyone wrote with ballpoints. However, writing with ballpoints and other modern pens requires that they be placed at a greater, more upright angle to the paper—a position that’s generally uncomfortable with a traditional pen hold. Even before computer keyboards turned so many people into carpal-tunnel sufferers, the ballpoint pen was already straining hands and wrists

As usual, there’s more than one factor at play. Drafting requires print. Working with equations and their references contributed as well. And perhaps even rebellion. But the ballpoint’s affordances were surely a big factor, perhaps the determining factor. Affordances matter.

PS: yeah, I used a semicolon. Deal with it.

the territory is not the map (or, beyond the desert of the real)

. . . In that Empire, the Art of Cartography attained such Perfection that the map of a single Province occupied an entire City, and the map of the Empire, an entire Province. In time, these Excessive Maps did not satisfy and the Schools of Cartographers built a Map of the Empire, that was of the Size of the Empire, and which coincided point for point with it. Less Addicted to the Study of Cartography, the Following Generations understood that that dilated Map was Useless and not without Pitilessness they delivered it to the Inclemencies of the Sun and the Winters. In the Deserts of the West endure broken Ruins of the Map, inhabited by Animals and Beggars; in the whole country there is no other relic of the Disciplines of Geography.

Suárez Miranda: Viajes de varones prudentes, libro cuarto, cap. XLV, Lérida, 1658

— Jorge Luis Borges, On rigor in science (translated by myself, and here’s why )

Today abstraction is no longer that of the map, the double, the mirror, or the concept. Simulation is no longer that of a territory, a referential being, or a substance. It is the generation by models of a real without origin or reality: a hyperreal. The territory no longer precedes the map, nor does it survive it. It is nevertheless the map that precedes the territory — precession of simulacra — that engenders the territory, and if one must return to [Borges’] fable, today it is the territory whose shreds slowly rot across the extent of the map. It is the real, and not the map, whose vestiges persist here and there in the deserts that are no longer those of the Empire, but ours. The desert of the real itself.

— Jean Baudrillard, Simulacra and Simulations

(Translated by Sheila Faria Glaser)

The map is not the territory.

— Alfred Korzybski

Imagine we had invented airplanes and automobiles but no modern mapping or positioning systems. Without precise maps or GPS,  we could go very fast and very far, we could stumble onto wonderful places to visit, we would occasionally meet long lost friends. We would even be able to communicate at great speed by bringing documents and packages back and forth between a set of specific, well-known locations.

the territory is not the mapHowever, it would require enormous effort to make these experiences repeatable, consistent, and therefore reliably useful. Without appropriate navigational tools, pilots and drivers would have to rely on tedious record keeping and inefficient behaviors to describe a path — for example, keeping multiple copies of various partially accurate maps to stitch together something that may resemble a reasonable course to take, or using imprecise mechanisms to establish their positions. These pilots would often spend a lot of time on tasks that have nothing to do with traveling itself (like organizing all those maps), it would take them longer than necessary to reach even common destinations, and, perhaps frequently, they would get completely lost. This is perhaps not that different from what things were like, for example, for pre-Enlightenment European explorers. Every once in a while, the imprecision and unpredictability of incomplete information would pay off, as in someone “discovering” an unknown continent. But, most of the time, it was a fairly inefficient way to go about visiting our planet.

The Internet today is a vast, ever-expanding territory for which we have built great vehicles, but no modern maps. Instead, what we have is the equivalent of 15th century mapping technology to navigate in a world that lets us, and perhaps even requires we move at 21st century speed. We have no equivalent of GPS for the information landscape we inhabit. No accuracy. No context. All we have are scraps and notes we take along the way, feeble markings on dog-eared charts that become outdated almost as soon as they are created.

Furthermore, this analogy oversimplifies the problem in one important regard — the “vehicles” of the Internet not only travel the territory but also expand it. You can add information explicitly (e.g., post a photo) or create new information implicitly by simply navigating it (e.g. View counts on a video).

On the Internet, we quite literally create new roads as we walk.

The Internet as a “territory” is to some degree like that in Borges’ story: it creates the illusion that it and the map are one, that they are inextricably linked and interdependent, but they are not.

Modern systems and services are great at externally directed consumption. The digital mechanisms we use to navigate our present, the now, are increasingly sophisticated about putting new information in front of us.

But in almost every context, self-directed navigation through the vast ocean of data that we increasingly live in has become more difficult, and when we attempt to combine this with purpose and need for specific information (an article that we heard about, a document we created long ago, etc.) the task becomes even more difficult. Some of us are constantly trying out new organizational techniques for our folders, bookmarks, documents; most of us just make do with what we have.

Notifications are used across devices and software to trigger actions from us constantly, but in many cases their intent is not to aid or inform — not because they are necessary or useful, but because the product or service in question wants to accelerate growth, increase “engagement”, or increase revenue.

In response, operating systems started to include a “Do Not Disturb” feature that can be activated manually or automatically at certain times (e.g. at night). This is a useful feature, but the question we should ask ourselves is: Why it is so necessary? It isn’t just the number of services or apps that counts here. It is also that these apps and services lack or ignore simple elements that should be at the forefront in a world in which we are awash in devices and sensors. Awareness of context and time, along with adaptation to the circumstances of the person using the software are not common design parameters in our software and services. In the few cases when they are considered they are not given as much importance as they deserve, or they are implicitly sidestepped in the service of revenue or growth or some other internal metric. This is not a bad thing in and of itself, but it should be an explicit decision (even explicit to people using the product) and it rarely is.

Modern systems also require relatively precise inputs to work efficiently and correctly. Take “Searching” for example: before we can search for something, we have to know not only what we’re searching for but the specific technique for how to find it. To begin with, ‘search’ has by now largely become synonym with ‘keyword search.’ Any amount of disorganized, decontextualized information can, apparently, be managed effectively by typing a few words into a rectangular, two-dimensional box.

And there’s no doubt that if you understand the metaphors and abstractions involved, search as it exists today can be both an efficient and powerful tool. But, if you don’t, it can actually be counterproductive. Google is a spectacular achievement of a scope that is hard to overstate (even if rarely acknowledged) and a wonderful tool, but there can be a vast difference between someone who knows how to use it and someone who doesn’t, not unlike a person asked to find a particular book within the Library of Congress when they don’t have a clear understanding of how their filing system works.

“Search,” in general, presumes that what you’re looking for is differentiated enough to be separated from everything else by using words, or, even more explicitly, a sequence of unicode characters.

Consider that for a moment.

Even in the specific case of keyword search, words as they exist for us, in our heads, in speech, in writing, have context, nuance, pronunciation, subtlety. All of that is lost when we have to reduce what we are thinking to pure symbols, to just type—and having a remote system work based not on what we mean, but what it thinks we mean.

Search as it exists today is a tool designed primarily to find one element that shares one or two characteristics (typically keywords) with many others but has some fundamental difference that we can express symbolically. However, what we need is, more often than not, to be able to create or resurface connections across personal knowledge strands, the ability to find a specific item among many that are alike when we can’t define precisely what sets them apart.

If search engines aim for finding a needle in a haystack what we often need is more like  looking for a particular grain of sand on a beach. When “searching” for something that we’ve seen it is more frequent to recall the context rather than the detail. “That website we looked at in the meeting last week” is a more frequent starting point than one or two keywords from the website in question. 

In other words, this is not merely an issue of expertise or experience using the product, it is a fundamental problem rooted in the lack of subjective contextual information: subjective to the person using it, subjective to their situation, their place, who they are, the time it is, what they’ve seen in the past, the subtle and unique features of the landscape of their experience and knowledge.

Evoking, on the other hand, is something that people excel at: correlating, incrementally building up thin strands of information into coherent threads that allow us to pull from them and bring what we’re looking for into view.

We’ve become mesmerized with the territory and forgotten the map — for example, when the structure of websites rather than that of the information in question determines indexing and results. Or: a message with to, from and cc is not the pinnacle of expression of small group interpersonal communication dynamics but we can see clearly that so far we have failed evolve it in meaningful ways.

If we are to move past the current mire of software that remains stubbornly stuck in systems, modes of operation, protocols and interfaces created decades ago, if we are going to manage to break from interfaces that are barely one step removed from their paper-based counterparts, we will need software that doesn’t rely so deeply on how information is created, manipulated and stored. We are people, not users.

We connect — time, place, related ideas, half-remembered thoughts, sensory information, even feelings, all take part in the process of recall.

Software that in some sense “understands” and can help or even guide us through that process is what we should aim for, and figure out how to build. Software that adapts to us, instead of the other way around.


people, not users!

How we relate to things is dictated by how we think about them, which is strongly influenced by how we communicate about them… and the words we use for that purpose. Terminology matters beyond mere semantics. How we think about how our products are used, and the people who will be using our products, shapes what we build. I don’t care how obvious this may be, it’s still useful to say it, to be mindful of it.

We are people, not users.

When we “use a car” we think of ourselves as a person who drives, not “the user of a car”. You drive. The act of driving is not intrinsic to you, it’s temporary, just something you’re doing. When you use a pen, you are writing, when you use a brush you are painting. So what are we “users” of software and services (and all things that make up the Internetdoing? And what does “user” mean, anyway?

Let’s look at the dictionary definition of ‘user’:

user |ˈyo͞ozər| noun

1 a person who uses or operates something, especially a computer or other machine.

• a person who takes illegal drugs; a drug user: the drug causes long-term brain damage in users | a heroin user.

• a person who manipulates others for personal gain: he was a gifted user of other people.

So according to this, if you’re a user you might be using a computer ‘or other machine’, a drug addict, or possibly a sociopath.


We can’t erase the other (pre-existing) interpretations of “user” from our heads, so just on this basis ‘user’ is not a great term. But let’s set that aside anyway and put things in context. Where did this specific use (ahem) of the word come from? How did it come to be used in computing? For those who don’t know what “Multics” means, The Jargon File –and if you don’t know what that is, wikipedia, as always, can help— sheds some light:

user: n.

1. Someone doing ‘real work’ with the computer, using it as a means rather than an end. Someone who pays to use a computer. See real user.

2. A programmer who will believe anything you tell him. One who asks silly questions. [GLS observes: This is slightly unfair. It is true that users ask questions (of necessity). Sometimes they are thoughtful or deep. Very often they are annoying or downright stupid, apparently because the user failed to think for two seconds or look in the documentation before bothering the maintainer.] See luser.

3. Someone who uses a program from the outside, however skillfully, without getting into the internals of the program. One who reports bugs instead of just going ahead and fixing them.

The general theory behind this term is that there are two classes of people who work with a program: there are implementors (hackers) and lusers. The users are looked down on by hackers to some extent because they don’t understand the full ramifications of the system in all its glory. (The few users who do are known as real winners.) The term is a relative one: a skilled hacker may be a user with respect to some program he himself does not hack. A LISP hacker might be one who maintains LISP or one who uses LISP (but with the skill of a hacker). A LISP user is one who uses LISP, whether skillfully or not. Thus there is some overlap between the two terms; the subtle distinctions must be resolved by context.

Early computers were large, expensive systems that needed “administrators” and naturally people who could “use” but not “administer”.

“User” did not originally indicate a person. In a networked environment, at the network management level it may, for example, make sense to label a computer as a “user of the network”. In fact, UNIX considers any actor in the system, whether human or synthetic, to have a user (and a group) attached to it as a way of indicating access privileges to different functions or services. The “user” in UNIX is really a property that can be attached to things to indicate permissions and other relevant information (for example, a user will typically have a password, used for authentication, a home directory, etc).

Over time “the person named Joe Smith has a user in the system” turned into “Joe Smith is a user in the system.” We started to mix the concept of a user being a virtual entity controlled by a person with a way to refer to the person themselves.

This use of terminology migrated from terminal-based systems (UNIX, et al) to desktop computers and beyond. An iPad, for example, has no need to distinguish between a user and an administrator. We are, in effect, “administrators” of our iPads, but we still call ourselves “users.” Incidentally, that’s what anyone building software for it calls us, and themselves, as well.

This is one of the reasons why so much of the software we use everyday feels impersonal: it was built for a “user”, a faceless entity that may or may not be human. If you happen to build software and disagree, I challenge you to visualize what comes to your mind when you think of the “user” of your software. For most of us it’s not a person, no face, no arms: a shapeless blob of requirements that, somehow, can manage clicks and taps and keypresses. It will take a concerted effort on your part to picture an actual human doing something specific with your software. And it should be the other way around.

So, why is this a problem?

We are more than what we use, and because we have purpose we are doing more than just using.

Homer is baffled when he can't find the 'Any' key.

Homer is baffled when he can’t find the ‘Any’ key.

The effects of ignoring this simple truth seep in at all levels of language and thought, and ultimately define and constrain what we build. We think of “the user” of software. The user of piece of software. Who’s unique in that sentence?

In general, we talk about what a person does, we describe their actions, we don’t define the person as a generic, interchangeable element while giving the privilege of specificity to the tool. Except in software.

In software, the designer of a word processor would generally refer to the person using their software as “the word processor user.” (let’s ignore, for the moment, the insanity of calling a tool for writing a “word processor.”)

Someone designing a hammer would not call the intended audience for their product “hammer users.”

They would give them purpose and a name. Carpenter, Sculptor, and so on, and in doing so they would be defining a context in which they intend their tool to be used, context which would then aid in making the design better adapted to its intended task.

The designer of a pen would think of a person using the pennot a “pen user”. A “user” uses the pen to let ink flow from the pen to the paper, permanently marking it in a way that may or may not make any sense. A person who writes has a purpose: a memo, a letter, a book. In that purpose you also discover design constraints. A pen used for calligraphy is different than a pen for everyday use, which is different than a pen used at high altitude, or in space, or for drawing.

Beyond “purpose” there’s something else that a person has that is frequently ignored by software: a life.

Just thinking of “the user experience” is not enough. A lot of software, and certainly the vast majority of dominant software and services, appears to rely on the Donald Trump principle of design: it screams ME, ME, ME. You want to shut down your computer? You can’t: your “word processor” demands that you make a decision about saving or not that file you were editing. Are you highly stressed while driving your car because you’re late to a job interview? Deal with it: your preferred social network wants you to check out the photo of a friend having lunch while on vacation, while you’re also being told that there’s a great offer on coat hangers at a nearby mall, and your calendar is alerting you that you have lunch with a friend soon, even though it’s set for 6 pm and the appointment was mistakenly set for the wrong time, then duplicated for the right time, leaving the old one intact. And who has lunch at 6 pm anyway?

How one would fix this problem is a good question. The answers will be heavily dependent on context. My point is that it’s a question we’re not asking as frequently as we should, if at all. And calling people ‘users’ gives us a pass on that.

Profile photos or friends are used frequently to lend an air of ‘humanity’ or ‘personalization,’ but strip that away and it’s the same content, the same links, the same design, the same choices. Conveniently, it also creates a barrier, and in the process defines a type of human-machine dialogue that puts the weight of decisions and results on “the user” while software absconds, claiming nothing is its responsibility.

We can do better than that.

For a while now I’ve been avoiding the term ‘user’ in everything I write, be it code or prose. It’s hard. And it’s completely worth it.

We are people, not users, and what we build, how we build it, and why we build it should reflect that.

PS: There’s other aspects to this that I’ll expand on in future posts.

PPS: One of those topics is, specifically, how the more recent software development practice of creating “user stories” fits into (and affects) this practice is a topic for a future post. Spoiler alert: it’s not enough. :)

software you can’t make fun of

factsandfictionsWe dream of Minority Report; what we have is The Drudge Report. Many of us would happily embrace the moral hazards of pre-crime enforcement—if we could only have some of the supercool holographic, seamless information technology manipulation we see in the movie.

Art is a powerful lens through which we can examine culture and society. Artistic expression is also a conduit through which we relate to each other and try to make sense of what’s happening around us. When it comes to technology, popular artistic expressions of it are interesting for two main reasons.

First, art reflects reality as widely perceived for a particular age. It acts as a mirror, and while it doesn’t represent objective reality, it can be a valid measure of how how we really see ourselves. When we see Homer Simpson struggle to use a computer, we can laugh at it because he is an oaf, but we can also relate to what he is going through, because we experience it everyday.

Second, art can also express our collective fears, desires and aspirations. For example, The Terminator falls squarely in the “fear” category (and what better way to represent fear of technology that than through a monomaniacal unstoppable killing machine with a heavy Austrian accent?) while Iron Man, at least in part, is more aspirational, a non-cynical view of Vorsprung durch Technik.

So what do popular representations of information technology in art tell us, not about what the tech industry thinks it is, but how people perceive it, how we relate to it, whether it’s doing what we want or not?

Asking this question leads to some uncomfortable answers. It is striking how art, and in particular popular art —TV, movies, bestselling books— is in almost universal agreement: in their current form software, hardware, the Internet and information technologies are (apparently) good for humor, but not much else.

The flip-side is that when information technologies have to be used for a “serious” purpose (say, by detectives trying to solve a crime, doctors trying to save a life, spies chasing terrorists), without cynicism but matter-of-factly as part of the world, they rarely if ever look like what actually exists. Not only that, they are qualitatively different than what is available today.

It’s not just in the context of science fiction: whether in contemporaneous or futuristic settings, when information technologies are involved, nothing looks or, more importantly, behaves like what’s available in our everyday reality.

Here’s a short clip with some of my favorite examples:

Think about it beyond the examples in the video. On TV, on books, on movies, and not just for comedy. If you see a “realistic” depiction of the technologies we have, it is almost invariably in the context of humor or, at best, a cynical point of view. This is not a case of confirmation bias. Examples of use of information technology in realistic settings are few and far between, and most of those are for highly specialized areas, like computer experts.

Even in those cases, it’s still notable when it happens. The new USA Show Mr. Robot (btw, watch this show, it’s awesome!) has actually gotten attention specifically because it stays true to reality.

Consider what you are exposed to everyday while using your computer or the Internet. The challenges involved in actually getting your work done (e.g., struggling to find the right information, reading through nearly incomprehensible email threads) or just everyday communication or entertainment (being bombarded with advertising, posting what you had for dinner, commenting on traffic). Now try to recall examples of media depictions of those activities in which they are just a matter of everyday life and not used as a comic foil, for humor, or acerbic/cynical commentary.

There aren’t many. We are spending significant portions of our lives in front of screens, and yet a straightforward, realistic depiction of this reality seems to automatically become a joke. Even non-fictional accounts of events tend to avoid the subject altogether.

The appearance of other technologies also involved humor, fear, cynicism, but there was also a good share of positive depictions and, more importantly, reflections of reality as reality without turning it into a punchline. Phones, for example, could be used for jokes (perhaps, most effectively, by Seinfeld) but also as an “everyday” communication mechanism. Cars, rockets, biotechnology, advanced medicine, modern industry, media itself, all have been depicted for good, for bad, but also as a staple of life.

It’s valid to consider that, perhaps, there’s something intrinsic in information technology that resists use in artistic representations, but that’s not the case.

In fact, art and popular media are awash in representations of information technologies used for purposes other than humor.

It’s just that those representations are completely removed from reality—drastically divergent from what we actually use today.

Many of these clips are for stories set in the future, but one would be hard pressed to trace a path between, say, the Mac Finder or Internet Explorer and the systems depicted. After all the main element that separates “futuristic” interfaces from those placed in alternate versions of the present like in James Bond movies is the common appearance of 3D holographic interactive displays. Even more: movies like the Iron Man series or TV Shows like Agents of S.H.I.E.L.D. all manage to skip the part where it’s all in the future and place those interfaces and interaction mechanisms into the fictional “present” they depict.

Computers that don’t get in the way seems to be more  part of the ‘Fiction’ than the ‘Science’ in Science Fiction.

Apparently, to have your computer help you, without interrupting, and without getting in the way, seems like a fantastical notion. To enjoy entertainment without glitches or being flooded with inane commentary seems preposterous.

Literary representations of technology, even in dystopian contexts, also tend to prefer non-linear extrapolation. William Gibson’s description of Cyberspace is a good example:

“Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts… A graphic representation of data abstracted from banks of every computer in the human system. Unthinkable complexity. Lines of light ranged in the nonspace of the mind, clusters and constellations of data. Like city lights, receding…”

— William Gibson, Neuromancer

What is significant is that even though these representations of information technology are unrealistic, we still connect with them. They don’t strike us as nonsensical. They just seem far-fetched, particularly as we return to the reality of pages that never load, files that can’t be found, viruses, spam attacks, and a flood of data we can’t digest into anything sensible.

If these depictions represent something worth aspiring to, we need to start moving along that path instead of burrowing deeper into the hole we find ourselves in: we need software you can’t make fun of.

At least, not as easily as it is today. :-)


Get every new post delivered to your Inbox.

Join 386 other followers

%d bloggers like this: