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

List:       kde-pim
Subject:    Re: [Kde-pim] Usability help needed for KPilot
From:       Adriaan de Groot <adridg () cs ! kun ! nl>
Date:       2003-04-17 19:56:35
[Download RAW message or body]

[Dealing with both David and Reinhold's comments at once.]

On Wednesday 16 April 2003 23:40, David Bishop wrote:
> On Wednesday 16 April 2003 03:10 pm, Adriaan de Groot wrote:
> > While reworking the KPilot conduit selection dialog (again - why didn't
> > anybody ever mention QCheckListItem before? It's been around since Qt 3.0
> > at least), I ended up with the dialog layout shown at
> > http://www.cs.kun.nl/~adridg/snapshot10.png (17k). It's ugly. Things are
> > OK without the command buttons (enable all, disable all, configure) and I
> > wonder what would be best: (a) ditch them because they don't provide
> > additional functionality (you could check all the boxes individually, and
> > double-click already does a configure on the selected conduit) or (b)
> > shuffle them around till they look sensible. I'd prefer (b), since
> > double-click isn't really that intuitive. But then, where should those
> > darn buttons go?
>
> I never remember.  Am I supposed to enter from stage left, or stage right?
> And is this our can-can number, or does that come later?

I forget as well, but I do know this pink tutu is yours.

> Variant of B: Ditch the enable/disable all (Or, if you're *really*
> attached, make the button text variable, such that clicking it once will
> enable all, and change the text to 'disable all').  Then, move the
> configure to underneath the list (left-justified), and move the ok/cancel
> underneath it as well (right-justified), to make it all look purty.  My
> eyeballing it says it should work.

Heh, I should have mentioned that I wanted to use the list of checkboxes plus 
the command buttons not only within a dialog but also perhaps as a tab within 
a larger widget. I kinda like this solution, though it means rewriting parts 
of the UIDialog base class. In cases where the config widget ends up in a 
dialog, the dialog buttons should include "Configure". Otherwise, we need a 
little trick to add the "configure" button to the widget itself. 

On Thursday 17 April 2003 00:47, Reinhold Kainhofer wrote:
> > OK without the command buttons (enable all, disable all, configure) and I
> > wonder what would be best: (a) ditch them because they don't provide
> > additional functionality (you could check all the boxes individually, and
> > double-click already does a configure on the selected conduit)
>
> That's not true. Have you ever tried to work without a mouse? The buttons
> should also get keyboard shortcuts so that you don't need a mouse for the
> dialog at all. Removing the buttons is not an option.

Good point. I totally forgot about non-mousing folks (I gave away my mouse 
recently and then spent two days cursing my generosity because X won't even 
start without a mouse, so I figured non-mousing folks are a distinct 
minority). Do you really think the *-all buttons would be useful? As David 
points out (in another message) those are rare actions and you'd probably 
need to configure each conduit _anyway_. 

> How about aligning them horizontally below the list?

Gives you two rows of buttons. Ugly as well. I'm hacking on putting the 
"Configure" button while I write this response, though ...

> Second, the explanations for the conduits should be shorter than in your
> screenshot. IMO, the multi-line explanations look worse than the buttons on
> the right.

Aha. An alternating color scheme might help, but not much. Maybe we should put 
a little effort into short effective comments for each of the conduits - or 
ditch the comments entirely. Displaying the comments on one line gives a 
really wide dialog or chops off the text in such a manner that you can't read 
it at all.

Part of the question here is whether we want/need a description for the user 
of what a conduit does. I think we need one. In the current (BRANCH) version 
you need to mouseover the conduit and hover there to get a tooltip containing 
the description. That doesn't work very well _either_.

> Looking at the screenshot and the explanation of the null conduit, I can't
> help but think that the NULL conduit doesn't make any sense any more. Some
> time ago, kpilot went through all databases, and the first conduit that
> wanted that database was used. If no conduit claimed a database, it was
> just backed up. If the NULL conduit claimed a database, this prevented it
> from being backed up.

It's still sensible as a programming exercise. We might disable it from 
installation though. And you're right - it used to have a function due to the 
way that KPilot iterated through the databases. Nowadays KPilot doesn't sync 
non-conduit databases at _all_ when doing a regular sync. This is a bug, 
really, since that means that (say) the memos don't get udpated if you don't 
use the knotes conduit.

Anyway, I've updated the screenie 
(http://www.cs.kun.nl/~adridg/snapshot10.png) with a new attempt. There are 
two rows of buttons. Please imagine only one of the two -- the top row when 
the widget is being used inside a tab widget or the like, and the bottom row 
for use in dialogs.

-- 
pub  1024D/FEA2A3FE 2002-06-18 Adriaan de Groot <groot@kde.org>
     Key fingerprint = 934E 31AA 80A7 723F 54F9  50ED 76AC EE01 FEA2 A3FE
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]