Hello, Just like Simon, I don't post so often on this mailing list. I just wanted to mention that I have done some work in the past on KDE's concept of "extenders", as well as some mockups (*). For many reasons (technical issues, real life...) it never really went anywhere, but a fair amount amount of discussion happened on the kde-artists forums as to what was sensible or not etc. I'll dig up the materials as soon as I find some time for it, since it is related tightly to issues that are being raised here (system tray management, app notification and so on). I hope I can be helpful on this matter as a mockup drawer, as well as somebody who's heard a lot of stuff about this topic already. Feel free to let me know about any concepts you'd like to see sketched up, I'll give them a try.
I can remember at least two big problems that had some solutions elaborated : the first one was basically the overabundance and the heterogeneity of notifications. The obvious solution was to build a unique notification daemon that would take input from everybody and that would be able to queue, prioritize, display or not everything the user needed to know. It was also agreed that there would be an interesting gain of usability if the notifications could "morph" graphically into their answer (eg : the "You have mail" would detach from the tray and morph into a window that'd display the message and allow an answer upon user input). On the other hand, if you clicked on the mail icon in the tray it would give you a list of tasks that you could perform. With permanent internet connectivity, it seemed that this behavior made sense for at least some communication-related applications. Another problem was all those background tasks that usually require no input from the user until they are completed (that's typically downloading files, compiling, installing, etc). Those again could be managed by a single icon in the tray that could, pause, kill or prioritize the tasks (I have some mockups of this concept on another computer, I'll post these later). I will post further reflections on the topic later, otherwise I'll be late for my course. Amaury (*) There are a lot of these, so I'll upload only a few, let me know if you want to see the rest http://webeleve.ensmp.fr/~05chamay/addext.png http://webeleve.ensmp.fr/~05chamay/stuff.png http://webeleve.ensmp.fr/~05chamay/stuff4.png http://webeleve.ensmp.fr/~05chamay/ext3.png On 4/29/07, Simon Hough <[EMAIL PROTECTED]> wrote:
I have been a reader for a while here, posting for the first time:) Anyway, I do agree that the quick launch bar can seem very cluttered at times and wondered if making it more dynamic would help, i.e. pressing all three mouse buttons would trigger an action where all my quick launch icons would surround my mouse pointer arranged in a circle, then click on the app I wish to launch. Just my 2 cents:) Simon On 4/29/07, Thilo Pfennig <[EMAIL PROTECTED]> wrote: > > Hi, > > I would like to know if there were already some thoughts on redesining > the communication that applications do with the users? > > > > Some elements of criticm in GNOME > =========================== > Applets, Panel, Messages, Notification Area & Application behaviour. > > * Applications: > * When closing an application some applications keep running and be > visible in the notification area > * Some applications like workrave seem to use different mechanisms > to communicate to the user. > > * Notification area: > * Every application does behave different when you right or left > click on its icon > in the notification area > > * Messages (libnotify etc.) > * Sometimes you get messages that disapear and you can > not get back (no glipper kind of functionality) > > * Panel > * If you add more nice starters and applets, the panel gets > cluttered more and more. > * You sometimes loose a function/applet from the panel that is core > to the desktop. > > > Suggestions > ========== > > * All applications of a kind should only be allowed to use the > notification area or GNOMEs notification system if they use certain > kind of messaging. I expect different classes of applications to work > in the same way. I would like to see every music application to react > the same way on: > * single click > * double click > * right click > > The notification area is something that I expect my desktop to have > under control. I should not need to learn about how different > applications react. For instance some music browsers require a right > click and choice to skip a track and some open the skip dialogue with > a left click. > > * I also suggest to have a more standardized and monolithic panel > that can not be destructed > by accident. Since GNOME 2.2 or so where I started to use GNOME I > experience now and then that parts of the panel got lost. This could > also be better from a memory perspective. Today you have a panel and > many processes and some alone take some 50-60 MB. I suppose if these > were integrated this would be less? > > * If somebody wants to add additional functionality I suggest that > this functionality is added where it makes sense from the panels > perspective (or better from the perspective of HIG, usability > standpoint) > > * I would expect more features like queuing of icons/messages/applets > on the panel to save space. Like the "Window selector applet" - you > only have one visible icon but then can select multiple applications. > > * Somehow the icons in the notification area have become another menu > for applications. I mean you can open preferences and much more (like > with GAIM). > > > > Any thoughts or plans on this? > > > Thilo > > > > > > -- > Thilo Pfennig > http://issues.foresightlinux.org/confluence/x/R > _______________________________________________ > Usability mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/usability > _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
_______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
