Twitter: Error Messages Should Be More Useful Than the Average Tweet

I have a 140-character message for the people at Twitter:

@twitter Error messages important. They should be avoided, but when needed, should be descriptive, helpful, and more than 140 chars. kthxbye

The other day, I was trying to send a direct message using the official Twitter Android app. For no apparent reason, I kept getting one of the following two error messages, at random:

• Sending direct message failed.
• Sorry, we were unable to send the message.

These are terrible error messages.

First, why are there two different messages that say the same thing? One is polite and one is brusque. Twitter, choose one and stick to it! Randomly choosing an error message is pointless, not user friendly, and complicates solving the problem.

Rule of thumb #1: There should never, ever be any randomization in error messaging.

Next, these two messages provide no information whatsoever. Years of experience as a failed user led me to interpret these as indications of a momentary outage of Twitter service, and that I should try again later. So, I did. Over the span of two days, I tried to send my message nearly a dozen times, each attempt denied with the one of the above worthless error messages. I decided to engage in some sleuthing, leading me to this discovery, buried deep within the Twitter help center:

Bingo! I was, in fact, trying to send a message containing a URL! My assumption was incorrect. "Try again later" was not at all the appropriate course of action... the contents of my message were invalid. After remedying this, I successfully sent my message, and moved on with my life.

Beyond the horrendous error messaging, and the burial of critical information deep inside of the Twitter support web site, lies a much deeper problem. It is outrageous to think that any string of length 140 characters or less could ever be considered invalid.

Rule of thumb #2: A string that is less than 140 characters is ALWAYS a valid tweet or direct message.

I could understand Twitter engineers discovering a theretofore unknown issue, and posting an explanation while they rushed to address the issue. But, the above explanation seems to indicate that Twitter knowingly decided to break messaging functionality during back-end restructuring. Why was it necessary to do so? When a URL-processing sub-system is taken offline, messaging should not be disrupted. At its core, Twitter (to its credit) is an extremely simple product: the dispatching of max 140-character messages. Everything else is icing on the cake, and optional. If users miss their URL shortening or click analytics data for a few days, no biggie. If users cannot send the messages they want, that's a biggie. Everything at Twitter, from normal operation to planned back-end restructuring to unexpected situations, should be organized around this central principle.

I'm not done here.

I also received the following additional error message:

• Direct message could not be sent. Recipient is not following you.

This is also less than ideal. First of all, at times, the message was patently false... the recipient was following me. Pardon my French, but that's quite a huge fuck-up, and heads should roll.

Regardless, should this ever be the actual case, it could be handled much better. Note that this an edge case, considering that opening a direct messaging dialog with a recipient who isn't following you is prevented. This case then only occurs if the recipient unfollows you sometime between the rendering of the dialog-launching menu item and the clicking of the send button (or in my case, it occurred for no good reason at all).

• As soon as it is known that the recipient is not following, disable the send button. Re-enable the send button as soon as the recipient follows you.
• Put up a word bubble over the disabled send button, explaining why it's disabled.
• Provide a button for an action that helps remedy the situation. Either by
• Facilitating the composing of a tweet that asks the recipient to follow you
• Sending a private "follow request". This functionality does not exist at the moment, but it should.

Furthermore, it is hard to learn how to call up the direct message dialog. I looked through the action menu for "Send a Direct Message," but it did not appear to be there.

Compare:

 "Send a Direct Message" only appears if the recipient is already following you. How am I supposed to know that? I continued scouring the Twitter interface, but fortunately, the interface is small enough to be covered completely in a short amount of time.

Rule of thumb #3: Menu items that cannot currently be actioned should be disabled, not invisible. Additionally, the reason for disabling should be clearly labeled.

Hopefully, with the new money raised by the recent IPO, they can spend some of that on buying common sense.

PayPal: Do You Ship Internationally?

I met a merchant at a bazaar (in real life) who had some exciting merchandise. She directed me to her web site to showcase the remainder of her inventory. I was interested in buying a gift for an overseas friend, and thus asked the merchant:

Do you ship internationally?

She said "yes, I can do that!" Overjoyed, I browsed to her web site, powered by PayPal's shopping cart system. After filling my cart, I then had been escorted to the PayPal checkout flow.

I'm always a bit confused by the PayPal checkout flow. It is designed to coerce the user into using default payment settings (bank account instead of credit card, which is cheaper for PayPal to process). I managed to pull up the shipping address dialog in order to input my giftee's UK home address.

I was surprised to find this:

The country field was set to United States, and was unchangeable. At that moment, I had become consumed with the question "why can't I ship outside of the United States???" After all, I had confirmed with the merchant, face-to-face, that it was possible. 

Rule of thumb #1: Avoid telling the user "no," especially when the user knows the answer is actually "yes".

To me, it was straightforward: shipping companies do ship outside of the USA. All the merchant needed to do was to stick an address label on the box, and all I needed to do was to pay the shipping fee. What would ever be the case for bolting down the country field? The only complications I could imagine are 1) taxes 2) export restrictions. Taxation, with all of its vast complexity, already has been implemented by PayPal, and would have been an inappropriate justification for altogether preventing my order. Export restrictions are an edge case, and had not been applicable here.

I started to pursue a solution to this problem. I had contacted both the merchant and PayPal tech support (twice). The merchant noted that, in her browser, she did have the option to ship internationally. She suggested working around this, by requiring that I provide a US shipping address, and then that I pay the remaining shipping costs in ad hoc manner. I was resistant, because this would have put me at risk, and also would have entailed my acquiescence to the flaws of a bad product. No one could answer the simple question of "why is this happening?" The best suggestion that had come from PayPal tech support was "there's something wrong with the merchant's integration." Both I, the user, and they, the support experts, were staring at the exterior of a black box whose inner contents were utterly mystifying.

Rule of thumb #2: If you must tell the user "no", provide an accompanying explanation, with actionable steps.

Imagine how much time would have been saved if the address form just noted "this item cannot be shipped internationally due to the merchant's preferences (or due to export restrictions). Please contact the merchant." Imagine, additionally, a button that auto-emails the merchant a message from a @paypal.com e-mail address with a boilerplate explanation of "a potential customer of yours desires to ship internationally. Here's how to reconfigure your shopping cart integration to do so." This functionality would not only greatly benefit me, the customer, but it would also benefit the merchant, and would leave out tech support altogether. Note that these fixes are rather cheap and easy, implementable in a few hours by a mediocre developer.

Unfortunately, the developers didn't have the prescience to implement this functionality. They erroneously decided that a hardcoded text field is just fine, when actually, it's rather tyrannical. The instinct for good user experience was just not present.

The next steps suggested by tech support were for me to implore the merchant to contact merchant tech support to ask for help in fixing a problem that she didn't care to fix. There is plenty wrong with this, but I may perhaps leave the analysis for a later date.