Archives for posts with tag: ui

Is your software development a linear conveyor belt of bottlenecks?

This post describes my experience mixing Agile + User Experience design while building out the mobile site for thoora.com.  While this process worked for us, it won’t work for everyone/every project, however it allowed us to minimize blocked tickets and maximize the time of our small development team.  Breaking the work into manageable stories, and parallelizing the work early and often is a great technique to maximize output and manage the traditionally serial and inherently blocking jobs and responsibilities when mixing UX and Agile methodologies.

Read the rest of this entry »

I don’t know why, but I never really used Delicious.com (actually I had an account a long long time ago).  I recently made a new account and came across an interesting UX scenario.  It took me like 30 seconds to figure out how to actually make a bookmark (and yes, I was trying, and no, I am not an idiot). Once I figured it out, it was simple, but it got me thinking of an important web principle: “Make your core feature offerings DEAD SIMPLE to find.” While companies probably don’t like getting simplified down to a single feature, that is often what makes them popular. Using a technique from Steve Krug’s “Don’t Make Me Think,” lets see if we can figure out what some popular websites are trying to offer to us. Instead of showing a normal screenshot, each shot has a light gaussian blur applied to it.  For me, this is how I often “see” my own work through the eyes of a new visitor.  I also came up with some unofficial one liners for each:

Step 1: Create a Call to Action

It’s interesting, because you can find a lot of great design resources and AB tests on “sign up” or “buy now” buttons. However, I rarely see discussion on action items in terms of core functionality of a web application or service.  This first caught my eye while reading “Designing Web Interfaces” (pg. 82-83) on “Clear Call to Actions and Relative Importance.”

Youtube: Upload and Share videos

Notice the bright yellow blob in the corner -- the "Upload Video" button

Digg: “Digg”/Rank stuff from the web

Notice the 3 yellow/tan blobs running along the left - "DIGG" buttons

WordPress: Write and post blogs

Notice the blue blob on the right - the "Publish" button

Read the rest of this entry »

I made an analogy once a while back about error pages on websites.  When you are browsing a nice website and you get slammed with a default or ugly error page, it is like going to a really fancy restaurant only to find a really terrible bathroom.  Now this may seem like a really weird analogy, especially because I have seen some really nice bathrooms before, but ignoring this issue can really disrupt a nice meal, or for web users, can really disrupt their user experience.

Where did all my pretty colours go? I just wanted to watch cat videos!

Ideally, if someone typed in a URL wrong, or heaven forbid clicked a deadlink on your site, I think it is only fair to quickly explain the problem and help them along their way quickly.  Remember, arriving at error pages is a frustrating experience.  Your user did not mean to get there, and the customer is always right, so it is your job to apologize (if you choose) but more importantly comfort them so they don’t just leave.  By maintaining the same look and feel, the users don’t have the huge context switch that they might experience on a default error page served by Apache or IIS. This is how we handled it at http://thoora.com (Yes I’d like to think we are somewhat fancy)

Maybe not as fancy as the bathroom at the Ritz, but hopefully it shouldn't ruin my customers' meal

Note the link to the main page which quickly ushers them back to the regular service.  Now more and more you tend to see graceful error handling, but I think it is good not to go overboard.  If we don’t clearly illustrate that an error has occurred the user might not even know that something has gone wrong.  Now arguably one could say that hiding errors from users is good if possible, but if we encounter a 404 and the resource literally doesn’t exist, we should tell them.  I have seen error pages that look exactly like other pages, so over designed it is hard to tell what is going on.  Similarly, I have seen pages that treat a missing page as an invitation to serve me something completely different (although I might not be completely opposed to a recommendation of similar alternative pages).  When something goes wrong, let them know and help them recover gracefully.  This is especially true for the other type of visitors on your site.  The visitors that probably visit more often than you think, and really care about these dead pages.  The robots.

While decorating a bathroom, and having a guy handing you a towel is great, you still have to call it a bathroom.  If you don’t, Google (et all) will be constantly directing some of your traffic straight to your bathroom instead of your dinning area.  The robot needs to know that something bad happened and Apache (and most web-servers) will serve them the correct HTTP response code for you.  I can’t talk about this without thinking of an old commercial I used to love.  I laughed so hard every time I saw this (its been years since this campaign was run). Below is a screenshot of Firebug capturing a nice 404 back from a server. This lets your browser know, and more importantly the spiders/robots know that even though it looks nice, something went wrong (Tim Berners-Lee would be so happy).

Bots aren't as smart as (most) humans, they need help from time to time

So if you are going to fail, fail gracefully.  And if you are going to customize your errors, make sure you don’t forget about the robots.  On a side note I encourage all to use Google webmaster tools to see what the spiders are tripping on.  Google is great at finding links you didn’t even know existed on your site ;)

Further reading: ISBN-13: 978-0735714106

This post will probably make people think I am insane for bring up such a small issue.  But little things bother me, and this little thing has bothered me for years, and I have been waiting for Microsoft to fix this.  No matter what email client you choose to use, there is a set of basic features that all must support.  Once you start looking at competitve advantages, little features make the difference.

Target for today’s discussion: Windows Live! Hotmail

As a synopsis (to those who don’t want to read the whole post): Unlike all of its major competitors, Hotmail does not allow users to mark emails as unread within the context of reading an email.  As a secondary, they provide buttons that don’t actually do anything.

I will also look at some competitors: Gmail, Yahoo! Mail, and Facebook’s Message Inbox

The left navigation area of 4 popular message/email clients

I use a lot of email clients, gmail/hotmail mainly.  I also use 2 other lesser known clients but mostly to keep up on innovations in the UI etc.  Over the years, (after gmail came out) Yahoo! Mail seemed to be the only client that made improvements or drastic changes to their interface.

I took this above screenshot because it demonstrates how I (and many others) use email.  I generally try to keep my email box with 0 unread emails.  As it gets closer to Friday my work inbox sometimes gets up to 10, but I am pretty good keeping it low.  When I read a message and realize it is too long to read at the current moment, I mark it as unread.  Similarly, if there is an important email, with vital information I will need in the near future, I will mark it as unread.  Some clients allow the ability to mark or flag as important/follow up.  Most clients allow folders for organization.  Depending on the user’s level of organization they may have their own way of dealing with such messages.  Personally, I like to mark anything as “unread” until I have fully closed off all ties with that particular issue.  It is the one thing that at the end of the day, reminds me there is something outstanding (The big number beside my inbox).

Read the rest of this entry »