Notice: This document is a wiki. Help us and 📝 improve it.
A summary of some core design principles that are baked into our modeling tools.
- Editors, not drawing tools
- Less is more
- Know the context
- Do the hard work to make it simple
- No surprises
- Empower the user
Our editors are domain specific tools with a strong foundation on the standards they support.
- We ensure diagrams are always structurally consistent (no free floating sequence flows, can be exported to a valid standards representation at any point in time).
- We build upon domain specific modeling rules (no tasks in tasks, no sequence flows across pool boundaries).
- We do not support intermediate states, if they are without representation in target language (free floating connections).
- We support users to ensure diagrams stay semantically sound (change sequence to message flows and vice versa, ...).
- We enforce and/or embrace domain specific modeling conventions (left-to-right, top-to-bottom, encoded good practices)
- Guides users in learning and modeling the standards.
- Setup diagrams for interchange and basic understandability.
- Prevent unintentional human harm.
Our tools are intentionally minimalistic.
- We build upon a minimal set of core modeling concepts.
- Create special elements via the palette
- continue modeling via the context-pad
- change elements via the morph menu
- We expose only a small amount of things to do next (see also ➡️ know the context).
- Reduces the cognitive burden for newcomers and experienced users alike.
- Aids modeling in collaborative environments where different perspectives / tool / modeling experience clashes.
- Compensates for the standards being overly complicated at times
We understand that using our tools is highly situational, depending on what the user wants to achieve. We provide intuitive means that support users across all stages of diagram editing.
- We embrace continues modeling / locality (cf. context pad, infinite canvas).
- We provide tools for larger scale refactorings (i.e. space tool, drop on flow)
- We provide facilities for efficient navigation and discovery
- Get out of the way as a tool.
We do a lot of things under the hood so the user does not have to.
- We keep the diagram sound, as the user models (connection layout and repair on element move, automatic label move, infinite canvas and automatically origin alignment).
- However, we do NOT overrule the user.
- A user can think about what she would like to express
- Get out of the way as a tool.
- Do not cause frustrating extra work.
See also ➡️ no surprises.
We aim for predicable, intuitive editing behavior.
- We offer predictable core modeling actions (connect previews, move ghosts)
- We do repair / fix sensibly during user editing (layout / grid snapping / alignment)
- We clean up / support during local modifications (see also ➡️ do the hard work)
- We design breaking modeling changes with a migration path in mind (e.g. incremental grid snapping)
- We do NOT globally, magically fix everything
- Automagic changes should have the sole purpose of "getting the tool out of the way"
- Predicable behavior is a basis of trust and aids learning
We do no magic. Using our tools, the user is in control.
- We are agnostic to modeling styles and conventions (i.e. spacing). There is not one standard way to model.
- However, we pickup diagram styles and support users in building consistent looking models (auto-place, align / distribute, ...).
- We are forgiving. We rather allow the user to do what he attempts to do than blocking a request. Following up, we do best effort to support her intend and still end up in a valid diagram (drop on flow, change sequence to message flow when moving task across pool boundaries, cf. also ➡️ do the hard work).
- Users should be able to learn the implemented standards by doing
- Users should never be frustrated through changes our tool introduces
How to achieve all this? Iteration and user feedback.
Are we done achieving all this? No.