Fedora Account System
Red Hat Associate
Red Hat Customer
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. "
New version will have code which makes icon stop blinking after 1 minute. Is this good enough for you?
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.
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.
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)
I still tend to think that icon pop-up (+ max 1 iteration of the siren) is quite enough.
It's impossible to satisfy you all guys at once I think current behavior is satiasfactory. Reopen if you disagree, and explain your rationale.
> 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.
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.