Towards "Text-Editor-ish" UX - Feb 15th 2023

This document was last edited on February 15th 2023.

Elliot's note: I wrote this at the start of 2022. At the time, I didn't like what I had written enough to share it. Now, in preparing for my PX\23 presentation, I've realized that I come back to these guidelines quite often. I use the illustrated guidelines at the bottom of this post, and I want to share how I have been thinking.

People who program may find themselves switching between a code editor and other domain-specific editors as a part of their workflow. For example, a backend web developer may switch back-and-forth between editing an architecture UML diagram and editing code; a frontend web developer may switch between editing SVGs and editing code; a creative coder or game developer may switch between a custom-made world editor and code editor; a biologist may switch between a spreadsheet and a code editor. This switching process can be clunky:

The controls and interface elements of domain specific editors are often quite different from the controls of code editors. People who program cannot expect familiar key-combinations or button clicks to achieve familiar results across all the editors they use. Learning, remembering, and switching between the controls for all the different editors in use can be a significant mental load and a barrier to incorporating diverse editors into a person's workflow.

This is especially relevent in Polytope, where editors are placed beside and inside eachother.

First of all let me acknowledge that making editor UX seamless is not something that has a simple or completely generalizable solution. Different editors have different UX for a multitude of reasons – from the history of a given type of editor, to the familiarity to concepts of people who work in the domain that an editor is made for, to the widely varying ergonomics and hierarchy of controls across editors.

I aim to provide a Text-Editor-first perspective: I have some UX guidelines that, when applied to domain-specific editors, provide a user who is familiar with Text Editor UX a baseline of familiar and powerful controls regardless of the nature of the editor.

My goal with these baseline principles is

Now, onto some guidelines of "Text-Editor-ish" UX.

  1. Support Keyboard & mouse caret-based navigation... arrow keys, backspace, home, pgup, pgdn, end, ctrl + arrow keys, alt + arrow keys click to place caret positions (spatial vs indexed), multicursors. This is easily the most important guideline. If you implement this one effectively, guidelines 2, 3, 4, and 6 become much simpler.

    Editing note: This will be the topic of my PX\23 presentation! I'm very excited to share my progress in this area.
  2. Support selections. mouse click&drag, delete, shift&caret.
  3. Support copy & paste. plain vs structural copying.
  4. Support history i.e. ctrl z and ctrl shift z.
  5. Use normal output & input formats If at all possible, you should be able to export to a text file. Don't use proprietary formats. Make the output of your editor as readable as possible in a code editor. Invariance.

These are the principles I have been working on getting right in Polytope. They are guidelines to help me think through the design of the UX model in Polytope. I left off two principles I originally had here: Multiplayer, and having clearly displayed editor state. Since writing this, I've refined these ideas, making them more precise and useful. I look forward to sharing more!

Attribution: Save Icon SVG: PICOL, PIctorial COmmunication Language, CC BY 3.0 , via Wikimedia Commons