No hidden hotkeys.

• Every function gets a GUI button with the hotkey printed on it.
  
• If it can't be a GUI button, e.g., directional select or priority invert, the function gets a tooltip as soon as it's useful.
  
• Can you automate the function to reduce mental burden?
  
• Esc is special. It's a common hidden key in games, and it's like the home button on smartphones.

Still, in singleplayer Lix, you don't even need Esc; you can nuke. The nuke has a GUI button with a printed hotkey.

No dialogs.

• If you must display a message, display it without interrupting the control flow.
  
• The classic essay on this rule is Death to the Dialog Box on Coding Horror, 2004.
  
• Example: Level loading errors show in the Lix level preview screen. You can keep clicking levels.
  
• Five years ago, I followed this to an extreme, removed the end-of-singleplayer dialog, and printed game outcomes into the level browser. Only when people wanted a next-level button, the browser would have become too crowded.
  
• Dialogs break flow the most after you perform action/command X and usually get no dialog after X.
  

On hard-to-remove dialogs:

• Menus (that we implement as dialogs) are okay when we consciously summon them for their unique content, e.g., the options menu.
  
• The menu, if it is a modal dialog (i.e., you must finish dealing with it before you may continue your normal work), must still pull its weight. If we only have 1-2 small options, can we stick those into another existing screen?
  
• I believe that dialogs are less annoying (but still annoying) when you expect a drastic context switch anyway and have no clear next goal.
  

Example: You return from game to the menu. I still want to avoid dialogs here, but they're less nasty here than elsewhere.

Example: You start a time-consuming computation with nontrivial results that you rarely need, e.g., mass replay verification from inside the GUI.

Counterexample: When you need the replay verification often, dialogs will get annoying. E.g., you maintain Lix and want to test all packs before each release. Run the replay verification from the command line:
$ lix --coverage replays/path/to/your/pack

Counterexample: After you save a level in the editor, you usually want to playtest it. This is a clear goal; you don't want strange dialogs to get in the way despite the drastic context switch between editing and playing. Thinking about this, this leads us to more design insight: The context switch between editing and playing a level shouldn't be drastic in the first place. You're working on a single level throughout, after all. IIRC, back in the day, GigaLem suggested a button in the editor to playtest immediately.

-- Simon