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
to provide a (somewhat) complete set of guidelines that can be
utilized in the design of domain-specific editors which want to
support easy-to-use and powerful controls for people who are familiar
with Text Editors. The controls implemented based on these guidelines
don't even have to be the default controls for an editor: allowing the
user to change their control scheme to "Text-Editor-ish" is also a
viable option that strictly increases the accessibility of an editor;
to work towards a framework that enables building bridges from code
editing to unfamiliar domains, in order to enable experimenting and
creating using coding to be a part of learning a new domain;
to start a discussion on how to build bridges in the other direction,
from familiar domains to code editing, in order to make coding
accessible to a wider group of people;
For example, someone who has some knowledge in art may be able to
learn programming more easily if their programming interface
implemented the ability to draw shapes and diagrams as a part of their
code;
to work towards an ecosystem of interoperable editors of all different
kinds.
Now, onto some guidelines of "Text-Editor-ish" UX.
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.
Support selections. mouse click&drag, delete, shift&caret.
Support copy & paste. plain vs structural copying.
Support history i.e. ctrl z and ctrl shift z.
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