Don't Let Users Do Things They Can't Do

There are many "rules" when it comes to User Interface / User Experience design.  One that I try to stick to is "Don't let users do things they can't do."

It's one of my gripes with Linux.  If you're editing a configuration file, you are relying on yourself to sanity check your input - often without knowing what the limits are.

Take these two different examples.

In a text file, we might have:

#Maximum Widgets to fidget
maxW_to-F = 0

Whereas a GUI would show

How many Widgets do you want to fidget? 1 2 3 5

Even if you don't know the rules behind Widget fidgetting (must be a prime number lower than 7), the GUI won't let you choose a value that you can't select. The GUI doesn't prevent you setting an innapropriate value - just an illegal one. Your config file, however, could be set to any crazy value that a user type - often resulting in "unpredictable" results.

#Maximum Widgets to fidget
maxW_to-F = seventeen

It's with this in mind that I've made the following change to Dabr - the mobile Twitter client.

To Auth or Not To Auth? That Is The Question

Twitter's API has bug / peculiarity (reported to their discussion board) which causes Dabr to log a user out. Let me explain the steps

• User 1 (@private) has set her tweets to "protected".
• This means no one can see @private's tweet unless she allows them.
• @private has not allowed User 2 (@edent) to view her tweets.  She is protect from his view.
• @edent clicks to view @private's profile.
• @edent can see that @private has 42 friends, 17 followers and 3 favourites.

So far, this is the same behaviour on Twitter's website as it is through their API.  Here's the difference

Web

• @edent tries to see @private's followers and can see their names, profile pictures etc.
• @edent can also see @private's friends
• @edent cannot see @private's favourites (or even how many favourites she has)

API

• @edent tries to see @private's followers, friends or favourites
• Because @edent isn't allowed to see @private's info, the API returns 401 Authorisation Required.

This is where things get tricky. Dabr sees the 401 and concludes that the user has invalid credentials.  It then, as a security measure, clears the user's cookie and logs them out.

This may be a little harsh, but HTTP 401 essentially says that the authorisation has failed.

Fixing It

There are 3 ways that this could be fixed

1. Twitter could rationalise the API to allow access to the same content that a web user gets.
2. Twitter could return a different status code.
3. Dabr needs fixing.

So, how do we get Dabr not to log out when it receives a 401 only under these specific circumstances?

Looking at the code, we can see that Dabr simply sees the HTTP response code.  To fix it we'll need to pass extra parameters, check where the code was called from, investigate all the edge cases, add more logic to the system, futz around breaking things, etc... etc...

What a pain in the...

Or

Don't let users do things they can't do.

If a user can't see the information - why do we even let them try to see the information?  Why can't we just get rid of the link?

This is what a user currently sees:

We've established that they can't view followers, friends and favourites.  So we can get rid of those links (but not the information).

(Incidentally, I've changed the order of the links.  I've tried to group together similar items.  Followers, friends, favourites and lists go together. Then DM. Finally, follow, block, report spam.)

Now a user cannot click through to an unwanted error message.

Or

There is another way round this.  With "Direct Messages" we could do the same thing - simply remove the link if you're not able to send that user a DM.

Instead, we've taken the approach of displaying a suitable error message.

The advantage of this is that the user gets an explanation as to why they are unable to complete an action.

Your Thought?

Which do you prefer? Being unable to click on a link (with no explanation) or clicking on a link only to be given a warning message?