“A man’s got to do what a man’s got to do.” said the cowboy John Wayne. Mozilla’s new intern with the same name knows that Mozilla needs to do… and it needs to do performance. It isn’t just about JavaScript performance though, the battle for the hearts and minds is perceived performance. This is a tough game for Mozilla as the average user giving Chrome a shot is doing so on a fresh browser with no history, bookmarks, or add-ons. If you download a fresh Firefox nightly you may be surprised at how fast it is!

John has been doing some analysis comparing the perceived performance compared to Chrome:

and came up with some recommended actions for the team:

• With just a few changes in the Firefox start-up process, we could greatly enhance the feeling of Firefox’s speed. The changes listed below are recommendations to help better the overall Firefox experience.
• Draw the OS spinner icon as little as possible, but one solid break isn’t bad and might be better than one really long spinner.
• Draw the browser chrome while the window is being animated (drawn) to size. So that most of the drawing happens simultaneously rather than sequentially.
• Make a new ‘website loading’ icon with less visual weight that animates faster but is slightly larger (would allow a user to ‘see’ the faster animation).
• ‘Lazy’ load tabs that are being restored (already being talked about).
• Load upgrades and add-on updates upon browser close, not browser start.
• Delay loading the website’s title until the website is ready for interaction.

Sam Stephenson (of Prototype and 37Signals fame) has taken on the problem of the sizing of controls. If you zoom out, normally, controls are smaller in the same proportion as the rest of the content. In reality, you want nice large controls that are tap friendly. This is where his device scale technique comes in:

He also talks about how he takes hover elements and makes them tappable to get the same item shown or hidden.

Can We Do ARIA Today?

Yes.

Firefox and IE (he didn't say which version) have really good support for ARIA. And Opera, Chrome, and Safari. Likewise for the screenreaders - JAWS, Windows Eyes, NVDA - also have good support. An the libraries - YUI, Dojo, JQuery-UI - all have good support baked in, one of the benefits of using ARIA is automatic support.

Improving Perception - ARIA and Screenreaders

Websites can have problems in perception when rendered with a screenreader; it's hard to get the big picture about what the words refer to. With ARIA, we can close the gap in perception. This is another example of progressive enhancement - augment the item by adding properties, markup or Javascript if required:

Improving Usability - Keyboard Focus, ARIA, and YUI support

Keyboard access. For some people, it's a necessity, and for others it's still an option or preference (think Vim). To support it, you must be able to tab to the element to get focus, so you should control tabbing with tabindex. A good application of controlling tabbing is, amazingly enough, moving through tabs. Another is modal dialogs; the browser doesn't "know" it's modal, so we have to control focus to make sure it doesn't slip out of the thing that's the only thing users should be able to click on!

Todd shows us just how many steps are required to perform a task in a complex application like Yahoo! mail, using just tabs to navigate through - 19 steps in this example, walking through the toolbar; and even more, when you consider the wider picture of entering the app in the first place. To help with this, he introduces a pattern whereby tabIndexes are updated dynamically to control what comes next, as you move through a toolbar. A negative tabIndex will ensure the element is skipped over.

You can also use the "focus" pseudoclass to ensure focus appearance is consistent for all elements. But, and it's a big one, it's not very well supported; even IE8 doesn't support :focus on <a>, for example. Doing it manually with Javascript has problems, in particular performance. Fortunately, PPK has worked out how to handle focus and blur with event delegation, so that it's much more performant, and the resulting technique is built into YUI3.

Device-independence with markup was also advocated to further improve accessibility:

Improving Discoverability - ARIA

Essentially, this is about "random access" and keyboard shortcuts; jumping straight to areas in this page and activating them. The key ARIA feature here is "landmark roles" to identify particular points on the page. This is still something where users aren't aware of the feature, and Todd points out it's not surprising as most screen reader users are self-taught (just under 75% according to the study he showed). Also, not every user is a geek, and the same applies to screen-reader users.

The next logical step was to clean up the script a bit and make it work without Greasemonkey. Now you can simply embed it into any document. See it in action on YouTube:

As shown in the demo page, all you need to do is to point to the script and call the init() method with the two field IDs as parameters.

There are some ways to customise the script and its behaviour, all of which are described on GitHub. Download the script and read the docs there.

Bill Scott presented Designing Web Interfaces, a slideshow based on core items from his book (co-authored by Theresa Neil).

There are some really interesting posts on the site, such as 30 Essential Controls. Theresa has been pinging the major frameworks and will be posting a matrix of coverage by the various frameworks. But more generally it is a nice checklist of controls that can liven up an interface.

The latest episode focuses on chromless browsing:

What would a browser look like if the Web was all there was? As the Web becomes even more ubiquitous, we’ll never have to leave it. Whether it’s on touch tables, giant wall-sized screens, mobile devices, or just our computers, exploring the interactions for browsing a windowless Web will become ever-more important in the next couple of years.

I really like how they use the video to not show talking heads, but instead add to their content.

As I was listening to them discuss the different between usability and discoverability it really resonated with me. Most of my favourite features are not discoverable at all. For example, I navigate tabs with Apple-1, Apple-9 etc.

But back to the topic at hand, imagine you are in full screen browsing mode, how would you get around? For me, I hope those Apple-# keys still work (tabs fade in when I hit apple?)

How many tabs does an average use at a time? How about novice users? How often is the stop button pressed? How many times do people open a new tab to perform a search?

There are hundreds of questions like these whose answers would help quantitatively inform the design process of Firefox.

Those are the questions that Aza Raskin and the Mozilla Labs team are working on solving with Test Pilot, a very exciting project that is kicking off in force.

I am jazzed to see where this goes. I would love to see the crowd show us that "wow, people really do that?" which is my constant experience from usability studies. Maybe we could get some performance info too, and learn from the crowd that plugin A + plugin B causes issues. Who knows. The platform it just beginning. Have ideas? "Come brainstorm at a Lab’s Night, participate in the forums, hop on IRC, or help create on our wiki."

Some folks aren't as happy with uncertainty in hyperlinking; one of them, Darragh Curran, wrote in to tell us about his project: Long URL Please.

Long URL please (http://www.longurlplease.com) is a JSON webservice to
efficiently convert short urls (tinyurl.com/123) to their originals.
I've got a simple jquery plugin to take advantage of it, and a firefox
plugin. It's running on google app engine.

Darragh hates short URLs so much he's offering to contribute his time to help wipe them off the face of the web:

I'd love to see it used in apps like twhirl/tweetdeck/twitterific, on
microblogging sites and pretty much anywhere that's got lots of short
urls. In that respect I'll happily contribute my time to help those
people/teams integrate with the service.

There's even a bookmarklet.

John Resig linked to an interesting new time picker UI that Maxime Haineault implemented as a jQuery plugin:

He made a "two click" time picker. The first click is within the time field. This activates the display and allows the user to choose the time - all of which is done by moving the mouse over the times that you desire. The final click is anywhere - filling in the time that was chosen. It's hard to explain, you simply have to try it.

One thing that you'll notice using it is that it's fast. Very fast. I'd argue much faster than clicking into the input area, moving to the keyboard for entering the time, typing the time, then moving back to mouse.

I would be remiss not to mention John's other post of the day, where he goes into detail on CSS Animations and CSS Animations.

Ext.KeyMap

Ext provides several components that support keyboard navigation out of the box such as GridPanel, ComboBox, and TreePanel. To implement custom keyboard handling, developers can use the Ext.KeyMap and Ext.KeyNav classes to attach keyboard bindings to any component or element they wish.

The first set of keys we wanted to handle was all of the Function keys (F1-12). While most browsers reserve some/all of these keys, with some ext-pertise, we are able to override the default function if need be for our application. The application we were working with was completely dynamic and server driven, so we really couldn’t define all of the handlers ahead of time. This led to us dynamically building an array of key handler configuration objects and passing them all through to our new Ext.KeyMap object.

PLAIN TEXT

JAVASCRIPT:

1.  
2. var keys = [];
3. for(var i = 0;i <buttons.length;i++) {
4.     var btn = buttons[i];
5.     // fkey property contains a string referencing the Ext constants (ie: Ext.EventObject.F1)
6.     var fk = eval(button.fkey);
7.     btn.handler = this.handleKey.createDelegate(this, [fk]);
8.  
9.     keys.push({
10.         key: fk,
11.         handler: this.handleKey.createDelegate(this, [fk]),
12.         stopEvent: true,
13.         scope: this
14.     });
15. }
16.  

Ext.KeyNav

The next set of key handling added was some additions to the grid keyboard navigation. The GridPanel has built in key navigation from the RowSelectionModel that it creates. Check out this grid example and select a row, you can then use the arrow keys to move up/down and even hold shift and press down to select a range of rows. We added a simple way to navigate through a large paged data set by extending GrindPanel. The PagingToolbar provides keyboard handling once you’ve focused within the built-in TextField, but we wanted to allow the users to just hit ‘page down’ or ‘end’ when focus was anywhere within the GridPanel and ensure it functions as expected.

PLAIN TEXT

JAVASCRIPT:

1.  
2. MyGrid = Ext.extend(Ext.grid.GridPanel,{
3. ...
4. afterRender : function() {
5.    MyGrid.superclass.afterRender.call(this);
6.  
7.     this.nav = new Ext.KeyNav(this.getEl(),{
8.         pageDown: this.pagingNav.createDelegate(this,['next']),
9.         pageUp: this.pagingNav.createDelegate(this, ['prev']),
10.         home: this.pagingNav.createDelegate(this,['first']),
11.         end: this.pagingNav.createDelegate(this,['last']),
12.         scope: this
13.     });
14. },
15.  
16. pagingNav: function(page) {
17.     var pt = this.getBottomToolbar();
18.     if (!pt[page].disabled) {
19.         pt.onClick(page);
20.     }
21. },
22. ...
23. });
24.  

Aza Raskin and the Mozilla Labs team looks like they are having a lot of fun. They have been putting up proposals for new UIs and the latest involves a smarter new tab screen.

Aza discusses how opening a blank screen doesn't really help you. Opera already allows you to have a quick dial screen show up there, but what else can be done?

Often a new tab is opened to do a search, so they can put a search bar right there, and it can be smart enough to search across your own tools and providers (e.g. delicious). I personally don't do this, as I use Apple-K to jump to the search bar in the browser and have the search results open in a new tab.

What I found even more interesting was the context specific smartness. How often do you do this:

• Find an address
• Select and copy the address
• Open a new tab
• Go to maps.google.com
• Paste in the new address

Instead, the new tab selector can be smart and automatically show you the map option. NOTE: there are of course other options such as plugins that find the addresses and give you links to the map.

Here it is in action:

And his analysis:

Instead of popping up the book, music, dvd information quickly we are required to watch the talent of the developer to sloooowly animate the box into place. Come on folks, we can do better than this!

There is no need to see utility objects like this animate into place.

Here is the general rule. Try your feature without animation. Is the meaning clear? If so then don't add ANY animation. If it is not, try adding a quick animation. Did that get it? Then stop there.

Save animation for when you need it. Animation is good for at least seven reasons:

• Maintain context while changing views. Carousels are a good example of this. The scroll animation helps the user maintain context as they move through information.
• Explain what just happened. The Apple store Customize your Mac uses this to highlight price changes while configuring a Mac for purchase.
• Show relationships between objects. The Mac Genie effect when closing or opening windows. It is fast enough and it ties the iconified window to the dock.
• Focus attention. Backpackit's Spotlight technique focuses attention on the change that happened.
• Improve perceived performance. Progress Bars.
• Create an illusion of virtual space. Yahoo! Home page's personal assistant (Tabs animate open).
• Engagement. Mini-Cooper site, configure your car. The animation is fun.

BTW, I go into detail on animation in my upcoming O'Reilly Book, Designing Web Interfaces.

On the Stack Overflow blog, Jeff Attwood asks Is it OK to require JavaScript to participate?

Note that by “participate” I mean “edit, answer or ask a question”. Of course passively reading a question and the associated answers will work fine without JavaScript enabled.
...
While we do believe in progressive enhancement, it’s possible that some of the features we’re building for asking and editing may be so dynamic that they do not degrade well, if at all.

What say you? Is it OK for a website in 2008 to require JavaScript for active (not passive) participation?

On a forum site like StackOverflow, is it an "enhancement" when you add a comment? Not really, which would make me lean towards keeping the site simple and not requiring Javascript for making basic contributions. There is also accessibility to consider (although "accessible" is not the same thing as "Javascript not required").

It could be argued that as a developer-focused website, Javascript can be assumed. But developers are also the most likely folks to go out of their way and turn Javascript off. And developers are also among the most critical of sites that require Javascript (or Flash) when it could have worked without it.

We were thinking about the case for Undo on the Web that Aza Raskin is proposing and it got us thinking about the usage patterns of form data.

An example that got me was the Address Book application on the Mac. I find myself storing past addresses in the general "Notes" section at the bottom, but what if history was built into the system so I could go back in time? This could be a nice metaphor in general that goes beyond undo.

I took this use case and put together a working example that uses Gears to store the history locally so it can be speedy through the history.

The slider component comes from Script.aculo.us, and you can check out all of the code.

In the video below I show the application in action and then do a quick code walk through:

This is just the beginning of course. A slider if fun, but it would probably be more usable if it was simply left and right arrows that click through the versions, or at least putting tacks onto the slider.

At the Accessibility2.0 conference in London earlier this year, Antonia Hyde of United Response gave a talk about rich media and web apps for people with learning disabilities and outlined a perfect media player for the needs of this group of disabled web users.

Whilst not ticking all the boxes, I took the YouTube API and created an easy interface for YouTube videos that has big friendly buttons and easy to use volume controls:

You can just add a YouTube URL to the end of the player URL to play the video or download the whole player to host it yourself and style it any way you want.

Check out the blog post about Easy YouTube player to get all the information and try it out.

What I found was that neither mine, nor the extJS nor the demo pages on the YouTube API page work in Opera, which means there is a bug in the API itself.

I was asked by a design agency in London to go there and give a brown bag presentation (during lunch break) on the matter and took this as an opportunity to write up reasons and examples for progressive enhancement concentrating more on the why than on the how.

The gist would be to say: enhancing a product progressively means you'll always deliver a working product - as you have no idea how your product can fail in certain environments, you plan for it to fail. This ties in nicely with the agile manifesto - you always deliver software that works.

In my talk I came up with seven "rules" of pragmatic progressive enhancement:

1. Separate as much as possible
2. Build on things that work
3. Generate dependent markup
4. Test for everything before you apply it
5. Explore the environment
6. Load on demand
7. Modularize code

I've taken these ideas and backed them up with benefits you get by following them and code examples in a full article: Pragmatic Progressive Enhancement.

The article is licensed with Creative Commons and uses YUI in the example scripts, feel free to translate, remix and create examples using other libraries.

You can also read the slides on slideshare:

Pending the quality of the recording, there'll also be a video available sooner or later.

Event Delegation means that you piggy-back on the behaviour of browsers to report events on child nodes up the tree to their parents. Instead of applying event handlers to each element you apply a single one on the main parent element and use the event target to determine which element was activated.
The benefits of Event Delegation are that you use a single event handler for a unknown amount of nodes. This is very handy when it comes to developing dynamic menus where the data is pulled via Ajax.

So far, PPK found that apart from IE all browsers play along, and there is a test page to give him feedback.

Bob Buffone has created a tool that can be used to output script and HTML to make your site more usable on an iPhone. He tells us about it here:

I bought an iPhone about six months ago; in that time I noticed that even though it had this part of the Web and that part of the Web. Every page I went to I was only reading this part and in order to do that, I needed to scroll it into view and resize the page the same way every time. When I go Ajaxian.com on my iPhone I need to scroll the content to the right location and scale it so the middle column fits the screen and then start reading. It’s a real pain in the ass.

This was the case for my blog as well. I didn’t want to rewrite it so I figured out a way to use a little JavaScript to set the scale and position of the page at start up so the main content area completely fills the screen for the iPhone.

Once you input the URL to your site, it gets loaded and you can interact with it to put the box in the right place. For Ajaxian, it then output the following HTML:

and JavaScript to do the right thing on the iPhone:

• The Seek Paradigm: Have the user ask for what they want.
• The Show Paradigm: Display everything up front, and let the user explore and organize it.

"The first is usually more prevalent on the web. The latter usually more prevalent on desktop or deeper web applications. Theresa lists 10 different patterns illustrating Seek and Show."

She details both paradigm with very nice real world examples.

First, Enso 2.0 is on the horizon which will be nice and free. Aza just added his design thoughts for the new version.

I am interested in seeing how Enso could do more within the browser. You can already do things like open a URL, but you could take it further and use it as a way to script the way you do things in the browser.

Then, Aza talked about the design decisions in adding an about page. When you read that you probably think: "are you kidding me?" but there is a little more too it:

Say I’m listening to “Bohemian Rhapsody”, singing along in that I-hope-the-neighbors-won’t-report-me-to-the-landlord sort of way, and I decide to find-out more about Songza. I click the link and — BAM — I’m no longer listening to the song. Instead, I’m staring at this self-serving, slightly meglomaniacal page about Songza’s history and its founders. Not only that, but I’ve lost my spot just at the best part of the song (I’m not saying which part that is in hopes of starting a small flame war). The naive approach to creating a separate page has turned the unassuming “about songza” link into a landmine — under no circumstance should you punish your users for using your system. Because there is no way for the user to know which links will intterupt the music, every link is a Russian Roulette. Not cool.

The solution is to open a new window (although preferably, it would be a new tab). This way, the “about songza” page opens without interrupting the song. It’s work-flow transparent. Spamming the user with extra windows or tabs is never a good thing, so we use a little bit of Javascript to open a new page only if a song is currently being played. We used a similar solution for the “Watch Video” link as well, except we went the extra mile there and automatically pause the Songza song so that it doesn’t compete with the video.

Now we need examine the behavior of the “return to songza” link that formerly went at the bottom of the about page. By opening the about page in a new window, we’ve broken the link’s behavior. If I were to click on it, it would cause that new window to go to Songza, which means I would have two separate instances of Songza open. How annoying! One solution would be to change the link to say “close about page”. That works great if I had come to the page from Songza, but if I had found myself on the page by doing a search, I would have no way of getting back to Songza proper without editing the URL. We are in a bit of a bind — either way we do the link, we have a suboptimal behavior.