Bobby Wilson

Quick Note

I thought it would be fun for me to do a critique of a website that I found in a “review my site” forum. I didn’t pick this site for any reason in particular, and I don’t personally know the designer/developer. I am going to try and do these semi-regularly to keep myself sharp, and to provide constructive feedback to those looking for reviews.

Site Introduction

The website I found to critique is http://www.townofgrandfallswindsor.com/. I found the site in the “Review My Work” category of the Freelance Switch forum. link

Standards

The first thing I always check when critiquing a website is standards validation. I don’t necessarily care what standard the designer chose to use, but I hold web standards in high regard. I go right to the W3 Validator to validate the site. The designer in this case chose XHTML 1.0 Strict, a fine choice. The site does not validate as of today, with one error, “there is no attribute “target”". In all of the “strict” specifications there is not an attribute of “target”. However, in XHTML 1.0 Transitional specifications there is. The way to stay strict in this case would be to use some javascript to open the link in a new window. That was the only standards concern, so we can move on to the next section.

Information Architecture

Information architecture is the bread and butter for SEO. To get a good idea of information architecture I turn off the style sheet. Doing so lets you see a nice hierarchical view of the site as far as information goes. If the site is well designed from an information architecture point of view, it should be organized and easy to read. This is also a good time to see the content by itself. This site starts pretty well, you get an <h1> of Grand Falls Windsor, which is the town that the site is about. I expected there to be a hyphen between the “Grand Falls” and “Windsor” because that’s how it is everywhere else. You a <ul> of navigation, pretty standard. Moving down, you get a teaser of copy, then an <h2> of “Reasons you should visit Grand Falls-Windsor”, followed by another <ul> of four reasons. Then, something very disappointing happens. Without any sort of separation from the reasons to visit Grand Falls-Windsor, there is a giant <ul> of links that have to do with different aspects of the town. I would have like to seen categories, or something to break down this large list of links. Below that there is “August 2008″ followed by all of the dates in august. I would have opted for a table in this case, because this is one situation where I would want the data represented in tabular form. After that there is “Upcoming Events” with an event underneath that, perfectly fine. “Latest News” with a news item. An “About Us” with some copy, and a “Links” section with a few links. Lastly a copyright notice. Nothing to complain about at the bottom, I sometimes wonder if “links” could be a more descriptive name in these cases, but it is very minor.

Layout and Design

Header Graphic

The first thing I notice when I arrived at this site was the large feathered image at the top. The page loads a random image/collage every time you refresh the page as well. After a few clicks on refresh I am undecided about whether I like this or not. Generally I don’t like the feather effect, and I think it goes back to looking at my high school yearbook with a feathered collage of pictures every other page. This is one of the better examples of feather I have seen though. The other comment I have about this header is the varying quality of photography. Some of the photos are interesting, high resolution (for the web), and colorful, while others are either pixelated, dreary, or just not very interesting. Another thing I noticed about this header graphic is that sometimes there is a translucent gray bar underneath the typography and other times there isn’t. I think it should always be there especially when using white text. The crest next to the type is also blurry, low quality, and doesn’t stand out like I think it should.

Navigation

I like the design and color choice of the background of the navigation bar. The pinstripes are a nice touch, what I don’t like is the cut-outs in the corners that look like they were done with a small eraser tool in Photoshop. I think I would like the cut-outs if they were a clean sharp curve. I also notice that there is no indicator of which page we are on with the menu items, clicking “HOME” also reloads the page even if you are home. The navigation is also somewhat deceiving, the only thing that changes upon click is a sub menu on the right hand side. This is somewhat odd behavior to me because I expect new content, especially from primary navigation. I noticed that this was an XHR request, so I turned off javascript to see if he was degrading gracefully, and BAM! exactly what I was initially looking for. Individual pages per navigation link, this couldn’t have made me happier. As well as there being a separate content page, we also get to know where we are. This is awesome, I would like to see similar behavior with the XHR requests, make me feel like something happened when I click a link, and tell me where I am once I do that. I think even minimally adding a header to the top of the sub menu would make me happy, telling me what the category the links are.

Calendar

I think that calendars can be very useful, if they are used. I do find the background graphic of the calendar distracting. It bothers me when something should be a bit distorted because of it is on a curved surface but isn’t, like the dates to the lower right corner. To me the graphic somewhat cheapens the calendar because of its low quality.

“Idea Garden”

There is the second feather job I have seen, and this one I don’t appreciate as much as the first one. The first thing I notice is that the white box below show be above the feathered image, not below it. The copy also doesn’t makes sense to me, it seems it should just be a contact us, like the page title says when you arrive there. This link could also fit into the primary navigation at the top, as it is a something that people come to look for. I also question the choice of the green in the link color, I don’t know where it fits in, in the color scheme.

“Reasons to visit Grand Falls-Windsor”

I think this section is pretty effective. The title is bold in color. The points have nice spacing and typography. The added detail with the unique bullet is nice.

Footer

