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

List:       kde-usability
Subject:    Re: sys tray interfaces (was usability report)
From:       Gav Wood <gav () kde ! org>
Date:       2003-01-31 15:03:58
[Download RAW message or body]

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


> Mac OS:
> OSX:

no comment - i never really used them.

> Windows/KDE before the advent of systray/window mixed apps:
> Minimize: Hiding to make room, shows the corresponding entry in the taskbar
> "unpressed"
> Close: Destructive, closes the window while losing all its data, selections
> etc. (sometimes combined with a save: yes/no dialog), but actual program
> continues running until all of its windows are closed
> Quit: Performed by choosing "quit" from the program menu or by closing all
> its windows
> Issues: None

actually, unless you're harking back to the win3.11 days (god forbid!) the 
volume control has always been a permanent fixture in the system tray and 
that despite having a (closable) main window did not exit without an explict 
quit.

the same goes for all? the systray applets i saw around in the win95 days, 
including the ati display contols

> Windows/KDE with the systray mess:
> Minimize: Hiding to make room, shows the corresponding entry in the taskbar
> "unpressed" or shows up as icon in the systray.

except in the most unconformant applications, afaik minimise has never meant 
anything but what you describe it as being previously on windows.

> Close: Destructive or non-destructive depending on kind of program, closes
> the window while possibly losing all its data, selections etc. (sometimes
> combined with a save: yes/no dialog) depending on kind of program, but
> actual program continues running possibly even after all of its windows are
> closed depending on kind of program

no - see above for the windows volume control.

> Quit: Performed by choosing "quit" from the program menu and sometimes also
> by closing all windows
> Issues: How does the user find out which kind of program a program is? The
> user might be able to get to know that by finding out whether it has an
> icon in the systray, but the question is how many will bother to check it
> out and what will prove them that a systray icon is connect to an existing
> program. There's not even a graphical hook showing a connection like the
> one you get when minimizing a window to the taskbar.

dont confuse windows with kde - no (conformant) programs "minimise to the 
systray". 

i say again if the user can see the program has a sys tray entry, then it will 
stay around until explicitly quited.

programs based in the systray will show the systray icon there anyway, 
regardless of what dialogs they show also. quite simply, if there's a systray 
icon there for the program, then that icon represents the program. it's quite 
simple really.

> > minimising is fundamentally different to the functionality provided by
> > the
>
> system tray.
>
> Please explain how the functionality differs and how an average user can
> "naturally" understand the difference (as in it being an intuitive GUI
> feature).


if a program is based in the systray (i.e. an icon appears there when it is 
started - not hard to see!), then it lives there until explicitly told to 
quit, regardless of the state of its windows.

example: the volume control program has an entry in the systray, therefore 
closing the dialog with the controls in them does not terminate the program - 
you have to go to the systray for that.

> > the window is the window(!);
>
> And the user get to know that by closing it he's often losing data without
> being able to get it back.

knotes seems to be well implemented usability-wise and you can close those 
windows without losing their data.

> > the application is (represented by) the sys tray icon.
>
> Hm, I've quite some applications which seem not to be represented by a
> systray icon. Is that some kind of inconsistence? =P

if there's one there, then that's it's representation.

> > quite simply, a "kde daemon-like program" can be strictly defined as a
>
> program whose main* interface is the systray icon.
>
> "I see, and how do I get a program's main interface into the systray?

there are two types of program in this world - those that live in the systray 
(i.e. put an icon there on startupo - not hard to see!) and those that dont.

>  What
> is a "daemon-like program"?

a program that lives in the systray (group 1 above)

> Which program has which systray icon?

which ever one it looks like - er.... if the icon is kopete's icon, it's for 
kopete; if the icon is a speaker, it's for the volume control.

> Why can't
> I close a program with a systray icon the same way as every other program?"

because systray programs are like the hermits of programs. they skulk away and 
dont want to know you until some point in the future when they might want to 
get your attention or you might want to use them. as such they need some 
other method of interfacing to you since a basic window will not provide the 
optimum ui functionality. hence programs based in the sys tray need to be 
explicitly closed down due to their minimal interface presence.

perhaps if we put a close button on each sys tray icon? hmm but that would get 
in the way - lets put it as a standard entry in every systray icon's menu - 
oh wait; it is!

if you ask silly questions, you'll get boring answers :-)


> > indeed such a program could be more easily be defined as any program
> > which
>
> provides a system-tray icon (and adheres to kde's guidelines concerning
> them).
>
> "But that program doesn't remove that system-tray icon anymore even after I
> closed all windows!"

no, because that would take the entire point away of it living in the 
systray!!!

the point of an app living in the systray is that it can have no screen 
presence (read no windows open!) without quiting.


> > quite simple - if it displays a systray icon, then that is the program,
>
> and the windows may be closed without the app being closed.
>
> "Which program displays what icon?

already answered that one.

>How can I know whether I can close the
> current window without losing all its data?"

if there is any data loss involved with closing a window, it will generally 
warn you before it is lost.

> > window mimisation is just window management (like shading and
> > resizing)...
>
> and as such to define minimise as close would confuse the hell out of me at
> the very least.
>
> "But I can't restore the closed window since I closed it, can I? Or what do
> you mean? *confused"

window management is stuff you do on a single window - e.g. resize. minimise, 
maximise, shade.

the sys tray provides a place for apps that need _no_ windows on screen to 
present a minimial ui.

> > er no.
> >
> > if(app has systray_icon) then
> > 	sys tray icon == app.
> > else
> > 	main window == app.
> >
> > the rule is simple.
>
> "I don't understand. What language is that?"

a new language i made called silly-C. here it is in english:

if the app in question has a systray icon then
	the sys tray icon must be removed ("quit" in its menu) before the app is 
quit.
otherwise
	the main window(s) must be closed before the app is quit.

> > i say again:
> > minimisation is window management;
>
> "And that's taken care by the windows manager so I can restore it again
> later on. But the closed window will be lost forever since it's not taken
> care by the windows manager, right?"

it will be closed. - until you reopen it. - like a konqueror window - if click 
"Home" on your desktop, then it will open a window with your home contrents - 
if you minimise it then you can get it back just by clicking it's title in 
the window list, but if you close it it will be closed.

you then have to reopen it again in the manner you did the first time. but 
closing a window does not mean the content os it are destroyed - otherwise 
nobody would have home directoies left! ;-)


> > the systray provides a different type of interface for the user. it
> > should
>
> generally be used for applications who need no screen presence/user
> interaction much of the time.
>
> "Yes indeed. I only a lot of icons there, some of them seem to be animated,
> and every single one behaves differently when I click them, nothing for
> me... *scared"

they all provide a basic menu on RMB, including quit.


> > minimising is used for hiding windows, yes.
>
> "...and I can restore them later on."

indeed you can, from the window list.

> > closing is used for closing windows. if you want to call that hiding,
> > then
>
> they do the same job.
>
> "No, closing will destroy my data unless I saved it. When I open the window

er... no - konqueror, knotes, kaddressbook.... all have non-destructive close 
actions. see the above example for an explaination.

> again it's empty or showing the default view again most of the time."

er.. no - see above.

> > think of the kopete contact list window as the same sort of window as the
>
> gimp's brush selection window --- you can close it and the app still
> survives and you can reopen it easily enough.
>
> "I always need to restart kopete to get the contact window again. And a

no you dont.

> friend told me that all gimp windows are hidden away in some deep submenus
> which are so complex that I'm just scared."

better go hide under a cave then ;-).

seriously, for users as un-tech-savvy as the one you are portraying, the 
systray functionality might need some basic help page. but then i have 
_never_ met anyone as untech-savvy as such a user - i think perhaps aaron 
might have a worthwhile comment here, being a support person?

> > consequently, you may think of the sys tray icon as gimp's main window:
> > if
>
> that goes, the app is exitted.
>
> "Interesting. And what tells me what tray icon is what app?"

the icon, strangely enough :-)

> > in some cases it may be tempting to make an analagy between gimp's main
>
> window and the kopete's contact list. this would be an error for two 
reasons:
> > 1. it would provide fundamental inconsistency between different kde
>
> applications' usage of the systray interface and their helper windows.
>
> > 2. it would provide fundamental inconsistency between different kde
>
> applications' usage of the systray interface and their helper windows.
>
> > i know technically this is just one point, but i thought it was such a
> > big
>
> one, i'd better mention it twice.
>
> I honestly don't get your point here, for real now. =P

no kde app that shows a sys tray icon quits just because all its dialogs are 
closed. (except kscd doh!)

> > it is a destructor button - unlike minimise which simply shunts the
> > window
>
> to another part of the screen in a minimal fashion (or shade, which does a
> similar thing), close actually gets rid of the window
>
> "...so I won't be able to restore it anymore..."

only so much as with konqueror, knotes, kaddressbook....

>
> > and you have to ask the program nicely to get the window back again (or
>
> perhaps not).
>
> "How can I master this voodoo magic?"

use the menus, luke!

> > > differentiate between windows and applications
> >
> > evidence?
>
> Show any newbie the complete list of running processes on their computer.
> They'll most likely wonder why there are way more than he has windows on
> his screen.

applications != processes.

> > i haven't heard many complaints from kmail, whose "main window", even
> > when
>
> closed does not (neccessarily) exit the app; thereby showing a string
> difference between app and window.
>
> That wasn't my point. My point was that if one closes all windows he should
> be sure that the program is quit. Or that programs continue running even
> after all windows are closed. But don't mix both of them.

programs only continue running after all windows are closed if and only if 
they have a sys tray icon with the same icon as the windows. is that little 
rule simple enough?

> > you mentioned inconsistency and i was merely saying that it is consistent
>
> with what went before. i actually do think it's the best interface
> presented so far, but i would never try to ratify that simply because
> others do it that way.
>
> Is the behavior of close buttons consistent or not? In my experience it
> isn't, and that's very very bad usability wise. And the whole systray
> matter is adding a lot of unnecessary inconsistency to the mess. We really

close buttons always close the window - close button may or may not quit the 
app, depending on the type of window (e.g. closing a find dialog wont close 
the app), or the type of app (e.g. closing a knotes note wont close knotes, 
closing the volume control wont close kmix, closing kmail's main window may 
or may not close kmail depending on what other windows are open).

