Tag Archives: usability

A UX pattern: Reusable hints with jQuery

Update (1): The CSS source had wrong formatted comments and the markup was using class instead of id, please update your sample code when you grabbed it earlier!

Update (2): Please find a working demo here: Hints demo

When building nifty UI solutions, always keep in mind that in order to make your target audience use your cool features, you must teach them. The iPhone is to a certain extend only intuitive because they have the marketing power to teach people on TV how to do pinches and swipes. Anyway, since most budgets are smaller, let’s try to achieve the same with contextual hints.

Contextual hints are basically help bubbles that pop up as soon as you are in a certain context. They can also serve as an application walkthrough or tutorial. If you build a todo list, the first hint you would show your users would be sticking on top of the “Create new todo” button, and would tell you something like “Why don’t you click here and create your first task?”.

I’m sure you got the idea, let’s build a very simple solution without any graphics (The downside: Will not look too good in IE..). First, we need to create the markup for the hint:

<div id="bubble">
	<span class="content"></span>
	<div class="pointer"></div>
</div>

Sweet. We just have the outer bubble element which has the id #bubble, a content div that will hold our text and a pointer div which we’ll transform to a nice triangle. Next, let’s do the CSS:

#bubble {
	background: rgba(255,255,255,0.9); /* use rgba to let the bubble shine through a bit */
	font-size: 1.2em;
	padding: 1em;
	width: 22em; /* the bubble needs a certain width since it's absolutely positioned */
	-moz-border-radius: 1em; /* give the bubble nice rounded corners */
	-webkit-border-radius: 1em; /* ...in both gecko and webkit */
	position: absolute;
	z-index: 100; /* give it a high value here to lie on top of all other stuff */
	opacity: 0; /* opacity must be set to zero at beginning (use filter: alpha(opacity=0) for IE) */
}

#bubble .pointer {
	position: absolute;
	bottom: -1em;
	left: 2em;
	width: 0;
	height: 0;
	border-style: solid;
	border-color: rgba(255,255,255,0.9) transparent transparent transparent; /* make sure only one border side is shown */
	border-width: 1em 2em 0em 1em; /* this is called a border slant and creates the shape of the triangle */
}

Obviously feel free to customize everything related to styling, font size etc. Next, we want it to see come all together by doing the JavaScript/jQuery work:

$.fn.hint = function(msg) {

	var offset = this.offset(), // generate the offset position of the hinted element
		bubble = $('#bubble'), // cache the bubble as jQuery
		pointer = $('.pointer', bubble), // cache the pointer of the bubble
		fadeDistance = 50; // the distance from where the bubble will fade in

	// append the message to the bubble, position it and slowly fade it in
	bubble
		.find('span.content').html(msg).end() // insert the new message
		.css({
			top: offset.top - bubble.outerHeight() - pointer.outerHeight() + this.outerHeight()/4 - fadeDistance, // the element offset minus the height of the bubble, minus the height of the pointer, plus one quarter of the height of the element to be on top of it, minus the fading distance
			left: offset.left + this.outerWidth()*0.75 - 42 // the element offset + 3/4 of the element's width to position the bubble at the right side, minus the pixel width to the edge of the triangle
		})
		.animate({
			opacity: 1, // fades it in
			top: '+='+fadeDistance+'px' // moves it in from the fade distance that we substracted above
		}, 600);

	// make sure the bubble goes away when clicking on the hinted element
	return this.one('click', function() {
		bubble.animate({
			opacity: 0, // fades out
			top: '-='+fadeDistance+'px' // animate back the fade distance
		}, 300);
	});

};

That’s it. Now all you need to know is it’s usage, but you probably know it already:

$('#myButton').hint("Click here to make it explode.");

This will blend it your hint, and as soon as you click on the element, it will fade away again. Sweet, huh?

The usability series: Responsiveness

Usability is something I consider a major part of my professional life. I even tend to think of it as the key to any good website or application. If it’s unusable, it doesn’t help if it can spit out flying dragons. That’s why rather than doing one summary post on the fundamentals, I decided to discuss one usability pattern at a time and dig into it really deep. As first entry in this series, I decided to go with a key fundamental often forgotten even by the pro’s – responsiveness.

What’s it all about?

For real people to actually use your application in daily life, it’s not enough to bundle it with a nice UI and a bunch of cool features, it has to be really responsive as well. The reasoning is simple – people hate to wait. People hate to wait in
lines (except the British, hehe), they hate to wait for their salary, they hate to wait for the weekend to arrive and they
hate to wait for the next season of their beloved TV series. Ok, sometimes the anger can transform into excitement (and vica versa) – but raise your hopes too much, this seldom happens in the case of web apps. Yes, people hate to wait after the click.

Responsiveness is often described by how quickly an application reacts upon a user triggered action. Basically everything we do in the web is interaction – the website or application waits for an user action and then replies. There has been already a lot of research on today’s topic, concluding for instance that people already get the feeling they’re waiting if the result doesn’t come up in less than 0.5 seconds. But the answer to the problem is the tricky bit.

The obvious solution: Performance optimizations

Many of todays apps and websites are Ajax driven, to the extend that a user initiated action triggers a request to the server. This is why the most obvious solution coming to mind is to improve the time each request takes. Be careful though – this is also exactly why responsiveness is so often forgotten in the frontend planning. People tend to think of it as something non-visual, therefore they let the backend guys do the work.

Now after you speeded up the requests and your backend, you have to take the frontend really serious. The JavaScript powering your website is often the most visible bottleneck because it’s directly happening on the client, even before any backend request can happen. And it’s not only JavaScript – heavy usage of CSS Frameworks (especially resets) for instance can horribly slow down any application as well. Remember – if your frontend performs bad, the backend guys don’t even have a chance to make up for it. Of course I could go into detail how to actually optimize your code, but that’s content for another blog post.

Transparency and disguise

In the last couple years I noticed a general pattern when designing a responsive experience. There are essentially two ways to tackle it: The first is total transparency – the user should never be clueless, and if the application is in a loading state, tell it to your user so he doesn’t get annoyed too much. The second, and to me the one with almost unlimited potential is illusion.

Fixing the experience without fixing the implementation

Something only very few people I met realized is that an application can be improved even without fixing the implementation. There is really only one thing that matters to the user – how the application feels. Yes, let me repeat that: Your implementation doesn’t have to be responsive – it just has to feel that way.

Apple – masters of illusion

The best way to describe what I mean by making your application *feel* responsive is through a perfect example. It’s the best illusion of responsiveness I’ve ever seen so far. I’m talking about the iPhone.

The iPhone runs a very sophisticated operating system based on Mac OS X, with thousands of API’s for developers to use. Combined with the fact that the iPhone isn’t running particularly fast hardware (more than a standard cellphone, but way less than any netbook), simple performance optimizations could only get you so far here, and this is is where the magic comes in.

Almost every interaction on the iPhone uses an animation to transition from one state to another. You’ll see animations when you launch or quit applications, when you slide through screens and on many other instances, sometimes so tiny you don’t realize it. Since they’re very well integrated into the general flow of the interaction, they not only excite users but serve as visual cue helpers that let the user ‘grasp’ what’s happening. But the key is what happens during the animation: Any application you launch or close on the iPhone needs time to initialize and to de-initialize. You guessed it already: It’s all done when the user is distracted by a beautiful zoom effect. How cool is that?

As a summary: At the cost of slowing down the operating system in technical terms (every animation takes a fixed amount of time), Apple improved the whole user experience and made the iPhone feel extremely responsive.

Loading indicators

As a conclusion to the illusion technique, in 90% of all cases a loading indicator is evil. Why on earth would you want to highlight the slow parts of your application? That being said, a loading indicator is always better than a frozen state and a clueless user. As a general rule, only add a loading indicator to your application if all other improvements fail. For instance, there are situations where you absolutely can’t predict when the result will arrive. Imagine a multiplayer game with two players, and you’re waiting for the other player to select his character. In this case you have to notify the user that the game is waiting for a response.

See you next time!

Taking Usability to another level

So I love that my main interest is finally a hot topic, and recently, Aza Raskin continued doing a great job evangelizing Usability in web and application design, making it more popular than ever.

However, our efforts to usability are still limited to one single angle: The actual end user experience. While this is unquestionably the most important part, we can’t ignore another: Usability for developers. Since tackling the whole world of development is too much for one blog post, we’ll only investigate web development here.

Syntax & API

Why are certain programming languages more popular than others? Usually not because they’re faster – not even because the input or output is smaller. A single argument counts most: The easiest understandable, the one with the greatest learning curve wins.

Think about it – while binary approaches to languages and data formats are much more efficient, it’s a pain to work with. Take JavaScript – due to it’s flexible and dynamically typed nature, it’s not always the most efficient way to code – however, it’s the most popular.

Let’s think about a higher abstraction: JavaScript libraries. jQuery, for once, is highly popular amongst web developers because the API has a natural, language-oriented aspect. It’s almost neurologic – by looking at a certain block of jQuery code, you start to almost guess what the other functions could be named like.

Now, as soon as you have a good concept of the API using real-world language, easy to understand by simply looking at it, there needs to be a next step: Make the learning curve as small as possible. This can be done by providing a complete and solid documentation, demonstration of every feature, walkthrough tutorials and ways to communicate within the community (forums, mailing lists).

So, in other words, for a web programming language or toolkit/framework to be developer friendly, the following arguments (at the very least) need to apply:

  • Real-world language when naming API calls (do, write, make, etc)
  • A high learning curve, achieved by
    • Good documentation
    • Good demonstration
    • Good communities around the project (forums, mailing lists, etc)
    • A strict API design with no or little exceptions

Of course there’s more to it, but this should give you a good start (by the way, this works for most development, not only web development).

Tools

The second very important field where usability needs to be improved are the actual tools web developers use to create applications and websites. It’s no wonder Dreamweaver is ridiculously successful – it’s not necessarily something that outputs great results (although it can, if you’re disciplined!), but it’s simply so damn easy to use.

Web developers usually have to use tools for the following tasks, and the sub lists tell you how these need to beĀ  improved:

  • Writing the source code (IDE’s, Editors)
    • Better versioning integration
    • Helpers for refactoring
    • Integration with the browser engine
  • Creating and designing the frontend (WYSIWYG Editors)
    • Integration with the browser engine, instead of faulty preview modes (Dreamweaver CS4 has that, but they didn’t remove the preview mode yet)
    • Smart control panels that utilize a framework’s documentation to create fields / controls
    • Tight framework integration
    • Integration with actual design applications (i.e a bridge to Photoshop from Dreamweaver, allowing “live slices” to be be embedded into the Dreamweaver source, that update automatically as soon as I change the overall image in Photoshop)
  • Testing (End-platform, various browsers, Selenium [automated tests])
    • Semi-automated testing frameworks that run in a browser and serve a click-through for testers and mainly create experience surveys
    • Automated user tests, creating a ‘fake’ user that executes clicks and drags on actual websites and applications
  • Debugging (often integrated in IDE’s, our in the actual platform, i.e. Browsers)
    • One tool that debugs across various browsers, instead of great tools for each browser, i.e. Firebug, Dragonfly, the IE8 Debugger.

While there are some solutions that are clean, well designed and integrated for application development (see iPhone development), web developers still suffer. Especially testing and debugging is still a pain in the arse, and needs to be improved.

Conclusion

In the end, I think there is a lot that needs to be done to make the actual developers happy before those can make the end users happy. A developer in an inspiring environment can create things you wouldn’t even imagine.

On the jQuery UI side of things for instance, there’s still a lot that needs to be done, but what’s really great is that we realized that our development cycle sucked. We have started to make developer tasks as easy as possible – there’s a new jquery.simulate plugin that triggers actual clicks and drags to ease testing, there are new commit hooks that will clean trailing whitespaces and there will be a project tool in the future that aids in documentation, testing and API design. We were also proud to be the first framework to announce web widgets in Dreamweaver.

So if you’re involved into a product that helps developers, think about how usable it is (instead of all it’s cool features), and help me and my comrades to make developer lifes easier, so they can create the great products we all love.