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 1BDE945F9; Wed, 19 Aug 2026 10:25:03 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 7583345E0; Wed, 19 Aug 2026 10:25:00 +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.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_PASS,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) by atuin.qyliss.net (Postfix) with ESMTPS id CF27845DC for ; Wed, 19 Aug 2026 10:24:58 +0000 (UTC) Received: by mail-vs1-xe2d.google.com with SMTP id ada2fe7eead31-75609e844faso544290137.0 for ; Wed, 19 Aug 2026 03:24:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787135097; cv=none; d=google.com; s=arc-20260327; b=UGYbj3QtzSzYsqGZyKY87rlcRRR3+u1N+kFX/mRXJWKxyeDySu2Tfyxcto05NKSDT9 pt1ww7g9dzBxAxbtNZIIcU2aKu5viL6eflDk98dRJe3nKhs06wM7Oh0Mk3EqFpTC9I5z oq75ZZRdSVKSDRvPw4y00C59x9scY/RMOgylWr9KZt4lnN2DWSrXWpJIx4KpNWJnKJpx MVrRvf/n9/m5jcH4Fb/pyP4U6X9cVZ55mscJjCR0tvcXWcLx06pxWBpIFCVYvi4BjXSD LF+8t037PY3+NHBddr/l4FzQr1OMTQydzEBbO8i7u/jsAkA7J1ObPMefyLxU98qFUnok KLSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ZUtCUS6G60bWpL++CdBGaAp/y3yLSdZRoClIS9EXub4=; fh=/qIBy/fzr7tIXdcp4ytYokbiIOO2IfDTYCek0idnaRw=; b=An8iZUxvOdRwZz3rQnnjRzAPxab62PuyzzMSF16zS4fxi1L5w+h9ZZRpiWppa+/Sej ChL8AVchX+0VwKDmPJwe+28lyIlsg2aw8TdCND4jxIyNCAUIzm7Qm5tlv3MaUnQK0GlD YJbRUeURTI4I7YHflzuEm/FDT3hI7vFTduHByhddqds1zp122GnGhtKLX8rIF3Wbhlcp 1mhIoVLp1ZyTmku0hLVPX+BmYs3wrYgOB4Oik0u7nqE9JjJ/RmRYqmjBAe+u8jOnnq56 1DqYgAd87cF2tN7AVOngUOz8VF1A2Wf5901COpNAaQLzncsjCM+umi/jqQwCM6NPpiRK +OPQ==; darn=spectrum-os.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787135097; x=1787739897; darn=spectrum-os.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=ZUtCUS6G60bWpL++CdBGaAp/y3yLSdZRoClIS9EXub4=; b=iAMTv0/pDQe95VvYtT+CeaZKF3rPIdr/uLQLqpF63pwwph+wi+DF5xp85d1j/DM21x RZ3ijw9/f2gqK4RRTiQwxeYPmLm5MFSPj8o/5+kmQb/dEaWESyGRDRCHiCJLudhVF1bM FT2mPELs2UdoQWdfIEWqtYJfPOf8e6wG+w7K7oKDexBWW8Ex+tcy8WuZa1SXvCPsCuGF 57XhUoTZMF0xlikRPl7knHvRj5NbguQlAPKe34jMq+N3rRqe2X0DDTyUG92qr6nuZpll u0Kj0+/6SlYRzqKpFgLL9zktzjN5iYP5Yd0r1YXptlktaDDuwCG3XKQRMNN4X1xRVZh1 +M+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787135097; x=1787739897; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ZUtCUS6G60bWpL++CdBGaAp/y3yLSdZRoClIS9EXub4=; b=ealrCFR01i4t3+ar17wBcpNM0B/XCkxaYqWHy1Zt+2WPxFJiVtD2kdeEcrfM24UYOB KU+A1j4RlxxRJ/26ViGmRNzK7HfSl9kDtXZEcCaX7c3lKwW2T78A/XfaDGymqJ0Gg9r1 ENnbPN9NC3TVuJ2pyX0/liP4h75+TSbt4/ZIv4Zh1LZ6wZNaaO/eg+UKOF8Uf2RjLxob QHQkoTzmI3HQUg9lihRQJeD9JGtoO6cRULO7IxldwWP0li0iUQ0gUhTXYd2cDPVK5F3G CyVOAxpPQ1SBdsKYDkeimfcrvwCRLjj9Nt/6+aSOBXbSY+eXqDU79z4wW42CwV5NzNbN ab3g== X-Forwarded-Encrypted: i=1; AHgh+RqUfxkFrBIeQ7hIUU0ZukJTsEIbuuH7SJGJROHi27eFEY7YtveR8WjooBSBN0e3XvZdS8e8Ug==@spectrum-os.org X-Gm-Message-State: AOJu0YzULlxObilrrXHB7w+U84NWCF3NfSlYqGVfBbUhfF6y1YoFL4Vf KqY9loO0zutG1INn4cFLri0sa4zhkdkBvpA0E7Zut2jW/Qv1sdTtCRgu6Yrr2O9yUI15xxkatr1 +bWFW1hB2x7ZlU4LSBWYZj7p3mlXStIQ= X-Gm-Gg: AR+sD10Q8i5uVvV7RzvmOa9Li3tCRDAlSmnjcmtWEp4BbYYeS5Ivkh1dCsNP4OWMAbW 6HRUMSyiF2VIU7tn3URIrHIUssFWEKX6qu4u6vd9B0xavWksdVNtFxr6AsXK0Eexbc8adKEz96i Q2NeUNB4e7vVZgubB2cLeBHQOXXTHsFn78G1MwBdDk76T+1/Wsgthsy0y0mAuvOw2C8t3lOLSjp XL0SM0acIa402Dqw5S3qa8fc/ZzfV6ao8A3d2G2AfZuenm71mVpiITEAF2fWcmCY9ZRA/GCWrHc UEs5r54rZRBDTdYM/boR7wNtzj8/bt4TnrPiLmQziOX1wjaBoDcK7h1qNqeiaZfZE52UFQ0SoKU = X-Received: by 2002:a05:6102:e0b:b0:778:86f2:9f23 with SMTP id ada2fe7eead31-77886f2a09cmr139056137.0.1787135097153; Wed, 19 Aug 2026 03:24:57 -0700 (PDT) MIME-Version: 1.0 References: <87cxw43fht.fsf@alyssa.is> <4f49473e-a2a1-48a8-acb9-5237fdaac648@gmail.com> In-Reply-To: <4f49473e-a2a1-48a8-acb9-5237fdaac648@gmail.com> From: =?UTF-8?Q?Vaida_Plankyt=C4=97?= Date: Wed, 19 Aug 2026 11:24:15 +0100 X-Gm-Features: AcwNN1XisNRnaml6yImtaDcm16Y3gQSHZNfQk321ixh4ZJgVZBo7S8nwb-5rYxg Message-ID: Subject: Re: UX: Initial use cases & actions To: Demi Marie Obenour Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 6OPHZNRY7UJXCEFLDQBVAUS4DUGKPYJH X-Message-ID-Hash: 6OPHZNRY7UJXCEFLDQBVAUS4DUGKPYJH X-MailFrom: vaidaplankyte@gmail.com 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: Alyssa Ross , 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: On Thu, Aug 6, 2026 at 3:50=E2=80=AFAM Demi Marie Obenour wrote: > > On 8/5/26 07:23, Vaida Plankyt=C4=97 wrote: > > On Thu, Jul 30, 2026 at 12:04=E2=80=AFPM Alyssa Ross wro= te: > >> > >> 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. To= r 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 continuousl= y 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 set= up > >>> * 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 pe= rsists > > 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 volum= e. > - 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 Viewe= r > >> (non-persistent)" configuration will be out of date as soon as I chang= e > >> more configuration in the "template", so I'd probably end up wanting t= o > >> 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 whe= n > >> 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 u= se: > > > > - 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 t= ype) > > - 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 =E2=80=9Cprivate=E2=80=9D/=E2=80=9Cincognito= =E2=80=9D/=E2=80=9CInPrivate=E2=80=9D > 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 thing= s, > >> 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 ne= xt > >> time we have some community call or community something else to get mo= re > >> input, though! > > > > Absolutely! > > Indeed so! > -- > Sincerely, > Demi Marie Obenour (she/her/hers)