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.
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.”
In our age of information and technology, there isn’t as much mystery as there used to be. In that sense, short URLs (e.g., tinyurl.com/123) can be fun! Who knows where you’ll wind up.
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.
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 am a strong believe in making the keyboard a first class citizen for your applications, including on the Web. Thus, I was interested to read how Ext JS has keyboard handling that ties into the entire system:
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.
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.
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.
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.
One of the examples that Ben and I give in our State of Ajax talk at Google I/O today revolves around form history.
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.
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.
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've been talking about progressive enhancement here before and got a lot of flak in comments about it. It seemed that there was a general misunderstanding of progressive enhancement and unobtrusive scripting as a "passing fad" or "backward facing rather than being innovative".
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:
Separate as much as possible
Build on things that work
Generate dependent markup
Test for everything before you apply it
Explore the environment
Load on demand
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.
Over at Quirksmode.org, Peter-Paul Koch is researching if Event Delegation which works splendidly with click events is also possible for blur and focus.
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:
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.
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.
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.
, UI
