The road to professional web development

Christian Heilmann | http://icant.co.uk | http://wait-till-i.com

Taipeh, Taiwan, April 2009

Hello and thank you for being here.

I am Chris...

...and today I will talk about the road to professional web development.

You cannot look forward without learning from the mistakes of the past.

Otherwise you are very likely to repeat them.

So let’s take a look at the past of web development.

The Dark Ages

http://www.flickr.com/photos/25725360@N05/2929959881

In the beginning there was HTML.

It structured text into headings, lists and paragraphs and linked documents with each other using anchors.

This was good, and quite a revolution...

...but also very, very boring.

People wanted colours, different types of text, borders and images.

Which lead to the next step.

The first mistake:

Presentational Markup

Adding bgcolor, color, <font>, border, hspace, vspace,float and all other presentational HTML allowed us to style the document.

It doesn’t allow you to style a whole site though.

If the design of the site changes, you needed to change each document of it.

However, as sites were small this was not a problem – yet.

Design was still limited to a single column.

Until people realised that you can use the <table> element to create multi-column layouts.

And it was *so* easy.

..if you knew all the problems that different browsers have with showing the table properly.

<table width="500" border="0"> <tr> <td width="1" bgcolor="black"><img src="spacer.gif" width="1" height="1" alt=""></td> <td width="10" bgcolor="black"><img src="spacer.gif" width="10" height="1" alt=""></td> <td width="118" bgcolor="black"><img src="spacer.gif" width="118" height="1" alt=""></td> <td width="10" bgcolor="black"><img src="spacer.gif" width="10" height="1" alt=""></td> <td width="300" bgcolor="black"><img src="spacer.gif" width="350" height="1" alt=""></td> <td width="10" bgcolor="black"><img src="spacer.gif" width="10" height="1" alt=""></td> <td width="1" bgcolor="black"><img src="spacer.gif" width="1" height="1" alt=""></td> </tr> <tr> <td width="1" rowspan="3" bgcolor="black"><img src="spacer.gif" width="1" height="1" alt=""></td> <td width="1" rowspan="2"><img src="spacer.gif" width="10" height="10" alt=""></td> <td width="1" colspan="3"><img src="spacer.gif" width="1" height="10" alt=""></td> <td width="1" rowspan="2"><img src="spacer.gif" width="10" height="10" alt=""></td> <td width="1" rowspan="3" bgcolor="black"><img src="spacer.gif" width="1" height="1" alt=""></td> </tr> <tr> <td>Navigation</td> <td></td> <td>Content</td> </tr> <tr> <td colspan="5"><img src="spacer.gif" width="1" height="10" alt=""></td> </tr> <tr> <td rowspan="7"><img src="spacer.gif" width="1" height="1" alt=""></td> </tr></table>

Navigation Content

Also: what do you need to do when the navigation has to move to the right?

The solution was to separate the presentation from the structure.

CSS

CSS allowed you to define the look and feel in a much more detailed manner.

CSS is defined once and applied to as many documents as you want.

So moving a navigation meant changing a single file.

However, the problem was that developers wanted more and more and the standards took too long to agree on.

Browser Wars

http

://w

ww

.flic

kr.c

om/p

hoto

s/71

8956

5@N

07/3

2791

7817

6

As browser makers were in fierce competition this lead to non-standard extensions to both HTML and CSS.

This, together with more and more support for JavaScript in browsers lead to another dark period of web development.

DHTML Hell

http://www.flickr.com/photos/19703909@N00/3411843177

Using DHTML (JavaScript controlling visual changes in the document) we went nuts.

Moving and scrolling and JavaScript dependent navigations.

Blink, Flicker, Crash.

The biggest issue was that we tried to support every browser the same way.

Which is why one group stood up and put a stake in the ground.

WaSP – to hell with bad browsers.

The work of the WaSP and many individual trainers,

writers and developers made web standards a good idea to

follow and understand.

Which made a lot of sense.

As the first .com bubble collapsed people spent much less money on silly web sites.

Instead, they wanted easy to maintain, extend and change

web sites.

This meant also that people didn’t want JavaScript

solutions any more.

We did our best to make people understand that –

used the right way – JavaScript is not evil.

Unobtrusive JavaScript

http://www.zhuoqun.net/html/y2008/1103.html

http://icant.co.uk/articles/seven-rules-of-unobtrusive-javascript/

However, the painful memories of DHTML hell were

still hard to forget.

Until the next revolution came.

var request; try{ request = new XMLHttpRequest(); }catch(error){ try{ request = new ActiveXObject("Microsoft.XMLHTTP"); }catch(error){ return true; } } request.open('get',this.href,true); request.onreadystatechange=function(){ if(request.readyState == 1){ output.innerHTML='loading...'; } if(request.readyState == 4){ if (request.status && /200|304/.test(request.status)) { retrieved(request); } else{ failed(request); } } }

AJA

X

Ajax meant that web sites are fast, easy to use and highly interactive.

And it works by using JavaScript.

The new interest in JavaScript helped us go out to the world and tell it how you can use JavaScript together with web standards and create amazing experiences.

To make this work, we needed a buzzword for “new JavaScript”

DOM Scripting

