Jerud
Glad you enjoyed it.
Fast navigation of an app when doing repetitive processes is worth its weight in gold for anyone more than a casual user. CAD (as you mentioned) and 3D apps like Autodesk Maya, went through a phase where they were trying to move users from pulldown menus that were getting longer with more sub-menus and sub-sub menus. These new ‘pop-up’ or ‘context’ round menus, sometimes called a “Gate” where you would drag or swipe between menu items, didn’t seem to catch on with our users because they rapidly realized that they were just re-arranging the existing congested menu structure.
Symbolics tried to used a ‘sentence’ structure of noun-verbs (probably buried somewhere in Symbolic Lisp programming history), so your menu structure read similar to an english sentence. For example:
Create/Sphere/Polygon/ByMouse
and
Create/Sphere/Polygon/ByNumeric
It was intuitive because it was arranged how a user would describe the operation they needed to perform.
I believed that Symbolics’ sentence structure for UIs was so intuitive that I utilized (ok, copied) a similiar structure for some Amiga graphics applications that I published. But I soon realized that once an applications hits a certain ‘density’ or functions, the ‘sentence of commands’ became so long that you were once again making the amount of time to navigate the menus too long to be efficient. Any complex UI rapidly runs out of screen real estate and become cluttered.
So (theoretically) the entire problem and it’s solution becomes as simple as this (for many apps):
- The app’s main window/canvas should be as blank as possible and resizable. Rarely should anything be visible by default unless absolutely necessary.
- The app (usually) has too many functions to all be on screen at once, so don’t put them there. Organize them effectively so they can be found when needed, knowing that they may take longer to find if you need them often. Accept that this model is OK and HIDE them behind top-level menus.
- Now grant the user the ability to arrange and group oft-used UI elements (Buttons, etc) in Toolbars that can be easily arranged, floated or docked to the UI and persisted in the app every time it is launched and grouped into toolsets that can be changed easily.
Now (most) users can be happy: Each user can put the functions he/she uses at the forefront of the app where they like, and the lesser used functions can be reached when needed. Almost everyone is happy…….except…….the programmers, who have to design the app’s UI/toolset in a way to allow all this.
This is (relatively) simple for a modern native application/OS, but becomes much more difficult in our current era of web applications, where apps are ‘coded once’ for a web browser or electron-wrapped in an attempt to avoid writing independent code for each OS. We are forced to give up the best features of each native OS’s UI in favor of the ‘least common’ UI feature sets that a web browser can provide to them all.
For reference to those that are interested, an excellent example of flexible UI design is Directory Opus. It’s been around since the 1980’s on the Amiga & Windows and has one of the most well-thought out flexible user interfaces for user control. See: https://www.gpsoft.com.au
For an example of how NOT to design a user interface, see an Windows applications using the microsoft “Ribbon” UI 🙂 Those guys must never have learned to eat their own dog food.
