This post originated from an RSS feed registered with Java Buzz
by Elliotte Rusty Harold.
Original Post: Error Dialogs for the Internet Age
Feed Title: The Cafes
Feed URL: http://cafe.elharo.com/feed/atom/?
Feed Description: Longer than a blog; shorter than a book
Here’s a red error message Eclipse popped up on my screen today:
There are a lot of things to complain about here, but the main one is not obvious from a static screenshot (though it turns out a static screenshot has exactly the problem):
The message cannot be copied.
The first thing any competent computer user does when presented with an incomprehensible error message such as “No server type definition” is to Google it. Only why should the user have to type it in? This message should be able to be copied right out of the UI.
And why stop at error dialogs? Any confusing UI element should be able to be selected and copied. This is critical for tech support, debugging, documentation, and anything that happens when apps go wrong. Here’s a history window from Crashplan. None of these messages can be copied and emailed to tech support. If I want to tell them what Crashplan is doing wrong (something they refuse to believe can possibly be happening) I have to laboriously retype all this information:
This is one of the (few) things web apps often get right and desktop and mobile apps usually get wrong. As long as the UI is HTML, you can probably select it. Here’s a recent Firefox error message. The complete message is selectable so I can, for example, copy and paste it into an email to the site owner alerting her to the problem:
That’s not the only use for copyable text either.
I can (and did) easily use it for alt text of the above img element, which improves the searchability of the problem.
I can search for the error message in the Firefox source code repository, if I feel like fixing the grammatical error in the message.
There are probably a dozen other uses I haven’t yet imagined that are enabled by having easy access to the message as text.
Text is fluid and accessible, and admits many different uses, in a way screenshots don’t.
When writing UI code, resist the urge to display non-selectable labels. For example, in Swing never use the JLabel class because JLabels are not selectable without a lot of error-prone custom event handling code. Instead use a JTextPane and configure it so it looks like a JLabel:
JTextPane label = new JTextPane();
label.setText("Something bad happened!");
label.setEditable(false);
label.setBackground(null);
label.setBorder(null);
In some circumstances, you may also want to change the font to match what users expect in a label. Exploding Pixels has instructions for doing that if you find it necessary.
I blame Oracle for making this necessary. Why do toolkits even allow non-selectable text? There should be no such thing as an unselectable, uncopyable label. Uneditable, yes; but not uncopyable. JLabel must die.
Widget libraries (GTK+, Cocoa, AWT, Swing, SWT, etc.) should remove non-selectable labels. The default should be to allow the user to select and copy UI text.
There are a few widgets that have non-selectable text because clicking them already does something else. Enabling selection of menu items would probably confuse less dexterous users who select a menu item they mean to click. Perhaps buttons as well. But all labels — that is, all strings of text whose primary purpose is to be shown to the user — should be able to be copied and pasted. It’s simple respect for the user.
Previous Topic
