Re: [platform-help-dev] re: Eclipse help system requirements

[khalsted@xxxxxxxxxx]

Re: Home vs. Collapse All
You're right, it's similar but different. And the functionality requested
was specifically the collapsing type of functionality. With "Home", I would
expect that it would take me to the "top", but that any expansion I had
done would remain open (for example, in other infoviews, a la V1), and that
the default home page would be shown. That's not what they want. They want
to keep the current content page (if possible), but start from fresh
navigation.

Re: progressive context disclosure
Usability problems -- Then we should have some UCD folks look at it!
And, yes, it would be much nicer the context was handled automatically --
less work in setting it up.

Kari Halsted
User Assistance PDT
IBM Canada - Toronto Software Lab
(905) 413-3331 / tl 969-3331 / D3-238

The more I want to get something done, the less I call it work.
                   - Richard Bach


Dorian Birsan/Toronto/IBM@IBMCA@xxxxxxxxxxx on 12/10/2001 03:01:57 PM

Please respond to platform-help-dev@xxxxxxxxxxx

Sent by:  platform-help-dev-admin@xxxxxxxxxxx


To:   platform-help-dev@xxxxxxxxxxx
cc:
Subject:  Re: [platform-help-dev] re: Eclipse help system requirements



Kari,

Would a "Home" button be more appropriate then a "collapse all"? There is a
slight difference, because Home usually means the initial state of the help
viewer, not necessarily the closing of all branches of a TOC.

Re: progressive disclosure of nested contexts:
Yes, this is better than what is currently done, even though may present
some usability problems (your users are already divided on what the UI
affordances should be like). I assume you expect this navigation through
context to be automatically handled by the platform, without developers
(code or ID) having to specify the list of nested contexts, or you want
developers to control what the nested list is?

-Dorian





                    Kari

                    Halsted/Toronto/IBM@IBMCA       To:
platform-help-dev@xxxxxxxxxxx
                    Sent by:                        cc:

                    platform-help-dev-admin@e       Subject:     Re:
[platform-help-dev] re: Eclipse help system
                    clipse.org                       requirements



                    12/10/2001 01:11 PM

                    Please respond to

                    platform-help-dev






Greg,
Here's some details on the feature requests:

<kari> - Expand/collapse all for nav tree  </kari>
<greg>
Can you elaborate on expand/collapse all in terms of the users actions.
</greg>

Suppose the user has been clicking around in the navigation tree, and it's
expanded quite a bit, so they've lost sight of where they are. They just
want to "start over".  A "collapse all" button collapses all the nodes in
the tree, so that you're back to the beginning, with no nodes expanded. If
the user has done a lot of clicking around, this will save them a lot of
extra clicking just to close everything up.

"Expand all", I think, is a less important feature. It would expand all the
nodes in the tree so that the entire TOC is visible. I don't think users
would use this as much as a "Collapse all" button, but it seemed a logical
companion. If I had to choose one or the other, I'd pick having the
"Collapse all".
------------------------------------

<kari - A visual cue on UIs that there is context-sensitive
      help available  </kari>
<greg>
This one is actually not part of the help system. It's provided by the
platform ui itself.
Can I encourage you to post your design suggestion to their mailing list.
When you...can I persuade you to also include any pictures/drawings
showing visualizations that you might recommend. I am sure they would be
interested in the input.
</greg>

I thought that might be the case. I will re-post this information.
Including a drawing is a great idea -- will do.
------------------------------------

<kari> - higher/lower context sensitivity on infopops
      (e.g., an arrow on an infopop for a field that will
      take you to the wizard's infopop)
</kari>
<greg>
 I think I know what you mean here but can you elaborate.
FYI - currently the F1 support generates/supports nested contexts.
Unfortunately these have been identified as a real source of confusion and
annoyance. In 2.0 the plan is for a more static F1 context id, although
there are some thoughts a couple of us have had offline about extensible
references which we'll post when I can find a few seconds.
</greg>

I know about the nested contexts, and I agree that they are confusing and
annoying, and the removal of that "feature" is welcomed! This idea comes
from some feedback from users/writers who said that sometimes they got an
infopop with very specific info about the field they were on, but they
wanted more general info about the page they were on, or the wizard they
were in. Some people expected that if they pressed F1 again (i.e., when
there was an infopop already open) that they would get an infopop about the
object next down the containment stack (the object that contains the
current object). Others thought a good idea would be a little arrow button
on the infopop that would open the infopop for the object next down the
containment stack. Users just need some way of moving the infopop context
from a specific context to the more general context. Does that help
explain?

Kari Halsted
User Assistance PDT
IBM Canada - Toronto Software Lab
(905) 413-3331 / tl 969-3331 / D3-238

The more I want to get something done, the less I call it work.
                   - Richard Bach

_______________________________________________
platform-help-dev mailing list
platform-help-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-help-dev



_______________________________________________
platform-help-dev mailing list
platform-help-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-help-dev