archive.Joe Lamantia.com

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.

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).

Col­lab­o­ra­tion is the lat­est ral­ly­ing cry of soft­ware ven­dors hop­ing to embed new gen­er­a­tions of enter­prise class tools and user expe­ri­ences into the fab­ric of the mod­ern work­place. Microsoft, IBM, and other firms expect that con­trol or lead­er­ship in the mar­ket for col­lab­o­ra­tion, whether by own­ing the archi­tec­ture, sys­tems, or other solu­tion com­po­nents, will be lucra­tive. A recent Rad­i­cati Group study (qual­ity uncon­firmed…) of the mar­ket size for enter­prise col­lab­o­ra­tion offered an esti­mate of $1.6 bil­lion now, grow­ing 10% annu­ally to $2.3 bil­lion in 2010.

Beyond the sub­stan­tial money to be made cre­at­ing, sell­ing, installing, and ser­vic­ing col­lab­o­ra­tion solu­tions lies the strate­gic advan­tage of mar­ket def­i­n­i­tion. The vendor(s) that own(s) the col­lab­o­ra­tion space expect(s) to become an inte­gral to the knowl­edge economy’s sup­port­ing envi­ron­ment in the same way that Ford and Gen­eral Motors became essen­tial to the sub­ur­ban­ized con­sumer archi­tec­tures of the post WWII era by serv­ing simul­ta­ne­ously as employ­ers, man­u­fac­tur­ers, cul­tural mar­keters, cap­i­tal reser­voirs, and auto­mo­bile sell­ers. Col­lab­o­ra­tion ven­dors know that achiev­ing any level of indis­pen­si­bil­ity will enhance their longevity by mak­ing them a neces­sity within the knowl­edge econ­omy.

It’s worth tak­ing a moment to call atten­tion to the impli­ca­tions: by defin­ing the user expe­ri­ences and tech­no­log­i­cal build­ing blocks brought together to real­ize col­lab­o­ra­tion in large enter­prises, these ven­dors will directly shape our basic con­cepts and under­stand­ing (our men­tal mod­els and cog­ni­tive frames) of col­lab­o­ra­tion. Once embed­ded, these archi­tec­tures, sys­tems, and busi­ness processes, and the social struc­tures and con­cep­tual mod­els cre­ated in response, will in large part define the (infor­ma­tion) work­ing envi­ron­ments of the future.And yes, this is exactly what these ven­dors aspire to achieve; the Microsoft Share­point Prod­ucts and Tech­nolo­gies Devel­op­ment Team blog, offers:

“Share­Point Prod­ucts and Tech­nolo­gies have become a key part of our strat­egy for deliv­er­ing a com­plete work­ing envi­ron­ment for infor­ma­tion work­ers, where they can col­lab­o­rate together, share infor­ma­tion with oth­ers, and find infor­ma­tion and peo­ple that can help them solve their busi­ness prob­lems.“
[From SHAREPOINT’S ROLE IN MICROSOFT’S COLLABORATION STRATEGY.]

And IBM’s mar­ket­ing is not pitched and deliv­ered in a man­ner as sweep­ing, but the impli­ca­tions are sim­i­lar, as in the overview IBM® Work­place™: Sim­ply a bet­ter way]:
“IBM Work­place™ Solu­tions are role-based frame­works to help cus­tomers apply IBM Work­place tech­nolo­gies faster and more pro­duc­tively… These solu­tions are designed to pro­vide ‘short-cuts’ for cre­at­ing a high per­for­mance role-based work envi­ron­ment, help­ing to accel­er­ate time-to-value.“

The Mod­els for com­mu­ni­ca­tion and rela­tion­ships built into our tools are very pow­er­ful, and often employed in other spheres of life. How many times have you started writ­ing a birth­day card for a friend, and found your­self instinc­tively com­pos­ing a set of bul­let points list­ing this person’s chief virtues, notable char­ac­ter traits, and the most impor­tant / amus­ing moments of your friend­ship. The creep­ing ubiq­uity of the rhetor­i­cal style of Pow­er­point (Tufte’s essay here) is just one exam­ple of the tremen­dous social impact of a habit­u­ated model of com­mu­nica­tive prac­tices that’s run amok.

What does the future hold, in terms of enter­prise ven­dor con­trol over every­day work­ing expe­ri­ences? I’ve writ­ten before on the idea that the days of the mono­lithic enter­prise sys­tems are num­bered, mak­ing the point along the way that these behe­moths are the result of a top-down, one-size-for-all approach. I think the same is true of the cur­rent approach to col­lab­o­ra­tion solu­tions and work­ing envi­ron­ments. And so I was happy to see Andrew McAfee of Har­vard Busi­ness School make sev­eral strong points about how enter­prise col­lab­o­ra­tion efforts will real­ize greater suc­cess by *reduc­ing* the amount of struc­ture imposed on their major ele­ments — roles, work­flows, arti­facts, and rela­tion­ships — in advance of actual use.

