Archive for the ‘Design’ Category

Consistent Designs Across Browsers

Monday, February 9th, 2009

Firstly, a caveat: I am not a designer. I am a server side programmer who dabbles in web design and development. I do not know CSS as well as someone who designs websites for a living would. So take this advice with a grain of salt.

Today @RealtorPaul asked why his site wasn’t displaying right in Firefox, when it was displaying fine in IE. This is a common enough occurrence in web design, and it’s due to the fact that different browser vendors use different render engines, and each render engine has it’s own share of bugs.

Bugs are qualified by measuring against a set of standards laid down by the W3C as a target for render engines. Among the various browsers, IE typically has the longest history of the worst standards support around, with IE 6 being the #1 criminal, and admittedly IE 7 is much better, but still flawed.

When users develop a HTML interface that they check primarily against IE, testing how it looks in IE, etc, they’ll often get a nasty shock when they check in a Gecko (Firefox, etc) browser, as their designs fall apart and generally look horrible.

While the ideal way to trouble shoot these problems is to go over your CSS code with a fine tooth comb and understand how all the various rules are working, and understand how all the browsers render those rules, that’s not very practical. Luckily, the 80/20 rule tends to come into play here, meaning the largest problems between browsers are caused by a small selection of things. Here is a list of things you can check against:

  • Do you have a valid doctype in your HTML code? A valid doctype will look like this: 
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" 
    "http://www.w3.org/TR/html4/strict.dtd">

    You can find a list of available doctypes at the W3C website. I personally recommend the HTML 4.01 doctype over the XHTML doctypes, for reasons that deserve a topic of their own. To use a doctype, put it as the first thing in every HTML page in your website.

  • Are you using a lot of padding and margins? One of the differences between Firefox and IE (just to name two) that most people hit is the difference in the box model. IE renders it’s box model incorrectly, and as a result, can cause a lot of grief when using a lot of padding and margins. 
  • Are you using properties that do not have 100% support in all browsers? Some CSS features are not implemented completely in all browsers, and their support is patchy at best. You can find a list of these CSS features at quirksmode.org.
  • Are you floating a lot of elements? Floating elements removes them from the regular flow of the page, and as a result, can have some funky results on your design. Floating elements can be awesome when you know how to use it, but can be confusing as hell when you don’t. Make sure you know what you’re doing when you float stuff.
  • Are you changing the flow of elements with the “display” property? Certain elements are block level elements (they sit on their own line, and push elements beside them down) and some are inline elements (they happily co-exist in the middle of other elements). If you’re changing how some elements display, be aware that other properties (I’m looking at you, “width” and “height”) don’t work on inline elements. Know what happens when you change how things are displayed.

Those are the CSS concepts that get me the most. Many problems are solved just by adding a valid doctype to your page, however if you’re still finding you’re having problems, give the other items on the list a look.

This list is far from exhaustive, nor is it even very in depth. However, it’s a good place to start looking, and it might point you in the right direction. With the state of the browser market as it is, debugging CSS is as much an art as creating the design for a site is.

When debugging CSS, you might want to start with just bare bones HTML, and slowly add rules as you go, and isolate that way which rules are the ones that are messing everything up. Also, keep in mind that CSS is cascading – which means you need to put your more specific rules at the bottom of your stylesheet, general rules at the top, otherwise your general rules will override your specific rules.

The best way I’ve found to debug CSS is to incrementally apply styles, and use a tool like Firebug to turn rules on and off dynamically, so you can see what happens. The most important thing to remember is that even experienced developers have to deal with browser incompatibility. If you find you’re struggling, keep at it, and don’t lose heart. It’s all part of designing a website.

Pixel Perfection is Impossible

Wednesday, February 4th, 2009

This post is an elaboration of a comment that I left on a post about CSS frameworks. I agree wholeheartedly with Joren’s position on CSS frameworks after having used 960gs for the layout of this site (at the time of posting this).. As I mentioned in my reply to Joren’s post, I used the framework to try to cut down the stress I feel when I try to make things line up properly and that most certainly didn’t work as intended.

