Archive for July, 2010

Why I think that Graphic/Web Designers shouldn’t write HTML/CSS

Thursday, July 29th, 2010

Over the years, I’ve worked on a number of different projects, and I’ve come to the conclusion that for a reasonable size site, graphic design should be done as an image and the translation of that into HTML/CSS should be done by programmers.

This inevitably causes confusion and consternation from web designers and clients as they feel that the web designers should be writing the HTML.  I’ve put together this post to explain why I have found that to be a bad idea.

In my opinion, designers don’t tend to know how to write good, standards compliant HTML and there is no reason that they should need to.
OK, so I’m generalising a bit here, but I’ve never come across a web designer who makes neat HTML and CSS, doesn’t use table layout and validates according to standards compliance checking systems.

The thing is that designers are focused on making things look pretty. That is the way that it should be, and worrying about how they are going to implement something in HTML can interfere in that process. A good metaphor is that you don’t expect an architect to actually know how to build a house – you go to them to design a building that looks good. The builders actually translate those plans into a real life building. If the architect had to worry about where every brick was going to go, what was the best mix of mortar for this region and whether it was compliant with all the building regulations, it could really get in the way of their creative process.

Of course, there is a problem with that analogy, which is that architects do need to worry about some of the practical side of things. They can’t design a house with the front door a metre off the ground with no steps because it would make the house very difficult to access. In the same way, a good designer should either be well versed in usability or work with someone who is (frankly, they probably should be anyway, because they should be designing things to focus people’s attention on the important areas of a page). They should also work with the programmer to ensure that their design covers everything that is needed to meet any technical requirements. Otherwise you can end up with eg. not enough space for the required menu items.

Note that I haven’t said that the designer needs to check with the programmer that the design is possible to implement. The reason I haven’t is that I’ve never hit this problem and I doubt that it arises very often. HTML/CSS is pretty powerful and if you know what you are doing, you should be able to implement just about any design (of course, it might not be easy).

Designers generally don’t (need to) worry about standards compliance. You might wonder why standards compliance is important, and that is a whole other discussion, but in brief, it makes it much easier and cheaper to maintain the site in the long term, improves browser compatibility, SEO and accessibility.

Designers generally don’t think about cross browser compatibility. There are at least 4 main web browser engines these days (Trident/Internet Explorer, Gecko/Firefox, Webkit/Chrome/Safari, Opera) several versions of each and a number of less common ones. There are increasingly more and more new engines popping up for things like mobile devices (although a lot use adapted versions of the main engines too).

Another area that designers are understandably inconsiderate of is speed optimisation. Why should they have to worry about how long their masterpiece takes to load? Again, that gets in the way of creativity. Programmers can use all sorts of tricks like image optimisation, careful reuse of CSS/scripts, CSS sprites etc.

Quite apart from all this, there are practical considerations. Having multiple people working on a website can often result in changes being overwritten. I have had rarely worked on a reasonable sized website with a designer without having to re-write at least one chunk of code because they had either downloaded the entire site, changed it and put it back, overwriting my changes, or they had just been editing a file at the same time as me (in all fairness, I’ve overwritten their changes that way too).

Also, websites that have a lot of dynamic functionality use increasingly abstract frameworks (such as ASP.NET Web Forms) to deal with separating the design from the code. This makes things much easier and quicker (and therefore costs less to develop) for programmers, but it does mean that designers often can’t understand what they are looking at or how to make changes.

Now, I’m not saying that designers should never make websites themselves. Small businesses often just need a cheap website that is mostly static text and images and don’t want to have to pay for a programmer to do all the HTML/CSS properly, and in those cases, you could probably make a good case that most of what I said isn’t an issue. That’s fair enough, and if they need a small contact form or something then that’s probably not a major hassle for a programmer to do (assuming that they are hosting it somewhere that supports it). If your website is focused on functionality though, and you aren’t using an off-the-shelf solution, you are far better to keep a strict separation between coding and design.

Re-attaching SQL Server 2008 databases with Filestreams in a different path

Wednesday, July 7th, 2010

I’ve recently been moving servers and when I moved the databases, I was unable to re-attach them with a different path for the filestream folder.  The following blog post has a solution –

The Rambling DBA: SQL 2008 Filestream and Attach Database.