This is mostly addressing Patrick's Parsing Problems, but anyone with an interest in UI might find it interesting.
When designing something, the most critical thing to know is what the thing has to do. Then you design it to do that task efficiently and beautifully.
The problem with UI design is that most people don't know what their UI is supposed to do. Not clearly. So they overdesign and go astray.
There are three kinds of UI: static, parsed, and reverse parsed. These are the only three kinds of UI anywhere in reality. There are no other options, although many UI are actually several UI wrapped together, often of multiple types.
Static UI are the most common in computer applications. These are usually an array of menus and icons. The user always has all the options, although they often have to dig deeply to find the particular one they are looking for. Static UI can be as opaque as a 3D toolkit or as transparent as a number pad on an ATM.
The primary joy of this system is that it is really easy to design, but at a more fundamental level, it is also very useful for complex systems in which you might be controlling several different aspects simultaneously - or need to be able to make new aspects immediately. It is also useful for systems which you use a lot, because you'll become very adept at navigating them. In a game design, however, this system is usually the most inefficient.
Reverse Parsed UI are essentially dolled up static UI. This interface only offers you the options that are directly applicable to the situation at hand. The most common reverse parsed interface is right-clicking on a Windows machine. Games also commonly use reverse-parsed interfaces - everything from the RTS game which shows you unit commands to the Sims, which uses a snazzy-looking right-click menu.
The primary strength in a reverse-parsed UI is ease and simplicity. It is exquisite for controlling diverse elements in a very easy and transparent manner. Because it typically wastes a click, it is slightly slower than static UI, but is easy for a beginner to use.
Parsed UI are more common than you might think. A parsed UI is any system which uses a complex multivariate input to conrol the situation. The most common parsed UI? A mouse. Of course, a mouse is a computer UI, and most programs use the mouse to interface with a static or reverse parsed program UI.
A parsed UI is useful for differentiating between at least a hundred nearly identical options. For example, which angle to fire a bullet at. Where to place a pit trap.
That is the only thing a parsed UI should be used for.
Now, that might sound zany. For example, a program is a parsed language. But when you build a program, you build something out of a million different, mostly identical pieces and aim them at each other very precisely. Functionally, a program is a set of objects which are picked and aimed carefully from a truly staggering number of options.
But the thing about a program is that you are actually using a static interface (plus a little reverse goodness with tab completion) to interface with this parsed UI!
How zany is that?
You're taking a parsed interface (your body), ignoring the other parsed interfaced (your mouse) in favor of a static interface (your keyboard) with which you use a parsed interface (the programming language).
Why? It's a matter of precision vs range.
A mouse doesn't work very precisely, or very quickly. But because it is a parsed system, it has excellent range, able to skip over huge numbers of identical options to pick roughly the option it wants. Buttons are large specifically because of the precision loss.
A keyboard is very precise, but is "local" - since it's a static UI, there's no way to get far from where you are short of typing additional letters. The more identical options, the more letters. But once you get there, you are there exactly.
Of course, a mouse is intuitive and a keyboard is not, and there's something to be said for that, as well. You could make a keyboard "jump" to specific menu locations using mapped keys (some games do this), but it requires more memorization.
Anyhow, does your game require choosing from a hundred nearly identical options? If not, you do not need a parsed system. And if so, you only need a parsed system for that part of your game.
Understand what your UI needs to do, and give the user the most efficient UI for the task. Choosing a UI because you think it's a kewl koncept is silly, and will piss off your players unless it is specifically serving a game purpose efficiently.