Vaida Plankytė writes: > On Thu, Jul 30, 2026 at 12:04 PM Alyssa Ross wrote: >> >> Vaida Plankytė 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).