> need a definitive rule what the close button's behavior actually is instead
> differing between several kind of programs whose close button behave
> differently.

i think it's fine as it is.

> > "minimising to the systray" (a contradiction in terms, since nothing
>
> legitimately minimise to the systray - windows may only be minimised to the
> window list.)
>
> Where is that written? My Win used to run two daemon-like applications
> nearly all of the time: Imonc, showing network traffic when minimized to
> systray, and DC++ which just keeps sharing P2P file stuff when being
> minimized to systray. Both programs minimize to systray by pressing the
> minimize button and quit completely (after a confirmation you can turn of)
> when clicking the close button. This is the kind of behavior I prefer when
> dealing with deamon-like programs.

they're windows programs, and as such do not have to adhgere to the kde style 
docs.

if this was kde, it would be incorrect and inconsistent behaviour.

you cannot quote other programs interactions on other platforms and say the 
kde should act like them to be more consistent - i could name a multitude of 
other ways of window/app handling that i prefer on other platforms but i 
would never insist that the hole of kde be changed just because i thought it 
made more sense to me.

> > but it is possible to close the contact list window, just like it's
>
> possible to close the downloads window.
>
> But you can restore them, can't you? So it's not destructive and thus

ughgh - this is the last close question i'm going to answer now - see my other 
stuff on the charecterstics of close on konqueror windows - does slashdot get 
wiped when you close the browser window? does your home dir get erased when 
you close the home window?


> should use the close button for this behavior. Introduce a new button if
> you think the minimized button doesn't do it either. I think Outluck
> Express uses to have a "hide" button in its mail receive/send progress
> dialog...

another windows program let's at least keep it to kde!



> > are you saying that only windows which actually quit the app when closed
>
> should have a close button?
>
> No, but only windows which are destroyed (as in you are losing any kind of
> data by doing so) by clicking the close button.


konq doesn't delete files when closed

kmail does delete mail when closed

knotes doesn;'t delete notes when closed

kaddressbook doesn't delete address when closed

> When the genie effect is used then it won't confuse users. But right now
> newbies won't know what systray icon is related to the Kopete contacts list
> and how they can restore the list after "destroying" it.

then if they do get confused (and i doubt they will after a day'susage) 
poliutely tell tham the kopete _is_ the icon in the sys tray and that they 
have to close that to close kopete.

it is, after all, standard kde functioality  - if they use kde, they should 
know it as it's one of the fundamental points of the ui. aaron do people have 
this much trouble with the sys tray?

> > the kde guide lines define the consistency - any apps that dont follow
>
> them are inconsistent. (if you cant already tell! ;-)
>
> The KDE guidelines is imo violating the unwritten rule of the purpose of
> close buttons. And the fact that the purpose of minimize and close buttons
> were never written down and standardized within KDE is a real shame
> usability wise.

close buttons are not always destructive, sys tray or not.

> > minimising is purely a window operation; the system tray presents
>
> developers with a wholly different type of application interface to a
> window.
>
> And who's thinking about the actual users? Nobody? Usability is related to
> computer-user interaction, not computer-developer interaction, isn't it? ;P

indeed, which is why the systray is invaluable for "kde-daemons".

> > i believe your problem is that kopete's contact list window does not look
>
> quite "peripheral" enough to be distinguished from a non-systray based
> application's main window.
>
> I have no problem with the look, my problem is the abuse of the close
> button which is a result of using two completely different and incompatible
> ways of representing applications.

erm - and all the other non-destructive close buttons i mentioned?

> > in any case, i believe attempting to blur difference between minimising a
>
> window (a window operation, like shading it....) and closing peripheral
> windows of an application to leave only the sys tray icon visible would not
> alleviate any problem that there may be (and lets face it, with any
> interface there will always be some problem :-( ):
>
> We are on the usability list exactly for finding those weak points and
> offering consistent and intuitive solutions.

indeed - i have seen none offered so far, and the kstyle guides prrovide us 
with a good standard way of inteeracting - i see no reason to throw them 
aside in favour of an inconsistent minimise behaviour that sometimes 
"minimises to tray" (currently a contradiction in terms) and sometimes 
minimises to window list.

>
> > i believe it would only serve to confuse users who have learnt the (not
> > so
>
> difficult) rule that if an app has a sys tray icon, you have to explicitly
> quit it, not just close the windows.
>
> This rule is an exception for the rule which applies to all programs which
> don't have a systray icon. Exceptions should be avoided since they do no
> good, and I think I showed enough examples to show just that and also
> offered a solution which would work well with everyone.

no - it's a consistent rule for every program that is sys tray based, and 
what's more it is the whole point of being systray based!

> PS: Did you really read everything until here? ;)

you betcha. my fingers hurt now :-/

gav
- -- 
Gav Wood -- gav at kde dot org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+OpBf0BEfrsjnAxsRAvMNAKCQdiku1L3wreCYi+s+okW2tvSkDwCfaGFa
I56bJyN0p3WOXxMaeiKgkO8=
=264H
-----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]