The End of Empire: IBM, OpenDocument, and Enterprise Monocultures

IBM recently announced the next version of Lotus Notes will support OpenDocument Format as a native file format (as reported in IBM Bets Big On Open Source In Next Release Of Lotus Notes). This shift to an open file format is - as the majority of the coverage of IBM's announcement correctly interprets it to be - a direct challenge to the dominance of the Office suite of productivity applications, a class of products in which Microsoft has long relied on proprietary file formats as a cornerstone of it's market control strategy. Making the challenge explicit, the next version of Lotus Notes will also include "...built-in word processing, spreadsheet, and presentation graphics software".

Since Microsoft relies on the integration of SharePoint and the Office suite as a pillar of it's collaboration plans (in Gates outlines SharePoint strategy, hammers IBM, John Fontana of Network World quotes Bill Gates as saying, "The key point is that SharePoint is becoming the key platform for collaboration of all types... When people look back on what we are doing with Office [2007] here, the most revolutionary element will be what we are doing with SharePoint."), IBM's shift to OpenDocument Format is also a strategic move in the larger category of enterprise collaboration, itself a subset of the emerging comprehensive information working environments Forrester Research calls the information workplace.

An End to Imperialism

I've suggested already that the conceptual construct labeled 'collaboration' is at heart another instance of enterprise software and solution vendor marketing rhetoric designed to mask reality - it's simply not possible to change established cultural, organizational, perceptual, or philosophical understandings of what work is and how it should be done with an approach centered on technology - in a quasi-utopian haze.

IBM's adoption of OpenDocument doesn't change this picture of the collaboration landscape. Instead, it indicates a larger shift; dawning recognition and acknowledgment that monocultures are no longer viable, or valid, or broadly acceptable in the enterprise arena.

