Discussion:
[mantisbt-dev] Introducing MantisBT Modern UI
Rafik Robeal
2014-08-17 03:00:12 UTC
Permalink
Hello Everyone,

For people who don't know me, my name is Rafik Robeal and I am working on building MantisHub<http://www.mantishub.com>.

I've experienced MantisBT first hand working with many users who love and admire MantisBT. I can simply say that MantisBT has proven itself to be powerful feature-rich bug tracker. One thing remains though, its UI is behind the times. To establish MantisBT as the best modern open source bug tracker for many years to come, a modern UI is needed.

Over the past few months I've been working on building a modern UI for MantisBT. The main drivers for this effort are: (1) a request from MantisBT core team back in January when I delivered the mantisbt.org<http://mantisbt.org> modern website that you see live today, (2) a loud and clear feedback from MantisBT/MantisHub<http://www.mantishub.com> customers who publicly and privately spoke against the current UI , (3) a personal desire to contribute to MantisBT open source effort with a lasting positive impact on both end users satisfaction and product adoption.

Enough introduction ... what is this all about? In four words: freaking awesome user interface

Before reading any further, fire up your browser and go to: http://mantishub.com/modern/index.php
You are accessing the preview version on MantisBT Modern UI. Use username: reporter & password: demo

I've already submitted the pull request<https://github.com/mantisbt/mantisbt/pull/272> for this work which includes:

* Integrate with Bootstrap v3.2<http://getbootstrap.com/> framework as the foundation for all Mantis UI elements.
* Use Fontawesome<http://fortawesome.github.io/Font-Awesome/> for vector based icons.
* Redesign Layout & Navigation
* Update all pages with the new style, look and feel
* Improved experience on mobile devices

The goal is to share the code and get feedback on it. We need to decide on when this code can be merged specially in relation to the 1.3 release. Decide whether it is 1.3 or 2.0 and figuring out when the 1.3 branch will be created so that the pull request can eventually be integrated.

I'd love to hear from everyone and address any potential issues you see with the new design or code.

Thanks,
Rafik Robeal
Alain D'EURVEILHER
2014-08-17 07:27:34 UTC
Permalink
Hello Rafik,

As a regular user of mantisbt and a follower of the discussions of the
mailing list, and considering the fact that the 1.3, which was supposed to
be released 01.2014, is still not today, I would personally recommend to
release the feature with the 1.3. (Who knows when the 2.0 will come out at
the end...?)

That being said, I also know that it's a bit painful to add new features in
a roadmap at the very final steps of a software release (=> tests, impacts,
more delay, etc.). So... I don't know what the dev team would think about
it.
But for sure, the answer you will get from the end users (customers) will
always be "the sooner the better" ;-)

AlainD.
Post by Rafik Robeal
Hello Everyone,
For people who don't know me, my name is Rafik Robeal and I am working on
building MantisHub <http://www.mantishub.com>.
I've experienced MantisBT first hand working with many users who love and
admire MantisBT. I can simply say that MantisBT has proven itself to be
powerful feature-rich bug tracker. One thing remains though, its UI is
behind the times. To establish MantisBT as the best modern open source bug
tracker for many years to come, a modern UI is needed.
Over the past few months I've been working on building a modern UI for
MantisBT. The main drivers for this effort are: (1) a request from MantisBT
core team back in January when I delivered the mantisbt.org modern
website that you see live today, (2) a loud and clear feedback from
MantisBT/MantisHub <http://www.mantishub.com> customers who publicly and
privately spoke against the current UI , (3) a personal desire to
contribute to MantisBT open source effort with a lasting positive impact on
both end users satisfaction and product adoption.
Enough introduction ... what is this all about? In four words: *freaking
awesome user interface*
http://mantishub.com/modern/index.php
reporter & password: demo
I've already submitted the pull request
<https://github.com/mantisbt/mantisbt/pull/272> for this work which
- Integrate with Bootstrap v3.2 <http://getbootstrap.com/> framework
as the foundation for all Mantis UI elements.
- Use Fontawesome <http://fortawesome.github.io/Font-Awesome/> for
vector based icons.
- Redesign Layout & Navigation
- Update all pages with the new style, look and feel
- Improved experience on mobile devices
The goal is to share the code and get feedback on it. We need to decide on
when this code can be merged specially in relation to the 1.3 release.
Decide whether it is 1.3 or 2.0 and figuring out when the 1.3 branch will
be created so that the pull request can eventually be integrated.
I'd love to hear from everyone and address any potential issues you see
with the new design or code.
Thanks,
Rafik Robeal
------------------------------------------------------------------------------
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
P Richards
2014-08-17 09:23:34 UTC
Permalink
Alain,



It’s even more painful, when it’s a big change, and changes the approach we go in Mantis - hasn’t been discussed on the mailing list, and there’s work in progress (well, on hold until after 1.3) to allow greater flexibility of theming mantis already. We agreed back in January to use the following approach regarding external libraries:




Changing external libraries


Adding or removing an external library should be discussed first on the developer mailing list.

The following must be considered when reviewing an external library

* Technical fit

* License compatibility

* Recent development activity

* Community size/support

Changing versions of a library does not need to be discussed, unless there are major changes in the review criteria, e.g. change of license



When looking at templating email notifications, I’d also taken a stab at allowing flexible templating of the view issues / report issues pages.



Now, in terms of Rafiq’s work, I don’t necessarily see it as being a major problem (i.e. that we’ve got other work on theming) as I think it covers two different things - i.e. Rafiq’s trying to do a visual design, anything I’ve looked at tends to be working on allowing flexibility/functionality rather then visual effects, so the two probably go together in the end.



My main issue is we have plugin’s that add functionality, there’s multiple CSS frameworks out there now - Jquery UI, foundation, bootstrap etc, that we do need to consider our approach within Mantis. I’m pretty confident we could make a similar style using query ui, foundation or bootstrap - without two much work, so we need to decide what works best long term.



The reason I started looking at using Jquery UI in the past (we actually moved the Jquery UI javascript from a plugin to the Mantis Core) was due to it being used by some plugins, and having the visual theme roller - which struck me as something that would allow an end user without HTML or CSS experience to brand Mantis into their company colours without very much work. Given that Mantis has found a whole bunch of uses - for both software development and non-software development workflows, this struck me originally as an easy win for end users and plugin author’s for styling.



Now it may be we can make use of Jquery’s theme roller with bootstrap/foundation etc, or that they are separate and it’s one or the other, but we need to have a proper discussion on the Mailing list first.



Paul





From: Alain D'EURVEILHER [mailto:***@gmail.com]
Sent: 17 August 2014 08:28
To: developer discussions
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



Hello Rafik,



As a regular user of mantisbt and a follower of the discussions of the mailing list, and considering the fact that the 1.3, which was supposed to be released 01.2014, is still not today, I would personally recommend to release the feature with the 1.3. (Who knows when the 2.0 will come out at the end...?)



That being said, I also know that it's a bit painful to add new features in a roadmap at the very final steps of a software release (=> tests, impacts, more delay, etc.). So... I don't know what the dev team would think about it.

But for sure, the answer you will get from the end users (customers) will always be "the sooner the better" ;-)



AlainD.



On Sun, Aug 17, 2014 at 5:00 AM, Rafik Robeal <***@mantishub.net <mailto:***@mantishub.net> > wrote:

Hello Everyone,

For people who don't know me, my name is Rafik Robeal and I am working on building MantisHub <http://www.mantishub.com> .

I've experienced MantisBT first hand working with many users who love and admire MantisBT. I can simply say that MantisBT has proven itself to be powerful feature-rich bug tracker. One thing remains though, its UI is behind the times. To establish MantisBT as the best modern open source bug tracker for many years to come, a modern UI is needed.

Over the past few months I've been working on building a modern UI for MantisBT. The main drivers for this effort are: (1) a request from MantisBT core team back in January when I delivered the mantisbt.org <http://mantisbt.org> modern website that you see live today, (2) a loud and clear feedback from MantisBT/MantisHub <http://www.mantishub.com> customers who publicly and privately spoke against the current UI , (3) a personal desire to contribute to MantisBT open source effort with a lasting positive impact on both end users satisfaction and product adoption.

Enough introduction ... what is this all about? In four words: freaking awesome user interface

Before reading any further, fire up your browser and go to: http://mantishub.com/modern/index.php
You are accessing the preview version on MantisBT Modern UI. Use username: reporter & password: demo

I've already submitted the pull request <https://github.com/mantisbt/mantisbt/pull/272> for this work which includes:

* Integrate with Bootstrap v3.2 <http://getbootstrap.com/> framework as the foundation for all Mantis UI elements.
* Use Fontawesome <http://fortawesome.github.io/Font-Awesome/> for vector based icons.
* Redesign Layout & Navigation
* Update all pages with the new style, look and feel
* Improved experience on mobile devices

The goal is to share the code and get feedback on it. We need to decide on when this code can be merged specially in relation to the 1.3 release. Decide whether it is 1.3 or 2.0 and figuring out when the 1.3 branch will be created so that the pull request can eventually be integrated.

I'd love to hear from everyone and address any potential issues you see with the new design or code.

Thanks,
Rafik Robeal


------------------------------------------------------------------------------

_______________________________________________
mantisbt-dev mailing list
mantisbt-***@lists.sourceforge.net <mailto:mantisbt-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
Victor Boctor
2014-08-18 00:11:53 UTC
Permalink
Paul,
Post by P Richards
Alain,
[Victor] When Rafik contributed the new website in January, he was asked by several on the team to help out with doing the same for MantisBT itself. Hence, his contribution. He has used Bootstrap on the website and carried that forward to MantisBT itself. Given that he has followed through with this and put this hard word, I would expect that we would motivate him for that and appreciate the good work, rather than just being negative.
Post by P Richards
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a major problem (i.e. that we’ve got other work on theming) as I think it covers two different things - i.e. Rafiq’s trying to do a visual design, anything I’ve looked at tends to be working on allowing flexibility/functionality rather then visual effects, so the two probably go together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to extend MantisBT through plugins. The believe Rafik’s suggested change was focused on revamping the visual design for all features. But to scope the change, it doesn’t try to go further than that. Once it is in, we can add more flexibility and modernize further.
Post by P Richards
My main issue is we have plugin’s that add functionality, there’s multiple CSS frameworks out there now - Jquery UI, foundation, bootstrap etc, that we do need to consider our approach within Mantis. I’m pretty confident we could make a similar style using query ui, foundation or bootstrap - without two much work, so we need to decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think given that we have this used in the website and the proposed pull request now, I don’t see why we would go for something else. Bootstrap also provides a good story for responive design allowing us to have great native support for phones over time.
Post by P Richards
The reason I started looking at using Jquery UI in the past (we actually moved the Jquery UI javascript from a plugin to the Mantis Core) was due to it being used by some plugins, and having the visual theme roller - which struck me as something that would allow an end user without HTML or CSS experience to brand Mantis into their company colours without very much work. Given that Mantis has found a whole bunch of uses - for both software development and non-software development workflows, this struck me originally as an easy win for end users and plugin author’s for styling.
[Victor] From memory the dependency we took was mainly on jquery and not jquery mobile. With bootstrap you can also have the equivalent of colored themes.

Thanks,
-Victor
Paul Richards
2014-08-18 07:16:54 UTC
Permalink
On 18 Aug 2014, at 01:00, Victor Boctor <***@gmail.com> wrote:

Paul,

On Aug 17, 2014, at 2:23 AM, P Richards <***@mantisforge.org> wrote:

Rafiq,

As i’ve seen on the PR, and when you originally said you were looking at
this a month ago, and asked you to mail the Mailing List, we need to have a
discussion about the design and the approach.


[Victor] Correct. The request from you when Rafik sent out a preview was
to publish the code and the discussion to the DL, which he just did. Your
words were that even though the decision to use bootstrap is likely to be a
short discussion, it is worth having anything.


