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

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

Back to the top