UX: Flow entering guest name

[samuelwei]

Currently guest users are asked their name when they click on "Start"/"Join" inside a modal

sometimes also with additional consent to attendance logging, recording, streaming, etc.

Until clicking on start/join some users might not realise, that they are not logged in to their user account.
Some users are also confused why their name and the consent is asked in the same step.

[samuelwei]

UX Solution 1
Status: Failed in UX Test

Visually seperate the guest name textbox in a gray box from the cosent checkboxes. Adding a second button as a hint for users with a user account that they can login (redirects to login page).

Result in UX Tests at Uni Osnabrück: Users are even more confused and don't understand what to do and where to click. Logged users are redirected back to the room if they click on the button, however they have to click on "start"/"join" again to return to this modal.

[tibroc]

Re Solution 1:

Users expect that they are logged-in once they enter their name and click on "login"

[samuelwei]

UX Solution 2
Status: Proposal

Move the guest name textbox to an earlier stage. Add to existing overlay when entering a room with an access code, and add a new overlay when no access code is needed. In these existing/new overlays, users can also choose to login with their account instead. This will eliminate the need to ask for the name in the dialog shown on "start"/"join". In case no additional consent is requires the dialog will not be shown at all.

The need to enter the guest name in case of visting a room that has no access code can also be reduced by saving the guest's name from the last usage in a cookie/local storage (maybe asking to remember the name for next time). A new bar would also indicate inside a room that the user is viewing the room as a guest, showing the guest name and a button to change the entered name.

1. Step; Showing new overlay for non-loggedin user, for a room without an access code

1. Step; Showing existing overlay for non-loggedin user, for a room with an access code

1. Step; Showing existing overlay for loggedin user, for a room with an access code

2. Step; Showing room with new bar for non-loggedin user

2. Step; Showing room for loggedin user

[agoroncy]

UX Solution 2 is really nice. And I think it's easy to distinguish the both options. What happens, wenn I start to login on this page? Do I come back to the 3rd screenshot to enter the Access Code and join the meeting?

[samuelwei]

UX Solution 2 is really nice. And I think it's easy to distinguish the both options. What happens, wenn I start to login on this page? Do I come back to the 3rd screenshot to enter the Access Code and join the meeting?

Thanks for the feedback. Yes, users that visit a room protected with an access code would return to the 3. screenshot after login to enter the access code. In case the now logged in user is the owner of the room or the room is shared with that user the user would go to the last screenshot.

[lkiesow]

@tibroc, can you clarify if we have the current version of PILOS or if you applied a patch related to this?

Regarding solution 1, I can now state with confidence that the UX is really bad. I've seen several people run into the same problem one after another. Me included 😅: As a guest, I click “Join”, I enter my name and then click the huge button called “login” to join the meeting. You don't realize that the upper and lower parts of the dialog (user name input and continue button) belong together, but are separated by something completely unrelated: the login. Also, the “Continue” and “Cancel” are very generic and much smaller, so you don't really notice them.

pilos-guest-join-usability-issue.mp4

The result was several people complaining that they couldn't join because they seemingly needed a login with my then trying and running into the same issue, only to go back and carefully thinking about the function of the different buttons. After all, I knew that I should have been able to join as a guest.

So, let's not use UX Solution 1, please?

[samuelwei]

@lkiesow Yeah, let’s not use Solution 1. what are your thoughts of solution 2?

[lkiesow]

The second option looks way better. Especially since there are fewer elements for guest overall. That hopefully makes it simpler for users to join.

That being said, it would be good to be able to just test it.