From kde-core-devel Tue Feb 15 11:48:16 2005 From: Waldo Bastian Date: Tue, 15 Feb 2005 11:48:16 +0000 To: kde-core-devel Subject: Re: thoughts on the systray Message-Id: <200502151248.20396.bastian () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110846824028357 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart4436796.QunvaG2fPK" --nextPart4436796.QunvaG2fPK Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 14 February 2005 22:35, Lubos Lunak wrote: > On Monday 14 of February 2005 22:19, Waldo Bastian wrote: > > On Monday 14 February 2005 21:00, Lubos Lunak wrote: > > > 2) applet-like cases > > > - e.g. kxkb, klipper > > > > Isn't the only difference that they don't have a "window" asociated with > > them? > > It is, but it's _the_ difference. Basically kxkb the systray icon the > systray icon is the main interface. With some app which uses systray for > minimizing the window is the main interface, and the systray icon is just > something additional. It makes the two things very different for me, > different concepts. I think there are 3 functional aspects: * Access to main window (like a takbar-entry) * Status indicator * Quick access to main functions And a 4th one that seems to be shared by all: * Persistent non-intrusive UI presence I think the 4th one drives the concept, the other 3 just provide value tot = the=20 concept. So you can argue whether it is truly necassery to use the systray= =20 icon for something that only needs 1 out of these 3, in the end that's a=20 decission based on a cost-value evaluation *), I don't think any of the 3=20 aspects are fundamental in and of themselves, only 4 is. I think it may make sense to approach, from a technical implementation poin= t=20 of view, the systray as an extension of the taskbar. However, from the=20 perspective of an application developer, there should be a real distinction= =20 between taskbar and systray, using the systray should be a conscious design= =20 decision on the part of the application developer (keeping in mind the=20 cost-value evaluation mentioned above), and a choice for the systray should= =20 result in certain garantees with respect to presence/visibility and access = by=20 the user. As a secondary concern, perhaps even as an afterthought, it could be made=20 possible for the user to override the initial decision of the application=20 developer and migrate the application from systray to taskbar or vice versa= =2E=20 But that's a fringe concern aimed at the 1% of users that want to have thei= r=20 favourite app in the systray or to correct misguided *) decisions from=20 application developers who may have different ideas about value than the=20 end-user. It's like Konquerors can-do-everything design: from a technical design poin= t=20 of view this is a great approach, however to get a usable UI you must=20 artificially restrict the possibilities based on the roles that you identif= y=20 from a user-machine interaction point of view. As a whole this is a very=20 powerful approach because it allows you to make decisions from a UI and=20 usability point of view without the technical design getting in your way.=20 It's a mistake to think that the technical design alone is a complete=20 solution though, the different roles must be clearly defined as well. Cheers, Waldo *) Cost: the screen-estate available to the systray is limited and the more= =20 icons it contains the less effective it becomes. *) Misguided: application developers have a tendency to think that their=20 application is the most important one the user has ever seen or used and=20 should therefor be present in all possible UI locations (main-menu, panel,= =20 desktop, system tray) and started automatically on log-in. Users do not=20 always agree with this assessment, especially those users that use more tha= n=20 1 application. =2D-=20 bastian@kde.org | Free Novell Linux Desktop 9 Evaluation Download bastian@suse.com | http://www.novell.com/products/desktop/eval.html --nextPart4436796.QunvaG2fPK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQBCEeGEN4pvrENfboIRAlhNAKCNAWtiSCuF4SA7OZI8ErJ/d2c39wCgh5Fu Kv79WwXk4djO/prBglz5AtI= =jcL6 -----END PGP SIGNATURE----- --nextPart4436796.QunvaG2fPK--