[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the team
from the Rafik was to do the same modernization to MantisBT. Hence, he
started doing the work. As for plugins, they are typically easy to adapt
to whatever framework MantisBT is using.


Actually, I said we should have a be having a discussion on the mailing
list and before writing code:

"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis or
something else before writing any code.”

We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.

And sorry, the website was something that was also done without discussion
initially - so that’s not really a valid point. The website has always been
a separate code base to Mantis.


One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise the
look and feel of mantis in different ways.


[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the past
were motivated to improve the look. However, what we really need to focus
on is the ability for users to continue to be able to extend MantisBT via
plugins. If we get into theming, we can support color shade (e.g. green
template, blue template, etc) rather than complete customization. Complete
customization adds little value and can significantly increase complexity
of code and test matrix. I believe users evaluate MantisBT evalute it
based on functionalty, look, and extensions to fill gaps that we don’t have
in core or integrate their own custom functionality.


We’ve had a lot of questions over the years to allow alteration of bits of
Mantis. What we’ve always done is been flexible with the approach - hence
the fact today we have configuration variables for everything.

If you consider the design of Mantis and the number of pages, we have 7
main things users use / want to customise:

a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer

When people have gone in the past “it should be possible to template/theme
whole of mantis’, personally - I can’t see people doing that, or it being
sustainable for us.

However, I can see companies that want to brand mantis replacing A+F in the
list above, and potentially B

In terms of B/C/D/E - I suspect you would not touch the design of C/E, but
the ability to tweak B+D is where most drivers come from.

For example, I scrapped the report issues page at work a long term ago as
it was not suitable for non-technical users. And within Mantis at the time,
the flexibility we provide for customising it does not exist. This is
actually one block of Mantis where i’d agree with the people wanting
support for templates.

View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.




In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.


[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?


Mantis has always been a top down design - if you replace the header/footer
you can embed the remaining content within another page, leaving the menu
at the top for navigation.



For most end users, Mantis consists of 4 pages:

1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page

I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.


For example, in a modern system, the “My View” page I would have expect to
be a ajax dashboard.


I sent an email a few weeks ago now for feedback on using DataTables to
ajaxify the View Issues list.



[Victor] This is just a scoping exercise. The first iteration’s goal is to
improve the look and use a more modern code styling. Once this is in, we
can follow up by enriching specific page to make it use ajax. Good
examples are “My View” and filter page. Once Rafik’s change is checked in,
we can all collaborate on enriching specific pages as necessary.

For 3/4, the requests tend to be to allow fields to be re-ordered, turned
on/off.

At the moment, the work doesn’t help any of these requests from users.


[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a conflict
between these features and styling of pages.

Whilst I did try to have a look at the Pull Request, there seems to be a
number of Whitespace changes, and non-theme/design changes that make it
impossible to review the patches.


[Victor] I agree that the change has some white spacing issues that cause
more changes than actually needed. Maybe Rafik can explore of this issue
can be fixed with reasonable effort.

Back in January, we agreed as a Team to get 1.3 shipped, and then look at
UI and email notifications changes. Victor knows I’ve got some work on
templating emails and pages within Mantis from back then, which I said I’d
get a PR up for once the Database changes had been done - which we agreed
as a team to do immediately after 1.3. So until we’ve done this, compared
the two approaches and decide which route we want to go, i’m strongly
against this getting merged.


[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had discussed
email templating (not UI tempting) and proposed an approach, some previews,
and you complained and stopped the work. I’ve asked you then to share your
code / approach and you haven’t. You just killed the momentum and said that
you will publish your code by end of January then after 1.3. At that point
we also agreed that code that is not published doesn’t exist and can’t be
used to block other work. Rafik has shared a preview of this work with the
team 1-2 month ago and everyone except you on the core team was excited and
gave him UI level feedback which he addressed. So, I expect this code to
be merged. The discussion is when exactly it is going to be merged based
on the 1.3 plan.


We agreed to ship 1.3 first so


When rafiq shared a preview with people 1-2 months ago was when i jumped in
immediately and said:
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.

It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion to
take place properly. I think I said in the same email that I quite liked
the design.

Rafik is someone that’s never contributed to Mantis before, has never been
introduced to us apart from dumping a website re-design and now has added a
10,000 line commit, which is basically impossible to review.

My purpose for asking him to communicate with the development list 2 months
ago was so that we could have a discussion at an EARLY stage.

As it is, until we get a PR that doesn’t contain X000 lines of incorrect
whitespace changes in the first commit, it’s actually impossible to even
attempt to review and look at what has been done. And that’s aside from the
fact that we need to have a discussion around whether to use bootstrap.

Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the approach
we go in Mantis - hasn’t been discussed on the mailing list, and there’s
work in progress (well, on hold until after 1.3) to allow greater
flexibility of theming mantis already. We agreed back in January to use the
[Victor] When Rafik contributed the new website in January, he was asked
by several on the team to help out with doing the same for MantisBT itself.
Hence, his contribution. He has used Bootstrap on the website and carried
that forward to MantisBT itself. Given that he has followed through with
this and put this hard word, I would expect that we would motivate him for
that and appreciate the good work, rather than just being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a major
problem (i.e. that we’ve got other work on theming) as I think it covers
two different things - i.e. Rafiq’s trying to do a visual design, anything
I’ve looked at tends to be working on allowing flexibility/functionality
rather then visual effects, so the two probably go together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested change was
focused on revamping the visual design for all features. But to scope the
change, it doesn’t try to go further than that. Once it is in, we can add
more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s multiple
CSS frameworks out there now - Jquery UI, foundation, bootstrap etc, that
we do need to consider our approach within Mantis. I’m pretty confident we
could make a similar style using query ui, foundation or bootstrap -
without two much work, so we need to decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think given
that we have this used in the website and the proposed pull request now, I
don’t see why we would go for something else. Bootstrap also provides a
good story for responive design allowing us to have great native support
for phones over time.
The reason I started looking at using Jquery UI in the past (we actually
moved the Jquery UI javascript from a plugin to the Mantis Core) was due to
it being used by some plugins, and having the visual theme roller - which
struck me as something that would allow an end user without HTML or CSS
experience to brand Mantis into their company colours without very much
work. Given that Mantis has found a whole bunch of uses - for both software
development and non-software development workflows, this struck me
originally as an easy win for end users and plugin author’s for styling.
Roland Becker
2014-08-18 20:01:10 UTC
Permalink
Paul,

it seems your main concern is using Bootstrap
We set a policy in january that before we accept any external library changes
etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion around
whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.

I can't contribute that much to this decision as I have no own experience using
Bootstrap or any other comparable component.
I don't want to vote just because I read a few articles and comparisons about
it.

What I noticed is a big amount of transferred CSS and JavaScript compared to the
current version. (about additional 700KB when opening for the first time, but
also more traffic for following requests)

Are there any known issues using Bootstrap?

Roland
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking at
this a month ago, and asked you to mail the Mailing List, we need to have a
discussion about the design and the approach.
[Victor] Correct.  The request from you when Rafik sent out a preview was
to publish the code and the discussion to the DL, which he just did.  Your
words were that even though the decision to use bootstrap is likely to be a
short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed.  At this time, bootstrap was used and the request by the team
from the Rafik was to do the same modernization to MantisBT.  Hence, he
started doing the work.  As for plugins, they are typically easy to adapt
to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the mailing
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis or
something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without discussion
initially - so that’s not really a valid point. The website has always been
a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise the
look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
  In my opinion, a lot of the users that heavilty themed Mantis in the past
were motivated to improve the look.  However, what we really need to focus
on is the ability for users to continue to be able to extend MantisBT via
plugins.  If we get into theming, we can support color shade (e.g. green
template, blue template, etc) rather than complete customization.  Complete
customization adds little value and can significantly increase complexity
of code and test matrix.  I believe users evaluate MantisBT evalute it
based on functionalty, look, and extensions to fill gaps that we don’t have
in core or integrate their own custom functionality.
We’ve had a lot of questions over the years to allow alteration of bits of
Mantis. What we’ve always done is been flexible with the approach - hence
the fact today we have configuration variables for everything.
If you consider the design of Mantis and the number of pages, we have 7
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to template/theme
whole of mantis’, personally - I can’t see people doing that, or it being
sustainable for us.
However, I can see companies that want to brand mantis replacing A+F in the
list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E, but
the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago as
it was not suitable for non-technical users. And within Mantis at the time,
the flexibility we provide for customising it does not exist. This is
actually one block of Mantis where i’d agree with the people wanting
support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the header/footer
you can embed the remaining content within another page, leaving the menu
at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have expect to
be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables to
ajaxify the View Issues list.
[Victor] This is just a scoping exercise.  The first iteration’s goal is to
improve the look and use a more modern code styling.  Once this is in, we
can follow up by enriching specific page to make it use ajax.  Good
examples are “My View” and filter page.  Once Rafik’s change is checked in,
we can all collaborate on enriching specific pages as necessary.
For 3/4, the requests tend to be to allow fields to be re-ordered, turned
on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features.  I don’t see how there is a conflict
between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be a
number of Whitespace changes, and non-theme/design changes that make it
impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that cause
more changes than actually needed.  Maybe Rafik can explore of this issue
can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look at
UI and email notifications changes. Victor knows I’ve got some work on
templating emails and pages within Mantis from back then, which I said I’d
get a PR up for once the Database changes had been done - which we agreed
as a team to do immediately after 1.3. So until we’ve done this, compared
the two approaches and decide which route we want to go, i’m strongly
against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team.  At that point I had discussed
email templating (not UI tempting) and proposed an approach, some previews,
and you complained and stopped the work.  I’ve asked you then to share your
code / approach and you haven’t. You just killed the momentum and said that
you will publish your code by end of January then after 1.3.  At that point
we also agreed that code that is not published doesn’t exist and can’t be
used to block other work.  Rafik has shared a preview of this work with the
team 1-2 month ago and everyone except you on the core team was excited and
gave him UI level feedback which he addressed.  So, I expect this code to
be merged.  The discussion is when exactly it is going to be merged based
on the 1.3 plan.
We agreed to ship 1.3 first so…
When rafiq shared a preview with people 1-2 months ago was when i jumped in
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion to
take place properly. I think I said in the same email that I quite liked
the design.
Rafik is someone that’s never contributed to Mantis before, has never been
introduced to us apart from dumping a website re-design and now has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2 months
ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of incorrect
whitespace changes in the first commit, it’s actually impossible to even
attempt to review and look at what has been done. And that’s aside from the
fact that we need to have a discussion around whether to use bootstrap.
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the approach
we go in Mantis - hasn’t been discussed on the mailing list, and there’s
work in progress (well, on hold until after 1.3) to allow greater
flexibility of theming mantis already. We agreed back in January to use the
[Victor] When Rafik contributed the new website in January, he was asked
by several on the team to help out with doing the same for MantisBT itself.
  Hence, his contribution.  He has used Bootstrap on the website and carried
that forward to MantisBT itself.  Given that he has followed through with
this and put this hard word, I would expect that we would motivate him for
that and appreciate the good work, rather than just being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a major
problem (i.e. that we’ve got other work on theming) as I think it covers
two different things - i.e. Rafiq’s trying to do a visual design, anything
I’ve looked at tends to be working on allowing flexibility/functionality
rather then visual effects, so the two probably go together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins.  The believe Rafik’s suggested change was
focused on revamping the visual design for all features.  But to scope the
change, it doesn’t try to go further than that.  Once it is in, we can add
more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s multiple
CSS frameworks out there now - Jquery UI, foundation, bootstrap etc, that
we do need to consider our approach within Mantis. I’m pretty confident we
could make a similar style using query ui, foundation or bootstrap -
without two much work, so we need to decide what works best long term.
[Victor] Bootstrap is a very popular and respected library.  I think given
that we have this used in the website and the proposed pull request now, I
don’t see why we would go for something else.  Bootstrap also provides a
good story for responive design allowing us to have great native support
for phones over time.
The reason I started looking at using Jquery UI in the past (we actually
moved the Jquery UI javascript from a plugin to the Mantis Core) was due to
it being used by some plugins, and having the visual theme roller - which
struck me as something that would allow an end user without HTML or CSS
experience to brand Mantis into their company colours without very much
work. Given that Mantis has found a whole bunch of uses - for both software
development and non-software development workflows, this struck me
originally as an easy win for end users and plugin author’s for styling.
[Victor]
P Richards
2014-08-18 20:33:14 UTC
Permalink
My main concern is that we evaluate options properly - any decision we take now is something that the whole dev-team and any plugin author will be using.

So far, the works been done by someone that has never done a commit to mantis before - whilst it's fairly clear that they are not stupid, at the same time, there's historical decisions and historical roadmap items and plans etc that may not have been considered. It may be that after this work, we never see the author again. Our published contribution guidelines state to talk to the dev list first etc etc etc.

Hopefully Rafik will submit a PR with whitespace tidied up and splitting out some of the non-design changes (i.e. jquery) so we can actually have a proper look at the work, but there's decisions in that PR that we've already discussed and decided on a path 'for now'.

For example,

In october 2013 Victor send a mail about upgrading JQuery from 1.7.2 to 1.9 or 2.0
Robert replied stating that moving to 2.0 would rule out IE8
Etc
I replied with what I deemed a favourite question: "what browsers do *we support*? :)"
A Mantis user replied to the converstation stating about being careful about browser support as they only have IE8
Robert replied stating IE8 is here to stay.

I might have got the order slightly wrong in the above, but the end outcome I believe was we updated master from jquery 1.7.2 to 1.9.1

If I google for "IE market share" - the first hit I get is http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0, which states IE8 as having 22% share (not sure how they generate these stats as that seems nut ;)) IF I go for the 2nd hit (http://www.w3counter.com/globalstats.php), that shows chrome with 20% etc, IE9 6.5%, IE11 5.6%, and IE8 4%

My understanding is bootstrap 3 would support IE 8 for *most* things, and that jquery 2.x does not support IE8 - hence my point about breaking the PR up a bit, and also it needing to have a discussion.

The other part is ensuring that we map design changes to something that is flexible for as many existing users to use and fit into their existing setup as possible. The new layout would look great for a service (like mantishub), it may not look as good for people that are trying to top/tail it to use it in existing environments. We need to ensure that our approach provides flexibility for both - this is something that mantis arguably does well for other things due to our complexity of configuration options.

Paul



-----Original Message-----
From: Roland Becker [mailto:***@atrol.de]
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI

Paul,

it seems your main concern is using Bootstrap
Post by Paul Richards
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.

I can't contribute that much to this decision as I have no own experience using Bootstrap or any other comparable component.
I don't want to vote just because I read a few articles and comparisons about it.

What I noticed is a big amount of transferred CSS and JavaScript compared to the current version. (about additional 700KB when opening for the first time, but also more traffic for following requests)

Are there any known issues using Bootstrap?

Roland
Post by Paul Richards
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their own custom functionality.
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for everything.
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages as necessary.
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based on the 1.3 plan.
We agreed to ship 1.3 first so…
When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around whether to use bootstrap.
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for MantisBT itself.
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than just being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two probably go together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need to decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an easy win for end users and plugin author’s for styling.
[Victor]
Rafik Robeal
2014-08-19 05:25:09 UTC
Permalink
With respect to Bootstrap vs. other frameworks:

There are a couple of popular web frameworks: Bootstrap & Foundation

+ If you scan both bootstrap<http://getbootstrap.com/getting-started/> & foundation<http://foundation.zurb.com/docs/> docs, you will see the same features, similar markup and same web components.

+ Bootstrap has a much bigger ecosystem. It came first and was backed by twitter. It captured developers mindshare early on and became the de-facto standard web framework as these recent stats show:
http://techcrunch.com/2013/07/28/bootstrap-3-goes-mobile-first-now-reportedly-powers-1-of-the-web/
http://blog.meanpath.com/4-7m-sites-using-bootstrap-vs-334k-on-foundation/

As such, bootstrap has the lion share of docs, plugins, free and commercial themes (like the one used with Mantis) … etc

+ Other than that, it is hard to differentiate between both frameworks. Here are couple of different opinions to chew on:
https://medium.com/@felippenardi/top-5-core-differences-between-bootstrap-3-and-foundation-5-8b3812c7007c
http://blog.teamtreehouse.com/use-bootstrap-or-foundation


What about JQuery Mobile?
It is a great framework for building mobile user interfaces. I started using it when it was in early alpha and was a big fan. That’s until Bootstrap v3.0 came along. Bootstrap v3 is far superior framework for building responsive interfaces that works on desktop, tablet and mobile.


What about Theme Roller?
That’s not a framework. It is a feature available in jqueryui.com<http://jqueryui.com/themeroller/> to allow users to customize the look and feel of jqueryui components. The output of the theme roller is a custom css file to apply alongside the core jqueryui library. If you want the same for mantis, you need to build it. It won’t matter if the underlying framework is Bootstrap or Foundation.



So far, the works been done by someone that has never done a commit to mantis before

There is always a first time


The new layout would look great for a service (like mantis hub),

Nothing in this work was customized for MantisHub.
The sidebar design is increasingly popular choice (Github, Jira, BitBucket) because of the popularity of widescreen monitors. With widescreen, you have more horizontal space to work with and less vertical space. Using vertical space to show a navigation menu with 5 links is just a waste of precious user work area.


-Rafik


On Aug 18, 2014, at 1:33 PM, P Richards <***@mantisforge.org<mailto:***@mantisforge.org>> wrote:

My main concern is that we evaluate options properly - any decision we take now is something that the whole dev-team and any plugin author will be using.

So far, the works been done by someone that has never done a commit to mantis before - whilst it's fairly clear that they are not stupid, at the same time, there's historical decisions and historical roadmap items and plans etc that may not have been considered. It may be that after this work, we never see the author again. Our published contribution guidelines state to talk to the dev list first etc etc etc.

Hopefully Rafik will submit a PR with whitespace tidied up and splitting out some of the non-design changes (i.e. jquery) so we can actually have a proper look at the work, but there's decisions in that PR that we've already discussed and decided on a path 'for now'.

For example,

In october 2013 Victor send a mail about upgrading JQuery from 1.7.2 to 1.9 or 2.0
Robert replied stating that moving to 2.0 would rule out IE8
Etc
I replied with what I deemed a favourite question: "what browsers do *we support*? :)"
A Mantis user replied to the converstation stating about being careful about browser support as they only have IE8
Robert replied stating IE8 is here to stay.

I might have got the order slightly wrong in the above, but the end outcome I believe was we updated master from jquery 1.7.2 to 1.9.1

If I google for "IE market share" - the first hit I get is http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0, which states IE8 as having 22% share (not sure how they generate these stats as that seems nut ;)) IF I go for the 2nd hit (http://www.w3counter.com/globalstats.php), that shows chrome with 20% etc, IE9 6.5%, IE11 5.6%, and IE8 4%

My understanding is bootstrap 3 would support IE 8 for *most* things, and that jquery 2.x does not support IE8 - hence my point about breaking the PR up a bit, and also it needing to have a discussion.

The other part is ensuring that we map design changes to something that is flexible for as many existing users to use and fit into their existing setup as possible. The new layout would look great for a service (like mantishub), it may not look as good for people that are trying to top/tail it to use it in existing environments. We need to ensure that our approach provides flexibility for both - this is something that mantis arguably does well for other things due to our complexity of configuration options.

Paul



-----Original Message-----
From: Roland Becker [mailto:***@atrol.de]
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI

Paul,

it seems your main concern is using Bootstrap

We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.

Let's start the discussion and get a decision: Use Bootstrap or not.

I can't contribute that much to this decision as I have no own experience using Bootstrap or any other comparable component.
I don't want to vote just because I read a few articles and comparisons about it.

What I noticed is a big amount of transferred CSS and JavaScript compared to the current version. (about additional 700KB when opening for the first time, but also more traffic for following requests)

Are there any known issues using Bootstrap?

Roland

Paul Richards <***@mantisforge.org<mailto:***@mantisforge.org>> hat am 18. August 2014 um 09:16
geschrieben:


On 18 Aug 2014, at 01:00, Victor Boctor <***@gmail.com<mailto:***@gmail.com>> wrote:

Paul,

On Aug 17, 2014, at 2:23 AM, P Richards <***@mantisforge.org<mailto:***@mantisforge.org>> wrote:

Rafiq,

As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.


[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.


[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.


Actually, I said we should have a be having a discussion on the
mailing list and before writing code:

"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”

We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.

And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.


One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.


[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their own custom functionality.


We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for everything.

If you consider the design of Mantis and the number of pages, we have
7 main things users use / want to customise:

a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer

When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.

However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B

In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.

For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.

View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.




In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.


[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?


Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.



For most end users, Mantis consists of 4 pages:

1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page

I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.


For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.


I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.



[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages as necessary.

For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.

At the moment, the work doesn’t help any of these requests from users.


[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.

Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.


[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.

Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.


[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based on the 1.3 plan.


We agreed to ship 1.3 first so…

When rafiq shared a preview with people 1-2 months ago was when i
jumped in immediately and said:
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.

It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.

Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.

My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.

As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around whether to use bootstrap.

Paul


On Mon, Aug 18, 2014 at 1:11 AM, Victor Boctor <***@gmail.com<mailto:***@gmail.com>> wrote:

Paul,

On Aug 17, 2014, at 2:23 AM, P Richards <***@mantisforge.org<mailto:***@mantisforge.org>> wrote:

Alain,

It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
back in January to use the following approach regarding external libraries:


[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for MantisBT itself.
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than just being negative.

Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two probably go together in the end.


[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.

My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need to decide what works best long term.


[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.

The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an easy win for end users and plugin author’s for styling.
Robert Munteanu
2014-08-19 12:51:44 UTC
Permalink
Post by P Richards
My main concern is that we evaluate options properly - any decision we take now is something that the whole dev-team and any plugin author will be using.
So far, the works been done by someone that has never done a commit to mantis before
And that's fantastic, please don't play it any other way ... Having
such a sizeable and useful first contribution is something I am happy
about, not suspicious.
Post by P Richards
- whilst it's fairly clear that they are not stupid,
(...)
Post by P Richards
at the same time, there's historical decisions and historical roadmap items and plans etc that may not have been considered.
Which would those be?
Post by P Richards
It may be that after this work, we never see the author again. Our published contribution guidelines state to talk to the dev list first etc etc etc.
So the problem is that we get a quality contributions and then have to
maintain it?

Robert
Post by P Richards
Hopefully Rafik will submit a PR with whitespace tidied up and splitting out some of the non-design changes (i.e. jquery) so we can actually have a proper look at the work, but there's decisions in that PR that we've already discussed and decided on a path 'for now'.
For example,
In october 2013 Victor send a mail about upgrading JQuery from 1.7.2 to 1.9 or 2.0
Robert replied stating that moving to 2.0 would rule out IE8
Etc
I replied with what I deemed a favourite question: "what browsers do *we support*? :)"
A Mantis user replied to the converstation stating about being careful about browser support as they only have IE8
Robert replied stating IE8 is here to stay.
I might have got the order slightly wrong in the above, but the end outcome I believe was we updated master from jquery 1.7.2 to 1.9.1
If I google for "IE market share" - the first hit I get is http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0, which states IE8 as having 22% share (not sure how they generate these stats as that seems nut ;)) IF I go for the 2nd hit (http://www.w3counter.com/globalstats.php), that shows chrome with 20% etc, IE9 6.5%, IE11 5.6%, and IE8 4%
My understanding is bootstrap 3 would support IE 8 for *most* things, and that jquery 2.x does not support IE8 - hence my point about breaking the PR up a bit, and also it needing to have a discussion.
The other part is ensuring that we map design changes to something that is flexible for as many existing users to use and fit into their existing setup as possible. The new layout would look great for a service (like mantishub), it may not look as good for people that are trying to top/tail it to use it in existing environments. We need to ensure that our approach provides flexibility for both - this is something that mantis arguably does well for other things due to our complexity of configuration options.
Paul
-----Original Message-----
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI
Paul,
it seems your main concern is using Bootstrap
Post by Paul Richards
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.
I can't contribute that much to this decision as I have no own experience using Bootstrap or any other comparable component.
I don't want to vote just because I read a few articles and comparisons about it.
What I noticed is a big amount of transferred CSS and JavaScript compared to the current version. (about additional 700KB when opening for the first time, but also more traffic for following requests)
Are there any known issues using Bootstrap?
Roland
Post by Paul Richards
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their own custom functionality.
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for everything.
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages as necessary.
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based on the 1.3 plan.
We agreed to ship 1.3 first so…
When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around whether to use bootstrap.
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for MantisBT itself.
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than just being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two probably go together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need to decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an easy win for end users and plugin author’s for styling.
[Victor]
P Richards
2014-08-25 14:25:09 UTC
Permalink
I spent the last couple of days trying to theme a few of the common end-user pages i.e. not the management bit with foundation - that actually comes in slightly smaller in terms of data transfer, and also taking a look at the bootstrap PR.



I'm slowly coming to the conclusion that given the approach we've gone so far, and plugins - and that we spent some effort into trying to make the current master have better css etc, that I'm probably against adding a bulky framework to mantis.



I do want to have a play with http://getuikit.com/ as that's a slightly lighter framework, just to decide whether it's case of I'm not a fan of current design's, or not a fan of some of the bulkier frameworks.



Having played around, there's definitely some things in the bootstrap theme changes that I'm not keen on, and equally there's some things in the DIFF that don't make sense (false<>true's switch around) - not sure if that's intentional or not as it certainly looks like it may be bugs. The filter box also is fairly broken on the browser I tried.



In terms of foundation, some of the way they name classes, and organise things seems to be more natural coming from where we are with Mantis and our current naming/css.



I’ve included 3 images in a table below – showing the foundation version, current 1.3 and the bootstrap version. I could write out my opinions on the positives/negatives of all 3 images, but I don’t want to do that (just yet) so that others can have a think about what they’d actually want. The only thing I would like to do is do a new version of the middle one, with some updated css, and a 4th version using uikit to get a good comparison.












In terms of Mantis, and this is something I’ve said before, we have about 5 ‘key’ components that I’d expect a user to use on a daily basis:



a) Logon Screen – First Page that anyone sees!

b) “My View”

c) “View Issues”

d) “View Issue”

e) “Report Issue”



Seperately to that, we have 3 components that are either separate or integrated – but lesser used:



a) Installation Process – Separate to mantis

b) Management screens – within Mantis, but only seen by admins

c) Flexiblity to end users provided by plugins etc



Personally, I think we really need to decide what we’d like a the views (a-e) to look like, because, whilst I agree we need to modernise slightly, I’m not sure that throwing in a big framework is necessarily the best fit.



I’m going to go off and create a logon screen using (uikit), and also modernising the logon screen in 1.3 to get some updated comparison screen shots. In the mean time, it would be interesting to know from others what they like/dislike about the current and variants I posted above (which I’ve deliberately left my personal views of what bits of each I like out of this email to get some fair design ideas :))



Paul









-----Original Message-----
From: Roland Becker [mailto:***@atrol.de]
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



Paul,



it seems your main concern is using Bootstrap
Post by Paul Richards
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.



I can't contribute that much to this decision as I have no own experience using Bootstrap or any other comparable component.

I don't want to vote just because I read a few articles and comparisons about it.



What I noticed is a big amount of transferred CSS and JavaScript compared to the current version. (about additional 700KB when opening for the first time, but also more traffic for following requests)



Are there any known issues using Bootstrap?



Roland
Post by Paul Richards
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their own custom functionality.
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for everything.
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages as necessary.
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based on the 1.3 plan.
We agreed to ship 1.3 first so

When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around whether to use bootstrap.
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for MantisBT itself.
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than just being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two probably go together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need to decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an easy win for end users and plugin author’s for styling.
Alain D'EURVEILHER
2014-08-25 15:25:44 UTC
Permalink
Hi every one,
Wow! All that orange color scares me a lot, on the Foundation style (If I
may give my preferences as well).
For now on the 3, I definatelly go for the Mantis 1.3 and Bootstrap.
Although I am really fine with the Mantis 1.3 (sort of get used to it) I
have a preference for the bootstrap version, because it's new and soft. And
also because I'm starting to get used to this framework myself by working
on another tool (using the ace template too by the way).

I did not know about the ligth uikit, and I like it. If is is really much
lighter, I think I would prefer uikit, considering the era of mobile
devices we live with today. After all the main components used by bootstrap
are defined in UiKit so.
Also, to be sure about the size, I think the comparison should take all the
uikit core + the different add-ons if needed in Mantis (autocomplete,
validation etc...) + the mantis customizations.

Regards,
AlainD.
Post by P Richards
I spent the last couple of days trying to theme a few of the common
end-user pages i.e. not the management bit with foundation - that actually
comes in slightly smaller in terms of data transfer, and also taking a look
at the bootstrap PR.
I'm slowly coming to the conclusion that given the approach we've gone so
far, and plugins - and that we spent some effort into trying to make the
current master have better css etc, that I'm probably against adding a
bulky framework to mantis.
I do want to have a play with http://getuikit.com/ as that's a slightly
lighter framework, just to decide whether it's case of I'm not a fan of
current design's, or not a fan of some of the bulkier frameworks.
Having played around, there's definitely some things in the bootstrap
theme changes that I'm not keen on, and equally there's some things in the
DIFF that don't make sense (false<>true's switch around) - not sure if
that's intentional or not as it certainly looks like it may be bugs. The
filter box also is fairly broken on the browser I tried.
In terms of foundation, some of the way they name classes, and organise
things seems to be more natural coming from where we are with Mantis and
our current naming/css.
I’ve included 3 images in a table below – showing the foundation version,
current 1.3 and the bootstrap version. I could write out my opinions on the
positives/negatives of all 3 images, but I don’t want to do that (just yet)
so that others can have a think about what they’d actually want. The only
thing I would like to do is do a new version of the middle one, with some
updated css, and a 4th version using uikit to get a good comparison.
In terms of Mantis, and this is something I’ve said before, we have about
a) Logon Screen – First Page that anyone sees!
b) “My View”
c) “View Issues”
d) “View Issue”
e) “Report Issue”
Seperately to that, we have 3 components that are either separate or
a) Installation Process – Separate to mantis
b) Management screens – within Mantis, but only seen by admins
c) Flexiblity to end users provided by plugins etc
Personally, I think we really need to decide what we’d like a the views
(a-e) to look like, because, whilst I agree we need to modernise slightly,
I’m not sure that throwing in a big framework is necessarily the best fit.
I’m going to go off and create a logon screen using (uikit), and also
modernising the logon screen in 1.3 to get some updated comparison screen
shots. In the mean time, it would be interesting to know from others what
they like/dislike about the current and variants I posted above (which I’ve
deliberately left my personal views of what bits of each I like out of this
email to get some fair design ideas J)
Paul
-----Original Message-----
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI
Paul,
it seems your main concern is using Bootstrap
Post by Paul Richards
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.
I can't contribute that much to this decision as I have no own experience
using Bootstrap or any other comparable component.
I don't want to vote just because I read a few articles and comparisons about it.
What I noticed is a big amount of transferred CSS and JavaScript compared
to the current version. (about additional 700KB when opening for the first
time, but also more traffic for following requests)
Are there any known issues using Bootstrap?
Roland
Post by Paul Richards
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their
own custom functionality.
Post by Paul Richards
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for
everything.
Post by Paul Richards
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages
as necessary.
Post by Paul Richards
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based
on the 1.3 plan.
Post by Paul Richards
We agreed to ship 1.3 first so

