Top 10 Trauma

[Marc Stiegler <marcs>]

Well, it's done: I completed first pass assessment of all 271 issues 
from the capability review. Actually, there were 274 by the time 
a few trailers got added.

The review has an organization and structure the likes of which 
has probably never been seen in Xanadian history.

Each issue, in addition to receiving a unique ID number (actually 
a tumbler), has an Importance (hi, medium, or low), a Difficulty 
(hi, medium, or lo), a date when Resolution Is Needed By (now, 
prealpha, alpha, prebeta, beta, or shrinkwrap), and a Troublesomeness 
(hi, medium, or lo). A high troublesomeness means that at least 
two Xanadians will howl in pain no matter which of the known 
alternatives we select.

Each issue also gets an Urgency. The Urgency is calculated by 
multiplying the other fields together, using a 1 to denote High, 
and a 3 to denote Low, with resolution dates "now" through "shrinkwrap" 
assigned values 1 through 6. So, an Urgency of 1 would mean that 
1) we need to decide immediately, 2) it'll be hard, 3) everybody 
cares, and 4) nobody agrees. An Urgency of 162, on the other 
hand, means that 1) we never have to decide, 2) it'd be easy 
anyway, 3) nobody cares, and 4) everybody agrees. 

The good news is, there are more "162"s than there are "1"s. 
Indeed, no issue got a rating of 1, though there are several 
issues with ratings of 2.

Each item also has a Current Solution, i.e., what we would do 
this afternoon if we had to solve the problem right now, if this 
were the only thing holding us back from shrinkwrap. I look forward 
to upgrading the Current Solutions as we come up with better 
answers. Of course, there is a Task Leader assigned for each 
issue, the guy who is stuckee for figuring out those better answers.

I wrote all this stuff in a Hypercard stack. I am putting the 
stack into my Tops folder "current work" for anyone to peruse 
(it'll probably be there by the time you read this message). 
I also loaded all 274 issues into a database, so I could sort 
them and query on them in various ways. The database is also 
in "current work", so you can perform your own sorts and queries, 
if you can figure out 4th Dimension.

If you can't figure out 4D, don't worry. I'll be distributing 
personalized lists of issues to everyone, with all the tasks 
you have been volunteered for as Lead (of course, one of the 
opportunities you have as Lead is to persuade someone else to 
be Lead :-). Jo, I'll bring you a copy of the database the next 
time I'm in Sausalito. 

Well, I can hear everyone panting with anticipation. What are 
the really important problems? 

Let me say a few words about the algorithm I used to pick the 
10 Best here. The algorithm is nontrivial when there are 271 
fine, strapping young issues to choose from.

First, I noted that a lot of these issues don't get seriously 
activated till Beta, when when we have some real live users, 
who will be the final arbiters on many issues. 108 of the issues 
fall into this category (or else fall into the shrinkwrap category, 
which catches everything that comes after Beta). So I put those 
aside for the moment.

Perusing the remaining list, I concluded that issues were pretty 
tame unless they had urgencies of 12 or less. Furthermore, if 
the issue didn't have a high level of troublesomeness, we could 
just leave it to someone to solve and be done with it.

So I pruned the issues by taking just those with an urgency stronger 
than 12, and a high troublesomeness. This brought us down to 
32 issues.

One of the ways of getting a "high" rating for troublesomeness 
was if I didn't understand the issue any more. I also threw those 
out of my collection; I'll review those unclear issues in more 
detail, but I'm pretty sure none of them are killers (the killers 
I remembered quite clearly :-)

Some of the issues overlapped, as they examined several aspects 
of the same underlying issue. Those I lumped together into single 
issues.

With these filters on the issue list, the Top 10 Trauma for Xanadu 
are:

1) The relationship between filtering by link type and endorsement 
isn't fully satisfactory (or at least it wasn't at the time of 
the review; dean may have already fixed it). You don't really 
filter by link type; you filter by endorsement. Since the type 
and the endorsement are not the same thing, you can get errors 
and/or intentional abuses. The distinction between the two also 
raises some difficult issues in the frontend, such as, does the 
"From" field in the header bar show the endorsement or the edit 
club? 

