Bug 547568

Summary:	ABRT icon animates
Product:	[Fedora] Fedora	Reporter:	Dave Malcolm <dmalcolm>
Component:	abrt	Assignee:	Jiri Moskovcak <jmoskovc>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	anton, dfediuck, dvlasenk, iprikryl, jmoskovc, kklic, mnowak, npajkovs
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-01-29 13:27:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	555378
Bug Blocks:

Description Dave Malcolm 2009-12-14 23:31:58 UTC

Description of problem:
ABRT embeds an animating icon in the panel when crashes happen.

Version-Release number of selected component (if applicable):
abrt-1.0.0-1.fc12.i686

How reproducible:
Every time something coredumps

Actual results:
Continuously animated icon in panel, drawing my attention away from whatever task I want to be focusing on.

Expected results:
Icons in the panel should not animate.  Quoting the GNOME Human Interface Guidelines:
http://library.gnome.org/devel/hig-book/stable/desktop-notification-area.html.en#notification-area-animation

"2.4.3. Animation Guidelines
_Icons should not usually appear animated_ (emphasis added). They may change to indicate a change of state, but should not do so when that change is occurs regularly rapidly. A battery status indicator would usually change slowly, therefore an icon is appropriate. By contrast, a load meter would always be changing, therefore it should use a flat image.

Any icon may blink to indicate an error in deference to showing an alert. For example, a printing-in-progress icon may blink when there is a paper jam, but not when the printer is on fire - that should show an alert. (arguably ABRT _is_ showing an error here, but as a user I did not choose to have it appear, so I don't see that it should have the right to blink here).

Do not rely on blinking or animation as a means of alerting the user to any particular event.
"

Comment 1 Denys Vlasenko 2009-12-15 08:52:51 UTC

New version will have code which makes icon stop blinking after 1 minute. Is this good enough for you?

Comment 2 Michal Nowak 2009-12-15 09:00:14 UTC

I'd appreciate if the animation is completely gone. One minute is too long, one loop of the animation is max I can live with.

Comment 3 Denys Vlasenko 2009-12-15 10:09:27 UTC

The quoted text says "icon may blink when there is a paper jam". I think a segfault or kernel oops is an unusual enough event to be highly visible too. I don't want to remove blinking completely. Will reduce to 30 sec.

Comment 4 Scott Schmit 2010-01-10 17:42:19 UTC

I think it's a good thing to flash long enough to be noticed -- some bugs that ABRT catches would never get correlated with what the user did if there wasn't immediate feedback that something broke. (Particularly selinux denials)

Comment 5 Michal Nowak 2010-01-11 10:13:21 UTC

I still tend to think that icon pop-up (+ max 1 iteration of the siren) is quite enough.

Comment 6 Denys Vlasenko 2010-01-18 15:07:30 UTC

It's impossible to satisfy you all guys at once

I think current behavior is satiasfactory.

Reopen if you disagree, and explain your rationale.

Comment 7 Dave Malcolm 2010-01-18 17:24:02 UTC

> It's impossible to satisfy you all guys at once
Agreed.

Reopening this bug: to satisfy "everyone", the design of ABRT needs to spell out who the target user is, and needs to satisfy those people.

The best-practice for doing this is via the use of "personas". 

I've filed bug 555378 to try to get help from user-interaction experts on this; hopefully they'll be able to help define who the application is for, and use that to work with the ABRT developers on an overhaul of the UI.  In the process of doing that, they should come up with a design for the notification part of the user experience, in a way that satisfies the target users.

Comment 8 Denys Vlasenko 2010-01-29 13:27:57 UTC

Our DESIGN document says:

We want to catch kernel oopses, binary program crashes (coredumps)
and interpreted languages crashes (Python exceptions, maybe more
in the future).

We want to support the following use cases:

* Home/office user with minimal administration

In this scenario, user expects that abrt will work "out of the box"
with minimal configuration. It will be sufficient if crashes
just show a GUI notification, and user can invoke a GUI tool
to process the crash and report it to bugzilla etc.

The configuration (like bugzilla address, username, password)
needs to be done via GUI dialogs from the same GUI tool.

* Standalone server

The server is installed by an admin. It may lack GUI.
Admin is willing to do somewhat more complex configuration.
Crashes should be recorded, and either processed at once
or reported to the admin by email etc. Admin may log in
and manually request crash(es) to be processed and reported,
using GUI or CLI tools.

* Mission critical servers, server farms etc.

Admins are expected to be competent and willing to set up complex
configurations. They might want to avoid any complex crash processing
on the servers - for example, it does not make much sense and/or
can be considered insecure to download debuginfo packages
to such servers. Admins may want to send "raw" crash dumps
to a dedicated server(s) for processing (backtrace, etc).

As you see, GUI is targeted at home/office users. I don't understand what is the problem with flashing notification for these users.

The flashing period has been reduced (in git, expect it in 1.0.5) to just three seconds.

Closing this bug, please reopen and let me know your concerns.