Real World HTML5 (#lwsworld) Live Blog

by edds. 0 Comments

Lightening Talk kicked off with a highly entertaining talk from Peter Fletcher (@joyfeed) about recording his sneezing and what effect this has on his life.

Marcus Alexander: the search for quality

19:31: going to talk about what it is like actually working with clients.

What is quality? Quality is sometimes not immediately obvious.

How can you test code for quality? 4 different JavaScript code examples which would you pick? Each have their own plusses and minuses. Quality is not just meeting the requirements.

Client’s requirements are usually very different from that of the developer. The actual tech portion of their requirements are much smaller than those of the developer.

Get everything agreed with the client and you will know what the requirements are. At least you have one version of the requirements, but they might change at some point.

Sometimes when a client gives you something you don’t want to do you might have to “choke on” requirements you don’t want to do.

Planning is important. There are external factors and other people that might add to the initial time estimate. These have to be factored into the original project plan. Understand what goes on before and after the building stage.

If you give a client a website it will be completely vandalised within a week when they decide to customise it. Their customisations aren’t always pretty but it’s their site after you hand it over.

If you know what might change when you are initially coding a site you can code around it and make things easier to change.

You can make your life easier by using things like quick links to parts of the site you use regularly. Build/deploy scripts can save you time by exporting neat packages and compiling CSS/JS for you.

If you have coding/development standards you need to be able to justify them. Standards save you pain in the long term.

Bugs: you spend most of your time fixing bugs. They are not all your own bugs. Sometimes it is not very easy to reproduce bugs. Most bugs are duplicates or things that are unpublished requirements. Some bugs are ok to ship with.

The user is not the enemy, the client is not the enemy. Don’t worry about it, it might not go live. Don’t expect clients to understand.

Arron Ross-Patterson: Should we validate?

Why validate your code? The only real reason is for superiority problem. You should probably spend more time working out what your code rather than obsessing with validation.

Accessibility: alt text helps accessibility right? Should images have alt text can they really represent what the image says? They usually can’t. That information should be in the body copy.

Tables: other tags really aren’t all that semantic. Displaying a calendar is fairly hard and most HTML elements don’t really fit. The one that does is a definition list but they are an arse to style. Microformats are a massive bloat and slow page download times. So should we use them?

Some things that don’t validate are still very much semantic. The internet is evolving and we can’t always take those articles as the be all end all.

Always question the code. Does it work in everything as this is often more important than validating.

Q&A

Arran: no method of trying to dispaly some data is ideal

Should we aim to validate? Validation doesn’t mean that we are being semantic. Validation is a tool that we should be using as part of our toolset, but we should know why we are doing something.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

HTML tags are not allowed.