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

Personally, I think the "in app" thing is great. Those would work well for situations that require requesting user input.

However, we need to be very careful about how we open them. If we want to permit opening them from a background thread then they can't steal focus or cause any click targets to move (it would be really annoying if a notification opened just before you clicked and caused the button you were aiming for to move out of the way).

That means the notifications should probably not push other things out of the way and should overlay a region of the screen that isn't normally used for click targets or widgets with focus.

For this reason, I'd suggest drawing these notifications on top of either the toolbar (at the top) or status bar (at the bottom).


On Wed, Sep 21, 2016 at 7:45 AM Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:
I think this is great.

Any feedback on in-app notifications as shown in the linked screenshot?

-Gunnar

--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/






> On 21 Sep 2016, at 05:56, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
>
> >Â (eg. a job finished, an automatic update was installed, there is new commits available at origin, etc.)
>
> I think if we permit this sort of thing, our users will just get in the habit of ignoring all notifications without reading them. The fact that they're less annoying than dialog boxes shouldn't be an excuse to start opening them for every little thing. Really, we should only open them for the sorts of things we currently open dialog boxes for. If our UI guidelines state clearly the sorts of situations where notifications are permitted and we police that policy within the IDE, we should be able to prevent the majority of abuse.
>
> We should also probably collect metrics on Eclipse.org about the clickthrough rate for each notification type. If users aren't clicking on certain types of notifications, those notifications should be off by default.
>
> On Wed, Sep 21, 2016 at 5:18 AM Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:
> 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
>
> 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
> _______________________________________________
> 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