"Experimental Feature" standardized flag

[ninavizz]

The problem you're addressing (if any)
Sometimes an unstable or experimental feature will need to be deployed, to collect feedback from users in the wild that is needed to determine the feature predictably stable. These features need to be clearly marked, and their experimental nature briefly qualified, so that users understand the dependability and experimental nature of a thing they may choose to use.

A standardized system should exist, consisting of: 1. An icon identifying such features, and 2. A bubble explaining a) what "experimental" means across Qubes OS, and b) how that applies to the specific feature identified by the hovered-over bubble.

Describe the solution you'd like
The laboratory semiotic of a beaker has been observed in many interactive contexts, to signify experimental things (an entire release, or an individual feature). Dividing the bubble into 2 sections, one that is consistent across all instances of the beaker icon, and the second specific to the experimental feature highlighted, feels like a solid approach.

Where is the value to a user, and who might that user be?

• Users with high security risks that need to understand the complete scope of a feature they're opting into using.
• Users who don't read each and every published notation of releases (so, most).

Describe alternatives you've considered
RTFD, winging it

Additional context
Specific example this was created for, is the "Open In disposable qube" option in the vm settings' Applications tab.

Related, non-duplicate issues
#6366

[andrewdavidwong]

Is "experimental" just a synonym for testing?

If not, then how is it different?

If so, then be aware that currently users have to specifically enable a testing repo in order to experience anything in testing. This is probably not trivial for non-technical users to do at present (though I can imagine an easy toggle in the future). This means that, at present, only users who deliberately seek out an "experimental" experience are likely to have one. Users who don't want this experience can't just stumble into it by accident. This means that, at present, these experimental flags will not be seen by regular, stable, non-testing users.

On the other hand, if you are assuming that we will start shipping experimental features to all users in the stable branch (current), then this seems like a bigger project management decision. Maybe it would be fine in the case of clearly-flagged UI features, but that's a separate discussion.

[ninavizz]

Is "experimental" just a synonym for testing?
If not, then how is it different?

Nope! The specific "related" feature flagged above, is for setting an application to by default open files in a disposable VM. This one feature, @marmarek cited as needing to be deployed at a mass scale, for more users to deliver feedback on than the usual testing repo contributors. While this need is for a one-time thing, it reason behind the need feels applicable to future Qubes development needs—so I thought it'd make sense to pitch this as a global system, that would get rolled-out first with just this one feature... but be available, should more similar situations arise.

@marmarta's initial mockup for a redesign of the VM Settings: Applications Tab window, shows all of this explained in several lines of text at the top of the window. However, users just don't read stuff.

No matter how reasonable it is we expect them to read it, and how much we want them to read it—they just won't. Which has been a known common user behavior by the broader UX community, for years. I also, personally, keep observing this in user testing over and over again, in high-stakes use contexts... whether it's the SecureDrop app in Qubes, or California's driver license application. People just don't read stuff, unless it's small bits of text that follow a contextual help pattern.