The Mitch is Back

Mitch generally agreed with yesterday’s blow-by-blow dissection of Xpertweb’s measures to avoid hardening of the data arteries. But he adds four important points on the specific biases that are usually embedded in enterprise data design. These are the biases to avoid by providing for gradual system evolution.

Participation and modality biases, that define how and when users should contribute to the group’s dialog; this may take the form of forcing people to use a form or that they learn some esoteric mark-up language to participate—maybe some of your team is most comfortable using email, but cannot do so to submit information to the workgroup application (why do they have to change? Because a programmer said so? Not a good enough reason when those people earn $80,000 a year already and do just fine communicating by email);

Which is why Xpertweb v 1.0 will be able to read your email (or a dedicated email account). It’s not certain though whether the messages will be organized in a way that a script can make sense of it. Certainly they will if they’re script generated, but you never know about those pesky humans.

I’ve always felt that modality bias is the greatest challenge in networked human interaction. Modality is the mode of interface dictated by the software’s User Interface and data categories. Most of us are comfortable with email, as Mitch points out, though we forget how recently we’ve adopted that mode. When you force people into a new modality, you’d better have some damn good reasons, which is not always the case.

But the web’s theme the past few years has been about unstructured content becoming structured. Web pages like this are unstructured. Even if the content is worth something (unlikely as that may be), it’s hard to find and aggregate the nuggets to establish meaning, because HTML is a presentation tool, not a data-tagging tool. That’s what led to the formulation of XML and XHTML, which requires authors to tag their content by categories. XML adoption has been slow, except by enterprises using it to encode data between two otherwise uncooperative data bases. It’s a pain to tag your data, which is Mitch’s point.

Just as so many mastered the email modality in the early 90’s, so have we mastered online purchasing in the later 90’s. It seems to me we’ve become as comfortable with forms used to buy things on line as we have with the familiar three-paned email interface. So, if the Xpertweb forms can look a lot like other online experiences, we’ve got a shot at providing a friendly user modality.

Semantic biases, evident both in the range of options available for categorizing information, from labeling every new topic as a “problem” to be solved instead of a business opportunity (this evolving from the quality-assurance based practices of software programmers) to limited ranges of choices in pop-up menus that prevent the group from straying outside the well-defined lines that the program lays out;

Bingo! Labeling is a huge problem, since programmers can’t get the lingo and categories right without enthusiastic collaboration with the people who will use the system. Such collaboration is rare because users have no interest in pitching in on the design until the piece of dreck is switched on. I can think of only three ways to reduce the semantic bias problem:

1. Rely on language and processes so well-established that they’re naturally comfortable.
2. Provide some metadata describing the terms as they’re presented (the tooltips approach).
3. Provide a way to evolve form design and add or redefine datatypes easily.
   (without needing permission or great expertise)

Time and skill biases, based on the presumption that every user has the same amount of time each day to participate in a group project to assuming that it takes everyone the same time to perform chores in the interface (that they all have the same skill level with the technology);

Here’s evidence of the steep gradient between the early adopters and the rest of us. The early adopters see the value of the new tools and are adept at responding to new modalities, unlike you and me. Too bad they’re never around when you need some guidance. Fortunately, time spent is a matter of skill, and skill is usually a matter of time and patience. I learned in the Air Force that there are brilliant pilots and the rest of us, but time in the seat is the great skill leveler–most pilots are average pilots. Motivation is the skills leveler. If you have a strong reason to master something you will. Think of all the grandparents who’ve mastered email to stay in touch. Now they’re even exchanging pictures! Money can also be a strong motivation, and Xpertweb has some explicit rewards built into the system to inspire enthusiastic mastery of the bit of procedurality that can’t be avoided.

Historical bias, the preservation of outmoded knowledge because of the rigidity of technology. What if your company has moved from making buggy whips to airplanes and the software you use still is designed for a buggy whip company? Often, it is the failure of software to evolve with the organization that makes it utterly useless—this has happened in many media companies, where digital technology was designed for outputting paper or television signals and has locked companies that could be exploiting the Internet and on-demand multimedia networks into outmoded business models.

