Excuse me adrian for this late answer,
Your table explanation is clear and I agree with that.
On tables managing a designer and then a precise visual improvement is
interresting and remains simple. We are in a well-defined element.
Good point that we agree!
Now on icons, the problem is wider than table since we have different
domains:
* icons on submit button can be associate only to a style
* icons on menu, a little harder than button, maybe given the
possibility to use menu name as class style
* icons on field (diplay or text) for user eye pleasure
* icons on hyperlink for user charm and reduce screen in carrying
management information (ex : mail icons with title-image that contains
email address).
For each case I wish :
* Having generic system that simplify / limit developer possibility
* Manage style icons by the theme
* Keep the concept of condensing information through icons, which is a
real user need when using lists
I suggest, if you agree to bring your vision for its proper integration
issues, to create some jira that explain for each case :
* improvements expected
* Solution used at this time on internal projects
* How I see the solution
From that we can work with own different visions
Nicolas
Le 29/04/2011 14:53, Adrian Crum a écrit :
To understand our differences a little better, it might help to set
aside the subject of icons for a moment and consider another visual
element - the HTML <table> element. I believe the way HTML tables are
handled in OFBiz represents a good balance between developers and
theme designers. If we can agree on how tables are handled, then maybe
we can apply the same concept to icons and agree on those too. If we
can't agree on how tables are handled, then... well... we will just
have to agree to disagree. ;-)
OFbiz provides a CSS class for basic <table> element layout - called
basic-table. That class provides simple positioning and spacing. The
basic-table class is intended to be "decorated" with other classes to
add other visual embellishments. A developer can add light-grid or
dark-grid CSS classes to basic-table to give it a grid. A developer
can add a hover bar to a table by adding the hover-bar CSS class to
basic-table. This CSS class decorator pattern has been in use for a
while now, and it seems to be a good approach because it gets used a lot.
The developer is free to choose which classes make the most sense for
the screen they are developing. What the developer CAN'T do is specify
what those classes look like - that is left up to the theme designer.
The CSS classes are a way for the developer to give the theme designer
hints about what a particular HTML element should look like without
being specific about its visual appearance.
The theme designer controls the positioning and spacing in
basic-table. The theme designer controls the color and line thickness
of light-grid and dark-grid. The theme designer controls the
appearance of hover-bar. Different themes might style those classes
differently, but what remains consistent across themes is that they
are all used in the same way. An HTML <table> element styled with
"basic-table light-grid" will always have a light grid - regardless of
the theme. Now, here is something interesting to think about - a theme
designer could choose not to style the grids, and eliminate table
grids altogether. There is no "law" saying that all CSS classes must
be styled. A theme that eliminates grids may or may not get used - it
depends on the user. Some users might prefer to have grids turned off
- so they would select the "gridless" theme. ***This is where the
balance between developer and theme designer comes in*** - the
developer provides a hint that a table should have grids, but the
developer doesn't force grids on the theme designer or the user.
Now let's apply the icon conversation to the HTML <table> element
example. What has been suggested is that all themes be made consistent
by hard-coding table grids in the markup. When I objected to that, it
was suggested that table grids can be enabled/disabled by a user
setting. For the sake of compromise I agreed to that, but I believe it
is unnecessary because a user could simply choose a theme that has
grids enabled or disabled.
To summarize: What I am advocating is that we treat icons the same way
as we do all other visual elements - let the theme designer have
control of their use. I see no valid reason why icons should be
treated differently. Users who want icons will choose a theme that
uses them. Users who don't want icons will choose a theme that doesn't
use them. The system we use now is flexible and it works - it doesn't
need to be changed.
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
