Design goals

The goal with this new design was to develop a simple, responsive layout that provided flexibility for creative expression through graphic design work. I am a big fan of the idea of providing customized page design based on the subject matter of the content. The layout and HTML structure for each section of the site is identical but the presentation around it can be easily customized through CSS, by targeting classes that have been applied to the body tag. For the most part, this type of custom design is seen primarily in print media. On the Web, the idea is typically ignored so that development can be streamlined. Jason Santa Maria’s personal website is a stunning example of this concept and an inspiration for this site.

Responsive Web Desgin

A feature of this website that I payed particular attention to is was the concept of “responsive website design”. For a majority of my personal work, I make my Websites that utilize “liquid”layouts. The same is true for this website, but with the help of some CSS3 media queries and some jQuery, the layout also adjusts itself to the screen size to provide a pleasant user experience on large and small screen sizes.

Example:

About page: 1680px wide

About page: 1024px wide

I am working on applying this concept to a mobile platform as well. Although not completely finished, I have been experimenting with adapting the same set of code to a mobile version of my website while optimizing it to run smooth on much much less powerful devices.

Up and coming

With the framework in place, I will continue to make updates and adjust the “Themes” of the many blog posts and pages of site to keep things fresh and explore different ways to utilize the web as an artistic medium.

Comments / Suggestions?

If you’ve stopped by my site to take a look at my work or read a blog post, let me know what you think by leaving a comment!

Download RMSforms-v0.5.css
View Examples / Reference Sheet

RMSforms v0.5 was tested in IE6 – 7, Firefox 3 & Google Chrome. More testing is to come.

It is validated using XHTML STRICT doctype

The HTML

“RMSforms”, CSS forms framework is based off a very simple HTML structure:

<fieldset>
  <legend></legend>
    <ul class="form [modifier]">
      <li><label class="[label modifier]"></label><input/></li>
    </ul>
</fieldset>

The Beauty of the Un-ordered List

Un-ordered lists are a great tool for grouping form elements together because they make sense semantically and provide for the level of flexibility needed to style a form effectively.

In essence, a web-based form is a LIST of form fields with coresponding labels that are grouped together visualy based on their association to each other. In the HTML structure of RMSforms, the <ul> provides a container for the list of all related labels / form fields and the <li> provides a container for the grouping of the individual <label> / form field combinations. In more complex forms, a <label> can often times be used to distinguish not only just one <input>, but a "nested form" that has a series of labels / form fields. With the the <ul><li> structure, nesting a form is very easy.

Other CSS form techniques use <p> tags, <div> tags, and line breaks to group individual labels & form field combinations together. I think these grouping methods leave a lot to be desired as far as flexibility and semantics. In my opinion, line breaks should be avoided whenever possible, <p> tags should only be used when presenting a paragraph, and although <div> tags would work, your html code would get real sloppy in an advanced form.

The CSS

In every web-based form there are two layout orientations that can be used to display the relationship between a <label> and it’s corresponding form field; horizontal or vertical. The same is true for the visual orientation of the <label> / form field groupings to one another. This simple concept is the basis for the class names being used within the “RMSforms” framework.

The allmighty “form” class

Each top-level form <ul> in the "RMSforms" html structure has a base class of “form” applied to it. This class establishes a basic visual relationship between the elements within the form, sets a background-color and provides some outer padding.

<ul class=”form”></ul>

The Modifier Classes

The most important classes defined in the "RMSforms" stylesheet are the “form modifiers”. These are 3 letter classes that modify the visual relationship between the <li>, <label>, and <input> elements respectively.

The first letter in the modifier class names describes the orientation of the <LI> tags in the form <ul>, the second letter describes the orientation of the <LABEL> tags in he form <ul> and the third letter describes the orientation of the form fields within the form <ul>. The 3 letters that make up the modifier class names are “H”, “V” and “I”

• H = Horizonal Block
• V = Vertical Block
• I = Inline