When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around
whether to use bootstrap.
Post by Paul Richards
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
back in January to use the following approach regarding external
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for
MantisBT itself.
Post by Paul Richards
Post by P Richards
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than
just being negative.
Post by Paul Richards
Post by P Richards
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two
probably go together in the end.
Post by Paul Richards
Post by P Richards
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need
to decide what works best long term.
Post by Paul Richards
Post by P Richards
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an
easy win for end users and plugin author’s for styling.
P Richards
2014-08-25 17:17:26 UTC
Permalink
Alain,



According to them it is, An article was posted by someone recently (http://zslabs.com/articles/do-more-with-less) about moving away from foundation (Which they’d used for years) to uikit and links to UIKit’s own blog article - http://yootheme.com/blog/2013/08/13/how-big-is-uikit



In terms of variants, my thoughts on the 3 were:



Left: orange/red is a bit too bright. I quite like the sign up/lost password being in a separate box – makes it fairly clear and separate to the logon form.

Mid: box ‘submenu’ doesn’t really stand out – [] make it look dated. Needs to look less like a table of data.

Right: Signup/warnings either aren’t that clear, or in wrong order ( separate panel from left/mid is probably better design. I think I prefer logo’s being on left rather than right of username/password box. Submit button should probably be centered.



I’m going to spent an hour now and see how easy it is to theme the same page with uikit, to get an idea of file size.



Paul







From: Alain D'EURVEILHER [mailto:***@gmail.com]
Sent: 25 August 2014 16:26
To: developer discussions
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



Hi every one,

Wow! All that orange color scares me a lot, on the Foundation style (If I may give my preferences as well).

For now on the 3, I definatelly go for the Mantis 1.3 and Bootstrap.

Although I am really fine with the Mantis 1.3 (sort of get used to it) I have a preference for the bootstrap version, because it's new and soft. And also because I'm starting to get used to this framework myself by working on another tool (using the ace template too by the way).

I did not know about the ligth uikit, and I like it. If is is really much lighter, I think I would prefer uikit, considering the era of mobile devices we live with today. After all the main components used by bootstrap are defined in UiKit so.
Also, to be sure about the size, I think the comparison should take all the uikit core + the different add-ons if needed in Mantis (autocomplete, validation etc...) + the mantis customizations.

Regards,
AlainD.





On Mon, Aug 25, 2014 at 4:25 PM, P Richards <***@mantisforge.org <mailto:***@mantisforge.org> > wrote:

I spent the last couple of days trying to theme a few of the common end-user pages i.e. not the management bit with foundation - that actually comes in slightly smaller in terms of data transfer, and also taking a look at the bootstrap PR.



I'm slowly coming to the conclusion that given the approach we've gone so far, and plugins - and that we spent some effort into trying to make the current master have better css etc, that I'm probably against adding a bulky framework to mantis.



I do want to have a play with http://getuikit.com/ as that's a slightly lighter framework, just to decide whether it's case of I'm not a fan of current design's, or not a fan of some of the bulkier frameworks.



Having played around, there's definitely some things in the bootstrap theme changes that I'm not keen on, and equally there's some things in the DIFF that don't make sense (false<>true's switch around) - not sure if that's intentional or not as it certainly looks like it may be bugs. The filter box also is fairly broken on the browser I tried.



In terms of foundation, some of the way they name classes, and organise things seems to be more natural coming from where we are with Mantis and our current naming/css.



I’ve included 3 images in a table below – showing the foundation version, current 1.3 and the bootstrap version. I could write out my opinions on the positives/negatives of all 3 images, but I don’t want to do that (just yet) so that others can have a think about what they’d actually want. The only thing I would like to do is do a new version of the middle one, with some updated css, and a 4th version using uikit to get a good comparison.












In terms of Mantis, and this is something I’ve said before, we have about 5 ‘key’ components that I’d expect a user to use on a daily basis:



a) Logon Screen – First Page that anyone sees!

b) “My View”

c) “View Issues”

d) “View Issue”

e) “Report Issue”



Seperately to that, we have 3 components that are either separate or integrated – but lesser used:



a) Installation Process – Separate to mantis

b) Management screens – within Mantis, but only seen by admins

c) Flexiblity to end users provided by plugins etc



Personally, I think we really need to decide what we’d like a the views (a-e) to look like, because, whilst I agree we need to modernise slightly, I’m not sure that throwing in a big framework is necessarily the best fit.



I’m going to go off and create a logon screen using (uikit), and also modernising the logon screen in 1.3 to get some updated comparison screen shots. In the mean time, it would be interesting to know from others what they like/dislike about the current and variants I posted above (which I’ve deliberately left my personal views of what bits of each I like out of this email to get some fair design ideas :))



Paul









-----Original Message-----
From: Roland Becker [mailto:***@atrol.de <mailto:***@atrol.de> ]
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards

Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



Paul,



it seems your main concern is using Bootstrap
Post by Paul Richards
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.



I can't contribute that much to this decision as I have no own experience using Bootstrap or any other comparable component.

I don't want to vote just because I read a few articles and comparisons about it.



What I noticed is a big amount of transferred CSS and JavaScript compared to the current version. (about additional 700KB when opening for the first time, but also more traffic for following requests)



Are there any known issues using Bootstrap?



Roland
Post by Paul Richards
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their own custom functionality.
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for everything.
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages as necessary.
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based on the 1.3 plan.
We agreed to ship 1.3 first so

When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around whether to use bootstrap.
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for MantisBT itself.
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than just being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two probably go together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need to decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an easy win for end users and plugin author’s for styling.
P Richards
2014-08-25 23:48:58 UTC
Permalink
Right, having mocked up a logon page under UIKit also, I’m finding the following page request sizes for the first hit to the logon page:



Mantis - Current - 158KB

UIKit - 208KB

Foundation - 272KB

Bootstrap - 378KB



Paul



From: Alain D'EURVEILHER [mailto:***@gmail.com]
Sent: 25 August 2014 16:26
To: developer discussions
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



Hi every one,

Wow! All that orange color scares me a lot, on the Foundation style (If I may give my preferences as well).

For now on the 3, I definatelly go for the Mantis 1.3 and Bootstrap.

