Mantis Look and Feel

Hello list,

while monitoring the Mantis issue list, I encountered more
and more
reported issues that deal with the look and feel and/or
general
usability of Mantis, e.g. 

  6628  Skinning
  6737  "How to reproduce" in the default
section
  6729  "Assigned to" without an assignee
  6725  Handling of duplicates
  6159  Handling of sticky issues
  4227  Templates

and maybe some more. (I only checked the first page sorted
by last
update...) To quote user nathanmx from issue 6628:
"The current look
and feel is functional but Mantis needs an identity."

I have put some ideas in a mockup proposal for the
"View/Edit Issue"
page as an attachment to 6628, but I think these issues need
to be
resolved in a coordinated way, hence this post on the
mailing list.

If you like the idea of a fresh or improved Mantis design,
please let
the list know. In case of questions or if you want me to
extend my
mockup to other parts of Mantis, you can reach me either via
mail or
via Jabber at stefanbjabber.noxa.de.

Regards, Stefan.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mantisbt-dev mailing list
Mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev

On Feb 22, 2006, at 15:01, Stefan Broetz wrote:

> I have put some ideas in a mockup proposal for the
"View/Edit Issue"
> page as an attachment to 6628, but I think these issues
need to be
> resolved in a coordinated way, hence this post on the
mailing list.

I looked at that, and while some of it is nice, I'm sure
you realize  
it's more than just a skin over the current functionality.
To make  
that design work would require fundamental changes in how
the Mantis  
interface works. For example, in Mantis currently, you first
select  
an action and submit the form, then are prompted for
additional  
information and a note. Your design has the user submit all 

information up front. In fact I think this method implied by
your  
design makes more sense than what Mantis currently does, but
that's a  
functionality question, not a skinning question. You wrote
in #6628  
that having a mockup ready would help the framework
designers figure  
out what functionality they would need to provide. But I
hadn't  
thought that the process of making Mantis use Smarty (or
another  
template system) would involve any functionality changes,
rather,  
that it would just involve moving the current design into
templates.  
Any changes to functionality should be dealt with separately
from the  
templating / theming / skinning issue. Though admittedly the
process  
of dreaming up a new theme is probably a good way to expose 

functionality shortcomings.

I have problems with your use of JavaScript to contextually
show and  
hide elements. In fact, I didn't realize any of that would
occur  
until I happened to see the JavaScript file in your archive
today and  
opened it to see what it does. There's a great benefit to
keeping all  
interface elements visible at all times. It helps the user
orient  
themselves, to know what other options are available, even
if not in  
the current context. Disabling out-of-context elements is
better than  
hiding them. It would also prevent the layout from jumping
around  
haphazardly like it does with narrower window widths, and it
would  
also work around some display artifacts I'm seeing in the
Safari  
browser when elements show and hide on your sample page. I
know you  
wrote in #6628 that you only designed it for Gecko browsers
at this  
point. Of course, the entire issue tracker should function
with  
JavaScript disabled, so JavaScript should only be used as an
 
embellishment, an enhancement for those who have scripting
enabled,  
and not for core functionality.

The right sidebar, while on the surface looking neat, seems
to hinder  
me from actually getting any information out of it. Maybe
it's just  
that the text is so small.

Your top navigation bar is pretty, but remember that
localized text  
is usually longer, often 30% or more, and also given varying
window  
widths and screen sizes, it's probable that not all items
will fit on  
a single line, so the design must either accomodate that, or
else  
arrange these buttons differently. Verticaly? There seem to
me to be  
an awful lot of buttons (this is a complaint with the
regular Mantis  
interface, not specifically yours) but I'm not sure how any
could be  
removed or grouped better.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mantisbt-dev mailing list
Mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev

"RS" == Ryan Schmidt <ryandesignusers.sourceforge.net> writes:

RS> On Feb 22, 2006, at 15:01, Stefan Broetz wrote:
>> I have put some ideas in a mockup proposal for the
"View/Edit Issue"
>> page as an attachment to 6628, but I think these
issues need to be
>> resolved in a coordinated way, hence this post on
the mailing list.

RS> I looked at that, and while some of it is nice, I'm
sure you realize  
RS> it's more than just a skin over the current
functionality. 

I'm pretty sure about this, that's why I called this post
"Mantis Look
and Feel" and not only "Mantis Look".
Indeed, first I'd like to
concentrate more on the "feel" part of Mantis.
The look is something
that can follow at a later stage.

RS> To make that design work would require fundamental
changes in how
RS> the Mantis interface works. For example, in Mantis
currently, you
RS> first select an action and submit the form, then are
prompted for
RS> additional information and a note. 

Currently that's only _one_ way of interaction with Mantis
and
definitely the preferred one. 

However, currently it is possible to first add a note and
then change
the state of an issue with again the possibility to enter a
comment.
For some users this is confusing as they don't know what to
enter as a
change comment other than "State changed". I
know that the comment is
optional but this is not visible from a user point of view.
Additionally, if you have e-mail notifications enabled, you
receive
two mails (one for the comment, one for the state change)
where one
e-mail would be enough.

On the other hand, there are things you'd like to comment
(like
addition of an issue relationship or a file attachment)
which you
cannot in the same form transaction so you'd have to first
comment and
then upload (or the other way round) again resulting in two
e-mails
being sent.

Then are are the already reported inconsistencies about
updating an
issue. With the mighty update function, you could resolve an
issue
without specifying a resolution or assign an issue without
specifying
a handler. If you set an issue to "feedback",
you can add a comment
and the issue is still in this state. 

I quite realise that some of these issues are historically
based as
Mantis has become quite mature in functionality (consider
e.g. the
workflow implementation) while the user interface didn't
quite catch
up. Therefore the proposed changes seem a bit radical at
first. Maybe
this is no longer the case if you are a bit more
conservative in the
"look" department.

RS> Your design has the user submit all information up
front. In fact
RS> I think this method implied by your design makes more
sense than
RS> what Mantis currently does, but that's a
functionality question,
RS> not a skinning question.

That's why I want to discuss this on the dev mailing list
instead of
commenting the various issues independently.

RS> Any changes to functionality should be dealt with
separately from
RS> the templating / theming / skinning issue.

I definitely disagree at this stage. Functionality is
"only" the
internal part of Mantis. However, this functionality has to
be
presented to our users in a consistent way. 

In traditional model-view-controller frameworks you have
some kind of
data model (which correlates in Mantis to the core folder
and probably
is what you meant when writing "functionality").
On the UI side you
have the view part which could be Smarty, PHP templates,
XSLT or any
other presentation framework. Finally you have a controller
that has
to bring these two ends together. I usually call this the
glue between 
data model and UI. When doing radical changes to the data
model (e.g.
introducing workflow capabilities or sponsorships) it is
sometimes
more appropriate to reflect these changes in the UI, too,
instead of
just changing the glue.

RS> There's a great benefit to keeping all interface
elements visible
RS> at all times. It helps the user orient themselves, to
know what
RS> other options are available, even if not in the
current context.
RS> Disabling out-of-context elements is better than
hiding them.

That depends. If there are only some fields that get
disabled and if
it is quite clear how to activate them (e.g. as they are
visually
close as it is currently the case), then the disabling
approach might
be appropriate and better. 

If a single click enables or disables a lot of widgets which
are spead
all over the page, then the show/hide mechanism might be
better.
(Although one should rethink the whole page if it would be
better to
split it in a wizard-like page.)

RS> It would also prevent the layout from jumping around
haphazardly
RS> like it does with narrower window widths,

That's a serious UI issue which could either be resolved by
setting
the widgets to disabled or to invisible (instead of hidden).
Should be
a matter of modifying the CSS, though.

RS> and it would also work around some display artifacts
I'm seeing in
RS> the Safari browser when elements show and hide on
your sample
RS> page. I know you wrote in #6628 that you only
designed it for
RS> Gecko browsers at this point.

First I'd like to concentrate on a stabe UI interface in
one browser.
I chose a Gecko browser as it is available to most
platforms. If we
have agreed on a UI, then one can use techniques as
presented on
www.positioniseverything.net to make the design
cross-browser
compatible. 

RS> Of course, the entire issue tracker should function
with
RS> JavaScript disabled, so JavaScript should only be
used as an
RS> embellishment, an enhancement for those who have
scripting
RS> enabled, and not for core functionality.