A list of all the form modifier classes:

• vvv – Vertical <li>, Vertical <label>, Vertical form fields
• hvv – Horizontal <li>, Vertical <label>, Vertical form fields
• hii – Horizontal <li>, Inline <label>, Inline form fields
• hhh – Horizontal <li>, Horizontal <label>, Horizontal form fields
• vii – Vertical <li>, Inline <label>, Inline form fields
• vhh – Vertical <li>, Horizontal <label>, Horizontal form fields

Usage Example…

The class “hvv” describes a form with <li> tags that are layed out horizontally and <label> tags which are vertical block elements that sit on top of vertical block form field tags.

<ul class=”form (default form class) hvv (form modifier)“></ul>

To view this example in html, take a look at the RMSforms example page

Label Modifiers

Often times, you may want the visual orientation between a <label> and form field tags to vary within a form. For example, if one of your labels in a “VHH” form has a lot of text in it, you may want it to sit on top of it’s corresponding form field rather than to the left of it. This is where the label modifiers come into play. Label modifiers are used to override the classes placed on the form <ul> and should be applied to <label> elements within a form. The exiting label modifiers are classes:“v” or “h”.

Form Nesting

One of the advantages to this form framework is the ability to nest form <ul> tags without a problem. In many advanced forms, problems pop up when needing to incorporate multiple <label> / form field combinations within one grouping. Using the form modifier classes, simply nest a form <ul> with the appropriate modifier applied to it within an <li> and you’re all set.

Why Not Just Use Tables?

Ah, the great question. Why not just use tables? Wouldn’t be a lot easier? Yes it would, but, being a semantic Web design nut, I believe tables should only be used in html to describe tabular data. If your not too concerned with html semantics, it is a very plausible solution for the laying out forms.

Comments, Suggestions and Modifications Are More Than Welcome.

"RMSforms" CSS Forms framework is a work in progress. The goal of this project is to make form styling as simple as possible. There are probably many scenarios in that I didn’t account for, or bugs that I have not come across. If you have any questions, comments or ways to improve this framework please post them up or contact me directly. I look forward to hearing from you!

Updates: 6/16/2011

• Added “list-item modifier: inline” (line 125): Adding class=”inline” to any <li> in a form will convert all inputs and labels contained in that list-item to inline elements. This is helpful when you have a form where a group of form elements needs to be displayed horizontally within one list item of a form laid out vertically.
• Separated “theme styles” from the framework styles in the Examples / Reference Sheet : This was done so that no generic font or layout styles are contained in the framework, making it easier to implement.

“I don’t really like it. Overall, this is really not the direction I wanted to go in with the site. Do you think we could try something new?”

The client is not always right… we just have to make them think they are always right

The initial response to this situation, post anger and aggression, is: “wow this client stinks!” What does “he / she” know about the direction they SHOULD go in! I’m the designer!

For the most part, theses comments are all valid. The client is not a designer, if they responded like the above quote they probably do stink, and no, they don’t know what direction they SHOULD go in.

What the client does know is what they WANT and how they want it to look. Unfortunately it is up to you to give them what they want. I believe every client has a basic mental picture of what they want from their website. “Good clients” are people who are willing to alter that image based on your input. Bad clients are the ones that stick to that image and don’t want to make any alterations to their beautiful imagination.

So in other words…

In order to go anywhere with clients, you need to understand your client and try to grasp their imaginary website. Being able to do this takes time and understanding of your client’s personality, site examples, and listening to how they talk about their website. If you do this, it is easier to do what the client wants. You have to use their imagination as a starting point for your comp.

The key is to both satisfy their mental image while demonstrating good design principles at the same time. Take advantage of the client’s hazy mental picture. Modernize it. Make it work. Unfortunately, a lot of the time client’s mental images of their site are based off badly designed web sites so you may have to sacrifice some cool web 2.0 design trends and styles in order to achieve a good balance.

