Recent Articles
Monday
15Feb2010

Save, an historical oddity

Last year, I was teaching a group of 10-15 year olds about the history of computing. The kids were pretty familiar with the technology, mostly knowing what CPU and memory and storage are. What really amazed me, though, was the universally-blank expressions on their faces when I mentioned “floppy disks”. These kids were all born (1994-1998) right at the time when floppy disks became extinct. As a result, they had not a clue what they were. Unless you directly step in to educate the next generation, knowledge can be lost between generations pretty quickly. 

The save button will be one such historical quirk.

By the time my group of teenagers manage to raise their offspring to teenagehood, *they* will have to explicitly teach their children about the “bad old days” when documents needed human action in order to save. They will tell heroic stories about redoing work due to blackouts or pulled power cords. And their children will sit there dumb-founded: “Computers used to lose information?”

 

It was only ever a performance hack that caused software developers to require users understand the difference between volatile and non-volatile memory. Other than image and video editing apps, it’s not technical limitation that causes the perpetuation of the save button; rather, it’s cultural inertia of software developers that preserves the save button. After all, Apple’s iPhone and iPad devices already hide the difference between RAM and flash; developers of productivity applications will soon borrow the concept. There’s sufficient computing resources to do this right now, for most apps.

The manual save mechanism on desktop apps will not outlast the generation of programmers who, as children, grew up using iPhones and iPads.

 

When you implement continuous, automatic autosave, you also have to provide a generous undo mechanism. After all, people still make mistakes; or explicitly rely on these mechanisms to experiment.

The session-specific undo mechanism will soon give way to persistent undo mechanisms. Applications will begin to universally implement journalling and automatic versioning to support persistent undo. They will enable the exploration of multiple time-points in the versioning history using multiple representations, transition effects and graphical slide-based timeline metaphors. (Think of app-specific Time Machine functionality.)

Furthermore, in addition to a purely linear undo mechanism, developers will analyse the independence of objects within their programs, using it to implement object-specific undo and version exploration mechanisms. So in a text editor, I’ll be able to select a paragraph and have it show me the half-dozen major variations over the last n minutes/hours/days, regardless of when I edited that paragraph.

Now, providing these features introduces a certain complexity to programming. You might ask how this fits with my assertion that programming productivity will only increase relatively slowly. These mechanisms will be provided by a combination of patterns, frameworks and the use of appropriate database technology. (Ironically, today’s database technology is frequently the reason database-centric apps frequently fail to implement undo.) In the future, the persistent store will provide the framework for journalling and versioning, for both single-user and multi-user environments.

Having these mechanisms on hand will enable independent developers to inexpensively include these “advanced features” in their apps way, way before we even get close to the Hundred Year UI.

Source: To my knowledge, Petter Hesselberg’s Programming Industrial Strength Windows first proposed getting rid of the save mechanism. He also makes a strong argument for changing Save As into Archive, whereby the newly-named archived copy is the *other* document (not the current one), reversing the conventional behavior of Save As and, in so doing, providing much better UX.

Monday
15Feb2010

Searching for the Hundred Year UI

Of the many thought-provoking essays written by Paul Graham, his Hundred Year Language thought experiment has always struck me as fascinating. Unlike Graham’s conclusion—in which he concludes that a language described in 1958 would provide the basis for the Hundred Year Language—I think user interface design provides a wide scope for invention and reinvention.

What’s inspirational about Graham’s challenge, is his notion that perhaps by looking out a hundred years, we can begin adopting approaches that will prove to be fruitful in moving us toward the hundred year mark right now. 

How could we possibly see a hundred years out?

It’s important to remember that the GUI is 30+ years old. The visionaries who foresaw our present—Vannevar Bush, Douglas Englebart, Ted Nelson, Alan Kay—needed a view that stretched 40 to 50 years in advance of the state of art. If they could see to the 40 or 50 year horizon, why shouldn’t we, equipped with additional information drawn from the history of computing, aim to shoot for a hundred? By combining our historical understanding with a creative vision, why shouldn’t our vision reach ahead that far?

Principles in our search

I would like to propose some principles that should stand us in good stead.

  1. Human cognition will change only gradually over the next hundred years.  Jakob Nielsen reports that conclusions from interaction research performed twenty and thirty years ago are still valid. There’s no reason to believe these results will change (much, if at all) over the next hundred years.
  2. Culture may change significantly. Any study of modern history demonstrates the significant cultural changes that can occur over the course of a hundred years. Whether that is due to economic, industrial, technological, political or philosophical causes, cultural attitudes and outlooks can change substantially.
  3. Technology development will continue unabated. Unless our economic system is systemically interrupted by drastic events (think: peak oil), technological development will increase the capabilities of our machinery to virtually unimaginable levels. (Paul Graham’s thought is that the lower bound of computational performance over the next hundred years is a million times faster. Now, he might be able to imagine that, but I’d consider the experience of a million-times faster computer to be virtually unimaginable. Let us try, though.)
  4. Programming will still be hard. Fred Brooks won’t be disproven in the next hundred years: there will still be no silver bullet. Programming is an unnatural act—asking humans to be purely logical when we are designed for emotional response—and the rate of progress in programming productivity won’t be any greater than that demonstrated by the last thirty years.

 