The creation and preservation of monocultures (recently in the news associated with Microsoft thanks to Dan Greer and others' prescience) is one of the salient characteristics of the old approach to enterprise software solutions. It is especially visible in those enterprise solutions whose intended role within a portfolio of product and service offerings is to serve as a consistent revenue source, strategic bulwark against competition, and cost shifting mechanism whereby clients paid for the development of new products and services, often under the guise of maintenance, patches, upgrades, etc.

Broadly, the old approach to enterprise solutions was an imperial model, with aspects of colonialism, that pursued a military style take and hold growth pattern.

Wikipedia offers the following introduction to imperialism:

"Imperialism is a policy of extending control or authority over foreign entities as a means of acquisition and/or maintenance of empires. This is either through direct territorial conquest or settlement, or through indirect methods of exerting control on the politics and/or economy of other countries. The term is often used to describe the policy of a country's dominance over distant lands, regardless of whether the country considers itself part of the empire."

In the realm of software imperialism, the customer organization buying and installing an enterprise software package was seen as a form of territory to be occupied or controlled by one or more hostile, rivalrous software and services vendors seeking to extract continuing revenues from their occupied possessions; revenues in the form of maintenance, support, customization, administration, or other sorts of solution upkeep and extension expenses.

Empires exerted control formally through a variety of political and economic mechanisms, and informally through influence over political, economic and cultural spheres. Wikipedia's entry for "empire" offers some instructive parallels to the enterprise solution model:

"First, in an empire there must be a Core and a Periphery. The empire's structure relates the core elite to the peripheral elite in a mutually beneficial fashion. Such as relationship can be established through any number of means, be they aggressive, coercise, or consensual. And while there is a vertical relationship between the core and periphery, there is a lack of substantive relations between periphery and periphery. This relationship he describes as an incomplete wheel: there are hubs and spokes, but no rim."

The relationship of interconnected elites is easy to see in the pattern of incented sales and buying decisions; "Need tickets to that exclusive event? No problem, we'll get them for you right away..."

But it's the idea of disconnected hubs and spokes that is key to understanding the correspondence between the old enterprise model and imperialism. How often do individual client solutions (perhaps for different departments or business units) interact with each other? How often do instances of the same solution for different clients allow effective interaction between different clients of the same vendor? How often do different products nominally part of 'integrated' solution sets that were in actuality assembled by aggregating the offerings of acquired companies successfully interact?

Again, without overloading the analogy, there are clear parallels between the degrees of empire and the lifecycle of enterprise solutions and vendors.

"Motyl also posits varying degrees of empire: Formal, Informal, and Hegemonic. In a formal imperial relationship, the core can appoint and dismiss peripheral elites, obviate any external agenda or policies, and directly control the internal agenda and policies."

As a consultant, I've seen aggressive software and services vendors directly drive business direction, strategy, investment, and process change decisions all too often. Organizations lacking vision, effective leadership, or those entering complacency or suffering decline look to vendors for leadership by proxy, allowing or asking vendors to apply their own inappropriate frames of reference and perspectives to understand and choose courses of action in situations outside the vendor's proper domain.

"In an informal imperial relationship, the core has influence but not control over appointing and dismissing peripheral elites, direct control over the external agenda and policies, and influence over the internal agenda and policies."

This informal relationship is the position of the entrenched vendor that provides 'perspective' on many situations outside their proper domain. Vendors seeking to increase their territory within client organizations often pursue growth via this method. Alternatively, vendors will control the environment in which customers and other service providers make decisions, as in the "open API" approach wherein the enterprise exposes a portion of it's architecture, code base, or other platform, but maintains exclusive control over the API without any binding commitments.

Wikipedia continues:

"Finally, in a hegemonic relationship, the core has no control over appointing or dismissing peripheral elites, control over the external agenda, influence over external policies, and no control over the internal agenda or policies."

This is the stage that the existing collaboration solutions seem to be entering, as witnessed by IBM's announcement, and Microsoft's failure to date to advance the OpenXML standard to full legitimacy.

The Passing of Imperium

In essence, the old enterprise approach exemplified the closed system, one that was sustained by the authority and credibility of the originating vendor in the face of other competing closed systems. Fundamentally, software empires and imperialism are predicated on the validity of closed systems. What happens when open systems become the preferred model?

"Empire ends when significant peripheral interaction begins, not necessarily when the core ceases its domination of the peripheries. The core-periphery relationship can be as strong or weak as possible and remain an empire as long as there is only insignificant interaction between periphery and periphery."

OpenDocument is designed to allow exactly the sort of periphery to periphery interaction that closed architectures prohibited. IBM's shift to OpenDocument shows awareness that old style closed imperial enterprise systems are no longer viable. In this, they are following the changing rhetoric of those such as Larry Cannell from collaborationloop.com, who offers a strongly pro-open system view in A Vision For Collaborative Technologies:

"I believe openness breeds innovation, and there are many parts of the collaborative technology market that need a big injection of innovation. While vendors continue pushing integration as their primary value proposition for closed systems, the astute competitor will embrace openness and provide innovation within an ecosystem of collaborative technologies based on open standards. Today we have a plethora of email systems which nearly everyone connected to the Internet is capable of using. We need comparable open and simple choices for other collaborative technologies; whether it is collaborative workspaces or online communities. It will not be until we have simple open standards that foster familiarity and easy interconnectivity that will we see widespread use and explosive innovation."

Cannell is careful here to take a positive and forward-looking line regarding collaboration, but his view of closed systems is clearly negative. And the implied consequence of a closed system is lack of innovation, one of the key signs of organizations in decline.

Didn't I start out by saying that we should be wary of the marketing rhetoric surrounding collaboration? Yes, precisely because the majority of the rhetoric coming from enterprise vendors still exemplifies the closed system, imperialist enterprise ethos.

However, in the case of IBM, it's clear that they've anticipated the consequences of ignoring the environmental shift to open systems that is at hand, and reacted accordingly, at least as regards the core document standard underlying Lotus Notes (which is still awful, BTW, just in case anyone misinterprets this article to mean I think otherwise...). The relationship of Notes to Workplace seems largely unknown at this point, and still subject to bitter infighting, in another great parallel to the imperial model. Microsoft, as the other major collaboration vendor, may be able to stem the tide against open systems in the short term, but will eventually have to respond.

My thoughts on the current form of enterprise solutions as a class / industry / way of solving business problems remain unaltered - in fact I think that IBM's move supports many of the predictions I made earlier this year, following earlier treatments by others writing on the same subjects.

local tags: collaboration, enterprise, ibm, lotusnotes, microsoft, odf, sharepoint, systems_theory

Cartograms, Tag Clouds and Visualization

I was enjoying some of the engaging cartograms available from Worldmapper, when I realized tag clouds might have some strong parallels with cartograms. After a quick substitution exercise, I've come to believe tag clouds could be to lists of metadata what cartograms are to maps; attempted solutions to similar visualization problems driven by common and historically consistent information needs.

Here's the train of thought behind the analogy. Cartograms are the distorted but captivating maps that change the familiar shapes of places on a map to visually show data about geographic locations. Cartograms change the way locations appear to make a point or communicate relative differences in the underlying data; for example, by making countries with higher GDP (gross domestic product) bigger, and those with lower GDP smaller. In the example below, Japan's size is much larger than it's geographic area, because it's GDP is so high (it's the dark green blob on the far right, much larger than China or India), while Africa is nearly invisible.

Gross Domestic Product

Tag clouds pursue the same goal: to enhance our understanding by communicating contextual meaning through changes in the way a set of things are visualized, relying additional dimensions of information to make context explicit. Where cartograms change geographic units, tag clouds change the display of a list of labels (the end point of a chain of linkages connecting concepts to focuses) to communicate the semantic importance or context of the underlying concepts shown in the list.
Visually, the relationship of clouds to lists is similar to that of maps and cartograms; compare these two renderings of the most popular search terms recorded by nytimes.com, one a simple list and the other a tag cloud.

List Rendering of Search Terms

Cloud Rendering of Search Terms

This explanation of cartograms from Cartogram Central a site supported by the U.S. Geological Survey and tional Center for Geographic Information and Analysis makes the parallels clearer, in greater detail.
"A cartogram is a type of graphic that depicts attributes of geographic objects as the object's area. Because a cartogram does not depict geographic space, but rather changes the size of objects depending on a certain attribute, a cartogram is not a true map. Cartograms vary on their degree in which geographic space is changed; some appear very similar to a map, however some look nothing like a map at all."

Now for the cut and paste. Substitute 'tag cloud' for cartogram, 'semantic' for geographic, and 'list' in for map, and the same explanation reads:

"A tag cloud is a type of graphic that depicts attributes of semantic objects as the object's area. Because a tag cloud does not depict semantic space, but rather changes the size of objects depending on a certain attribute, a tag cloud is not a true list. Tag Clouds vary on their degree in which semantic space is changed; some appear very similar to a list, however some look nothing like a list at all."

This is a good match for the current understanding of tag clouds.

Diving in deeper, Cartogram Central offers an excerpt from Cartography: Thematic Map Design, that goes into more detail about the specific characteristics of cartograms.

Erwin Raisz called cartograms 'diagrammatic maps.' Today they might be called cartograms, value-by-area maps, anamorphated images or simply spatial transformations. Whatever their name, cartograms are unique representations of geographical space. Examined more closely, the value-by-area mapping technique encodes the mapped data in a simple and efficient manner with no data generalization or loss of detail. Two forms, contiguous and non-contiguous, have become popular. Mapping requirements include the preservation of shape, orientation contiguity, and data that have suitable variation. Successful communication depends on how well the map reader recognizes the shapes of the internal enumeration units, the accuracy of estimating these areas, and effective legend design. Complex forms include the two-variable map. Cartogram construction may be by manual or computer means. In either method, a careful examination of the logic behind the use of the cartogram must first be undertaken."

Doing the same substitution exercise on this excerpt with the addition of 'relevance' for value, 'size' for area, and 'term' for shape, yields similar results:

"Erwin Raisz called tag clouds 'diagrammatic lists.' Today they might be called tag clouds, relevance-by-size lists, anamorphated images or simply spatial transformations. Whatever their name, tag clouds are unique representations of semantic space. Examined more closely, the relevance-by-size listing technique encodes the listed data in a simple and efficient manner with no data generalization or loss of detail. Two forms, contiguous and non-contiguous, have become popular. Listing requirements include the preservation of term, orientation, contiguity, and data that have suitable variation. Successful communication depends on how well the list reader recognizes the terms (of the internal enumeration units), the accuracy of estimating these sizes, and effective legend design. Complex forms include the two-variable list. Tag cloud construction may be by manual or computer means. In either method, a careful examination of the logic behind the use of the tag cloud must first be undertaken."

The correspondence here is strong as well.

Stable Need
The fact that cartograms and tag clouds show close parallels means that while the tag cloud may be a new user interface element emerging for the Web (and major desktop applications like Outlook, in the case of Taglocity), tag clouds as a type of visualization have strong precedents in other much more mature user experience contexts, such as the display of multiple dimensions of information within geographic or geospatial frames of reference. Instances of strong correspondence of problem solving approach in both mature and emerging contexts could indicate simple application of parallel framing (from the mature context to the emerging context) as an untested conditional, until the true extent of divergence separating the two contexts is understood. This is very common new media.

Instead, in the case of tag clouds, I think it points at stable needs driving structurally similar solutions to the basic problem of how to visually communicate important relationships and additional dimensions of meaning under the limitations of inherent flatness. The parallels between cartograms and tag clouds place the appearance of the tag cloud within the larger history of continuing exploration of new ways of visualizing information. In this view, tag clouds are a recent manifestation of the stable need to create strong and effective visual ways of conveying more than membership in a one-dimensional set (the list), or location and extent within a two-dimensional coordinate system (the map).

local tags: cartogram, cartography, tagclouds, tagging, visualization

Who Should Own How We Work? Collaboration, the New Enterprise Application

Collaboration is the latest rallying cry of software vendors hoping to embed new generations of enterprise class tools and user experiences into the fabric of the modern workplace. Microsoft, IBM, and other firms expect that control or leadership in the market for collaboration, whether by owning the architecture, systems, or other solution components, will be lucrative. A recent Radicati Group study (quality unconfirmed...) of the market size for enterprise collaboration offered an estimate of $1.6 billion now, growing 10% annually to $2.3 billion in 2010.

Beyond the substantial money to be made creating, selling, installing, and servicing collaboration solutions lies the strategic advantage of market definition. The vendor(s) that own(s) the collaboration space expect(s) to become an integral to the knowledge economy's supporting environment in the same way that Ford and General Motors became essential to the suburbanized consumer architectures of the post WWII era by serving simultaneously as employers, manufacturers, cultural marketers, capital reservoirs, and automobile sellers. Collaboration vendors know that achieving any level of indispensibility will enhance their longevity by making them a necessity within the knowledge economy.

It's worth taking a moment to call attention to the implications: by defining the user experiences and technological building blocks brought together to realize collaboration in large enterprises, these vendors will directly shape our basic concepts and understanding (our mental models and cognitive frames) of collaboration. Once embedded, these architectures, systems, and business processes, and the social structures and conceptual models created in response, will in large part define the (information) working environments of the future.

And yes, this is exactly what these vendors aspire to achieve; the Microsoft Sharepoint Products and Technologies Development Team blog, offers:

"SharePoint Products and Technologies have become a key part of our strategy for delivering a complete working environment for information workers, where they can collaborate together, share information with others, and find information and people that can help them solve their business problems."

[From SHAREPOINT'S ROLE IN MICROSOFT'S COLLABORATION STRATEGY.]

And IBM's marketing is not pitched and delivered in a manner as sweeping, but the implications are similar, as in the overview IBM® Workplace™: Simply a better way]:

"IBM Workplace™ Solutions are role-based frameworks to help customers apply IBM Workplace technologies faster and more productively... These solutions are designed to provide 'short-cuts' for creating a high performance role-based work environment, helping to accelerate time-to-value."

The Models for communication and relationships built into our tools are very powerful, and often employed in other spheres of life. How many times have you started writing a birthday card for a friend, and found yourself instinctively composing a set of bullet points listing this person's chief virtues, notable character traits, and the most important / amusing moments of your friendship. The creeping ubiquity of the rhetorical style of Powerpoint (Tufte's essay here) is just one example of the tremendous social impact of a habituated model of communicative practices that's run amok.

What does the future hold, in terms of enterprise vendor control over everyday working experiences? I've written before on the idea that the days of the monolithic enterprise systems are numbered, making the point along the way that these behemoths are the result of a top-down, one-size-for-all approach. I think the same is true of the current approach to collaboration solutions and working environments. And so I was happy to see Andrew McAfee of Harvard Business School make several strong points about how enterprise collaboration efforts will realize greater success by *reducing* the amount of structure imposed on their major elements - roles, workflows, artifacts, and relationships - in advance of actual use.

McAfee sees considerable benefit in new approaches to enterprise IT investment and management that reduce the top-down and imposed nature of enterprise environments and solutions, in favor of emergent structures created by the people who must work successfully within them. McAfee advocates allowing staff to create the identities, structures and patterns that will organize and govern their collaboration environments as necessary, in an emergent fashion, instead of fixing these aspects long before users begin to collaborate.

McAfee says:

"When I look at a lot of corporate collaboration technologies after spending time at Wikipedia, del.icio.us, Flickr, and Blogger I am struck by how regimented, inflexible, and limited the corporate stuff seems, because it does some or all of the following:

• Gives users identities before they start using the technology. These identities assign them certain roles, privileges, and access rights, and exclude them from others. These identities almost always also place them within the existing organizational structure and formal corporate hierarchy.


• Contains few truly blank pages. Instead, it has lots of templates--for meetings, for project tracking, for documents and reports, etc.


• Has tons of explicit or implicit workflow-- seqences [sic] of tasks that must be executed in order.

How much of this structure is necessary? How much is valuable? Well, the clear success stories of Web 2.0 demonstrate that for at least some types of community and collaboration, none of it is."

The critical question is then "what types of community and collaboration require which approaches to creating structure, and when?" As anyone who's used a poorly or overly structured collaboration (or other enterprise) tool knows, the resulting environment is often analogous to a feudal society designed and managed by crypto-technical overlords; one in which most users feel as if they are serfs bound to the land for in perpetuity in order to support the leisure-time and war-making indulgences of a small class of shareholding nobility.

Answering these questions with confidence based on experience will likely take time in the range of years, and require numerous failed experiments. There's a larger context to take into account: the struggle of enterprise software vendors to extend their reach and longevity by dominating the language of collaboration and the range of offerings is one part of a much broader effort by society to understand dramatic shifts in our ways of working, and the social structures that are both driven by and shape these new ways of working. And so there are several important ideas and questions underlying McAfee's assessment that social system designers should understand.

One of the most important is that the notion of "collaboration" is conceptual shorthand for how you work, who you work with, and what you do. In other words, it's a distillation of your professional identity. Your role in a collaboration environment defines who you are within that environment.

More importantly, from the perspective of growth and development, your system assigned role determines who you can *become*. Knowledge workers are valued for their skills, experience, professional networks, public reputations, and many other fluid, context dependent attributes. And so locking down their identities in advance strips them of a substantial proportion of their current value, and simultaneously reduces their ability to adapt, innovate, and respond to environmental changes by shifting their thinking or practices. In plain terms, determining their identities in advance precludes the creation of future value.

Another important underlying idea is the importance of properly understanding the value and utility of differing approaches to systematization in differing contexts. McAfee's assessment of the unhealthy consequences of imposing too much structure in advance is useful for social system designers (such as information architects and knowledge managers), because it makes the outcomes of implicit design strategies and assumptions clear and tangible, in terms of the negative effects on the eventual users of the collaboration environment. For complex and evolving group settings like the modern enterprise, creating too much structure in advance points to a misplaced understanding of the value and role of design and architecture.

Fundamentally, it indicates an overestimation of the value of the activity of systematizing (designing) collaboration environments to high levels of detail, and without recognition for evolutionary dynamics. The design or structure of any collaboration environment - of any social system - is only valuable for how well it encourages relationships and activity which advance the goals of the organization and it's members. The value of a designer in the effort to create a collaborative community lies in the ability to create designs that lead to effective collaboration, not in the number or specificity of the designs they produce, and especially not in the artifacts created during design - the templates, workflows, roles, and other McAfee mentioned above. To simplify the different views of what's appropriate into two artificially segmented camps, the [older] view that results in the premature creation of too much structure validates the design of things / artifacts / static assemblies, whereas the newer view valuing minimal and emergent structures acknowledges the greater efficacy of designing dynamic systems / flows / frameworks.

The overly specific and rigid design of many collaboration system components coming from the older design viewpoint in fact says much about how large, complex enterprises choose to interpret their own characters, and create tools accordingly. Too often, a desire to achieve totality lies at the heart of this approach.

Of course, most totalities only make sense - exhibit coherence - when viewed from within, and when using the language and concepts of the totality itself. The result is that attempts to achieve totality of design for many complex contexts (like collaboration within enterprises large or small) represent a self-defeating approach. That the approach is self-defeating is generally ignored, because the pursuit of totality is a self-serving exercise in power validation, that benefits power holders by consuming resources potentially used for other purposes, for example, to undermine their power.

With the chimera of totality set in proper context, it's possible to see how collaboration environments - at least in their most poorly conceived manifestations - will resemble virtual retreads of Taylorism, wherein the real accomplishment is to justify the effort and expense involved in creating the system by pointing at an excessive quantity of predetermined structure awaiting habitation and use by disenfranchised staff.

At present, I see two divergent and competing trends in the realm of enterprise solutions and user experiences. The first trend is toward homogeneity of the working environment with large amounts of structure imposed in advance, exemplified by comprehensive collaboration suites and architectures such as MSOffice / Sharepoint, or IBM's Workplace.

The second trend is toward heterogeneity in the structures informing the working environment, visible as variable patterns and locuses of collaboration established by fluid groups that rely on adhoc assortment of tools from different sources (BaseCamp, GMail, social bookmarking services, RSS syndication of social media structures, communities of practice, business services from ASP providers, open source applications, etc.).

But this itself is a short term view, when situation within a longer term context is necessary. It is common for systems or environments of all sizes and complexities to oscillate cyclically from greater to lesser degrees of structure, along a continuum ranging from homogeneous to heterogeneous. In the short term view then, the quest for totality equates to homogeneity, or even efforts at domination. In the long term view, however, the quest for totality could indicate an immature ecosystem that is not diverse, but may become so in time.

Applying two (potential) lessons from ecology - the value of diversity as an enhancer of overall resilience in systems, and the tendency of monocultures to exhibit high fragility - to McAfee's points on emergence, as well as the continuum view of shifting degress of homogeneity, should tell us that collaboration solution designers would be wise to do three things:

1. Adopt the new design viewpoint and focus on designing structures that allow collaborators to create value


2. Specify as little structure of any kind in advance as possible


3. Anticipate the emergence of new architectural elements, and allow for their incorporation under the guidance of the community of collaborators

The end result should be an enterprise approach to collaboration that emphasizes the design of infrastructure for communities that create their own structures. Big vendors be wary of this enlightened point of view, unless you're willing to respond in kind.

local tags: architecture, collaboration, enterprise, lotus_notes, mental_models, organizations, social_systems, ux, web20

Tag Clouds: "A New User Interface?"

In Pivoting on tags to create better navigation UI Matt McAllister offers the idea that we're seeing "a new user interface evolving out of tag data," and uses Wikio as an example. For context, he places tag clouds within a continuum of the evolution of web navigation, from list views to the new tag-based navigation emerging now.

It's an insightful post, and it allows me to build on strong groundwork to talk more about why and how tag clouds differ from earlier forms of navigation, and will become [part of] a new user interface.

Matt identifies five 'leaps' in web navigation interfaces that I'll summarize:

1. List view; a list of links


2. Left-hand column; a standard location for lists of links used to navigate


3. Search boxes and results pages; making very large lists manageable


4. Tab navigation; a list of other navigation lists


5. Tag navigation; tag clouds

A Lesson in 'Listory'

As Matt mentions, all four predecessors to tag based navigation are really variations on the underlying form of the list. There's useful history in the evolution of lists as web navigation tools. Early lists used for navigation were static, chosen by a site owner, ordered, and flat: recall the lists of favorite sites that appeared at the bottom of so many early personal home pages.

These basic navigation lists evolved a variety of ordering schemes, (alphabetical, numeric), began to incorporate hierarchy (shown as sub-menus in navigation systems, or as indenting in the left-column Matt mentions), and allowed users to change their ordering, for example by sorting on a variety of fields or columns in search results.

From static lists whose contents do not change rapidly and reflect a single point of view, the lists employed for web navigation and search results then became dynamic, personalized, and reflective of multiple points of view. Amazon and other e-commerce destinations offered recently viewed items (yours or others), things most requested, sets bounded by date (published last year), sets driven by varying parameters (related articles), and lists determined by the navigation choices of others who followed similar paths.)