Although I am really fine with the Mantis 1.3 (sort of get used to it) I have a preference for the bootstrap version, because it's new and soft. And also because I'm starting to get used to this framework myself by working on another tool (using the ace template too by the way).

I did not know about the ligth uikit, and I like it. If is is really much lighter, I think I would prefer uikit, considering the era of mobile devices we live with today. After all the main components used by bootstrap are defined in UiKit so.
Also, to be sure about the size, I think the comparison should take all the uikit core + the different add-ons if needed in Mantis (autocomplete, validation etc...) + the mantis customizations.

Regards,
AlainD.





On Mon, Aug 25, 2014 at 4:25 PM, P Richards <***@mantisforge.org <mailto:***@mantisforge.org> > wrote:

I spent the last couple of days trying to theme a few of the common end-user pages i.e. not the management bit with foundation - that actually comes in slightly smaller in terms of data transfer, and also taking a look at the bootstrap PR.



I'm slowly coming to the conclusion that given the approach we've gone so far, and plugins - and that we spent some effort into trying to make the current master have better css etc, that I'm probably against adding a bulky framework to mantis.



I do want to have a play with http://getuikit.com/ as that's a slightly lighter framework, just to decide whether it's case of I'm not a fan of current design's, or not a fan of some of the bulkier frameworks.



Having played around, there's definitely some things in the bootstrap theme changes that I'm not keen on, and equally there's some things in the DIFF that don't make sense (false<>true's switch around) - not sure if that's intentional or not as it certainly looks like it may be bugs. The filter box also is fairly broken on the browser I tried.



In terms of foundation, some of the way they name classes, and organise things seems to be more natural coming from where we are with Mantis and our current naming/css.



I’ve included 3 images in a table below – showing the foundation version, current 1.3 and the bootstrap version. I could write out my opinions on the positives/negatives of all 3 images, but I don’t want to do that (just yet) so that others can have a think about what they’d actually want. The only thing I would like to do is do a new version of the middle one, with some updated css, and a 4th version using uikit to get a good comparison.












In terms of Mantis, and this is something I’ve said before, we have about 5 ‘key’ components that I’d expect a user to use on a daily basis:



a) Logon Screen – First Page that anyone sees!

b) “My View”

c) “View Issues”

d) “View Issue”

e) “Report Issue”



Seperately to that, we have 3 components that are either separate or integrated – but lesser used:



a) Installation Process – Separate to mantis

b) Management screens – within Mantis, but only seen by admins

c) Flexiblity to end users provided by plugins etc



Personally, I think we really need to decide what we’d like a the views (a-e) to look like, because, whilst I agree we need to modernise slightly, I’m not sure that throwing in a big framework is necessarily the best fit.



I’m going to go off and create a logon screen using (uikit), and also modernising the logon screen in 1.3 to get some updated comparison screen shots. In the mean time, it would be interesting to know from others what they like/dislike about the current and variants I posted above (which I’ve deliberately left my personal views of what bits of each I like out of this email to get some fair design ideas :))



Paul









-----Original Message-----
From: Roland Becker [mailto:***@atrol.de <mailto:***@atrol.de> ]
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards

Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



Paul,



it seems your main concern is using Bootstrap
Post by Paul Richards
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.



I can't contribute that much to this decision as I have no own experience using Bootstrap or any other comparable component.

I don't want to vote just because I read a few articles and comparisons about it.



What I noticed is a big amount of transferred CSS and JavaScript compared to the current version. (about additional 700KB when opening for the first time, but also more traffic for following requests)



Are there any known issues using Bootstrap?



Roland
Post by Paul Richards
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their own custom functionality.
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for everything.
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages as necessary.
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based on the 1.3 plan.
We agreed to ship 1.3 first so

When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around whether to use bootstrap.
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for MantisBT itself.
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than just being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two probably go together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need to decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an easy win for end users and plugin author’s for styling.
Robert Munteanu
2014-08-25 15:56:19 UTC
Permalink
Hi Paul,

"Perfect is the enemy of good".

I understand that you don't 100% agree with the 'modern UI' submission. I
for one think that it's one of the best things happening to MantisBT in the
last years from user's point of view. But that doesn't really matter right
now.

What IMO matters is that we have a submission, ready for review, admittedly
with kinks that we can iron out which brings a lot of value. On the other
hand we have the promise of _another_ ui submission, which I'm sure Rafik
can say is not a trivial matter.

I say it would be more productive to try and get this PR into shape and
merge it into MantisBT. We simply can't afford this type of duplicated
work, especially since we want the new DB layer in for 2.0, just like the
Modern UI.

Thanks,

Robert
Post by P Richards
I spent the last couple of days trying to theme a few of the common
end-user pages i.e. not the management bit with foundation - that actually
comes in slightly smaller in terms of data transfer, and also taking a look
at the bootstrap PR.
I'm slowly coming to the conclusion that given the approach we've gone so
far, and plugins - and that we spent some effort into trying to make the
current master have better css etc, that I'm probably against adding a
bulky framework to mantis.
I do want to have a play with http://getuikit.com/ as that's a slightly
lighter framework, just to decide whether it's case of I'm not a fan of
current design's, or not a fan of some of the bulkier frameworks.
Having played around, there's definitely some things in the bootstrap
theme changes that I'm not keen on, and equally there's some things in the
DIFF that don't make sense (false<>true's switch around) - not sure if
that's intentional or not as it certainly looks like it may be bugs. The
filter box also is fairly broken on the browser I tried.
In terms of foundation, some of the way they name classes, and organise
things seems to be more natural coming from where we are with Mantis and
our current naming/css.
I’ve included 3 images in a table below – showing the foundation version,
current 1.3 and the bootstrap version. I could write out my opinions on the
positives/negatives of all 3 images, but I don’t want to do that (just yet)
so that others can have a think about what they’d actually want. The only
thing I would like to do is do a new version of the middle one, with some
updated css, and a 4th version using uikit to get a good comparison.
In terms of Mantis, and this is something I’ve said before, we have about
a) Logon Screen – First Page that anyone sees!
b) “My View”
c) “View Issues”
d) “View Issue”
e) “Report Issue”
Seperately to that, we have 3 components that are either separate or
a) Installation Process – Separate to mantis
b) Management screens – within Mantis, but only seen by admins
c) Flexiblity to end users provided by plugins etc
Personally, I think we really need to decide what we’d like a the views
(a-e) to look like, because, whilst I agree we need to modernise slightly,
I’m not sure that throwing in a big framework is necessarily the best fit.
I’m going to go off and create a logon screen using (uikit), and also
modernising the logon screen in 1.3 to get some updated comparison screen
shots. In the mean time, it would be interesting to know from others what
they like/dislike about the current and variants I posted above (which I’ve
deliberately left my personal views of what bits of each I like out of this
email to get some fair design ideas J)
Paul
-----Original Message-----
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI
Paul,
it seems your main concern is using Bootstrap
Post by Paul Richards
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.
I can't contribute that much to this decision as I have no own experience
using Bootstrap or any other comparable component.
I don't want to vote just because I read a few articles and comparisons about it.
What I noticed is a big amount of transferred CSS and JavaScript compared
to the current version. (about additional 700KB when opening for the first
time, but also more traffic for following requests)
Are there any known issues using Bootstrap?
Roland
Post by Paul Richards
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their
own custom functionality.
Post by Paul Richards
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for
everything.
Post by Paul Richards
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages
as necessary.
Post by Paul Richards
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based
on the 1.3 plan.
Post by Paul Richards
We agreed to ship 1.3 first so

When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around
whether to use bootstrap.
Post by Paul Richards
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
back in January to use the following approach regarding external
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for
MantisBT itself.
Post by Paul Richards
Post by P Richards
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than
just being negative.
Post by Paul Richards
Post by P Richards
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two
probably go together in the end.
Post by Paul Richards
Post by P Richards
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need
to decide what works best long term.
Post by Paul Richards
Post by P Richards
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an
easy win for end users and plugin author’s for styling.
P Richards
2014-08-25 16:54:45 UTC
Permalink
Robert,



We’ve spent a lot of time optimising mantis to be smaller (in terms of CSS/HTML in 1.3) – at the moment, adding bootstrap would reverse that effort.



Personally, as it stands, I’d be for keeping the current look and feel for mantis and enhancing the CSS, and keeping the smaller file size. If you compare the CSS/HTML between 1.2 and 1.3, we’ve actually done a fair chunk in this regard already(, and not got that work to users.)



My reason for playing with foundation was to evaluate frameworks and whether to use them in Mantis – so far, having looked at Bootstrap+foundation, my thinking is “No, do not use”. My reason for wanting to have a look at UIKIT, is to see the size of a page request, and whether some frameworks provide the framework, without substantially increasing page response size.



Paul







From: Robert Munteanu [mailto:***@gmail.com]
Sent: 25 August 2014 16:56
To: developer discussions
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



Hi Paul,

"Perfect is the enemy of good".

I understand that you don't 100% agree with the 'modern UI' submission. I for one think that it's one of the best things happening to MantisBT in the last years from user's point of view. But that doesn't really matter right now.

What IMO matters is that we have a submission, ready for review, admittedly with kinks that we can iron out which brings a lot of value. On the other hand we have the promise of _another_ ui submission, which I'm sure Rafik can say is not a trivial matter.

I say it would be more productive to try and get this PR into shape and merge it into MantisBT. We simply can't afford this type of duplicated work, especially since we want the new DB layer in for 2.0, just like the Modern UI.

Thanks,

Robert



On Mon, Aug 25, 2014 at 5:25 PM, P Richards <***@mantisforge.org <mailto:***@mantisforge.org> > wrote:

I spent the last couple of days trying to theme a few of the common end-user pages i.e. not the management bit with foundation - that actually comes in slightly smaller in terms of data transfer, and also taking a look at the bootstrap PR.



I'm slowly coming to the conclusion that given the approach we've gone so far, and plugins - and that we spent some effort into trying to make the current master have better css etc, that I'm probably against adding a bulky framework to mantis.



I do want to have a play with http://getuikit.com/ as that's a slightly lighter framework, just to decide whether it's case of I'm not a fan of current design's, or not a fan of some of the bulkier frameworks.



Having played around, there's definitely some things in the bootstrap theme changes that I'm not keen on, and equally there's some things in the DIFF that don't make sense (false<>true's switch around) - not sure if that's intentional or not as it certainly looks like it may be bugs. The filter box also is fairly broken on the browser I tried.



In terms of foundation, some of the way they name classes, and organise things seems to be more natural coming from where we are with Mantis and our current naming/css.



I’ve included 3 images in a table below – showing the foundation version, current 1.3 and the bootstrap version. I could write out my opinions on the positives/negatives of all 3 images, but I don’t want to do that (just yet) so that others can have a think about what they’d actually want. The only thing I would like to do is do a new version of the middle one, with some updated css, and a 4th version using uikit to get a good comparison.












In terms of Mantis, and this is something I’ve said before, we have about 5 ‘key’ components that I’d expect a user to use on a daily basis:



a) Logon Screen – First Page that anyone sees!

b) “My View”

c) “View Issues”

d) “View Issue”

e) “Report Issue”



Seperately to that, we have 3 components that are either separate or integrated – but lesser used:



a) Installation Process – Separate to mantis

b) Management screens – within Mantis, but only seen by admins

c) Flexiblity to end users provided by plugins etc



Personally, I think we really need to decide what we’d like a the views (a-e) to look like, because, whilst I agree we need to modernise slightly, I’m not sure that throwing in a big framework is necessarily the best fit.



I’m going to go off and create a logon screen using (uikit), and also modernising the logon screen in 1.3 to get some updated comparison screen shots. In the mean time, it would be interesting to know from others what they like/dislike about the current and variants I posted above (which I’ve deliberately left my personal views of what bits of each I like out of this email to get some fair design ideas :))



Paul









-----Original Message-----
From: Roland Becker [mailto:***@atrol.de <mailto:***@atrol.de> ]
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards

Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



Paul,



it seems your main concern is using Bootstrap
Post by Paul Richards
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.



I can't contribute that much to this decision as I have no own experience using Bootstrap or any other comparable component.

I don't want to vote just because I read a few articles and comparisons about it.



What I noticed is a big amount of transferred CSS and JavaScript compared to the current version. (about additional 700KB when opening for the first time, but also more traffic for following requests)



Are there any known issues using Bootstrap?



Roland
Post by Paul Richards
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their own custom functionality.
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for everything.
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages as necessary.
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based on the 1.3 plan.
We agreed to ship 1.3 first so

When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around whether to use bootstrap.
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for MantisBT itself.
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than just being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two probably go together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need to decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an easy win for end users and plugin author’s for styling.
Robert Munteanu
2014-08-25 20:35:39 UTC
Permalink
Post by P Richards
Robert,
We’ve spent a lot of time optimising mantis to be smaller (in terms of
CSS/HTML in 1.3) – at the moment, adding bootstrap would reverse that
effort.
Is that really a goal? Same bland look, but faster loading?
Post by P Richards
Personally, as it stands, I’d be for keeping the current look and feel for
mantis and enhancing the CSS, and keeping the smaller file size. If you
compare the CSS/HTML between 1.2 and 1.3, we’ve actually done a fair chunk
in this regard already(, and not got that work to users.)
Well, that's your personal opinion. My personal opinion is that looks beat
rendering speed all the time. Maybe others have an opinion as well...
otherwise it's you and me arguing, which is not very productive :-)
Post by P Richards
My reason for playing with foundation was to evaluate frameworks and
whether to use them in Mantis – so far, having looked at
Bootstrap+foundation, my thinking is “No, do not use”. My reason for
wanting to have a look at UIKIT, is to see the size of a page request, and
whether some frameworks provide the framework, without substantially
increasing page response size.
Really, I don't see the point in this. Will we ask Rafik to rewrite the
contribution in whatever UI toolkit we favour? I don't think it's fair or
realistic. Will we reject the contribution and wait for your contribution
using UIKit or whatever you think is better? I don't think that's fair
either. And we previously discussed that we won't block existing
contributions for future promised ones.

Robert
Post by P Richards
Paul
*Sent:* 25 August 2014 16:56
*To:* developer discussions
*Subject:* Re: [mantisbt-dev] Introducing MantisBT Modern UI
Hi Paul,
"Perfect is the enemy of good".
I understand that you don't 100% agree with the 'modern UI' submission. I
for one think that it's one of the best things happening to MantisBT in the
last years from user's point of view. But that doesn't really matter right
now.
What IMO matters is that we have a submission, ready for review,
admittedly with kinks that we can iron out which brings a lot of value. On
the other hand we have the promise of _another_ ui submission, which I'm
sure Rafik can say is not a trivial matter.
I say it would be more productive to try and get this PR into shape and
merge it into MantisBT. We simply can't afford this type of duplicated
work, especially since we want the new DB layer in for 2.0, just like the
Modern UI.
Thanks,
Robert
I spent the last couple of days trying to theme a few of the common
end-user pages i.e. not the management bit with foundation - that actually
comes in slightly smaller in terms of data transfer, and also taking a look
at the bootstrap PR.
I'm slowly coming to the conclusion that given the approach we've gone so
far, and plugins - and that we spent some effort into trying to make the
current master have better css etc, that I'm probably against adding a
bulky framework to mantis.
I do want to have a play with http://getuikit.com/ as that's a slightly
lighter framework, just to decide whether it's case of I'm not a fan of
current design's, or not a fan of some of the bulkier frameworks.
Having played around, there's definitely some things in the bootstrap
theme changes that I'm not keen on, and equally there's some things in the
DIFF that don't make sense (false<>true's switch around) - not sure if
that's intentional or not as it certainly looks like it may be bugs. The
filter box also is fairly broken on the browser I tried.
In terms of foundation, some of the way they name classes, and organise
things seems to be more natural coming from where we are with Mantis and
our current naming/css.
I’ve included 3 images in a table below – showing the foundation version,
current 1.3 and the bootstrap version. I could write out my opinions on the
positives/negatives of all 3 images, but I don’t want to do that (just yet)
so that others can have a think about what they’d actually want. The only
thing I would like to do is do a new version of the middle one, with some
updated css, and a 4th version using uikit to get a good comparison.
In terms of Mantis, and this is something I’ve said before, we have about
a) Logon Screen – First Page that anyone sees!
b) “My View”
c) “View Issues”
d) “View Issue”
e) “Report Issue”
Seperately to that, we have 3 components that are either separate or
a) Installation Process – Separate to mantis
b) Management screens – within Mantis, but only seen by admins
c) Flexiblity to end users provided by plugins etc
Personally, I think we really need to decide what we’d like a the views
(a-e) to look like, because, whilst I agree we need to modernise slightly,
I’m not sure that throwing in a big framework is necessarily the best fit.
I’m going to go off and create a logon screen using (uikit), and also
modernising the logon screen in 1.3 to get some updated comparison screen
shots. In the mean time, it would be interesting to know from others what
they like/dislike about the current and variants I posted above (which I’ve
deliberately left my personal views of what bits of each I like out of this
email to get some fair design ideas J)
Paul
-----Original Message-----
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI
Paul,
it seems your main concern is using Bootstrap
Post by Paul Richards
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.
I can't contribute that much to this decision as I have no own experience
using Bootstrap or any other comparable component.
I don't want to vote just because I read a few articles and comparisons about it.
What I noticed is a big amount of transferred CSS and JavaScript compared
to the current version. (about additional 700KB when opening for the first
time, but also more traffic for following requests)
Are there any known issues using Bootstrap?
Roland
Post by Paul Richards
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their
own custom functionality.
Post by Paul Richards
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for
everything.
Post by Paul Richards
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages
as necessary.
Post by Paul Richards
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based
on the 1.3 plan.
Post by Paul Richards
We agreed to ship 1.3 first so