The footer is another feathering. I am over-feathered at this point and I don’t think the translucent gray box helps at this point. The three columns isn’t bad, and I think it works here. The yellow headers are a bit much, and I don’t think they compliment the background color. White text as body copy is a tough call, it is always hard to read especially in a seriffed font, on top of an image. The email address link in the copy is unreadable to me. I think the photography feels a little forced, and I am fine with just plain text. When there is text my first concern is reading it, don’t put it on top of an image please.

Overall

I think this site is a strong, pretty effective design. I like the general color scheme, tan, red, blues, white. There is a few single instances of colors that I question, and I would like to have been something that fit a little better in the scheme, but nothing major. The typography is nice, it left me wondering what it was, and I think it fit the style of the site. The feel was classic, symmetrical, rich, with nice details. I am just noticing that I might have like to see what the menu looked like with a detail either side of the text instead of just the left. The site was also very close to being strict XHTML 1.0, with a minor change it will. I like the progressive enhancement with the javascript, without the javascript the site is still intact. I think the people of Grand-Falls Windsor will be very happy with their new site.

Further Critiques

If you want me to critique your site, leave a comment letting me know that you are interested. I will contact you and get you on the list for next time.

Are you serious?

Yes. Absolutely yes. Static content is the lightest, easiest, and fastest content on the web. There was a time, when I was all about the latest and greatest in CMS technology. I have spent many a hours trudging through the bowels of Joomla, Drupal, and Mambo. Slashing the foliage of MovableType, Mephisto, Typo, and Wordpress with my machete. All because I needed the most flexible, extendible, hackable, and mashable solution to manifest my off-the-cuff projects.

Why use plain ol’ static pages?

The first reason, is that static pages “just work”. Yeah, you can make typos, mismatch markup, and break links, but even with the most abstracted CMS these issues still exist. With static pages, there is no “moving parts” so to speak.

Automation

Static content doesn’t mean you have to write out every single piece of HTML by hand. In fact, there is excellent software that you can run locally to build shared layouts, generate blog entries, and leverage dynamic templating. You run a build command and the software pumps out static pages ready to upload. You can even automate the upload/syncing process.

It’s cheap!

You can sign up for the least expensive hosting package, and that will work just fine for a very long time. It’s cheap in terms of resources too, web servers (software) are usually very light weight. Storage and bandwidth will be the only variables you have to worry about. Storage is not a problem, scaling storage is easy and relatively inexpensive. Running out of bandwidth means you are transferring a lot of data, which is usually a good problem (people are visiting your site). Maintenance is minimal, you still need to call your web guy to make edits and updates, but problems will usually be simple fixes.

SEO

Static content is ideal for SEO, the search engines see everything just as it is, plain ol’ static HTML. Search engine spiders were built with static pages in mind. The spiders can quickly and easily parse through all of your pages without a hangup. In terms of SEO, nothing beats static content.

When static pages won’t cut it

Web Applications

There are plenty of situations when static pages won’t cut it. In terms of web applications you are out of luck. Even the most simple applications use some sort of dynamic technology to exist. Every form you see uses a dynamic technology to process the information. That isn’t to say that you must say goodbye to static pages. Applications can still have a large amount of static content.

What about blog?

Blogs can be pulled off with static pages, and I am still intrigued by the idea. With a static blog, you don’t get the administrative dashboard, you don’t get plugins, and you only kind of get comments. Why am I using this database driven blog software to run this site instead of generating static content locally and syncing it up? One of the few reasons that I am, in fact, using a dynamic blog engine is because of comments. There are ways to have comments without using a database, but it wasn’t compelling enough to me. I also like the web interface that lets me publish from any computer with internet access.

Conclusion

Static pages are great because they are quick and easy to create. They are ideal for sites that showcase a company or product. Some clients might ask if they will be able to edit a page, and you will tell them no. The truth in this situation is that aside from just plain body copy, a client won’t really know how to change anything else even inside a CMS. I would prefer to save the upfront hours I would spend setting up a CMS and spend them on these minor updates and changes. Static pages stay completely usable even if you do decide that you need a little more infrastructure, you just pop them in as pages in your new CMS.

Resources

Ruby static page generators

• webgen
• webby
• nanoc

Introduction

If you ask any web designer what tool they use most in their web design toolbox, most will tell you Adobe Photoshop. Web designers love Photoshop because they can use a familiar image manipulation program to create a very colorful, graphical, photo rich website comp in a day. They show the client their comp, and the client gets the idea that the website is almost done, since they can see how the finish site should look right in front of them. The client is perplexed when you tell the client there is still a lot of work to do before the site is finished. The web designer sends you a “sliced” comp and their work is done.

Problems

The problem with a sliced Photoshop document is that everything is a graphic, the body text, headers, and menus. There is never a situation where this is acceptable. Even if you are making a single page that will only be up for a limited time, you will still at minimum want your page copy to be indexed in search engines, and the flexibility to edit the copy just in case there is a typo.

Usability / Accessibility