But they remained fundamentally lists. They itemized or enumerated choices of one kind or another, indicated implicit or explicit precedence through ordering or the absence of ordering, and were designed for linear interaction patterns: start at the beginning (or the end, if you preferred an alternative perspective - I still habitually read magazines from back to front...) and work your way through.

Tag clouds are different from lists, often by contents and presentation, and more importantly by basic assumption about the kind of interaction they encourage. On tag-based navigation Matt says, "This is a new layer that preempts the search box in a way. The visual representation of it is a tag cloud, but the interaction is more like a pivot." Matt's mention of the interaction hits on an important aspect that's key to understanding the differences between clouds and lists: clouds are not linear, and are not designed for linear consumption in the fashion of lists.

I'm not saying that no one will read clouds left to right (with Roman alphabets), or right to left if they're in Hebrew, or in any other way. I'm saying that tag clouds are not meant for 'reading' in the same way that lists are. As they're commonly visualized today, clouds support multiple entry points using visual differentiators such as color and size.

Starting in the middle of a list and wandering around just increases the amount of visual and cognitive work involved, since you need to remember where you started to complete your survey. Starting in the "middle" of a tag cloud - if there is such a location - with a brightly colored and big juicy visual morsel is *exactly* what you're supposed to do. It could save you quite a lot of time and effort, if the cloud is well designed and properly rendered.