However, the idea of unobtrusive scripting and web standards development became a bit forgotten because of yet another revolution.

WEB 2.0

http://www.flickr.com/photos/brownpau/198591442/

WEB 2.0 meant that users are creating the web they use.

Everything had to be highly interactive and Ajax is not even a nice-to-have but a main goal.

So this is where we are.

The mess we have to deal with.http://www.flickr.com/photos/28114609@N05/3433642297

The Ajax revolution and the Web 2.0 move set high expectations.

Users expect web sites to be highly responsive and working like real applications.

However, we are still working in browsers and on the web.

Ajax driven web sites do not reload the whole document.

This breaks a lot of things.

No bookmarking.

No back button.

No interaction with assistive technology.

To make our products work, we need to know a lot of things:

the technologies

how browsers fail supporting them

how users interact with systems

what people use

The problem is that most likely you won’t have the time to do all that.

The other problem is that as individuals we are likely to find solutions for our problems but not for all of the possible ones.

For this, we need to collaborate and compare our findings.

We also need to be careful not to repeat the mistakes of the past.

Working on a solid base

It is not about technology.

You do not work to satisfy browsers.

Standards only make sense when they offer an easier way of achieving a goal and if they have support in the real world.

As a developer, you should work first and foremost for the user of your products.

The second most important person to work for is the developer that takes over from you.

The easier the interface, the more people will use it.

In order to make web development a professional choice we need to act like professionals.

This means that instead of getting excited about hacks and quick solutions we should concentrate on other goals.

Does it work for everybody?

Is it easy to change?

Is it a smooth experience?

Does it make it easier for users to do what they want to do?

Here’s the good news: we are almost there.

Web development libraries like jQuery, prototype, mootools, Dojo, YUI... are there to help you do your job.

These libraries are all open for you to feed back problems and contribute solutions.

They are a much sturdier base to build on than browsers and their current documentation.

One base to work from is YUI:

http://developer.yahoo.com/yui/

The Yahoo User Interface library was build to make it easier for Yahoo developers to build our products.

Working with as many locations, products and people as Yahoo does it is the only way to keep a constant high quality.

With that many developers at hand we were able to build a great library based on solid principles.

When we build products, we test them with users and see what they want.

Analyzing this we came up with usage patterns, which are available to you.

http://developer.yahoo.com/ypatterns

They even come with stencils for your designers.

http://developer.yahoo.com/ypatterns/wireframes/

One thing we needed to do is to define what browsers to support and what “support” means.

http://developer.yahoo.com/yui/articles/gbs/

Support is not giving every browser the same experience.

It means using what the browser can reliably do and not making it reach what it cannot do.

This is the main principle of progressive enhancement.

We must build products that work, and only work more smoothly when the browser in use allows for it.

Without JavaScript With JavaScript

http://developer.yahoo.com/yui/examples/autocomplete/ac_basic_array_clean.html

Without JavaScript

With JavaScript

http://developer.yahoo.com/yui/examples/datatable/dt_enhanced.html

We used the design pattern information and built widgets that work this way.

We test them across the supported browsers to make sure they work.

http://ui.jquery.com/

http://ui.jquery.com

Using these, you can build applications that work across all the browsers supported by the GBS.

We provide the bricks, you build the product.

http://www.flickr.com/photos/seven13avenue/2080281038/

All of the widgets can be extended and styled the way you want them to.

http://developer.yahoo.com/yui/articles/skinning/

You can extend the widgets by listening for events that happen to them.

http://developer.yahoo.com/yui/examples/autocomplete/ac_basic_xhr_log.html

If you don’t want to use the widgets, you can use the helper libraries that we use to build the widgets.

These do the same thing, but on a code level. They make web standards work across browsers (DOM support, event handling).

If all you need is creating CSS layouts that work across browser land, there’s that, too.

http://developer.yahoo.com/yui/grids/builder/

Even for *very* lazy developers:

One other thing we do is make web development less random by providing testing tools.

All of this is open source, fully documented and you can either host it yourself or get it from a high speed distributed network (even Google’s).

Practices we follow:Progressive enhancement

Standards compliance

Code validation (JSLint)

Extensibility

Modularisation

Documentation

Even if you don’t want to use anything we offer, these are good ideas to use in your work.

Don’t become a part of the group of developers that leave behind unmaintainable products.

Another thing to consider is how your products perform.

Fast and smooth products make users happy.

There’s a lot of good information available at the exceptional performance site.

http://developer.yahoo.com/performance/

All of which can be tested using YSlow.

http://developer.yahoo.com/yslow/

One final thing we’re working on a lot is accessibility.

http://yuiblog.com/blog/category/accessibility/

This is all I have time for today, so thanks again.

Check out the bookmarks on the last page for lots of good tutorials and documents.

Two of mine were even translated:

http://www.cn-cuckoo.com/2007/08/14/unobtrusive-javascript-progressive-enhancement-gracefully-degrade-82.html

Two of mine were even translated:

http://www.zhuoqun.net/html/y2008/1103.html

Christian Heilmann

http://icant.co.uk

http://wait-till-i.com

http://scriptingenabled.org

http://twitter.com/codepo8

T H A N K S !

http://delicious.com/codepo8/taiwantrip