From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 89F368D73; Wed, 05 Aug 2026 16:07:43 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 0C2048D88; Wed, 05 Aug 2026 16:07:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fhigh-a8-smtp.messagingengine.com (fhigh-a8-smtp.messagingengine.com [103.168.172.159]) by atuin.qyliss.net (Postfix) with ESMTPS id 2C7198D87 for ; Wed, 05 Aug 2026 16:07:40 +0000 (UTC) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id 4A3B51400014; Wed, 5 Aug 2026 12:07:38 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Wed, 05 Aug 2026 12:07:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1785946058; x=1786032458; bh=9/8D1+JE8n Kxy8k8hYZtG9btVQd6pFF/EEtXiuNsHHk=; b=KD4+2hmdUIIXmjiIZmesJguTp/ H9i20nH8GYrxttR2vcChMHkCH3YbeqRvJEXWYQZlS4ELgKBu3pFyHienxx+WnNuQ t+hB9i4lFm8l6o/HqaUJ/qItgDgnRj0o+BeibE3gKLyreM/D4P9fZ80dcAEPFvHQ NjYUq9NXkUiWZw8fOC4y9zgclOlgTt4VjXaV3NOre4wXBWm1n7bdUnF8YNB+6M9P /w0X4BcZw4hBxcxhKHlHTJjK2hfAL8SHk8rDgFEB1EWeDRDmAhkli4w8/ETDyQ46 UQ/WylnJ/5BwyG3koozPHGG0NMsn3TUMNZ4WjS7j5zDOQ+1frf3CklSHkNxw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1785946058; x=1786032458; bh=9/8D1+JE8nKxy8k8hYZtG9btVQd6pFF/EEt XiuNsHHk=; b=A7d6W4Mg7AKNh64D7M3yYSRYctw72LFqoCWOLOEhBpkrw88eLFy kh5KrdY+V8p6XbVZ8NTm5ONdKlGpbXGkYXfgSFdiC9YFEeTaYNn08AW51M4oxbo/ Bi55Eq7kmFhu+VAuD5b2/W/vUWIhCjqqTIFFmpRx2CJ7UYfqufpHrQ1cqFz/hRxv yn0U8egHRrayVm4eBzwE3zcBIx93LhRYqZkdxpks1Os6EX3JC8PkqlddjZSVwDMx ko7qx+YYl76gnPnwW28oSyfK/QkMEtGyGCz/ijhtcvZQT7WkSEV2W8OQMmfbSsqk iKtzF4/Oedp9n3QibCrhuEqgQDFx+At1hcw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFq1c8fo1GIvHRo75Ic+rZNK18rszGUfeiAIhTmLWd8kKgRvmUzEzCRJ8LNhybumI wb+SXCk3jek5s4hWp03ZoC1cMRLU0i7rnyNd1zG/FYxsUIHF/5iAUm1wjjwj7hsu/iY8qa zcrCg67w9e2fyL35Fjuw0b++Cf06thIkvEeN/37VZX59r8RJMDcLv6TYaKA/b3szkIMROv 7N26K2I+kjy8RpFEw+0rtx8tTlt72XVRwbBC/+1fkjNx6Ge0enthhTJBoOLt/lpAfG/f17 YyMlPxBZEa9NiJbcQdcPvGz+a6sj2NOzEGXchLSr6RAw9OKzFAPdqRQP4oOCoL+k2kmFdO NWU8yljCGWFwsC3SGlByMnnO2p40MTgaQabZTh5XoN4NPuUBKPBOeEIjuI4uhpTOrFwwKk YwVSTM0TDt6u/jwFALLiao8k4ngPU+qbcY+/5Dk2Nv7sEMmZnDINpzft0lxbhx2NsrEmFT kvmAfOZJVATaFb/iN5UkDRUroDwNskTfC1d/WmYuNj+gXJM4aB4qzdj5yvkmLejt2MQ/+P 5zYATN14eUpiue2LxArAnJVplNfV0mCuSO25+giMkglouiZt6KLmS1T8g4paFMzhMMTNfL ER9TzXf7WwdV/FwVitHwntJr7ddId3NWByL4YIcq9lxPvdI67i98uSOhGNGQ X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Aug 2026 12:07:37 -0400 (EDT) Received: by fw12.qyliss.net (Postfix, from userid 1000) id 4EBB1C78074D; Wed, 05 Aug 2026 18:07:36 +0200 (CEST) Date: Wed, 5 Aug 2026 18:07:36 +0200 From: Alyssa Ross To: Vaida =?utf-8?B?UGxhbmt5dMSX?= Subject: Re: UX: Initial use cases & actions Message-ID: References: <87cxw43fht.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lixb3w23bm37uqeu" Content-Disposition: inline In-Reply-To: Message-ID-Hash: LLPBEYOVYHXQ47M4JFQR45HZOUTWGXCS X-Message-ID-Hash: LLPBEYOVYHXQ47M4JFQR45HZOUTWGXCS X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.10 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --lixb3w23bm37uqeu Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: UX: Initial use cases & actions MIME-Version: 1.0 Vaida Plankyt=C4=97 writes: > On Thu, Jul 30, 2026 at 12:04=E2=80=AFPM Alyssa Ross wrote: >> >> Vaida Plankyt=C4=97 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 per= sists >> >> 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 typ= e) > - 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 | | =E2=A4=B7 My configured Document Viewer | persistent | non-persistent | | Signal | persistent | non-persistent | | =E2=A4=B7 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 =E2=80=94 I'd quite like not to use "VM" inter= nally 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). --lixb3w23bm37uqeu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQGoGac7QfI+H5ZtFCZddwkt31pFQUCanNfxgAKCRCZddwkt31p FS9jAQCmOE3ZJhbx4XsW8kcv1OGUOCmXp+vvshAtLZbTvo+iEwD+KELV1akWlU0A oZxyW2z8wHgrN5WnOLhANP1w71CQNQM= =BVgw -----END PGP SIGNATURE----- --lixb3w23bm37uqeu--