Could we remove button-style-1 and button-style-2 ?

[Bruno Busco]

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

[Adrian Crum-3]

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
>

[Adrian Crum-3]

One more thing that might help clear up any confusion...

Some of the CSS class names were not the best choices (hindsight is
20-20). A more accurate name for the button-bar class would be
link-group (or control-group), and then the button-style classes could
be named group-style-1 and group-style-2. I'm not suggesting that we
change the names, I'm just saying if the class names had been different
there might be less confusion over what the classes are used for.

I was the author of those classes, so I'm pointing the finger at myself.
Giving things meaningful names has always been an enigma for me.

-Adrian

On 1/29/2011 8:34 AM, Adrian Crum wrote:

> 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
>>

[Bruno Busco]

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 <[hidden email]>

> 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
>>
>>

[Adrian Crum-3]

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<[hidden email]>
>
>> 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
>>>
>>>

[Bruno Busco]

Adrian I think we are almost on the same page, please read inline.

2011/1/30 Adrian Crum <[hidden email]>

> The application developer designs the application, not the graphic artist.
> The graphic artist styles the application, he doesn't design it.
>

100% agreed


>
> 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.
>

IMO when a developer in this situation he should think: "What is the
functions of the links in set A and i set B?. Are they similar or equivalent
to functions that already exist in the rest of the applications?"
For the set where the answer is yes than the link style should be the one
used for that function in the other application.
For the set where the answer is no than a new style should be defined with a
name that describes the new function.


> 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 explained above the developer is absolutely free to define new functional
styles but FUNCTIONAL because, as you say, he is responsible for functions
offered to the user, not of how they appear. So, for example, he is allowed
to style a submit button with a "confirm" or a "cancel" style but he should
never be allowed to attach a "smallSubmit" or a "largeSubmit" style to it.
If the confirm buttons should appear smaller or greater than the cansel
buttons is something that the graphic artist should decide.


> As an application developer, I want the option to use different styles to
> provide different visual cues to the user.
>

You will have this option as explained. The graphic artist will help you to
have it consistent in all the applications.


>
> 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.
>

The process can be gradual. I am trying to have a common agreement first so
that we will not fight for every style changed or removed. So moving on, we
should agree on the rationale behind it than make a list of styles to be
removed or changed toghether with new functional names to be used all over
the application and then gradually proceed in inplementing.

Thank you for you help on this.
-Bruno

> -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<[hidden email]>
>>
>>  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
>>>>
>>>>
>>>>

[Adrian Crum-3]

On 1/29/2011 11:59 PM, Bruno Busco wrote:

> Adrian I think we are almost on the same page, please read inline.
>
> 2011/1/30 Adrian Crum<[hidden email]>
>
>> The application developer designs the application, not the graphic artist.
>> The graphic artist styles the application, he doesn't design it.
>>
> 100% agreed
>
>
>> 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.
>>
> IMO when a developer in this situation he should think: "What is the
> functions of the links in set A and i set B?. Are they similar or equivalent
> to functions that already exist in the rest of the applications?"
> For the set where the answer is yes than the link style should be the one
> used for that function in the other application.
> For the set where the answer is no than a new style should be defined with a
> name that describes the new function.
>

So, every application that has a group of links that aren't common to
other applications should have its own style for that set of links? Are
you serious? Every application would have its own style sheet then. NO
NO NO. The concept is to have a palette of styles for the application
developer to choose from, not to have a separate set of styles for each
application.

The bottom line is, there is no valid reason to remove the two styles.
There are valid reasons to rename them. If you are REALLY REALLY REALLY
motivated to remove styles, then PLEASE PLEASE PLEASE remove the
deprecated styles - not the ones we're currently using.

-Adrian

[Ryan Foster-3]

getting closer.  I agree with you both.  See comments inline...

Ryan L. Foster
801.671.0769
[hidden email]
ryanlfoster.com

On Jan 30, 2011, at 1:25 AM, Adrian Crum wrote:

> On 1/29/2011 11:59 PM, Bruno Busco wrote:
>> Adrian I think we are almost on the same page, please read inline.
>>
>> 2011/1/30 Adrian Crum<[hidden email]>
>>
>>> The application developer designs the application, not the graphic artist.
>>> The graphic artist styles the application, he doesn't design it.
>>>
>> 100% agreed

