[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Top 10 Trauma
- To: <drexler>, <xanatech>
- Subject: Top 10 Trauma
- From: Marc Stiegler <marcs>
- Date: Mon, 19 Feb 90 00:32:05 PST
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
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
With these filters on the issue list, the Top 10 Trauma for Xanadu
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
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
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.