When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around
whether to use bootstrap.
Post by Paul Richards
Paul
Post by P Richards
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
back in January to use the following approach regarding external
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for
MantisBT itself.
Post by Paul Richards
Post by P Richards
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than
just being negative.
Post by Paul Richards
Post by P Richards
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two
probably go together in the end.
Post by Paul Richards
Post by P Richards
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need
to decide what works best long term.
Post by Paul Richards
Post by P Richards
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an
easy win for end users and plugin author’s for styling.
P Richards
2014-08-25 21:14:16 UTC
Permalink
On Mon, Aug 25, 2014 at 7:54 PM, P Richards <***@mantisforge.org <mailto:***@mantisforge.org> > wrote:

Robert,



We’ve spent a lot of time optimising mantis to be smaller (in terms of CSS/HTML in 1.3) – at the moment, adding bootstrap would reverse that effort.



Is that really a goal? Same bland look, but faster loading?



Pretty sure I didn’t say same bland look – In fact, I said we need to enhance the CSS (i.e. look). What I’m not keen on is breaking changes to the design that aren’t necessarily for the better long term, without evaluating the approach.





My reason for playing with foundation was to evaluate frameworks and whether to use them in Mantis – so far, having looked at Bootstrap+foundation, my thinking is “No, do not use”. My reason for wanting to have a look at UIKIT, is to see the size of a page request, and whether some frameworks provide the framework, without substantially increasing page response size.



Really, I don't see the point in this. Will we ask Rafik to rewrite the contribution in whatever UI toolkit we favour? I don't think it's fair or realistic. Will we reject the contribution and wait for your contribution using UIKit or whatever you think is better? I don't think that's fair either. And we previously discussed that we won't block existing contributions for future promised ones.

--



We’ve had a number of look/feel/UI changes that we’ve not put in in the past for various reasons. Coming up with a contribution that removes features that people use (atrol said about footers iirc) and radically changes the look needs to fit in with existing users. At the moment, Rafik’s work changes too much, breaks some functionality and I don’t necessarily believe is the right way forward. I think we can do an approach that allows people to keep the same look now whilst also giving people a new look that which to use it – hence evaluating options.



As Alain said in his post, given that more people are using mobile devices and wifi etc, size is actually important.



At the moment, my view is not to add bootstrap or foundation to mantis. This is given the changes currently in 1.3 over 1.2, the overhead of those frameworks, and the fact it’s a complete breaking change for plugins etc. My rational for looking at UI Kit etc as well, is to work out if that’s a long term view (aka 2.x) or just a 1.3 view.



I’m definitely against this UI going into 1.3 – although I think most of the team have agreed that a radical UI change like this would be a 2.x change. Equally, it’s highlighted that the CSS we currently have in 1.3 can be improved, and this would be a non-breaking change for users.



Paul
Rolf Kleef
2014-08-25 21:17:55 UTC
Permalink
Post by P Richards
I for one think that it's one of the best things happening to MantisBT
in the last years from user's point of view.
As a lurker who uses and occasionally scratches his own itch adapting
Mantis: +1

