I saw a tweet asking for feedback on a new website for a firm in Florida, Ryan Design Group. Competently constructed in a technical sense, it’s a site that demonstrates the problems caused when client demands are at odds with good design practice.

The Good

The site in the main is reasonably well put together. It has a clear design ethos, a solid layout and good use of color. While not truly outstanding design, it’s better than most sites created for small local businesses. It showcases the company’s brand, has a nice (if over-engineered) navigation system, and lays out Ryan Design Group’s work and contact information effectively.

There are no major complaints about the core design and functionality of the site. Nothing to suggest the design company doesn’t know what they’re doing. It’s clear from their wider portfolio that they have the capacity to offer decent web design as part of an overall package of graphic and print services.

The Bad AND The Ugly!

Unfortunately, two huge errors mean the solid core of the site is going to be seen by a lot less people than might otherwise be the case.

Don’t have a lengthy loading Flash splash page.

It’s a core rule of web design, and this site falls straight into that trap. An eleven second Flash animation splash page. The Flash work is well done, but that’s beside the point.

I want to visit a website and immediately be able to access the information I’m looking for. It’s a two stage process; navigate to website then navigate to relevant content. A flash introduction page triples that; navigate to website, splash page loads, I acknowledge I’m not interested, I look for “skip intro”, I click it, I navigate to relevant content. Six steps instead of two.

The splash page adds no value, and a lot less people are going to stay on the site simply because it exists.

• Varying studies suggest that a splash page can reduce click through rates by anything from 25% up to more than 70%. People just give up.
• Flash splash pages lack important keyword phrases and significantly undermine search engine optimization.

Splash pages provide a barrier to information. They can mean the difference between winning new business or losing it.

Don’t embed music on your page, don’t open new windows.

The site automatically loads music, another fundamental error. It compounds this error to ensure the music keeps playing by loading the rest of the site in a new tab/window! This wrests control of the browser from the user and is confusing. I didn’t realize initially that the site had loaded a new window so I couldn’t even work out where the music was coming from!

• Sound loops increase page download times. Load times should be optimized. More than 5% of US internet users still use dial-up (with evidence that in tough economic times more people revert to that cheaper option), and broadband speeds can be variable.
• Musical tastes vary widely. I don’t mind the music on the Ryan Design Group site. Others might be put off because they hate it!
• I’m already listening to music. With online radio stations, iTunes, Spotify, Pandora, Last.FM etc, millions of people are listening to music while they browse. Adding another soundtrack just leads to a horrible clash of noise. It could be even worse; if your visitor is on a Skype phone call while they browse you’ve just messed up their call.

Do You Say “No” To Your Client?

The designers have done what they can to alleviate these huge problems, providing options to skip the Flash introduction and mute the music. But those are such negative issues for a website that there’s little that can be done to avoid the massive downsides to the user experience.

Should the designers have refused to integrate these client requests into the site? I would have. Clients hire me to be a web designer. They acknowledge I know more about web design than them. I’d explain to a client the problems of splash pages and integrated music, and why I wouldn’t do it, regardless of how insistent they were.

That’s a tough path to take. It’s where you have to have the confidence to say to the customer that they’re wrong, and to stick to your guns. I have no idea about this designer’s relationship with the client, their economic situation, or any of the other factors that made they accepted the client’s demands for this site.

I still think they should have said “no”. Every designer makes compromises, but compromise shouldn’t mean agreeing to something that you know is outright bad design practice. A clearly competent designer now has a portfolio piece that fails to demonstrate their ability. The immediate benefit of agreeing to this client’s demands could easily harm their future business.

Many people probably first heard of the golden ratio in Dan Brown’s faux cerebral Da Vinci Code. It’s noted there as 1.618 / 1. That’s a slightly simplified version, like saying Pi is simply 3.14, but close enough (like Pi, you can go on indefinitely with your decimals). From a design standpoint, simply put, things look naturally good if their dimensional ratio are close to this – e.g. a rectangle that’s 1.618 metres long and 1 metre wide.

Easy Web Implementation

The most obvious way to implement the golden ratio in web design is when you have a two column layout for a website. You have your main column and your sidebar. So why not use the golden ratio to determine the widths of each section? Easily done in any fixed width design. I prefer fixed width as a designer (an entirely subjective choice, the fixed vs fluid argument will run forever), so I utilize the golden ratio regularly.

