We received a message from visitor Jovan Milosevic asking that we look at the popular shareware game Pirates: The Quest for the Seas. Normally, we're not too interested in games and game interfaces, since gamers seem particularly tolerant of the interfaces they are required to use; in many cases, overcoming the difficulties of the interface is part of the challenge of the game. However, the screenshots Jovan included with his message very much caught our attention, prompting us to suggest a different name for the program:
Pirates: What happens when a GUI is designed by someone who has never used a GUI
We can offer no opinion as to Pirates' quality as a strategy game. TUCOWS rated the game as having 4 out of 5 cows, causing us to seriously question the integrity of their rating system, which purportedly requires that a program in this category "has a cool, intuitive interface", and be "user friendly". The poor quality of the user interface in Pirates did not inspire us to sacrifice the time necessary to learn how to play the game. While Pirates is a game, we have seen many of its interface failures in corporate applications and felt that it was important to discuss the underlying reason: the developer didn't have the faintest notion as to how to design a graphical user interface.
We recognize that some visitors may disagree with our assessment of particular features of the application, and we invite your feedback. Comments can be sent to bchayes@iarchitect.com.
Last updated 20-February-1999
Let's start this discussion with what is perhaps the most bizarre password dialog we have yet come across:
Apparently, and this is learned only after much consternation, the user is expected to type the password into the ... Cancel button. As characters are typed, there is no indication that the input has been received other than the fact that the blinking cursor moves to the right as characters are typed. Placeholder characters are not displayed, so there is no feedback as to the number of characters typed. Moreover, there is no visual indication as to how to "submit" the password; the user is expected to simply hit the Enter key upon completion of the password. We didn't want to; we have come to expect that when presented a dialog with a single, enabled command button, pressing the Enter key will select that command button. If you have entered an incorrect password, the program behaves as if you didn't enter a password at all; no feedback is provided other than the fact that the password dialog disappears.
The main window of Pirates includes a menu bar, and an array of command buttons. Interestingly, when the game first starts, the menus are useless; while they seemingly offer functions, the functions themselves do nothing. Of the seven menu titles shown, only the last two are functional, and unlike the other five, these are commands, not menus. The menus become relevant, and functional, only after the user has initiated a game using the appropriate command buttons.
Windows users will notice that the main window does not have a system menu icon (normally located in the upper left-hand corner of the window), and that the window close button (the X in the upper right-hand corner of the window) has been disabled. The Turn menu offers a "Save and Exit" function, but this does nothing, until the user has launched a game. The only way to quit the program is to select the "EXIT PIRATES" command button. Thus, the designer has disabled all the typical means of closing a program used on this particular operating system, and required the user to perform an operation that is not normally performed in the operating system (selecting a command button from a window with a menu).
Some of the menus themselves are worthy of note. The Music menu, for examples, offers two choices, "Music On" and "Music Off". Perhaps because the developer had not yet learned how to place checkmarks in menus, there is no indication as to which option is currently in effect. The Animation menu is similarly designed.
There is a potential interesting consequence of this design that should not be unexpected. Pirates plays a short tune when the program is first run. Selecting "Music Off" during this tune has no effect on this tune (nor on the irritating Parrot Screech sound played whenever a command button is selected), since the Music menu is disabled, despite is enabled appearance, until a game has been initiated. Thus, the new user could reasonably conclude that the program has a bug: Music Off did not turn off the music, and selecting "Music On" will not cause music to be played. Similarly, the program displays a sailing ship in the opening window, yet the "Sailing Animation On" menu option does not initiate animation. Some users might never try these menu options again, and some, we would expect, would simply remove the seemingly "bug-ridden" program from their PCs without exploring further.
We chose not to remove the program just yet. We wanted to learn enough about the game to be able to fairly evaluate its interface, and chose the "How to Play PIRATES" menu command. We were then rewarded with perhaps the worst Help system we have yet to come across, part of which is displayed here:
The Pirates help system consists of a very lengthy ReadMe-like textual description of the game, and 20 command buttons to navigate to sections of the document. We're just grateful that the game wasn't so complicated as to require 40, or 50 sections; thankfully the relative simplicity of the game left some room to read the help file. Despite the plethora of buttons, there were two that were noticeably absent: "Close (this window)" and "Print". The only way to close the help window is to select the Windows close button (in the upper right-hand corner), and it should be noted that this is one of the very few windows in the program in which this button is enabled.
The Print button would have been a very helpful addition. The "help" is quite lengthy, and is displayed in a restricted and unchangeable window size. We have no doubt that many users would have preferred to learn about the game at their leisure away from the computer rather than be limited to the display method programmed into the application.
As an alternative to the Pirates help, the user could turn to the "Pirates Tutorial", which in all fairness, provides detailed assistance in how to play the game. The tutorial, however, is not without serious design problems.
First, like all of the dialogs in the program, the tutorial ignores the user's display preferences and uses hard-coded colors. Interestingly, we see this particular color combination not infrequently. Yellow text on a green screen seems to be the combination of choice for programmers that are used to older monochromatic computer monitors, and is a very good indication that the programmer has little GUI experience. The three-dimensional text chosen for Pirates is an extra bonus to make the text just a bit more difficult to read.
Secondly, while the tutorial window is resizable (by dragging the border), only the size of the window changes; the user is presented with a large white window with a small green area containing text in the upper left corner. Conversely, the tutorial can be minimized, but doing leaves the user in a state of limbo; the tutorial is a "modal dialog", such that the program ignores any input until the tutorial is closed in the appropriate manner; the new user that minimized the tutorial, purposefully or inadvertently, will have to search for the minimized window to have any further interaction with the program.
More importantly, the tutorial consists of dozens of screens similar to that displayed here. Unfortunately the tutorial is forward-only; while the "Next" button is clearly and unambiguously labeled, the other has no such label. The unfortunate user hoping to review the last screen will sadly learn that the button means "Go All the Way Back to the Beginning".
The file selection dialog in Pirates will undoubtedly create uncertainty for new users of the program. Instead of alphabetizing the items in the lists to make it easy to locate an item of interest, the developer chose to use randomly order the lists. To display the contents of a different drive, the user must (1) locate the drive by clicking on the tiny drive scroll arrows, then (2) double-click on the drive name. The Tab key can be used to navigate among controls, but the navigation order of the controls is random, each list object is actually two controls (the list and the scrollbar, thus requiring two Tab presses to move to another control), and since only the command buttons indicate that they have the focus, you rarely know which control you have landed on.
Perhaps it was the designer's intention of presenting a visually balanced dialog, but we considered the inclusion of non-command buttons to be particularly unbalanced. Apparently, when there are commands that apply in certain contexts but not to the current context, their labels are hidden from the user, and a placeholder for the button is left. In a typical Windows application, the button is given a disabled appearance, not unlike that of the "Exit Profile Viewer" button, which despite its appearance, is the only selectable button.
Here's a question for the developer: is the dialog a "File Navigator" or a "Profile Viewer"?
Needless to say, this is about as far as we ventured into the game. While we hold the position that game interfaces are often part of the challenge of the game, none of the interface "features" we've listed have anything to do with playing the game; they are all from the preliminary steps necessary to initiate a game. Thus, the complete lack of attention to the user interface cannot be excused by saying "it's part of the game". Rather, it's simply an indication that the developer has no practical GUI experience, and shouldn't be designing GUI interfaces until he or she has at least spent some time using one.