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.

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.

Congratulations to James Robertson and StepTwo Designs for releasing an updated version of the Intranet Review Toolkit, just before this year’s IA summit in lovely Vancouver (obligatory flickr link).

Version 1.1 of the Intranet Review Toolkit includes a heuristics summary designed for quick use; it’s based on a condensed version of the complete set of heuristics you may remember I offered a while back. StepTwo was kind enough to credit my modest contribution to the overall effort.

Other additions include a collaboration / community of use destination site http://www.intranetreviewtoolkit.org.

It’s only February, but I can already tell that I’m going to say “SharePoint is *not* an intranet!” many, many, many times in 2006…

Proving that a well-developed sense of humor is required for success in product design — especially for Lotus Notes — Mary Beth Raven, who leads the design team for the next version of Lotus Notes, recently posted a rather funny comment in reply to my suggestion that the Notes Design team offer customers a choice of unpleasant but related user experience themes. She used this as the occasion to invite all members of the community of Notes to users to register as volunteers for usability testing.
I’ve made three postings to date specifically discussing the Notes user experience: Lotus Notes User Experience = Disease, Mental Models, Resilience, and Lotus Notes, and Better UI Tops Notes Users’ Wish Lists. I’m not sure which of these prompted Mary Beth to reach out, but I’m glad she did, because doing so is smart business on two levels. At the first level, Mary Beth plainly understands that while vocal critics may seem daunting to user experience designers, product managers, and business owners, engaging these critics in fact presents design teams with opportunities to build strong connections to users and gather valuable feedback at the same time. What better way is there to show the strategic value of user research?
I learned this at first hand while working on a redesign of the flagship web presence of a large software firm several years ago. Some of the most insightful and useful feedback on the strengths and weaknesses of the user experiences I was responsible for came from ‘disgruntled’ customers. The user research I was doing on site structures, navigation paths, and user goals established a channel that allowed unhappy (and happy) customers to communicate about a broad range of their experiences with PTC products and services in a more complete way than by simply buying a competing product, or renewing an existing software license.
Based on these and other experiences building user research programs, I suggest that product managers, user research leads, and user experience designers first collaborate to define a user research strategy, and then define and create a simple but effective user research infrastructure (like registration gateways to volunteer databases, community / program identifiers and incentives, contact management tools, specific personas that technical and customer support teams can learn to recognize and recruit at all stages of the customer lifecycle, etc.) that will support the creation of channels to users throughout the design cycle.
At the second level, it allows the Notes team to directly explore collaboration methods, products, and technologies related to the very competitive collaboration suite / integrated electronic workspace / office productivity markets in which IBM, Microsoft, and several other giant firms are looking to secure dominant positions in the new culture of collaboration. [Note: I’ve posted a few times on Microsoft products as well – Backwards Goals: MS Office Results Oriented UI, and Microsoft’s Philosophy On Information Architecture.]
Members of the community of Lotus Notes users can register as volunteers for usability tests during the design of the next version of Notes at this URL: https://www-10.lotus.com/ldd/usentry.nsf/register?openform.

Related posts:

Update: Version 1.1 of the Intranet Review Toolkit is available as of 03/20/2006, and now includes a summary spreadsheet.
Thanks go to James Robertson for very gently reminding me that the licensing arrangements for the Intranet Review Toolkit preclude republishing it as a summarized form, such as the spreadsheet I posted earlier today. In my enthusiasm to share a tool with the rest of the community, I didn’t work through the full licensing implications…
Accordingly, I’ll be removing the spreadsheet from harms way immediately, while hoping it’s possible to make it available in a more legally acceptable form.
Apologies to James and the rest of the Toolkit team for any unintended harm from my oversight.

Related posts:

In the overview of the new “results oriented” UI planned for MS Office 12, our friends in Redmond offer:
“The overriding design goal for the new UI is to deliver a user interface that enables users to be more successful finding and using the advanced features of Microsoft Office. An additional important design goal was to preserve an uncluttered workspace that reduces distraction for users so that they can spend more time and energy focused on their work.”
Let me get that straight. Your first goal is to make it easier for me to find and use advanced features that the vast majority of people employ rarely if ever, and didn’t need in the first place?
And something else that was also important – but not as important as access to all those shiny advanced features – was to make the workspace uncluttered and allow me to focus on my work?
Isn’t that… backwards?

Related posts:

Lotus Notes has one of the most unpleas­ant and unwel­com­ing User Expe­ri­ences this side of a medium-security prison where the war­den has aspi­ra­tions towards inte­rior design and art instruc­tion. One of the most painful aspects of the Notes expe­ri­ence is the default set­tings for font size and color in the email win­dow. The default font size (for Macs) is on the order of 7 point type, and the default color for unread mes­sages is — iron­i­cally — red. The com­bi­na­tion yields a user expe­ri­ence that resem­bles a bad skin rash.

I call it “angry red microNotes” dis­ease, and it looks like this:

Over­all, it has an unhealthy affect on one’s state of mind. The under­tones of hos­til­ity and resent­ment run­ning through­out are man­i­fold. And nat­u­rally, it is impos­si­ble to change the default font size and color for the email reader. This is fur­ther con­fir­ma­tion for my the­ory that Notes has yet to escape it’s roots as a thick client for series of uncon­nected data­bases.

After three weeks of suf­fer­ing from angry red microNotes, I real­ized I was lit­er­ally going blind from squint­ing at the tiny type, and went to Google for relief. I found niniX 1.7, a util­ity that allows Mac based Lotus Notes users the abil­ity to edit the binary for­mat Notes pref­er­ences file, and change the font size of the email client. I share it in the hopes that oth­ers may break the chains that blind them. This will only solve half the prob­lem — if some­one can fig­ure out how to change the default color for unread mes­sages to some­thing besides skin rash red, I will hap­pily share with the rest of the suf­fer­ing masses (and appar­ently there are on the order of 118 mil­lion of us out there).

But will it always be this (hor­ri­ble) way?

In Beyond Notes 7.0: IBM Lotus sketches ‘Han­nover’ user expe­ri­ence Peter Bochner of SearchDomino.com says this of the next Notes release, “Notes has often been crit­i­cized for its some­what staid user inter­face. Accord­ing to IBM’s Bis­conti, in cre­at­ing Han­nover, IBM paid atten­tion “to not just the user inter­face, but the user expe­ri­ence.“

Okay… So does that mean I’ll have my choice of dis­eases as themes for the user expe­ri­ence of my col­lab­o­ra­tion envi­ron­ment?
Accord­ing to Ken Bis­conti, IBM Lotus vice pres­i­dent of Work­place, por­tal and col­lab­o­ra­tion prod­ucts, “Through improve­ments such as con­tex­tual col­lab­o­ra­tion and sup­port for com­pos­ite apps, we’ve gone above and beyond sim­ple UI enhance­ment”.

I think sim­ple UI enhance­ment is exactly what Ken and his team should focus on for the next sev­eral years, since they have so much oppor­tu­nity for improvement.

While looking around inside the Sharepoint documentation, I found this tasty snippet that explains a great deal about the way Microsoft approaches information architecture, probably design and architecture:
“Creating an effective category structure requires planning and some understanding of how others might organize the content.”
Yes, that’s right – you only need SOME understanding of how others MIGHT organize the content. No need to get the right people, even – anyone off the street will do, as long as they are clearly a member of the group ‘others’, so maybe even the neighbor’s kid would be fine.
Besides, I’m sure the inconvenience associated with trying to develop a decent information architecture informed by knowledge of users’ mental models would probably get in the way of all that planning that’s so important to the success of your portal project.

Related posts: