Re: UX: Initial use cases & actions

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

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.