New Ways of Looking at What We Know [Hidden Dragon BizBlog 1.2]
There is a discussion going on about the future of Personal Knowledge Management (PKM) that was started by Eric Mack, and carried on by Michael Sampson and Pascal Venier. The good stuff, as often is the case, is in the comments. As a relative newcomer to the discussion, I am fascinated by the direction Eric is looking: what does GTD address fully? and what needs more attention?
The trail of breadcrumbs
I also found a link to this blog, Slaw, with a post on information overload. This point in particular caught my eye:
Design: The design of online information can greatly affect information retrieval. Information that is well-designed will reduce the stress that sometimes accompanies the information-gathering process. Studies have shown that data that is visualized, compressed and properly aggregated is much easier to process (see R.L. Ackoff, “Management Misinformation Systems” (1967) 14 Management Science 147 and J. Meyer, “Information Overload in Marketing Management” (1998) 16 Marketing Intelligence and Planning 200).
I have been thinking a great deal about this topic (designing for information retrieval) since I started beta-testing my new calendar and organizer project. I have also started using TiddlyWiki for archiving digital information and managing my projects. But my mind keeps going back to this demo of SeaDragon that I saw last month, and the implications for text documents and context-searching in general.
Do we need to design a GTD 2.0?
If there is a need for the “next generation” of GTD, Eric is asking one of the right questions with “what should it look like?” Indeed, the look of the system is going to become more and more important to its successful execution. By “look of the system” I mean several things:
- The ability to communicate the workflow graphically;
- the ability to portray and interpret a graphical (or physical) representation of the current status;
- and the ability to visually navigate the tags, bookmarks, contexts, and archives.
Bret Victor has an amazing paper on design for information management at his website WorryDream:
Information software design can be seen as the design of context-sensitive information graphics. I demonstrate the crucial role of information graphic design, and present three approaches to context-sensitivity, of which interactivity is the last resort. After discussing the cultural changes necessary for these design ideas to take root, I address their implementation. I outline a tool which may allow designers to create data-dependent graphics with no engineering assistance, and also outline a platform which may allow an unprecedented level of implicit context-sharing between independent programs. I conclude by asserting that the principles of information software design will become critical as technology improves.
Although this paper presents a number of concrete design and engineering ideas, the larger intent is to introduce a “unified theory†of information software design, and provide inspiration and direction for progressive designers who suspect that the world of software isn’t as flat as they’ve been told.
Is there a new way to present information?
The concepts that Victor furthers in this paper are powerful insights into the future of information presentation. The entire paper is worth reading (and saving and re-reading) for the problem-solving examples and the innovative concepts for programming.
Quoting from Victor again:
Today’s ubiquitous GUI has its roots in Doug Engelbart’s groundshattering research in the mid-’60s. The concepts he invented were further developed at Xerox PARC in the ’70s, and successfully commercialized in the Apple Macintosh in the early ’80s, whereupon they essentially froze. Twenty years later, despite thousand-fold improvements along every technological dimension, the concepts behind today’s interfaces are almost identical to those in the initial Mac. Similar stories abound. For example, a telephone that could be “dialed†with a string of digits was the hot new thing ninety years ago. Today, the “phone number†is ubiquitous and entrenched, despite countless revolutions in underlying technology. Culture changes much more slowly than technological capability.*
The note has the specific examples of how a new vision of GTD will need to transcend an entrenched culture of how we presently use our tools:
* Other obsolete but entrenched designs: the QWERTY key layout (intentionally sub-optimal to reduce typewriter jams), the von Neumann architecture (see John Backus, Can Programming Be Liberated from the von Neumann Style?, 1978); C and UNIX (see Richard Gabriel, The Rise of “Worse is Betterâ€, 1991).
The future of information is in the context
The unified theory of software design, making the tools and process invisible, is Victor’s vision of the future. I fully agree that this future is going to be context-sensitive, if not context-driven, and that there will be a convergence of the tools that we use for storing and retrieving information.
The context of what we are doing right now is central to the GTD paradigm, and I submit that having information related to that particular context at our fingertips will be where the next set of improvements originate.
Interaction is the bottleneck
Maintaining and managing your workflow at a level of stress-free productivity is the goal of Getting Things Done. Frequently one encounters roadblocks to productivity, one of which is the information bottleneck that exists where the User interacts with the System. Whether it takes place at the in-box, the capture notebook, or the Next Action list, this choke-point must be overcome on order for the workflow system to operate independently and invisibly. The design goal, therefore, of a GTD 2.0 should be to incorporate new tools (or, old tools used in a new way) for the automatic contextualization of information. This context can then be tagged or bookmarked (or identified in a new way?)Â as it is coming into the system for intuitive, or even automatic, retrieval at a later time.
I would appreciate seeing your thoughts in the Comments.
Original post here: Stephen
Comments: