Maybe we should all email the fine folks at 3Com a copy of Chapter 17 of _The Magic Cauldron_. That is the appendix in which Eric Raymond explains "Why Closing Drivers Loses A Vendor Money". The basic argument is that copying someone else's technology is a dead-end business due to today's rate of product development. Any competitor foolish enough to base their business on a copy of today's products is simply guaranteeing they will always be a generation behind due to the lost opportunity for innovation. Any loss of sales will be more than offset by increased consumer loyalty.
If you're in an emailing mood, send one off to Xircom, too. They still won't release their old technology because of the same misguided fears about competition. They managed to turn my CEM2 PCMCIA card into a piece of unsupported junk and lost a customer in the process. Did they really think that by making the CEM2 impossible to use I would really rush out and buy one of *their* new products?
Certainly they could come up with something similar that wasn't infringing, like "Screenprinting for braindead titheaded fuckwits" and not have to worry about infringing on some trademark...
Of course, then you would be facing a "look and feel" lawsuit. Out of the frying pan and into the fire....
One of my former employers only had two names. Since almost all applications (in the pen-and-ink world, at least) ask for a middle initial, he would give each company a different initial. When the snail-spam started arriving he could tell by the initial which company had sold his name.
Part of the confusion over "what do you need in a GUI" is due to the unstated question of "what do you want the GUI to do?"
Some people are talking about vitualizing the desktop. That's great if you are using the GUI to emulate a desktop, but useless in a single-task computer such as an ATM. Other people are talking about extensible functionality, which is great for programs that use plug-in technology but useless on a monolithic application. Some people think that consistency between applications is the holy grail, while others think it's minimizing mouse travel or allowing experts to define hot-keys.
At a very basic level, a GUI needs to enable a user to perform a defined set of tasks with as little diversion of attention as possible. The perfect GUI should be mentally invisible to the user. How this is done will vary from user to user, task to task, and computer to computer. Standardization makes learning easier but may end up making the interface harder to use. Do you want a GUI that is consistently difficult to use?
At risk of seeming contradictory, I'll point out that sometimes the key to an effective GUI is to make things more difficult for the user! For example, the proposed GUI for a system I am testing had a number of buttons that were placed together on a menu bar because they act on the same data and the designers figured putting them together would make learning the system much easier. They neglected the fact that the consequence of choosing the wrong button was very high and their adjacent locations made that selection error an unacceptably high risk. In the end, a recommendation was made to "denormalize" the GUI so that human error would be less likely.
Slashdot Mirror
Maybe we should all email the fine folks at 3Com a copy of Chapter 17 of _The Magic Cauldron_. That is the appendix in which Eric Raymond explains "Why Closing Drivers Loses A Vendor Money". The basic argument is that copying someone else's technology is a dead-end business due to today's rate of product development. Any competitor foolish enough to base their business on a copy of today's products is simply guaranteeing they will always be a generation behind due to the lost opportunity for innovation. Any loss of sales will be more than offset by increased consumer loyalty.
If you're in an emailing mood, send one off to Xircom, too. They still won't release their old technology because of the same misguided fears about competition. They managed to turn my CEM2 PCMCIA card into a piece of unsupported junk and lost a customer in the process. Did they really think that by making the CEM2 impossible to use I would really rush out and buy one of *their* new products?
Of course, then you would be facing a "look and feel" lawsuit. Out of the frying pan and into the fire....
One of my former employers only had two names. Since almost all applications (in the pen-and-ink world, at least) ask for a middle initial, he would give each company a different initial. When the snail-spam started arriving he could tell by the initial which company had sold his name.
Some people are talking about vitualizing the desktop. That's great if you are using the GUI to emulate a desktop, but useless in a single-task computer such as an ATM. Other people are talking about extensible functionality, which is great for programs that use plug-in technology but useless on a monolithic application. Some people think that consistency between applications is the holy grail, while others think it's minimizing mouse travel or allowing experts to define hot-keys.
At a very basic level, a GUI needs to enable a user to perform a defined set of tasks with as little diversion of attention as possible. The perfect GUI should be mentally invisible to the user. How this is done will vary from user to user, task to task, and computer to computer. Standardization makes learning easier but may end up making the interface harder to use. Do you want a GUI that is consistently difficult to use?
At risk of seeming contradictory, I'll point out that sometimes the key to an effective GUI is to make things more difficult for the user! For example, the proposed GUI for a system I am testing had a number of buttons that were placed together on a menu bar because they act on the same data and the designers figured putting them together would make learning the system much easier. They neglected the fact that the consequence of choosing the wrong button was very high and their adjacent locations made that selection error an unacceptably high risk. In the end, a recommendation was made to "denormalize" the GUI so that human error would be less likely.