On Wednesday 12 June 2002 12:33 am, Troels Tolstrup wrote:
> On Tuesday 11 June 2002 08:06, Tim Jansen wrote:
> > IMHO the shorter "more information" link in #9 is better than the
> > "Click here for more information" in #10.
>
> I changed the link text and uploaded a #12. I think the visual layout i=
s
> getting close now.
> (still at http://www.tolstrup.org/kde/baloon.html)

This is coming along VERY well.  Great work!

> Except one thing. Colors. Should the color scheme be used or should the
> normal tooltip color be used? I actually made it yellow so far to make
> it resemble a tool tip.

I think it should use the tooltip color, however I would note that the no=
rmal=20
tooltoop color has become such because the colors red & yellow (according=
 to=20
marketing, ui design, etc.) indicate 'action' (as in 'HEY! You NEED to do=
=20
something) and thus draw attention.  The lighter tone of the tooltip gets=
=20
attention but doesn't neccessary YANK a person in like a solid yellow wou=
ld. =20
This is, of course, a good thing.

I really like having two colors there (the kind titlebar look, like the l=
ower=20
screenshots have.  Really attractive and professional.

> Im still not 100% sure about the behavior either.
>
> Should clicking on it close it? Even if it has a close button? Wouldnt
> that be confusing? What if they attempted to click on the link but
> missed it?

I think clicking on it SHOULD close it.  The user clicking there says tha=
t=20
they ackowledge that it is there and (hopefully) have read it.  Have a bu=
tton=20
to close it is good, IMHO because the user then doesn't have to ask=20
themselves 'how do I close it'.  I know it sounds redundant, but sometime=
s=20
you have to be.

> Should the delay pause while the mouse is on top of it?

I think this is a good idea.

> What is the best way to disable a specific popup for good? Right
> clicking and selecting "Dont show again" in a context menu? (the item
> should be grayed out if it cant be disabled, the program will have to
> do the actual disable work i think) Or should the baloon include a
> checkbox? (i think it would take up darn much space though, especially
> since there should be an ok button too as it would be nasty to change
> things without the user aknowledges his choice)

Hmmmm, that's a tough one.  Maybe make it an option that the app can deci=
de=20
whether to include the functionality or not.????

> Is it a problem that help about the baloons in general would be in the
> more information link? This would cause all baloons to have such a
> link, even if it doesnt contain any context specific help. But im not
> sure how else to add the baloon help to it.
>
> An alternative could be to place the help as an option to the RMB
> context menu and add a tool tip to the baloon explaining how to get to
> it, or is that abuse of the tool tips? It would have the advantage that
> the more info link would only be shown when there is more info.

RMB generally will NOT get used by the standard user.  So, if it is an op=
tion=20
that users will somehow NEED, then it should NOT be RMB.  If it is more o=
f a=20
power-user thing, then I think RMB is fine.

> Another alternative would be to add a menu button like in the window
> decorations. This could contain both the help and the "dont show this
> again" option and would hence get rid of the RMB context menu. See #13
> for an example of this. Im not artist so i have no idea if the icon is
> clear or not. I somehow feel that is better than the other options,
> even though i dont like putting another button on it.
>
> I will start playing around with the KPassivePopup code and see if i ca=
n
> make a working prototype soonish (as in copy the code and make a demo
> program using it). It will be my first QT/KDE project so i dont dare
> giving a time estimate yet.
--=20

Christopher M. Young,
RHCE, MCSE, SCSA, CCNA, CCA
cyoung@linuxnetworker.com

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability