Re: UX: Initial use cases & actions

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

On Thu, Aug 6, 2026 at 3:50 AM Demi Marie Obenour <demiobenour@gmail.com> wrote:
>
> On 8/5/26 07:23, Vaida Plankytė wrote:
> > On Thu, Jul 30, 2026 at 12:04 PM Alyssa Ross <hi@alyssa.is> wrote:
> >>
> >> Vaida Plankytė <vaidaplankyte@gmail.com> writes:
> >>
> >>> 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
>
> In Qubes OS (https://qubes-os.org):
>
> - UC2 is a template-based VM or (much more rarely) a standalone VM.
> - UC1 is a disposable VM template that has a blank (zeroed) private volume.
> - UC3 is a disposable VM template that has a non-blank private volume.
>
> Qubes OS has supported this since its very first public commit in 2010,
> so I think it would be very helpful to see what insights the Qubes OS
> community has to offer.

Absolutely! Related to that, I was looking at the "How to organize
your qubes" docs
(https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-organize-your-qubes.html)
and thought it'd be a good exercise to see how the different setups
would map across to our proposed Spectrum design-- it'd be a good test
of whether things get too confusing or (hopefully) easy to reason
about.

> >> If I have a persistent "My Configured Document Viewer" configuration*,
> >> do I choose "Create Non-Persistent" once, and then I have a separate
> >> icon or whatever to click every time I want the non-persistent version,
> >> or do I click something like "Run Non-Persistent" every time I want to
> >> do that?  In the former scenario, my new "My Configured Document Viewer
> >> (non-persistent)" configuration will be out of date as soon as I change
> >> more configuration in the "template", so I'd probably end up wanting to
> >> delete it and create it again from the template, which sounds pretty
> >> inconvenient.  In the latter scenario, that's not a concern, but it
> >> might be easier to mistakenly end up running a persistent instance when
> >> I meant to run a non-persistent one.
> >
> > I was indeed suggesting the latter: you'd essentially use either the
> > base app or a persistent instance as an entry point for running a new
> > non-persistent instance; that instance could then gain an icon for the
> > length of its lifecycle, until it is closed. So non-persistent
> > instances are created "on-demand", which avoids the issue you describe
> > of a separate non-persistent launcher getting out of sync from the
> > persistent template. I imagine the lifecycle of a non-persistent VM
> > spans a few seconds (quickly checking out a document) to a few hours
> > (more involved work/browsing), but not beyond that, so there's no need
> > to support a "rebase" on a template either.
>
> What happens if you click on the "run non-persistent instance" icon
> twice?  Should you launch the application again in the same instance,
> or should you get a second non-persistent instance?  Qubes OS does the
> latter, which is also what I recommend.  That prevents two different
> websites or files one opens from tampering with each other.
>
> Qubes OS also has "named disposables", which have the former behavior.
> That shows that both behaviors have uses.  However, in Qubes OS named
> disposables are used much less often than automatically-created
> disposable VMs.

Agreed that launching a second non-persistent instance works better!
The fact that we don't really support running multiple applications in
the same VM makes UX work easier, which is nice. There's a consistent
"each application is in its own VM" rule.

> >> To me, the latter scenario would
> >> be the ideal one, but we'd need to be confident our specific design
> >> mitigated that dangerous potential confusion.
> >
> > Yes, it's key to distinguish clearly when you're running one type or
> > the other, and also have default actions that mitigate confusion!
>
> Indeed so!  In Qubes OS, opening the disposable VM template (base app)
> when one wanted to open an application in a new disposable VM is a
> common mistake.

Definitely a pitfall we should ensure our design is robust against!

> > For visual distinguishing between persistent/non-persistent, we could use:
> >
> > - App icon outline and window borders (e.g solid vs dashed/dotted)
> > - Icons/labels in the app navbar, indicating the type of instance
> > - Naming (custom naming, but also automatic pre- or suffix indicating type)
> > - Colour - probably not? Seems better suited for theming persistent
> > VMs for different contexts. Though we could make non-persistent VMs a
> > paler version of persistent ones
>
> Solid vs dashed/dotted seems like a good idea to me.
>
> > Regarding default actions:
> >
> > It seems use cases where you'd want to primarily use a persistent or a
> > non-persistent VM are both equally likely. We could allow for a user
> > setting on a persistent VM that determines whether the persistent
> > version, or a non-persistent new instance based on it, are launched by
> > default; both actions would still be available as secondary actions
> > (i.e. right-click options menu). This would be convenient and avoid
> > users that almost always want a non-persistent to not have to always
> > right-click to access the option on a persistent. The downside is in
> > having different default behaviour across VMs, but if we visually
> > distinguish well between different types, then maybe having a default
> > behaviour dictated by the user for that instance's use case is less
> > risky?
>
> I think so.  I expect opening base app to be fairly rare.  I'd be
> fine with requiring the user to confirm that this is what they want,
> and possibly defaulting to the base app having no network access.
> Changing settings might well not need it.
>
> > We could also ensure sensible defaults for this. Making persistent VMs
> > start with this setting set to "launch a non-persistent instance", if
> > we feel this would be safer than the other way around? Cognitively,
> > having to go into the options menu to access the action of opening the
> > persistent instance itself rather than it being the default action
> > isn't too bad, as it's equivalent to "i'm editing the settings of a
> > template". Users that want to always launch it as persistent can just
> > switch it to the alternate behaviour.
> This is quite similar to the “private”/“incognito”/“InPrivate”
> features of various browsers, except that those features save downloaded
> files and passwords.  However, password management and downloaded files
> should ideally be system-wide in Spectrum, meaning that those, too, would
> be saved.
>
> I don't think we want to reuse the terminology, though.
> >> * configuration? instance? I wish we had a better name for these things,
> >>   even if it's agreed that it's not necessarily what we end up calling
> >>   it to users.
> >
> > Agreed. I'm almost keen to just use "VM" internally because it's so
> > much shorter to write, and explanations often end up mentioning the
> > term as well as "persistent"/"non-persistent" several times a line, so
> > it's a big space/cognitive saver. But maybe that says something about
> > how user-facing terms, that'll appear in docs in potentially equally
> > extensive explanations, should also be short and snappy. "Base app",
> > "saved app" and "one-off app" or something.
>
> Qubes OS uses "Disposable VM".  What about "Disposable app"?

Disposable is a good word, as people are familiar with what it means
from general life contexts. I quite like "app" too!

Is "window" an option, or would it conflict with how people would use
applications in Spectrum? If you choose to open a new window from an
app's menubar, does it live in the same instance or not? I feel it'd
be more natural for people to think of "app" to denote the actual
application, and "window" to denote an instance/VM, as they're likely
to be familiar with that terminology, but I can also see how that
could get confusing if "generic window" and "Spectrum window" terms
don't align.

> >> Overall these use cases sound right to me.  We should bring them up next
> >> time we have some community call or community something else to get more
> >> input, though!
> >
> > Absolutely!
>
> Indeed so!
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)