Archive for May, 2008

@media session 11

Friday, May 30th, 2008 at 4:21pm

Global Design - Characters, Language & More

Richard Ishida

Richard is the W3C’s Internationalisation Activity Lead.

Character Encoding

  • There are many options, but Unicode is the best - it supports many languages in a single character set - making it easy to architect multilingual solutions, and have a mix of languages on a single page (if required).
  • Makes storing and retrieving multilingual data in a database much easier
  • Also provides extra characters such as © ™ etc
  • Has wide support in browsers, scripts, editors, databases etc.

You can declare the encoding in the HTML:

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />

Or if you’re using XML:

<?xml version=”1.0″ encoding=”UTF-8″?>

Databases must be told to save data as utf-8 also - to maximize compatibility. For more details, see:

Richard’s presentation: slides (PDF) | audio (mp3)

@media session 10

Friday, May 30th, 2008 at 3:00pm

WAI-ARIA - It’s Easy

Steve Faulkner

Web Accessibility Initative - Accessible Rich Internet Applications

It’s a W3C spec, close to becoming a recommendatio, aims to make sense out of NOISE, out of silence.

Wherever possible, use the native tags to convey role and state - where you can’t, use the new WAI-ARIA attributes to add extra meaning - this way, the keyboard operability is built in.

Role and state information can be applied to virtually any HTML element. For instance, the extra code for a button/graphic might be:

<a href=”" title=”OK” role=”button”><img src=”ok.gif” /></a>

The extra attribute, role=”button” is the thing which tells assistive technologies more information - the role of the element is a button, and the standard usage instructions fed to the user would be “to activate, press spacebar”.

Of course, the same thing could be achieved with an image button, but WAI-ARIA can still add extra useful information:

Button off-state:

<input type=”image” src=”okoff.gif” alt=”highlight off” role=”button” aria-pressed=”false” />

and for the on-state:

<input type=”image” src=”okon.gif” alt=”highlight off” role=”button” aria-pressed=”true” />

AJAX and WAI-ARIA

It can help in the following situations - when

  1. Users not having access to content changes
  2. Users not being aware of content changes

Eg Twitter’s letters left indicator - when you’re typing in the box, screen reader users don’t know the numbers are changing (they are in virtual cursor mode for text input).

Live Region attribute addresses this problem - pause during typing, and the letters left is announced by the screen readers. The relevent attribute is aria-live, properties are “off, polite, assertive or rude”. So they gain access to content changes.

Support
Major browser vendors, yahoo, google, Jaws, etc. You can start using them now, they won’t break agnostic browsers, it will be ignored.

FireVox is a plugin for FF - you can test it with that?

Attributes can be added by unobtrusive Javascript. But if you put them in now, they might not validate.

Firefox Accessibility Extension - useful for testing without a screenreader. Knows about WAI-ARIA attributes and will indicate state changes etc.

ARIA: Accessible Rich Internet Applications/Relationship to HTML FAQ

Steve’s presentation: slides | audio

@media Session 9

Friday, May 30th, 2008 at 12:25pm

The Why and Which of JavaScript Libraries

John Resig took us through various scenarios when you write JavaScript:

  • Plug & Play:
    Drop in a widget, little or no JavaScript knowledge required, just customise some options and go - no flexibility
  • Some assembly required:
    Write common utilities, use pre-made code to distance yourself from browser bugs - flexible, until you hit a browser bug
  • Down and dirty:
    Write all code from scratch, deal directly with bugs, quirksmode can save your life - eccessively flexible - almost too flexible
  • Use JavaScript library:
    Makes JavaScript bearable, gets the job done fast, simplifies cross-browser support - easily customisable

John then did a comparison between the various JavaScript libraries, including jQuery, Prototype, YUI and Dojo, which are commonly in use. A developer survey showed that jQuery and Prototype were used by around 32% of developers; YUI was 22% and others around 14%.

John’s full slides give much more detail of each library’s strengths.

John’s presentation: slides (slideshare) | audio (mp3)

@media Session 8

Friday, May 30th, 2008 at 11:30am

Building on the Shoulders of Giants

Jonathan Snook

Culture
We come from a culture where developers tend to like to reinvent the wheel, whereas designers like to reuse. If, as developers, we want to use components of others’ work (under GPL or whatever), this provides us with some distinct advantages. Look how many times the Linux distribution has forked!

Tools
There are loads of PHP frameworks out there, and also for other languages. We dont’ have to write everything from scratch, but make use of pre-existing libraries and functions.

Flash - now has built in sockets support. Useful for charts in pages (if you need them)

Types of Data
Location, Time, Relationships etc

Pitfalls
Dynamic APIs can foul up your application; service availability; you are middleman - if something goes down people blame you, not the service provider.

Benefits
Dealing with well-tested code. Speeds up development. Solve problems outside original solution.

Ideas
Enables you to get stuff out fast. Iterate fast and often. Eg Overheard RSS feed built really quickly (using library elements from Cake PHP). You can see what works. You can put stuff out in hours, rather than days or weeks.

Jonathan’s presentation: slides (blog+links) | audio (mp3)

@media Session 7

Friday, May 30th, 2008 at 10:30am

Professional Front-End Engineering

Nate Koechley

Nate began by giving us a bit of historical context to the way Yahoo! has evolved over the years.

He then covered topics such as Yahoo’s server architecture, graded browser support [see below], progressive enhancement, unobtrusive JavaScript etc.

He suggests we all have an interesting set of decisions to make regarding front-end design:

  1. Do what is standard
    if impossible, then
  2. Do what is common
    if impossible, then
  3. Do what it takes

Then we get on to:

  1. Do what is simple
    +
  2. Do what is flexible & progressive
    +
  3. Do what is open

This is in order to satisfy the multiple audiences for any website: Users, Developers, Machines.

At Yahoo!, they focus on 8 specific areas:

  1. HTML
  2. CSS
  3. JavaScript
  4. Accessibility
  5. Internationalisation
  6. Performance
  7. Infrastructre & Process
  8. Tooling

They use tools such as JSLint to check code for quality, and adopt the idioms it promotes to improve their code. Also, unit testing with YUI Test.

There’s much more detail in his slides (see below).

Nate’s presentation: slides (blog/slideshare) | audio (mp3)