Thanks - that makes sense.
-Adrian
Quoting Ryan Foster <[email protected]>:
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
[email protected]
ryanlfoster.com
On Jan 31, 2011, at 10:09 AM, [email protected] wrote:
Quoting Ryan Foster <[email protected]>:
getting closer. I agree with you both. See comments inline...
Ryan L. Foster
801.671.0769
[email protected]
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<[email protected]>
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?
