Wednesday, May 7th, 2008
Category: Usability
, JavaScript, Tutorial, Unobtrusive JS
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.
You can also read the slides on slideshare:
Pending the quality of the recording, there’ll also be a video available sooner or later.
Monday, April 14th, 2008
Category: Usability, JavaScript, Browsers, Unobtrusive JS, Standards
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.
Tuesday, March 25th, 2008
Category: Usability, JavaScript, iPhone
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:
HTML:
-
-
<meta name="viewport" content="width=980; initial-scale=0.631163708086785"/>
-
and JavaScript to do the right thing on the iPhone:
JAVASCRIPT:
-
-
(function(){
-
-
//Variable used to control the zoom and
-
//position of the page when it is loaded.
-
var viewport = {
-
initialScale: 0.631163708086785,
-
width: 980
-
};
-
//(-80) is for the navigation bar, otherwise you can't read it
-
//until it is fully loaded
-
var scrollPosition = {
-
left: 198,
-
top: (188-80)
-
};
-
if (/iPhone/i.test(navigator.userAgent)) { // sniff
-
//write the meta tag for the initial scale. This should
-
//happen in the <head> section of the html page.
-
document.write('<meta name="viewport" content="width='+
-
viewport.width+'; initial-scale=' +
-
viewport.initialScale + '">');
-
-
//This loop will catch the page is loaded with out needing
-
//to use the onLoad event.
-
var _timer = setInterval(function(){
-
if (/loaded|complete|interactive/.test(document.readyState)) {
-
clearInterval(_timer);
-
-
//This will scroll the content into view,
-
//could be enhanced with animated scrolling but less is more.
-
//if the user started scrolling then let them handle it.
-
if (window.pageXOffset == 0 && window.pageYOffset == 0)
-
window.scrollTo(scrollPosition.left,
-
scrollPosition.top);
-
}}, 10);
-
}
-
})();
-
Friday, February 1st, 2008
Category: Usability, Design
Bill Scott clued me in to this interesting first post from Theresa Neil on two design paradigms for handling large amounts of data:
- 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.
Category: Usability
Aza Raskin has been chatting about a couple of things now that he is at Mozilla.
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.
Monday, November 26th, 2007
Category: Usability, Articles, UI
Now and then we weave the Ajaxian car into the designer fast lane from the developer one as we see something interesting. This time around we have Amy Hoy talking about product pages as an example of how to do good UX(P|D|).
She starts out with UX 101:
- Be nice to your users and customers (and potential customers).
- Design as if your main goal is to inform and educate.
- Be honest and forthcoming, while you’re at it.
- Help your users and customers to do what they want, not what you want them to do.
- Be consistent with your message and quality of service (and I’m including software design here, folks).
- Scientific, measurable “usability” doesn’t necessarily make for a good experience.
- Good design makes people feel good.
And then continues to use these rules to rip apart landing pages for Opera and Firefox. You can see her red and green pens at work:
Tuesday, September 4th, 2007
Category: Usability
Luke Wroblewski has been doing some research for his new book and took a look at some eye-tracking and usability studies to do with web form design.
He wrote up his findings in Primary & Secondary Actions in Web Forms, where he discusses alignment, differentiating paths, and placement of various pieces of the form layout:
While the primary goal of most Web form designs is to get people through a form as quickly and painlessly as possible, there are situations where slowing people down is advisable. When choosing between primary and secondary actions, visual distinctions are a useful method for helping people make good choices.
Should this distinction be more prominent like the button vs. link in Option A or a bit more subtle like the two different colored buttons in Option C? Option A fared a bit better in time to completion, average number of fixations, and average total length of fixations indicating people completed the form faster but not by much.
The need for these distinctions becomes moot, of course, when no secondary actions are present. Make sure you really need each secondary action on a form and don’t add them indiscriminately.
Conversely, the alignment of actions with a form’s input elements provides a clear path to completion that helps people complete forms faster. Be conscious of where you place form actions as primary actions directly aligned with input fields tend to increase completion rates and the less time people have to spend on your forms, the happier they will be.
Sunday, January 28th, 2007
Category: Usability, UI
Podtech's LunchMeet vidcast has done an interview with Kris Tate and Thomas Hawk of Flickr rival Zooomr. Zooomr has a lot of nice features, but one thing that stood out in the demo was the use of popup icons that appear when you hover over the photo. As you hover, they show up in the corner, and allow you to do things like open the photo up as a lightbox or toggle its "Fave" status (i.e. declare it as one your favorite pics).
The neat thing about this popup mechanism is that it's pretty consistent across the site...whether you're looking at thumbnails or a detailed view of the pic, you get that consistent set of icons. This means you can mark a pic as your favorite without having to open it up first. In the ongoing effort to build a rich collection of tags, it's also conceivable that users could tag the photo with a similar popup mechanism.
From an eye candy perspective, the Ajax-powered (or DHTML if you like) portal feature is pretty sweet too. Like Flickr's popup notes, the pic shows a box outline. With portals though, what you see when you hover over it is a new inset photo and you can actually scroll around the second photo while looking at the portal photo. And of course, clicking on the inset photo opens it up. Hard to explain, but easy to understand if you try it out.
Watch Lunchmeet's Eddy and Irene talk to Zooomr's Kris (founder/CTO) and Thomas (CEO) ...
Wednesday, January 24th, 2007
Category: Usability, Showcase
Mkemne:) is a basic German "finance 2.0" website aiming for an easy interface for users to assess the state of the market. It presents company info and you get to add your favorite companies to a persistent watchlist. It was developed by Nader Cserny of Brand Infection, who was also responsible for the UI design of several Ajax sites we have previously featured here - Blummy, BandNews, WizLite, all sites developed by Alexander Kirk. (I've recently worked with Nader.)
Like a lot of Ajax/Web2.0 sites these days, it uses Lazy Registration - or what Mike Arrington recently termed "Auto-Login via a browser cookie" - to build the watchlist without requiring a formal signup process. Interestingly, Nader calls it "extremely lazy registration" because there is no sign up at all, ever. And for basic personalization like a watchlist, there's a good argument that cookies are all you need.
mkemne:) is a user-friendly stockmarket portal, currently available for the German market.
...
I am interested in the stockmarket since the age of 14 and until today I am horified by the existing services. Google Finance being a welcome exception. With mkemne:) I wanted to create a portal that enables everybody to access market data in a fast and easy way.
Features:
- Reduction to the max. No 1000 links, banners, colors, etc.
- Keep a watchlist of your stocks. Add and remove them with a simple click
- Quickly catch the Winners/Losers of the day. A click saves your preferred indexes for the next time you visit the front page.
- Very Lazy-Registration. Actually there is no registration :)
- Read News about the stocks you keep in your watchlist, subscribe to your personalised RSS-Feed
Technology:
- LAMP, cURL, cron
- moo.fx + moo.ajax
- ezSQL
- Snoopy
- magpieRSS
- FeedCreator
- PHP/SWF Charts
Saturday, December 30th, 2006
Category: Ajax, Usability, Editorial, Web20
It's the time of year to be posting random predictions for 2007. Here are 2007 Ajax predictions from Dion and myself, please post your own in the comments.
Dion predicts:
- Ajax beats AJAX in all but bad newspapers.
- Someone tries to coin Ajax 2.0.
- A large amount of apps have flash AND ajax, and users don't know or care.
- Many frameworks consilidate or die.
- A widget api means componts can run on many frameworks using one api.
- Ajax wpf/e interop.
- Dashboards become front boards.
- More desktop apps get written with javascript.
Michael predicts:
- 2005 was the year that developers learned all about Ajax and by 2006 everyone else in the industry had caught up. In 2007, is is mainstream users who become acutely aware of the trend towards rich applications inside the browser, and discover that even word-processors and spreadsheets - along with a wide array of workplace applications - can be webified. At the same time, users remain oblivious - and rightly so - to the underlying technologies that power them.
- The boundaries of Ajax harden, with most developers gaining a clear understanding of what it can and can't do with modern browsers and managers in a better position to decide on application architecture (whether to use Ajax, Flash, desktop, etc.).
- More attention on Ajax accessibility due to some government report or court case.
- Google Office. Finally!
- Backlash against Google Office as managers learn that their data must be hosted externally in order to use it. Pressure from bloggers and some analysts to make an Office appliance that can live behind the firewall, but it's not happening in 2007.
- The advertising and media communities finally become aware that page view metrics are no longer the only way, but generally treat it as a problem and fail to see that the situation is actually better than before.
- Several fringe technologies heat up as developers notice they are already being used in some applications and learn how to apply them: HTTP Streaming (Comet), Virtual Workspace (Live Scrolling - never-ending scrollbars), Cross-Domain JSON (along with JSONP, JSON APIs, JSONRequest, and a general lack of awareness about the JSON security issues), Unique URLs (bookmarkability/back button), Lazy Registration (personalized functionality before formal signup). Comet in particular ... it may be 8 or 9 years old, but it's big news in 2007.
- Other fringe technologies grow, but remain, well, fringe. Such as Host-Proof Hosting and applications involving offline storage.
- With its excellent documentation and pattern language integration, the Yahoo UI library becomes the standard weapon of choice among mainstream developers seeking a pure Javascript framework. In the Java world, GWT makes great strides as the platform becomes richer and design patterns emerge.
- Mobile web development continues to suck.
- Javascript increasingly recognised as the world's most popular "second language" and becomes popular as a lingua franca to describe generic programming concepts. Several attempts at server-side Javascript frameworks.
- IE7 causes more than a few headaches.
- Firebug is installed by pretty much any developer using Firefox.
- CSS is back, baby! Echoing the recent mass adoption of Javascript, developers who previously had a fleeting familiarity with CSS now become fluent practitioners.
Best wishes for 2007, however you play your Ajax!
Thursday, December 14th, 2006
Category: Usability, Business, Microsoft
If you've read any tech news in the past 24 hours, you'll now be familiar with the meeting Bill Gates held among influential bloggers, ahead of next year's Mix conference. Aside from learning what's on Bill's Zune, we get to hear his views on the future of web apps, thanks to a question from Liz Gannes. She asked him which apps should live in the browser and which should not, one of the key questions in Ajax and one we have touched on in the past.
He replied that the distinction would come to be silly from a technical standpoint, but that the necessary movement toward web APIs does present challenges on the business side. “One of the things that’s actually held the industry back on this is, if you have an advertising business model, then you don’t want to expose your capabilities as a web service, because somebody would use that web service without plastering your ad up next to the thing.”
His solution wasn’t very specific: “It’s ideal if you get business models that don’t force someone to say ‘no, we won’t give you that service unless you display something right there on that home page.”
Then for the tease: “And, you know, [inside the browser and outside the browser are] moving towards each other, but there’s still a bit of a barrier there, and new technology, things we’re working on, really will change that.”
Wednesday, December 13th, 2006
Category: Usability, Articles
Alexei White has written a post on Building a Fish Eye Menu in which he goes over iterations of his development of a fish eye component.
- Iteration 1 - Proximity Detection and Scaling
- Iteration 2 - X-Axis “Zooming”
- Iteration 3 - Alignments Left, Right, and Center
- Iteration 4 - Labels and Menu Item Activation (Bouncing)
- Iteration 5 - Container Object and Y-axis Zooming
Are people into less conventional UI components like Fisheye, or are they strictly eye-candy with no practical role in enterprise software?
I know there are still things that Fisheye can use in the way of functionality. It would be nice, for example, to have vertical orientations for the menus, and also to be able to attach traditional drop-down menus to each element. I would also like to see context menus and groupings.
Thursday, November 30th, 2006
Category: Usability
Jason Fried of 37 Signals talked about a Basecamp design decision that had to do with their help section.
An Ajax callback on an input selection was occuring too fast:
Speed is good, but speed can also be deceiving. Sometimes things can happen too fast. Sometimes it doesn’t look like anything changed. That was the original impetus for the yellow-fade technique introduced in Basecamp.
But the yellow fade just didn’t seem to make as much sense in this case. We wanted to be a bit more subtle. Flashing a huge 500 sq/px section yellow was too much.
A subtle difference was found between changing the headline, and making it white on black. With a black background, you saw it change length, and users could process that change:
Now when you make the switch the shape of the header also changes. The black bar changes length. That’s a lot more obvious than just black text on a white background.
This plays off Tufte’s “smallest effective difference” theory which basically says you should make all visual distinctions as subtle as possible, but still clear and effective.
Changing black text was too subtle and not clear enough. But changing the background to black allowed the section change to be clear and effective yet subtle enough not to startle you like a huge yellow fade might have done.
Wednesday, November 8th, 2006
Category: Usability, Editorial
Aza Raskin spoke at The Ajax Experience about the desktop being dead. The talk was entertaining, and he kindly posted his slides.
He has followed up the talk with a question: Is Converging Towards the Desktop Good? in which he takes the side of "No.".
He comes out against recreating windowing toolkits in JavaScript, and instead embracing the web-way, and thinking outside of the desktop box to come up with a more humane interface:
In 2004, Google chose to use one nascent technology, Ajax, to create an e-mail service: since there didn't exist any Ajax toolkits that allowed them to reduplicate the desktop on the web, they were constrained to think simply, "how can we work with Ajax and the web to make email humane?"
Their answer was something that was actually more humane than any desktop e-mail client already in existence. What's even more interesting is that traditional desktop developers had long been able to create an email client as humane as Gmail--but they never did, because UI toolkits made it so easy to create something that was familiar, that was the same, that was inhumane.
You cannot be better without being different.
The desktop-like web toolkits being developed today endanger innovation by entrenching us in familiarity of the past. We need to remember that there is something better than the desktop in many of today's web applications, and we need to carry this innovation with us as we move forward to create new tools and new interfaces.
Do you agree or disagree?
Tuesday, November 7th, 2006
Category: Usability, Editorial, CSS
This is a touch off-topic, but important for those that want to build killer web applications :)
The iA folks have written a post on Web Design is 95% Typography (including a follow up part two).
95% of the information on the web is written language. It is only logical to say that a web designer should get good training in the main discipline of shaping written information, in other words: Typography.
95% may be a touch inflammatory of course, but I think there is an important point here.
I think that one of the reasons that Wordpress did so well is that they cared about the UI, and one of the major pieces of care was in the typography. As soon as WP came out, the default theme made Movable Type (of the time) look immature. It also had the now popular BIG FONTS.
Where usability gurus usually fail
- The text lines (measure) are too long.
- 100% scalable is not a reader friendly solution: Don’t make me think, ok, but don’t make me resize my window either.
- Lack of whitespace.
- Lack of active whitespace.
- Linespacing is too narrow.
- The text blocks are not well alined.
- Too many font sizes.
- Pictures are badly placed and disrupt the ease reading.
Before you go to bed tonight.... remember.... is your line-height set correctly!
(In a somewhat related note, if you are anal about fonts, there is a new Dina Programming Font)
Tuesday, October 24th, 2006
Category: Usability, UI, The Ajax Experience
Notes form Aza Raskin’s presentation on Death of the Desktop.
Interface Concepts
- cognetics = ergonomics of the brain
- 7 +- 2 = amount of things we can keep in our brains
- habituation – never use a warning when you mean undo
- people will make mistakes despite any warnings, due to habit
- hick’s and fitt’s law
- hierarchical menus are evil
- information efficency
- there are quantitative measures of how good an interface is
Interface
