In my studied opinion, that is the case with error messages for the user that are generated by nearly(?) all software that employ a graphical user interface ("GUI"). The format of error messages has been obsolete since the advent of the World Wide Web ("the Web").
The defect is that error messages are universally written to the monitor in a form that blocks the user from copying the message to the system's clipboard.
Perhaps this was tolerable in the golden days of proprietary software when error messages commonly displayed a number that corresponded to an entry in the user manual that repeated the number and text of the message, then explained what to do if the error is encountered. If that didn't take care of the problem, there was always free tech support via a toll-free telephone number. But those days are long gone.
I strongly suspect that everyone who has made heavy use of software over the last three decades or so would agree that the trend in software user documentation quality has declined drastically over that period. With modern free and open source software in particular, the documentation is all too often downright skimpy and outdated or it doesn't exist.
(That is not to suggest that proprietary software has no documentation issues. Witness Windows 7, whose Help file provides no navigation instructions to locate the needed control, but instead provides a hyperlink to activate it. Amazingly, the Win7 Help file is itself becoming a GUI, disregarding the extra steps it takes to activate a control compared to navigating to it, if you only could learn the navigation steps. I dare say: this was a giant leap in the wrong direction.)
With the advent of ubiquitous networking and the Web, software users can often work around the absence of supporting documentation for error messages, by transcribing the precise text of the message to a Web search engine text entry field, surrounded by opening and closing quotation marks to search for the exact string. Up pops the needed information in the search results page because someone else has already raised the question and received an answer.
Unless, that is, the user has made a single transcription error with a single erroneous character whilst laboriously switching back and forth between the program's message box and the the browser's search engine page to keyboard the message's text. Then the endeavor transitions to a proofreading and correction exercise and anger over the perceived developer user-unfriendliness grows.
But the anger is often misdirected at the program developer when its target more rightfully should be the developers of a GUI toolkit, which provides the widgets from which a program is assembled, with the program developer providing further code that ties the widgets together to perform particular functions, akin to adding frosting atop a cake.
GUI toolkit run-times generate their own error messages. Should the program developer use a different widget to display error messages that are copyable, the appearance of the run-time and program error messages will near certainly differ in appearance, introducing a lack of uniformity in messaging format. And only the program's own messages would be copyable.
Too, there is that powerful force of custom: error messages have never been copyable; why should the thought of making that change ever occur to a developer? So I think this is a usability bug that needs to be repeatedly reported by software users to GUI toolkit developers until they get the message: non-copyable error messages are obsolete and a serious usability bug. Reporting the bug to program developers is a waste of time; it is the GUI toolkit developers who need to hear that message.
What's in this concept that benefits software developers?
- Ultimately, a drastically reduced technical support burden, particularly if the user troubleshooting technique of copying error message texts and searching for them on the Web is publicized in documentation.
- Developers thereby enable and encourage users to develop web pages that list error messages in numerical order, along with instructions on how to stop the message from appearing.
- Developers gain a far better excuse for not documenting error messages themselves. :-)
I encourage all software users who read this to report non-copyable error messages as a severe usability bug to the GUI toolkit developers their software depends upon. The following web search will usually produce a link to the given GUI toolkit's bug reporting system (where XXX is the name of the GUI toolkit):
How to report a XXX bug
Wikipedia has a helpful list of widget toolkits. And please feel free to link this article in your bug reports.
Addendum: On September 8, 2015, the version 4.0.8 release of the NoteCase Pro outliner implemented copyable content in all message boxes, in part because of this essay.
No comments:
Post a Comment