McAfee sees con­sid­er­able ben­e­fit in new approaches to enter­prise IT invest­ment and man­age­ment that reduce the top-down and imposed nature of enter­prise envi­ron­ments and solu­tions, in favor of emer­gent struc­tures cre­ated by the peo­ple who must work suc­cess­fully within them. McAfee advo­cates allow­ing staff to cre­ate the iden­ti­ties, struc­tures and pat­terns that will orga­nize and gov­ern their col­lab­o­ra­tion envi­ron­ments as nec­es­sary, in an emer­gent fash­ion, instead of fix­ing these aspects long before users begin to col­lab­o­rate.

McAfee says:
“When I look at a lot of cor­po­rate col­lab­o­ra­tion tech­nolo­gies after spend­ing time at Wikipedia, del.icio.us, Flickr, and Blog­ger I am struck by how reg­i­mented, inflex­i­ble, and lim­ited the cor­po­rate stuff seems, because it does some or all of the following:

• Gives users iden­ti­ties before they start using the tech­nol­ogy. These iden­ti­ties assign them cer­tain roles, priv­i­leges, and access rights, and exclude them from oth­ers. These iden­ti­ties almost always also place them within the exist­ing orga­ni­za­tional struc­ture and for­mal cor­po­rate hierarchy.
• Con­tains few truly blank pages. Instead, it has lots of templates–for meet­ings, for project track­ing, for doc­u­ments and reports, etc.
• Has tons of explicit or implicit work­flow– seqences [sic] of tasks that must be exe­cuted in order.

How much of this struc­ture is nec­es­sary? How much is valu­able? Well, the clear suc­cess sto­ries of Web 2.0 demon­strate that for at least some types of com­mu­nity and col­lab­o­ra­tion, none of it is.“

The crit­i­cal ques­tion is then “what types of com­mu­nity and col­lab­o­ra­tion require which approaches to cre­at­ing struc­ture, and when?” As any­one who’s used a poorly or overly struc­tured col­lab­o­ra­tion (or other enter­prise) tool knows, the result­ing envi­ron­ment is often anal­o­gous to a feu­dal soci­ety designed and man­aged by crypto-technical over­lords; one in which most users feel as if they are serfs bound to the land for in per­pe­tu­ity in order to sup­port the leisure-time and war-making indul­gences of a small class of share­hold­ing nobil­ity.

Answer­ing these ques­tions with con­fi­dence based on expe­ri­ence will likely take time in the range of years, and require numer­ous failed exper­i­ments. There’s a larger con­text to take into account: the strug­gle of enter­prise soft­ware ven­dors to extend their reach and longevity by dom­i­nat­ing the lan­guage of col­lab­o­ra­tion and the range of offer­ings is one part of a much broader effort by soci­ety to under­stand dra­matic shifts in our ways of work­ing, and the social struc­tures that are both dri­ven by and shape these new ways of work­ing. And so there are sev­eral impor­tant ideas and ques­tions under­ly­ing McAfee’s assess­ment that social sys­tem design­ers should under­stand.

One of the most impor­tant is that the notion of “col­lab­o­ra­tion” is con­cep­tual short­hand for how you work, who you work with, and what you do. In other words, it’s a dis­til­la­tion of your pro­fes­sional iden­tity. Your role in a col­lab­o­ra­tion envi­ron­ment defines who you are within that envi­ron­ment.

More impor­tantly, from the per­spec­tive of growth and devel­op­ment, your sys­tem assigned role deter­mines who you can *become*. Knowl­edge work­ers are val­ued for their skills, expe­ri­ence, pro­fes­sional net­works, pub­lic rep­u­ta­tions, and many other fluid, con­text depen­dent attrib­utes. And so lock­ing down their iden­ti­ties in advance strips them of a sub­stan­tial pro­por­tion of their cur­rent value, and simul­ta­ne­ously reduces their abil­ity to adapt, inno­vate, and respond to envi­ron­men­tal changes by shift­ing their think­ing or prac­tices. In plain terms, deter­min­ing their iden­ti­ties in advance pre­cludes the cre­ation of future value.

Another impor­tant under­ly­ing idea is the impor­tance of prop­erly under­stand­ing the value and util­ity of dif­fer­ing approaches to sys­tem­ati­za­tion in dif­fer­ing con­texts. McAfee’s assess­ment of the unhealthy con­se­quences of impos­ing too much struc­ture in advance is use­ful for social sys­tem design­ers (such as infor­ma­tion archi­tects and knowl­edge man­agers), because it makes the out­comes of implicit design strate­gies and assump­tions clear and tan­gi­ble, in terms of the neg­a­tive effects on the even­tual users of the col­lab­o­ra­tion envi­ron­ment. For com­plex and evolv­ing group set­tings like the mod­ern enter­prise, cre­at­ing too much struc­ture in advance points to a mis­placed under­stand­ing of the value and role of design and archi­tec­ture.

