Some background and additional thoughts for the community in general, not Ryan specifically...

In 2007 the UI was refactored - partially because of the same reason mentioned here: too many styles in the style sheet and no consistency in their use.

At around the same time we were also adding a lot of new contributors and committers to the community. I started to notice that the UI layout was losing consistency - and I assumed it was because the new commits weren't being checked thoroughly.

In 2008 there was another UI refactor that drastically changed the layout - where nearly every screen was wrapped in a screenlet. That layout change was never discussed with the community, and I have no idea why it was made.

So, I created a Wiki page of UI Layout Best Practices for others to refer to:

https://cwiki.apache.org/confluence/display/OFBADMIN/User+Interface+Layout+Best+Practices

That document is intended to describe basic layout - from a typesetter's perspective. Specific CSS styles shouldn't be mentioned in it, but they are - and I plan to fix that when I have time. The document is based on the de-facto UI layout prior to things going bad.

I use those Best Practices myself - even recently when I moved the security UI artifacts from the Party component to the Common component. Once I understand the basic layout, I go to the HTML markup page:

https://cwiki.apache.org/OFBIZ/ofbiz-maincsscss-html-element-collection-styles.html

to see what styles are available to lay out the page.

It was my hope that those documents would help keep the UI consistent, but like I said earlier - they are only effective if people read them.

I said all that to say this: It's common for style sheets to bloat, and it's common for UI layout to creep. It takes conversations like this one to bring the bloat and creep to the community's attention, but it won't change until someone takes action.

-Adrian


On 1/12/2011 1:29 PM, Adrian Crum wrote:
Keep in mind that the button-style-* classes are button-bar decorators.
Having two buttons that perform the same but look different was not an
issue here - the two styles indicated two different purposes, PLUS they
were in different button bars. So, you had a row of buttons in one style
that were intra-app, and another row of buttons in a different style
that were inter-app. There was no confusion - the styles and the
separation into two rows were a clear visual indicator of where the link
was going to take you.

The purpose of the button-bar style was to provide a container for
graphic artists to design around. The buttons could be arranged in a row
(the current orientation) or they could be a vertical stack.

-Adrian

On 1/12/2011 1:05 PM, Ryan Foster wrote:
Consistency is not synonymous with monotonous. Hey, that sounds like a
good catch phrase... Consistency is not synonymous with monotonous™

But seriously, if different elements perform the same way then they
should look the same and be called the same thing. There is no reason
why we can't have<button class="btn">,<input type="submit"
class="btn">, and<a class="btn"> if they all do the same thing. That
doesn't make the UI bland, it makes it consistent and familiar. I'm
all for having options, but they should be done with a purpose. For
instance, we could a primary button style, a secondary button style
and a tertiary button style, but these should be combinations, not
individual style. For example:

<a href="#" class="btn primary">
<a href="#" class="btn secondary">
<a href="#" class="btn tertiary">

That way, we could apply a consistent button style and then make
adjustments if we need to based on what action the button performs,
Save vs. Cancel, etc. But simply having a button-style-1, and a
button-style-2 because maybe we want to have a blue button and a green
button is not a good reason, no is it a good idea. Having 2 buttons
that perform the same, but look different just confuses the user and
makes an already complex application even more difficult to use.

Ryan L. Foster
801.671.0769
cont...@ryanlfoster.com
ryanlfoster.com

On Jan 12, 2011, at 1:30 PM, Adrian Crum wrote:

We need the smallSubmit style so we can style links to look like
submit buttons. Maybe we could change the CSS class to
"a.smallSubmit" to make sure it is used only for<a> elements.

The button-style-1 and button-style-2 style names are pretty generic
- they don't indicate how the button should appear (aside from the
obvious - that they should look like buttons). Originally, the rows
of buttons below the page title had two styles that indicated two
types of buttons: those that linked to other pages within the
application (intra-app) and others that linked to pages outside the
application (inter-app). That distinction has been lost in recent
changes.

A similar thing was done with the table header styles - there are two
styles to choose from, depending on how you use them. The style names
don't indicate what they look like.

I don't think there is anything wrong with having more than one style
to choose from. If we were to cut back too much on the selection,
then the UI would start to look bland or monotonous.

I created a Wiki page that listed some of the deprecated styles and
another page that describes the new styles and how they should be
used. Those pages are effective only when people take the time to
read them.

-Adrian

On 1/12/2011 12:01 PM, Bruno Busco wrote:
In addition, when deprecating or selecting styles to be used we should
better use style names that describe what the button IS in the
screen and
not HOW it should appear.

So style names like
.buttontextbig, .smallSubmit, .mediumSubmit, .largeSubmit,
.button-style-1, .button-style-2,

should not be used.

Style names like:
.buttontext,
.loginButton,
.button,
input[type="reset"],
input[type="submit"],
input[type="button"]

are OK.
In this way the theme can make a button larger or smaller than another
button according to its function.

My two cents.
-Bruno

2011/1/12 Ryan Foster (JIRA)<j...@apache.org>


[
https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980883#action_12980883]


Ryan Foster commented on OFBIZ-4092:
------------------------------------

I tried deleting deprecated styles and letting things break when I
created
the BizznessTime theme... mostly just pissed people off. :)

Update The Flat Grey Visual Theme
---------------------------------

Key: OFBIZ-4092
URL: https://issues.apache.org/jira/browse/OFBIZ-4092
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Reporter: Adrian Crum
Assignee: Adrian Crum
Priority: Minor
Attachments: ac_flatgrey.patch, ac_images.zip,
accounting800x600.png, brushed-aluminum.gif, catalog800x600.png,
catalogManager.png, content800x600.png, contentManager.png,
flatgrey.patch,
flatgrey.patch, flatgrey.patch, flatgrey.patch, flatgrey.patch,
images.zip,
ofbiz_logo.gif, partyDetail.png, partyManager.png, screenshot.gif,
timeSheet.png


Update the Flat Grey visual theme. Design objectives:
1. Floating, flexible layout - screen can be resized.
2. Sight impaired accessible - users can change font size in their
browser.
3. Supports RTL layout.
4. Does not require JavaScript. JavaScript can be used to add
embellishments, but the theme can't depend on it.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.






Reply via email to