It works like this. I’m designing a size that’s going to be 960 pixels wide, with a main column and a sidebar. So I head off to one of those wonderfully useful pages you find on the web sometimes, goldenratiocalculator.com. I enter 960 as my width, and the calculator tells me that my sidebar should be 367 pixels wide, and my main content should be 593 pixels wide. Quickly and easily I’ve got a solid aesthetic basis for my site.

You can extend the use of the golden ratio far more widely. You can use it for line-height vs font-size for example, for margins of headers, for input boxes vs label width in forms. Clearly it’s not the only design choice you ever need make, but it’s proven over millennia to be a great one.

Overly Pedantic Question

This is one for the designers out there. Do you add margins before or after you calculate the golden ratio for your columns?

If we just made our sidebar 367 pixels wide and the main content 593 pixels wide there’d be no margin. The text in the sidebar would run up against the content without a gap. And it’s always been clear that good margins and white space in general can really improve the visual impact of a web design. So we’re going to need margins.

Let’s say we’re going to have a 30 pixel margin between our sidebar and our main content. If we’ve already made the golden ratio division, that means subtracting 15 pixels each from the width of our two columns. So the sidebar is 352 pixels wide and the main content is 578 pixels.

Except that isn’t the golden ratio any more. It’s pretty close, but it’s not exact. Of course, we could just say “screw it”, because the difference is minimal, but sometimes I like to be pedantic. As display screens and resolutions get larger, the importance of an accurate reflection of the golden ration might get more important in any case.

I tend to assume that the margin is outside of the scope of the golden ratio. I know that I’m going to have a margin of 30 pixels out of a total width of 960 pixels. That means I need to work out my golden ratio on the basis of 930 and not 960. That gives me a sidebar width of 355 pixels and a content width of 575 pixels. OK, we’re talking about a 3 pixel difference here, barely noticeable, but still.

Anyone else have a preference on this one way or another? Or is it too anal to even care about it?!

Highlighting recent posts in WordPress is really easy. The basic WordPress index.php page does it automatically, adding each new blog post to the page as it’s written. It’s also easy to add links to those posts through sidebar widgets. It’s more difficult to highlight pages based on when they were created. Pages are supposed to be more static, so date based calls to that content is less common.

Making WordPress Look On Pages As Posts

The portfolio page on my site uses a custom template. I worked on some code to make WordPress look at new pages in the same way it looks at posts, and display them based on how recently they were created.

<?php $portfolio_items = array(
 'post_type' => 'page',
 'showposts' => 3
 );
 $posts = get_posts($portfolio_items);
 if ($posts) {
 foreach ($posts as $post) {
 setup_postdata($post);
 } } ?>

This makes WordPress pull down pages as $portfolio_items (this can be defined as anything), which are defined to render in the same was as posts. I can then define how many I want to show.

Displaying The Information On The Page