As we progress on this search, we may very well decide that there are other principles we can treat as axiomatic. When we do, it will mightily assist our capacity to envision the future.

Now let’s get creative! How about joining me in envisaging what our UIs may be like in a hundred years?

Sunday
14Feb2010

Tweeting tip

Tip for heavy tweeters—Actually read what you retweet.

Twitter conversation, apparently showing someone who didn’t read or understand what he retweeted.

Sunday
14Feb2010

Weirdness

So I’m linked to the WSJ from a tweet. When I get there, the WSJ lets me read one and a bit paragraphs, telling me I need a subscription to see the rest.

But that first paragraph gives me enough info to flip open a new tab and launch a raid via Google. Google returns me a link to the article, which I click on, and the WSJ now shows me the entire article.

Just who does this help?

Sunday
14Feb2010

What to do about information scarcity

On July 31, 2009, the Basex blog finally ticked me off. I unsubscribed. Their crime? Harping on, and on, and on about information overload.

Basex invented the term.

Basex sponsor annual studies.

“Information overload continues to increase.”

“Information Overload is never far from our thoughts here at Basex but, with the cost of the problem looming at some $900 billion per annum…”

Blather, blather.

Look, I’m a busy manager, responsible for developing and operating an online service. I regularly process around 100 incoming email per day, send around 50, subscribe to 83 blogs, read 2 websites daily, follow 406 people on Twitter, are Friends with 55 people on Facebook, have 77 connections and 4 group memberships on LinkedIn, and I’m not suffering from information overload. Surely if it were a real problem, I’d be suffering some form of breakdown.

And yet I find myself seeking even more information. Based on a quick perusal of my last month’s search activity on Google, I average around 8 searches per day, opening an average of three to four pages per search. So, in contrast to suffering information overload, I’m actively seeking more information.

Sampling the concept of information overload

In preparing to write this post, I scanned the last 300 posts on Twitter about “information overload,” roughly corresponding to tweets over the last 24 hours. What are people saying?

  • Quite a few declare their own information overload.
  • I found a link to the Information Overload Research Group.
  • Quite a few people quote Clay Shirky’s pithy phrase: “It’s not information overload, it’s filter failure.”
  • A number of people point to David Allen’s article The Problem is not information overload, which argues that purported information overload is really a decision problem (Allen uses the term: “meaning assignment”).
  • Engaged Learning write a post that expands on Shirky’s filtering theme: “So instead of throwing our hands in the air and saying we suffer from information overload, we must learn to dynamically adjust our filters and focus.”
  • Steve Mollman wrote a piece entitled How can we cope with information overload? It contextualises the problem, quotes Clay Shirky, but turns out to shill for a predictive filtering iPhone app called My6Sense.
  • Blueprint 2020 attempts to provide six steps to “avoid” information overload.
  • BNET Australia attempts to attract flow with the provocative title, Which Is Worse for Your Brain: Texting or Pot? But it betrays its heading’s promise by not only not discussing comparative mental states; worse, failing to mention pot even once in its article; yet even worse, turns into one of those completely disconnected, disjointed ten-point advice columns. Mercifully, it stops short of ten, offering only five points. 
  • Finally, I found my way to Steven Sagmeister’s TED address, The power of time off.

So, two years after the seminal assertion, “It’s not information overload, it’s filter failure”, and four years after the initial publication of David Allen’s, “The Problem is not information overload”, the information overload meme is still buzzing.

Defining information

Departing from both folk understanding and information theoretic definitions, Eli Goldratt defines “information” as “the answer to an asked question.” 

“Everything else,” declares Goldratt, “is simply data.” The implication is that much of the “information” consumed each day is not, actually, information—but is, in fact, data. This data becomes information only when it begins to answer questions that you have asked.

The challenge then, is to ask questions. To ask better questions. To ask relevant, actionable, significant questions. To create a personal sense of what is important. In other words, to create a personal filter.

The more profound the question, the more significant the answer.

Data, entertainment, serendipity and information

In any given moment, the vast majority of digitally-available extant text is simply data. It answers questions I don’t ask, don’t care about, won’t read.

Much of the information delivered via blogs and virtually all information from news media is simply entertainment. (See Dave Pollard’s perspective that news media is unactionable; and therefore entertainment.) I let this stuff wash over me because I enjoy reading it. I enjoy being entertained. It’s not just data—I find it interesting. But it’s also not information, because it is irrelevant to my work, my family, my life.

There are times when an article, a post, an essay, a video delivers something unexpected. A point of view with the potential to update my personal filter. Something that causes me to ask new questions, to learn that something else is actually important to my world-view. This is serendipity.

Finally, there is information. Satisfying answers to questions asked.

Data, entertainment, serendipity and information forms a filter of ascending value.

The real problem

When viewing media consumption through this filter, the real problem becomes apparent. Despite the massive volume of data potentially available, the significant amount of data being attended to, the amount of entertainment and the occasional encounter with serendipity: the real problem is the continuing scarcity of truly significant information

Really important information is still scarce. Richard Hamming had it right: We need to ask questions that matter.