The application developer designs the application, not the graphic
artist. The graphic artist styles the application, he doesn't design it.
For example, I am a developer designing a screen. The screen requires
two sets of links. The links in set A all share something in common, and
the links in set B all share something in common, but sets A and B have
nothing in common. How do I indicate that to the user? I will use
different styles for the two sets of links.
What you're saying is that I am not allowed to make that decision - that
is the theme designer's decision. I don't agree with that view. The
theme designer is free to style set A and set B any way they want, but
it is not their job to determine if set A or set B exist in the application.
As an application developer, I want the option to use different styles
to provide different visual cues to the user.
I agree that some of the styles have been named poorly. We should rename
them if that is the case, but we shouldn't get rid of them.
-Adrian
On 1/29/2011 2:35 PM, Bruno Busco wrote:
Adrian,
I am sorry to put again this on the table. I know we have already discussed
about but I think that you are trying to better explain over and over a
wrong concept.
You can see how it is wrong when you say "In the original visual theme, the
tab-bar decorator was used for the sub-menu at the top of the main content
area, button-style-1 was used for intra-app links, and button-style-2 was
used for inter-app links."
It cannot be a visual theme to use a decorator for a sub-menu,
button-style-1 for intra-app links etc. It is the application itself. So why
the application should decide which style should be used for a sub-menu? It
should only identify the sub-menu as a sub-menu and then the visual theme
should decide to decorate the sub-menu with a specific visual aspect.
If the application developer A is free to use button-style-1 for intra-app
links and button-style-2 for inter-app links then application developer B
would be free to use button-style-1, let me say, for backoffice links and
button-style-2 for ecommerce web site links.
Then how could a visual theme designer create a graphics that somehow helps
the user to distinguish between links?
He could not do anything, he will understand that if the two decoration
classes have not the same CSS the links will appear different without a
clear reason and so we will have that the two classes will be, in a proper
designed theme, with the same CSS.
We are moving now towards having more visual themes hosted separately from
the main trunk. If we do not clear away those ambiguity we will never have a
solid base in the main trunk to let external visual themes to rely on.
So my suggestion is to change all style names that do not describe element
functionality but visual aspect.
Of course I get your suggestion to spend some time removing box* styles but
they should not be the only one to leave.
-Bruno
2011/1/29 Adrian Crum<adrian.c...@sandglass-software.com>
I'm sure we discussed this just a few weeks ago, but I will go over it
again...
The button-style-1 and button-style-2 CSS classes are button-bar class
decorators. The button-bar class has other decorators too - tab-bar and
tool-bar. Altogether, there are four button-bar decorators. The button-bar
decorators were not intended to be used alone to style links, but they have
been used that way recently and I have been fixing those instances as I come
across them.
Setting up the CSS classes this way gives the graphic artist some
flexibility in styling the buttons. Attributes that all button bars have in
common (spacing, positioning, orientation) can be applied to the button-bar
class, and then the various decorators can have attributes that make them
unique.
It is up to the application developer to decide what the various button-bar
decorators represent. The decorators have no inherent purpose - they simply
provide the developer with some choices. In the original visual theme, the
tab-bar decorator was used for the sub-menu at the top of the main content
area, button-style-1 was used for intra-app links, and button-style-2 was
used for inter-app links.
I see no reason to remove any of the button-bar decorators. The decorators
give the developer and graphic artist a palette of choices. That same
concept gives us a choice of table header styles, table grid styles, etc.
If there is an interest in removing unnecessary styles, then (in my
opinion) that effort should be invested in removing the deprecated CSS
styles. You can find them listed at the bottom of the Flat Grey maincss.css
file. Removing the box* styles would be a good place to start.
-Adrian
On 1/29/2011 6:46 AM, Bruno Busco wrote:
Hi,
again on this topic.
I have seen that in the new Flat grey theme the button-style-1 and
button-style-2 are rendered in the same way.
I agree on this and was going to do the same on the Tomahawk theme.
While doing this I asked myself if it does make sense to keep those two
styles.
They seems to be intended to be used to differentiate between intra-app
and
inter-app links.
But why an user should be aware of the matter that a link is an intra-app
or
inter-app ?
Shouldn't it be completely transparent to him?
I think that keeping these styles is only confusing and I would like to
remove it.
Moreover we should go toward style names that describe element functions
and
not their apparence.
For example the "create", "delete", "search", "refresh" button styles have
not been defined as "button-with-plus", "button-with-cross",
"button-with-maglens" etc.
The new Demo page layout is a great tool to test themes.
It could also work as a "style dictionary" having all allowed styles
present
on the page and specifiyng that only styles present in this page should be
used in the rest of the code.
Does anybody see any issue if we get rid of the button-style-1 and
button-style-2 styles?
Thank you,
Bruno
