UX: Initial use cases & actions

["Vaida Plankytė" <vaidaplankyte@gmail.com>]

Sharing some initial key use cases & potential design approaches, so
as to move these conversations into the public sphere and get some
feedback!

I've consciously abstracted away from describing UI, such as how VMs
are differentiated visually, user-facing naming of entities and
actions, or where actions are located in the UI. There's some ideas
being explored around this, but I thought I'd be good to share the
high-level thinking first and get people's feedback. The aim is to
address key usage scenarios in a user-friendly and flexible way
(easier said than done).

I'd be most curious to hear if there are obvious usage scenarios that
y'all think should be included as part of this MVP design. One I'm
thinking through is whether the user needs the ability to Duplicate a
Persistent or Non-Persistent VM.

UC1: Non-Persistent VM for one-off use
* AKA "I want to always launch a fresh instance of this app", e.g. Tor Browser
* Opening the base app would open a Non-Persistent VM as a default
* When closed, VM is discarded

UC2: Persistent VM for continuous use
* AKA "I want to continuously use an instance and have changes
persist", e.g. Signal
* "Make Persistent" action on a Non-Persistent VM changes it to
Persistent: this happens in-place, i.e. there is only one VM, a
Persistent one, as a result of this action
* Autosaving a Persistent VM would be a lot friendlier to the user
than requiring confirm-on-close or manual snapshotting
* When closed, VM persists

UC3: Non-Persistent VM based on a Persistent VM, for reproducible setup
* AKA "I want to set up an app with my preferences, and open one-off
instances based on this setup for specific situations", e.g. document
viewer
* "Create Non-Persistent" action on Persistent VMs; this allows for
templating-style functionality: a Non-Persistent VM is spawned off,
and is treated as completely separate
* When closed, Non-Persistent VM is discarded, while Persistent VM persists