Christian Robottom Reis
kiko at async.com.br
Mon Dec 8 15:25:49 UTC 2003
On Mon, Dec 08, 2003 at 01:41:12PM +0100, Ludovic Dubost wrote:
> - Especially being able to have the actions in a menu bar at the top of
> a page is more similar with the usual experience non-tech users have
> with computer applications.
This is a really important point (though rather orthogonal to the CSS
issue here) -- our footer is a usability problem for most of our pages,
since the user ends up having to scroll down (many times guessing he
needs to scroll down) to [find out how to] navigate through the site.
However, I need to stay focused here if we want the initial CSS
framework to land -- when it's in, we can work on the UI improvements.
> - Changing the look to use CSS buttons not only allows to change it more
> easily but gives a 'sexy' look that is quite important to easy the
> adoption of the tool to a resisting non-tech audience..
You'll find that many people will be reluctant to rely on images for
buttons as "menu items", but that if a decent CSS structure is devised
it should be easy to add those to a site CSS file.
> - Also using a standard naming for the 'standard' and 'advanced' DIV
> allows to apply the same CSS/JS code. Creating a separate div for the
> header of each section was a way to apply a style.
> <div id="editadvtitle"><h1>Advanced</h1></div>
> <div id="editadv">
> <table>... with form elements</table>
I didn't understand your point here.
> - The footer is at the bottom of the page. The only way to get it back
> at the top is absolute positioning. So float positioning is kind of
> forbidden if you want to keep the footer at the bottom in non CSS mode.
This could be param-configurable, or we could just move the footer
content to the top of the page. Again, this is a larger UI change that
should happen later..
> - I first used <li> for each action, search query or admin menu item.
> But in fact there is a neat solution to keep the '|' as separators so
> that the no-style view looks like it does in the current footer. Like this:
I think that <li> is really the way to go for the top-level actions,
though, and we might be able to tolerate some visual changes to allow
> - I don't say that bugzilla should be delivered with many skins and
> that there should be a skin trading mecanism.. But it could be a way to
> more easily apply other peoples work on your bugzilla installation
> without patches..
> I hope this helps in creating a CSS aware bugzilla which would allow to
> create different looks for bugzilla without having to patch templates..
Well, I think template customization is still going to be an integral
part of localizing Bugzilla to an organization. We can:
- use CSS to help people do a popular subset of possible changes to
- separate usually-customized content into separate header files to
avoid problems when updatings,
- improve Bugzilla's UI layout to avoid the need to local
customizations and improve OOTB usability,
but having templates allows us to shift the finer points of UI
discussion to localized templates. It helps keep us productive :-)
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331
More information about the developers