+ 1.  Although I think it would be great if we could get more active UxD and IxD (User Experience and Interaction Design) participation in the UI as a whole.  An effective interface is SO much more than just making a screen look nice.  An experienced Interaction Designer can offer valuable insight on how much is too much when it comes to forms and data on a page, how and where to place a form to make it easier to use, and possibly suggest ways to break up complex interactions or workflows to make it easier for the end user to use.  If some of these decisions could be made in collaboration at the development level, it can make the theme designers job a lot easier and improve the UI of the application as a whole in the long run.

>>
>>
>>> 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.
>>>
>> IMO when a developer in this situation he should think: "What is the
>> functions of the links in set A and i set B?. Are they similar or equivalent
>> to functions that already exist in the rest of the applications?"
>> For the set where the answer is yes than the link style should be the one
>> used for that function in the other application.
>> For the set where the answer is no than a new style should be defined with a
>> name that describes the new function.
>>
>
> So, every application that has a group of links that aren't common to other applications should have its own style for that set of links? Are you serious? Every application would have its own style sheet then. NO NO NO. The concept is to have a palette of styles for the application developer to choose from, not to have a separate set of styles for each application.
>
> The bottom line is, there is no valid reason to remove the two styles. There are valid reasons to rename them. If you are REALLY REALLY REALLY motivated to remove styles, then PLEASE PLEASE PLEASE remove the deprecated styles - not the ones we're currently using.
>
> -Adrian

Agreed.  I think having different grouping options is a good thing.  But, lets add the classNames and IDs to the group, not the buttons or links inside the group.  The designer can easily target styling from there much easier than having to worry about individual styles for buttons.  