These words have been heard by probably every web designer when consulting with a client. It is a comment that is very limited in its ability to give a designer any sort of useful feedback toward the visual design of a website because “bigger and bolder” needs to be applied to elements of a site very carefully to be effective. “Bigger and bolder” is usually only a small part of a solution to the problem of emphasizing important information. Big red and blue text in 32pt Arial font does not sell or even emphasize unless it is displayed in a way that is consistent with the site design but provides adequate contrast from the less important content. Not everything can be big and bold or else nothing is, and everything that is big and bold must be consistent with the rest of the site.

Eye Tracking Studies

It was proven through eye tracking studies performed by Jacob Neilson and others that, on the web, people ignore sections of a web page that look like ads. A similar study was conducted by Neilson when testing the effectiveness of large graphics on homepages. The findings were similar. According to eye tracking software, users spent very little time at all looking at the large graphical sections on a page. What these studies imply is that users ignore content which is inconsistent with the site design and seem irrelevant to the the content of a page. Ads are distinguished by their inconsistency with the design of a given site while many large graphical images on a page come off as irrelevant unless accompanied by areas of text.

Proper Emphasis

When emphasizing specific content on a page it is important to make use of contrast in combination with elegance to avoid the above mentioned situations. High contrast draws attention, and differentiates the important information from the less important information while elegance presents the information in a way that will not detract users from viewing it. Elegant displays of important information will emphasize the content you want but will not seem to demand attention of the user due to it’s inherit ability to “fit in” with the rest of the site content.

Bigger is only bigger if there is contrast and bolder is only bold if the layout presents the information elegantly. Other than that, you have what comes off as an advertisment and people will ignore it.

Examples…

The Iphone informational pages, or any of apple’s promotional product pages display high contrast, elegant graphical sections in ways that are very consistent with the page design and lead into to important, and relevant content.

In the term “liquid layout”, I’m not referring to web sites where only the background colors / background images extend to the bounds of the browser window but the content and page layout is not affected.

Why you may not want to use a liquid layout.

• Dificulty
• Aesthetics
• Usability

Difficulty

Simply put, liquid layout are more difficult to construct than static layouts. For each element of the layout / design you must take into account the ability to extend it vertically as well as horizontally. In terms of CSS Layouts, this factor can be a nightmare, especially if you have, for example, one static column and one “liquid” column. CSS was obviously not developed to handle the “pixel / Percentage” combination very well because the only efficient means of succeeding in this are basically work arounds. I found a great site titled Layout gala that helps out a lot with this technique, and I actually used as a basis for the layout of this site.

Aesthetics

Aesthetics and design principals sort of have to go out the window when it comes to creating a liquid layout especially since you have to compensate for an individuals with high screen resolutions. Design and “visual harmony” on the web, or in any media for that matter is based very much on proportions and when a liquid layout is used, these proportional rules need to be extended to a point where they just don’t work anymore. This is especially the case when trying to get a layout to “look nice” stretched out horizontally on a 30″ monitor.

Usability

The optimum readable width for a section of text on the web has been proven to be about 450px 65-85 characters (source) . This width is almost always exceeded on large monitors with high screen resolutions when a liquid layout is implemented, unless of course the content section is a static width.

Why you should consider using liquid layouts.

• Extensibilty
• Usability
• Taking advantage of the medium

Extensibilty

With a liquid layout, there is no need for a re-design when a larger screen resolution has become the most popular… your site will conform to any size browser window size.

Usability

Websites that fit your browser are often easier to read and interact because all the content is always visible and there is rarely any need for the horizontal scroll bar regardless of the browser window size. There is an obvious exception to this if you implement a minimum width on your containing element.

Taking advantage of the medium

I read this article by Thomas Baekdal where he writes about the redundant debate between liquid vs. static layouts. His response is:

“There is an amazing amount of articles on the net on how to make the overall layout. But, none of these gets it right. They are all trying to solve the wrong problem.

