Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ui-best-practices-working-group] Notifications


----- Original Message -----
> From: "Gunnar Wagenknecht" <gunnar@xxxxxxxxxxxxxxx>
> To: "User Interface Architecture Working Group" <ui-best-practices-working-group@xxxxxxxxxxx>
> Sent: Wednesday, 21 September, 2016 3:18:34 PM
> Subject: Re: [ui-best-practices-working-group] Notifications
> 
> Here are how OS notifications work in two popular OSs:
> 
> http://www.howtogeek.com/223503/how-to-use-and-configure-the-new-notification-center-in-windows-10/
> https://www.macobserver.com/tmo/article/how-to-manage-os-x-notifications-and-notification-center

For the record:
Here is the GTK/Gnome way https://help.gnome.org/users/gnome-help/stable/shell-notifications.html.en .
And the API behind it is really clear and sane - https://developer.gnome.org/gio/2.50/GNotification.html .

> 
> I think it's important to realise that those notifications should be
> completely optional, i.e. users can configure their OS to ignore some
> specific apps. Thus they could be used IMO to inform the user about
> interesting things (eg. a job finished, an automatic update was installed,
> there is new commits available at origin, etc.).
> 
> I - for example - completely disabled notification center in macOS because I
> dislike distractions.
> 
> 
> The other ones - the important notifications are the "in-app" notifications
> that are display inside an app. Something like this:
> https://bugs.eclipse.org/bugs/attachment.cgi?id=263138
> 
> I think those is the more important notifications. However, my concern is
> they will be abused by plug-in developers if we only add those to platform
> without OS level notifications.
> 
> -Gunnar
> 
> --
> Gunnar Wagenknecht
> gunnar@xxxxxxxxxxxxxxx, http://guw.io/
> 
> 
> 
> 
> 
> 
> > On 20 Sep 2016, at 20:28, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
> > 
> > I'd imagine OS notifications are fairly restrictive in terms of the sort of
> > content they can contain, and they might be fairly obtrusive on some
> > operating systems. Would they still pop up if Eclipse wasn't the
> > foreground app? Could we make non-expiring notifications that stick around
> > until acknowledged? How restrictive would they be.
> > 
> > A benefit of using OS notifications is that we'd get good platform
> > look-and-feel everywhere and notifications from multiple apps would
> > inter-operate smoothly. These would be pretty strong arguments in favor of
> > using OS notifications if we can... but we'd have to understand their
> > restrictions before we could understand how far we can rely on them in
> > Eclipse.
> > 
> > You make a convincing argument. IMO, it would be worth prototyping
> > something... or at least doing an analysis to understand what the
> > notification capabilities would be if OS notifications would be if they
> > were added to SWT. How hard would this be to do?
> > 
> > Also, no matter what sort of notifications we choose, we should establish
> > some UI guidelines for opening notifications and we should publish them
> > from day 1. If plugins start opening notifications for irrelevant stuff,
> > users will get in the habit of dismissing them without reading them,
> > making them useless. (I already do this for pretty much all mylyn
> > notifications.)
> > 
> > I'd suggest some initial criteria:
> > 
> > High priority notifications (everyone sees these):
> > - Something the user initiated has completed, and that thing has output to
> > show the user (besides "I'm done").
> > - A background operation requires user input to proceed (such as a
> > confirmation or the password for the key store)
> > - Direct 1-to-1 IM from another human
> > 
> > Low priority notifications (Off by default. Users only see these if they
> > explicitly opt in.)
> > - New software updates available
> > - Broadcast (1-to-many) messages from another human (mailing lists, bugs,
> > forum posts)
> > - Incoming Email
> > - New content available
> > 
> > Banned notifications (Nobody should ever see these)
> > - Notifications related to automated syncing of information
> > - Messages that just say "this job has completed"
> > 
> > For reference, here are the Android notification guidelines:
> > 
> > https://material.google.com/patterns/notifications.html#notifications-anatomy-of-a-notification
> > 
> > 
> > 
> > On Tue, Sep 20, 2016 at 12:58 PM Gunnar Wagenknecht
> > <gunnar@xxxxxxxxxxxxxxx> wrote:
> > I take the opportunity to switch topics. :)
> > 
> > 
> > 
> > > On 20 Sep 2016, at 08:12, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
> > >
> > > If we want to create a notification framework for Eclipse (to replace
> > > dialogs opened by background threads), there's a bug open for evaluating
> > > and porting the Mylyn notification framework to the Eclipse platform. A
> > > couple developers could probably finish this up in about a week.
> > 
> > 
> > My feeling is that these type of notifications are not what we should do
> > from a UI perspective.
> > 
> > There are different types of notifications. For some I would appreciate an
> > integration at the OS level to use the OS notification system (think about
> > something long running, asynchronous finished, an update has been
> > performed, etc). Others require more attention from a user and could be
> > visualised with a coloured bar in the window/view/editor (such as a
> > sign-in is required or other configuration).
> > 
> > Has this been discussed?
> > 
> > -Gunnar
> > 
> > --
> > Gunnar Wagenknecht
> > gunnar@xxxxxxxxxxxxxxx, http://guw.io/
> > _______________________________________________
> > ui-best-practices-working-group mailing list
> > ui-best-practices-working-group@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe
> > from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
> > _______________________________________________
> > ui-best-practices-working-group mailing list
> > ui-best-practices-working-group@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe
> > from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
> 
> _______________________________________________
> ui-best-practices-working-group mailing list
> ui-best-practices-working-group@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
> 

-- 
Alexander Kurtakov
Red Hat Eclipse team


Back to the top