I’ve been doing some work since 4.2 to make sure jobs and notifications in the plasma systemtray have better usability then in it’s 4.2 incarnation. Being a new feature it unsurprisingly still had some rough edges. Thanks to a lot of feedback, and discussion on the issues, the current implementation solves a lot of annoyances. Here’s a probably quite complete overview of improvements:
- There are 2 kinds of people: those that like it that the popup with jobs and notifications automatically hide after a short while when it’s automatically shown, and those that don’t like this behavior. Apparently, most of the plasma developers are in the first group, but looking at some of the comments I got through bugreports, blogposts and what not, the second group also has quite some followers.
Two problem with auto hiding are:
a) people tended to get confused, thinking the job was finished when it autohides
b) some people usually wait for a job to finish when they start one, or have enough screen real estate (multiple monitors) that the popup isn’t really in the way of anything anyway.
Issue a) will be much improved now that we animate the icon in the systemtray that indicates there are jobs/notifications while jobs are actually running, and the fact that, at least for compositing users, the popup smoothly slides into the panel when it get’s hidden, giving a clear hint to whats going on. For issue b) however, we decided to add a config option to the systray config dialog so you can disable autohiding if you don’t like it. Autohiding has also been improved by making it more consistent: always autohide on new automatically added items, and not only on jobs. - When a job completes, it now becomes an entirely different widget, and the popup get’s automatically shown so you can see when a job finishes, and, if it’s a file transfer, even open the file or destination directory (in case of multiple files), directly from that message. Furthermore, these items are nicely grouped with all completed jobs. I’ve currently got a patch pending on reviewboard with which they get automatically destroyed after some time (currently 5 minutes, might still change) so they don’t get in your way, but don’t get destroyed when you’re not using your computer. So you can safely go away from your computer for a couple of hours, and when you come back, will still be able to see which jobs are finished in your absence.
- The job progress widgets have been improved: nicer layout, shows ETA, and can even show number of files/directories/bytes with a click on the ‘more’ link.
- The job progress widgets are grouped in one single progress bar that shows eta, and total progress of all running jobs on your system. By default this group is collapsed, but if you like all the details, you can expand it with a single mouse click (persistent between plasma restarts btw) and will see all individual jobs.
- The icon to show/hide the popup is now not only animated when jobs are running, it also shows how much items (jobs and notifications) are there, and how much of them have been completed if some are still running. It even has a tooltip… one glance and you instantly know how much jobs are still running, even if the popup is hidden.
- The plasma notifications also show custom images, like kopete’s contact images.
- Probably forgetting some stuff here, and some bugs got squashed.
Of course there are supposed to be pretty pictures with an blogpost like this, so here you go (don’t get worried by the not so readable white text in front of the spinner icon, small problem with the Air colorscheme that will get adressed):
Because the tray uses extendergroups now to group running and completed jobs you can now even do insane stuff, like detaching the in-progress-jobs group to your desktop, in which case every new job will appear there on your desktop, but completed jobs will still appear in to tray’s popup (which is actually quite a nice configuration, as I found out when I tested it).
But keep those suggestions coming (well, only if they are good suggestions of course ;)), so the 4.4 systray can be even better 🙂
pindaBlog 
May 4, 2009 at 8:14 pm |
That sounds really nice so far.. although I got some small suggestions and a little “mockup” for you (actually I wanted to post it on the brainstorm forum but registering didn’t work (received no activation mail)):
1.) the number of completed jobs still doesn’t say anything to me (according to the screenshots — they are just wrong/unclear)
2.) how about grouping those notifications by type
o) hardware related
o) messages (mails, instant messaging)
o) file operations (copying, moving)
o) some_stuff_that_won’t_come_to_my_mind_right_now
I propose something like with the new dbus-systemtray (each program set’s the type of notification it sends, just as each program should define a category what systemtray icon it is (passive/hardware))
3.) how about integration of brightness control and such stuff (like ubuntu is just doing it with their notification framework) — I’ve heard something about a new framework for KDE some time ago but it seems like the discussions have stopped 😦
Yeah.. keep going the nice work you’re doing 🙂
May 4, 2009 at 8:16 pm |
Yes, well… I /do/ have one suggestion, that is, is it possible to insert the notification icon at the left side of all systray icons instead of the right side? So that the position of the other systray icons do not change. And so that I do not misclick one of the others…
May 4, 2009 at 8:42 pm |
Very nice, but it’s unclear whether this nice additions will be there in 4.3 or 4.4.
May 4, 2009 at 8:48 pm |
Nice features there…
My opinion is more and more that the pause/stop buttons need to be lots of bigger ones. So you can a) use them easily with touch screen and b) Old people can use and understand them more easily. Now they are so damn small that they dont even understand they are buttons.
I have again today supported few >60 years old users for Skype usage between them. And every one had problems with small buttons. They dont usually understand the UI at all, it is just a flat colored screen where they do not reconize the different elements, what does not come any better with different color schemas.
How does the “all task” progress bar move? Smoothly or does it jump when tasks gets completed?
One thing what I would like to see about this, is to get a own widget/plasmoid about this notification. I dont like at all it is tied to systray and it is pop-upping when there is something happening.
I liked the first implentation where there was a big blue (!) icon on panel like the current device notifier widget. You could see right away is there a something going or not. And it could be moved to other place without problem. And it was big enough for a) touchscreens and b) old users.
Sometimes it feels that usability experts forgets the old or handicapped people, even that they most of their times remember it.
Offtopic: One of these problems is on the KickOff menu, the application “Return” sidebutton is just too thin for accurate mouse usage. It should be much bigger or other way to get to root of application menu. Now you need to point to ~8px wide button what does not tell right away what it is. Many new (young) KDE4 users has asked first time from me that how they get back on the menu without closing it. After first time, they know how it works but… Still it is designed too much to be used on left corner of the screen ;-(
May 4, 2009 at 8:48 pm |
Brilliant.
I really like how it looks and I think you have made a good analysis of the use cases and have right to the end at solving the issues. At least I can say that I am represented in one of the groups you mentioned and the current solution sounds like a perfect fit.
I personally prefer the progress bars solid (without the blocks) but that’s just a matter of taste. And I guess some plasma styles will end up doing it that way, so no real problem there. The same goes for the “links” styles, I really don’t like underlines.
As a suggestion, I don’t know how much control over the Jobs this “job manager” has, but I think it would be really great to be able to control the job execution with simple drag and drops.
Use case 1:
Let’s say I put a bunch of directories to copy from my HD to my portable device. And of course since I wasn’t smart enough to first select them all and then drag them they are all copying in parallel slowing down a lot the process.
I would like to drag and drop the jobs one next to the other so that they get executed sequentially instead of in parallel.
Use case 2:
There are a bunch of files I want to download from the same web site, so I click on all the links, but I only want do download one at a time, so I would drag them all into a sequence. Suddenly I realize I want one of them really soon, so I just drag it on top of the sequence I have just created so that it executes in parallel immediately.
As for the GUI for it, I see it similarly as the Qt QDockWidgets work.
Well, there goes a suggestion. Don’t know if it is good nor feasible so take it with a pinch of salt…
Anyway, thanks already for this great gift!
ricard
May 4, 2009 at 8:55 pm |
Btw, I noticed you had a Fallout 2 game’s ISO on the copy-task.
From there I have found a a) resolution patch for Fallout 2 (I play game now with 1920×1200 resolution) b) different mods like textures etc.
http://www.nma-fallout.com/forum/dload.php?action=category&cat_id=15
May 4, 2009 at 9:41 pm |
Real nice work! 🙂
Just for the stats: I belong to the second group, you mentioned at the beginning… 🙂
…and the “insane stuff”, that you talked about in the end, sounds really promising! 😀
May 4, 2009 at 10:03 pm |
This looks great.
I do think however, there needs to be a way of disabling (certain types of) notifications for a period of time, as a productivity tool. It would be great to be able to have an option in the ‘advanced’ right-click window menu of (say) emacs or OOo that says “hide all notifications except ones originating from this window for the next 30 minutes” (for example). Sometimes you are working, (and downloading something in the background so don’t want to cut internet) and just don’t want interruptions for a while (but do want to to have the info available once you have finished work).
Just a thought. Would be great to make sure this kind of use case is considered in the notification architecture. See http://www.lightbluetouchpaper.org for a similar sort of idea.
keep up the good work,
cheers
M.
May 4, 2009 at 10:33 pm |
@friesoft:
1) yes, it looks like I was able to trigger a bug, which I can’t reproduce anymore now… it will need some further investigation. :p
2) might certainly be an idea, though it would probably make the most sense to have the same categories as the new systray spec. something to consider for 4.4
3) useful, but first somebody needs to step up to do that.
@ruurd:
hmm, then you would have the same issue if you have your systray on the left. dynamicly chosing the best position maybe? I’ll consider it.
@Makosol:
they will be in 4.3.
@Fri13: and I’m not even a usability expert…. but anyway, the nice thing is that the icon size of icons in the extender title bar (like the pause/stop) can be defined by the plasma theme. They default to 16×16, but you can make a theme that uses 32×32 icons if you’d like. There always obviously the tradeoff of saving screen real estate vs accessability, but as long as that stuff in configurable, I don’t see a problem. And with the new systray spec there’s not even a reason why systray icons need to be 22×22, but you can have a systray with giant icons.
I’ve seen a couple of requests for having the ability to move the position where notifications/jobs appear, and it’s something I’ll consider for 4.4.
The global progress moves smoothly btw.
@richard:
I’m not sure your use case is important enough to be worth investing much in. If you’d come up with a way in which it doesn’t complicate the GUI i’d be intersted, but for now I think the use case is too specific.
May 4, 2009 at 10:59 pm |
Rob, this looks really good! I think you have addressed all issues I had with the notifications in 4.2. I more excited about 4.3 every day. 🙂
One question: is there some sort of logging function for completed jobs? It would be great if they could be looked up even after they have been shown for a few minutes and then destroyed.
May 4, 2009 at 11:40 pm |
Yeah I second Ruurd. Please oh please make the icon on the left side or at least make it some way fixed, because i’ve already missed too many clicks in the systray or even other parts of the panel due to incoming kopete messages.
In fact I think I’m going to file a bug for this 😛
May 4, 2009 at 11:54 pm |
I’d like to second Ricard comment as for preferring the progress bar solid without blocks. Actually I remember it being called a temporary design in the past so I’m, surprised it is still in use. In any case progress bars as blocks are bad usability as the width (“unit”) of blocks is totally arbitrary and hides small progresses from the user. Especially with progresses that take long this pretty much defeats the very purpose of a progress bar. /rant
May 5, 2009 at 12:40 am |
@Malc: I believe seele (from the kde usability team) wanted to look at ways to not immediately display all notifications, but delay depending on circumstances. Could be sweet,
@mutlu: no, I will implement something like that for 4.4, but didn’t have time enough to accomplish that for 4.3. As a ‘workaround’ you can detach completed jobs of interest: detached items don’t get destoryed automatically.
@Anon: that’s up to the theme. I’m not sure if this is the definate look of the progress bar for Air. I’ve actually not updated air for quite some time now, so these screenshot don’t even reflect the current state of Air. But then the theme is not really what this blogpost is about….
…. but to say it is bad usability because it defeats the puropose of a progress bar is a bit odd imo. I believe the purpose of a progress bar is to show at a quick glance how much of the job is completed. You don’t need an accuracy of 0.3% for that. /rant
May 5, 2009 at 1:10 am |
Overall this looks incredible. However I have a stupid question. In the first screenshot, one of the copy jobs is progressing at 0/Bs and it has an estimated time of completion of 0 seconds.
Shouldn’t it just not list an estimated time of completion rather than say it will be completed in 0 seconds?
May 5, 2009 at 1:20 am |
@T.J. Brumfield: that’s no stupid question, it’s actually a very good suggestion, I’m fixing it right away.
May 5, 2009 at 11:06 am |
Just one additional idea:
Maybe its a good idea to only trigger the autohide if there is some action (like screensavers are triggered). So if i go to the toilet i wont miss an incoming message.
May 5, 2009 at 1:19 pm |
Really looking forward to it and i hope pidgin will get some sort of integration plugin as well, because kopete is one of the 2 things dragging kde4 atm (the other one is konqueror).
May 5, 2009 at 2:21 pm |
IMHO the application should be able to tell if it the job should be auto-hidden or not.
IMHO this is pretty important when copying files to removable medias. Indeed, when copying a file to a removable media ( USB HD or USB keys ), you should :
– open dolphin on the removable media
– copy the files to the media ( normally from dolphin )
– when the copy is complete, select “remove safely” to ensure that files are correctly copied on the media
– then remove the media.
It means that you need to know precisely when the copy is finished, but also you should be proposed to select the “safely remove” option if needed as you may screw your USB key/datas.
New users tend to have a very limited “view”. What I mean if the fact they only clearly see a tiny portion of the screen at a time, and have a bad peripheral view. because of this, if you display the job window, and then hide it, then won’t be able to see where it have been hidden, and may not even noticed the icon in the notification area, or understand the meaning of it. That’s why also the animation when hidden the job dialog should clearly show that the dialog is being reduced in the systray.
It’s the same thing that Aaron say when speaking about magical appearance ( or disappearance ). You should have a clear transition between the two states/locations.
So IMHO :
1. when someone copy files from dolphin to a removable device, Dolphin should told to no hide the job by default. Now smart/advanced users could still click on “hide this job” and fall back to present default behavior ( job is hidden, progress is shown in notification area ). This will allow new users to know what’s going.
2. at the end of the job, we should even have the ability to “remove safely” ( umount ) the removable device. It means that applications should be able to defined customs actions to do when a job is finished and allow users to do the action or not. Of course, i guess that this can’t be some application specific actions, except if this can be handle by DBUS calls. Most of the time it could be phonon or solid ones.
May 5, 2009 at 2:44 pm |
In the mockups all the path/filename examples are nice an short and not truncated.
One of the major gripes I have with these notifications is not being able to extend the view horizontally to read the full path/file.
Before now I’ve launched 2 copies of nearly identical deep folders and not been able to distinguish between the notifications because I couldn’t expand the view.
Fixed sized views are the sort of thing I expect from Micro$oft, not from FOSS.
May 5, 2009 at 2:56 pm |
How about the progress notification in the task bar as described here:
http://forum.kde.org/easy-beautiful-progress-notification-in-the-task-bar-t-43570.html
that is the second most popular idea in the forum.
May 5, 2009 at 3:13 pm |
I’ve done a more detailed proposal on my blog with more proofreading 😉
http://www.linux-wizard.net/blog-kde_4_job_notifications_medias-283.html
May 5, 2009 at 3:46 pm |
@Alan: Actually: you can just drag the corner of the popup and drag to make it bigger… 🙂
@Paul: Would be nice if somebody implemented that. The dataengine is already there, implementing that would probably not be too hard.
@FACORAT: nice and constructive proposal, thanks. Allowing apps to provide custom actions (like unmount) is something we were actually planning to add to add some point (4.4 hopefully). Something like the extra don’t hide option could be considered as well.
May 5, 2009 at 7:13 pm |
Ah yes, this will help things quite a bit. For my two cents 😉 i’d like to see icons in panel split up into a notification system and another box for utility-applets. The systray is a definitely over-encompassing concept including notifications, utilities (like turning the sound up and down) and application launchers (like the calendar). Any thought of adding another box for sysutils? Or maybe even a break in the systray box would do.
Good work. Be nice to see these changes in a future version of KDE.
May 11, 2009 at 6:34 pm |
[…] oryginalny wpis… […]
September 13, 2009 at 6:26 am |
Hi,
I have just tested the new notifications and jobs from KDE 4.3 and it is really nice. Much better than the previous version. Congratulations!! But I still have one bug left…
Sometimes a kopete event takes place and I’m notified – e.g. a message arrives. The notification appears fine to me but when I click in the “view” or “ignore” button, nothing happens and this notification stays there for good… there is no way to acknowledge this notification and it stays there in the queue until I logout.
Perhaps kopete is sending a buggy message anyway, but the notification area should be more robust and provide, for example, a way to clean the queue of events.
Thanks for your important efforts!