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

List:       kde-usability
Subject:    Re: "Baloon" help
From:       Christopher Young <cyoung () linuxnetworker ! com>
Date:       2002-06-12 17:17:44
[Download RAW message or body]

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 is
> 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 normal 
tooltoop color has become such because the colors red & yellow (according to 
marketing, ui design, etc.) indicate 'action' (as in 'HEY! You NEED to do 
something) and thus draw attention.  The lighter tone of the tooltip gets 
attention but doesn't neccessary YANK a person in like a solid yellow would.  
This is, of course, a good thing.

I really like having two colors there (the kind titlebar look, like the lower 
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 that 
they ackowledge that it is there and (hopefully) have read it.  Have a button 
to close it is good, IMHO because the user then doesn't have to ask 
themselves 'how do I close it'.  I know it sounds redundant, but sometimes 
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 decide 
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 option 
that users will somehow NEED, then it should NOT be RMB.  If it is more of a 
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 can
> 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.
-- 

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
[prev in list] [next in list] [prev in thread] [next in thread]