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

List:       kde-usability
Subject:    Re: "Baloon" help
From:       Troels Tolstrup <troels () tolstrup ! org>
Date:       2002-06-10 21:24:10
[Download RAW message or body]

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

On Monday 10 June 2002 18:57, Gordon Tyler wrote:
> Apparentl, there already is a KPassivePopup (although I don't know
> what it looks like) in the KDE source but not in kdeui.

I did read that, but i was going on to explore the possiblities first 
before looking at the existing code as i dont think we should be 
limited by it. If it does number 1 to 3 of my initial points then that 
is a great start, but i do think that it should do number 4 (at least 
the dont show this again part) and number 5 (more info) as well.

This is the reason that im ignoring the existing implementation for now. 
And i think we should make sure it does everything we want it to before 
we start using it like crazy.

> I think that the most common action a user would want to do is
> dismiss the tooltip so that should be made the easiest by clicking
> anywhere in the tooltip.

You might be right, i still think it should have an X button for those 
who dont think of clicking on it. Or maybe an extra popup for the 
popup's explaining that the user can click on it to close it.

Just kidding about that last option :P

> Also, these tooltips should be purely informational. Any critical
> information that must not be easily lost should be displayed by a
> proper dialog.

Indeed

> How about this: If the user clicks to dismiss the popup, then it
> should be turned off. If they don't dismiss it and it just times out,
> then it should not be turned off.

ack. That is too subtle i think. I think just clicking should close it, 
not disable it. Read my comment below.

> Perhaps the ? icon could be changed to a hyperlinked phrase at the
> bottom of the tooltip, "Click here for more information"
[Above paragraph taken from further up in the mail, but i felt it would 
fit in with the next one]

> What if the ? icon or "click here for more info" link were to show
> the configuration dialog for the tooltip? Then if the user wanted
> full help for it, they click the Help button on that dialog.

I think that would be a good idea.

I added 3 new versions at the bottom of
http://www.tolstrup.org/kde/baloon.html

The first one has no buttons, but got the more info link at the bottom.
The second one has both the link and a close button
The 3rd one has no link, but has a help button.

I dont know which one is best. I also played with the idea of removing 
the caption again, yet maybe keeping the icon, but i dont know.

An attempt to make a dialog that could pop up if you click on the link 
is attached. There is also a screenshot as well as a link to the .ui 
file on the webpage.

This is my first real attempt to use the designer so i wouldnt be 
surprised if my design sucks :) Anyway, it shows 2 sets of help links.

The first link is context specific. This might not always be present 
(like if kppp doesnt have a help page that could be associated with 
modem connections)
the second one is a link to the program handbook.

And i think these 2 should be followed by as many related links as 
possible. 

The next 2 links are passive popup / baloon specific. (i know the 
current class is called a passive popup, but i think we need to use a 
different word when talking to the user)
The first one is a help to the dialog we are in.
The second one is help about the passive popups in general.

Those 2 shold probably be placed in a help button next to the close 
button now that i think about it :)

> > And im also not 100% sure if there should be a global switch to
> > turn them all off.
>
> Hmm... I'm not sure about this one as well. It adds some programming
> complexity behind the scenes and I don't know if it's really that
> useful?

After thinking about it i think my conclusion is that there shouldnt be 
a global switch. Its not like we will have 5000 of these so people can 
simply disable the ones they dont want.

As for the complexity, i do think this will add complexity anyway since 
i dont think the apps should be bothered with handling whatever a popup 
is turned on or off. The popup should do that itself. Say you just give 
it a name, and an optional context specific help document and it 
handles everything else. The easier using such a beast is the easier it 
will be to get people to use it :) But im not into the different 
guidelines/design rules of KDE and dont know if it would be ok to store 
these popup settings in its own config file (as in: kpassivepopuprc) or 
it should be in every app that uses them's config files. But i think it 
would be, code wise, easier to let the kpassivepopup class deal with it 
itself. But im talking code now and i think that is too early ;)

> > > Yes! I'm currently unhappy with KMail's new mail notification.
> >
> > Me too, which is why i hurried to turn it off. It is quite
> > annoying.
>
> I don't mind the beep. But if I have my speakers off, or I'm not at
> my desk, I have to go specifically check in KMail's window if I have
> new mail. As others have mentioend in this thread, there is a patch
> floating around which does a Kicker tray thing which is what I want.

Does it beep? =) I usually play music when using the computer ;)

Mvh
Troels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9BTTomTmAA3i3lrERApq/AJ4uU3Gh4kVZtaRlLDC8XR+VmfYgewCggtZs
jFwTOlD7Dj50cXJZLj6ivUI=
=iSoD
-----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]