Software Interface Ideals and Order Preference

For a programmer there is an ideal ordered list of preferred interface types for software. What this means is that by default, with no other overriding constraints or concerns, and you're deciding what kind of UI to create first or next for a particular piece of software, or perhaps what will be the only kind, that you should give strong preference to certain types over others. Because if you do, certain benefits will fall out from that decision which will yield a significant net win in terms of architecture, efficiency, and the ability to maintain the software and add future features. That order, from best to worst, is the following:
  1. CLI*
  2. API**
  3. web API (eg. RESTful HTTP with JSON)
  4. web UI, no Flash, just pure HTML/CSS/JS/SVG
  5. web UI, w/Flash
  6. multi-platform desktop app UI (eg. Java Swing)
  7. mono-platform desktop app UI (eg. Objective-C w/Cocoa for OS X)
This order is significant in several ways: NOTES:

* You could further subdivide the CLI case into CLI standalone process vs CLI client/server architecture w/multiple processes, but that goes beyond interface into implementation. I tend to start with a single process, monolithic architecture and later break out the implementation into separate client and server portions only when it makes sense. On a related note, in the CLI case, I further bias to starting with a Unix shell script, built on top of built-in shell commands and/or other CLI tools, and then resort to writing custom application code only when needed or it would be a significant net win in comparison. Even then, you can start with a shell script, have it wrap around calls to a custom application, and do progressive evolution of the implementation as needed. I also bias to starting with a scripting language (like bash), then interpreted (like Python), then compiled (like C) as last resort, unless other concerns like performance or minimizing resource usage matter more, AND are obvious at the present time. Some issues won't be obvious yet, and some roadblocks or bottlenecks may never occur. Cross those bridges when you get to them, if ever, not before.

** There is a good argument for ranking API above CLI in certain situations. You generally can't go wrong by having them as your top preferences, in either order. However, even if I build the CLI first, then later an API, I will in those cases refactor the CLI implementation so it becomes "on top of" the new API. Likewise, continuing this pattern, when it comes time to build a web API you should strive to build it on top of the programming API. And ideally the web UI (HTML, etc.) should be built on top of the web API and/or the programming API. This strategy minimizes DRY violations, maximizes platform flexibility and leverageability, while also helping to force or encourage good design choices on the part of the programmer. Vegetables: they're good for you, so eat them.

*** TODO decide how to add/treat REPLs; decide whether to include alternate media/interaction types like IVR, touch, Braille