By default, in all major browsers, when you hover your mouse over text on a web page, the cursor changes from the regular arrow (the “default” cursor) to a “text” cursor.
You can see this demonstrated in the GIF below or by simply testing it out on just about any web page:
Never forget that usability lessons can be learned from virtually anything you use. This concept has been discussed extensively in Don Norman’s famous book, and I thought I’d discuss something specific in this area in this post.
Last week I sent out a tweet regarding an annoyance with USB plugs.
When you code a button or other clickable element, you need to also define a comfortable click area. Depending on the context and the design, this can sometimes be a challenge. Let’s look at a few examples in a short case study, so we can see the various ways this can be done.
Some navigation bars that I’ve seen are quite paradoxical in the click area they define. Look at the screen shot below showing the main nav bar for WebProNews.
I don’t mind drop-down menus. They give designers and information architects options for using screen space wisely. But I think many sites do themselves a disfavour by using them in an inconsistent manner.
The popular travel site Carnival Cruise Lines is a perfect example of what I’m talking about. I love the design of their site. For a travel website, it’s very good; it’s clean, and professionally designed. But I have one small problem with their drop-down menus.
Being a big baseball fan, I find myself perusing MLB.com pretty much daily. And if you read my site regularly, then you already know that.
Here’s something I hate about the way their navigational structure is architected.
I often go to the home page to scan for the most popular news items, or newsworthy stuff that catches my eye. If I don’t find anything to click on, then I might choose the “Standings” link.
Here’s a nice lesson for web app designers and developers, to help streamline the user’s progress when interacting with your application.
In many cases, it’s enough to log users in and then redirect them to the main screen of the app, where they can then choose what they want to do. It’s also good practice to send them back to whatever screen they were on before they logged in, instead of just sending them to the main screen.
But here’s a way to handle a user log-in when the user has not yet interacted with your pages, as shown below from PayPal:
There are some cases during the user experience where preloading content is not a good idea.
For example, if the user is faced with multiple options as to what content he will choose, then it would not be a good decision to preload all content. This would add unnecessary HTTP requests and bandwidth for both client and server, and would degrade the user experience.
But in other cases, using JavaScript (or some other means) to preload video or images is the right choice, because of the path the user has chosen to take. The website for Major League Baseball has a video page that I think could benefit from this kind of improvement.
