Re: [mantisbt-dev] Mantis Usability

[John R. <jr...@le...>]

Patrick Schoenfeld wrote:
> Hi,
> 
> this time I'm not writing as the Debian packager, but as the
> administrator of a small-sized company, which uses mantis for overall
> bug and issue tracking. In the past several of our users complained,
> that overall look & feel of mantis is not very pleasure. They say that
> working with it is inefficient, mostly due to mantis beeing overloaded,
> wasting space, etc. I was puzzled a bit, because I'm a technician myself
> and felt no real problems, but yes, working could be "smoother", but
> unfortunately this is not so easy to do, as its a bit vague.

First, I'm curious what version of Mantis you're using.  There have been 
a lot of strides in the latest versions, especially in the development 
tree of 1.2.x.

> So I wanted to kick-off a discussion about this topic.
> I'll start with describing some common problems that have been
> communicated to me and some possible solutions. I hope nobody gets
> pissed by the explanations below. Naturally this topic is a bit
> emotional, so the explanations below might be just that. Please don't
> take it as an attack. Mantis is a good application, and the user
> interface is better then those most bugtrackers provide (bugzilla is a
> mess for example), but it could be a better work experience for not so
> technical people.
> 
> - Links to issues: In every link to an issue there is the numeric id of
>   the issue which needs to be clicked in order to get to the detail
>   page. Thats consistent through the complete interface, but confusing.
>   Obvious it is a really technical kind of view. Like the primary key of
>   a database item, but in fact it should be process oriented instead.
>   Question is: What would the user like to do? A link like 'Details' or
>   probably 'Edit' in-place would be more intuitive. One of my users even
>   suggested to make the whole line clickable. He said that he felt
>   uncomfortable with a little link instead of just the whole field to be
>   clickable. Like a button, where you normally can click anywhere and
>   not only on the text in the middle.

I assume you mean to have the entire link clickable in the View Issues 
or My View pages?  I agree that this would be helpful, but because this 
would require javascript, we would still need the physical link there 
for users without.

> - Projects and subprojects: This is really a weird thing. Subprojects
>   are defined by adding a new project, then going to the project that
>   should have it as a sub-project, choice the project created before and
>   say "Add this as a sub-project". Obvious this is not a really normal
>   workflow. It should be possible to just define new subprojects, even
>   those that does not exist yet in the project page. Similar its really
>   confusing that sub-projects get listed on manage_proj_page.php. The
>   only indicator that this is not a main-project is by the '>>' in front
>   of it, but its flat, so this is not obvious.

IIRC, version 1.1.x and higher have a link from a project's details page 
to create a new sub-project, which just sends you to the normal project 
creation process, but automatically attaches it to the parent project 
afterward.  The one thing that is possible with the abnormal workflow of 
Mantis, is that a given project can actually be attached as a 
sub-project to multiple parents, which is very useful where I work, and 
is a great option to have.

> - Project selection: With quit a lot projects (and possible subprojects)
>   this quickly becomes unusable. I'd suggest to not show sub-projects in
>   the main drop-down. Instead I would prefer to make that AJAX-based and
>   give the user the possibility to chose sub-projects *after* choosing
>   the appropriate project. Thats also what users are used to I think.

There is an extended project browser that does almost exactly what you 
want.  By default, $g_show_extended_project_browser = OFF;

> - On the 'View Issues' page the user is beeing hit by the filters in the
>   default settings. Most average users do not use that often, so it
>   should be collapsed normally.

Older versions of Mantis did not support having blocks collapsed by 
default, but in 1.2.x, the collapse system was recently overhauled to 
support exactly that feature.  In my opinion, the filter block *should* 
be collapsed by default, and in my uses, I open it up just long enough 
to change something, and then I close it right afterward.

> - One of my users felt that Category column is to big, while the summary
>   is to small. That is caused by the fact that there are many columns
>   displayed (we even added one, because we need it) and the design of
>   each shown issue is single-row. It has been suggested to split every
>   listed item into two lines. Preferrably one with all the meta data
>   (like category, severity etc.) and the second row the description.
>   The meta data could have a smaller font as the description. The bug
>   number could be changed to read 'Details' or similar and be in a field
>   that is spanned over both rows.

Version 1.2.x now has the ability to customize columns shown in 
different views, although I don't believe it can control column width. 
Even if we agree that there should be two rows of data per result, We 
shouldn't get rid of the bug id column, not only because it has the 
physical link to the beg for users without javascript, but because in 
the large majority of cases for software groups, bugs are referenced by 
number everywhere.

> - Issue Details appears to be un-ordered. Our users for example feel
>   that Notice should be near to the bug note and be less place-filling.
>   Possibly it would be good to have a clickable list of notes, ordered
>   like a thread tree and only show the active note to save place.
> 
> These are just examples. I would wish that there could be opened a
> discussion for that. Ideally with involvement of the users, by
> prominently inviting them on the startpage. In my experience the most
> open source projects have interface problems, while functionality is
> good. To enhance mantis in that area its good to ask users what they
> actually think, because there are so many different ways people work
> with mantis.
> 
> Feedback requested.
> 
> Regards,
> Patrick
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev


-- 
John Reese
LeetCode.net