Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INVITES: When users click X on 'join topic/join group', they get a blank screen #1701

Open
BeccaMelhuish opened this issue Nov 28, 2024 · 11 comments
Labels
UX Priority UX issues that are important to fix relatively soon UX UX related issue. Needs input from UX specialists.

Comments

@BeccaMelhuish
Copy link
Contributor

What is the problem?

When you follow a URL share link to a public topic or public group, the join pop-up is over a blank page.

image

When you then click the 'X', if you don't want to join it, you are then left on a blank page:

image

Why is this a problem?

Not very helpful for users. Plus doesn't give them any idea of what they're signing up to.

Possible solution.

Related to this and this issue (which discuss the fact that new users need to see as much about what they're joining as possible to decide if they want to join), I'm thinking that for public topics and groups, the pop-up can be overlaid with the group or topic greyed out a little in the background. (As it's public anyway). Then if they click X, they are taken to that group/topic anyway, just without having joined it.

For private topics, perhaps it can be overlaid over the dashboard, so then if the click X they land on the dashboard?

I'm also thinking that it would be best if this pop-up was moveable in all cases (by clicking and dragging), so the user can move it out of the way to have a look at what's in the background, to help inform them that (hopefully) yes, they do want to join!

image

@kevincrepin @TiinaDUX @Lidziya-p what do you think? :)

@BeccaMelhuish BeccaMelhuish added UX UX related issue. Needs input from UX specialists. UX Priority UX issues that are important to fix relatively soon labels Nov 28, 2024
@kevincrepin
Copy link
Collaborator

Logical to me to have this overlaying the dashboard and when closing the dialog window it keeps you there.

But it's not very common behaviour to be able to move this dialog window around. And wouldn't they have already seen the content of the group before pressing that "join group" action?

@BeccaMelhuish
Copy link
Contributor Author

BeccaMelhuish commented Nov 29, 2024

@kevincrepin Ah re the last question - no, this is for invites via URL, so they've seen absolutely nothing yet at this point, this is the first thing they see (once we've swapped it with login).

For private topics, public topics, private groups and public groups - so we need to decide what they see behind the pop-up in each case, and where they are taken after clicking X :)

@kevincrepin
Copy link
Collaborator

What page this dialog opens up over:

  • Not logged in: the landing page when not logged in
  • Logged in: dashboard

I don't see a need to differentiate based on what they are invited to. It's gonna make things more complex and not sure if the value is really there? Let's say we do it in such a way that if you get an invite to a private topic, the screen behind the dialog is the private topics page. If you close now it's not like that private topic you were invited to (but didn't join because you pressed X) will be visible here. So I'm not sure if the added complexity of taking this approach actually pays off?

If you press X we can assume you don't want to deal with it and then the dashboard is a better "general starting point".

@BeccaMelhuish
Copy link
Contributor Author

BeccaMelhuish commented Nov 29, 2024

@kevincrepin I definitely see your point for private topics and groups, and think it makes sense it should be overlaid over the DB(logged in)/home(logged out), but for public ones it makes a lot of sense to me that it should be overlaid over the public topic/group.

My reasons for this are:

  • They may not feel ready to commit to 'join' something they don't yet see, and want to have a look around it before joining it. Often they will be just following the link to have a look - they are curious, want to see what it's all about, and will have not yet decided that they do actually want to participate.
  • For groups, they may not be confortable joining the group when they see it will make their email address visible to the admin(s). In a public group the admins may well be total strangers. Or they may fear lots of notifications if they 'join' something. But they may still want to access the group, check it out and even participate in the topics. So this gives them the option to do so while landing in the right place. Then later they can join the group when they feel more confident/keen to.
  • Users in tests have shared/shown the feeling that 'join' is a big commitment early on and could be a barrier to entry. Which to my mind makes a lot of sense. Users aren't necessary very engaged initially, but it's in the process of participating that they then become engaged.

Actually, I'm reminded now that we did decide here that we would remove the 'join' pop-up entirely for public topics, and just have it for public groups. So this solution would be a kind of compromise between the two, just for groups?

In which case, the solution would be:

  • For private topics/groups not logged in: pop up over logged out landing page
  • For private topics/groups logged in: pop up over DB
  • For public topics: no pop-up, get prompted to log in when they engage and automatically added to the topic when they have engaged (or clicked join)
  • For public group: pop up over public group

@kevincrepin wdyt? :)

@kevincrepin
Copy link
Collaborator

I feel that if the main problem to solve here is the "I don't wanna join yet, but I want to see what this is about" then I'd rather have a secondary button "view without joining" instead of making the "close window" the main flow to solve that problem.

Screenshot 2024-11-29 at 15 21 53

And then I would say it could still follow the logic of always opening in the dashboard :D Then we don't need to make an exception on this.

@BeccaMelhuish
Copy link
Contributor Author

@kevincrepin Oh nice, how much simpler that is! :D

Wdyt re public topics - do we do the same thing, or stick with previous decision to not have a pop-up at all?

And I guess here we need to change it to:

'To join this group' (or topic) etc

image

@kevincrepin
Copy link
Collaborator

I would here again say that unless it's a massive barrier it would be nice to have the same behaviour, so we have less exceptions and the user gets used to the behaviour pattern.

Yep, I'll update the text :)

@BeccaMelhuish
Copy link
Contributor Author

BeccaMelhuish commented Nov 29, 2024

That makes sense, let's trial it like this for now then! :)

So @ilmartyrk, to summarise dev tasks for this one:

When a user follows a URL share line and gets a join pop-up:

  • When logged out, it should be overlaid over the landing page
  • When logged in, it should be overlaid over the DB
  • For public groups, there should be a 'View group without joining' button that takes them to the group
  • For private topics, there should be a 'View topic without joining' button that takes them to the topic

@BeccaMelhuish
Copy link
Contributor Author

BeccaMelhuish commented Nov 29, 2024

Noting this group issue re issues that need to be fixed first though: #1706

@ilmar
Copy link

ilmar commented Nov 29, 2024

Hi!
Could you please stop tagging me in this project? I’ve been receiving notifications for several years now. I have no connection to citizenOS; you need @ilmartyrk
Thanks! :)

@BeccaMelhuish
Copy link
Contributor Author

Apologies @ilmar!! Thanks so much for bringing this to our attention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
UX Priority UX issues that are important to fix relatively soon UX UX related issue. Needs input from UX specialists.
Projects
Status: Now - Ready for dev
Development

No branches or pull requests

5 participants