So I don't how to write literals for a feature that creates a password layer before allowing people into, say, a virtual meeting room. For now all I got is "Enable entry via passcode" or "Set passcode" but both don't seem to give enough context to the person setting it up that the passcode should be mandatory.
1It is difficult to understand what your problem is. Are you trying to create a "configuration" page for a meeting room? If so, can you share your current designs with us so we can better understand your requirements.– musefanApr 15, 2021 at 14:35
Thanks for your comment. To be more clear, imagine there is a host who is trying to setup a video meeting of sorts. And while inviting people he wants to setup preferences like locking the meeting with a passcode. I just need a UX literal that conveys that you can set a passcode your participants have to enter to get into the meeting. The present UX doesn't convey well. I have added a screen for reference. Imagine the "video meeting" is named "Broadcast"– WannabePM0_7Apr 20, 2021 at 16:24
Suggested wording and behavior
[✓] Require a password to view the broadcast: [ ••••• ]
[ ••••• ] represents a normal password input field like you have in your mockup.
If the checkbox is unchecked, the password field should still be visible, but it should be disabled (i.e. grayed out) and its contents should be cleared:
[ ] Require a password to view the broadcast: [ ]
First, I’ll note that this label’s terminology should be consistent with the rest of the app. My suggestion assumes your app has “broadcasts” with “viewers”. Adjust the wording as necessary if your app has, for example, “participants” instead.
Your latest wording “Ask for a password when people enter the broadcast” is much clearer than your earlier drafts. The remaining flaws I see:
- It doesn’t indicate that the viewer (not the broadcaster) will be asked for the password.
- It doesn’t indicate what would happen if the viewer enters the wrong password.
Of course, the user can assume what the answers to those will be, and they are likely to be right, but having to guess would slow them down.
Changing “Ask for” to “Require” solves the second issue: it suggests that if the user enters the wrong password, they simply won’t be allowed to join. The label still doesn’t specify retry behavior, but assuming you will have multiple settings, I don’t think it’s worth making the settings dialog more complicated by explaining that. Without further explanation on retry behavior, I would assume that the viewer could try to enter the password again at least a few times.
When thinking about how to resolve the first issue, I considered “Require viewers to enter a password to view the broadcast”, but the repetition of “view” seemed to make the sentence unnecessarily complicated. That’s why I decided on “Require a password to view the broadcast”.
I think it’s better to have a colon at the end of the label than no punctuation. The colon hints that the text field contains something mentioned in the sentence – in this case, it’s the password. Combined with the password styling of the field and the context that these are settings for a single broadcast, I think the meaning of the field will be clear enough.
Why show the password field all the time, even when the checkbox is unchecked? So the user can anticipate that the password would be just a simple text password. It would also help the user navigate the interface faster when they check the checkbox, as the user could start moving their mouse towards the text field right away.
Don't provide a checkbox.
If it's mandatory build a "set passcode" data entry box into the workflow.
Triggering the set passcode process may be an optional button.
No when they click on the checkbox a data entry box with the passcode will appear, which they can edit and change. I've added that as well into the post, you can take a look. Apr 21, 2021 at 4:32
I think I just need a good literal that says that you have to set a passcode that allows your participants to enter the broadcast. "Ask for a passcode when people enter the broadcast" doesn't seem to work Apr 21, 2021 at 4:41