Once upon a time, when the industry had a good decade or two of actual user experience on graphical user interfaces, a set of good design rules were established. Most operating system development companies even had their guidelines for developers on how to create a standardized GUI for their programs so as to make them as easy and intuitive to use as possible.
These are mostly small things, but they are important. For example, if a program has a menu (as most graphical programs do), it should always be located in the same place in all programs (at the top, below the title bar) and there are certain menus that should always have the same name (such as "File" and "Edit") and contain the same basic set of commands (such as "Open" and "Save"). If a menu element does an immediate action, it should be named without any punctuation (eg, "Save"), but if it does not immediately do something but instead opens a dialog where more options can be specified, its name should use an ellipsis (eg. "Save as...") Dialogs should always have a certain set of buttons named in a certain way (and, in general, they should always have a button to cancel the action.)
And so on and so forth.
The purpose of all these rules and guidelines is to unify all programs, make them use a standardized format and layout for common tasks, and thus make it as easy as possible for users to learn to use a new program. Also, the rules are intended to make it easy and intuitive to know what something does (for example, as mentioned, if a menu element does not immediately perform an action but opens a dialog, and hence it's "safe" to select it without the danger of it doing any modifications, its name will have an ellipsis in it. This is an intuitive and standard way of knowing this, with a very small formatting guideline that might feel insignificant in a completely different context. It's all these small things that make a good GUI a good GUI.)
There are also many guidelines and principles on how to design a good GUI on a higher level. An example of such a principle is "if you feel the need to add a text label explaining the usage of some GUI element, you are probably doing something wrong". The usage of GUI elements should be, in general, intuitive and easy to understand without textual explanations.
Other useful guidelines include things like what color schemes to use in the application. These are often aimed at making the application easy to use for beginners and people with disabilities (such as poor eyesight.) For example, making gray text on slightly grayer background can be a bad idea because people with poor eyesight may have difficult time reading it. (The ability to distinguish between low contrast elements is often poorer with old people.)
Whatever your opinion might be of Microsoft, Windows 3.x was actually pretty decent in terms of GUI design. All standard window and dialog elements were clear, consistent, and easy to understand and use, and if a program closely followed the standard guidelines of Windows GUI design, it was significantly easier to learn and use than a program that deviated from it.
Lately, however, it seems that many companies are completely ignoring these useful guidelines, and aiming for something that they seemingly think "looks cool" rather than is usable.
A very common trend seems to be to hide things from the user by default. This trend probably started around Windows 95. While Windows 3.x always showed file names in full, at some point newer Windowses started hiding file name extensions by default. In fact, they started hiding almost everything by default: You only got a name (without extension) and a program icon.
That's right: A program icon. Not an icon representing the file type, but the icon of a program (the program that would open it.) This means that if you had two files with the same name but with different extensions (like for example "image.jpg" and "image.gif"), both of which were opened with the same program, they would be completely identical in the file browser. Not visual distinction whatsoever. It's impossible to tell them apart without doing some additional operations to find out. This is most certainly not good GUI design.
In Windows ME one of the most braindead ideas ever to come out of any company in existence was defecated by Microsoft: Let's hide "unused" menu items in menus. And, while we are at it, let's reorder the unhidden ones for good measure. This goes against all good GUI design principles in existence, it's a horrible, horrible idea, and should have never been even thought. Menus become basically the antithesis of what good GUI design is.
In Windows 7 Microsoft went even further with all this "let's hide everything from the user" ideology: Now they hide menu bars and title bars by default. This is supposed to make programs look hip and cool. However, it significantly decreases the usability of everything because now you have to do extra steps to get to a menu, and you don't get any useful information that a program may put in the title bar. (For example, web browsers typically put the title of the web page there, and text editors the title of the document you are editing.)
(I have never understood why Microsoft hates menus so much. They seem to be doing their hardest to get rid of them. What exactly is so wrong with menus? They are clear, intuitive and easy to use, they categorize actions in a hierarchical and intuitive manner, and they don't clutter the GUI because the dozens and dozens of possible actions are neatly packed into expansible menus. The more actions a program can perform, the more important is for it to use menus for this, rather than something else, especially since menus are a good solution and have been used for this purpose for many decades.)
One of the key GUI design principles is that buttons, clickable icons and anything that can be clicked should look like it, and if they are disabled, they should clearly look disabled (by usually being colored in dim grays). This is another rule that Microsoft has liked to break for a long time: Clickable icons are no longer distinguished from just decoration because their borders are hidden (are we seeing a pattern here?) unless you hover them and, what's worse, in some cases they are even colored in grayscale until you hover them, making it harder to distinguish if they are disabled or not. This is not how you do good GUI design. You shouldn't have to hover anything in order to see if it's an enabled clickable element. It should be obvious as-is.
Perhaps Apple knows better than this? Nope.
For example, open a new tab in Safari. How do you close this tab? It's not immediately apparent... It turns out that the close button of the tab is completely hidden by default, and you have to hover the tab in order to make it visible. Apparently this is supposed to be hip and cool, but it's a completely counter-productive design that makes the usage of the program less obvious for no benefit.
The current window and the other windows used to be clearly distinguished from each other in the first versions of MacOS X. However, as newer and newer versions have been published, this distinction has been made more and more difficult to discern. At this point the active window has almost the same title bar coloring as every other window, making it very difficult to see which one is the active one currently. Why have they done this? No idea. It only makes using the system harder, for no benefit.
Recently Apple announced that they would hide scrollbars by default. This was a real facepalm moment for me. I was like, "WTF? Are they going to hide everything in the future? Just don't show anything. What exactly is the point?" What possible use there would be in hiding scrollbars? No longer can you see where in the page you are by looking at the scrollbars, without having to perform additional actions to make them visible. This is almost as much a braindead idea as what microsoft did with menus in Windows ME.
These are mostly small things, but they are important. For example, if a program has a menu (as most graphical programs do), it should always be located in the same place in all programs (at the top, below the title bar) and there are certain menus that should always have the same name (such as "File" and "Edit") and contain the same basic set of commands (such as "Open" and "Save"). If a menu element does an immediate action, it should be named without any punctuation (eg, "Save"), but if it does not immediately do something but instead opens a dialog where more options can be specified, its name should use an ellipsis (eg. "Save as...") Dialogs should always have a certain set of buttons named in a certain way (and, in general, they should always have a button to cancel the action.)
And so on and so forth.
The purpose of all these rules and guidelines is to unify all programs, make them use a standardized format and layout for common tasks, and thus make it as easy as possible for users to learn to use a new program. Also, the rules are intended to make it easy and intuitive to know what something does (for example, as mentioned, if a menu element does not immediately perform an action but opens a dialog, and hence it's "safe" to select it without the danger of it doing any modifications, its name will have an ellipsis in it. This is an intuitive and standard way of knowing this, with a very small formatting guideline that might feel insignificant in a completely different context. It's all these small things that make a good GUI a good GUI.)
There are also many guidelines and principles on how to design a good GUI on a higher level. An example of such a principle is "if you feel the need to add a text label explaining the usage of some GUI element, you are probably doing something wrong". The usage of GUI elements should be, in general, intuitive and easy to understand without textual explanations.
Other useful guidelines include things like what color schemes to use in the application. These are often aimed at making the application easy to use for beginners and people with disabilities (such as poor eyesight.) For example, making gray text on slightly grayer background can be a bad idea because people with poor eyesight may have difficult time reading it. (The ability to distinguish between low contrast elements is often poorer with old people.)
Whatever your opinion might be of Microsoft, Windows 3.x was actually pretty decent in terms of GUI design. All standard window and dialog elements were clear, consistent, and easy to understand and use, and if a program closely followed the standard guidelines of Windows GUI design, it was significantly easier to learn and use than a program that deviated from it.
Lately, however, it seems that many companies are completely ignoring these useful guidelines, and aiming for something that they seemingly think "looks cool" rather than is usable.
A very common trend seems to be to hide things from the user by default. This trend probably started around Windows 95. While Windows 3.x always showed file names in full, at some point newer Windowses started hiding file name extensions by default. In fact, they started hiding almost everything by default: You only got a name (without extension) and a program icon.
That's right: A program icon. Not an icon representing the file type, but the icon of a program (the program that would open it.) This means that if you had two files with the same name but with different extensions (like for example "image.jpg" and "image.gif"), both of which were opened with the same program, they would be completely identical in the file browser. Not visual distinction whatsoever. It's impossible to tell them apart without doing some additional operations to find out. This is most certainly not good GUI design.
In Windows ME one of the most braindead ideas ever to come out of any company in existence was defecated by Microsoft: Let's hide "unused" menu items in menus. And, while we are at it, let's reorder the unhidden ones for good measure. This goes against all good GUI design principles in existence, it's a horrible, horrible idea, and should have never been even thought. Menus become basically the antithesis of what good GUI design is.
In Windows 7 Microsoft went even further with all this "let's hide everything from the user" ideology: Now they hide menu bars and title bars by default. This is supposed to make programs look hip and cool. However, it significantly decreases the usability of everything because now you have to do extra steps to get to a menu, and you don't get any useful information that a program may put in the title bar. (For example, web browsers typically put the title of the web page there, and text editors the title of the document you are editing.)
(I have never understood why Microsoft hates menus so much. They seem to be doing their hardest to get rid of them. What exactly is so wrong with menus? They are clear, intuitive and easy to use, they categorize actions in a hierarchical and intuitive manner, and they don't clutter the GUI because the dozens and dozens of possible actions are neatly packed into expansible menus. The more actions a program can perform, the more important is for it to use menus for this, rather than something else, especially since menus are a good solution and have been used for this purpose for many decades.)
One of the key GUI design principles is that buttons, clickable icons and anything that can be clicked should look like it, and if they are disabled, they should clearly look disabled (by usually being colored in dim grays). This is another rule that Microsoft has liked to break for a long time: Clickable icons are no longer distinguished from just decoration because their borders are hidden (are we seeing a pattern here?) unless you hover them and, what's worse, in some cases they are even colored in grayscale until you hover them, making it harder to distinguish if they are disabled or not. This is not how you do good GUI design. You shouldn't have to hover anything in order to see if it's an enabled clickable element. It should be obvious as-is.
Perhaps Apple knows better than this? Nope.
For example, open a new tab in Safari. How do you close this tab? It's not immediately apparent... It turns out that the close button of the tab is completely hidden by default, and you have to hover the tab in order to make it visible. Apparently this is supposed to be hip and cool, but it's a completely counter-productive design that makes the usage of the program less obvious for no benefit.
The current window and the other windows used to be clearly distinguished from each other in the first versions of MacOS X. However, as newer and newer versions have been published, this distinction has been made more and more difficult to discern. At this point the active window has almost the same title bar coloring as every other window, making it very difficult to see which one is the active one currently. Why have they done this? No idea. It only makes using the system harder, for no benefit.
Recently Apple announced that they would hide scrollbars by default. This was a real facepalm moment for me. I was like, "WTF? Are they going to hide everything in the future? Just don't show anything. What exactly is the point?" What possible use there would be in hiding scrollbars? No longer can you see where in the page you are by looking at the scrollbars, without having to perform additional actions to make them visible. This is almost as much a braindead idea as what microsoft did with menus in Windows ME.
Comments
Post a Comment