2) We need to figure out what it means when people do strange 
noncontinguous selections: what if the guy selects one headline 
in the flat view of an inclusion list, then selects a few characters 
from another headline, plus a few characters from one of the 
references, plus a whole document reference? What if he pastes 
this mess into the middle of another headline? Yech! I love Ravi's 
proposal to not allow it; but for reasons which I won't go into 
here, that is not quite viable.

3) Do we need user-traversed embedded links in Release 1 of this 
particular small-workgroup, office-oriented product?  This is 
of course a traditional disagreement, like a stick of gum that 
retains its flavor no matter how much you chew it. 

4) There are a bunch of archiving issues, all of which belong 
to dean, all of which we have intentionally postponed thinking 
about till we had more of the system working (though as dean 
and I were discussing a couple of days ago, he needs to get started 
on this...now, according to the PERT chart. Of course, the PERT 
chart also says he needs to be done with fm now--and this is 
even more important than the archiving).

5) Converting the raw information from a Xanadu version comparison 
into a markup diagram is a problem of unplumbed depths. Every 
time I think about it, I find more terrible wrinkles. It gets 
worse when I think about using Xanadu versioning for nontextual 
objects. I think we may have to build some very sophisticated 
tools on top of Docs & Links to make it possible for mere mortal 
programmers to use it without a year of research.

This is actually something I might be able to make a technical 
contribution on. No one else has the time to think about it (or 
rather, no one else ought to have the time to think about it--we 
have plenty of wonderful stuff crying to be built, we need to 
build it!). But I have started using my driving time when I go 
to Sausalito to contemplate it.

6) We need to figure out a minimal set of formats for storing 
pictures that we can then interchange among all three frontends. 
We have rightfully postponed figuring this out; but eventually, 
it will be a hard problem.

7) In using plain old normal text, some people here have a fierce 
desire to store style information "right", so that people won't 
get hiccups as they shift from pcs to macs to suns. There seems 
to be a Xanadu contingent that wants to do this the "right" way 
even if the "right" way is incompatible with the standard technique 
used on Macs (and on PCs with Windows, last I saw) for picking 
a character style off the menu. All kinds of truly intense battles 
could arise on this terrain. Hugh tells me that significant progress 
has been made on this since the capabilities review; I sure hope 
so.

8) We discussed not implementing historical trace for Release 
1. In keeping with the philosophy of doing the minimum amount 
that would be wonderful, this is an interesting opportunity for 
shrinking the amount of work we need to do before shipping a 
product. I can already hear the howls of agony (one of the howls, 
by the way, is mine :-). Anyway, it deserves further consideration.

9) There are a number of issues associated with multiple editors 
for a document (such as, when do you grab the bert? or worse, 
when do you release the bert?), all of which go away if we make 
it one editor per document for Release 1 of this particular frontend 
that was designed for small workgroups.

10) Deleting a document is an act of terrible ramifications in 
a hypermedia system. My favorite subproblem in this lump is, 
suppose you delete a document which is the only bridge through 
which connections flow from one part of the information pool 
to the other? Now you have two disconnected pools; thou shalt 
never find everything ever again, unless thou ist very lucky. 
Anyway, I can now see why implementors of hypermedia systems 
would prefer, for technical reasons, to bar the user from deleting 
anything, ever. Fortunately, we are wise enough to implement 
this system for users, not for implementers :-)

11) Multi-bert endsets: what do they mean, what do you do with 
them, and how do you survive them in this particular frontend 
designed for small work groups?
 
12) There's a lot of stuff in the InfoFactory frontend. It is 
no where near as complicated as Word 4.0, but it certainly isn't 
as simple MacWrite Release 1. The most important improvement 
we can make is to reduce the number of choices and shades of 
meaning running around the screen. I think everyone agrees about 
this. This agreement will produce curious value-system impacts 
on everyone, since there's not a person in the building who doesn't 
have at least one Favorite Feature that is missing from the InfoFactory 
that he knows he Must have.

Yeah, there are 12 issues in the Xanadu Top 10. So who said I 
could count? :-)

All in all, we didn't uncover much in the way of terrifying surprises: 
for the most part, the people who need to worry about these issues 
have been aware of them for a while. With a little time in intensive 
care, I'd say the prognosis for Xanadu is pretty good.

--marcs