[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-help-dev] why does the help window have two toolbars?
|
Erik,
We are not planning to change the design in 2.0. See my comments.
>1. I thought Netscape 4 had some startup mechanism to open the browser in
>"kiosk mode" without the menu bar or toolbars. Did they remove that from
>Netscape 6?
Kiosk is only Netscape 4 on Windows thing. Netscape 6 has different
mechanism.
Help is not only viewed from the browser that help itself launches. To
view help in the infocenter mode, user will usually launch full browser,
point to the site. There is no chance to force kiosk mode in this
scenario. Help supports pluggable browser adapters. The APIs do not limit
what can be on the tool bar.
>
>Even if Netscape opens with toolbars, I would think that it's more usable
>to duplicate functionality than to split functionality between the
>containing window's toolbar and the contained HTML tool bar. To get to
the
>SWT toolbar, the mouse has to move much farther from the content links.
>Also, the user can't look in one place for the content operations.
There pros and cons having back/forward buttons duplicated in HTML tool
bar. After many iterations we decided to not have them. I doubt we will
change it in Eclipse 2.0, but we can reconsider post 2.0.
>
>By the same reasoning, shouldn't the print button be in the SWT toolbar
and
>off the HTML toolbar?
Functionality of our print button differs from browser's print button.
Ours prints the topic frame only.
>
>
>2. Regarding a link replacing the frameset, won't links open in the main
>content frame by default? If the content developer needs to open a link
in
>a full window, couldn't he or she target the link to a _blank window?
They can, but do not always do. We cannot prevent it, but should try to
minimize impact such links.
>
>In the rare cases where the linked resource reopens itself in the top
>window or where the documentation plugin contains legacy HTML that targets
>in the top window, couldn't the user open the right-mouse context menu to
>go back? Or, if the user doesn't know about the right-mouse menu,
couldn't
>the user always close and reopen the help?
They could. Back button is the probably the first thing they would try
using.
>
>What if a topic links to a resource that redirects to another URL? The
>back button will merely repeats the redirect. To get past the redirect,
>the user would need a back menu.
This is a different problem. There is a enhancement 13339 that has not
been implemented yet. It does not affect users that do not use our browser
adapter on Windows (other platforms, and infocenter users).
Because Eclipse doesn't provide a back
>menu, the work-around will still be to close and reopen the help.
Yes.
Why is
>the workaround more acceptable for this case than for the top window case?
The top window problem has more solutions, than redirect problem. After
the frameset is replaced, there is almost always a need to restore the help
framaset. After browsing the document redirects, user will not often try
to go back. All help frames are still available and will usually be used
for further browsing.
>
>My concern is that the SWT frame toolbar seems to make the UI worse in 99%
>of the cases without really doing away with a workaround.
It provides easy to find solution (the back button) to frame replacement
problem. It does not affect the redirect problem.
First, this is not 99% cases. There is other browsers that are used (other
platforms, infocenter). You can also provide other browser adapter on
Windows that does not have the SWT frame you do not like.
Second, if we also provide buttons inside the HTML, it will make UI look
worse in 100% of cases (unless one plugs in adapter that has no buttons).
Third, if we also provide buttons inside the HTML, and remove, these
buttons from Windows browser adapter, the adapter will be unusable with any
pages that have no JavaScript back/forward buttons.
>
>
>For what it's worth,
Erik Hennum
ehennum@xxxxxxxxxx
Bottom line: We have spent not ignored any of the issues that you raise.
We considered more scenarios, consulted usability teams, and agreed on the
solution you are seeing. It is a compromise and there is no clear good or
bad answer. Suggestions are always welcomed, and discussion will continue.
It is however my responsibility, to ensure that the design decision will
have overall good impact, and does not solve one issue at a cost of
another.
Konrad Kolosowski
Eclipse Help System
Erik
Hennum/Oakland/IBM@IBMUS To: platform-help-dev@xxxxxxxxxxx
Sent by: cc:
platform-help-dev-admin@e Subject: Re: [platform-help-dev] why does the help window have two
clipse.org toolbars?
05/17/2002 08:25 PM
Please respond to
platform-help-dev
Hi, Konrad:
Thanks for the explanation. Not to whinge, but...
1. I thought Netscape 4 had some startup mechanism to open the browser in
"kiosk mode" without the menu bar or toolbars. Did they remove that from
Netscape 6?
Even if Netscape opens with toolbars, I would think that it's more usable
to duplicate functionality than to split functionality between the
containing window's toolbar and the contained HTML toolbar. To get to the
SWT toolbar, the mouse has to move much farther from the content links.
Also, the user can't look in one place for the content operations.
By the same reasoning, shouldn't the print button be in the SWT toolbar and
off the HTML toolbar?
2. Regarding a link replacing the frameset, won't links open in the main
content frame by default? If the content developer needs to open a link in
a full window, couldn't he or she target the link to a _blank window?
In the rare cases where the linked resource reopens itself in the top
window or where the documentation plugin contains legacy HTML that targets
in the top window, couldn't the user open the right-mouse context menu to
go back? Or, if the user doesn't know about the right-mouse menu, couldn't
the user always close and reopen the help?
What if a topic links to a resource that redirects to another URL? The
back button will merely repeats the redirect. To get past the redirect,
the user would need a back menu. Because Eclipse doesn't provide a back
menu, the workaround will still be to close and reopen the help. Why is
the workaround more acceptable for this case than for the top window case?
My concern is that the SWT frame toolbar seems to make the UI worse in 99%
of the cases without really doing away with a workaround.
For what it's worth,
Erik Hennum
ehennum@xxxxxxxxxx
Konrad
Kolosowski/Toronto/IBM@I To:
platform-help-dev@xxxxxxxxxxx
BMCA cc:
platform-help-dev@xxxxxxxxxxx, platform-help-dev-admin@xxxxxxxxxxx
Sent by: Subject: Re:
[platform-help-dev] why does the help window have two toolbars?
platform-help-dev-admin@
eclipse.org
05/17/2002 01:10 PM
Please respond to
platform-help-dev
It is easy to implement back and forward buttons in HTML, but we decided
not to have them for the following reasons:
On non-Windows platform we do not have an embedded browser, and help is
viewed in Mozilla or Netscape browsers that have a back and forward buttons
of their own. Having these buttons also inside HTML area would not make
sense.
On Windows, it is possible for a document to have a link that will result
in the whole frameset being replaced with other contents. At this point
there would be no way to restore help HTML frameset as the buttons would be
wiped out from the view, if they were inside the HTML view. Having buttons
on the SWT frame is a must.
Konrad Kolosowski
Eclipse Help System
Erik
Hennum/Oakland/IBM@IBMUS To:
platform-help-dev@xxxxxxxxxxx
Sent by: cc:
platform-help-dev-admin@e Subject:
[platform-help-dev] why does the help window have two
clipse.org toolbars?
05/17/2002 03:46 PM
Please respond to
platform-help-dev
Hi, Ecliptans:
Probably this issue has come up before, but I couldn't find it in the mail
archives or a search of the newsgroup.
Why does the help viewer window in framework Eclipse help (and I presume,
standalone Eclipse help) have the toolbar with forward / back in the
containing window as well as a DHTML toolbar in the window contents?
I would have expected that forward / back could be implemented pretty
easily with JavaScript in the DHTML toolbar. There would be also be
significant benefits to adding to the display space by eliminating the
window's toolbar and in offering a single mechanism to modify the help UI.
Was there a reason it wasn't possible to implement forward / back in the
window content toolbar?
Thanks in advance,
Erik Hennum
ehennum@xxxxxxxxxx
_______________________________________________
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
_______________________________________________
platform-help-dev mailing list
platform-help-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-help-dev