Anyone with a disability will struggle to view your page correctly. Users won’t be able to enlarge text, and a screen-reader won’t render the image text. The image text isn’t selectable for reuse. The web site won’t feel like a website because it is all graphics.

Information Architecture

When you comp with HTML you get a very nice representation of content hierarchy. The actual content of the site will be right there in black text and you will see the page for the content, and it won’t be able to hide behind a stylized graphical comp. This is essential at this stage because it keeps the content in check.

SEO

Any well designed site should be able to have the style sheet and graphics turned off and still function very well as just HTML, after all this is how the search engine bots see it. As an exercise turn off the style sheet and graphics from a sliced Photoshop document, and open that up in a browser, how does it look? As mentioned before, search engines won’t index image copy making your site poorly indexed, or invisible to them.

Development

When Photoshop comps are used just as a starting point for the actual markup and style-sheets, very little of the Photoshop comp even ends up in the finished site. The graphics that were formerly the body text are replaced with paragraph tags and actual text. The headers are replaced with actual heading tags, and menus replaced with list tags. Having actual markup and CSS instead of a sliced up image, will make it much more flexible. If you need to to make a change to the copy, you just make a change to the copy, instead of tracking down the Photoshop document editing the text and re-exporting the page.

Solutions

HTML from the start

You can use HTML from end to end. As a developer it is much easier to work with HTML created by the designer, rather than fixing the HTML that Photoshop generated, or scraping all of the generated HTML in favor of writing your own much cleaner HTML.

Client Presentation

When the designer does show the HTML comp to the client, the client will be correct in thinking that the site is almost finished. You will also be able to post the HTML comp on the web so that your client can look at the site in an actual browser instead of looking at an image file that may or may not be the actual size of the site. The more you can show your client the site in the browser the better off you will be. They will see the site in the context of a browser instead of removed from context as a graphic. The changes they request will be easy to fulfill as HTML.

Old Workflow

1. Designer hops into Photoshop starts creating their layout and graphics
2. Designer pastes in the copy from the client, or lorem ipsum if they don’t have copy
3. Designer saves out a Photoshop document comp and shows the client
4. Designer gets back into Photoshop to make the changes the client asks for
5. Designer saves out another Photoshop document comp and shows the client the new changes
6. Client finally approves the design
7. Designer hands off sliced up Photoshop document to development team
8. Developer turns the Photoshop generated HTML into something they can actually work with
9. Developer finds a typo, and tells the design team
10. Design team gets back into Photoshop to fix the error and then re-generate their Photoshop document
11. Developer puts graphic back into HTML
12. Developer shows designer the current state of the site
13. Designer wants to know why it doesn’t exactly like the Photoshop document they gave the developer
14. Argument continues, ultimately going nowhere… Leaving the designer and developer to go back and forth for almost all design changes
15. Client is disappointed with the wait every time something needs updated

New Workflow

1. Designer starts with copy from the client, or lorem ipsum if they don’t have copy
2. Designer structures the site with HTML using the proper markup for the respective content
3. Designer shows client current state of design, and explains that this is just the information architecture of the site but thought the client should understand, and provide feedback just based on the current hierarchy
4. Designer can hand off what they have to the developer to begin doing back-end work because it is HTML already and easy to change
5. Designer begins to work in styles, images, and any client feedback thus far
6. Designer shows client current state of design with styles, images, client changes, and maybe even some of how the back-end will work since the developers have already been working on their part
7. Designer can continue to work with developers to fine tune markup and styles, because they know HTML so well now
8. Developer finds typo, and changes it right there, after all it is just text
9. Developer shows designer current state of the site, and says, “it looks exactly like your comp”
10. Designer says “Duh, I wrote that HTML“
11. Client loves the speed at which the team works

The first workflow is actually how I have worked before, no joke, it seems funny to read, but that is really the way things can go sometimes. The second workflow is pretty realistic, when your designer knows HTML and CSS very well it creates a great collaborative environment between designer and developer. It lets both parties speak the same language and should speed up your workflow a lot. Designers will no longer complain about their Photoshop comps being trashed when the developers get ahold of them, because they will be writing the exact HTML that the developers will use. You can put the design on a web server immediately since it is already HTML and give your client a view of the site in an actual browser, the way the finished product will be. This can sometimes be a bit of a jump for the client if they always see the comp as a printed out image, or in image preview software.

Conclusion

It just makes sense to use HTML from start to finish. When you start with something usable you can just build upon, and manipulate that instead of always going back to Photoshop. Designers will also become better designers because they will be using the rules and standards of the web instead of Photoshops rules and standards. They will realize their limitations from the beginning. Photoshop gives you way more options than are possible on the web, so when it is exported for the web it doesn’t look how you plan it to, and just wait until you pass it to the development team. Photoshop is great for manipulating images, creating graphics, and layouts for print. Still feel free to use it to create graphical elements for your sites, but just leave the layout and styling to HTML and CSS.

Resources

• 37signals - Why We Skip Photoshop