#180: ABRT2 gui review
Reporter: jmoskovc | Owner: kirkb
Type: usability assessment | Status: assigned
Priority: major | Component: Interaction Design / Usability
Severity: Moderately Involved | Resolution:
Comment (by elad):
Not a designer, just dumping my opinion here:
Basically I think the "wizard" isn't a good approach, it might be a
and powerful UI for advanced users, but scares away newbies.
I think that a window that will simply say "blah blah has crashed", with
the icon of the application (name and icon should be pulled from the
desktop file), and have a text-area for comment, and a text similar to
"Please report this problem! it will only take a few moments and will help
us fix it".
When the user is done writing the comment:
1. If it's the first time, the GUI should ask for bugzilla user name and
1. the GUI should also present an option "always use retrace server" -
enabled by default
2. the GUI should present an option "I do not want to verify the
backtrace every time, and I understand that fedora will not be responsible
for any private data that I may send by mistake" - disabled by default.
* That's because the backtrace is not understand-able by beginners and
they probably won't know whether it contains private information or not.
2. After the first time configuration (or if such configuration is not
needed), the window should proceed to the next step - analysing and
1. Short, simple, status messages, such as "Gathering data",
"Uploading", "Analysing", "Checking for previous reports",
2. Should be a small window, with progress bar and status only.
Something like the nautilus file copy window.
3. A button that will expand the window to show more details for
advanced users is fine, but showing the details by default is not a good
3. When the reporting is done, the window should display the link to the
bug report and a small explanation such as: [[BR]]
"Thank you for your bug report, we really appreciate it. You'll get email
notifications for changes made in the report and for added comments, and
you should help the developers by responding to their questions in the bug
report." (the wording is not so good, but that's the general meaning).
Other nice-to-have UI improvements:
* Packagekit integration. when the user starts reporting a bug, ABRT
could query packagekit to see if there are any updates to the software
that crashed or to the libraries it uses, and recommend the user to update
the package if there is an update available, with text that explains that
the problem might have been fixed by this update. It shouldn't force users
to update though, and should allow reporting even if the package is a bit
* Extremely friendly notifications for specific bug status change, for
example, if the bug gets a NEEDINFO flag, a notification should be
displayed to the user, something like "We need some more info to fix your
problem in <application name>" and a link, or, if the bug is closed with
the ERRATA resolution, then a notification should be shown: "We fixed your
bug! thank you for your report. an update with the fix will be available
soon for you".
One might argue that those notifications are not needed because we have
email notifications, well, this is exactly the reason we need those
notifications. take [https://bugzilla.redhat.com/show_bug.cgi?id=539756
bug #539756 ] as an example, it gets a new CC every week, and every one
who ever "reported" this issue using abrt is getting a message for every
new CC, resulting spam that users will quickly "learn" to ignore. So there
are two solutions: either improve bugzilla not to send emails on new abrt
CCs to everyone who was added to the CC by abrt (but do send message for
users who were added to the CC manually), or implement this two simple
status notifications in ABRT. The second one is easier to implement IMO.
* A button ladled "why report bugs?" that will open a web page or a
document with an explanation about the progress and why is it so
Ticket URL: <https://fedorahosted.org/design-team/ticket/180#comment:6>
Design Team <http://fedoraproject.org/wiki/Design>
Fedora Design Team