In principle it is possible to make it JavaScript optional.
However,
we have arrived in the 21st century and JS makes it easier
to build
pages on the fly and on demand. For example I do not want to
load and
transmit a list of potential assignees if the user only
wants to have
a look at the issue. Therefore the lazy-load approach.

Maybe it would be possible to introduce a user preference
whether the
issue tracker should use JavaScript/DHTML or maybe we can
determine it
in some way. (We already have a site-wide setting in the
current
version.) If a user chooses to disable JavaScript, then the
actions
could become a wizard:

  On the main page you could select "Assign issue to
some user" and on
  a second page you are asked to which user you want to
assign the
  issue. 

However, if you make multiple changes in one go, you'd have
to be
asked several questions.

RS> The right sidebar, while on the surface looking neat,
seems to
RS> hinder me from actually getting any information out
of it. Maybe
RS> it's just that the text is so small.

I tried to make the whole page completely relative, so if
your browser
supports increasing the font size, the page should scale.

I deliberately moved this information into a side bar as the
most
important information is the summary (together with the
issue id for
developers), the current state, the user description and the
comments.

Other sidebar information is supposed to be highlighted if
it is
important (e.g. if the priority is set to high it would be
printed in
red/bold letters).

Therefore a smaller font seemed to be justified.

RS> Your top navigation bar is pretty, but remember [...]
it's
RS> probable that not all items will fit on a single
line. [...] There
RS> seem to me to be an awful lot of buttons (this is a
complaint with
RS> the regular Mantis interface, not specifically yours)
but I'm not
RS> sure how any could be removed or grouped better.

The top bar a specific part I'm not happy with, either. But
I wanted
to get the first design proposal out of the door, so I did
not spent
too much thoughts about it yet.

Maybe the functionality could be incorporated into the
sidebar in some
way. Something like a "General Navigation"
section. I'll think about
that.


So long for now, 
Stefan.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mantisbt-dev mailing list
Mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev

hi,

Just a quick 2 cents:

- Look: I like the improvements a lot, for several reasons:

* Clustering related information
* Using the "hierarchy" in the information to
position and style it
* Not having labels sometimes above, sometimes next to
values
* Having the status field in a clear place (and I would
probably like the ETA 
field in that same box, or at the top of the list of
properties, or in a 
separate "dates" box)

If we can do a similar clustering (around tasks/flow) for
the top menu and in 
pages, the actions can make more sense to users too.

- Feel: I like the discussion to tease out where
functionality of Mantis would 
need to change if you want to change the sequence of steps.
If that is more 
clear, it is easier to have both a "3-page
wizard" for the non-JS folks, and 
perhaps even do an AJAX-style approach to work with issues
(individual, views).

A different approach to the "actions" can be to
allow a click on "status" or 
"ETA" or so to do an in-situ change of the
value, being able to add a comment at 
the end of the comments list, etc. Lots more thinking needed
here, I know, and 
whether an "edit this issue"+"save
changes" approach is better is open to debate.

on 04/03/2006 09:59 Stefan Broetz wrote:
> I'm pretty sure about this, that's why I called this
post "Mantis Look
> and Feel" and not only "Mantis Look".
Indeed, first I'd like to
> concentrate more on the "feel" part of
Mantis. The look is something
> that can follow at a later stage.

             --- 8< ---{..snip...snip..}--- 8< ---

> RS> Any changes to functionality should be dealt
with separately from
> RS> the templating / theming / skinning issue.

Well, making the whole system template-based needs to be
done regardless, and 
allows everyone to experiment a lot more with layouts.
We're hoping to get a 
client in where Mantis would be used as a workflow engine
for application 
procedures, if that goes through, we will want to work on
templates where 
possible, and look at the "look" more than the
"feel" (which would come from 
some custom fields, and perhaps tweaking a little there).

          /-- Kind regards,
         /--- Rolf.
____________________________________________________________
____________
drostan.org - online collaboration - strategy, development,
facilitation


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mantisbt-dev mailing list
Mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev

Hi Rolf,

RK> * Having the status field in a clear place (and I
would probably
RK> like the ETA field in that same box, or at the top of
the list of
RK> properties, or in a separate "dates" box)