Fun­da­men­tally, it indi­cates an over­es­ti­ma­tion of the value of the activ­ity of sys­tem­atiz­ing (design­ing) col­lab­o­ra­tion envi­ron­ments to high lev­els of detail, and with­out recog­ni­tion for evo­lu­tion­ary dynam­ics. The design or struc­ture of any col­lab­o­ra­tion envi­ron­ment — of any social sys­tem — is only valu­able for how well it encour­ages rela­tion­ships and activ­ity which advance the goals of the orga­ni­za­tion and it’s mem­bers. The value of a designer in the effort to cre­ate a col­lab­o­ra­tive com­mu­nity lies in the abil­ity to cre­ate designs that lead to effec­tive col­lab­o­ra­tion, not in the num­ber or speci­ficity of the designs they pro­duce, and espe­cially not in the arti­facts cre­ated dur­ing design — the tem­plates, work­flows, roles, and other McAfee men­tioned above. To sim­plify the dif­fer­ent views of what’s appro­pri­ate into two arti­fi­cially seg­mented camps, the [older] view that results in the pre­ma­ture cre­ation of too much struc­ture val­i­dates the design of things / arti­facts / sta­tic assem­blies, whereas the newer view valu­ing min­i­mal and emer­gent struc­tures acknowl­edges the greater effi­cacy of design­ing dynamic sys­tems / flows / frame­works.

The overly spe­cific and rigid design of many col­lab­o­ra­tion sys­tem com­po­nents com­ing from the older design view­point in fact says much about how large, com­plex enter­prises choose to inter­pret their own char­ac­ters, and cre­ate tools accord­ingly. Too often, a desire to achieve total­ity lies at the heart of this approach.

Of course, most total­i­ties only make sense — exhibit coher­ence — when viewed from within, and when using the lan­guage and con­cepts of the total­ity itself. The result is that attempts to achieve total­ity of design for many com­plex con­texts (like col­lab­o­ra­tion within enter­prises large or small) rep­re­sent a self-defeating approach. That the approach is self-defeating is gen­er­ally ignored, because the pur­suit of total­ity is a self-serving exer­cise in power val­i­da­tion, that ben­e­fits power hold­ers by con­sum­ing resources poten­tially used for other pur­poses, for exam­ple, to under­mine their power.

With the chimera of total­ity set in proper con­text, it’s pos­si­ble to see how col­lab­o­ra­tion envi­ron­ments — at least in their most poorly con­ceived man­i­fes­ta­tions — will resem­ble vir­tual retreads of Tay­lorism, wherein the real accom­plish­ment is to jus­tify the effort and expense involved in cre­at­ing the sys­tem by point­ing at an exces­sive quan­tity of pre­de­ter­mined struc­ture await­ing habi­ta­tion and use by dis­en­fran­chised staff.

At present, I see two diver­gent and com­pet­ing trends in the realm of enter­prise solu­tions and user expe­ri­ences. The first trend is toward homo­gene­ity of the work­ing envi­ron­ment with large amounts of struc­ture imposed in advance, exem­pli­fied by com­pre­hen­sive col­lab­o­ra­tion suites and archi­tec­tures such as MSOf­fice / Share­point, or IBM’s Work­place.

The sec­ond trend is toward het­ero­gene­ity in the struc­tures inform­ing the work­ing envi­ron­ment, vis­i­ble as vari­able pat­terns and locuses of col­lab­o­ra­tion estab­lished by fluid groups that rely on adhoc assort­ment of tools from dif­fer­ent sources (Base­Camp, GMail, social book­mark­ing ser­vices, RSS syn­di­ca­tion of social media struc­tures, com­mu­ni­ties of prac­tice, busi­ness ser­vices from ASP providers, open source appli­ca­tions, etc.).

But this itself is a short term view, when sit­u­a­tion within a longer term con­text is nec­es­sary. It is com­mon for sys­tems or envi­ron­ments of all sizes and com­plex­i­ties to oscil­late cycli­cally from greater to lesser degrees of struc­ture, along a con­tin­uüm rang­ing from homo­ge­neous to het­ero­ge­neous. In the short term view then, the quest for total­ity equates to homo­gene­ity, or even efforts at dom­i­na­tion. In the long term view, how­ever, the quest for total­ity could indi­cate an imma­ture ecosys­tem that is not diverse, but may become so in time.

Apply­ing two (poten­tial) lessons from ecol­ogy — the value of diver­sity as an enhancer of over­all resilience in sys­tems, and the ten­dency of mono­cul­tures to exhibit high fragility — to McAfee’s points on emer­gence, as well as the con­tin­uüm view of shift­ing degress of homo­gene­ity, should tell us that col­lab­o­ra­tion solu­tion design­ers would be wise to do three things:

The end result should be an enter­prise approach to col­lab­o­ra­tion that empha­sizes the design of infra­struc­ture for com­mu­ni­ties that cre­ate their own struc­tures. Big ven­dors be wary of this enlight­ened point of view, unless you’re will­ing to respond in kind.

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:

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.