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

List:       kde-core-devel
Subject:    Re: kcontrol patch #1
From:       Tom Hoferek <yoamwmvs () umail ! corel ! com>
Date:       2001-03-28 16:02:04
[Download RAW message or body]

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. 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.

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. 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.

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.

> > Patch #2
> > ------
> > 
> > I have removed the Search tab and replaced it with a Search button. The
> > search button then brings up a dialog box. Unfortunately, the process of
> > splitting out the patches has slightly broken this feature in that the
> > search list isn't populated. It worked before and I can't figure out why
> > it doesn't now. Perhaps someone could take a look at it and figure out
> > why.
> 
> 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. 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. 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.

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

> > Patch #5
> > ------
> > 
> > Display a list of the modules under a category when a category is
> > selected. This uses a modified AboutWidget that lists the Category and
> > sub-modules when a category is selected. If a category is selected after
> > changes were made to a module, the standard message box pops up to let
> > the user accept or forget their changes. There is one minor bug with
> > this that I haven't been able to figure out which has to do with
> > resizing the AboutWidget when a category is selected. If a category is
> > selected after a module, then the resizing is correct. If a category is
> > selected on startup or after another category, there is a resizing
> > problem. However, resizing kcontrol as a whole by dragging an edge
> > causes a proper resize.
> 
> 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.

Cheers,

Tom

-- 
The address in the headers is not the poster's real email address.  Do not send
private mail to the poster using your mailer's "reply" feature.  CC's of mail 
to mailing lists are OK.  Problem reports to "postmaster@umail.corel.com".  
The poster's email address is "tomh@corel.com".


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