These articles define the problem as either having too much space – i.e. large empty areas outside your content – or too little space that forces horizontal scrolling and lack of whitespace.

I understand why this is a problem, and why people want to eliminate it. But, you are not solving the right one. The real problem is; how do you optimize the visual presentation of your website? How do you make your content look amazing? How do you make it easy to see – to read?”

He is correct, and this article is probably another one of those articles about the debate between liquid and static layouts but I think reasons for using liquid layouts extend beyond the bounds of making sure content looks great. What I want to bring to attention with this article is the question of whether or not, as WEB designers, we should develop websites to cohere to ALL of the unique aspects of our medium. Should we make a point to implement all the tools and techniques available to us so that each of our web-sites takes into account the fact that the size of our medium is not static at all? With a static layout, for the most part, we are basically replicating design techniques seen on print and television media but that is not our medium.

In television, there are two aspect rations, thats basically it 4×3 and 16×9, so designing for television is easy when it comes to choosing a size. The same is true for print. In the web, there are different screen resolutions, screen sizes, and then the window size. By ignoring this aspect of our medium are we are taking the easy way out? Should we be taking the easy way out? If we ignored the size of the medium in any other application, things would look awkward and would not be received correctly. This is the same situation in the web and is also the reason why I think there is so much debate about this topic.

Some nicely implemented liquid layout sites: (more to come)

• w3.org.
  This site has been adapted with a liquid layout and manages never to become “awkward”. With that said, it isn’t to high on the “flashy design” totem poll
• vivabit.com
• smashingmagazine.com

The problem visualized:

There are basically 3 ways to get divs to expand with their floated children:

1. “Clear the floats”

   Probably the most common way to go about getting container <div>’s to expand with floated child elements is to place a “clearing element” with the css property: “clear:both” after the floated elements within the containing <div>. This method works great, but there are some situations where the clearing elements end up needing to be an empty <div>, or I have seen the <br> tag used before… Personally, I don’t really like using blank elements for the sake of getting layouts to work properly. Also, top margins do not work on “cleared” elements in IE7 and FireFox.

   Container
   

   Float:left

   Float:right

   clear element
   (clear:both, margin-top:10px;)

2. Float the containing <div>

   The easiest way to go about getting <div>’s to expand vertically with their floated children is to float the containing <div> with a specified width. This method works great for static layouts but there are some slight drawbacks with the nature of the “float” property that stem from the need to specify widths on floated elements. Sometimes things get messy further down the hierarchy. In addition, if you want to center a floated <div>, an extra <div> is needed. Once again, Personally, I like to be as efficient as possible with <div> usage.

   Container (float:left, width:230px;)
   

   Float:left

   Float:right

3. Overflow:hidden; Height:1%;

   So what if you want a liquid width and don’t want to use extra elements to achieve “vertical containment” around your floated elements? Use the properties: overflow:hidden and height 1%;.

   This method doesn’t have to be used often but it has it’s advantages. It basically acts the exact same way as setting the CSS properties: float:left; width 100%; BUT the advantage is that you don’t have to set any widths. I have found this technique to be very useful in liquid layouts where I need some padding on a container element. I also use this technique when standardizing pieces of code for use in multiple web sites. I design a lot of e-commerce sites, and depending on the site, modules have to be placed in areas of varying widths depending on the site design, so in order to make the the code standard across the board without having to set widths every time, the module needs to be liquid.

   This method basically makes the container element think that their is a height set on it so it acts just like floating the container… but with no widths! The overflow:hidden takes care of the FireFox end of the solution while the height:1%; takes care of IE. An important thing to note about this method is that a height cannot be set on the container of the element of the you place overflow:hidden, height:1%; in or, well, obviously it will make the height of the div 1% of the container.

   Container (overflow:hidden; height:1%)
   

   Float:left

   Float:right