Kunal Anand created a visualization of the intersections of his del.icio.us tags that shows the differences between a cloud and a list nicely. This is at heart a picture, and accordingly you can start looking at it anywhere / anyway you prefer.

Visualizing My Del.icio.us Tags

We all know what a list looks like...

iTunes Play Lists

What's In a Name?
Describing a tag cloud as a weighted list (I did until I'd thought about it further) misses this important qualitative difference, and reflects our early stages of understanding of tag clouds. The term "weighted list" is a list-centered view of tag clouds that comes from the preceding frame of reference. It's akin to describing a computer as an "arithmetic engine", or the printing press as "movable type".

[Aside: The label for tag clouds will probably change, as we develop concepts and language to frame new the user experiences and information environments that include clouds. For example, the language Matt uses - the word 'pivot' when he talks about the experience of navigating via the tag cloud in Wikio, not the word 'follow' which is a default for describing navigation - in the posting and his screencast reflects a possible shift in framing.]

A Camera Obscura For the Semantic Landscape
I've come to think of a tag cloud as something like the image produced by a camera obscura.

Camera Obscura

Where the camera obscura renders a real-world landscape, a tag cloud shows a semantic landscape like those created by Amber Frid-Jimenez at MIT.

Semantic Landscape

Semantic Landscape

Like a camera obscura image, a tag cloud is a filtered visualization of a multidimensional world. Unlike a camera obscura image, a tag cloud allows movement within the landscape. And unlike a list, tag clouds can and do show relationships more complex than one-dimensional linearity (experienced as precedence). This ability to show more than one dimension allows clouds to reflect the structure of the environment they visualize, as well as the contents of that environment. This frees tag clouds from the limitation of simply itemizing or enumerating the contents of a set, which is the fundamental achievement of a list.

Earlier, I shared some observations on the structural evolution - from static and flat to hierarchical and dynamic - of the lists used as web navigation mechanisms. As I've ventured elsewhere, we may see a similar evolution in tag clouds.

It is already clear that we're witnessing evolution in the presentation of tag clouds in step with their greater visualizatin capabilities. Clouds now rely on an expanding variety of visual cues to show an increasingly detailed view of the underlying semantic landscape: proximity, depth, brightness, intensity, color of item, color of field around item. I expect clouds will develop other cues to help depict the many connections (permanent or temporary) linking the labels in a tag cloud. It's possible that tag clouds will offer a user experience similar to some of the ontology management tools available now.

Is this "a new user interface"? That depends on how you define new. In Shaping Things, author and futurist Bruce Sterling suggests, "the future composts the past" - meaning that new elements are subsumed into the accumulation of layers past and present. In the context of navigation systems and tag clouds, that implies that we'll see mixtures of lists from the four previous stages of navigation interface, and clouds from the latest leap; a fusion of old and new.

Examples of this composting abound, from 30daytags.com to Wikio that Matt McAllister examined.

30DayTags.com Tag Clouds

Wikio Tag Cloud

As lists encouraged linear interactions as a result of their structure, it's possible that new user interfaces relying on tag clouds will encourage different kinds of seeking or finding behaviors within information experiences. In "The endangered joy of serendipity" William McKeen bemoans the decrease of serendipity as a result of precisely directed and targeted media, searching, and interactions. Tag clouds - by offering many connections and multiple entry paths simultaneously - may help rejuvenate serendipity in danger in a world of closely focused lists.

local tags: semantics, tagclouds, tagging, ux, visualization