Presenters :

• Amy Hoy @amyhoy
• Thomas Fuchs @thomasfuchs

Sites:

• http://mir.aculo.us
• http://slash7.com/about/

photo credit: Chris Shiflett

A quote from Thomas Fuchs’ site… “You’re using my work every day, even if you’re not aware of it”. Thomas is the author of http://script.aculo.us and working group member of prototype.  Funnily enough williegoosen.com uses mootools, which uses prototype.  Amy has also made some rather cool tweet walls http://twistori.com/ and more recently http://letsfreckle.com/ a time sheeting app.

So I knew there were some tricks, having spent some time with ySlow in the weeks before, but was enlightened by the simple techniques that make a lot of difference.  Amy and Thomas did a great job of tag teaming through a rather dry subject and made it rather interesting, with one of the team walking through the slides and the other answering questions on a chat room style back-channel.

The talk started off with one of the rules being “only fix it if you need to” which i suppose makes a lot of sense. Tweaking performance can be a real fickle business, but if the users aren’t happy you have to fix it quick!

Test, don’t guess. benchmark. Make sure you can quantify the issue before you attempt any fixes so you can measure your improvement.

In some cases it will just be impossible to please your users but there are ways to keep people engaged and let them feel you are not ignoring them, while doing the heavy lifting in the background.

Main areas of focus
Loading -  connecting/spinning wheel, back-end speed, dns, latency * easiest win*.
Rendering - white screen of death, you can see items still loading in the status bar.
Execution - site stops responding after is completely rendered.

But to be honest there were just so many “oooh I should be doing that”, “woops shouldn’t be doing that” moments I will try and capture a bunch of them. Non-techy people can stop reading here.

Do’s

• Simple html = simple dom = faster rendering.
• Use yslow and dommonster to identify issues.
• JS scripts at the bottom of your pages.
• Keep external assets to a minimum.
• Set content expiry time frames correctly in the headers.
• Yuicompressor + gzip to reduce .js .css .html size x5 smaller http://refresh-sf.com/yui/.
• Merge .js files into a single .min.js file see http://getsprockets.org/ and http://dailyjs.com/2010/01/27/pro-practices-1/.
• Reduce image size with http://smush.it 30% size reduction no loss.
• Far future cache-headers (resolve updates issues by replacing with new file names).
• Multiple asset hosts – assets on separate hosts than HTML allows for concurrent downloading.
• Focus on whats important to users, webapps(gmail) focus on executing where as static pages (google search) focus on loading/rendering real fast.
• Only HTML and maybe analytics JS should be load in subsequent loads rest should be cached.

Dont’s

• JS in the middle of a page will block the execution of the whole page until its finished running, and can leave the user looking at an unrendered page.
• 404 requests really hurt.
• Avoid slow external assets \ 3rd party libs.
• Watch out for weight of frameworks, try microframeworks instead see underscore.js and emile.js.
• Frameworks and widgets are frowned upon but if you have to script.aculo.us and jquery were mentioned

Interesting

• Cool animation on how browser renders components does multiple sweeps over content to do the layout see http://en.boose.gr/gecko-reflow/.
• Other open tabs can affect your sites performance or crash the whole browser.
• -webkit-transforms are fast and very cool 2/3d stuff at 30-60fps for used on iphone and some android phones similar in jquery animation would be 5-10 fps.
• If it takes long in real life to do something you could get away with a bit of lag, moving between forms and search should be instant.
• Too many page assets becomes a performance hit conciser 3-5 streams for asset downloads being the default in a browser and will require cueing if more assest are required.
• Dynatrace http://ajax.dynatrace.com/ IE tool for testing page loading.

“Silence of more than four seconds become embarrassing because that implies a breaking of the thread of communication.” RB Miller(1968)

And if the conversations is still not happening after all the tuning, then its time to fake it!

• Perception is critical.
• Tell people how long it will take – visual indication of progress can increase patience up to 5x.
• User should feel like they are heard and their input is being considered.
• Instant reaction even if action takes longer for action to complete.
• Never leave the user bored.

Derek Featherstone
Real world Accessibility for Ajax and Web Apps
Sites : www.boxofchocolates.ca www.furtherahead.com

Right so i got caught out by the title like the typical buzzword try-er-outer. So first thing i read going through the workshops, was …. AJAX. So wow that’s like so now and everyone is doing it so the more AJAX the better right?

Upon closer inspection the workshop was more around the _accessibility_ part. And the first 10 min I thought whoops not quite what I intended to spend a day on, but i was captivated after the intro.

Quick key points
1. Forms
- Watch out for Visual labeling, use element
- “em” inside the “label” and position with CSS
- Replace “em” with a “strong” if its an error.
- Plan error/advisory information carefully (keep in flow or shift focus to it if not in flow)
- Dual purpose interfaces can cause issues.

2. Linear Flow
- feedback on an action should be where your focus is going
- have elements linear in HTML and position with CSS for visual organisation

3. Proximity
- when injecting content with ajax place do so in context.
- avoid injecting content at the end of the document if possible
- best yet avoid ajax if it can be hidden with CSS and revealed

4. Backup plan
- have a fall back option, multiple ways of achieving same goal
- use headings for “rescue point” if user gets lost in document

5. Visual Design vs Structure
- check that your visual design and un-styled document is telling the same story
- turn your CSS off see if site still makes sense
- build linear flow into your wire frames

6. Development Testing
- Test for accessibility from the start.
Design Stage: Color contrasts, general layout
Functional Testing: must work with keyboard
Demo Testing: all alt must be accurate, screen reader emulators, turn off css
Final Test: real people varied needs.
- test success error AND corrective paths
- check for alt tags and that they make sence.

A Tools and Links
- Screen readers Shark and Dragon Natural speaking
- HTML Tidy in Firefox is a good start
- Fangs Firefox plug-in screen reader emulator
- Juicy Studio Firefox plug-in for Luminosity Colour Contrast Ratio Analyser
- www.simplyaccessible.org for some examples
- WCAG the accessibility bible

Soo once again to make some sence of all the random jucy tidbits of knowledge, its definitely something i will be promoting from now on.

At a basic level it costs nothing. Its up to the UX designer and Developers to just take a bit more care in element placement and thinking about the project not just from you users perspective but also the less able users. As a by product this will produce a much higher quality product and the HTML is bound to be more semantic and efficient.

A quote from Derek that summed it up quite well :

Its about whats under the covers