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 9AED18BB4; Wed, 05 Aug 2026 11:24:07 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 83DE88B76; Wed, 05 Aug 2026 11:23:55 +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-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by atuin.qyliss.net (Postfix) with ESMTPS id E1C168B75 for ; Wed, 05 Aug 2026 11:23:48 +0000 (UTC) Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-2d032846c95so11488245ad.1 for ; Wed, 05 Aug 2026 04:23:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785929021; cv=none; d=google.com; s=arc-20260327; b=QCGOJpcWi+lutFrPrcSQx7ShwlGxvlIHf0Jt8LwL6NCaAGWbW5em5gtKQCX01usU3C ITKfxOPfMZPDGMU4crNaeMLXQgSpdOYf01cIenPhQfpedZa2tFqf6xrIUD16MOotAPeX u5/AtrsAObAzzpc1GA6Q6DvUxjrZJKDFRKCUS4yzuYVibDb/CWaS7fLHh9wDNrOOFT6U NfY7ZO4UfV8EaGt9RcrfixklGnEwCYXwpwAZsl5tAQWT7lDrE5LE64Vc7uLAjkuT/Zff 70nlbXBZcohnIMmF9Go4+1Aqn9ycdhbr0/oRhUIPEayC0ZkSL8kQT2lPvzfSuRK59BZD LEgQ== 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=jhjxH77g8yTGW3VgMGmkt5MZefRJ+oN2xxkWgjrwegs=; fh=yMGRd5TP38CK4dSDtrxYzpMiJyqOSczUTIbb/EEwNQI=; b=SU50Xp4O6ZjlkfqnRzCa342YVxloWQ7YCrS6AJLjZt1g88Z7DFLU9ELaw4cwgZT3T7 gOW8uYKAyhZ5Nh/A8bDvbBLqP1rNrcaIx+gGKm3js4LZCMtIcnLHarJolpOD/1qL07zd Za9/iNjrCG2w82M4kPJt+vYB68Vcz0gxb8ENZzT+n8B4gpUsQ/Omy1vay3OWAX7scCRZ xt7U/tnlm48Zv+aVVtmnAVATZIqIeDgYbPNeKaAqKG2mac7TKf68VYEf8esmgN2vhY+6 EIg5VCkBskNVRbAQ7yAm2L+xzY2M3ui0ztKfcVWICndvttsNh35oQZYgXdILlPRyCVvm CbVw==; 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=1785929021; x=1786533821; 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=jhjxH77g8yTGW3VgMGmkt5MZefRJ+oN2xxkWgjrwegs=; b=iJK97vHMltqPCkW/InSQz81ZH0bjdsU1EATilF+rNp+ZcgtzpALlU8wxz0Du9i4FL5 yMOsAoMzO9vbY1Sd7Ja08xG3icwWPnq1c9beO+2jyuXLsmpc+OYCnPlbiNp4iJdsfkZ4 GITfy/oxjkcR9qctVsABpil4n0KtqKD2/RAt6MogfxuIACKRGYITigxx90jxOgc1NEfC I5Tv6PIdi2qh54pCs/wQbsQvs2RgxcvXGvnzj5DnhaIqLd3S3EAX8qaa7/eST4RJsZTK 0eM2IncFBJy5NQW7NkPWsfKmIxoKY5q+F5m7SBvQJ4YRW9O+UlvRzP+D4a/LGP7Wi6/I sfBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785929021; x=1786533821; 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=jhjxH77g8yTGW3VgMGmkt5MZefRJ+oN2xxkWgjrwegs=; b=VTuZJ1KUnWOj/6wPiHGB2iN1ZWg1oVBuV51mseZkSSxQDZKxIpGMEVfLQdofi0QPEt tYXR1J7mCG0m5uRo55CRTPDw8pbaxMPBJg09/4wwByzG+k67EsD+ZWvDKQugLiRsOzBB Inmali+OYb8X9YVRlzp744/jdKi/+imrAWWS13q/78HoIExOrOUnKw8QT7AKY2Pxz/6G uhLibReqeES1AujOKW84f45XXQ2rpOGijsPm/uELm1OUq/0k13YBJm7tBeENwIZvJc+N eZvYBlRSlYDw6ptO/k0Zbn9DWTh9GUZHF+gdx9dzbdL76ofEh/shUNeY2pgIaANOiJXF IEiQ== X-Gm-Message-State: AOJu0Yw9SObewp8/o4L+jdeOhozhqO+RtqK8tLUYPIXGSQkei57lE/QH iOZ0T9D+NjD8USSMqPYHUxtrBdGpQJt/DX25JhBXtUgBS833q+4evWsqz8MuCd2Yv1N3csjnCXX OGqy18XbRCt7GIGUevyFQ2bb1jAXM/DWIzlKU7ls= X-Gm-Gg: AR+sD11gg6DprkG0A/t8+5d8FoelgFQX1+2voz8qGZ2quG7A8oCxrKkt+sJpbhQ+8Xt fTTr7e4+lNQJF5yGRgI24H5O5QsvMT6xG1dkIQgiyM5jAXWpvt2T1QCZvYgOsM2DIXeFjYOUU9/ DlHe9Hav0LzRsG///v3atAihjhnrHq568OpjtBucC5LWmEDiiP9zMCguwTxNO4qsGdOUhLV2XWQ kjFm4qzLYeV8qsVDA+LnolIpiXPX7T6Z81R7eiam8BdLjU2Ewm5u8PF3W7pw2PdKi/j6N/eV1xu 0XTUxoke+qMc3BbfxJUCuolrw321pZ8DPbe5O0/KTFeqsL4KtMlXgTFxYVsfaNtRck1YNUYxr6d qoxwOLzCWOw== X-Received: by 2002:a05:6a21:6915:b0:3c4:46ca:3350 with SMTP id adf61e73a8af0-3cb85df0a05mr7415530637.6.1785929021251; Wed, 05 Aug 2026 04:23:41 -0700 (PDT) MIME-Version: 1.0 References: <87cxw43fht.fsf@alyssa.is> In-Reply-To: <87cxw43fht.fsf@alyssa.is> From: =?UTF-8?Q?Vaida_Plankyt=C4=97?= Date: Wed, 5 Aug 2026 12:23:04 +0100 X-Gm-Features: AUfX_mxXrYSMtUB6w0AWOepwuRjnL5kKyQMP-xD0LHJktJZlgELPR9iYKY08EaU Message-ID: Subject: Re: UX: Initial use cases & actions To: Alyssa Ross Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: TJ6TNCY7VPXAGZRJ72TKBDONTMPDQ6AH X-Message-ID-Hash: TJ6TNCY7VPXAGZRJ72TKBDONTMPDQ6AH 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: 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, 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 pers= ists > > 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. > 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 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. > * 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. > Overall these use cases sound right to me. We should bring them up next > time we have some community call or community something else to get more > input, though! Absolutely!