I hate The Scorpions but I can feel a wind of change. While there was many a flamewar on mailinglists, forums and chatrooms in the last few years it seems that we finally realised that airy designers, dysfunctional developers, usabilitistas and accessibility zealots actually all have the same goal: Delivering good, successful web sites

The recipe for those is easy:

• Solve problems the user has
• Offer content the user wants
• Deliver it in a slick and beautiful fashion
• Make it darn easy to use
• Make sure it works at least on the basic level for everybody

Now, whoever claims to be able to do all of the above is either highly gifted or a stinking liar.
Therefore we need to hop on our toes and glance over the garden fence to see what the others do, the finger painting kids one side, the ones building huge sand castles on the other, and the ones feeding the sandcastles to other kids and write down their impressions on a piece of paper in the last garden.

The other problem with our pie in the sky wish list is the harsh business world:

• The user issues are assumed by marketing (“They want to buy our product, everybody needs it”)
• The content is provided by business (“We got lots of material, our newspaper press releases from 1981 onwards and all our business case papers, 430 pages each!”)
• The design is defined by the 1962 guideline for internal memos or the new 3D logo creator of the CEO’s son
• There is no feedback on how hard it is to use the site, visitors just leave and the developer gets blamed for being crap at SEO.
• The stake holders heard of accessibility and know it has something to do with putting an “AAA” banner on the site or get sued.

So there – we are a bit stuck. But that should not stop us from learning and sharing, because if we ever get to talk to a stakeholder with him/her listening (wedging them in toilet doors is an option, or stealing the TP roll and make them listen till we give it back), we better have some good material based on facts at hand.

But oh, woe is us – when we look around for good tutorials we will find a lot of material written by someone of group A for group A, B for group B and so on…

• Design tutorials talking about typography and colours and harmony not considering the restrictions of the web
• Scripting tutorials with yet another foo(bar) example with no real-life connection
• CSS tutorials assuming everyone uses Opera or Firefox
• Accessibility tutorials that look like someone forgot to connect a style sheet, just to find out there is actually one, but it looks just like the browser standard.
• CSS or scripting tutorials showing that it is possible to do something that was meant to be achieved by the other, or even by HTML.

What we need is better tutorials, aimed outside our area of expertise and delivered slick, painless and with a practical use. Collaboration is the key to that.

• Scripters should liaise with designers to get their code examples designed in a nice fashion and their articles re-edited to make them understandable to somebody who does not consider regular expressions a valid mean of communication
• Designers should liaise with HTML developers, scripters and accessibility gurus to see if what they want to achieve is feasible and where the pitfalls are.
• Accessibility and usability people should get input from designers to understand why some things were designed the way they are and find a consensus, and to get help making their own texts prettier and illustrated.
• Everybody should grab someone outside our world and see if the things we write are understandable

This all should not be restricted to our blogs, but should also happen before something gets published in web zines. While a lot of editors of web zines are great writers and know a lot about getting messages across, their technical knowledge might be limited. Not all of them employ or invite technical reviewers and experts and that is why we end up with a lot of tutorials that are buggy or flat out wrong and yet very successful.

So please, think a bit before submitting the next article and get some more people involved to sort out the issues and add the nice wrapping paper before giving your ideas to the public.

Things that are not helpful and have to go:

• Bleeding edge tutorials working in a small environment advertised as a cool new feature rather than an experiment
• Scripts for their own sake – without a real business task at hand (business stakeholders would never ask for coloured scrollbars if they hadn’t seen them somewhere)
• Untested functionality breaking in a big percentage of the browsers in use or in modern browsers
• “Hey I can do in X what we rightfully did in Y for years” tutorials
• Tutorials with examples focused on one level but violating the other two badly – if you want to explain a cool JavaScript idea, make sure your HTML is semantically correct, validates and you leave the styling to the CSS.

“Don’t judge a book by its cover” is a nice idea, but that is exactly what people do, so let’s sell standards based development as a nice shiny and easy to grasp parcel, rather than a bit of string, some crumbled wrapper and a almost unused box.

I bounced the following idea off some people at @media (Douglas Bowman, Molly and a lot of others) and I am ready to go along with it. It’d be good to hear some thoughts though:

We all know and love CSSZengarden. It showed the design community what can be achieved with CSS and how easy it is to redesign a web page completely, simply by applying another style sheet.

However, for our day to day web development life, the garden has become a bit of a problem, mainly because:

• The designs have become an image replacement competition instead of testing what CSS can do
• It is too easy to style only one document that has been marked up with loads of IDs and classes – in the real business world we’ll have CMS defining the content markup and we don’t have that option
• The focus seems to have shifted from style and functionality to style/brand on its own.

My idea now is to start a CSSFactory. The idea is the same as CSSZengarden, the difference though is:

• The Markup will be a 5 page web site with different layouts and content for each page
• The Markup might have variable content order on reload to simulate a CMS that allows editors to rearrange them
• The content will be available in English, German and maybe French (I’d need help with the French – Stephane?)

That way we can prove that it is possible to create bullet-proof CSS that can be applied to real life web sites, and maybe get a bit more buy-in from project management and managements when we try to advocate standards.

Comments?

14.07 Changes

Ok, I realise that some of the bits mentioned here confused people, so here are some extra explanations:

• The JavaScript is only an idea to simulate how a real backend would allow editors to change the content. I intend to use it to avoid the need to reload the pages from the server each time. Saves me server traffic and you time during development. I develop and write most of my hobby works (like this idea or the unobtrusive JavaScript course) on the tube whilst commuting every day, I thought it’d be handy to show how flexible CSS is without the need to run a localhost with PHP.
• The random order of course will only apply to the content slot of the template. Much like we do for most clients. One of the basic princibles of accessible and usable sites is that we keep the navigation on the same spot throughout the site, moving it would be counterproductive.
• I started on some of the markup, but want to get an offline version of the course and the linkrot prevention idea out of the way first. I also wonder if I should get a dedicated server and domain or use this one instead.

I must have been kissed by a Muse at @media, because I had another idea, that I’d like to get help with.

The problem

• There are far too many outdated, obtrusive and plainly badly written tutorials and scripts out there
• As they have been around for a long long time, they are ranked very high in search engines, and new, interested developers will find them instead of The Good Stuff™.

The dilemma

As the developer or writer of these scripts and articles, you do have the choice of the rock and the hard place:

• You hardly have the time or the inclination to rewrite the articles, sometimes they have been published by a third party and you cannot do that.
• You don’t want to delete them, as you do get visitors, and they might be persuaded to explore your publications more and find The Good Stuff™.

One solution

What I thought about, and many people at @media agreed is that there should be an option to keep these scripts and tutorials for achived reasons and tell the visitor about The Good Stuff™
The idea is to set up a service, which I intend to call Obsoletely Famous (yes, I miss Futurama), which is basically a RSS feed listing good, modern articles and resources for the topic at hand.

(Basically a pre-filtered del.icio.us, as many people linking to it sadly enough does not necessarily mean it is a good quality resource, it is simply popular, probably by oversimplifying the issue at hand. A good example of that are a lot of ALA articles, where the real good information ended up in the comments, but not many users go there)

As the developer / maintainer of the script you can set up a bridge page (or a custom error page) that tells the visitor that the above was fun while it lasted, but the list here actually shows better ones.

The benefits

• We re-use the high google ranking to promote The Good Stuff™
• We help writers and scripters / developers to back off things they are not proud of any longer without giving the visitors alternatives
• We ensure that newer users find The Good Stuff™
• New writers of The Good Stuff™ can easily reach more people

The plan of action

Give me the bricks, and I’ll build the house

Basically, we need to identify our areas of expertise and define The Good Stuff™ links. Then I can set up the RSS feed and create some example bridge pages. In the long run, I might persuade my evolt colleagues to host it.

Areas covered:

• JavaScript
• DOM JavaScript
• CSS
• HTML
• Visual Design
• Usability
• Accessibility

We can start by listing some here in the comments.

Check your own stuff

• Let’s all go through what we have online and see what is a possible candidate for becoming obsoletely famous (I know for a fact that 75% of my onlinetools.org is). Squint your eyes and look at it in a menacing way – make it aware that its days are numbered^*
• Scan your bookmarks for good, modern tutorials and name them here.

^* optional

There has been quite an interesting thread on css-discuss about solutions how to make a blog post construct like

headline
date
text

link. In compliant HTML you cannot nest block elements in a link, therefore you would need to repeat the link three times – one inside the header element and two inside the paragraphs for date and the text. This poses an accessibility issue of three links to tab through / listen to / appear in the document’s links list.

Ingo Chao came up with a pure CSS solution.

The only problem with that one is that the link text will be just far too long, and you have no structure in the text any longer.

I decided to harness JavaScript to do the dirty work.

After all the feedback for the Star Trek CSS navigation I played some more and thought of a osX dock style navigation much like the googlex but without images.