Personally I do not like the ETA field for two reasons:

 * I think the name is not chosen properly. If it really
stands for
   "Expected Time of Arrival", then I would have
to update all my
   issues constantly. So maybe something like
"Expected amount of
   work" would be better.

 * Something supporting "Agile
Development"/"Extreme Programming"
   theories would be better. The time tracking patches
proposed in
   Issue 4428 do look promising. If they reached core, I
would include
   them into the mockup.

RK> If we can do a similar clustering (around tasks/flow)
for the top
RK> menu and in pages, the actions can make more sense to
users too.

Do you have anything special in mind? I did have a look at
various
other issue tracking system implementations like
bugs.kde.org,
bugzilla.gnome.org, bugzilla.redhat.com, various JIRA
setups) and they
all have some kind of top bar.

I do not think that this is bad, either. The top bar is for
general
navigation in the issue tracker while the action area is for
working
on the issue itself. These are two different use-cases, so
IMHO we
should keep them visually seperate.

RK> - Feel: I like the discussion to tease out where
functionality of
RK> Mantis would need to change if you want to change the
sequence of
RK> steps. If that is more clear, it is easier to have
both a "3-page
RK> wizard" for the non-JS folks, and perhaps even
do an AJAX-style
RK> approach to work with issues (individual, views).

I tried to minimise the amount of clicks to perform
important work on
issues while throwing out all functionality which could lead
the user
to use Mantis in an ineffective or inconsistant way.

One major problem has been the "Add comments"
box. This seems to be
the most important functionality and therefore must be
accessable both
easily and quickly. However, adding comments sometimes has
impacts on
an issue status, e.g. moving it from "new" to
"confirmed". That's what
I liked about the bugzilla approach.

Maybe a solution for the non-JS-folks out there could be a
dedicated
view and edit mode for issues. But that would mean that one
would have
to click on edit before being able to leave a comment. 

I'll think about this, however the time I'm currently able
to spend on
open source development is unfortunately rather limited. And
there is
still a lot of mockup work to do as Mantis consists of more
than just
a "View Issue" page. And some kind of written
document where I
describe all my proposals (and summarise the comments from
the mailing
list as well) would be nice, too...

RK> A different approach to the "actions" can
be to allow a click on
RK> "status" or "ETA" or so to do
an in-situ change of the value,
RK> being able to add a comment at the end of the
comments list, etc.

That's something the bugzilla customisations mentioned
above try to
achive. Take a look at RedHat's implementation: They have
all
non-critical fields changable in an input or drop-down box
while the
status and assign-to fields are readonly in the overview and
only
changable in an action area. IMHO this clutters the page and
you might
not immediately where to look for the item you want to
change.

RK> We're hoping to get a client in where Mantis would
be used as a
RK> workflow engine for application procedures, if that
goes through,
RK> we will want to work on templates where possible, and
look at the
RK> "look" more than the "feel"
(which would come from some custom
RK> fields, and perhaps tweaking a little there).

If you want to integrate Mantis into another application:
Did you have
a look at MantisConnect (http://futurewar
e.biz/mantisconnect/) which
provides a SOAP interface to Mantis?

Regards, Stefan.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mantisbt-dev mailing list
Mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev

Hi list,

version 0.3 of the mockup series for an improved Mantis look
and feel
has been uploaded to http://bug
s.mantisbt.org/view.php?id=6628.

As it has already been stated here on this list, my
proposals go far
beyond skinning being is the title of issue 6628. Therefore
I propose
to open a new issue titled "Improve Look And
Feel" and make all
existing issues dealing with either look or feel children of
this new
one. It can also be set related to the templating issue
4227. What do
you think?

By the way: I do not think that the look and feel should be
changed
real soon now. Maybe it is something for the 2.0 release?
What do the
Mantis gurus think about this?

I plan to hang around on #mantishelp at irc.freenode.net
next saturday
(25/03/2006) morning and early afternoon (UTC). So if there
is any
need for a live discussion, feel free to contact me there.
Of course
I'll continue to monitor the mailing list, too, but
sometimes e-mail
is too slow for communication...

See you, Stefan.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking
scripting language
that extends applications into web and mobile media. Attend
the live webcast
and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/
sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mantisbt-dev mailing list
Mantisbt-devlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-d
ev