I see people try basically ANY bug tracker other than Mantis, to just
not have to show Mantis, despite running into un-satisfied requirements
that Mantis can do out of the box or could do with a little tailoring
(n=3, it's a small sample)
Post by P Richards
I'm sure Rafik can say is not a trivial matter.
As someone who burnt his fingers on trying to work towards a more
MVC-based version of Mantis (years ago by now) for a more generic "issue
workflow/case management engine", I can only say that Rafik's proposal
will help take away a first layer of scaring off new users: it will look
like something they'd expect to see, whether the mental model is clear
or not.

So: I'll happily flip through a few more cat videos on a
(Bootstrap-based?) social platform while you figure out how to shave off
a few KBs from Mantis and fix some tabs/spaces?

...

My 2 cents and 0 bits: release 1.3, then merge Rafik's stuff and/or
Paul's Db stuff, and release as 1.4, 2.0, 3.x, I don't care, but get
agile: release early, release often. Test things, break things, fix it.

The process is stuck in the 20th century. The visual interface is just
an expression of that.

~~Rolf.
Victor Boctor
2014-08-26 06:26:18 UTC
Permalink
Thanks Rolf and Alan for the feedback.

Paul,

- Rafik’s work is based on one of the most popular frameworks, it involves months of intense work, and gets the job done nicely. I don’t see a reason to reset this work for some incremental improvements from a perspective that only you hold.

- Rafik’s work covers all pages, not just the main pages (your a..e), it also includes management, installation, and even deprecated pages like news, etc. So it is comprehensive and there is no jumping between modern and legacy experience. Again, that is one of the reason it is a lot of work.

- Making every discussion so difficult, not appreciating others work, and always having reasons why changes can’t go in will generally result in losing contributors and not making progress.

- Post 1.3 (v2.0), we are going to break plugins compatibility. Plugins can be easily adapted to follow the lead of the core Mantis in terms of the UI.

- If there are bugs in the filter box or something else, I’m sure Rafik would be happy to handle it as part of the pull request.

- I never knew that we were trying to optimize for the size of the css. I thought we just don’t like writing much CSS, hence, we had smallish size. Heck, if we were, then the first thing we should have done would have been to minify these css files. Given the scale of use of a Mantis instance and the nature of 1st load vs. Nth load, most of these files will be cached anyway.

- I have seen a lot of users complain about Mantis look as a show stopper for using it. I have also seen us have several failing attempts to modernize the UI. So let’s not screw this one up. As Robert and other said, it is the best thing that happened to our users recently. Users don’t care about code conventions, spaces, api cleanup, db api or any of this stuff. They want a product that works, has functionality they need, and looks decent.

- I personally think that we spend more energy in Mantis than we should because we don’t build on top of any frameworks that can increase our productivity and have us follow some technology that others in the industry leverage every day.

I can keep going, but I think you get where I’m heading. My understand is the following:

- Damien, Robert, Roland and I are all in favor of the change.

- We got several good praises from others on the DL.

- Rafik has applied all feedback we gave him earlier on the UI, and has published the pull request to get code feedback. Let’s be pragmatic and go through this process to deliver this to our users.

- Once pull request is ready it will be committed to master after 1.3 branch is created.
Post by Rolf Kleef
Post by P Richards
I for one think that it's one of the best things happening to MantisBT
in the last years from user's point of view.
As a lurker who uses and occasionally scratches his own itch adapting
Mantis: +1
I see people try basically ANY bug tracker other than Mantis, to just
not have to show Mantis, despite running into un-satisfied requirements
that Mantis can do out of the box or could do with a little tailoring
(n=3, it's a small sample)
Post by P Richards
I'm sure Rafik can say is not a trivial matter.
As someone who burnt his fingers on trying to work towards a more
MVC-based version of Mantis (years ago by now) for a more generic "issue
workflow/case management engine", I can only say that Rafik's proposal
will help take away a first layer of scaring off new users: it will look
like something they'd expect to see, whether the mental model is clear
or not.
So: I'll happily flip through a few more cat videos on a
(Bootstrap-based?) social platform while you figure out how to shave off
a few KBs from Mantis and fix some tabs/spaces?
...
My 2 cents and 0 bits: release 1.3, then merge Rafik's stuff and/or
Paul's Db stuff, and release as 1.4, 2.0, 3.x, I don't care, but get
agile: release early, release often. Test things, break things, fix it.
The process is stuck in the 20th century. The visual interface is just
an expression of that.
~~Rolf.
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Alain D'EURVEILHER
2014-08-26 07:02:35 UTC
Permalink
"Users don’t care about code conventions, spaces, api cleanup, db api or
any of this stuff. They want a product that works, has functionality they
need, and looks decent."

Exactly! I wouldn't say no more :-) That's also what Rolf said about beeing
agile.

AlainD.
Post by Victor Boctor
Thanks Rolf and Alan for the feedback.
Paul,
- Rafik’s work is based on one of the most popular frameworks, it involves
months of intense work, and gets the job done nicely. I don’t see a reason
to reset this work for some incremental improvements from a perspective
that only you hold.
- Rafik’s work covers all pages, not just the main pages (your a..e), it
also includes management, installation, and even deprecated pages like
news, etc. So it is comprehensive and there is no jumping between modern
and legacy experience. Again, that is one of the reason it is a lot of
work.
- Making every discussion so difficult, not appreciating others work, and
always having reasons why changes can’t go in will generally result in
losing contributors and not making progress.
- Post 1.3 (v2.0), we are going to break plugins compatibility. Plugins
can be easily adapted to follow the lead of the core Mantis in terms of the
UI.
- If there are bugs in the filter box or something else, I’m sure Rafik
would be happy to handle it as part of the pull request.
- I never knew that we were trying to optimize for the size of the css. I
thought we just don’t like writing much CSS, hence, we had smallish size.
Heck, if we were, then the first thing we should have done would have been
to minify these css files. Given the scale of use of a Mantis instance and
the nature of 1st load vs. Nth load, most of these files will be cached
anyway.
- I have seen a lot of users complain about Mantis look as a show stopper
for using it. I have also seen us have several failing attempts to
modernize the UI. So let’s not screw this one up. As Robert and other
said, it is the best thing that happened to our users recently. Users
don’t care about code conventions, spaces, api cleanup, db api or any of
this stuff. They want a product that works, has functionality they need,
and looks decent.
- I personally think that we spend more energy in Mantis than we should
because we don’t build on top of any frameworks that can increase our
productivity and have us follow some technology that others in the industry
leverage every day.
I can keep going, but I think you get where I’m heading. My understand is
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and has
published the pull request to get code feedback. Let’s be pragmatic and go
through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3 branch is created.
Post by Rolf Kleef
Post by P Richards
I for one think that it's one of the best things happening to MantisBT
in the last years from user's point of view.
As a lurker who uses and occasionally scratches his own itch adapting
Mantis: +1
I see people try basically ANY bug tracker other than Mantis, to just
not have to show Mantis, despite running into un-satisfied requirements
that Mantis can do out of the box or could do with a little tailoring
(n=3, it's a small sample)
Post by P Richards
I'm sure Rafik can say is not a trivial matter.
As someone who burnt his fingers on trying to work towards a more
MVC-based version of Mantis (years ago by now) for a more generic "issue
workflow/case management engine", I can only say that Rafik's proposal
will help take away a first layer of scaring off new users: it will look
like something they'd expect to see, whether the mental model is clear
or not.
So: I'll happily flip through a few more cat videos on a
(Bootstrap-based?) social platform while you figure out how to shave off
a few KBs from Mantis and fix some tabs/spaces?
...
My 2 cents and 0 bits: release 1.3, then merge Rafik's stuff and/or
Paul's Db stuff, and release as 1.4, 2.0, 3.x, I don't care, but get
agile: release early, release often. Test things, break things, fix it.
The process is stuck in the 20th century. The visual interface is just
an expression of that.
~~Rolf.
------------------------------------------------------------------------------
Post by Rolf Kleef
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
Roland Becker
2014-08-26 07:49:18 UTC
Permalink
"Users don’t care about code conventions, spaces, api cleanup, db api or any
of this stuff."
That's also what Rolf said about beeing agile.
Agile does not mean that MantisBT developers don't have to care about it.
You should respect this work the same way you respect the UI work.
We will end in mess and technical debt without it.

Roland
"Users don’t care about code conventions, spaces, api cleanup, db api or
any of this stuff. They want a product that works, has functionality they
need, and looks decent."
Exactly! I wouldn't say no more :-) That's also what Rolf said about beeing
agile.
AlainD.
Post by Victor Boctor
Thanks Rolf and Alan for the feedback.
Paul,
- Rafik’s work is based on one of the most popular frameworks, it involves
months of intense work, and gets the job done nicely.  I don’t see a reason
to reset this work for some incremental improvements from a perspective
that only you hold.
- Rafik’s work covers all pages, not just the main pages (your a..e), it
also includes management, installation, and even deprecated pages like
news, etc.  So it is comprehensive and there is no jumping between modern
and legacy experience.  Again, that is one of the reason it is a lot of
work.
- Making every discussion so difficult, not appreciating others work, and
always having reasons why changes can’t go in will generally result in
losing contributors and not making progress.
- Post 1.3 (v2.0), we are going to break plugins compatibility.  Plugins
can be easily adapted to follow the lead of the core Mantis in terms of the
UI.
- If there are bugs in the filter box or something else, I’m sure Rafik
would be happy to handle it as part of the pull request.
- I never knew that we were trying to optimize for the size of the css.  I
thought we just don’t like writing much CSS, hence, we had smallish size.
Heck, if we were, then the first thing we should have done would have been
to minify these css files.  Given the scale of use of a Mantis instance and
the nature of 1st load vs. Nth load, most of these files will be cached
anyway.
- I have seen a lot of users complain about Mantis look as a show stopper
for using it.  I have also seen us have several failing attempts to
modernize the UI.  So let’s not screw this one up.  As Robert and other
said, it is the best thing that happened to our users recently.  Users
don’t care about code conventions, spaces, api cleanup, db api or any of
this stuff. They want a product that works, has functionality they need,
and looks decent.
- I personally think that we spend more energy in Mantis than we should
because we don’t build on top of any frameworks that can increase our
productivity and have us follow some technology that others in the industry
leverage every day.
I can keep going, but I think you get where I’m heading.  My understand is
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and has
published the pull request to get code feedback.  Let’s be pragmatic and go
through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3
branch is created.
Post by Rolf Kleef
Post by P Richards
I for one think that it's one of the best things happening to MantisBT
in the last years from user's point of view.
As a lurker who uses and occasionally scratches his own itch adapting
Mantis: +1
I see people try basically ANY bug tracker other than Mantis, to just
not have to show Mantis, despite running into un-satisfied requirements
that Mantis can do out of the box or could do with a little tailoring
(n=3, it's a small sample)
Post by P Richards
I'm sure Rafik can say is not a trivial matter.
As someone who burnt his fingers on trying to work towards a more
MVC-based version of Mantis (years ago by now) for a more generic "issue
workflow/case management engine", I can only say that Rafik's proposal
will help take away a first layer of scaring off new users: it will look
like something they'd expect to see, whether the mental model is clear
or not.
So: I'll happily flip through a few more cat videos on a
(Bootstrap-based?) social platform while you figure out how to shave off
a few KBs from Mantis and fix some tabs/spaces?
...
My 2 cents and 0 bits: release 1.3, then merge Rafik's stuff and/or
Paul's Db stuff, and release as 1.4, 2.0, 3.x, I don't care, but get
agile: release early, release often. Test things, break things, fix it.
The process is stuck in the 20th century. The visual interface is just
an expression of that.
~~Rolf.
------------------------------------------------------------------------------
Post by Rolf Kleef
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
------------------------------------------------------------------------------
Slashdot TV. 
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Alain D'EURVEILHER
2014-08-26 08:15:01 UTC
Permalink
I know, I know. I do not mean any misrespect of any kind. But I think that
the idea is to find a correct balance between the users most expectations
(front end) and the design requirements and enhancements (mostly backends,
refactoring, etc...).

Don't worry, I totally understand the position of everyone.
In fact to be honest with you guys, I feel like v1.3 really takes a lot of
time to be released. I understand that you want to be sure it is very well
tested (i expect not less), but still. And I think that's because its
extensible roadmap. We make the same mistakes here in the team I work with,
and it's always the same thing: estimate a date of a release with a defined
roadmap. And a few weeks before the due date, there's always some new
features to add into it. Which sort of slow down the whole process (new
tests, integration tests, impacts, refactoring, bla bla bla...).
For me, you should release the 1.3 as is, turn that page for good, and
continue the discussion of the GUI for another release. We will not die
really if we don't have a new GUI now; we survived without it till now
after all.

I'm just saying.
Post by Roland Becker
Post by Alain D'EURVEILHER
"Users don’t care about code conventions, spaces, api cleanup, db api or
any
Post by Alain D'EURVEILHER
of this stuff."
That's also what Rolf said about beeing agile.
Agile does not mean that MantisBT developers don't have to care about it.
You should respect this work the same way you respect the UI work.
We will end in mess and technical debt without it.
Roland
um
Post by Alain D'EURVEILHER
"Users don’t care about code conventions, spaces, api cleanup, db api or
any of this stuff. They want a product that works, has functionality they
need, and looks decent."
Exactly! I wouldn't say no more :-) That's also what Rolf said about
beeing
Post by Alain D'EURVEILHER
agile.
AlainD.
Post by Victor Boctor
Thanks Rolf and Alan for the feedback.
Paul,
- Rafik’s work is based on one of the most popular frameworks, it
involves
Post by Alain D'EURVEILHER
Post by Victor Boctor
months of intense work, and gets the job done nicely. I don’t see a
reason
Post by Alain D'EURVEILHER
Post by Victor Boctor
to reset this work for some incremental improvements from a perspective
that only you hold.
- Rafik’s work covers all pages, not just the main pages (your a..e),
it
Post by Alain D'EURVEILHER
Post by Victor Boctor
also includes management, installation, and even deprecated pages like
news, etc. So it is comprehensive and there is no jumping between
modern
Post by Alain D'EURVEILHER
Post by Victor Boctor
and legacy experience. Again, that is one of the reason it is a lot of
work.
- Making every discussion so difficult, not appreciating others work,
and
Post by Alain D'EURVEILHER
Post by Victor Boctor
always having reasons why changes can’t go in will generally result in
losing contributors and not making progress.
- Post 1.3 (v2.0), we are going to break plugins compatibility.
Plugins
Post by Alain D'EURVEILHER
Post by Victor Boctor
can be easily adapted to follow the lead of the core Mantis in terms
of the
Post by Alain D'EURVEILHER
Post by Victor Boctor
UI.
- If there are bugs in the filter box or something else, I’m sure Rafik
would be happy to handle it as part of the pull request.
- I never knew that we were trying to optimize for the size of the
css. I
Post by Alain D'EURVEILHER
Post by Victor Boctor
thought we just don’t like writing much CSS, hence, we had smallish
size.
Post by Alain D'EURVEILHER
Post by Victor Boctor
Heck, if we were, then the first thing we should have done would have
been
Post by Alain D'EURVEILHER
Post by Victor Boctor
to minify these css files. Given the scale of use of a Mantis
instance and
Post by Alain D'EURVEILHER
Post by Victor Boctor
the nature of 1st load vs. Nth load, most of these files will be cached
anyway.
- I have seen a lot of users complain about Mantis look as a show
stopper
Post by Alain D'EURVEILHER
Post by Victor Boctor
for using it. I have also seen us have several failing attempts to
modernize the UI. So let’s not screw this one up. As Robert and other
said, it is the best thing that happened to our users recently. Users
don’t care about code conventions, spaces, api cleanup, db api or any
of
Post by Alain D'EURVEILHER
Post by Victor Boctor
this stuff. They want a product that works, has functionality they
need,
Post by Alain D'EURVEILHER
Post by Victor Boctor
and looks decent.
- I personally think that we spend more energy in Mantis than we should
because we don’t build on top of any frameworks that can increase our
productivity and have us follow some technology that others in the
industry
Post by Alain D'EURVEILHER
Post by Victor Boctor
leverage every day.
I can keep going, but I think you get where I’m heading. My
understand is
Post by Alain D'EURVEILHER
Post by Victor Boctor
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and has
published the pull request to get code feedback. Let’s be pragmatic
and go
Post by Alain D'EURVEILHER
Post by Victor Boctor
through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3
branch is created.
Post by Rolf Kleef
Post by P Richards
I for one think that it's one of the best things happening to
MantisBT
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
Post by P Richards
in the last years from user's point of view.
As a lurker who uses and occasionally scratches his own itch adapting
Mantis: +1
I see people try basically ANY bug tracker other than Mantis, to just
not have to show Mantis, despite running into un-satisfied
requirements
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
that Mantis can do out of the box or could do with a little tailoring
(n=3, it's a small sample)
Post by P Richards
I'm sure Rafik can say is not a trivial matter.
As someone who burnt his fingers on trying to work towards a more
MVC-based version of Mantis (years ago by now) for a more generic
"issue
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
workflow/case management engine", I can only say that Rafik's
proposal
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
will help take away a first layer of scaring off new users: it will
look
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
like something they'd expect to see, whether the mental model is
clear
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
or not.
So: I'll happily flip through a few more cat videos on a
(Bootstrap-based?) social platform while you figure out how to shave
off
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
a few KBs from Mantis and fix some tabs/spaces?
...
My 2 cents and 0 bits: release 1.3, then merge Rafik's stuff and/or
Paul's Db stuff, and release as 1.4, 2.0, 3.x, I don't care, but get
agile: release early, release often. Test things, break things, fix
it.
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
The process is stuck in the 20th century. The visual interface is
just
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
an expression of that.
~~Rolf.
------------------------------------------------------------------------------
Post by Alain D'EURVEILHER
Post by Victor Boctor
Post by Rolf Kleef
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
------------------------------------------------------------------------------
Post by Alain D'EURVEILHER
Post by Victor Boctor
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
------------------------------------------------------------------------------
Post by Alain D'EURVEILHER
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
P Richards
2014-08-30 23:24:08 UTC
Permalink
I doubt any one takes any offense :)



We’ve never really had a ‘roadmap’ as such for Mantis – at least not in recent years.



If you look at https://github.com/mantisbt/mantisbt/graphs/contributors, there’s very few people who actively code on Mantis historically:



Victor worked on Mantis code actively until ~2009. Jreese/David pretty much replacing him, when he moved countries/jobs. Although he’s kept active input on what’s going on in the project throughout. John stopped contributing when he changes jobs and finished school or whatever and wrote a blog post about php and/or mantis @ http://noswap.com/tags/php



David had his own visions of where to take mantis – a lot of the security http headers, crypto api stuff etc is from his input, form security etc.



After 1.2, David did a bunch of work on using gettext for translations, restructuring file system layout etc. Equally around the same time, I started looking at DB API.

At this point, Rombert came along to improve the SOAP API, and obviously Damien came along also working on fixing bugs in the core.



Going forwards (long term), we are probably actually in a reasonable position – as people care about Mantis.



The problem (short term) is we’ve had a 2 year period in the middle where personnel has changed, and what our plan is has changed.



Ignoring next/other branches (that we’ve agreed to not use, but port changes from to master), you can see some of that 2 year period from commits in the current master - it’s particularly evident in lang api if you look at the history: https://github.com/mantisbt/mantisbt/commits/master/core/lang_api.php



Aug 2010: end new lang api format ( me) – [performance increase]

(Next - April 2012 – replace lang api with gettext https://github.com/mantisbt/mantisbt/commit/8a2a5c1b6f937f9f97970b23a17bb9977a9d67f5)

Oct 2013: damien/myself: revert out new lang api format.



(Fast-forward a year, I think one of the reasons we pulled it (amongst how to generate language files in the right format) was whether we would look at moving to gettext in the future. I’d probably that won’t happen and we’d be better un-reverting that commit, and working with translatewiki to see if it’s possible to generate the language files.)



I’d like to see us pick a date to branch 1.3 for release, say 31st October 2014 (to give a chance to get all patches that already exist for 1.3 merged), and then say 1st January 2015 for 2.0.



Paul







From: Alain D'EURVEILHER [mailto:***@gmail.com]
Sent: 26 August 2014 09:15
To: Roland Becker
Cc: developer discussions
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



I know, I know. I do not mean any misrespect of any kind. But I think that the idea is to find a correct balance between the users most expectations (front end) and the design requirements and enhancements (mostly backends, refactoring, etc...).

Don't worry, I totally understand the position of everyone.

In fact to be honest with you guys, I feel like v1.3 really takes a lot of time to be released. I understand that you want to be sure it is very well tested (i expect not less), but still. And I think that's because its extensible roadmap. We make the same mistakes here in the team I work with, and it's always the same thing: estimate a date of a release with a defined roadmap. And a few weeks before the due date, there's always some new features to add into it. Which sort of slow down the whole process (new tests, integration tests, impacts, refactoring, bla bla bla...).
For me, you should release the 1.3 as is, turn that page for good, and continue the discussion of the GUI for another release. We will not die really if we don't have a new GUI now; we survived without it till now after all.

I'm just saying.
"Users don’t care about code conventions, spaces, api cleanup, db api or any
of this stuff."
That's also what Rolf said about beeing agile.
Agile does not mean that MantisBT developers don't have to care about it.
You should respect this work the same way you respect the UI work.
We will end in mess and technical debt without it.

Roland
"Users don’t care about code conventions, spaces, api cleanup, db api or
any of this stuff. They want a product that works, has functionality they
need, and looks decent."
Exactly! I wouldn't say no more :-) That's also what Rolf said about beeing
agile.
AlainD.
Post by Victor Boctor
Thanks Rolf and Alan for the feedback.
Paul,
- Rafik’s work is based on one of the most popular frameworks, it involves
months of intense work, and gets the job done nicely. I don’t see a reason
to reset this work for some incremental improvements from a perspective
that only you hold.
- Rafik’s work covers all pages, not just the main pages (your a..e), it
also includes management, installation, and even deprecated pages like
news, etc. So it is comprehensive and there is no jumping between modern
and legacy experience. Again, that is one of the reason it is a lot of
work.
- Making every discussion so difficult, not appreciating others work, and
always having reasons why changes can’t go in will generally result in
losing contributors and not making progress.
- Post 1.3 (v2.0), we are going to break plugins compatibility. Plugins
can be easily adapted to follow the lead of the core Mantis in terms of the
UI.
- If there are bugs in the filter box or something else, I’m sure Rafik
would be happy to handle it as part of the pull request.
- I never knew that we were trying to optimize for the size of the css. I
thought we just don’t like writing much CSS, hence, we had smallish size.
Heck, if we were, then the first thing we should have done would have been
to minify these css files. Given the scale of use of a Mantis instance and
the nature of 1st load vs. Nth load, most of these files will be cached
anyway.
- I have seen a lot of users complain about Mantis look as a show stopper
for using it. I have also seen us have several failing attempts to
modernize the UI. So let’s not screw this one up. As Robert and other
said, it is the best thing that happened to our users recently. Users
don’t care about code conventions, spaces, api cleanup, db api or any of
this stuff. They want a product that works, has functionality they need,
and looks decent.
- I personally think that we spend more energy in Mantis than we should
because we don’t build on top of any frameworks that can increase our
productivity and have us follow some technology that others in the industry
leverage every day.
I can keep going, but I think you get where I’m heading. My understand is
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and has
published the pull request to get code feedback. Let’s be pragmatic and go
through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3
branch is created.
Post by Rolf Kleef
Post by P Richards
I for one think that it's one of the best things happening to MantisBT
in the last years from user's point of view.
As a lurker who uses and occasionally scratches his own itch adapting
Mantis: +1
I see people try basically ANY bug tracker other than Mantis, to just
not have to show Mantis, despite running into un-satisfied requirements
that Mantis can do out of the box or could do with a little tailoring
(n=3, it's a small sample)
Post by P Richards
I'm sure Rafik can say is not a trivial matter.
As someone who burnt his fingers on trying to work towards a more
MVC-based version of Mantis (years ago by now) for a more generic "issue
workflow/case management engine", I can only say that Rafik's proposal
will help take away a first layer of scaring off new users: it will look
like something they'd expect to see, whether the mental model is clear
or not.
So: I'll happily flip through a few more cat videos on a
(Bootstrap-based?) social platform while you figure out how to shave off
a few KBs from Mantis and fix some tabs/spaces?
...
My 2 cents and 0 bits: release 1.3, then merge Rafik's stuff and/or
Paul's Db stuff, and release as 1.4, 2.0, 3.x, I don't care, but get
agile: release early, release often. Test things, break things, fix it.
The process is stuck in the 20th century. The visual interface is just
an expression of that.
~~Rolf.
------------------------------------------------------------------------------
Post by Rolf Kleef
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
Robert Munteanu
2014-08-26 08:50:57 UTC
Permalink
Post by Victor Boctor
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and has published the pull request to get code feedback. Let’s be pragmatic and go through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3 branch is created.
+1, this is my understanding as well.

Robert
--
http://robert.muntea.nu/
Roland Becker
2014-08-26 12:38:42 UTC
Permalink
Post by Robert Munteanu
Post by Victor Boctor
I can keep going, but I think you get where I’m heading.  My understand is
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and has
published the pull request to get code feedback.  Let’s be pragmatic and go
through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3 branch
is created.
+1, this is my understanding as well.
Robert
- Once pull request is ready it will be committed to master after 1.3 branch is created.
+1 if 1.3 branch is not created before 1.3.0 (or maybe even better 1.3.1) has
been released.

Roland
Rafik Robeal
2014-08-27 03:55:59 UTC
Permalink
Hi All,

Thanks Avetis, Alain & Rolf for sharing your feedback and for your support to this Modern UI effort.

As many of you pointed out, the pull request with the extra spaces is not easy to review. I managed to remove almost all spaces that I am aware of. Now, you can have a better feel of the changes. I cannot claim that it is 100% clean; so if you see any file that needs my attention, please drop me a line and I will take care of it.

With such a great support from the core team and the community, I am more committed than ever to work through all the issues you raise and drive this to be part of Mantis 2.0.

All the best,
Rafik


On Aug 26, 2014, at 5:38 AM, Roland Becker <***@atrol.de<mailto:***@atrol.de>> wrote:

Robert Munteanu <***@gmail.com<mailto:***@gmail.com>> hat am 26. August 2014 um 10:50
geschrieben:


On Tue, Aug 26, 2014 at 9:26 AM, Victor Boctor <***@gmail.com<mailto:***@gmail.com>> wrote:


I can keep going, but I think you get where I’m heading. My understand is
the following:

- Damien, Robert, Roland and I are all in favor of the change.

- We got several good praises from others on the DL.

- Rafik has applied all feedback we gave him earlier on the UI, and has
published the pull request to get code feedback. Let’s be pragmatic and go
through this process to deliver this to our users.

- Once pull request is ready it will be committed to master after 1.3 branch
is created.


+1, this is my understanding as well.

Robert


- Once pull request is ready it will be committed to master after 1.3 branch
is created.
+1 if 1.3 branch is not created before 1.3.0 (or maybe even better 1.3.1) has
been released.

Roland
Roland Becker
2014-08-27 07:05:05 UTC
Permalink
Thanks Rafik for the cleanup,

but I would like to repeat what I wrote as a comment to the PR about a week ago:

"I am a bit concerned as the modern-ui-2 branch is 41 commits behind
mantisbt:master at
the moment.
Furthermore there are some open PR's mostly from grangeway where we voted +1.
Not sure, but merging the branch might become even harder after those commits."

Roland
Post by Rafik Robeal
Hi All,
Thanks Avetis, Alain & Rolf for sharing your feedback and for your support to
this Modern UI effort.
As many of you pointed out,  the pull request with the extra spaces is not
easy to review. I managed to remove almost all spaces that I am aware of. Now,
you can have a better feel of the changes. I cannot claim that it is 100%
clean; so if you see any file that needs my attention, please drop me a line
and I will take care of it.
With such a great  support from the core team and the community, I am more
committed than ever to work through all the issues you raise and drive this to
be part of Mantis 2.0.
All the best,
Rafik
On Aug 26, 2014, at 5:38 AM, Roland Becker
hat am 26. August 2014 um 10:50
On Tue, Aug 26, 2014 at 9:26 AM, Victor Boctor
I can keep going, but I think you get where I’m heading.  My understand is
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and has
published the pull request to get code feedback.  Let’s be pragmatic and go
through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3 branch is created.
+1, this is my understanding as well.
Robert
- Once pull request is ready it will be committed to master after 1.3 branch is created.
+1 if 1.3 branch is not created before 1.3.0 (or maybe even better 1.3.1) has
been released.
Roland
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Rafik Robeal
2014-08-28 03:18:52 UTC
Permalink
Hi Roland,

I saw you comment and I noticed that differences with master while doing the cleanup.

I am planning to merge the latest changes in master and update the pull request over the next few days. I’ve done this few times already, it is time consuming but I think it is needed.

Hopefully that will address your concern.

Thanks,
Rafik

On Aug 27, 2014, at 12:05 AM, Roland Becker <***@atrol.de<mailto:***@atrol.de>> wrote:

Thanks Rafik for the cleanup,

but I would like to repeat what I wrote as a comment to the PR about a week ago:

"I am a bit concerned as the modern-ui-2 branch is 41 commits behind
mantisbt:master at
the moment.
Furthermore there are some open PR's mostly from grangeway where we voted +1.
Not sure, but merging the branch might become even harder after those commits."

Roland


Rafik Robeal <***@mantishub.net<mailto:***@mantishub.net>> hat am 27. August 2014 um 05:55
geschrieben:


Hi All,

Thanks Avetis, Alain & Rolf for sharing your feedback and for your support to
this Modern UI effort.

As many of you pointed out, the pull request with the extra spaces is not
easy to review. I managed to remove almost all spaces that I am aware of. Now,
you can have a better feel of the changes. I cannot claim that it is 100%
clean; so if you see any file that needs my attention, please drop me a line
and I will take care of it.

With such a great support from the core team and the community, I am more
committed than ever to work through all the issues you raise and drive this to
be part of Mantis 2.0.

All the best,
Rafik


On Aug 26, 2014, at 5:38 AM, Roland Becker
<***@atrol.de<mailto:***@atrol.de><mailto:***@atrol.de>> wrote:

Robert Munteanu <***@gmail.com<mailto:***@gmail.com><mailto:***@gmail.com>>
hat am 26. August 2014 um 10:50
geschrieben:


On Tue, Aug 26, 2014 at 9:26 AM, Victor Boctor
<***@gmail.com<mailto:***@gmail.com><mailto:***@gmail.com>> wrote:


I can keep going, but I think you get where I’m heading. My understand is
the following:

- Damien, Robert, Roland and I are all in favor of the change.

- We got several good praises from others on the DL.

- Rafik has applied all feedback we gave him earlier on the UI, and has
published the pull request to get code feedback. Let’s be pragmatic and go
through this process to deliver this to our users.

- Once pull request is ready it will be committed to master after 1.3 branch
is created.


+1, this is my understanding as well.

Robert


- Once pull request is ready it will be committed to master after 1.3 branch
is created.
+1 if 1.3 branch is not created before 1.3.0 (or maybe even better 1.3.1) has
been released.

Roland
Roland Becker
2014-08-28 08:04:35 UTC
Permalink
Victor,
maybe you can have a look at the other open PR's where we voted +1 and merge
them to master if they are ok for you.
If not, there might be another round of time consuming tasks for Rafik.
- Squash all your changes into a new branch, then try merging with that.  That
will remove the spacing issue.  I wonder if having the early commits with
these changes would cause more conflicts compared to the squashed changes
which reverted these spaces manually.
- Try merging to the current branch as is.
The result of this experiment will help guide the approach that we should use
when getting this into master.  The goal is to simplify the process of merging
between 1.3 and 2.0 as much as possible.
On Aug 27, 2014, at 8:18 PM, Rafik Robeal
Hi Roland,
I saw you comment and I noticed that differences with master while doing the cleanup.
I am planning to merge the latest changes in master and update the pull
request over the next few days. I’ve done this few times already, it is time
consuming but I think it is needed.
Hopefully that will address your concern.
Thanks,
Rafik
On Aug 27, 2014, at 12:05 AM, Roland Becker
Thanks Rafik for the cleanup,
"I am a bit concerned as the modern-ui-2 branch is 41 commits behind
mantisbt:master at
the moment.
Furthermore there are some open PR's mostly from grangeway where we voted +1.
Not sure, but merging the branch might become even harder after those commits."
Roland
August 2014 um 05:55
Hi All,
Thanks Avetis, Alain & Rolf for sharing your feedback and for your support to
this Modern UI effort.
As many of you pointed out,  the pull request with the extra spaces is not
easy to review. I managed to remove almost all spaces that I am aware of. Now,
you can have a better feel of the changes. I cannot claim that it is 100%
clean; so if you see any file that needs my attention, please drop me a line
and I will take care of it.
With such a great  support from the core team and the community, I am more
committed than ever to work through all the issues you raise and drive this to
be part of Mantis 2.0.
All the best,
Rafik
On Aug 26, 2014, at 5:38 AM, Roland Becker
Robert Munteanu
hat am 26. August 2014 um 10:50
On Tue, Aug 26, 2014 at 9:26 AM, Victor Boctor
I can keep going, but I think you get where I’m heading.  My understand is
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and has
published the pull request to get code feedback.  Let’s be pragmatic and go
through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3 branch is created.
+1, this is my understanding as well.
Robert
- Once pull request is ready it will be committed to master after 1.3 branch is created.
+1 if 1.3 branch is not created before 1.3.0 (or maybe even better 1.3.1) has
been released.
Roland
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Damien Regad
2014-08-28 08:56:23 UTC
Permalink
- Squash all your changes into a new branch, then try merging with that. That
will remove the spacing issue. I wonder if having the early commits with
these changes would cause more conflicts compared to the squashed changes
which reverted these spaces manually.
Victor Boctor
2014-08-29 16:34:57 UTC
Permalink
@dregard is probably right. I think rebase will be harder, but merge
shouldn't. I also prefer not squashing the changes. So normal merge is
the plan.

@atrol I've reviewed a couple of pull requests that I was missing.
- Squash all your changes into a new branch, then try merging with
that. That
will remove the spacing issue. I wonder if having the early commits
with
these changes would cause more conflicts compared to the squashed
changes
which reverted these spaces manually.
P Richards
2014-08-30 22:34:02 UTC
Permalink
Guys,

Seriously - get a PR generated that doesn't include 10,000 lines of whitespace (4space vs tab changes) in the first commit.

IF you want me to do the leg work on that, fine - I Will - I have a **chunk** of spare time atm.

If you want to not squash the history of the branch fine, but the white space in the first commit needs to go.

My normal approach to reviewing changes is to review each diff - as that's what we end up with at the end. I really don't mind querying the whitespace changes in the first 10,000 line diff but it might get spammy really quickly.

I'd rather see a *clean set of patches* then the PR being updated every time master changes.

At the moment, given their seem to be some changes that go against what we've tried to do in 1.3 up until now, a few bugs and a few thousand lines of whitespace changes, and it's a first commit from someone that's not coded on mantis before, it's going to be quicker to review and evaluate if it's actually clean.

I know I'm not our best expert on GIT, but it must be making life harder to maintain by having tab<>spaces differences in the first commit...

Paul






-----Original Message-----
From: Roland Becker [mailto:***@atrol.de]
Sent: 28 August 2014 09:05
To: Rafik Robeal; Victor Boctor
Cc: MantisBT Dev Mailing List
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI

Victor,
maybe you can have a look at the other open PR's where we voted +1 and merge them to master if they are ok for you.
If not, there might be another round of time consuming tasks for Rafik.
- Squash all your changes into a new branch, then try merging with
that. That will remove the spacing issue. I wonder if having the
early commits with these changes would cause more conflicts compared
to the squashed changes which reverted these spaces manually.
- Try merging to the current branch as is.
The result of this experiment will help guide the approach that we
should use when getting this into master. The goal is to simplify the
process of merging between 1.3 and 2.0 as much as possible.
On Aug 27, 2014, at 8:18 PM, Rafik Robeal
Hi Roland,
I saw you comment and I noticed that differences with master while doing the cleanup.
I am planning to merge the latest changes in master and update the
pull request over the next few days. I’ve done this few times already,
it is time consuming but I think it is needed.
Hopefully that will address your concern.
Thanks,
Rafik
On Aug 27, 2014, at 12:05 AM, Roland Becker
Thanks Rafik for the cleanup,
but I would like to repeat what I wrote as a comment to the PR about a
week
"I am a bit concerned as the modern-ui-2 branch is 41 commits behind
mantisbt:master at the moment.
Furthermore there are some open PR's mostly from grangeway where we voted +1.
Not sure, but merging the branch might become even harder after those commits."
Roland
August 2014 um 05:55
Hi All,
Thanks Avetis, Alain & Rolf for sharing your feedback and for your
support to this Modern UI effort.
As many of you pointed out, the pull request with the extra spaces is
not easy to review. I managed to remove almost all spaces that I am
aware of. Now, you can have a better feel of the changes. I cannot
claim that it is 100% clean; so if you see any file that needs my
attention, please drop me a line and I will take care of it.
With such a great support from the core team and the community, I am
more committed than ever to work through all the issues you raise and
drive this to be part of Mantis 2.0.
All the best,
Rafik
On Aug 26, 2014, at 5:38 AM, Roland Becker
Robert Munteanu
hat am 26. August 2014 um 10:50
On Tue, Aug 26, 2014 at 9:26 AM, Victor Boctor
I can keep going, but I think you get where I’m heading. My
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and
has published the pull request to get code feedback. Let’s be
pragmatic and go through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3 branch is created.
+1, this is my understanding as well.
Robert
- Once pull request is ready it will be committed to master after 1.3 branch is created.
+1 if 1.3 branch is not created before 1.3.0 (or maybe even better
+1.3.1) has
been released.
Roland
----------------------------------------------------------------------
--------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Victor Boctor
2014-08-17 23:25:11 UTC
Permalink
Hi Alain,
Post by P Richards
But for sure, the answer you will get from the end users (customers) will always be "the sooner the better" ;-)
Thanks Alain for the feedback. It is great to see the positive feedback and validation that our users would appreciate this as soon as possible. We will have the discussion and determine the v1.3 vs. v2.0. The goal is to balance not delaying v1.3 vs. going through two length stablization cycles. Stay tuned. We will do our best to deliver this sooner to users either way.
Post by P Richards
Hello Rafik,
As a regular user of mantisbt and a follower of the discussions of the mailing list, and considering the fact that the 1.3, which was supposed to be released 01.2014, is still not today, I would personally recommend to release the feature with the 1.3. (Who knows when the 2.0 will come out at the end...?)
That being said, I also know that it's a bit painful to add new features in a roadmap at the very final steps of a software release (=> tests, impacts, more delay, etc.). So... I don't know what the dev team would think about it.
But for sure, the answer you will get from the end users (customers) will always be "the sooner the better" ;-)
AlainD.
Hello Everyone,
For people who don't know me, my name is Rafik Robeal and I am working on building MantisHub.
I've experienced MantisBT first hand working with many users who love and admire MantisBT. I can simply say that MantisBT has proven itself to be powerful feature-rich bug tracker. One thing remains though, its UI is behind the times. To establish MantisBT as the best modern open source bug tracker for many years to come, a modern UI is needed.
Over the past few months I've been working on building a modern UI for MantisBT. The main drivers for this effort are: (1) a request from MantisBT core team back in January when I delivered the mantisbt.org modern website that you see live today, (2) a loud and clear feedback from MantisBT/MantisHub customers who publicly and privately spoke against the current UI , (3) a personal desire to contribute to MantisBT open source effort with a lasting positive impact on both end users satisfaction and product adoption.
Enough introduction ... what is this all about? In four words: freaking awesome user interface
Before reading any further, fire up your browser and go to: http://mantishub.com/modern/index.php
You are accessing the preview version on MantisBT Modern UI. Use username: reporter & password: demo
Integrate with Bootstrap v3.2 framework as the foundation for all Mantis UI elements.
Use Fontawesome for vector based icons.
Redesign Layout & Navigation
Update all pages with the new style, look and feel
Improved experience on mobile devices
The goal is to share the code and get feedback on it. We need to decide on when this code can be merged specially in relation to the 1.3 release. Decide whether it is 1.3 or 2.0 and figuring out when the 1.3 branch will be created so that the pull request can eventually be integrated.
I'd love to hear from everyone and address any potential issues you see with the new design or code.
Thanks,
Rafik Robeal
------------------------------------------------------------------------------
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
------------------------------------------------------------------------------
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
P Richards
2014-08-17 23:35:29 UTC
Permalink
Victor,



We need to decide if this is the approach we want to take first - so far,
we've not even had a discussion on whether to move to using bootstrap in
Mantis.



In any case, we all know that we need to modernize the UI, but there's no
point rushing something in if it's not the right solution. Especially given
that we've previously said we would look at updating the UI in 2.x as a
team.



At the moment, whilst I like some aspects of the design, I'm not sure this
is the right solution.



Paul



From: Victor Boctor [mailto:***@gmail.com]
Sent: 18 August 2014 00:25
To: MantisBT Dev Mailing List
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI



Hi Alain,



But for sure, the answer you will get from the end users (customers) will
always be "the sooner the better" ;-)



Thanks Alain for the feedback. It is great to see the positive feedback and
validation that our users would appreciate this as soon as possible. We
will have the discussion and determine the v1.3 vs. v2.0. The goal is to
balance not delaying v1.3 vs. going through two length stablization cycles.
Stay tuned. We will do our best to deliver this sooner to users either way.



On Aug 17, 2014, at 12:27 AM, Alain D'EURVEILHER
<***@gmail.com <mailto:***@gmail.com> > wrote:





Hello Rafik,



As a regular user of mantisbt and a follower of the discussions of the
mailing list, and considering the fact that the 1.3, which was supposed to
be released 01.2014, is still not today, I would personally recommend to
release the feature with the 1.3. (Who knows when the 2.0 will come out at
the end...?)



That being said, I also know that it's a bit painful to add new features in
a roadmap at the very final steps of a software release (=> tests, impacts,
more delay, etc.). So... I don't know what the dev team would think about
it.

But for sure, the answer you will get from the end users (customers) will
always be "the sooner the better" ;-)



AlainD.



On Sun, Aug 17, 2014 at 5:00 AM, Rafik Robeal <***@mantishub.net
<mailto:***@mantishub.net> > wrote:

Hello Everyone,

For people who don't know me, my name is Rafik Robeal and I am working on
building MantisHub <http://www.mantishub.com/> .

I've experienced MantisBT first hand working with many users who love and
admire MantisBT. I can simply say that MantisBT has proven itself to be
powerful feature-rich bug tracker. One thing remains though, its UI is
behind the times. To establish MantisBT as the best modern open source bug
tracker for many years to come, a modern UI is needed.

Over the past few months I've been working on building a modern UI for
MantisBT. The main drivers for this effort are: (1) a request from MantisBT
core team back in January when I delivered the mantisbt.org
<http://mantisbt.org/> modern website that you see live today, (2) a loud
and clear feedback from MantisBT/MantisHub <http://www.mantishub.com/>
customers who publicly and privately spoke against the current UI , (3) a
personal desire to contribute to MantisBT open source effort with a lasting
positive impact on both end users satisfaction and product adoption.

Enough introduction ... what is this all about? In four words: freaking
awesome user interface

Before reading any further, fire up your browser and go to:
http://mantishub.com/modern/index.php
You are accessing the preview version on MantisBT Modern UI. Use username:
reporter & password: demo

I've already submitted the pull request
<https://github.com/mantisbt/mantisbt/pull/272> for this work which
includes:

* Integrate with Bootstrap v3.2 <http://getbootstrap.com/> framework
as the foundation for all Mantis UI elements.
* Use Fontawesome <http://fortawesome.github.io/Font-Awesome/> for
vector based icons.
* Redesign Layout & Navigation
* Update all pages with the new style, look and feel
* Improved experience on mobile devices

The goal is to share the code and get feedback on it. We need to decide on
when this code can be merged specially in relation to the 1.3 release.
Decide whether it is 1.3 or 2.0 and figuring out when the 1.3 branch will be
created so that the pull request can eventually be integrated.

I'd love to hear from everyone and address any potential issues you see with
the new design or code.

Thanks,
Rafik Robeal


----------------------------------------------------------------------------
--

_______________________________________________
mantisbt-dev mailing list
mantisbt-***@lists.sourceforge.net
<mailto:mantisbt-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.

----------------------------------------------------------------------------
--
P Richards
2014-08-17 09:23:14 UTC
Permalink
Rafiq,



As i've seen on the PR, and when you originally said you were looking at
this a month ago, and asked you to mail the Mailing List, we need to have a
discussion about the design and the approach.



You've made a 'decision' to use bootstrap - up until now, we've not used any
CSS framework. I know when i've previously looked at data table's, many
months ago, I had been looking at making use of jquery's theme roller.
Whilst it might make sense to use bootstrap, we have plugin authors using
Mantis etc, there's other frameworks available etc, so it warrants a
discussion with the development community FIRST.



We've had design requests and theming requests from users before - some of
them in the past have been quite good, some not so good, and have never
actually implemented a change.



One of the main requests from users in the past, is that users want slightly
different thing's - i.e. people want to be able to customise the look and
feel of mantis in different ways.



In it's current form, this PR isn't suitable for this - For example - whilst
it's nicer, the reason I use mantis is due to the way it can be integrated
into other systems - so the side bar is a no go.



For most end users, Mantis consists of 4 pages:



1) My View Page

2) View Issues Page

