Make less interface when you can

Smart programming isn’t always about the hard stuff. Sometimes, it’s just doing the simple, but clever, things. Here’s a tiny example.

I spent a few hours this weekend implementing the Basecamp API into BugSpray, our home-grown, web-based bug tracking tool. This lets Basecamp users import a project, companies, and users from Basecamp over to BugSpray.

To access any call to the API, four things must be known:

  1. The URL domain to someone’s Basecamp project.
  2. A valid Basecamp user name.
  3. A valid Basecamp password.
  4. Whether the project is running under SSL (http v. https).

From an interface perspective, this seems pretty straightforward. Three text fields, one set of “http/https” radio buttons, and off-you-go! But, that user experience is rather odd.

The obnoxious bit is, you need to know whether you are indeed running Basecamp under SSL. I’d imagine most users don’t know. The instructions “Login to your Basecamp account and see if the URL in your browser has http:// or https:// in front of it” sounds kinda-like-not-a-great-time.

Instead, I simplified the UI to this:

When a user passes BugSpray the info, the code makes two calls. First, it tries calling the URL with login credentials under httphttps. If it gets through, yippee. If it fails, it tries calling the URL with login credentials under httpshttp. If it gets through, yippee. If it fails, then it notifies the user that the login credentials are probably wrong. *(see addendum)

The SSL issue is still there, it’s just a business logic issue rather than a user experience issue. Instead of asking the user, “Is your Basecamp site under SSL?” it just tries both. The slight performance hit of the potential extra call is certainly worth the user experience gain of not having to think about whether you’re Aych-Tee-Tee-Pee-Essin’ it. And, once the code successfully connects to the API the first time, we already know the answer to the https question for that user. Subsequent calls to the API don’t have to run through the double try-catch block.

Before you go filing this post under the “ho hum” programming tip of the day, just remember all the tiny little clever things you can do under the covers to make less interface.

* An addendum regarding authentication security
In my original post, I stated that I first test the Basecamp call using http, and if it fails, I use https. A commenter correctly pointed out this is a horrible idea since those who have SSL on will have their credentials initially sent over http under clear text (technically base64-encoded because the authorization happens over basic authentication).

Here’s how I’ve fixed this issue.

Now, I call https first, and if it fails, I call http. Now, a Basecamp account under SSL will successfully login without worry of sending credentials over clear text since the https call attempt happens first.

But, there’s still a loophole. Suppose the credentials were typed incorrectly. Then, the https call will fail and the http call will be attempted. But, if the Basecamp account is, indeed, under SSL, we’re sending credentials (albeit the incorrect ones) over http. That’s not good enough security.

To stymie the loophole, I now check the error response on the initial https attempt. If the error is an unauthorized error (401), I know that the credentials themselves are wrong (regardless of whether https or http is the correct protocol since the server authorization occurs before the page is requested). In this case, I don’t attempt the http call at all since the credentials are wrong.

Otherwise, I check if the error is a protocol violation exception. This means that the credentials are correct, but the protocol is wrong. Only then do I attempt the call under http.

A bit more thinking then initially anticipated, but now we still get to keep it out of the UI without the security issue.

7 responses to “Make less interface when you can

  1. I’ve never used Basecamp so maybe this isn’t relavant, but I assume a project available under HTTPS is also available under HTTP? So wouldn’t it be better to try the HTTPS option *first* ?

  2. I’m with you on this. And thats one of the first things I noticed when i used OSX. For instance if you setup in mail account it tries several settings whithout the user noticing it, choosing the most secure first.

    What was you decision process for testing http first and not https? Is it because most people don’t (or can’t because of pricing plan) use https? I would do ith the other way arround for security reasons but you approach might scale better when only few users use https.

    For me this is a good example of hiding implementation details. The user shouldn’t have to worry about what technlogies are used.

    Good example.

  3. I find your approach offensive. If I had an ssl account on any site the last thing I would want is someone sending my credentials in clear text without me knowing about it.

  4. @diabolickmachine- You have a point. I’m going to switch the ordering around now so it sends the credentials under HTTPS first. If that fails, then we could try it under HTTP. That solves the security problem a bit better…the only recourse being if you are running under HTTPS and happen to mistype your login info, then it would attempt the HTTP with your bad credentials in clear text. But, they’d be the incorrect parameters anyways. Thoughts?

  5. One compromise might be a check box labeled with something non-geeky like “I am very concerne4d about the security of my project data” – if this is checked, then only the https login is tried. A minor elaboration would be one of those “What is this?” links next to the check box label that when clicked, pops up a short explanation of the http/https alternatives. This approach reqiuires more programming, but as we all know, it’s hard work to make something both simple and sophisticated.

  6. @bob42–

    I’ve posted an addendum (see the yellow box at the end of this post) regarding the correct workaround. Fortunately, in this case, I still think we get to keep it simple for the user!

  7. Excellent post. And excellent comments that led to a relly neat final solution in the spirit of good usability. Voted up!

Comments are closed.