In my daily work I come across more than my fair share of interfaces. These are internal tools, off the shelf, and external web sites. Today, I came across an external web site that inspired me to post a blog entry.
It must be an epic event!
No, it was the use of three different verbs to describe the same action in the help text.
In an employee survey, names withheld to protect the innocent, I was taking they have three verbs to describe the "click the next button" action.
First, there was the always confusing, to me "select".
Secondly, there was the slightly more correct but confusing in that it's an indirect action "push".
Finally, they said "press", again an indirect action.
I may disagree with the verbs used in the help text but the greater message here is that interfaces are about consistency, especially help text. If you don't make me think, or distract me from my goal - getting to the next page, you have succeeded.
The next time you are using an web form try to keep track of the different verbs used to help you - you might find they are doing the opposite.
I have been working as an official business analyst for just over 10 months now and one large piece in my current position is to be the user advocate. This typically manifests itself as lead tester of software. I have been watching a trend, here in Whitehorse, that sees an increase in the use of links as buttons, or link buttons. These link buttons are used on forms and are usually used to indicate a secondary action - the primary action is usually a button.
First off, I am not an official interaction designer (IxD) nor am I a guru in this space but I have implemented a lot of interfaces on lots of different platforms, soaked in the design guidelines of many platforms, worked closely with IxD people and have what I consider a decent eye for a usable interface. That out of the way...
My primary concern with the use of a link button is that it is running against 15 years of ingrained mental models - a link navigates; a button signifies an action. Using a link to signify an action breaks that mental model. It requires users to think if they are triggering an action, such as submiting a form, or navigating to another page or application screen.
A secondary concern is the web browser can store that action in it's history allowing the user to use the Back button to return to the previous state. The user probably does not wish to return to this location, but navigation actions are stored, button actions are not store in the same manner.
Link buttons get more twisted when working with the web as application. In a regular desktop application I have not seen links to signify actions - they are navigation links to help files, web sites, other external locations. Pure navigation. However, in the web as application the purpose of the link can be used for dual purpose - because of design decisions. I state that you can use other techniques to indicate primary and secondary actions without causing user confusion or design issues.
I propose an end to the use of the link as button on website. It has the potential to confuse the user, it breaks the mental model of what purpose a link serves and the usability aspects can be accommodated using standard input tools.
This forum thread comes from this argument from the other direction (buttons as navigation) but the arguments are the same in reverse.
If ever there was a company I want to root for it's Jive. This little company is churning out some great product right now and the most recent developments in their collaborative tool Clearspace make me think this support is not unfounded.
This tool is a light weight wiki/DMS/IM platform that plugs in beautifully with their open source XMPP (GTalk/Jabber if you aren't hip on the lingo) offering - Openfire. It also has plugins to connect to all those nasty proprietary networks as well (MSN, Yahoo, etc).
The applications themselves are well designed, have very clean UI and the admin console is very shiny and usable. The bonus to all of this: they just work. By using clever engineering and good architecture this platform combination will run on practically every Java supporting host known to business. I like that.
In addition the integration of the IM piece with the collaboration piece is well thought out and seamless. You can see who is where and if they are available... presence to the N'th degree here folks.
And it's cheap. Free for less than 5 people and 29$ (US) a year/user for more.
If you have the time/inclination - check it out! You will not be disappointed.
So, Apple released the latest and greatest version of iTunes! Version 7.0!
So, what is good -
What is bad -
I have been using GMail to host my domains email for about two years now with no problems. Its a hassle-free, inexpensive way (free!!) to manage my email for my various domains. If you don't mind your email becoming part of the zeitgeist then this method of email hosting is for you.
However, as Google moves towards a more one-stop-shop-for-everything-web-related a schism is beginning to form in my usage of their tools. Namely, I use @justwerks.com as the email address I promote as the "way to contact Evan"; however, I use a @gmail.com address to sign into Google.
See where this is going?
I need to have the ability to tell Google that the @justwerks.com (among others) address maps to @gmail.com. As it stands I cannot accept invitations from the Calendar app unless people send email to the @gmail.com address, which breaks the entire purpose of using @gmail.com to transparently host my domains email. I am then left in a situation where I have to let people know both my @justwerks.com and my @gmail.com address. No, no, no, no.
The purpose of using @justwerks.com is to promote a branding message of "@justwerks.com is the way to contact Evan"; not "@justwerks.com is the way to contact Evan unless its a Google Calendar invite, in which case use @gmail.com".
Anyone have any hacks/configuration switches to work around this or should I start a blogging campaign?
There is nothing like dropping a Led Zeppelin song title to start off a random tangent but I digress.
I have been thinking about development recently and more specifically development failures. Each and every company I have been a part of, or will be a part of, there has been communication failures. These have been as simple as forgetting to implement a simple feature request to the much more critical.
I believe I know the root cause of communication failures: email.
I renewed my driver's license today and was asked to perform a vision test. I had to the usual : read this line of tiny text, which side of your head is the flashing light on, look at the grid of coloured circles and name them off.
Then this evening I was reading an older article on evolt.org about designing for colour blindness.
I then started to ponder the problems faced by users that can see the entire colour spectrum and how they are equally affected by colour schemes that have little variation in highlighted areas or previously visited links.
The rising popularity of AJAX in the "web 2.0" crowd brings some usability issues that may be unheeded by developers keen to use the latest and greatest technology.
As a brief overview : AJAX is a combination of Asynchronous Javascript and XML (with a helping of DOM tree manipulation). Essentially these elements combine to allow the developer to create a dynamic web page that does not require a full page refresh.
Now, when designing these great new applications there are a couple of rules that must be followed else the application confuse the user to never be used again. (Hardly a model for success in the web world!).
In the past two months I have had to explore the business community of the Yukon I have come to realize that it relies heavily on meeting people. Great, easy to do right? This is a small town. (20 000 people or so).
Now, imagine you have been brought up in the age of the internet and wish to find contacts/comanies/anything in, say, Whitehorse.
Go ahead, use Google, I dare you.
