coffeecoders.de » webdesign

Website Optimization Best Practices

stevie — Mon, 01 Jun 2009 11:25:33 +0000

Many new projects grow from a small base to a full blown app in time. Besides the pride of the accomplishments the developer now has to care about behind-the-scenes-stuff like page load, caching and effective webdesign to keep or improve the current speed when using the project.

Speed – or to be more precise the lack of it – is one of the major annoyances and a main reason for users to not come back. So it is in your own best interest to reach the best possible speed.

I found a very extensive list of website optimization techniques which I wanted to share with you (and to keep a link for future references). I can’t really say that by now I even follow half the list of improvements but I will certainly try to make the next app better than the one before – as always.

Link: www.chazzuka.com: Website Optimization Best Practices, speed up your website load

PostgreSQL.org Website Design Contest

stevie — Sat, 09 May 2009 17:08:34 +0000

Just a quick tip for all you designers out there:

The team of PostgreSQL wants a redesign of their homepage and started a contest to find the new look. If you are interested to win the 2000$-prize you should visit the page and get involved.

Good luck!

Link: PostgreSQL: News: PostgreSQL.org Website Design Contest

Top 10 Mistakes in Web Design

stevie — Fri, 17 Apr 2009 12:35:41 +0000

Although this blog tends to be more a developer’s than a designer’s blog most of us will have to deal with GUI-design at some point.

So these tips might become in handy if you have to design your next webapp or if you have to make another site more attractive for users (i.e. redesign/relaunch).

Enjoy.

Link: Top 10 Mistakes in Web Design Jakob Nielsen’s Alertbox.

Web browser capabilities revisited

stevie — Sun, 15 Feb 2009 23:40:04 +0000

As a web developer you always have to keep in mind that what looks great on your box not always looks that good on your client’s or on some random visitor’s screen. This is mostly because of the different browser engines and versions.

With this in mind you might tend to avoid any newer techniques, features or elements just to be on the safe side. But this also keeps you from using shortcuts and often results in worse quality.

If you planning to use a newer feature it might help if you knew which users won’t be able to enjoy your work to the full extend. To help everyone with this problem Alexis Deveria compiled a long list of the features and how are they supported by Internet Explorer, Firefox, Safari, Chrome and Opera. This list is even searchable and customizable to your needs (e.g. exclude browsers).

I can’t thank him enough for going through all that trouble finding these information and I am certain that this list will have a top spot in my future bookmarks and maybe in your’s too.

Link: When can I use… – a huge, searchable list of browser capabilities

Choosing the right DOCTYPE

Daff — Sat, 14 Feb 2009 13:59:42 +0000

I think every web developer or designer had at least one or more sleepless nights because a web page looked entirely different in all the different browsers on the market. It seems impossible to ever get rid of all the tiny and annoying differences but there are two main considerations that may minimize the effect…

1. Choosing a proper HTML DOCTYPE

The HTML DOCTYPE is a very important point to consider when starting to generate HTML output, because it can influence the appearance on different browsers drastically. There is a bunch of different Doctypes available and the most important effect is to trigger the so called Quirks mode in different browsers. Basically the Quirks mode is used to simulate former browser bugs to ensure, that pages that have been developed against these bugs are still displayed properly.
So to make sure that you won’t have to deal with these bugs choose at least a doctype from the Quirks comparison table that makes even the much loved Internet Explorer work in an “Almost standard” mode. I use to choose XHTML strict doctype

because it can be handled like a normal XML document. Let’s just hope for HTML 5 where a

is enough.

2. Make your HTML valid

In October 2008 Opera published the markup validation report showing that in January 08 only 4.13% out of 3,509,170 pages validated against their Doctype.
So even if it may sound easy, especially in larger web projects or when using HTML generating Frameworks, CMSes or Plugins etc. it is really hard to ensure that all you pages have valid HTML, but it can save a lot of a hassle. It happened to me quite a few times, that seemingly browser specific displaying errors have been caused e.g. by a misspelled HTML tag and therefore invalid HTML. For local developing I’m using the HTML Validator Firefox Plugin. It has a lot of nice features and you can see if your page validates against the W3C validation algorithms in an instant.

CSS-Reset – minimizing browser rendering problems

stevie — Tue, 10 Feb 2009 09:52:51 +0000

If you have just a little experience on creating web designs you might have stumbled upon the differences between the browser engines.

Till now you might have tried to fix every render bug after another hoping that you still can finish in time.

Eric Meyer, yes the Eric Meyer, was tired of this problem too and created a template to reset all the common differences to a certain standard. If you start your webdesign based on this stylesheet, your design should yield much fewer rendering errors and you won’t have to worry that much about the creepy IE6 or some less common browsers.

Link: Eric’s Archived Thoughts: Reset Reloaded.