That doesn’t make any sense, “Uses must be invited by trusted users or staff, otherwise users can sign up on their own”.
I believe this is a mistake, please let me know how it goes.
1 Like
The key word is “otherwise”. This is for when the latter setting is OFF and it is not “Invite Only”
4 Likes
Ah, I see, I missed that in the moment - sorry.
2 Likes
Maybe the copy could be improved to make it more clear?
5 Likes
Comma splice is never a good sign for clarity 
3 Likes
Suggestion:
New users require invite by staff or trusted users to sign up
I think the “otherwise” part of the sentence is implied. For instance, the Private setting doesn’t say
Only logged on users can access this community, otherwise all users can even when not signed in
3 Likes
Changing the description is certainly an easy change we can make… but would it also help if we changed the description when toggling, so we’re describing the current state?
For example, for invite only we can have:
true_description: "Members must be invited by staff or trusted users"
false_description: "Anyone can create a new account"
8 Likes
It would certainly make the experience more understandable.
Maybe I have been looking at this too long, but it seems fairly clear to me as it is? @awesomerobot suggestion is interesting but my initial reaction is:
- more translations!
- setting label and explanation do not match
Seeing “Private” and “Content is visible without logging in” when the setting is disabled is more confusing to me than what we currently have.
Maybe the answer is a more explicit UI, but then that introduces more words which I think people will also find confusing unless we are careful about it. Maybe we have a slider that has “Public” on one side and “Private” on the other, with different helper text for each option?
In terms of improving copy with the current UI, what if we were to keep the language but prefix with “When enabled, …” ? That way it would be clear that the description implies what you see when it is enabled, and implies the opposite when it is disabled?
2 Likes
It’s definitely trickier with the current layout, the annotation which changes is furthest from the button within each section.
Private for example should probably be ‘Public’ until the switch is toggled. Invite-only could be ‘open registration’, etc etc.
Either that, or move the button and place the annotation adjacent.
1 Like
Would you be able to make a mockup explaining what you mean? I am not quite following.
Yeah this would be a step further than changing the description only as I did above, and would be more like this… right?
This can be a little confusing in its own right, because it can be interpreted as “turn this switch on to make it public” but at least after an initial toggle it might be cleared up.
Then there’s also something like:
These kind of switch toggles are notorious for confusing people, going back to a simple checkbox could be better here.
3 Likes
I think your example above adds clarity - at least for me. Having Private next to an unlocked padlock is super confusing.
I do like the switches personally.
Your other example is also great, but where would we show the state description?
1 Like
I had a thought today that it might make more sense to reverse the first three options on this step, and assume that most sites will want to be public, allow registration and not require approval. I believe this is the case.
So for most people on this step they will scan the list of enabled settings and confirm that things are as they should be. Those that want can disable settings according to their wishes. On our hosting on the basic plan where sites can only be private and invite only the distinction will be very obvious, and it will make sense to people that to gain access to public and open registration requires an upgrade to the standard or business plans.
@ella what are your thoughts? Would it be worth mocking this up to see how it looks?
2 Likes
