Re: UX: Initial use cases & actions

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 8780 bytes --]

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.

>> 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.

>> 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.

> 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"?

>> 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)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]