3) Report Issues Page

4) View Issue Page



I think we can do a better job then the current theme if we focus on looking
at the design and the ability to customise these 4 pages.



For example, in a modern system, the "My View" page I would have expect to
be a ajax dashboard.



I sent an email a few weeks ago now for feedback on using DataTables to
ajaxify the View Issues list.



For 3/4, the requests tend to be to allow fields to be re-ordered, turned
on/off.



At the moment, the work doesn't help any of these requests from users.



Whilst I did try to have a look at the Pull Request, there seems to be a
number of Whitespace changes, and non-theme/design changes that make it
impossible to review the patches.



For example -
https://github.com/syncguru/mantisbt/commit/b795b259463deca6e15806369a070c3b
2fa45322 looks to change whitespace incorrectly in account_delete.php on the
first line. I assume you've used spaces instead of tabs of vice versa. Those
changes need to not be included in the branch before it's even possible to
look at.





Back in January, we agreed as a Team to get 1.3 shipped, and then look at UI
and email notifications changes. Victor knows I've got some work on
templating emails and pages within Mantis from back then, which I said I'd
get a PR up for once the Database changes had been done - which we agreed as
a team to do immediately after 1.3. So until we've done this, compared the
two approaches and decide which route we want to go, i'm strongly against
this getting merged.



