UX: Initial use cases & actions

UX: Initial use cases & actions

[Vaida Plankytė]

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

Re: UX: Initial use cases & actions

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 3348 bytes --]

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

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

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

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!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: UX: Initial use cases & actions

[Vaida Plankytė]

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

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

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

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?

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.

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

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

Re: UX: Initial use cases & actions

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 8158 bytes --]

Vaida Plankytė <vaidaplankyte@gmail.com> writes:

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

Good, we're in agreement then. :)

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

Yes, as long as it's somehow visually obvious there's a lot of
flexibility for taste / other factors.  I'm intrigued by the idea of
different outline patterns.

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

I wonder whether we might be able to have a UI that makes each option
equally convenient to use.  I'm not sure how you'd do it with a
dock-like interface, but if you imagine a classic Windows Start menu:

| Document Viewer                 | persistent | non-persistent |
| ⤷ My configured Document Viewer | persistent | non-persistent |
| Signal                          | persistent | non-persistent |
| ⤷ Signal (Alyssa Ross identity) | persistent | non-persistent |

No additional clicks introduced by adding the persistent/not
differentiation, because we take advantage of two dimensions.  What do
you think?

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

I think I meant the opposite — I'd quite like not to use "VM" internally
because it's never clear to me what it means.  It might be a result of
some distinction that's only clear to me, because it's a mismatch
between a technical understanding of what a VM is and a more conceptual
one.  When the term "VM" is used, it's difficult for me to tell whether
what's being talked about is something that starts existing when an app
is launched and stops existing when it's closed, even if that's a
persistent instance (this is the kernel's point of view), or whether
it's something that sticks around (perhaps a more human point of view).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: UX: Initial use cases & actions

[Vaida Plankytė]

On Wed, Aug 5, 2026 at 5:07 PM Alyssa Ross <hi@alyssa.is> wrote:
>
> Vaida Plankytė <vaidaplankyte@gmail.com> writes:
>
> > On Thu, Jul 30, 2026 at 12:04 PM Alyssa Ross <hi@alyssa.is> wrote:
> >>
> >> Vaida Plankytė <vaidaplankyte@gmail.com> writes:

> > 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?
> >
> > 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.
>
> I wonder whether we might be able to have a UI that makes each option
> equally convenient to use.  I'm not sure how you'd do it with a
> dock-like interface, but if you imagine a classic Windows Start menu:
>
> | Document Viewer                 | persistent | non-persistent |
> | ⤷ My configured Document Viewer | persistent | non-persistent |
> | Signal                          | persistent | non-persistent |
> | ⤷ Signal (Alyssa Ross identity) | persistent | non-persistent |
>
> No additional clicks introduced by adding the persistent/not
> differentiation, because we take advantage of two dimensions.  What do
> you think?

Oh, that's a neat idea! I like that it groups apps based on their base
app. Also, I know we discussed previously that if we take the
"grouping shortcuts into folders" approach, users could neatly
separate out different contexts (work/personal/etc)-- but if we
supported some sort of tagging for apps, then users could filter the
list of apps from this launcher instead, which seems much more slick.
Perhaps each tag could be linked with a specific colour that also
affects the window decoration, for additional differentiation?

A slight difference between the two actions we'd want to ensure is
clear is you'd be /opening/ the persistent app, but /creating and
opening a new/ non-persistent app. It might be worth making that
explicit in the action labels: "open persistent" and "new
non-persistent" or such.

Once an app is open and visible in the dock or pinned, we could still
support the behaviour we've been discussing, for easy access.

There's a related additional UC we had discussed:

UC4: Duplication of a Persistent app, for separate persistent uses
* AKA "I want to set up an app the way I want it, then duplicate it to
configure two instances with different accounts", e.g. two Thunderbird
accounts
* "Duplicate" action on a Persistent app creates a copy as a
Persistent app, treated as entirely separate
* If we implement Persistent apps to have autosave, then duplicating
an app before making complex changes is a way to back it up in case of
mistakes
* Potential addition: supporting duplicating a Non-Persistent app, if
it's technically safe, easy to implement, and useful

It doesn't seem like duplicate needs to be a top-level action the same
way as "open persistent" and "new non-persistent" are (even though it
technically is the more correct analogous action to "new
non-persistent)? It could be relegated to a context menu, or we could
explore having all three actions visible if we think it's likely to be
used more regularly.

Re: UX: Initial use cases & actions

[Demi Marie Obenour]

[-- 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 --]

Re: UX: Initial use cases & actions

[Alyssa Ross]

Demi Marie Obenour <demiobenour@gmail.com> writes:

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

Definitely the latter.  Qubes supports running multiple applications in
the same VM at the same time, but we don't really.

Re: UX: Initial use cases & actions

[Vaida Plankytė]

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)