[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Notification bloat (4.xx)
From: Celeste Lyn Paul <celeste () kde ! org>
Date: 2014-05-24 0:54:08
Message-ID: CAAfNz7YQEYdT2aNh29dfLRD-Puj380cBYbBKbrND9RiFHkKAtQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
There definitely needs to be better logic when it comes to showing certain
types of notifications. One of KDE's strengths is that all notifications
are channeled through the same system, and so KDE can control the behavior
of all notification interruptions.
I'm not sure at what level this "behavioral logic" needs to live -- I
assume knotify but I'm not 100% sure what all lives there versus plasma.
For example: You are downloading many files. Some take a short amount of
time, some take a long time. Regardless, it is not uncommon that you get
several notifications -- one after another -- to say: your file is down. It
would be trivial to the user to delay some of these notifications a few
seconds to minimize interruption. E.g., maybe don't show a notification of
the same type of message from the same application within x seconds.
Notifications that are not important can be hidden in the history.
Notifications that are important can have a delayed display until x seconds
has passed or the user isn't doing something important (like typing).
As I said, just one example. I'm sure we could come up with a dozen use
cases like this. I guess the question is if it would be worth it enough to
the user to invest in smart logic like this in the next version of knotify.
Many times applications currently control this some of this level of
behavior, but maybe it is something that should be enforced at the KDE UX
level?
Just a thought.
~ Celeste
On Fri, May 23, 2014 at 4:58 PM, Mark Gaiser <markg85@gmail.com> wrote:
> On Thu, May 22, 2014 at 8:41 PM, Christoph Feck <christoph@maxiom.de>
> wrote:
> > On Thursday 22 May 2014 20:23:00 Mark Gaiser wrote:
> >> Hi,
> >>
> >> First of all, i have no solution for this. I've just observed an
> >> issue with the notification system that might benefit of
> >> improvements when we all brainstorm here about how it should
> >> behave. This is for KDE 4.xx, but i'm guessing the actual
> >> notifications are the same in plasma next. Please do correct me if
> >> i'm wrong.
> >>
> >> Just a few minutes i noticed a few things when i was:
> >> 1. downloading a few files using ktorrent
> >> 2. copying a few files in dolphin from X to Y
> >> 3. wireless network connection lost
> >>
> >> Point 3 is obviously a notification i want to see and know about.
> >>
> >> But 1 and 2 are not notifications that i care about. I don't even
> >> think they should be part of the "notifications" as they are now.
> >> They should just be short lives messages to tell me something and
> >> probably just disappear when they are not useful anymore. I don't
> >> think they should be persistent and pile up in the notification
> >> area as they do now.
> >>
> >> Slowly but steadily more applications start using the notification
> >> area. Which is great, no doubt there! But the amount of persistent
> >> notifications (that i need to click away for the notification
> >> bubble to become clean again) is beginning to be annoying.
> >>
> >> What's your opinion here?
> >
> > I have disabled "File transfers and jobs" in Notification Settings.
> > The old style progress window only appears when operations are not
> > completed immediately, and closes without any trace once they have
> > finished (unless I request to keep it open). Plasma notifications for
> > "progress" type notifications should also work this way.
> >
> > If you want more opinions, please also read the bugzilla entries for
> > plasma/notifications. Users there generally agree that the current
> > notifications are not without annoyances.
> >
> > Christoph Feck (kdepepo)
> > _______________________________________________
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
>
> Just out of curiosity, where did you find the option to disable "File
> transfers and jobs"? I can't find it in system settings ->
> "Application and System Notifications".. And i can't find another
> place to change notification settings. I was expecting a right mouse
> button on the notification bubble to give me a "Notification Settings"
> but there is nothing like that.
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
--
Celeste Lyn Paul
KDE Usability Project
www.kde.org
[Attachment #5 (text/html)]
<div dir="ltr">There definitely needs to be better logic when it comes to showing \
certain types of notifications. One of KDE's strengths is that all notifications \
are channeled through the same system, and so KDE can control the behavior of all \
notification interruptions. <div> <br></div><div>I'm not sure at what level this \
"behavioral logic" needs to live -- I assume knotify but I'm not 100% \
sure what all lives there versus plasma.</div><div><br></div><div>For example: You \
are downloading many files. Some take a short amount of time, some take a long time. \
Regardless, it is not uncommon that you get several notifications -- one after \
another -- to say: your file is down. It would be trivial to the user to delay some \
of these notifications a few seconds to minimize interruption. E.g., maybe don't \
show a notification of the same type of message from the same application within x \
seconds. Notifications that are not important can be hidden in the history. \
Notifications that are important can have a delayed display until x seconds has \
passed or the user isn't doing something important (like typing). </div> \
<div><br></div><div>As I said, just one example. I'm sure we could come up with a \
dozen use cases like this. I guess the question is if it would be worth it enough to \
the user to invest in smart logic like this in the next version of knotify.</div> \
<div><br></div><div>Many times applications currently control this some of this level \
of behavior, but maybe it is something that should be enforced at the KDE UX \
level?</div><div><br></div><div>Just a thought.</div><div> <br></div><div>~ \
Celeste</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, \
May 23, 2014 at 4:58 PM, Mark Gaiser <span dir="ltr"><<a \
href="mailto:markg85@gmail.com" target="_blank">markg85@gmail.com</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">On Thu, May 22, 2014 at 8:41 PM, Christoph Feck <<a \
href="mailto:christoph@maxiom.de">christoph@maxiom.de</a>> wrote:<br>
> On Thursday 22 May 2014 20:23:00 Mark Gaiser wrote:<br>
>> Hi,<br>
>><br>
>> First of all, i have no solution for this. I've just observed an<br>
>> issue with the notification system that might benefit of<br>
>> improvements when we all brainstorm here about how it should<br>
>> behave. This is for KDE 4.xx, but i'm guessing the actual<br>
>> notifications are the same in plasma next. Please do correct me if<br>
>> i'm wrong.<br>
>><br>
>> Just a few minutes i noticed a few things when i was:<br>
>> 1. downloading a few files using ktorrent<br>
>> 2. copying a few files in dolphin from X to Y<br>
>> 3. wireless network connection lost<br>
>><br>
>> Point 3 is obviously a notification i want to see and know about.<br>
>><br>
>> But 1 and 2 are not notifications that i care about. I don't even<br>
>> think they should be part of the "notifications" as they are \
now.<br> >> They should just be short lives messages to tell me something \
and<br> >> probably just disappear when they are not useful anymore. I \
don't<br> >> think they should be persistent and pile up in the \
notification<br> >> area as they do now.<br>
>><br>
>> Slowly but steadily more applications start using the notification<br>
>> area. Which is great, no doubt there! But the amount of persistent<br>
>> notifications (that i need to click away for the notification<br>
>> bubble to become clean again) is beginning to be annoying.<br>
>><br>
>> What's your opinion here?<br>
><br>
> I have disabled "File transfers and jobs" in Notification \
Settings.<br> > The old style progress window only appears when operations are \
not<br> > completed immediately, and closes without any trace once they have<br>
> finished (unless I request to keep it open). Plasma notifications for<br>
> "progress" type notifications should also work this way.<br>
><br>
> If you want more opinions, please also read the bugzilla entries for<br>
> plasma/notifications. Users there generally agree that the current<br>
> notifications are not without annoyances.<br>
><br>
> Christoph Feck (kdepepo)<br>
> _______________________________________________<br>
> Plasma-devel mailing list<br>
> <a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/plasma-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br> <br>
Just out of curiosity, where did you find the option to disable "File<br>
transfers and jobs"? I can't find it in system settings -><br>
"Application and System Notifications".. And i can't find another<br>
place to change notification settings. I was expecting a right mouse<br>
button on the notification bubble to give me a "Notification Settings"<br>
but there is nothing like that.<br>
_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br> \
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Celeste Lyn Paul<br>KDE \
Usability Project<br><a href="http://www.kde.org" target="_blank">www.kde.org</a> \
</div>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic