Mantis Usability Review
A critical review of usability of the "Mantis bug-tracking tool":http://www.mantisbt.org/ , based on my several-year experience and prompted by the apparent simplicity of "Flyspray":http://flyspray.rocks.cc/bts/ (at least a first-sight simplicity).
Done on versions 0.18.2 (tweaked, installed on https://jumbo.fav.zcu.cz/mantis/) and 0.19.2 (on http://www.kiv.zcu.cz/services/bugs/). The version of Mantis to which a problem applies, is indicated as [v18], [v19] or [all]; perceived severity of the problem is indicated by + to +++ tag.
General
Problems
- [all ++] bug IDs? hard to read The leading zeroes in bug IDs? should be stripped off, since they make the IDs? hard to read. They are a nice example of information noise, btw :-)
- [all +++] too many borders and boxes Pages tend to be really cluttered and noisy - all those (table) borders, mosaics of different cell backgrounds, etc create a lot of visual noise. In the end, these separator elements are countereffective, making information harder to find.
- Suggestion: subdue borders and link underlines where they are functional, remove where not (e.g. main menu, end-page parts of the View Bug page), use simple list-based design instead of tables in View Bug page details part, use a palette of similar color hues.
- [v19 ++] slow page generation The performance of this Mantis version is really sluggish, making it hard to use even on decent hardware. For a reference, here are saved pages with queries executed taken from our server: when viewing for the first time and after logging in.
Bug list page
Reference screenshots:
Summary: Flyspray has it right :)
Problems
- [v18 ++] bug summary hard to find The most important piece of information for a BT system is not emphasized and is put to the right of (which is most often interpreted as "behind in importance") items like category and # of notes which are less important.
- Suggestion: order items as follows: [ ], ID, Category, Priority, Severity, Summary, #, Status, [Update]. I'd suggest dropping the Updated column (Status is more important), and use "Pri" as Priority column heading ("P" is unclear).
- BTW, dropping Updated should also speed up the page generation, esp. on long bug lists, since obtaining that date needs to be done on every single bug report separately, resulting in as many queries as are the bugs listed. See pages with queries (a ZIP file).
- [all +++] bug summary not clickable The most obvious way to click-open a bugreport does not work; instead, obscure bug ID has to be clicked.
- [v19 ++] filter section too complex
- Suggestion: by default, have only a single line with stored filters dropdown, let the user click-open the whole section on demand only
- [v18 +] page too wide When the Categories names are long, the page width is unwieldy (see snapshot)
- Suggestion: set max-width for page, or better restructure bug list so that the problem does not occur
Bug view page
Reference screenshots:
Summary: Flyspray has it right :)
Problems
- [all +++] page top cluttered The top part of issue simple details table (from ID down to Status/Product Version in 0.19) is tall, scattered, hard to scan for information. Especially the important Severity, Status, Assigned to, Summary and Description fields are hard to find.
- Suggestion: Put category, severity, priority, status, assigned to+last update together in a prominent place. Put reporter+date submitted, view status, etc. under these, subdued. Emphasize summary and description block. Look at Flyspray bug page design ;-)
- [all ++] page bottom cluttered by boxes Below the Update issue etc buttons, lines and boxes have turned loose.
- Suggestion: The Relationships and Monitoring users boxes don't actually need the borders, they can be formatted as simple list. The Upload file box should be merged with Attached files line. The Add note box should be merged with the Notes part. Look at Flyspray bug page design ;-)
- [all +++] simple view same as advanced There is apparently very little difference between the simple and advanced views of a bugreport. Most importantly, these two views do not differ in complexity -- the advanced basically only adds the platform, steps-to-reproduce etc fields. There is no added value in the advanced view report, or - worse - the simple view is not simple. (Version 0.19 is a little better - simple view is simpler - than 0.18)
- Suggestion: (1) reduce the simple view to basic facts on the bug report only (summary, description, status+priority, assigned to). (2) format it in a simple way, emphasizing summary and status.
Summary page
Reference screenshots:
Problems
- [all ++] page cluttered The layout of the page makes it hard to find specific information, since the individual report boxes are just stacked upon each other without any hierarchical ordering.
- Suggestion: Level one improvement: group the boxes into regions "Bug stats", "Reporter/Developer stats", and try to merge boxes that logically hang together (status+severity, resolution+priority, by date + time stats). Level two improvement: split the page into several pages (along the lines of e.g. My Account) leaving only most vital stats (I'd suggest status, category) on the Summary front page.
Back to HomePage
