So, it seems it’s that time of the year again… the plasmoid used in KDE Plasma Desktop to display notifications and the progress of transfer jobs started to really show its age, due to some bad limitations in the old QGraphicsview code to handle complex layouts, so it appeared quite buggy and not so smooth to use. Yes, I’m aware that sometimes it started to dance resizing itself several times in a row, and there wasn’t much to be done on that regard… Until now 😀
The fact that there is some research/development being made to build a new backend for notifications that will support many new features, more “modern” to be actually useful with the applications that are so heavily “communication” oriented(both desktop clients and web stuff), that became essential part of out workflow.
The story begins more than a year ago: we needed a way to display notifications on Plasma Active, and obviously the desktop applet used back then wasn’t enough.
Since we would have to rewrite it in QML anyways, we started it, at the beginning as a thing used only in Plasma Active.
Here below is the status that will be shipped together Plasma Active 3, in about 2 weeks (more on that later 😉
Then, as it became more and more feature complete, it was obvious that it could have replaced the one used in the desktop quite easily.
But wait, we have different input methods so we need two completely different things otherwise one won’t be usable on the other platform, right?
Wrong 😉 what we need is a different UI, and not even dramatically different: we need it adapted for a different input method and yet still familiar, the actual code difference needs to be very little.
In QML plasmoids, we can specify some files that will be used only in some platforms, so the system will automatically pick the most suited one. Also the basic component used (buttons, scrollbars etc) while having exactly the same API on all platforms, they can have a radically different behavior (or even, a completely different implementation).
Here is the plasmoid that is going to be merged and shipped with our next iteration of the desktop:
While it looks very similar, there are some important differences:
- Different theme/look (that was easy;)
- The desktop version has scrollbars, the touch version works by flicking and has scroll indicators that automatically appear/disappear
- The touch version has way bigger hit targets
- The desktop version has mouse over effects, the touch version doesn’t
- The text in the notifications can be selected with the mouse in the desktop version, and there is a right mouse button menu that allows to select/copy to clipboard
- Instead, with an horizontal drag on a notification on the touch version, it will be moved, and if “thrown” outside the window, it will be deleted.
Difference in code? a couple 100-something lines QML files that are chosen either one or the other, that’s it.
The desktop version has more or less the same functionality as the old version shipped with 4.9, the changes are mostly about making the ui a bit simpler.
Also, this new notifications plasmoid is all about the user interface. It has been designed to be as easy as possible to change (or add a new one) the underlying notification system, so it will fit pretty well in the new system that is being researched right now.
Why do the progress of a file being downloaded is threatened as a notification, IMHO, a progress of a file being download is not a notification it is an executing process, It could be OK to show the notification when the file download is finished, but why the progress?
One thing I really miss from Gnome 3 which I think you should consider is to remove the notification when the user activates the application which created the notification. What I use notifications for most of the time is getting information about what has happened while I was away or if something needs attention, if I give that application attention then I don’t need a notification reminder that I have to give that application attention. I don’t know if this is a regular usage pattern, but it worked very well in Gnome 3.
Other than that, it looks great!
What about making the notification height as the default monitor size? From top to bottom. That way, when you change a notification category tab, you don’t have to move your mouse to it down or up. IMO this will improve usability. Just like this: http://imageshack.us/photo/my-images/441/98866156.png/
Marco, I hope this time the widget won’t be dancing here and there. That really drives me mad. 😀
> What about making the notification height as the default
> monitor size? From top to bottom. That way, when you
> change a notification category tab, you don’t have to
> move your mouse to it down or up.
The notification category tab moving up and down also annoyed me in the video, but I’d suggest instead to move the category tabs to the bottom (if the panel is at the bottom) so that it always stays in the same place, no matter the number of notifications you have to display.
> What about making the notification height as the default
> monitor size? From top to bottom. That way, when you
> change a notification category tab, you don’t have to
> move your mouse to it down or up.
The notification category tab moving up and down also annoyed me in the video, but I’d suggest instead to move the category tabs to the bottom (if the panel is at the bottom) so that it always stays in the same place, no matter the number of notifications you have to display.
The mouse up and down caused by the application tab moving up and down also annoys me. But to fix it, I suggest to move the tab buttons _below_ the notifications, so they always stay in the same place.
huh, your site gave me an error whenever I posted a comment, and I didn’t realize the comment had gone through anyway (cause new comments appear at the top, while I thought they’d appear at the bottom — hey, notice a pattern?)…
btw, a comment system that doesn’t have the option of leaving back an email address means that whoever comments will surely not keep track of the discussion…
> What about making the notification height as the default
> monitor size? From top to bottom. That way, when you
> change a notification category tab, you don’t have to move
> your mouse to it down or up. IMO this will improve
> usability. Just like this: http://imageshack.us/photo/my-images/441/98866156.png/
In this example, the tab buttons are at the top, along with the panel, so I don’t think you’d get down and up anyway.
It’s when the panel is at the bottom, and the tab buttons at the top (and the opposite, of course) that you get the problem.
Site error I sometimes get is:
03AHJ_VuuuSartIPbyxkdD_kc3c7J4rkqZC3BLreE-LF4l80PT0YgumKIPt7azswYJfQ9VsHLgDpJDFVsIY4wnAa7TvZ_HF3vAFzI1eZDQykRmrPsCPT_iW7HX7eXdWWHS_I0UFoPNvumlbgxpJutqIzvbs-3h26hjUw WBmalt call > What about making the notification height as the default > monitor size? From top to bottom. That way, when you > change a notification category tab, you dont have to move
Warning: Cannot modify header information – headers already sent by (output started at /home/foskit/public_html/mart/phpwet/include/actions/submitnews.php:284) in /home/foskit/public_html/mart/phpwet/include/actions/submitnews.php on line 366
Removing notifications when the originating application is focused is possible right now, with the KNotification::setWidget() and CloseWhenWidgetActivated API among others, but the decision to use this has to be up to the app itself.
Simply gaining focus is insufficient unless the notification is always modally presented to the user on focus. Consider receiving an IM from Bob, then you focus a chat with Alice? Should the notification auto-hide? What if I focus the contact list, but don’t respond or dismiss the message from to Bob. Do I want to the notification to disappear? Download progress notifications should never be hidden on focusing the browser or filemanager.
UI guidelines recommending when to use this would help app authors, though
Removing notifications when the originating application is focused is possible right now, with the KNotification::setWidget() and CloseWhenWidgetActivated API among others, but the decision to use this has to be up to the app itself.
Simply gaining focus is insufficient unless the notification is always modally presented to the user on focus. Consider receiving an IM from Bob, then you focus a chat with Alice? Should the notification auto-hide? What if I focus the contact list, but don’t respond or dismiss the message from to Bob. Do I want to the notification to disappear? Download progress notifications should never be hidden on focusing the browser or filemanager.
UI guidelines recommending when to use this would help app authors, though
Let us see whether the comment will get through this time:
The first video shows exactly what is wrong with the notification system: way too much noise due to completely outdated notifications.
• “the screen is being locked”: please take your time, I want to use the screen right now
• “battery level is critical”: sure, except that I already plugged in the power cable – says so in the next notification
• “Frank is now offline”: again, he is online, says so in the next notification
• “There is an upcoming calendar event”: that was three hours ago, maybe consider using past tense?
Tips for commenting:
* do not use single quotes, since they cause errors
* make sure to fill in title and name, since otherwise will not be posted, there is no error message
* make sure no not use any special chars in the title
Are we still in the 90s?
Hi Marco,
That’s looking awesome!
And all in QML. The future is here ^_^
Ma sostituire l’antiquato Kickoff con qualcosa simile a Search & Launch via popup per esempio?
How will the notifications be visible when I watch a fullscreen movie? It’s the main reason I currently use Colibri.
It seems to me that auto-removing non-error notifications when an application receives focus should be the *default*, but that applications can override this if need be.
This seems like sensible behavior for most applications that just display notifications for attention (kmail, downloads, what have you) and means that not every single one of the applications out there needs to add special handling for notifications (aside from actually issuing the notifications, obviously).
In the Desktop version, isn’t it better to place the buttons (All, KMail, kdialog,…) at the bottom so when you click one and the notification plasmoid gets resized, the position of the buttons remain fixed?
God damn…. Sorry but the desktop version looks horrible!
You are forced to press small arrow buttons to scroll notifications and even blindly, they still get lapped above each other and jumps up and down without sense!
Grouping and all the close ticks and..
It is HORRIBLE!?
Why not simply do this while re-coding system? http://forum.kde.org/viewtopic.php?f=83&t=91258&hilit=Intuitive+notification+system
I find the animations too slow when a notification is being cleared.
I often find myself quickly cleaning out notifications (and this goes both for desktop and my Android phone) and looking at the video, I will have to wait for 0.5 seconds before clicking the next X icon or risk the interface shifting on me in mid-click.
IMHO animations should add just a little spice to the whole experience, not make me work slower.
I never, ever touch the (i) button currently because it’s too “hard to see through” for the first glimpse.
– It’s always full of uninteresting messages date back from the system startup. Who cares?
– Why the copying notification doesn’t show up? Just a little (i) indicates in one of the screen corner that something happened. It must be a nightmare to find out what’s happening for a newcomer. Why the (+) sign there? Do I add something? Or if I pressed that I can remove something with the (-)? Why do the horizontal bars exist on the detailed view? Do them make the speed-chart look more precise? Not think so, because the actual speed text is upon at least three lines.
– Why is it good that I can make the notification list disappear with my mouse wheel? Kinetic scrolling or how they call it.
I understand that the whole technology behind the notification is superior but the end user interface (I speak for myself) is bad.
Oh, another thing: was there any research done if anybody actually uses the grouping by application? If I wanted to see what’s new in KMail, I will simply open KMail, right? The possible exception here would be super important messages (like one of my IMAP akonadi resources going offline for some reason) but in the current case they get buried under notification spam anyway.
I agree with MK. Why not implementing this fresh idea:
http://forum.kde.org/viewtopic.php?f=83&t=91258&hilit=Intuitive+notification+system
It’s promoted at the unanimity on KDE brainstorm, this mean that the KDE users like it. Or if you disagree with that idea, can you explain why it would be not the correct solution for KDE.
I really do not like the current notification system and the coming one doesn’t seem so different.
I agree with MK. Why not implementing this fresh idea:
http://forum.kde.org/viewtopic.php?f=83&t=91258&hilit=Intuitive+notification+system
It’s promoted at the unanimity on KDE brainstorm, this mean that the KDE users like it. Or if you disagree with that idea, can you explain why it would be not the correct solution for KDE.
I really do not like the current notification system and the coming one doesn’t seem so different.
I think it would be better for Plasma Active to not have the close button (X), as the hit area for the other action (open the music file in the demonstration video) could then be made bigger. Touch screens with small hit areas too close to each other are really annoying. Not only do they slow you down, it is impossible to use on the move (running, walking, bicycling). Since it is possible to swipe the notification away, the close button is not needed.
For the desktop I agree with one part of the comment from MK (anonymous), the left/right buttons for changing to the previous/next notification are too small. Would it not be possible to let them fill the whole height of the “window” so that the scroll was performed when clicking the left/right edge. It’s frequently done this way in picture slideshows on WWW, so the user interface would feel familiar to most people.
Apart from that I’d just say we are at least moving in the right direction 🙂
Sure we would like magic, such as the notification somehow knowing that a new notification was related to a previous notification and could join the two “Joe Bloggs went offline at 18:35 but came back online just a minute later” or “I did tell you about your appointment before it came up, but now the meeting is already over”.
But let us be realistic and walk one step at a time.
Besides, it is not given that you would want the system to remove previous notifications, and certainly the notification system itself could not do it, so it would have to return a reference ID to the application, and every application would have to add insanely complex logic (and of course configuration settings) to determine which (if any) previously issued notifications were related to the one about to be issued, and what (if anything) it should ask the notification system to do with each of them.
Naaahhh. I’d rather be able to work on my system instead of having to wait four minutes for it to figure out what to do when it wants to notify me about something.
I completely agree with Sean, and can add another reason to justify it. Moving those buttons to the bottom moves them closer to the notification button, so there will be less mouse movement.
Less mouse movement means fewer sick days and a higher gross national product, so this should really pay off well.
Responding to Ramsees, I think it’s a User Experience issue. I perform an action that takes some time to complete, and then I want to be notified when it’s done. This action can be done in several different ways or browsers, but it’s still performing the same mechanics.
Considering the alternative is using a different download view for every browser, I applaud the integration into the notifications window (Especially with the sexy new QML version)
That feature about moving notifications to a custom position sucks for me. I like to have my notifications in their default position, but if I accidentally move them (most of all cases when I’m trying to close a popup) they are moved. And place them to their original position is not easy: you have to edit plasma-desktop-appletsrc (well… I’m not quite sure how it is named) and restart the whole plasma. Is there any chance to include an option to disable custom position? Thanks!
To me this seems like a very intuitive way of doing it. The counter examples further down in the comments would then mean that Telepathy or Kopete would have to do something and not every application that wanted a normal behavior.
KDE has had 2 UI failures since KDE 4.0 that are replicated in these videos.
1. As the shadow is part of ths SVG, the position where notifications start is not following the logical line of the icon, but it’s 4px or more to the right of where it should be.
2. There is NO visual indication that a button has been pressed, when it is pressed. The (i) icon is exactly the same before and after the panel appears, even though there is a notification panel displayed. So, no visual relationship between the (i) icon and the panel.
These points must be fixed,for usability’s sake.
@ Jargno
“To me this seems like a very intuitive way of doing it. The counter examples further down in the comments would then mean that Telepathy or Kopete would have to do something and not every application that wanted a normal behavior.”
What examples and can you clarify the last sentence? What Telepathy and Kopete? What every application? What a “normal behavior”?
@ Kjetil Kilhavn
“Since it is possible to swipe the notification away, the close button is not needed.”
The swipe isn’t following purpose of the GUI, what is that user can see right away what are available options. Thats why swipe shouldn’t be used as only way, unless it is natural action in some GUI parts, like dragging a position slider to another part. To swipe a view or other parts, isn’t good either.
The close button is better than swiping. As it is faster and easier to close multiple notifications than doing a gesture when holding device with one hand and extending hand top of the display to do a gesture. Then pressing X at same position (and same line compared to each other) is faster as it is easy just to continually press. Problem just is that X is small one when compared to whole notification size.
If notifications would be on side of the screen so user can just hold device with four finger and with thumb to slide notifications it would be better. But still it would not be familiar action as user does not see how to remove notification.
@ Kjetil Kilhavn
“Since it is possible to swipe the notification away, the close button is not needed.”
The swipe isn’t following purpose of the GUI, what is that user can see right away what are available options. Thats why swipe shouldn’t be used as only way, unless it is natural action in some GUI parts, like dragging a position slider to another part. To swipe a view or other parts, isn’t good either.
The close button is better than swiping. As it is faster and easier to close multiple notifications than doing a gesture when holding device with one hand and extending hand top of the display to do a gesture. Then pressing X at same position (and same line compared to each other) is faster as it is easy just to continually press. Problem just is that X is small one when compared to whole notification size.
If notifications would be on side of the screen so user can just hold device with four finger and with thumb to slide notifications it would be better. But still it would not be familiar action as user does not see how to remove notification.
What I mean is just that the suggestion:
“””It seems to me that auto-removing non-error notifications when an application receives focus should be the *default*, but that applications can override this if need be.
This seems like sensible behavior for most applications that just display notifications for attention (kmail, downloads, what have you) and means that not every single one of the applications out there needs to add special handling for notifications (aside from actually issuing the notifications, obviously). “””
Makes a lot of sense. If notifications would be implemented so that when a program got focused the notification of that application went away. Making the default behavior that a notification would be removed seems smart.
The counter example was:
“””Simply gaining focus is insufficient unless the notification is always modally presented to the user on focus. Consider receiving an IM from Bob, then you focus a chat with Alice? Should the notification auto-hide? What if I focus the contact list, but don’t respond or dismiss the message from to Bob. Do I want to the notification to disappear? Download progress notifications should never be hidden on focusing the browser or filemanager.”””
Which would mean that since the IM application does not want the default behavior they would have to code it in. Instead of every application which just wants the users attention on one window, like Kmail, Akregator and many others programs to specifically having to code for that scenario over and over again.