Bug 555378

Description of problem:
Please forgive this overly general criticism, but I feel that the ABRT UI is in need of a full redesign, involving a User Interaction expert.

The entire GUI seems to be structured around implementation details of the application, rather than around the experience of the user, and I feel that the app could be significantly improved with a full redesign of the UI.

To try to make this more concrete: if I go to the "Edit" menu, the first item is "Plugins", which brings up a dialog for editing plugins.  This dialog appears to directly expose inner workings of the application, from the perspective of implementation.  As someone who merely uses the app, the dialog seems to me to be confusing to read, and extremely visually "busy"; it is essentially a collection of Enable/Disable checkboxes, but they are hidden in a fog of widgetry relating to the plugin infrastructure.

Next, the "Preferences" item:  this brings up a dialog named "Global Settings", and all of the options here appear to me to be "deep" implementation-level config: practically the first option is "Database backend" with an option to change from a SQLite3 backend to... no other possible options, and so it goes on.  None of the options are documented inline with the UI and there is no online help.  However, I'm not sure that any of these configurations settings should even appear in the GUI.

Similarly, when reporting a bug, all information is brought up in a 3-column list view, "Send", "Item", "Value", which appears to reflect the implementation details of how you're assembling reports.  Unfortunately this view is hard to figure out: individual rows vary greatly in height, making it difficult to see which checkbox in the "Send" column corresponds to the items in the other columns.  I have privacy and security concerns about sending certain information in certain reports, and it is difficult for me to quickly ascertain what information will be sent.  There appears to be no way to selectively anonymize parts of the report that are sent.  Basic navigation within this view can be difficult; some rows can be many hundreds of pixels high, and it's hard to see where rows begin and end, and if there are two rows hiding a third row between them that might e.g. contain password information.

I think the deeper issue here is to decide who the target users of this application are.  I believe that the design of this application needs to contain a statement of "personas" describing people who would use the application; see e.g. http://www.user.com/personas.htm

I believe that the application needs at least three personas:
  (a) a persona evoking a non-computerese user of the system, who's self-administering the system (e.g. a small businessman using OO.org spreadsheets who encounters a crash)
  (b) a persona evoking a sysadmin who is managing systems on behalf of others (either desktops, or headless servers) and trying to deal with the problems they encounter, be it due to bugs in the software, local/site-specific issues (e.g. "their intranet's down"), user-error, or malicious activity.
  (c) a persona evoking the maintainer who's receiving the bug reports and working with (a) and (b).

We have resources both within the Fedora community:
  https://admin.fedoraproject.org/mailman/listinfo/design-team
and within Red Hat itself who can help with this kind of design. CCing duffy who knows how to contact such resources.

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