Project

General

Profile

Feature #1891

Notification area animations

Added by skyjake about 10 years ago. Updated almost 5 years ago.

Status:
Progressed
Priority:
Low
Assignee:
skyjake
Category:
User experience
Target version:
User interface
Start date:
2014-10-28
% Done:

10%

Tags:
UI, Client, Widgets

Description

The animations occurring in the notification area could be improved further. For instance, if an alert notification simply disappears suddenly on its own after a few minutes it could be misunderstood as the problem having "fixed itself".

  • When there is only a single notification visible, its showing and hiding is animated with vertical motion. However, if there is more than one notification, the widgets simply appear and disappear with no animation. The same vertical motion should be individually applied to each notification. In practice, this calls for a redesign of the notification area widget's implementation.
  • Notifications could also/alternatively be made to fade away when they are hidden rather than abruptly disappearing.
  • Any notification should support an animation that further signals activity / tries to get the user's attention: a pulse, flash, etc. It would be beneficial if the notification area widget was responsible for these effects, so that individual notifications wouldn't have to handle it.

Related issues

Related to Feature #1848: Auto-hide warning indicator after X minutesClosed2014-07-22

History

#1 Updated by skyjake about 10 years ago

  • Related to Feature #1848: Auto-hide warning indicator after X minutes added

#2 Updated by vermil about 10 years ago

May I suggest consideration of visually different 'pulse' types depending on issue type. Let's say resource, engine and map?

I suppose one can set the warning indicator to only appear when certain issue types come up, but if the user leaves the settings at default or wants it to display multiple types of issue.

To be really crazy, perhaps the option to split the currently one warning indication log, into multiple smaller ones; each type of warning get's it's own log (i.e multiple logs on screen)?

I personally also think the log could contain a little more information to go with each alert. The map number for map alert's, the pwad/source for resource alert's etc.

#3 Updated by vermil about 10 years ago

I am reminded, that the post reply button on here (the trackers) is perhaps incorrectly called 'edit' even though it, as mentioned, posts a reply.

#4 Updated by skyjake about 10 years ago

vermil wrote:

option to split the currently one warning indication log, into multiple smaller ones

I kind of like this idea of having a separate indicator for each subsystem. That would afford another way to configure per-subsystem preferences like auto-hiding time and alert enabling, via the notification popups.

the post reply button on here (the trackers) is perhaps incorrectly called 'edit' even though it, as mentioned, posts a reply.

Yeah that's a bit of excessive generalisation in the Redmine UI: you "edit" an issue to add a comment, rather than replying or commenting directly. (BTW, I just upgraded our Redmine to 2.5.3.)

#5 Updated by danij about 10 years ago

skyjake wrote:

separate indicator for each subsystem

To me this seems like unnecessary complication. I really can't see any real benefit in having alerts behave and look differently for each subsystem.

vermil wrote:

I am reminded, that the post reply button on here (the trackers) is perhaps incorrectly called 'edit' even though it, as mentioned, posts a reply.

I agree. The way this Redmine skin organizes and labels the buttons is very unintuitive. I've just mistakenly edited skyjake's post above when trying to quote it...

#6 Updated by skyjake about 10 years ago

I restored the accidentally deleted comment. We can certainly look into better Redmine themes, although I'm pretty sure much of this is beyond a skin's ability to fix.

#7 Updated by skyjake about 10 years ago

  • % Done changed from 0 to 10

#8 Updated by skyjake about 10 years ago

Marking 10% progress because the notification area ownership model has been revised to work via relays. This gives the notification area more freedom in terms of how the notifications can be handled.

#9 Updated by skyjake over 8 years ago

  • Status changed from New to Progressed

#10 Updated by skyjake almost 5 years ago

  • Priority changed from Normal to Low

#11 Updated by skyjake almost 5 years ago

  • Target version set to User interface

Also available in: Atom PDF