Christian Heilmann

Tutorial/Article writers and Bloggers: Get yourselves organised!

Monday, June 27th, 2005 at 4:46 pm

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.

Share on Mastodon (needs instance)

Share on Twitter

My other work: