------------------------------------------------------------------------------Hello All,I am new here, and I am hoping to get my bearings and contribute a bit to the cause. Here is my first entry into the developer discussion: my first stab at a UI facelift.
The underlying code is quite different than the existing pages, as it is DIV/CSS based, and I have made some slight changes to the layout, which I have attempted to document below. The presentation is quite different than the existing, but the majority of the elements are still in the same locations.
Associated with the above PNG1. Move the User's information up and out of the way. It doesn't make sense to me to include the "My Account" and "Logout" access in the main navigation, as they serve a completely separate purpose. The main navigation should revolve around bug/project tracking needs.
2. Clear primary, and secondary navigation, with code in place to handle tertiary navigation should it be needed.
3. Where am I? There is a ton of functionality nestled away in the Mantis BT, so it can be daunting for the less tech-savvy, or those that are constantly pulled into meetings, interupted by the kids, whatever. Clearly defining where the user within the software should be a must. "a" makes it clear you are under the "Manage" tab, and "b" indicates the secondary location. In this case, it is the main landing page under the "Manage" tab.
There is a place for a logo, the legend has been incorporated into the design, but can be easily hidden if it is not required, and the "meat" of the page is very clear to the user.
What's missing?I have not yet incorporated the "project" dropdown, nor the "issue search" at this time, but I have some ideas.
Here is an HTML version, so that you can peak at the code:
I know there are some subtle changes going on in the 1.3 branch regarding the move to a CSS-friendly layout. Is there a more agressive approach to make sweeping changes for a 2.0? I saw in the recent archives that there wasn't much concern about backward compatibility for plugins. If that is the case, shouldn't a more aggressive approach be taken in order to ensure the plugin developers only need to be inconvenienced the one time, when a more robust offering is brought to light? I am probably jumping the gun a bit, so take it with a grain of salt.
Please let me know what you think of the above changes. Good, bad, indifferent.
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
mantisbt-dev mailing list