I read this article on A List Apart about HTML5, and currently there is a site called css3.info devoted to the development and implementation of CSS3. We can gawk at the new great things about CSS3 and HTML 5 but the question everyone wants to know is: when can we care? Right now it is still important to design design and developing sites for IE6… I mean come on. IE6 DOESN’T SUPPORT .PNG TRANSPARENCY out of the box! We can’t even use apects of css2 in some modern browsers. By the time we can actually use CSS3 and HTML5 or any other exciting new stuff, the web will be one big widget or gadget, or plugin… whatever. Technology is moving faster than people are moving and there are no enforced standards for “the people” so all we can do is wait… a long time. I’m not saying it’s a bad thing to create sites about CSS3 and HTML5 because it is interesting and exciting and at least sites like this start to open the doors, but it’s like waiting in line at a store to buy a highly anticipated DVD that hasn’t even hit the theaters yet. Come on people update your browsers! Use FireFox! Lets get the show on the road here!

So I guess the answer to the question “when can we care is” is: Whenever we want but we better have those browser conditionals on hand and ready for use.

Create a horizontally centered “tabbed” navigation menu using CSS without having to specify widths on any elements. Also, implement multiple background images to correspond with your design.

Why You Would need it?

You might want to create a centered layout with very “minimalist” menu. You may have multiple pages with varying amounts and sizes of navigation items and don’t want to have to specify a width on the ‘ul’ in every page

The solution:

Here it is:

The menu is created using no CSS hacks, workarounds, or conditionals.

The html:

<div id="navcontainer" style="border:1px solid #000000; padding:10px;">
<ul id="navlist">
<li id="first"><span><a href="http://www.rmsjr.com">Recent Work</a></span></li>
<li class='active'><span><a href="http://www.rmsjr.com/?cat=3">Web</a></span></li>
<li><span><a href="http://www.rmsjr.com/?cat=4">3D</a></span></li>
<li><span><a href="http://www.rmsjr.com/?cat=5">Graphic Design</a></span></li>
<li id="last"><span><a href="http://www.rmsjr.com/?cat=6">Traditional Art</a></span></li>
</ul>
</div>

The CSS:


#navcontainer ul, #navcontainer ul li, #navcontainer ul li.active span, #navcontainer ul li span, #navcontainer ul li.active span a, #navcontainer ul li span a{
padding-top:16px;
padding-bottom:16px;
}

————————————————————-

I have seen this type of thing being attempted here: http://24ways.org/2005/centered-tabs-with-css but in this example the menu didn’t show up correctly for me in IE7 and the author used the ol’ holly hack, which I believe doesn’t apply anymore.

I also saw something similar on http://css.maxdesign.com.au/listamatic/ , but all those horizontally centered menus were very bare bones and simple without using background images at all.

Conclusions:

It was a long hard battle through the winds of Internet Explorer and the Seas of Firefox but I finally endured the elements (no pun intended) and made it to land safely! I have not explored the lands of Opera or went on a Safari but I will soon (sorry if it doesn’t work yet for you “Operatarians” or “Safarians”).

I learned a few things during the process:

1. Don’t even bother doing this if you have a remote chance of a simpler block – level alternative
2. There is one minor, but extremely important difference to understand between how IE and Firefox handle in-line elements: Child inline-elements in IE expand the size of their parent elements… ** VERY IMPORTANT ** . This concept seems like it would be something obvious but it took me a while to grasp the dynamics of it due to the nature of inline styles and, with multiple parents, things get confusing during the process.
3. Padding is my friend. Padding is the key to creating a horizontally centered tab menu. Basically the main thing that determined the success of the menu was getting the correct padding on all the elements.

The Good Things:

1. The menu is always centered without having to set a width on any element.
2. The menu has very clean html / css
3. List items expand and contract with the content
4. and… well that’s about it. (a lot for a little I guess)

The Not So God Things:

1. The height measurements within the menu are very static. For example… If you want to change font sizes, many adjustments have to be made to paddings throughout the menu to get it to look correct.
2. You can’t have two lines of text in a list item.
3. Images can only be a limited height to keep the design in tact.