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

List:       kde-usability
Subject:    Re: systray interfaces
From:       Datschge () gmx ! net
Date:       2003-01-31 21:11:39
[Download RAW message or body]

> I think I overstated my point.  If an app is really SDI, it will naturally
die at the right time - when the last window is closed.  That's all I really
meant by "automatic".  Consider this another call towards the use of SDI for
all basic apps.

I'm so relived that you weren't talking about automatizations... ;)

Good news regarding this btw: it seems like an SDI approach on application
level and an MDI approach on window manager level is getting more and more
acceptance:
http://lists.kde.org/?l=kde-core-devel&m=104403468625974
http://lists.kde.org/?l=kde-core-devel&m=104403564927352

Moreover MDI isn't allowed anyway according KDE's guideline
;)
http://developer.kde.org/documentation/standards/kde/style/basics/windows.html

> I see - you want to capitalize on the window animation effects in
miminizing - makes sense.  I still think we should keep the close button, because 
> a) the action of closing the window is the same - we're just not closing
the "service"

No comments on that anymore please. ;P

> b) if you put a new button on the button bar some appreciable fraction of
users will freak out, and all will have to learn what that widget does

True. 8)

> c) Minimizing apps has a distinct meaning - if you change the minimize
button to a close button it distorts that meaning as well

True. %)

To be fair, (hopefully) when the windows animation effect is used in this
case ("minimizing to systray") then the abuse of the close button doesn't
really matter anymore since everyone can see that the closed window leaves an
animation pointing to its systray icon. I'd expect clueless users to try a left
click on that icon then which will ideally give them the same window back.
This is something everyone should be able to understand after watching it
happening once. =)

> The key difference is that the service has to continue to be "turned on"
even after you close the last window, whereas when you're done with the work
you're doing, you shelve the app (and if it's SDI, it's quitting happens w/o
your intervention).  I'm suggesting that the systray try to follow this
distinction and demonstrate that the service is still on.  I admit that the phone
metaphor really on works for IM, but I can't come up with a good analogy for
why the other monitoring/service/whatever-you-want-to-call-em tray icons
should still be there.

Gav already gave another good description:

"a kde gui program that needs no user interaction for long periods of time
but that must stay running to continue the service it provides, which may
benefit by providing _passive_ status reports in the form of an omni-visible icon
or a simple text message.

essentially a gui daemon (technically a contradiction in terms, since a
daemon by definition has no interface, but the idea is strict enough)."

> > I've an idea: left click on a "service" icon should always bring up the
app's main window. If a particular "service" has no main window it should
instead open a small "about" window containing short information about the
purpose of this "service" (and related stats, for fun) as well as buttons for
configuring and quitting it.
>
> I like that a lot. 

Me too. ;o)
Any other comment regarding making that the standard behavior on left click?

> In that case, I think it would make a lot sense to get Klipper out of the
tray.  To satisfy its diehard users, what about converting it to a an applet
which docks directly into the panel.  Then it could be put right where it's
always been, but the default instance of KDE could ship with it out of the
tray, and integrated into the clipboard.

Since I have action pop ups disable and thus only use klipper's RMB menu
which will exist in the systray as well I don't see any other reason to keep it
in the tray anyway.

> > How about a "configure" entry which is obligatory already as well
according to the guideline?
>
> Great idea.  What do others think?

Everyone speak up please. ;)

> > I think we agree that the guideline should suggest to use the same icon
for both the main window as well as the systray entry?
>
> Also an excellent point.

Anyone thinks this would be a bad rule?

> Frankly, I don't think it should ever appear in the tray - apps and
windows which can use the clipboard should have your and Luke's enhanced paste
button, and others don't need the clipboard's services.  It also distracts
attention from the clipboard buttons in a window's toolbar.  If people want the
Actions it provides, they should add it as a separate docked app (see above). 

Good reasoning, I fully agree.

> Also note that left and right click on the Klipper Icon do the same thing.
 If we do keep it in the tray, I think it would help to separate these.

This would be absolutelly necessary if we don't want it to break our just
proposed standard left click behavior again.

> > Deserves a home in the systray and should appear automatically whenever
the user has a scheduled alarm.  If there's nothing in the schedule it
shouldn't even start at all.
>
> Nice enhancement.  =)  What if the schedule is empty of that period?

Since it's connected to a "scheduler" it should always stay visible when
there's something scheduled so the user knows there is something and can
edit/correct it when necessary. The purpose of this service is being a reminder. A
last minute reminder which suddenly shows up only shortly before the actual
alarm starts would be quite pointless imo. =P

> > Deserves a home as soon as the user chooses to start it automatically
without any window. As long as he's starting it manually Kopete should only
appear with its windows and should ask the user first before using the systray.
>
> I like that idea.  Can I suggest you write it up as an addition to Aaron's
usability report?  If we're going to a have a "first-launch" wizard in
Kopete, I'd suggest that the relevant options go in there.

Ok, I'll look at that. But first I need to figure out the format used (not
so much for writing but for reading, my konqueror doesn't accept xml and
mozilla complains about it being invalid ^^;;).

> I think we're converging on what goes in the systray: 
> -It should be a running process (or service, if you like my lingo)

Or a GUI daemon like Gav suggested. Agreed.

> -It should have some inform the user on something for which she needs
regularly updated info, like battery, schedule, IM.

Agreed.

> -A right/middle click should produce a configuration menu

Partly agreed. The MM/RMB menu should at least contain "quit" and
"configure...", everything else may be up to the programmers imo.

> -A left click produces a main window which at least shows the apps status,
and possible stats.

As well as a short description of the app (no more "what is that icon for")
and ways to reach "quit" and "configure..." from there (for those who don't
think of or can't use the previously mentioned MM/RMB menu).

Like before we are looking forward to hearing more feedback, suggetions,
ideas and comments on this topic. =)

Cheers, Datschge

PS: I'm now preparing a draft for my proposed update for
http://developer.kde.org/documentation/standards/kde/style/basics/systray.html , many thanks to
all who gave input already (you know who you are =P). Everyone else: please
speak up if you need to mention something we missed so far. Thanks again for
your cooperation. =)

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

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