About using experiences inworld.

[Rolig Loon]

A short laundry list might be helpful, as you suggest, Love.  My basic observation -- based not on chatter in the forums but on the  widespread opinions expressed by people in world and by people who leave SL frustrated -- is that SL residents complain all the time about the learning curve here and about the user interface in particular.  Anything that presents a resident with more decisions, more options, more things to worry about should be avoided if at all possible.  So yes, I can see some value in having perhaps a short list of common things that you might encounter in an Experience, but ....  

The next question, of course, is "Which things?"  Forget about things that involve asking permission to take money from you, because Experiences quite deliberately cannot do that anyway.  So ....  Teleport?  maybe.  Control your camera?  That might be a good one.  Attach a HUD or a shield of some kind?  That's good too.  The list gets pretty long and starts to fill up the dialog box before you know it, so if we're trying to avoid clutter, how do we decide which ones are most important?  And what about all those things that you've always been granting automatically without even knowing, like animating you avatar when you sit down? Should we ask about them explicitly in an Experience dialog?

I really don't know the answers, Love.  All I know is that most of these questions lead to making residents face more choices. They break immersion, they slow things down, and they are just plain annoying. When LL is looking for ways to attract and retain users, those are not going to be high on their list of great things to do.

[Gabriele Graves]

So the same general information that everybody has about wanting SL to be easier and less complex but nothing that applies to Experiences specifically.

I don't even disagree with that generally.

SL should be simpler and easier for people.  I just draw different conclusions about how and where that should be applied.  Simplicity doesn't mean not having advanced options but in having a set of sensible, safe defaults initially presented with more options to drill-down into for advanced users should there be a need to have them.

A UI should be as simple as it can be to get the job done properly.

If you dumb something down too much it isn't fit for purpose.  For an extreme example, removing "Yes/No" buttons and only providing an "OK" button for dialogs that ask questions.  It becomes no longer fit for purpose and is useless but has one less option so is simpler.

This is exactly the problem with the Experience requests.  They are not fit for purpose as is if that purpose is to get informed consent.  There is no meaningful information in there that allows anyone to distinguish one Experience from another.

Nobody should be asking "Why don't some residents want to agree to an Experience?" but instead should be asking "What is provided in that request that would make anyone agree?".  It might as well be a box that just says "Region Blah wants you to agree to an Experience, Agree/Disagree" for all the difference it makes.

Unfortunately no amount of text you can put in that request box would give a proper account of how granted permissions will be used, when and how frequently and then enforce that.  Therefore, alternative methods are needed to make this feature fit for purpose of operating under informed consent.

So if it isn't fit for purpose then it isn't complicating it to add extra parts to make it useful, it is just making it fit for purpose.

Finally, no offense intended to Love but my opinion is that adding MFA isn't going to fix anything and doesn't add anything extra that is useful.

[Qie Niangao]

10 hours ago, Innula Zenovka said:

Possibly, but the real objection is that it would necessitate LL's completely re-writing the experiences code since, unlike regular run_time_permissions, experience_permissions aren't granular.   If you accept the experience, then scripts set to that experience automatically have all the relevant permissions.

You're asking for something that might  look similar but under the hood it would be completely different from experience tools.   It would mean LL making a whole new product.

That's true. But there's a problem with the current product. It's not as bad as Pathfinding, say, in the "doomed to failure by half-assed implementation", but it's a problem.

How many people even noticed the following gem?

Seems to be fixed in the latest Linden viewer, but still showing in current Firestorm and Catznip. Maybe somebody screwed up the patch after noticing that the original permissions dialog didn't reflect those two "recently" added Experience abilities (llSitOnLink and llSet- / ReplaceAgentEnvironment), leading me to wonder if Experiences were taking those permissions before without telling anybody.

At the very least, the text "… unless it is revoked from the experience profile" is a loss. Nobody even recognizes that nomenclature, nor does it suggest how trivially simple it is to do.

Honestly, I think the entire dialog needs to be trimmed down to even less than what Lucy suggests, simply "Do you want to participate in the AVsitter experience?" with Yes / No / Ignore / More Info buttons, where More Info raises a detailed dialog that includes the blocking options and the laundry list of permissions (possibly tailored to the ones the script actually wants) plus some text the script may optionally supply describing why the user should consider participating.

(I must admit, however, that I simply don't understand the MFA application @Love Zhaoying suggests. I can imagine some virtue in giving the user the choice of which permissions they want to grant the Experience, much as they can select specific app permissions in recent versions of Android, but that vastly complicates the app programming, and I imagine scripts too would need to be more complex to manage a hodgepodge of granted and denied permissions. But in any case I don't follow how this maps to MFA.)

[Lucia Nightfire]

12 hours ago, Qie Niangao said:

That's true. But there's a problem with the current product. It's not as bad as Pathfinding, say, in the "doomed to failure by half-assed implementation", but it's a problem.

How many people even noticed the following gem?

Seems to be fixed in the latest Linden viewer, but still showing in current Firestorm and Catznip. Maybe somebody screwed up the patch after noticing that the original permissions dialog didn't reflect those two "recently" added Experience abilities (llSitOnLink and llSet- / ReplaceAgentEnvironment), leading me to wonder if Experiences were taking those permissions before without telling anybody.

At the very least, the text "… unless it is revoked from the experience profile" is a loss. Nobody even recognizes that nomenclature, nor does it suggest how trivially simple it is to do.

Honestly, I think the entire dialog needs to be trimmed down to even less than what Lucy suggests, simply "Do you want to participate in the AVsitter experience?" with Yes / No / Ignore / More Info buttons, where More Info raises a detailed dialog that includes the blocking options and the laundry list of permissions (possibly tailored to the ones the script actually wants) plus some text the script may optionally supply describing why the user should consider participating.

(I must admit, however, that I simply don't understand the MFA application @Love Zhaoying suggests. I can imagine some virtue in giving the user the choice of which permissions they want to grant the Experience, much as they can select specific app permissions in recent versions of Android, but that vastly complicates the app programming, and I imagine scripts too would need to be more complex to manage a hodgepodge of granted and denied permissions. But in any case I don't follow how this maps to MFA.)

This was reported last year https://jira.secondlife.com/browse/BUG-231021

It is fixed in the current Firestorm beta.