Now I need to display the information on the page (the above code makes WordPress pull down the correct information, but doesn’t display anything. I can do this by adding code in the same way as I’d display any post or page when developing a WordPress template.

<?php $portfolio_items = array(
 'post_type' => 'page',
 'showposts' => 3
 );
 $posts = get_posts($portfolio_items);
 if ($posts) {
 foreach ($posts as $post) {
 setup_postdata($post);
?>

<li><a href="<?php the_permalink() ?>" rel="bookmark" title="Link to
<?php the_title() ; ?> portfolio page"><?php the_title(); ?></a></li>

<?php } } ?>

I just want to display the three most recent pages as links in a list, but you could display excerpts from the page, full articles or any other information if you wanted.

What If The Page Isn’t A Portfolio Piece?

We’re nearly finished, but there’s one small flaw. If all I ever added to my site was portfolio item pages then there’d be no problem. The code is pulling down any new page, though, so if I add a new page that’s not a portfolio piece it will still show up. I need to limit my results to a subset of pages.

Luckily WordPress makes this easy. All my portfolio item pages are children of the main portfolio page. So I simply need to add a parameter that limits the pages that are getting called.

I need to add a new line:

'post-type' => 'page',
'post_parent' => '163', // this is the new line
'showposts' => 3

‘163′ is the page ID of my portfolio page. Obviously you would need to check on the ID of your own pages if you were implementing this on your own site.

I’m happy with the results. The portfolio page calls a simple list of my three most recent portfolio pieces, and will update that list automatically every time I add a new one.

One of the most appropriate times to use this display toggle is with the dl, or definition list, tag. It means that we can display the item with the dt tag, but allow users to expand the list and view individual item descriptions stored in the dd tag.

A Basic Definition List

The HTML for the list is very simple.

<dl>
<dt>Item 1</dt>
<dd>Item 1 description</dd>
<dt>Item 2</dt>
<dd>Item 2 description</dd>
</dl>

We’re going to use a combination of jQuery and CSS to toggle visibility for the dd content.

Hiding The dd Content

Simple CSS would allow us to hide each dd:

dd 

{ 

display: none; 

}

But we want to be able to have different dd tags toggled on and off. We’re going to do this by defining the class of the dt tags. So we’re better defining the CSS so that it specifies dd tags that are adjacent to dt.

dt + dd 

{ 

display: none; 

}

Creating The Toggle

Now we want to use jQuery to dynamically change the class of the dt, and we’ll use CSS to change the visibility of the adjacent dd.

Our jQuery is:

$(document) .ready(function() 

{ 

 $('dt') .click(function(event) 

 { 

 $(this) .toggleClass('active'); 

 });

}

Now if we click on the dt it will toggle the class “active” on and off. This lets us update our CSS.

dt + dd 

{ 

display: none; 

}  

dt.active + dd 

{ 

display: inherit; 

}

The dd is set to display when the preceding dt has the class “active”. That means when a user clicks on the dt and sets its class to “active” it will show the additional content. When they click the dt again, it will remove the “active” class and hide the dd content.

Wait, There’s An Accessibility Issue

The method works great for nearly everyone, but there’s a problem. If a user has Javascript disabled then they won’t be able to access the dd content at all. That’s because our CSS sets the dd to display: none as default. We need to fix that, and the best way to do it is to use jQuery to create a class which we use to hide the dd.

$(document) .ready(function() 

{ 

 $('dt') .addClass('inactive');

 $('dt') .click(function(event) 

 { 

 $(this) .toggleClass('active'); 

 });

}

Then we need to update our CSS.

dt.inactive + dd 

{ 

display: none; 

}  

dt.active + dd 

{ 

display: inherit 

}

If Javascript is disabled then the “inactive” class is never loaded, so all the content stays visible. If Javascript is enabled then each dt is given the class “inactive” and all the adjacent dd content is hidden. Clicking on a dt toggles the “active” class, and because that’s after the “inactive” class in our CSS, it will override it and make the relevant content visible.

That means that users with Javascript disabled will automatically see all the content when the page loads. Users with Javascript enabled will see a list of dt titles, and will be able to toggle the visibility of the dd content.

Click here to view an example of the functional code.

Edit: Apparently this has some problems in IE. For some reason, although jQuery correctly attaches the right classes to the divs, and IE identifies the correct stylesheet, the ‘click’ event doesn’t change the appearance. I’ll try and track down the problem, and write a note about the solution when I do.

Using <h1> Tags Badly

<h1> tags are commonly used as the logo of a website. They use CSS image replacement to wrap the logo graphic inside the tags. The <h1> is always the site name, whichever page you’re on. Other page headings are tagged with <h2>. The <h1> tag is not intended to define the name of a site, but the topic of a page or section. Sites that use this practice are only using <h1> correctly on their home page (on that page the site name is the main topic), but incorrectly on subsequent pages.

<h1> tags should define the primary topic of each page. Each page should have a single <h1> tag (except  in very rare situations where a single page has two equally important and clearly seperate topics).

Ways To Correctly Use <h1> Tags

WordPress

This site is powered with WordPress. On the front page the title of the site is the <h1>. On  sub-pages it’s the page topic that’s the <h1>. WordPress makes it easy to achieve this automatically.

My template’s header.php has the following code:

WordPress automatically identifies if someone is on the frontpage of my site. If they are, it wraps the blog name and description in an <h1> tag. If not, that information is wrapped in a <p> tag. <h1> and <p> tags in the “blog-title” div are styled to look identical using CSS.

I also need to define the “post” title as an <h1> in my index.php, page.php and other template files. I use a custom template for my home page. If I was using the blog index as my home page then I’d set blog entry titles to be <h2> in the index.php and <h1> in other template files.

I can ensure that the <h1> tag accurately describes the subject of a particular page in my template. I don’t devalue the search engine benefits of the <h1> tag’s weight by always using it to define the logo