(For example #main-nav .btn, #subnav .btn {...} The groups are different, but the common button elements share the same className).

Start at a granular level and work up from there.  First, have all of the buttons look the same, then have all the links look the same, making sure there is a distinction between a button and a link.  Then you can begin to target styling for these elements based on grouping.  

So in summary: +1 for renaming, +1 for re-labeling, -1 for removing, and ++1 for consolidating.  Is that clear enough?

>

[Adrian Crum-3]

Quoting Ryan Foster <[hidden email]>:

> getting closer.  I agree with you both.  See comments inline...
>
> Ryan L. Foster
> 801.671.0769
> [hidden email]
> ryanlfoster.com
>
> On Jan 30, 2011, at 1:25 AM, Adrian Crum wrote:
>
>> On 1/29/2011 11:59 PM, Bruno Busco wrote:
>>> Adrian I think we are almost on the same page, please read inline.
>>>
>>> 2011/1/30 Adrian Crum<[hidden email]>
>>>
>>>> The application developer designs the application, not the graphic artist.
>>>> The graphic artist styles the application, he doesn't design it.
>>>>
>>> 100% agreed
>
> + 1.  Although I think it would be great if we could get more active  
> UxD and IxD (User Experience and Interaction Design) participation  
> in the UI as a whole.  An effective interface is SO much more than  
> just making a screen look nice.  An experienced Interaction Designer  
> can offer valuable insight on how much is too much when it comes to  
> forms and data on a page, how and where to place a form to make it  
> easier to use, and possibly suggest ways to break up complex  
> interactions or workflows to make it easier for the end user to use.  
>  If some of these decisions could be made in collaboration at the  
> development level, it can make the theme designers job a lot easier  
> and improve the UI of the application as a whole in the long run.

I agree. In my applications I start with OFBiz screens and I break  
them up into smaller screens. But even in simplified screens,  
sometimes there is a need to distinguish two sets of links.

>>>> 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.
>>>>
>>> IMO when a developer in this situation he should think: "What is the
>>> functions of the links in set A and i set B?. Are they similar or  
>>> equivalent
>>> to functions that already exist in the rest of the applications?"
>>> For the set where the answer is yes than the link style should be the one
>>> used for that function in the other application.
>>> For the set where the answer is no than a new style should be  
>>> defined with a
>>> name that describes the new function.
>>>
>>
>> So, every application that has a group of links that aren't common  
>> to other applications should have its own style for that set of  
>> links? Are you serious? Every application would have its own style  
>> sheet then. NO NO NO. The concept is to have a palette of styles  
>> for the application developer to choose from, not to have a  
>> separate set of styles for each application.
>>
>> The bottom line is, there is no valid reason to remove the two  
>> styles. There are valid reasons to rename them. If you are REALLY  
>> REALLY REALLY motivated to remove styles, then PLEASE PLEASE PLEASE  
>> remove the deprecated styles - not the ones we're currently using.
>>
>> -Adrian
>
> Agreed.  I think having different grouping options is a good thing.  
> But, lets add the classNames and IDs to the group, not the buttons  
> or links inside the group.  The designer can easily target styling  
> from there much easier than having to worry about individual styles  
> for buttons.

That's the way the button-style* classes were originally set up. It  
wasn't until recently people started using the classes on individual  
links. The mis-application of some styles was behind the motivation to  
create the Layout Demo page.


> (For example #main-nav .btn, #subnav .btn {...} The groups are  
> different, but the common button elements share the same className).


Bruno made a good point earlier - don't have style names that indicate  
what the element looks like. So, let's not have a .btn style - because  
that implies the element will look like a button.

That subtlety was behind some of the confusion we experienced in the  
Flat Grey button-style* discussion. I couldn't understand why you kept  
insisting the styles should look like buttons. Then I realized the  
class name contains the word "button." In my mind I always pictured  
them as a group of <a> elements that could be styled to look like  
anything, not buttons specifically.


> Start at a granular level and work up from there.  First, have all  
> of the buttons look the same, then have all the links look the same,  
> making sure there is a distinction between a button and a link.  
> Then you can begin to target styling for these elements based on  
> grouping.


Maybe we should start a new thread for renaming CSS classes.


> So in summary: +1 for renaming, +1 for re-labeling, -1 for removing,  
> and ++1 for consolidating.  Is that clear enough?

[Ryan Foster-3]

> Bruno made a good point earlier - don't have style names that indicate what the element looks like. So, let's not have a .btn style - because that implies the element will look like a button.
>
> That subtlety was behind some of the confusion we experienced in the Flat Grey button-style* discussion. I couldn't understand why you kept insisting the styles should look like buttons. Then I realized the class name contains the word "button." In my mind I always pictured them as a group of <a> elements that could be styled to look like anything, not buttons specifically.

What I am saying is that an element should be named according to how it acts.  Naming something .btn should not indicate that it should look like a button, but that it should ACT like a button.  I used .btn as an example because it was the easiest to illustrate.  

For example, you can submit a form using an <input type=submit /> tag, a <button /> tag, or an <a /> tag using javascript.  So if all three are different elements, but act the same way and/or perform the same function, then they should look the same. That way, if  developer A wants to create a standard form and submit it using a <input /> element, and developer B wants to create a form and submit it using javascript with an <a />, they both have the flexibility to do that without affecting how the UI looks to the end user.  All they have to do is add a className to the element such as <a href="javascript:" class="btn"> or <input type=submit class="btn">.

To the end user, the result is the same.  All they see is a form with a button to submit the form.  They don't care, nor do they really need to know, whether that button is actually a button or some other element.  All they care about is that they see a button, and they know what a button does, because that is what all of the other buttons that look like it do.

Ryan L. Foster
801.671.0769
[hidden email]
ryanlfoster.com

On Jan 31, 2011, at 10:09 AM, [hidden email] wrote:

> Quoting Ryan Foster <[hidden email]>:
>
>> getting closer.  I agree with you both.  See comments inline...
>>
>> Ryan L. Foster
>> 801.671.0769
>> [hidden email]
>> ryanlfoster.com
>>
>> On Jan 30, 2011, at 1:25 AM, Adrian Crum wrote:
>>
>>> On 1/29/2011 11:59 PM, Bruno Busco wrote:
>>>> Adrian I think we are almost on the same page, please read inline.
>>>>
>>>> 2011/1/30 Adrian Crum<[hidden email]>
>>>>
>>>>> The application developer designs the application, not the graphic artist.
>>>>> The graphic artist styles the application, he doesn't design it.
>>>>>
>>>> 100% agreed
>>
>> + 1.  Although I think it would be great if we could get more active UxD and IxD (User Experience and Interaction Design) participation in the UI as a whole.  An effective interface is SO much more than just making a screen look nice.  An experienced Interaction Designer can offer valuable insight on how much is too much when it comes to forms and data on a page, how and where to place a form to make it easier to use, and possibly suggest ways to break up complex interactions or workflows to make it easier for the end user to use.  If some of these decisions could be made in collaboration at the development level, it can make the theme designers job a lot easier and improve the UI of the application as a whole in the long run.
>
>
> I agree. In my applications I start with OFBiz screens and I break them up into smaller screens. But even in simplified screens, sometimes there is a need to distinguish two sets of links.
>
>
>>>>> 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.
>>>>>
>>>> IMO when a developer in this situation he should think: "What is the
>>>> functions of the links in set A and i set B?. Are they similar or equivalent
>>>> to functions that already exist in the rest of the applications?"
>>>> For the set where the answer is yes than the link style should be the one
>>>> used for that function in the other application.
>>>> For the set where the answer is no than a new style should be defined with a
>>>> name that describes the new function.
>>>>
>>>
>>> So, every application that has a group of links that aren't common to other applications should have its own style for that set of links? Are you serious? Every application would have its own style sheet then. NO NO NO. The concept is to have a palette of styles for the application developer to choose from, not to have a separate set of styles for each application.
>>>
>>> The bottom line is, there is no valid reason to remove the two styles. There are valid reasons to rename them. If you are REALLY REALLY REALLY motivated to remove styles, then PLEASE PLEASE PLEASE remove the deprecated styles - not the ones we're currently using.
>>>
>>> -Adrian
>>
>> Agreed.  I think having different grouping options is a good thing.  But, lets add the classNames and IDs to the group, not the buttons or links inside the group.  The designer can easily target styling from there much easier than having to worry about individual styles for buttons.
>
>
> That's the way the button-style* classes were originally set up. It wasn't until recently people started using the classes on individual links. The mis-application of some styles was behind the motivation to create the Layout Demo page.
>
>
>> (For example #main-nav .btn, #subnav .btn {...} The groups are different, but the common button elements share the same className).
>
>
> Bruno made a good point earlier - don't have style names that indicate what the element looks like. So, let's not have a .btn style - because that implies the element will look like a button.
>
> That subtlety was behind some of the confusion we experienced in the Flat Grey button-style* discussion. I couldn't understand why you kept insisting the styles should look like buttons. Then I realized the class name contains the word "button." In my mind I always pictured them as a group of <a> elements that could be styled to look like anything, not buttons specifically.
>
>
>> Start at a granular level and work up from there.  First, have all of the buttons look the same, then have all the links look the same, making sure there is a distinction between a button and a link.  Then you can begin to target styling for these elements based on grouping.
>
>
> Maybe we should start a new thread for renaming CSS classes.
>
>
>> So in summary: +1 for renaming, +1 for re-labeling, -1 for removing, and ++1 for consolidating.  Is that clear enough?
>
>

[Adrian Crum-3]

Thanks - that makes sense.

-Adrian

Quoting Ryan Foster <[hidden email]>:

>> Bruno made a good point earlier - don't have style names that  
>> indicate what the element looks like. So, let's not have a .btn  
>> style - because that implies the element will look like a button.
>>
>> That subtlety was behind some of the confusion we experienced in  
>> the Flat Grey button-style* discussion. I couldn't understand why  
>> you kept insisting the styles should look like buttons. Then I  
>> realized the class name contains the word "button." In my mind I  
>> always pictured them as a group of <a> elements that could be  
>> styled to look like anything, not buttons specifically.
>
> What I am saying is that an element should be named according to how  
> it acts.  Naming something .btn should not indicate that it should  
> look like a button, but that it should ACT like a button.  I used  
> .btn as an example because it was the easiest to illustrate.
>
> For example, you can submit a form using an <input type=submit />  
> tag, a <button /> tag, or an <a /> tag using javascript.  So if all  
> three are different elements, but act the same way and/or perform  
> the same function, then they should look the same. That way, if  
> developer A wants to create a standard form and submit it using a  
> <input /> element, and developer B wants to create a form and submit  
> it using javascript with an <a />, they both have the flexibility to  
> do that without affecting how the UI looks to the end user.  All  
> they have to do is add a className to the element such as <a  
> href="javascript:" class="btn"> or <input type=submit class="btn">.
>
> To the end user, the result is the same.  All they see is a form  
> with a button to submit the form.  They don't care, nor do they  
> really need to know, whether that button is actually a button or  
> some other element.  All they care about is that they see a button,  
> and they know what a button does, because that is what all of the  
> other buttons that look like it do.
>
> Ryan L. Foster
> 801.671.0769
> [hidden email]
> ryanlfoster.com
>
> On Jan 31, 2011, at 10:09 AM, [hidden email] wrote:
>
>> Quoting Ryan Foster <[hidden email]>:
>>
>>> getting closer.  I agree with you both.  See comments inline...
>>>
>>> Ryan L. Foster
>>> 801.671.0769
>>> [hidden email]
>>> ryanlfoster.com
>>>
>>> On Jan 30, 2011, at 1:25 AM, Adrian Crum wrote:
>>>
>>>> On 1/29/2011 11:59 PM, Bruno Busco wrote:
>>>>> Adrian I think we are almost on the same page, please read inline.
>>>>>
>>>>> 2011/1/30 Adrian Crum<[hidden email]>
>>>>>
>>>>>> The application developer designs the application, not the  
>>>>>> graphic artist.
>>>>>> The graphic artist styles the application, he doesn't design it.
>>>>>>
>>>>> 100% agreed
>>>
>>> + 1.  Although I think it would be great if we could get more  
>>> active UxD and IxD (User Experience and Interaction Design)  
>>> participation in the UI as a whole.  An effective interface is SO  
>>> much more than just making a screen look nice.  An experienced  
>>> Interaction Designer can offer valuable insight on how much is too  
>>> much when it comes to forms and data on a page, how and where to  
>>> place a form to make it easier to use, and possibly suggest ways  
>>> to break up complex interactions or workflows to make it easier  
>>> for the end user to use.  If some of these decisions could be made  
>>> in collaboration at the development level, it can make the theme  
>>> designers job a lot easier and improve the UI of the application  
>>> as a whole in the long run.
>>
>>
>> I agree. In my applications I start with OFBiz screens and I break  
>> them up into smaller screens. But even in simplified screens,  
>> sometimes there is a need to distinguish two sets of links.
>>
>>
>>>>>> 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.
>>>>>>
>>>>> IMO when a developer in this situation he should think: "What is the
>>>>> functions of the links in set A and i set B?. Are they similar  
>>>>> or equivalent
>>>>> to functions that already exist in the rest of the applications?"
>>>>> For the set where the answer is yes than the link style should be the one
>>>>> used for that function in the other application.
>>>>> For the set where the answer is no than a new style should be  
>>>>> defined with a
>>>>> name that describes the new function.
>>>>>
>>>>
>>>> So, every application that has a group of links that aren't  
>>>> common to other applications should have its own style for that  
>>>> set of links? Are you serious? Every application would have its  
>>>> own style sheet then. NO NO NO. The concept is to have a palette  
>>>> of styles for the application developer to choose from, not to  
>>>> have a separate set of styles for each application.
>>>>
>>>> The bottom line is, there is no valid reason to remove the two  
>>>> styles. There are valid reasons to rename them. If you are REALLY  
>>>> REALLY REALLY motivated to remove styles, then PLEASE PLEASE  
>>>> PLEASE remove the deprecated styles - not the ones we're  
>>>> currently using.
>>>>
>>>> -Adrian
>>>
>>> Agreed.  I think having different grouping options is a good  
>>> thing.  But, lets add the classNames and IDs to the group, not the  
>>> buttons or links inside the group.  The designer can easily target  
>>> styling from there much easier than having to worry about  
>>> individual styles for buttons.
>>
>>
>> That's the way the button-style* classes were originally set up. It  
>> wasn't until recently people started using the classes on  
>> individual links. The mis-application of some styles was behind the  
>> motivation to create the Layout Demo page.
>>
>>
>>> (For example #main-nav .btn, #subnav .btn {...} The groups are  
>>> different, but the common button elements share the same className).
>>
>>
>> Bruno made a good point earlier - don't have style names that  
>> indicate what the element looks like. So, let's not have a .btn  
>> style - because that implies the element will look like a button.
>>
>> That subtlety was behind some of the confusion we experienced in  
>> the Flat Grey button-style* discussion. I couldn't understand why  
>> you kept insisting the styles should look like buttons. Then I  
>> realized the class name contains the word "button." In my mind I  
>> always pictured them as a group of <a> elements that could be  
>> styled to look like anything, not buttons specifically.
>>
>>
>>> Start at a granular level and work up from there.  First, have all  
>>> of the buttons look the same, then have all the links look the  
>>> same, making sure there is a distinction between a button and a  
>>> link.  Then you can begin to target styling for these elements  
>>> based on grouping.
>>
>>
>> Maybe we should start a new thread for renaming CSS classes.
>>
>>
>>> So in summary: +1 for renaming, +1 for re-labeling, -1 for  
>>> removing, and ++1 for consolidating.  Is that clear enough?
>>
>>
>
>