Registered Member
|
Recently, Firefox updated the browser and showed some info as a non-persistent notification. My attention is limited and I didn't read the info. After the short period where it is shown I have no choice to get a notification back from the void. This makes sense for info like 'copy done', 'no new mails' etc. but anything else might be interesting later. One could argue that it is up to the developer to decide whether an info is relevant and has to be persistent or not. But IMHO this is not the right way because UX shifts the responsibility. What I expect is some kind of notification history. The current list is useless to me since I dismiss all persistent notifications quickly - and notice later that it might have been relevant. An idea is to stack similar info like "42x No new mails", but that's also not really helpful. Any ideas?
|
Registered Member
|
Can you please give an example of persistent notifications.
What about "dismiss" would mean to hide the element and there is an option to reveal all hidden elements? Another example of showing past notification (and other events) to the user is the Mozilla Thunderbird activity manager. The list is not grouped in any way but sorted by time. The user can clear the whole list but not individual elements. If the use case is to look up some missed notification I wonder whether the grouping/stacking is needed at all. For example, the list of past notifications could store all notifications (persistent or not), sort by time by default and add a search box to make the list searchable. |
Registered Member
|
Persistent notifications are those that require user interaction to dismiss. For instance, security relevant stuff.
In KDE4 we had such a list of notifications, the new behavior was introduced since people disliked the "spam" there. 09:58:00 Checking Foo 09:57:59 File copied successfully 09:57:59 File copied successfully 09:57:59 File copied successfully 09:55:13 No new mails 09:51:32 Intrusion detection 09:50:23 File moved to trash 09:45:12 No new mails ... If it's not more than about ten notifications per hour a full list would be good, IMHO. But I'm afraid of much more. However, I'm voting for a new handling and suggested such a list. |
Registered Member
|
What about introducing severity levels as in application log files? There are different severities (Trace, Debug, Info, Warn, Error, Fatal) and the default severity displayed to the user is "Info". So your example list would look like this by default:
And if the user chooses to see the severity starting from "Debug", like this:
|
Registered Member
|
|
Registered Member
|
The concept of notification is weird on many levels. For instance it shows a tray icon for progress but actually with the number of actions. So if you copy a directory with a number of large files the icon displays 1 just like when copying only one small file. This number goes up if more actions are batched meanwhile. But what the user needs to know primarily is the ETA. The HIG states about progress that below 500ms the cursor should indicate lengthy operations and above it has to be a progress bar. Well done is the feedback for instance by the midnight commander, where one progress bar shows the total progress and another the current. And really nice from a design perspective is the implementation from Microsoft that modifies the progress bar by the transfer speed.
So my suggestion is to show copy actions in a plasmoid that is minimized by default (kind of cashew) and enlarges after 500ms. This plasmoid should show the relevant information, maybe with a nice graph etc. Notifications are useful for persistent information such as when something goes wrong. But when the user starts the action and watches the progress, there is no need to pop up the finalization. But first of all I would challenge the idea to separate copy progress from the application. Why not show the progress in the status bar with an option to get an overlay widget for interaction? Just like Mozilla Firefox. |
Registered Member
|
I could add that initially when switching to Plasma - though it still happens sometimes - I forget that the copying is still taking place, and have started to delete or move the directories where the files are being copied from/to. The systray notification icon is really hard to notice sometimes, especially if I'm copying something I expect to be tiny. Then I expect the copy action to be almost instant, and I'm not even looking for the notification icon. Then it turns out that it was actually huge, and suddenly I'm removing a directory while still copying!
|
Registered Member
|
Thanks for reporting this particular issue. The same thing is occasionally happening to me! |
Registered Member
|
With respect to the issue veqz reported it would be nice if the copy process/progress would be visibly more clearly - separated dialog or not. Quite recently, this was already added to Plasma 5.6 Beta, see https://dot.kde.org/2016/03/02/plasma-56-beta and https://www.kde.org/announcements/plasm ... wnload.png I also like it how Firefox is doing it. With "status bar" you mean the application's status bar and not the Plasma panel? A separated/global place where progresses are collected could still co-exist, couldn't it? |
Registered users: Bing [Bot], claydoh, Google [Bot], markhm, rblackwell, sethaaaa, Sogou [Bot], Yahoo [Bot]