In addition, in the PR for theme changes you seem to have stuff that could
be implemented now as a separate PR:



For example, Jquery library update - this shouldn't be part of the
discussion on themes/layout as it's a library change



Some HTTP security header changes to replace a deprecated http header -
again - this should be a separate PR, as it looks like something that we'd
require now.







From: Rafik Robeal [mailto:***@mantishub.net]
Sent: 17 August 2014 04:00
To: mantisbt-***@lists.sourceforge.net
Subject: [mantisbt-dev] Introducing MantisBT Modern UI



Hello Everyone,

For people who don't know me, my name is Rafik Robeal and I am working on
building MantisHub <http://www.mantishub.com> .

I've experienced MantisBT first hand working with many users who love and
admire MantisBT. I can simply say that MantisBT has proven itself to be
powerful feature-rich bug tracker. One thing remains though, its UI is
behind the times. To establish MantisBT as the best modern open source bug
tracker for many years to come, a modern UI is needed.

Over the past few months I've been working on building a modern UI for
MantisBT. The main drivers for this effort are: (1) a request from MantisBT
core team back in January when I delivered the mantisbt.org
<http://mantisbt.org> modern website that you see live today, (2) a loud
and clear feedback from MantisBT/MantisHub <http://www.mantishub.com>
customers who publicly and privately spoke against the current UI , (3) a
personal desire to contribute to MantisBT open source effort with a lasting
positive impact on both end users satisfaction and product adoption.

Enough introduction ... what is this all about? In four words: freaking
awesome user interface

Before reading any further, fire up your browser and go to:
http://mantishub.com/modern/index.php
You are accessing the preview version on MantisBT Modern UI. Use username:
reporter & password: demo

I've already submitted the pull request
<https://github.com/mantisbt/mantisbt/pull/272> for this work which
includes:

* Integrate with Bootstrap v3.2 <http://getbootstrap.com/> framework
as the foundation for all Mantis UI elements.
* Use Fontawesome <http://fortawesome.github.io/Font-Awesome/> for
vector based icons.
* Redesign Layout & Navigation
* Update all pages with the new style, look and feel
* Improved experience on mobile devices

The goal is to share the code and get feedback on it. We need to decide on
when this code can be merged specially in relation to the 1.3 release.
Decide whether it is 1.3 or 2.0 and figuring out when the 1.3 branch will be
created so that the pull request can eventually be integrated.

I'd love to hear from everyone and address any potential issues you see with
the new design or code.

Thanks,
Rafik Robeal
Victor Boctor
2014-08-18 00:00:28 UTC
Permalink
Paul,
Post by P Richards
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking at this a month ago, and asked you to mail the Mailing List, we need to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview was to publish the code and the discussion to the DL, which he just did. Your words were that even though the decision to use bootstrap is likely to be a short discussion, it is worth having anything.
Post by P Richards
You’ve made a ‘decision’ to use bootstrap - up until now, we’ve not used any CSS framework. I know when i’ve previously looked at data table’s, many months ago, I had been looking at making use of jquery’s theme roller. Whilst it might make sense to use bootstrap, we have plugin authors using Mantis etc, there’s other frameworks available etc, so it warrants a discussion with the development community FIRST.
[Victor] The bootstrap decision really started when the website was developed. At this time, bootstrap was used and the request by the team from the Rafik was to do the same modernization to MantisBT. Hence, he started doing the work. As for plugins, they are typically easy to adapt to whatever framework MantisBT is using.
Post by P Richards
We’ve had design requests and theming requests from users before - some of them in the past have been quite good, some not so good, and have never actually implemented a change.
[Victor] Agreed. However, none of them really spent the energy to do a full transformation of MantisBT and go through the process of contributing it. In some cases, we invited the potential contributors to do so and they didn’t get to it. In other scenarios, we may have not done enough effort to make such contributors feel welcome to do such change and get the support they need to be successful.
Post by P Richards
One of the main requests from users in the past, is that users want slightly different thing’s - i.e. people want to be able to customise the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI. In my opinion, a lot of the users that heavilty themed Mantis in the past were motivated to improve the look. However, what we really need to focus on is the ability for users to continue to be able to extend MantisBT via plugins. If we get into theming, we can support color shade (e.g. green template, blue template, etc) rather than complete customization. Complete customization adds little value and can significantly increase complexity of code and test matrix. I believe users evaluate MantisBT evalute it based on functionalty, look, and extensions to fill gaps that we don’t have in core or integrate their own custom functionality.
Post by P Richards
In it’s current form, this PR isn’t suitable for this - For example - whilst it’s nicer, the reason I use mantis is due to the way it can be integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other systems and why the side bar blocks that?
Post by P Richards
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal is to improve the look and use a more modern code styling. Once this is in, we can follow up by enriching specific page to make it use ajax. Good examples are “My View” and filter page. Once Rafik’s change is checked in, we can all collaborate on enriching specific pages as necessary.
Post by P Richards
For 3/4, the requests tend to be to allow fields to be re-ordered, turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a foundation work for these features. I don’t see how there is a conflict between these features and styling of pages.
Post by P Richards
Whilst I did try to have a look at the Pull Request, there seems to be a number of Whitespace changes, and non-theme/design changes that make it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that cause more changes than actually needed. Maybe Rafik can explore of this issue can be fixed with reasonable effort.
Post by P Richards
Back in January, we agreed as a Team to get 1.3 shipped, and then look at UI and email notifications changes. Victor knows I’ve got some work on templating emails and pages within Mantis from back then, which I said I’d get a PR up for once the Database changes had been done - which we agreed as a team to do immediately after 1.3. So until we’ve done this, compared the two approaches and decide which route we want to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some change without discussion with the team. At that point I had discussed email templating (not UI tempting) and proposed an approach, some previews, and you complained and stopped the work. I’ve asked you then to share your code / approach and you haven’t. You just killed the momentum and said that you will publish your code by end of January then after 1.3. At that point we also agreed that code that is not published doesn’t exist and can’t be used to block other work. Rafik has shared a preview of this work with the team 1-2 month ago and everyone except you on the core team was excited and gave him UI level feedback which he addressed. So, I expect this code to be merged. The discussion is when exactly it is going to be merged based on the 1.3 plan.

Thanks,
-Victor
Robert Munteanu
2014-08-19 12:48:54 UTC
Permalink
Hi Paul,
Post by P Richards
Rafiq,
In it’s current form, this PR isn’t suitable for this - For example - whilst
it’s nicer, the reason I use mantis is due to the way it can be integrated
into other systems - so the side bar is a no go.
Um...

div#sidebar {
display:none !important;;
}

And out goes the sidebar. I actually think that by using Bootstrap and
and properly assigning id and class names Mantis will be easier to
style, not harder.
Post by P Richards
I think we can do a better job
Sorry, but we haven't done that for a _lot_ of time. IIRC this is the
basic MantisBT 0.x look. When someone else wants to do a better job,
fine. But perfect is the enemy of good. No sense rejecting a valuable
contribution becuase 'we can do better'.
Post by P Richards
For example, in a modern system, the “My View” page I would have expect to
be a ajax dashboard.
Would it be nice? Yes. Does it have to happen with this submission? No.
Post by P Richards
I sent an email a few weeks ago now for feedback on using DataTables to
ajaxify the View Issues list.
(and I replied ... )
Post by P Richards
For 3/4, the requests tend to be to allow fields to be re-ordered, turned
on/off.
At the moment, the work doesn’t help any of these requests from users
Sorry, I don't know which requests and which users. But what I do know
is that we lag behind a lot in terms of looks, and it shows.
.
Post by P Richards
Whilst I did try to have a look at the Pull Request, there seems to be a
number of Whitespace changes, and non-theme/design changes that make it
impossible to review the patches.
We can of course iterate on the PR. It's a steep learning curve and
we've all been through that.
Post by P Richards
For example -
https://github.com/syncguru/mantisbt/commit/b795b259463deca6e15806369a070c3b2fa45322
looks to change whitespace incorrectly in account_delete.php on the first
line. I assume you’ve used spaces instead of tabs of vice versa. Those
changes need to not be included in the branch before it’s even possible to
look at.
Back in January, we agreed as a Team to get 1.3 shipped, and then look at UI
and email notifications changes. Victor knows I’ve got some work on
templating emails and pages within Mantis from back then, which I said I’d
get a PR up for once the Database changes had been done - which we agreed as
a team to do immediately after 1.3. So until we’ve done this, compared the
two approaches and decide which route we want to go, i’m strongly against
this getting merged.
In addition, in the PR for theme changes you seem to have stuff that could
For example, Jquery library update - this shouldn’t be part of the
discussion on themes/layout as it’s a library change
Some HTTP security header changes to replace a deprecated http header -
again - this should be a separate PR, as it looks like something that we’d
require now.
Sent: 17 August 2014 04:00
Subject: [mantisbt-dev] Introducing MantisBT Modern UI
Hello Everyone,
For people who don't know me, my name is Rafik Robeal and I am working on
building MantisHub.
I've experienced MantisBT first hand working with many users who love and
admire MantisBT. I can simply say that MantisBT has proven itself to be
powerful feature-rich bug tracker. One thing remains though, its UI is
behind the times. To establish MantisBT as the best modern open source bug
tracker for many years to come, a modern UI is needed.
Over the past few months I've been working on building a modern UI for
MantisBT. The main drivers for this effort are: (1) a request from MantisBT
core team back in January when I delivered the mantisbt.org modern website
that you see live today, (2) a loud and clear feedback from
MantisBT/MantisHub customers who publicly and privately spoke against the
current UI , (3) a personal desire to contribute to MantisBT open source
effort with a lasting positive impact on both end users satisfaction and
product adoption.
Enough introduction ... what is this all about? In four words: freaking
awesome user interface
http://mantishub.com/modern/index.php
reporter & password: demo
Integrate with Bootstrap v3.2 framework as the foundation for all Mantis UI
elements.
Use Fontawesome for vector based icons.
Redesign Layout & Navigation
Update all pages with the new style, look and feel
Improved experience on mobile devices
The goal is to share the code and get feedback on it. We need to decide on
when this code can be merged specially in relation to the 1.3 release.
Decide whether it is 1.3 or 2.0 and figuring out when the 1.3 branch will be
created so that the pull request can eventually be integrated.
I'd love to hear from everyone and address any potential issues you see with
the new design or code.
Thanks,
Rafik Robeal
------------------------------------------------------------------------------
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
http://robert.muntea.nu/
Victor Boctor
2014-08-17 23:38:56 UTC
Permalink
Thanks a lot Rafik. It is a big undertaking addressing one of the weakest points for MantisBT that we have wanted to address it for a long time. I'm personally super excited. I believe this also builds a foundation on which we can build re-designed workflows and rich experiences (e.g. ajaxification of certain scenarios), native mobile support, etc.

I’ll be looking at the pull request and providing feedback there relating to the coding.
Post by Rafik Robeal
Hello Everyone,
For people who don't know me, my name is Rafik Robeal and I am working on building MantisHub.
I've experienced MantisBT first hand working with many users who love and admire MantisBT. I can simply say that MantisBT has proven itself to be powerful feature-rich bug tracker. One thing remains though, its UI is behind the times. To establish MantisBT as the best modern open source bug tracker for many years to come, a modern UI is needed.
Over the past few months I've been working on building a modern UI for MantisBT. The main drivers for this effort are: (1) a request from MantisBT core team back in January when I delivered the mantisbt.org modern website that you see live today, (2) a loud and clear feedback from MantisBT/MantisHub customers who publicly and privately spoke against the current UI , (3) a personal desire to contribute to MantisBT open source effort with a lasting positive impact on both end users satisfaction and product adoption.
Enough introduction ... what is this all about? In four words: freaking awesome user interface
Before reading any further, fire up your browser and go to: http://mantishub.com/modern/index.php
You are accessing the preview version on MantisBT Modern UI. Use username: reporter & password: demo
Integrate with Bootstrap v3.2 framework as the foundation for all Mantis UI elements.
Use Fontawesome for vector based icons.
Redesign Layout & Navigation
Update all pages with the new style, look and feel
Improved experience on mobile devices
The goal is to share the code and get feedback on it. We need to decide on when this code can be merged specially in relation to the 1.3 release. Decide whether it is 1.3 or 2.0 and figuring out when the 1.3 branch will be created so that the pull request can eventually be integrated.
I'd love to hear from everyone and address any potential issues you see with the new design or code.
Thanks,
Rafik Robeal
------------------------------------------------------------------------------
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Robert Munteanu
2014-08-19 12:42:06 UTC
Permalink
Hi Rafik,
Post by Rafik Robeal
The goal is to share the code and get feedback on it. We need to decide on
when this code can be merged specially in relation to the 1.3 release.
Decide whether it is 1.3 or 2.0 and figuring out when the 1.3 branch will be
created so that the pull request can eventually be integrated.
As I've noted previously, this is fantastic! A much needed face lift
for MantisBT. Looks good, and makes me want to use it _now .

I haven't yet reviewed the PR, and I expect to have several iterations
on it. I've expressed my desire to see this in 1.3 rather than
1.4/2.0, but that's just a personal opinion. I won't be doing the
heavy lifting, so if everyone thinks later is better, I'll defer to
that.

Robert
Post by Rafik Robeal
I'd love to hear from everyone and address any potential issues you see with
the new design or code.
Thanks,
Rafik Robeal
------------------------------------------------------------------------------
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
http://robert.muntea.nu/
Avetis Avagyan
2014-08-26 10:06:34 UTC
Permalink
Dear All,

UI is the weakest part of MantisBT and this is so for long time now. IMO every development in this direction should have 'urgent' priority and be publicly released as early as possible. Being one of the plugin developers I see no problem in incorporating UI changes into the plugin(s). Maybe it will be good if one collects contact details of plugin developers (those able to run on 1.2.x) and communicates to them need to have UI changes incorporated.

With best regards,
Avetis
(MantisStats Plugin, https://www.mantisstats.org)



-------- Original message --------
From: Robert Munteanu <***@gmail.com>
Date:26/08/2014 10:50 (GMT+01:00)
To: developer discussions <mantisbt-***@lists.sourceforge.net>
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI
Post by Victor Boctor
- Damien, Robert, Roland and I are all in favor of the change.
- We got several good praises from others on the DL.
- Rafik has applied all feedback we gave him earlier on the UI, and has published the pull request to get code feedback. Let’s be pragmatic and go through this process to deliver this to our users.
- Once pull request is ready it will be committed to master after 1.3 branch is created.
+1, this is my understanding as well.

Robert
--
http://robert.muntea.nu/
Loading...