Re: UX: Initial use cases & actions

[Alyssa Ross <hi@alyssa.is>]

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

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

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

Can you go into a bit more detail?  It sounds good but I'm having a hard
time picturing it.

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

The folder behaviour?  Yeah, that's true.  No reason we can't have a
folders of instances in the dock, _and_ a tabular launcher like this.

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

Yeah, I don't think it would be used often.  Would be fine to do it by
right-clicking the dock icon or window decorations or something.

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