Slashdot Mirror
What Makes a Good UI?
OSXCPA asks: "While there are plenty of OS business apps from accounting to ERP, they seem to share a common failing with "commercial" software - the user interface is terrible! Has anyone seen an application that has a UI that made you sit up and stare in amazement at the simplicity and effectiveness of it? For the techno-elite, drooly-gui may not be a priority, but I am working on a project (OS) where I have to show real savings (in task performance time and reduced data entry error) on a specialized accounting system via better UI. Am looking for some inspiration. Any ideas? Projects? Books?"
by Jef Raskin
u maneinterface/
http://www.jefraskin.com/forjef/jefweb-compiled/h
It's a book that can help you look at interfaces in a different way, with some measures you can make, and some guidelines that an be helpful. Maybe going all the way is not feasible immediately, but it can gie some insight on the subject.
Has anyone seen an application that has a UI that made you sit up and stare in amazement at the simplicity and effectiveness of it?
Google
The biggest problem I have with programs, is the way they make you hop all over to input data. If you can just go from input box to input box, flowing continously, then its a good UI design.
Who cares about looks, I care about functionality, well, I guess I do care about looks somewhat, take proxomitron's default colors when it came out, ICK. The user interface is perfect as a program goes.
But back to flow, nothing bothers me more than something taking away attention when you are working, pop up boxes, something that takes focus away from your work. I think this is why so many people like ratpoison, windowmaker, icewm, you can do your work without the distractions.
ok, do I really need Internet explorer to pop up and tell me when my download is finished? When I'm in the middle of typing an email? No. Stay out of the way. Stealing focus, or making a user hop around is biggest problem in UI design IMHO.
Vim.
No, don't laugh.
Its base set of commands is simple enough, and its effective.
For example, take 'd'. 'd' is for delete. 'dw' deletes a word, 'dd' deletes a line, 'd$' deletes until the end of a line.
'y' is copy. 'yw' copies a word, 'yy' copies a line, and 'y$' copies until the end of the line.
'c' is to change. Guess what 'cc', 'c$' and 'cw' does.
Moreso, 2dw deletes two words, as 2yw copies two words, etc.
Once you learn how one set of commands works, and you know another command, you probably know how that command works and how to use that command to extend the commands you currently know.
For example, /string searches for the next occurence of 'string'. Guess what
d/string and y/string does.
Sure, vim might not be the easiest UI to learn, but I seperate 'ease of learning' from 'ease of use'.
Just my $.02
PS: This post composed in vim. (Its my default editor for w3m)
Simple, but not restricting. Allow me to pull out the complexity if i need to. However, dont bog me down with 100 steps. (
Whatever you end up reading, I suggest you get some real users to sit down in front of it and test it. You need to be sure that the end user understands what you mean by what you say.
For instance, in this posting, your use of OS for Open Source instead of OSS for Open Source Software was mildly confusing because in the specialized world that is IT, OS, by convention, usually refers to Operating System. If you'd sat down and tested with a focus group, you might not have made this error ;)
Seriously, though, you'll get the best UI you can design if you just sit down with the end users and let them show you what makes sense for them...
Also try usability guru Jakob Nielsen's site Useit. Although mostly focused on web design it s a good read for anyone designing interfaces.
Thanks for browsing at -1
Please vistit my blog: www.framtiden.nu
Make a program that even one dummy could use and only dummies will use it!
It is not easy to create a software that is fully functional and intuitive at the same time. If you are searching for ERP, my bet is Navision. [currently Microsoft Business Solutions - Navision]
- Ability to manipulate data by dragging the category tiles around
- Formulae written in a reasonable facsimile of English
- Automatic identification of cell data collision
- Pretty simple scripting language
From 1992-1996, it was the only "spreadsheet" I would use. Too bad it could not migrate past Windows 3.1.You should really check out Joel On Software . His articles on user interface design are right on the mark. Specifically, you might want to read his User Interface Design for Programmers book (available mostly online, free).
You have to be fucking kidding me.
It's a file editor. With no 'open file' menu option !
Common places to look:
- Anywhere involving the mouse. Operations like selecting or cutting and pasting are very time consuming, and open to a huge degree of errors.
- Anywhere involving manual communication between programs. "The cron job emails this file to me as an attachment, then I save it and import it into Excel to run this macro."
- Anywhere that the human is acting as calculator. "I click in this field and then I type today's date."
- Anywhere there's a handoff between humans. "I start the server, email Jim to tell him its up, and then wait for him to tell me whether there are bugs he wants fixed."
- Manual touch points that don't need to be there at all. "I generate the newsletters, which takes like 10-20 minutes, and then when that's done I upload them to the test server."
In short, if you are trying to improve efficiency, then your human is your weakest link and your job is to minimize your human's input into the system. Whittle down their input to the bare minimum that cannot be accomplished by the computer itself, and then do the rest for them.Note very importantly that this implies there is one major audience that uses your product for one primary thing. We're not talking about something like a Microsoft Word that is used generically by a universe of different people. You said you have to optimize productivity, which implies that you have some control over hacking away at features that do not impact productivity.
www.HearMySoulSpeak.com
Quite a good book on what not to do. Kind of like a checklist of mistakes to avoid.
Gui Bloopers. Also I dislike Swing - but the Java Look and feel design guidelines are ok. Apple, and gnome have similar documents.
Something that doesnt have animated paperclips or dogs.
... This is not meant as a slight to developers. Those who are intimately aware of how every detail of the program works cannot shift perspective and see it from the point of view of someone who neither knows nor cares about the inner workings. I've spent 15 years designing systems to be used in a manufacturing environment. Saying that any problems are due to lack of user training is a cop-out, one that will kill follow-on business. Industry has the operators they have and are not going to start hiring special people and paying them more to run my systems. It's just reality.
I'll give what I think are the biggest UI traps:
1) UI's that expose all the capabilities of a system. This is not good UI design, in fact it is lazy UI design. What you need to do is understand how your users are going to do with your system, and present them with as few choices as possible. Example: If you have a screen for looking up Customer records, and further allow it to be customized to show various fields, and further allow it to check or uncheck any field, you can end up with a screen that does not show the Customer ID (because it was accidently turned off). From the developers point of view you are adding functionality. From a user's point of view there is now a way to accidently render the screen useless, or at least annoying.
2. Beware of allowing users to customize (Wow - there goes my Karma...) Customization is fine for stuff you play with, but in a professional environment it is much more important to have consistency. It is important that people can walk away from something for a week or a month, and come back and get to work right away. It is important that telephone support can make assumptions about what the user is seeing. Floating toolbars, menu items that come and go with frequency of use, frames that can be moved from top to bottom, all of these make it difficult both for telephone support and for people who are "backups" i.e. they were trained once and only use the system every so often.
3. Don't be afraid of busy screens (Damn - there goes the rest of my Karma) Professionals get used to the layout and appreciate having all the information right at hand. (This makes number 2 - consistency - especially important). So err on the side of putting as much useful information as will fit. And prune mercilously anything that isn't useful or required. Don't you hate it when you go to a bank or an airline check-in counter and see the attendent typing endlessly, screen flipping, all at the speed of light, but... why exactly do they need all that commotion?
4. Keyboard shortcuts, labeled and encouraged. The mouse is great for a lot of things, but speed is not one of them.
5. Remember your audience. Are they people who sit in front of the screen all day, using your application as their primary function, or are they several times a day users who simply need it to perform a vital function but just want it to work and go away? Even if it is the former, what about their backup's or the third shift people? In any case, present what they need immediately and clearly and leave off the fluff and BS.
6. Most important. Remember that your application is not what the people do. It is a tool that helps (or hinders) them in doing what they do. A tool should not be their primary focus. The task is their primary focus. Whether a carpenter or developer, any time spent fiddling with a tool simply means less time to spend actually doing the task.
No, and neither will you. The sign of a real good user interface is that you don't notice it, you just use it.
The problem is that it takes a lot of very hard work to get that far and most application developers (Open source as well as commercial) don't bother and/or lack the skills to do it.
My opinion? See above.
A good UI is one that does not cause to you sit up and take notice at all. A good UI is one that lets you sit back and get your work done, without making/allowing mistakes, without making you do anything repetitive, allows fast work, and all this without getting in your way.
Now creating this interface is often difficult. It is worse because sometimes the best UI for novices is different from the best one for experts. A novice needs a easy to learn interface, while the expert already knows it and just wants something that gets the work done fast.
Example: An accountant needs more power from from an accounting package than the average Joe. (yet the average Joe needs to send everything to an accountant once in a while!) "Joe" doesn't know how double entry bookkeeping works, and shouldn't have to learn. The accountant needs to know and use it.
- Go to MS Word(just about any version)
- choose Format->Font menu
- On the font tab, click the checkbox for "All Caps"
- Now, click on the checkbox "Small Caps"
Did you notice what happened? The "All Caps" checkbox disappeared! Why? Because "All Caps" and "Small Caps" are mutually exclusive! That means you should have them as radio buttons, not checkboxes! Checkboxes are for when you can have multiple options at once!That is poor UI design! Very inconsistant with the rest of the world.
I may be particularly dense, but I've concluded that Eclipse isn't the answer (otherwise, why was Penumbra developed ? (careful, thats pdf)
While I appreciate IBM's contribution to FOSS, and its an OK Java IDE, morphing it into a general purpose UI for general users is probably expecting too much.
I'd start with a set of simple web pages, and maybe upgrade to either VB, python/tkinter, or Perl/Tk (maybe wxPython if you must have that fancy chrome) only if you can't convey the functionality in some simple HTML + CSS + JavaScript.
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
A good UI should be infinitely configurable. A good example of what I think is a very bad UI is Aqua, the famous OS-X interface. It's even worse than the Windows interface. Look through how much trouble you must go to make a black background! And I'm not even talking about window behaviour etc. The Windows interface is a bit better, but the one I like best is fvwm2. It takes quite some time to figure out how the configuration file but then you can do absolutely everything.
-- Cheers!
Agree very much. Specially point 2.
Another one is to get rules about data documented, and keep on asking, when they say "and then I know that this record is bogus, so I ignore it"
In short, if you are trying to improve efficiency, then your human is your weakest link and your job is to minimize your human's input into the system. Whittle down their input to the bare minimum that cannot be accomplished by the computer itself, and then do the rest for them.
Spoken like a true non-user. The human is not the weakest link, the human is the one getting the job done. The machine is there to serve the user, not vice versa. If the user's needs are to have two buttons to click repeatedly, George Jetson style, throughout the day then that's the interface you need (I do a lot of manual QA stuff that's exactly like that). If the user needs a thousand knobs and dials, then you need to figure out how to organize those knobs and dials. It's not your job to tell the user to get out of the way and not worry their pretty little head while the computer works its magic.
I can't even get the engineers here to design a George Jetson interface properly. You'd think the button that everyone pushes literally several hundred times a day would be one they could make a little bigger, right? Nope, the point of the whole app is apparently about precise aim, not productivity.
I am no longer wasting my time with slashdot
Text.
Seriously.
Oh, I wouldn't say that's true at all. I think that by eliminating the redundancies, wait periods and other spaces were error creeps in, you free up the more important resource - human expertise - to be applied the way that it should. QA is a great example. If because of all the manual effort that you have to do you can only properly QA 10 bugs a day, but by optimizing some of those areas I can get you up to 30 bugs a day, didn't I just make you better at your job? I didn't lessen the value of properly QAing the system, nor did I lessen your input into finding and fixing bugs. I just made the system more efficient for you to do it in.
I didnt say the human is the weakest link. I said the human is the least efficient part of the system. If you need a thousand knobs and dials then I don't want to take those away from you. But if I discover that 90% of the time you're only using 3 of those knobs and the other 997 are for very rare circumstances, you can bet that I'm gonna move them to another page. Otherwise there is a portion of your time spent scanning for the right button out of a thousand, and a portion of time spent in error, which does not need to happen.
www.HearMySoulSpeak.com
Bruce Tognazzini's site.
He founded the Apple Human Interface Group and acted as Apple's Human Interface Evangelist. He's also written two books on UI design.
I believe that a key to good UI design is allowing the extensive options and a high degree of control over the software through both a graphical user interface, and a command line interface.
With GUI design it is important to not throw up to many options at once but provide a rich and complete set of options but place the most commonly used ones on main screens, and then put lesser used ones on "advanced" or "expert" screens. Organise and categorise options and cofiguration settings, and features and make them all easily accessible, but with most commonly used ones most prominant. Include a toolbar with commonly used features, then on the menu bar you can include the commonly used options and advanced options in "advanced" menus and submenus. This way, the average user isnt bombarded with options, but the user if they desire can set the more advanced options and features if they wish. The software should give users complete flexibility and control as possible and let them configure everything, but only if they want to. If all the user wants to do is jump right in and start doing what the software is supposed to do, they should be able to do so and the software should use reasonable defaults. The idea is to give the user the choice and freedom, if the user wants to control every aspect of the program, they should be able to do so, but if the user just wants to start using it withonly having to make a bare minimum of choices, they should also be able to do so. You can give users both. The program should be as simple or as complex as the user wants it to be, and allow the software to work the way the user wants it to work rather than enforcing limitations and restrictions on the user.
The command line interface allows for the programs features to be more easily scripted and integrated into other programs and as well eisier remote ssh and command line access to the programs features for those who desire it. Agian, no one is forced to use it as it is an advanced feature, they can still use the GUI, but it is there if someone wants to use it.
Here is a great rule of thumb when designing a UI: No one wants to use your stupid flipping application. Once you get past the ego trip of 'my app is in front of everybody, it must be shiny and say something cool about me', things go much better.
The UI should get the heck out of the way and let the user do his work. Things should be intuitive. Use the right control for the right job. Be consistent between screens. Watch how your users do their job, and use your system. If there are unnecesary clicks because focus goes to one control when they really use another control, fix it!
Sometimes, it is necessary to design a form that a five-year old cannot use. When this is true, include helps and hints (tooltips for quickies), some type of pop-up when longer help is necessary.
Most important: Sit with your user and watch him do his job. Feedback is so important, but how you get the feedback is more important. If you solicit feedback, you will generally get a million stupid suggestions, and the important ones won't get brought up.
Identify your power users. These are the ones who figure out how to break your app, who give you the ten ways to improve your product (and generally have good throughts -- not, "the background color should be puce"). Talk with them, thank them for their input, follow up when you have incorporated your changes, ask them if the changes were what they had in mind.
Keep your audience in mind. For lower-skilled workers, I keep things simple and avoid complicating the process. I put a higher emphasis on warning if things 'don't look right' to the computer. For higher-skilled workers, I give the user more autonomy, and less hand-holding.
Most of good UI design revolves around knowing your user base and communicating with them.
There are a ton of books that talk about the nuts and bolts. But good people skills is what seperates the code monkeys (who have three times more coding skills than me) from the successful software engineers.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
When you start the application, or create a new entry, the cursor should automatically show up in the first field. Then once you start typing, the focus should never jump to another field mid-word.
Aside from the security issues, this is why I can't use IE.
While I am a strong Open-Source-Software user myself, I've found that quite often some of the biggest points of contention between the users and developers come with UI design/enhancements. If it's a programmatic bugfix the developers are happy to fix it, but if it's a UI/usability fix/change most developers seem to get their hackles up.
Developers of projects like the GIMP make a UI have long ignored user requests for things like an IDE environment, and when pushed both the developers and power users alike tend to get contentious.
Of course GIMP is just one example, many programs are like this. In the case of having something simple like an IDE, how hard would it be to simple allow an option to turn it on. It would satisfy both new and power-users, and put an end to many a flamewar...
ALl of ed's commands are single letters. What could be easy to remember than a single letter?
a appends text. c changes lines. Simple!
And the error reporting is second to none! If your command contains an error, ed helpfully prints "?" to your terminal. No memorizing what 200 different error messages mean, all you need to remember is "?". Isn't ed great?
Don't blame me; I'm never given mod points.
From Jef: "For example, which of the following takes less time? Heating water in a microwave for one minute and ten seconds or heating it for one minute and eleven seconds?
"From the standpoint of the microwave, one minute and ten seconds is the obviously correct answer. From the standpoint of the user of the microwave, one minute and eleven seconds is faster. Why? Because in the first case, the user must press the one key twice, then visually locate the zero key, move the finger into place over it, and press it once. In the second case, the user just presses the same key-the one key-three times. It typically takes more than one second to acquire the zero key. Hence, the water is heated faster when it is "cooked" longer."
I read this a few years ago and I've always disagreed with this for a couple reasons. First and foremost, I can punch in '1-1-0-start' just about as fast as I can punch in '1-1-1-start.' It certainly doesn't take one whole second longer. (Most people can comfortably enter a memorized 7-digit phone number in less than 2 seconds. Try it yourself.) So the argument is wrong to begin with. Furthermore, even if it were right, it would only be right in that one case--at 2:22, or 3:33, or 4:44, even the lamest 1-button-per-second microwave button poker would start to notice a net loss. So when used as a general rule, it fails again.
Secondly, most people have a natural understanding of 1 minute and ten seconds. It's what they want, so it takes almost no mental effort to plug in '1-1-0' when you're thinking "a minute ten." It would probably take most people longer to think "OK, I want to cook this for a minute and ten seconds, but is there a clever way I can save a bit of finger movement?"* Until you learn the trick and get into the habbit of using it, it won't save you much. I used microwaves for over a decade and always entered the exact time I wanted without much thought.
My wife got me into the habbit of rounding up to the next closest duplicate number--i.e., 33 seconds instead of 30. I admit I do use it, but mostly for yet another reason--because speed is not important. Rarely do I stand by the door waiting for the instant my food is ready. I press a couple buttons, start getting my milk or whatever else I'm having, hear the food beep, and take it out whenever I get around to it. So, ironically, when I use the Jef method of time-saving, it's when I am not looking to save time.
Thirdly, if you want to be really clever, a minute and ten seconds could be more simply expressed as 70 seconds. OMFG Jef that's one whole less digit!!!11 (Of course, that only works up to 99 seconds.)
* and that is, in fact, the whole point of why Jef used this example--to make the computer do the thinking, not the user. His point is good but his example is bad. But overall, there's lots of good info all over his site. His site and Joel's (joelonsoftware.com) are two of the best.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
One related point is how to ask users for data. The wizard approach is good for users who don't always know what they want. It provides a simple way to extract information and make decisions on what to ask next based on previous responses. But it sucks for speed. For a specialized app, like this one, your users probably know exactly what information they need to provide. Let them provide it all at once instead of spread out over 10 dialog pages. Since your users probably won't be entering exactly the same type of data all the time, present them with a simple choice, then give them the huge forms. It's not elegant design (lots of duplicated information) but it's fast as hell. And you can always lay out the forms in the same sort of way, so five tabs takes you to the same field no matter what form you're in, etc.
I mean, don't you hate those Web forms where you answer one or two questions per page? And the damn thing seems to go on for hours? Just give me a monster page with all the fields, I'm smart enough to know which ones are relevant and need to be filled in.
But make sure it really can be automated! There's nothing more frustrating than a program which does something you don't want it to with no convenient way to stop it. The key here is to know your audience. A common pitfall for developers is to build the application they want, instead of the application the users want. This plagues the OSS world in particular, for obvious reasons. Excessive configuration is often a crutch for uncertain design principles. If you know what your app needs to do, and you know how people will be using it, then users shouldn't need to configure anything at all. Fine, let them change the sort order of tables or whatever. But if you find your users need to tweak your program extensively before they're happy with it, you've done something wrong.This goes back to the "lots of options" point as well. The more options you give your users, the more confused they tend to get and the harder it is for them to find the stuff they need to.
Also note that allowing for customization adversely affects consistency. Even simple customizations can adversely affect the ability of one person to use another's copy of the application. In a place where there are more people than computers that's a serious problem. It's also a problem if you want to offer technical support, training, etc. In a way, let MacOS be your guide: "I don't care if it's the best way, but it's the way you're going to do it." And if you're designing an app which builds, at least to a certain extent, on other apps, you should probably choose to do things the same way the others do. That will be the way your users are used to doing things, so unless you expect to see some enormous improvement in efficiency or ease-of-use, don't rock the boat.
There are good UIs, which follow all of the official look and feel requirements. There are efficient UIs, which allow users to work at their maximum speed. Do not confuse the two. They may not and most often are not the same.
My wife works in accounting and is extremely fast at using one of those printing calculators. However, the user interface in her accounting software make her mouse or tab between fields, greatly reducing her speed of entering data. It looks nice, but is difficult to use quickly. The interface for DOS applications was often much more efficient than their Windows counterparts because it allowed the users to keep their hands in place and reduced hand/arm movement to just finger movement. Compare that with having to reach for the mouse all of the time.
Here are some quick guidelines for improving data entry speed in applications:
1) Minimize hand movement for numeric entry and forward navigation through numeric fields by encouraging use of the numeric key pad.
2) Minimize hand movement for character data entry and forward navigation through character fields.
3) Try to keep fields of similar data type in order (where appropriate) to facilitate use of #1 and #2.
4) Allow the use of the mouse but don't require it unless you absolutely have to. This can be aided by selecting field types which allow the most efficient entry of the data such as text entry for a date instead of a calender popup. If your hand is already on the keyboard, keys, even hot-keys, are faster than the mouse.
This all boils down to reducing the amount of motion required to perform a task. Generally speaking, reducing motion increases speed. As for inspiration, take a look at some of those efficient DOS apps and see if you can use the same keystrokes in a GUI version. You get bonus points for combining that efficiency with UI look and feel requirements.
I think we're actually in violent agreement here: When the interface gets in the way instead of helping, you lose efficiency. By being the most critical component of productivity, that productivity gets lost if the human isn't served by a proper interface. I sort of made a knee-jerk response to the perceived attitude that "dumbed down" is somehow better. Unfortunately, I do actually get to see that philosophy in action fairly often, and often it's hidden behind neologisms like YAGNI (You Ain't Gonna Need It -- a glib way of dismissing requirements used by the exponents of a methodology that pretends to be responsive to them)
I am no longer wasting my time with slashdot
UI's that expose all the capabilities of a system. This is not good UI design, in fact it is lazy UI design.
:-)
A UI that doesn't let you access all the capabilities of a system is a broken UI. Think about it. If I write a program that can sort a list of numbers in either ascending or descending order, but only provide an interface allowing an ascending sort, what the heck was I doing coding the descending code in the first place?
This doesn't mean that the main screen of the UI needs to access secondary and tertiary functionality, but you need to provide some interface for the user to all the functionality.
Beware of allowing users to customize...
Customization is necessary for most ERPs, simply because no two enterprises have the same needs. If I have been using 9 digit SKUs for the last twenty years, and your software only allows 7 digit SKUs, then your software is going to cause me problems. I've actually encountered this exact scenario at work, where we have one database whose sole purpose is to translate old part numbers into the new part numbers used by our new inventory control system.
More generally, some level of customization is necessary for ALL software simply because no two users are alike. That doesn't mean you have twenty pages in a tabbed dialog for all the little tiny tweaks a user can do. Rather it means that the software has to be flexible enough to accomodate more than the mythical average user.
Don't be afraid of busy screens...
I've seen your screens. And I want to scream every time. While I do want all related necessary information on the same screen, I don't want ALL information on that screen. Based on some screens I've seen, it's almost like some developers have never heard of the "next" button, or expect you to have 1280x3076 monitor.
Dialog design is like writing. As a famous essayist once told me, the key to good writing is to take as much away as you can. Ditto for dialogs. Take away as much as you can. This doesn't preclude "advanced" buttons or multi-paged dialogs, of course.
Keyboard shortcuts, labeled and encouraged.
I absolutely agree. There is this CAD I use that only has keyboard shortcuts for the most common actions, with no way to customize [!] additional shortcuts. The more I improve using this CAD the more frustrated I get with this lack of functionality.
I also agree with your last two points as well. That's three out of six, so I guess that makes one of us only half right
Don't blame me, I didn't vote for either of them!
You said: A UI that doesn't let you access all the capabilities of a system is a broken UI.
If you add the word "necessary" in there somewhere, I would agree with you. I'll give you a real world example: Print orientation in industrial inkjet printers (these are the kind that write the date on the bottom of coke cans - not anything like a Deskjet). Because these printers are non-contact, you can't predict ahead of time which direction the product will go past the printhead, whether it is upside down, and whether it is printing on the inside of something transparent in order to be read from the outside. There are 3 different parameters that give you all the 8 different combinations, and 7 of the 8 could be used in the real world. The traditional way is to give the user control over all three parameters and let them try to figure it out. The better way is to let them print a test message, then select the way the print acutually printed. The code figures out the settings that correct the orientation. More work for the coder, but much easier for the operator. When this second method was implemented it was considered by many to be an amazing leap in the printer technology, when in fact, the printer hadn't changed at all. Sold a lot of printers though.
The important thing is to understand what the end user wants to do, and present it in a way that makes intuitive sense to them. It is oftentimes more difficult to code, but it is really the only right way to do it.
Yes, I make a habit of stopping by the manufacturing floor to see how the guys are doing and if there is anything that annoys them or something that they wish worked differently.
If I don't stop by, they never approach me with requests, but when I actively seek them out, I get feedback about changing a comment, making a test longer, shorter, bigger buttons, etc.
I am fortunate to be able to do this I think, because my boss doesn't really know what I am doing, so I can take time to learn PHP/mySQL and add new features and apps to our corporate intranet to improve productivity, in a relatively short period of time, but lots of other guys figure they don't have time to do it, and so nothing ever gets any better.
So, before you even think about the UI, work out what people will be doing with the software. What things are they trying to achieve? Be specific. (This is where use cases can be very helpful.)
Then you can look at a UI, and judge how best people can do those things, with the UI getting in the way as little as possible.
So your request for a flash, impressive UI is pointless: the best UI will be one that you're not even aware of! And one which seems completely obvious -- but only after you've seen it...
Ceterum censeo subscriptionem esse delendam.
Iwasn't trying to disagree with you. I was merely pointing out an example of what I considered (and thought you would also) of a positive example of hiding functionality.
Here's a more direct one: In a similiar vein the group responsible for developing the UI for a higher resolution printer was working on a windows driver and the corresponding application. They exposed every single Windows option for font control. I can't remember all of them now but there are many choices that you certainly don't even get in Word. This interface terrified and overwhelmed users (fortunately it was only an alpha). But the developer couldn't see it. 'If they can't understand it, they should take the time to learn it.' For the labels these operators were creating, they simply did not need these functions. We cut out most of the choices (and made the remaining ones much more intuitive). Industrial UI is all about speed, clarity and easing the frustration factor. Line operators have twenty things they are watching and setting up. Learning how to anamorphically resize print is a ridiculous waste of time.
It's not that they would never use it, it's that it would cause only trouble - "My print keeps changing in size - it spreads out'. Well, spreading print can be caused by mechanical problems, product handling problems, and by electrical problems. We would end up with a $125/hour service call (or one we eat under warranty) because someone on a different shift accidently created a format with some weird spread out font. I RAN service. I would bet my last Lorna Doone that this would be responsible for unnecessary service calls much more often than it would actually benefit someone.