All of us are seeing Mitch’s historical bias example. Consider how hard it is on the RIAA. Heh.

Historical bias is assured when the data structures, datatypes, data forms and output protocols can’t be evolved to keep up with the people evolving away from the system. But if someone is motivated to fix the problem and the means are easily engaged, then the changes will be done and the curse of legacy avoided.

I sense that Mitch has concerns about the predetermined stages of an Xpertweb transaction: Discover, Identify, Negotiate, Commit, Invoice and Evaluate. The reason to have discrete stages is because the purpose is to sensibly organize work, without requiring an organization. The asynchronous imperative of a transaction record requires that the data needs of each stage be met before moving to the next stage.

• The evaluation (our core value) can’t be captured until the invoice data is entered and presented
• The invoice can’t be presented until completion can be recorded
• The work can’t be committed to until the order details have been negotiated
• The details can’t be negotiated until the buyer’s preferences are recorded
• The buyer preferences can’t be entered until a service/product is identified
• The item can’t be identified until the Expert is discovered

At the risk of being doctrinaire, we feel the need to provi
de at least that much of a skeleton for the transaction record. If Xpertweb can avoid being haunted by that skeleton, it’s because all data and structures reside at the level of the user. Some think the idea is unworkable, but that’s a question that will be solved simply by seeing if it works. Similarly, many experts once wondered why you’d want bit-mapped displays so you could see formatted text onscreen. They also wondered why in the world you’d want to see formatted text.

Data for the rest of us is similarly untried and, by many, still unsought. Our design indeed raises problems. Unlike a central data store, there’s no team to manage and maintain it. It’s not optimized for compactness and speed. It assumes the proper functioning of the Xpertweb scripts on each user’s computer. It assumes that there are enough people who will learn a new (to them) technology and a new way of dealing. A determined techie could find another half a dozen objections.

Living With Diversity

We never set out to create a weird data architecture just to be different. We had no choice, since all conventional methods rely on the kind of centralized data hegemony that would eventually pervert our purpose. Xpertweb’s distributed data store is kind of holographic, present on at least four web sites (2 parties to a transaction and their two mentors). The mirroring of identical data on those sites imputes validity. Validation is further promoted by a validation tool built into every installation. This tool verifies the file structure, to make sure it conforms to this model. It also provides a schema to validate the XML structures, and to validate other sites, on a schedule or on request, so your mentor’s site is continually validating your site’s structure and file conformance to your schema.

The schema provides for the datatypes that are obvious and any optional datatypes the owner may designate using the XWriter tool. These would most typically be added to describe attributes of a service or product. Another compelling reason for adding new datatypes is to transform your ID.xml file into a full-fledged Digital ID using Liberty Alliance protocols to become your own Identity Provider.

The Open Source Haven

In facing these challenges, the Xpertweb model is fortunate to not be a business. If it were a business, we’d be capitalized to hire a crew of programmers and arrange for office space and computers and furniture and all the rest. Development would be done in secret so competition wouldn’t get wind of our gazillion dollar concept. Naturally we’d have a business plan to promise a Return On Investment with a stated marketing budget and rollout and the server farm, etc. Once the code was “done” (always a more-or-less state), we’d have a limited horizon to satisfy the nervous investors, so we’d move heaven and earth to inspire massive adoption by our target demographic. As with most new software, despite the promising number of enthusiastic early adopters, the press and the public would note that it’s interesting and worth looking into some day and would go back to business as usual.

Then would start the decade of dimming hope and rising anguish as the shrinking team of stakeholders tries to wring some value out of what has become an old idea that didn’t quite work out.

Xpertweb has no burn rate and no central software or servers. It will put its genetic material out there, with the means to further propagate it. Starting with just six users and spreading slowly at first, we expect to wring it out, make a few adjustments and then, as they say, let ‘er rip.

Naiveté

Perhaps we’re naive to think that ordinary people will choose to, or even can, master these new skills. But it seems less naive than assuming that our current skills and hierarchies will spontaneously inspire higher productivity and individual work satisfaction.

9:51:26 PM