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

by @edent | # # # # | 3 comments | Read ~106 times.

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?

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:

Old Style

Old Style

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

New Style

New Style

(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.

Direct Message Warning

Direct Message Warning

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?

3 thoughts on “Don't Let Users Do Things They Can't Do

  1. Tom Parker says:

    "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."

    If you're editing a configuration file manually (as opposed to using a GUI tool that edits that type of config file - which is usually the best way to mix the Unix paradigm of small text config files plus this issue), then you should really either a) know exactly what you're doing or b) be staring at the documentation for that file at the same time, otherwise yeah, you're in for a potential world of pain. Most things these days on a modern Linux system where you'd have a GUI dialog capable of editing that setting on other OSes also have a GUI dialog on Linux.

    Also, if a bit of software isn't sanity checking your input (which config files definitely count as), then it's a damn fool piece of software which needs a bug filing...

    1. I quite agree - the only problem is the lack of GUIs for essential / low level software.

      For example, when installing Ubuntu Netbook Remix, I was prompted to edit "/etc/modprobe.d/blacklist.conf" and then to fiddle around with GRUB or something else equally sensitive to typos.

      As an aside, it always amuses me when you run
      foo --help
      and get
      Foo is a program to bar. Valid options are
      foo --AGbgvxL

      Yeah... great help that! I know, I know, I should add documentation and feed back upwards.

      1. Tom Parker says:

        Yeah, the modprobe blacklist is one of those "someone needs to write a gui for the common use cases, but no-one's been bothered enough yet". To some extent this is because it's essentially a nasty hack to work around dodgy drivers, but that's always going to be the case for some drivers.

        (FYI, I just filed http://brainstorm.ubuntu.com/idea/23776/ which might get something done eventually...)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.