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

List:       kde-usability
Subject:    Re: "Baloon" help
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-06-12 2:49:20
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On June 11, 2002 10:33 pm, Troels Tolstrup wrote:
> 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'd say make it look like a "regular" tool tip for now colour-wise and we can 
see how it looks w/different colour schemes... i'd say this is an "experiment 
with it till it looks right" kind of thing and wouldn't worry about deciding 
100% before writing code...

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

IMO, it should either time out by itself or else close only when the close 
button is clicked ...

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

probably 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)

i really like your little window menu button; that would be a logical place to 
put this...

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

only if a more information link is supplied by the application should it 
appear. i'd put the balloon help in the window menu as well. the reason i say 
that is the "More Information" link appears contextually to refer to the 
balloon's contents; if the usre clicks on it and gets balloon help they will 
probably learn not to click on it and miss the real "more information" links.

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

it actually helps ballance it out visually IMO... i like it very much ...

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

i don't think we're in a rush ... as waldo's email to core-devel said, 
kpassivepopup should probably _not_ be made public in 3.1 and held until 3.2 
so that it can be made wonderfully spiffy w/out ugly compatibility kludges.

it's looking nicer in your mock-ups all the time, btw

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler" 
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9Bra01rcusafx20MRAsrxAKCZ/tc63GtuvLrDp6rtbplMBRKcjwCePFJm
10allfwocD+O4UQblCJ3Vx8=
=7UQJ
-----END PGP SIGNATURE-----

_______________________________________________
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]