[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Comments On Dean's FE Proposal
- To: <marcs>
- Subject: Comments On Dean's FE Proposal
- From: Eric Dean Tribble <tribble>
- Date: Wed, 20 Sep 89 16:49:58 PDT
- Cc: <us>, <tribble>
- In-reply-to: <Marc>,04 PDT <8909202146.AA05605@xxxxxxxxxx>
The other function, which is newer
than any of the documentation, is to make visible the difference
between REFERENCED documents and CONTAINED documents. In the
new draft-in-production, the bubble
is either square or circular to denote containment or reference.
This distinction could easily be made. If we imagine the document
icons on the right, then a triangle/arrow takes you to a refeenced
document, whereas a bubble takes you to a contained document.
It is possible that we should not even have both contained and
referenced documents in Release 1.0; it is possible we should
only have referenced documents.
Thinking in terms of exemplars, if we can only do one, it should be
contained documents. Thus, our frontend demonstrates a feature that
none else can do, and one that we want our developers to understand.
However, I would like to have
a clear upgrade path to contained documents, since we will surely
want the distinction either in a later release or in a power-user's
version (InfoFactory Professional?).
We need to discuss containment vs. reference. I would expect
'professional' users to be far more likely than 'amateurs' to use the
reference model, so again, the baseline should be containment.
The bottom line on this
is that we will eventually need an icon the size of the original
bubble icon, somewhere on the screen. What we eliminate by moving
the open-document operation to the dot is NOT the bubble, but
rather the dot, which was pretty inoffensive anyway.
You're almost right. The main thing we did was disassociate the icon
from the outline structure. In retrospect, that was the primary thing
that bothered me about it.
We also "fix" it so that, when you single-click to put a check-mark
in the icon spot, you wipe out the indicator of whether the document
is contained or referenced--a minor inelegance. You also lose
the indicator of whether the document is empty or not--another
minor inelegance. But a lot of little inelegances add up to a
This was one of the exercises for the reader. Forget checkmarks. We
just represent selection in the obvious way of reversing the icon (or
outlining it, or...).
This is the BEST case; we still have to deal with other parent-only
operations besides open-document.
I came up with some other ways of dealing with this. I still don't
know what you want this for. Until I do, I can't integrate it nicely
with the rest of the design.
On the opposing side, we can observe that no existing outliners
have parent-only operations.
Being merely as good as everything else in the world would be a big
Another reasonable observation is that parent-only operations
are not frequent. However, when you want one, you want it really
This won't be true if we have the right set of other operations.
Many many people out there really hate outliners (roger
is our best local example). How much of that hatred is caused
by the following sensation? On those rare occasions when you
DO want a parent-only operation, it provokes surprisingly fierce
anger, because you can SEE what you want to do, it's RIGHT THERE
staring at you, but YOU CAN'T DO IT. Instead of just grabbing
the parent and yanking it to the right place, you must first
select all the children, drag them up to the adjacent parent,
and THEN move the sucker. Needless to say, people make frequent
errors--they grab the parent, then remember that the children
are coming along for the ride. So they then reposition the parent,
and THEN follow the "legal" sequence. This still happens to me,
How often are these operations in which you want to promote/demote
items without changes the veritcal location of any of their
children/siblings? If that's not sufficient, then we still have an
advatnage by being able to easily select sets of children. You move
the entire family, then select all the children (a quick click and
drag) and move them back to the parent or sibling with which you wan
them associated. This has the advantage that we don't make policy
decisions about wehre the orphaned shildren should be placed.
Outliners earned their reputation for being too rigid with just
such clever behavior. I am desperate to make our system more
flexible than basic outliners, for this among other reasons.
The outline metaphor should add capabilities, not constraints.
Good philosophy. I would still like a specific example.
3) Assuming we will do single-header movement, how do we represent
a) Use a command-selection to get the parent alone. This brings
up a philosophical point: I do not believe that command-selection
works under hardly any circumstances. It is possible that More
HAS such a command selection to manipulate the header, I wouldn't
know, because I gave up trying to use the sucker without trying
this invisible possibility. Making it a command selection is
marginally different from not implementing it.
I disagree. You have a particularly strong aversion to shift keys.
If the documentation is adequate, then it should be easy to find. If
we use such extra selection bits sparingly, they should be easy to
find. I'm not advocating such practices, but for infrequent or
specialixzaed operations, they don't seem so abhorrent.
b) Expand the parent's triangle icon when there are children,
making 2 regions, one region for the family handle, one region
for the parent-only handle. I like some characteristics of the
concept--the parent-only distinction only appears when there
is a family there to drive a distinction. I am uncomfortable
with it in some way, but I can't articulate the issue at the
moment; I'll need to think on it. Anyway, using this approach,
combining it with the earlier discussion, our net reduction in
visual complexity with the new approach is that we got rid of
the column of small dots and now have occasional oversize icons
here and there in the view.
There are many measures of complexity. A major source of complexity
in the first design was having the triangle and the bubble in the same
location. I could never keep straight which was for which, and there
were no layout hints with which to figure it out. The rearrangement
saves us a lot more than a single icon. With the above proposal, the
shape remains the same , but it's real clear what selecting each icon
should do (if it's not obvious, then it's certainly mnemonic).
4) Looking at the new approach from a meta-view, it appears to
me that the main focus of this current proposal is a desperate
effort to reduce the triangle-plus-bubble next to the headline
to one icon, no matter what the consequences are for the rest
of the screen. This pair of icons obviously bothers everyone
else more than it bothers me. In my own mind's eye, the triangle
and bubble DO merge together, only to be resolved when needed.
Not quite. The set of distinction made visible by the two icons are
not quite right.
I am really inclined to believe the best solution is to find
a pair of icons that will seem to blend together in normal human
vision much as this pair blends together in mine. I will put
together a couple of proposals.
I'll believe it when I see it. I don't think they exist in general.
5) for making documents, we could just have a menu with items that
make links of some type to documents of some type. It might be
possible to make this extensible externally.