Re: UX: Initial use cases & actions

[Alyssa Ross <hi@alyssa.is>]

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

Vaida Plankytė <vaidaplankyte@gmail.com> 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.  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.

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

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!

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