> 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
cont...@ryanlfoster.com
ryanlfoster.com
On Jan 31, 2011, at 10:09 AM, adrian.c...@sandglass-software.com wrote:
> Quoting Ryan Foster <cont...@ryanlfoster.com>:
>
>> getting closer. I agree with you both. See comments inline...
>>
>> Ryan L. Foster
>> 801.671.0769
>> cont...@ryanlfoster.com
>> 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<adrian.c...@sandglass-software.com>
>>>>
>>>>> 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?
>
>
