Time for a Recount?
Mitch responds to
the Count the things that count blogalogue
that Ross Mayfield and I conducted earlier this week. On Monday, Ross had suggested,
in regard to the rating of experts,
- A rating is a price. We define a good and
deliberate over its value through signals. Sometimes we express
price not for transaction but to communicate value in its simplest
form (a guy at Stanford won a Nobel Prize on this). A price
is the simplest method of communicating value.
- A rating is a mode
of communication. What I value when. When
I send a smiley to someone, its a rating.
- A rating is a signal of trust. Whom
I value when. Trust is credit
and credit is priced.
On Tuesday, I harped
on proprietary data again,
Proprietary Data is the Basis of Tyranny
Perhaps we
need a systems approach, where we conceive a model transaction, one
that serves both parties equally, and removes the data dominance
factor. Of course, that's the purpose of our little design study.
We think we've come up with the 6 essential states in every transaction
(Discover, Identify, Specify, Negotiate, Invoice, Evaluate); and
we
think we've identified the Atomic Elements of transactions (People,
Products & Tasks).
If we're right, and our standard transaction
model simplifies selling and buying, then it might lead to more
and better buying and selling.
In any
event, we'll be counting some things that haven't counted before. Like
Quality ratings.
Flemming, still jet-lagged, gave
the post a thumbs-up but Mitch urges
us to not repeat the errors that have marked so
many endeavors: Establishing technical standards that enshrine data, or a
way of thinking about it, that becomes dogma. The dogma then dooms the participants
to follow the old flawed patterns, perhaps not even realizing what assumptions
are baked into their enterprise:
My take is that this is all great thinking, but we
need to keep clearly in front of us the idea that human relationships
is what we are talking about. The technology is a nice-to-have accelerator,
but it can be profoundly alienating. Technology, because it is usually
deployed en masse is a blunt force instrument that treats everyone the
same way, especially within the confines of a small group where starkly
different beliefs and styles of learning and communicating come into
sharp conflict.
There is no doubt in my mind or any manager’s that
an organization should pick tools that enforce its priorities to some
degree. It would be
impossible to cook a meal in a kitchen where knives were forbidden and every
company, because they do largely deal with the manipulation of information,
needs to define the range of data it will try to process. So, some dogma
is a very good thing. The very act of defining an organization requires managers
invent a bit of dogma, a dollop of determinism in an otherwise chaotic environment—after
all, we can’t be in the business of doing everything. A deterministic
system is purposeful and supports goal-setting.
The mistake would be to get locked into those goals by a technology infrastructure
that constantly enforced initial-state biases. If, after achieving your
first-year goals for establishing internal competencies and product development,
you
had to go back and spend a year and a large amount of capital to retool
your company for delivering its product or services to the market, instead
of
having these capabilities be an implicit result of your first year’s
efforts, your company is not likely to succeed. Think about how many times
your company or a company you know has had to retool information technology
to support new processes and the consequences of setting and forgetting
dogmas becomes painfully apparent.
I agree with Mitch, and not just because he is a valued advisor
and the expert entrepreneur in the booth of this quiz show. The failure of
organizations to understand their data strategies is one of the reasons they're
so frustrating to work with and for. But this design study could easily repeat
those kind of mistakes, even if our aims seem more open. So I want to address
Mitch's points in serial fashion to
give us
a
chance
to question assumptions behind the current Xpertweb design.
Let's start at the top: "we
need to keep clearly in front of us the idea that human relationships
is what
we
are
talking
about" To which I respond with a firm, "Well, yes and
no!" (Never equivocate on important points...;-).
Yes. I'm inclined to
wax rhapsodic when glimpsing a future with a kinder, gentler economy
based on human connections across the globe or around the corner. And
I do believe that our current structures devalue the creativity most
of us pour into our work and the deep and vital relationships we form
with partners we transact with. And I think Xpertweb improves the chances
of forming and maintaining those relationships, compared to proprietary
hierarchies, which would be the most social benefit of our socialware.
No. However,
there's also a pragmatic edge to getting things done, which is why
an Object-Oriented, "Open Resource" economy is so attractive,
where the obvious expert is easy
to find, easy to engage and easy to pay. Just as programmers can plug
other people's code objects into a program, so do we need to plug other
people's expertise into our activities, on-the-fly, and get on with
our
day. When I use a piece of open source code, admirable for its elegance
and price, to do something otherwise impossible or lengthy, it's
just a tool that I use without forming a relationship. As my long-time
friend, client and author, Jerry Vass teaches
his Fortune 500 clients, "Your company may be impressive, but the
buyer doesn't care if the seller lives or dies, as long as he doesn't die
on the premises."
Mitch has challenged us to strike the right balance between
over-determining behavior or making the design so loose that there's no value.
There's no way to respond without specifics, so
please indulge a detailed overview of the Xpertweb approach, including our
allowance for flexibility. Maybe you'll have some ideas about
whether it's too rigid or loose, and how it could be improved.
The Xpertweb Bottom Line
All we're really after is to elicit a rating from each transaction
and to make it indelible in the public record. The rating needs to be both
quantitative (1-99%) and qualitative (a written comment). We all know that
we rarely fill out rating surveys after the fact, so the rating must be required
at the moment of payment in the invoice, perhaps with an incentive to the
buyer.
Therefore, at a minimum, we need to provide an invoice form.
Ideally, an invoice should summarize the transaction so the buyer can make
a rating
based on more than memory. That means it's useful to capture the history
of the transaction. We decided to provide some basic transaction forms and
a dead-simple data capture system for the transaction details, including the
one we care
most about, the final rating.
Last time, I revealed my horror of proprietary data–that
both parties to a transaction need all the data so they are full peers. Flemming agreed and
so does Mitch, if we strike the right balance between rigid and useless.
That's what drove the decision to give everyone the same data
tools and
to require
a web server for both parties to each transaction. It was the only choice
left standing after all the other choices wouldn't work. Data that's not
on both web servers is suspect, since one of the parties may have changed
or deleted something. Validation is by duplication.
When you're designing a campus, put the
sidewalks where the grass wears out.
The 5,000 Year-old Flow Chart
How do we know what forms to provide to lead up to the one
we actually care about, the evaluation? On March 18, I suggested that
we have an ancient model to follow for the Xpertweb transaction flow:
It's obvious the transaction record must reflect the
real-world dynamics of the special kind of conversation called a transaction,
which, for the same 5,000 years, has had six distinct stages:
- Discover Find a seller to deal with
- Identify Select the specific product
- Negotiate Resolve
delivery location, timing, quality, etc.
(often a back-and-forth between buyer & seller)
- Commit Buyer and Seller
commit to the negotiated terms
(Goods or services are delivered between steps 4 & 5)
- Invoice Seller
reports the actual results and amount due
- Evaluate Buyer rates seller and
vice versa
(this is the vital metadata of relationship, now made explicit rather
than as a general impression. Or worse, hidden from
the market by the seller )
Notice that Xpertweb doesn't attempt to describe the
actual work nor to manage the payment details. Work details
are too specialized for our generalized
data capture, though it's described by the "Productid.xml" metadata
and can also be discussed in task remarks.
As for payment,
that's left to whichever
means the parties prefer, though some third
party payer is required, one which sends a confirming email to buyer
and
seller upon
taking irrevocable
responsibility for payment. Third party payer
commitment closes
out the transaction.
Why Do We Need a Flow Chart?
Transactions are asynchronous.
- The buyer, having discovered a
vendor and a product,
- identifies the buyer's interest and basics
like delivery details.
- The seller must, at a
minimum, agree to the delivery location and timing, but may need more
details–color, size, scope, etc. Those negotiations are
related to the parties' needs and the product type. Whether
the negotiation is complex or just the seller's simple "works
for me, I'll do it",
we need to provide a form for the dialogue.
- Naturally negotiations
end upon the parties' definitive commitment.
- After the work is performed, the seller submits an invoice–the
form Xpertweb really cares about,
- a)...where the evaluation by the buyer is recorded,
in numbers and words. followed by payment using mutually agreeable means.
b) After payment, the seller evaluates the buyer's role in the
task.
All those things happen in the real world, but the evaluation
is maintained privately by each party, and then not explicitly. Xpertweb
intends to make evaluations explicit and public.
Okay, we think we're clever enough to design those forms,
but we need a data store that's flexible and searchable. There are few examples
of open, pure-XML data stores. There's
a
lot of data
on web pages, but it's hard for computers to organize and aggregate
web info for us, so they're not really data. A lot of "real data" are
served by web pages, but the data are buried in proprietary data bases that
Google
and the rest of us can't get at without permission. A Peer Economy must be
a permission-free zone.
So, we found ourselves going the eccentric route again. Xpertweb
users will store their data on their own web servers, in pure XML format.
It won't require UDDI or SOAP or XML-RPC or anything else exotic to get at
user records. You can do it with a browser or a search engine. RSS will provide
pointers to help people find what they want.
Why is Data So Difficult?
There are two ways that data systems lock their users into
the kind of rigid structures Mitch is warning us against. The data structure
itself may not be malleable or the data language may make it hard to design
and integrate new forms to gather inputs (old or new) for the database and
display
the
gathered
data.
Most companies maintain a little bit of info about a lot of
people. Xpertweb users need a lot of data about relatively few people. So
instead of using a huge array to store the data, An Xpertweb site will keep
three kinds of small datasets:
- A person type data set for the owner of the site.
("youruniqueid.xml")
(this as complete a Digital ID as the owner wants to make it).
- A product type data set for each product. ("Widget1a.xml")
- A transaction type data set for each transaction.
("sellersuniqueID.buyersuniqueID.numberofunixsecondsatstart.xml")
Within each of those datatypes, the trick is
to have just enough structure that the data needs are served, but to avoid
freezing
that structure. Let's think about data
strategy. Every data design specifies data types (first
name, last name, city, zip, etc.) and data forms (rolodex card, product
sheet, etc.).
The
problem with the data tools we're used to is that, as Mitch
suggests,
they're too rigid:
- arbitrary structures–not enough design input from
on-the-street business units.
- Specialized languages and tools–hard to find experts
to maintain or modify
- Obscure code–dependent on continuing
involvement of a few staff or consultants
Those factors combine to make it difficult to do what every
data structure should: facilitate new types of data and new forms for
novel inputs and display of the old and new data types.
This design study tries to avoid those traps. The design is
as public as possible and welcomes pushback. We're describing only the data
structure and the three data types. Data collection and display will
be by plain old HTML forms using whatever CGI language that works. There
are a few required datatypes that are obvious, but any optional datatype
is allowed. For starters, we're providing free PHP code which Nobody
will own, Everybody can use and Anybody can improve,
like the Internet itself.
Because the data forms are HTML, there are thousands of people
able to modify them or add new ones. HTML skills are possibly the most common
computer specialty, so form design and modification can be learned or hired
out reasonably, probably as an Xpertweb-rated specialty.
Aha! you say. There may be tens of thousands of HTML-aware
people with Front Page or other editors, but only a small fraction of them
know how to design the code to equip HTML to save or display data.
That's the sad truth, esteemed Effendi. Where's the data design
tool for the rest of us that will let someone's niece or nephew build or
modify data forms? I saw an article today praising a barebones 300 page book
on web data that he used every day, rather than the several thousand other
pages on his shelf.
We call it XWriter and it will be part of the code we'll
provide to every user.
XWriter
will
let
any
HTML
author
add
the
required
data calls (inputs or display), working with any of the six types of HTML
input widgets (text box, text area, value list, value popup menu, check box
and
radio buttons).
XWriter 0.8 was built by Hurai Rody and Flemming will write Version 1.0
using techniques he's used on other projects.
So What's the Point?
If we're doing this right, these are the most likely reasons:
- Data structures are restrictive when the users don't help
design it.
- A lot of people are chiming in on this one, and every one
of those people is a buyer and a seller of stuff.
- Data structures are rigid when the data formats are obscure
and rigid.
- Structures are standardized and data sets are small, simple
and publicly visible
- Datatypes are hard-wired by designers with no sense of
the business logic
- Required data types are only the obvious ones (name, XWURL,
XWID, etc.)
Optional datatypes may be added at any time by listing it in XWriter.
- Data code is difficult, often obscure, with few skilled
enough to create or maintain forms.
- Xpertweb is based on HTML, the most common presentation format, with XWriter
available to add the PHP data calls.
This has been a lot of detail, but it's the only way to find
out if we're headed down the slippery slope Mitch warns us against.
Isn't the reason there are so many poor data solutions that the owners aren't
willing to dig around in the details? I've consulted on data projects and
the users are so rarely involved, it's no wonder they aren't ideal. Many
bloggers and bloggees have experienced detail aversion first hand, and it's
not a pretty sight.
Fifteen years ago when
I funded and later tried to run the Dynamac Computer project,
we would send an extra stick-on keyboard key with each computer. It was
red with white letters: DWIM. Do What I Mean.
It's what every database customer wants and it's what most data designers
are forced to guess at. We hope that we're looking at enough details to avoid
the DWIM trap, and we hope you will too.
Thanks.
1:24:50 AM 
|
|
