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?