Frustration

Specifically, I have a little widget that shows my most recent tweet on the front page, and I’m using a cute Twitter bird vector from DarkMotion.com as the background for this element. If you are viewing this post in IE, Chrome on a small resolution, and probably Opera and Safari, the bird is probably sitting obnoxiously below the recent post bar, getting in the way of content.

This little bird has given me so much grief in the design of this site, that I’ve thrown my hands up in despair and given up. The reason it’s plagued me so is the way 960gs automatically floats everything for it’s grid system. If you want to work outside the grid system, even a little bit, the framework makes you pay with blood.

I love the bird, I love showing my most recent tweet. I will not remove it. However, I can’t claim to be a serious developer, whilst still allowing obvious display bugs on the site, and I can’t bring myself to use a third-party theme to represent my personal blog. It just seems wrong.

In Joren’s post, there is an excellent comment defending frameworks, which makes mention that Joren’s blog has a 3 pixel difference in margins of the content, between the header and the footer. While I acknowledge that this wasn’t the author’s main point, it brings up something that I’ve never understood in web design, and the mentality of many web designers, both new to design and coming from print design.

A web page is a fluid medium. Web designers advocate abandoning the pixel for the em, citing greater flexibility and fluidity. So, at some level, they recognise this. However, people still insist on making designs that rely on pixel perfect precision positioning across all major browser vendors, which is where the need for CSS frameworks and reset stylesheets come from.

Web browsers are products competing in a market, and they have different ways of rendering CSS, and they have their own unique quirks. We know this, as well. Beyond glaring CSS interpretation bugs and discrepancies in box models, they have unique margins and padding on elements, and sometimes these only differ by a few pixels.

Why is this a problem?

Why do these people feel the need to contort CSS, torture it into burying these differences, into displaying  the same across each browser. There are far too many permutations of resolution and browser, not to mention whether or not someone has their browser full screened (I don’t) to try to enforce this pixel perfect design. 

Embrace the differences. Embrace the fact that your margins may not look identical. Recognise that at the design stage, and design your sites to compensate for this. Don’t split images into different elements if they’re intended to fit together seamlessly. Find another way. Don’t stress if the margin between your content and your header is 3 pixels bigger on IE than it is in Firefox. As long as the general communication goals of your design work across all browsers, and it doesn’t look like a train wreck, be happy.

I know all of this is easier said than done. I’m a server side programmer, not a CSS guru or a designer. However, I think it’s a worthy to keep in mind while designing. Don’t fight the diversity, embrace it.

Wireframe Your Interfaces First

Thursday, December 18th, 2008

As I’ve mentioned in a past post, I’m doing a rebuild of the CMS here at work and I’ve reached the point where the internals are done, and now I have to create a user interface for the application.

Now, in the past I have worked a variety of jobs and in those jobs a variety of roles. One of my jobs saw me as a web developer, like now, but with a difference: I was the only web developer.

I was responsible for quoting, requirements analysis, planning, design, development, testing, debugging, deployment and maintenance. If there’s only one thing I learned there, it was that web development is more than HTML and Javascript and a server side language, and a freelance web developer needs to know more than just programming and design.

What I really found hard was the design part.

That is, until I read somewhere that design is visual communication. Just like any other form of communication, you need to have a point, something to say. However, that point can very easily get lost in the minutiae of designing, of making sure something looks good.

I’ve found that wireframing is essential. You use the wireframe to establish the point of the page, the information that a page needs to contain, free of it’s appearance. You use the wireframe to tweak the structure, to experiment with different work flows. When you’re done, you go over the top and start designing.

Wireframing has enabled me to quickly build a general structure for a user interface, concentrating on the information and tasks that interface needs to perform.

I wireframe with Balsamiq, which I’ve found to be an excellent tool. You can try it out indefinitely on their site, fully functional, and all it costs is pop-up every 5 minutes asking you to buy it. I’m recommending we buy at least one copy for work, and I recommend you check it out if you want to make effective applications.