This decade has seen a tectonic shift in technology: the new information applications which are succeeding are those in which information is based on simple topics; the new document major document formats are those which allow the packaging of a topic.
The organization of information in to simple interlinked topics, typically something that can be described in a single phrase, is the common factor between such seeming disparate but succeeding technologies as the web-based Wikipedia, Amazon, Google, Ebay, Flickr, MySpace, YouTube, blogs, RSS, but also has had strong impact in non-WWW areas: the ITIL Configuration Item, the SCORM Learning Object, the S1000D Descriptive Module, integrated UML systems, for example.
The difference from the WWW in general is that though web technologies indeed encourage small pages, their is no necessity that pages are about one topic in particular. So the WWW is an excellent basis for implementing topic-based systems, but not itself one. Similarly, RDF may allow resources to be linked, but these are not necessarily at the level of topics. Another way of looking at topics is that a lack of topicality is what makes an poor index item poor.
There has been a decade long process at ISO SC34 to make and develop a series of standards based on topics, for example the Topic Map standard, IS 13250. This is good technology (like Xlink and RDF) to look at when considering how to implement a topic-based system.
The rise of Topics represents a great challenge to operating system and desktop suite vendors. When we look at Windows, or Mac or Linux window managers, we see that they really interact with the user at the wrong level. They say that the topic the user is interested in is applications and files. But how many people nowadays start their computer interaction with a web browser pointed to Google? There are still people whose organizing topic of interest in their computer interaction is the file or application, of course, but they have been swamped by people who are interested in the topic.
There are interfaces which organizes the user with different topics: most notably the Sugar interface of the One Laptop Per Child ($100 computers) in which the primary metaphors are the person (and their private activities and journal), the neighborhood, and the group (and group activities and bulletin board.) The interaction topics are “people, places, objects, actions”. But as with the desktop, these are not topics in general, just the topics of one domain (a fairly compelling domain, that of children and communities).
Indeed, we can see the large successful web applications as being topic-based interfaces each for particular domains and scopes. A lot of the Web 2.0 or Social Interface systems talk focuses on the human or social or write-able web aspects; my question is this: should we think of Topics as the “how” and the social aspect as the “why”, or should we think of the Topics the “why” and the social aspects as the “how”?
Moreover, should Linux, Windows, Mac and all seriously respond to the rise of Topical Interfaces by ditching the desktop metaphor? I tend to think yes: in terms of my supprt/runner/plug-in model topic interfaces belong at the “suite” level, and a desktop interface is just another suite.
One reason I found (and still do find) the Windows desktop so cumbersome to use compared to the a UNIX shell or the old Mac desktop was that it never seemed to provide me with the topics I was interested in. When the topic was “Installed programs” it lets me look at a menu from the start button, but not all programs are there; I have to switch to a completely different system, the file explorer, and look in Program Files and figure out from the files and directories what applications are there. We have to fight with the army we have, not the army we want, but we won’t win unless we have the army we need.
Topical Interfaces have eclipsed the Desktop Interface and are severely challenging the central position of the file., because increasingly the value of some information is in its linked-in-ness to some larger system. From this point of view, the recent trend (JAR, WAR, EAR, ODF, Open XML, SCORM, etc) to use ZIP and therefore package together all the files needed for one application session can be seen as an attempt to turn documents themselves in to a container for a bounded topic. OOXML’s Open Packaging Convention (OPC) represents the high-point (though not the state of the art, for which see RDF and ISO Topic Maps) in this trend, adding a linking and typing mechanism (relationships) within the ZIP package, However, the moves to make a platform out of the office suite and out of the Web browser (and the various Java Rich Client Platforms such as Eclipse, NetBeans, and so on) fall short of providing the integrated, topic-based interfaces.
The two worlds need to converge: we need Topical Interfaces which lets us navigate between and within topics and perform transactions, but which also allow each Topic can be bundled and shipped around as a document.
Over the last few months, in the office where I work, I have seen an amazing development effort that already is producing benefits, where a collaborative annotation system (PageSeeder) has been used to build a topic-based software engineering system that uses topics to tie all parts of a software job together:
- along ITIL lines, the basic abstract objects of interest inside the system and deliverables are identified as topics (e.g.a publishing system for pharmaceutical documents has “drug” as a central topic, regardless of whether there is a corresponding XML element for drug or how the requirements were organized, because the topic of “drug” is pivotal for discussion and use of the system),
- then links made to the original business requirements, architecture documents, sample documents, design documents, schema elements, stylesheets, test document and transforms, and bug tracking.
- All email and correspondence is saved by thread under a topic, and documents sent as attachments themselves are linkable.
The result is that when a customer decides they want some issue dealt with (new or altered functionality, bug fix, etc) and lodge this with a description, it is possible to trace trough the system to find all the original business requirements, which XML elements are affected, which scripts and styles and programs use these elements (and consequently, what will break or also need to be attended to), what previous discussion has been made, whether the new requirement contradicts an old requirement, and so on. (Some of the topics can be mashups of information in existing systems of course.)