[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kcontrol patch #1
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-03-29 1:02:29
[Download RAW message or body]

On Wednesday 28 March 2001 11:02, Tom Hoferek wrote:
> Dawit Alemayehu wrote:
> > I fail to see how popping-up a dialog box would be a better choice in
> > this case...  In fact it makes it is IMHO slightly worse.  Perhaps an
> > illustration will my make my view a  bit clearer:
> >
> > User A needs help filling out or settings some value in a certain control
> > panel module ; so (s)he clicks on the Help button and they get a popup
> > dialog.  User A then proceeds to  read the info and closes or minimizes
> > the popup dialog.  Now if (s)he wants to refer to this help again, (s)he
> > would have to bring up the dialog box and repeat the whole process.  This
> > would result in at the least three mouse clicks to switch back and forth
> > to read this info as needed.
>
> Your illustration assumes that the user closes or minimizes the Help window
> in the proposed model of the Control Center.

Right.  Is there any other alternative ?  I guess one can resize the windows to
fit both in the visible screen, but that is a nusicance for those that do not like
doing this.  I for example like all windows to be maximized and do things one at
a time unless you give me an app that is integrated like konqueror or kant etc.
It distrubs me when there are multiple windows visible in the screen at any given
time!  BTW I am stating this now from a user's prespective not a developer ; so
consider me as you would User A in the above scenario.

> If it is fair to assume that then it is also fair to assume that the user can just
> as likely switch away from the Help tab in the current model. The net result is
> the same thing -- in the current model the user would need to activate the Help
> tab again, thus there really is no advantage to the current model as far as your
> illustration goes. The user is either reactivating a window or a tab. Not much
> difference.

Huh ?  Swicthing to the help TAB is only one click and the help is permanently
displayed until such time that I am finished with filling out that particular module!
Furthermore, I agreed that the help button should be synced with the help tab
or to go even futher and hide the help TAB s until the user presses the "Help"
button.  Perhaps the "Help" button could be labeled "Show Help"  and "Hide Help"
to hint at the fact that the help is going to be shown somewhere within. I am sure
the user would not miss this when (s)he clicks on the button.  What I do not 
understand is how this can have a useability consequences when it actually requires
less from the user ?? Comparing it with a poping up dialog box which you have to move
out of the way by minimizing (

> One of the reasons I feel the proposed model is superior is precisely
> because it separates the primary work area, the Control Center main window,
> from the Help window. The Help window compliments the main window.

Well this is a very valid argument, but the section of the are taken over by the
help is the one that controls the modules and not the display are for which you
are seeking help.   The displayed help is module specific and AFAICT it has no
specific relations with the generic help that can be had from the "Help" (F1) menu.
Am I wrong in my assumptions about this ?

> The user should be able to view both of these at the same time in their
> entirety. In the current model, the Help tab takes over part of the main
> window. That lessens the potential effectiveness of the help. When referring
> to Help, the user should be able to see and use the entire main window of the
> Control Center. That way Help is likely to be more helpful.

But that is just it.  I could understand if the help was a generic one.
However, the help being sought after in this case is module specific and
as such only pretains to the current module you are viewing.  This IMHO
means that the modules selecter part of the control panel has no specific
use at the time the user is requesting this particular assitance.  If (s)he
is pressed the F1 button or selected "Help->Contents" or pressed F1 and
got an integrated help I would be against it as well since the help requested
in that case could possibly apply to the entire control panel in which case you
argument would be very valid.  However, under the current scenario I do not
feel it is.  Perhaps it is just me.  Or it is the labeling given to the TAB.  It should
perhaps have been "Description"  or "Quick Hint" or something else other than
help so that the user is not completely suckered into thinking that it is equivalent
to the pressing F1 or selecting "Help->Contents".


> Another point in favour of the proposal is consistency. No longer would
> there be a Help tab and Help buttons that do different things. As well,
> having a separate Help window is consistent with the way Help works with
> other applications. Lets not forget that if the Help is on a tab, the Help
> is forced to fit within a pane that is likely sized by the user for
> navigating the contents of the Control center rather than for reading help.
> A separate window can have a default size that takes advantage of good
> graphic design principles so that the Help is presented with the highest
> degree of legibility that is possible/practicle.

Well I simply disagree with you on this.  The help being shown is actually the qucik help
or description rather than a full fledged help.  It is something to assis the user with
qucikly gettting up to speed.  I personally equate this help with the "QUICK START"
description files that are included in some softare packages to get you started qucikly
without having to go through the whole detailed help are for which there is the full
fledged help documentation files, in this case the F1 button :) 

> > > Patch #2
> > > ------
> >
> > Similar issue here as well.  The first question that popped-up in my mind
> > is why an extra dialog box ? In the least, if you want to get rid of the
> > tab to simplify things why not simply marry the search and the index tabs
> > into a single one ?  Add a search button along with a klineedit (as
> > sketched below) either at the top or bottom of the index tab would allow
> > the user to search for the available entries and when the user selects
> > one, it would be displayed and the the module listing tree would simply
> > have to be synced.  Wouldn't this approach be the easiest path ?  You can
> > completely replace the content list that gets adjusted in the search tab
> > with the completion mode of the lineedit itself which now has a popup
> > completion mode.
>
> Similar response here as well. Usability is improved by separating the main
> window from the Search window. Users should be able to see the entire 
> main window when performing searches. 

Hmm.. isn't that a contradiction ?  You cannot see the entire control panel when
a dialog box is on top of it!!  On the other hand if the search info is integrated and
it reacted by updating the tree to show the hierarchy of the selected module, you
would not only not cover the very same thing your are trying to make visible to the
user at the all times, but also solve the problem you metioned below.

> Blending the search interface into the main window so that part of the main window
> is taken over reduces the 'learnability' of the Control Center interface.

Is "learnability" a crieteria or part of useability ?  I do not know, but useability for me
simply encompass consistency and ease of use that is it.  So I do not know about this

> It hinders the users' development of a mental model of it because while they may
> see the module they choose from the search results in the right pane of the main
> window,

> they don't see where the module fits in the Control Center hierarchy
> because the left hand pane is taken over by the Search controls.

Huh ? How ?  I did not say do a complete merge!  I said only one button with one
line edit!!  How does that translate to the left hand pane being taken over ?  This
two widgets would not even take 1/10 of the lef-hand pane.



> From a usability point of view, it is better to let the user see the big
> picture when using the Help and Search functions.

I guess I disagree with this completely.  I personally am not conveinced that
these changes are necessary with the exception of correcting the help buttons
to show the help in the module specific help in the "Help TAB" instead of launching
the general help. And the label of these buttons and the tab being changed to
something else along the lines of what I suggested above.

However, as they say "he who writes the code will have the final say" :)

> > > Patch #5
> > > ------
> >
> > Hmm... I actually think this is a good idea, however what happens when a
> > module that belongs in that category gets loaded ?  Does it display its
> > own info ? One of the most important things missing from the control
> > panel is an explanation of a particular module directly in the display
> > area.  This was replaced with the help TAB, but IMHO that is not
> > intuitive for the end-user.
>
> Something like this was proposed earlier on the KDE-look group. It was felt
> that the best thing to do when a module is selected is to display the
> module itself rather than a description of the module.

Right.  I did not want the description take over the while dispaly (right-hand) pane.
I simply meant a little description that takes 1/4 or even less of the top part of the
config dialog to give the description for the current module much like how the Netscape
preferences dialog tells some information.  Anyways, I am neither for nor against this and
accept whatever the prefered thing is...

Regards,
Dawit A.

[prev in list] [next in list] [prev in thread] [next in thread]