Page MenuHomePhabricator

Implement ability to view event page and eventdetails via 'my events' list
Closed, ResolvedPublic2 Estimated Story Points

Description

As an organizer, I want to be able to view my registration via the kebab menu, so that I can have an easy entry-point to see the event page.

Resources:

Acceptance Criteria:

  • If the user clicks to "View event page" via kebab menu, they should be brought to the event page.
  • If the user clicks on the event title that is displayed in the table for 'Your Events,' they should be brought to the EventDetails page for the event.
    • This means that the title should be treated like a normal link within the wikis
  • If the user has JS disabled and clicks on the 3 dots, they should be brought to the Special:EditEventRegistration page

Visual examples:

Screen Shot 2022-06-09 at 11.36.27 AM.png (1×2 px, 231 KB)

Event Timeline

@gonyeahialam - Hello there! Is 'view event page' supposed to take you to the event details page or the event page? And, if takes you to the event page, how do people access the event details page from this view?

In the prototypes "view event page" would take you to the Event page. You access the event details by clicking on the whole event "tile" itself; which should be clickable.

Capture d’écran 2022-06-10 à 17.27.31.png (1×2 px, 361 KB)

@CKMIE89 Thank you for clarifying! We then have 2 follow-up questions:

  1. Should the event title then be colored blue to indicate that it is a link (which is the standard behavior for wiki links)?
  2. Is it confusing if some actions are accessed in the kebab menu (such as edit, delete), but others are accessed via title link (such as going to the event details page)? I guess this would have been confirmed via user testing, but the team was curious about this.
  1. If the whole tile cannot be clickable than that is a viable option (having the title in blue) though it does change the design quite a lot.

I would prefer if the whole tile could have a different shade of the mouse hovers over it; is that possible?

  1. The point of this page is that you can access your events and see their details, so it makes sense that the man function of each tile would be to access the details. It's quite standard that there is one main option to open a tile and sub-actions in the menu. (think of your inbox for example) :)

@CKMIE89 Thank you for clarifying! We then have 2 follow-up questions:

  1. Should the event title then be colored blue to indicate that it is a link (which is the standard behavior for wiki links)?
  2. Is it confusing if some actions are accessed in the kebab menu (such as edit, delete), but others are accessed via title link (such as going to the event details page)? I guess this would have been confirmed via user testing, but the team was curious about this.
  1. In the demo, the engineers have already made it so that when you hover across the box it changes color to blue which is what I demoed much earlier. A similar example is https://en.wikipedia.org/wiki/Special:ContentTranslation#suggestions.
  2. I don't completely understand this. What actions would you like to remove from the kebab menu and why?

Thanks for clarifying on answer #1. I don't think the engineers knew that the link would turn blue when you hover over. Pinging @cmelo and @Daimona for their thoughts.

On point #2: It was brought up in sprint planning yesterday that some people may assume that all actions that a user can perform would be in the kebab menu (including accessing the event details page). So there was a question about the choice to have one action (i.e., go to event details) be accessed via the title while other actions (such as delete an event page) are accessed via the kebab menu. In other words, could this be confusing to users? Any thoughts on this, @gonyeahialam? Thanks in advance!

I think there's some confusion here, let me try to clarify:

  • First, I see two proposals: one is making the whole event row clickable, the other is making only the name clickable. Below I'll explain what I think about them, but I'm not sure if this distinction is obvious in the messages above.
  1. If the whole tile cannot be clickable than that is a viable option (having the title in blue) though it does change the design quite a lot.

Having the whole tile (a.k.a. row) clickable is probably possible, but it's not as trivial as it may sound and there are some drawbacks. The main issue is that each event is a table row, and making table rows clickable is by itself not an easy task. The best way to achieve that would be to simulate links via JavaScript. This wouldn't work for no-JS user but it's not a concern because they can still use the three dots button to view the event details. An actual concern of using JavaScript is that since it's not a real link, you cannot ctrl-click or right-click it, e.g., if you want to open it in a new tab. This can perhaps be worked around, but again, it wouldn't be easy. Also, there may be other issues due to not using an actual link; for instance, you don't get the link preview at the bottom left, and I'm unsure how it'd work in screen readers. So, it is somewhat doable, but we should keep these drawbacks in mind.

I would prefer if the whole tile could have a different shade of the mouse hovers over it; is that possible?

That is already the case, see patchdemo. It's not something we did. Every table pager in MediaWiki has the "blue-on-hover" feature on each row (see also Special:AllMessages). This is unrelated to links.

  1. In the demo, the engineers have already made it so that when you hover across the box it changes color to blue which is what I demoed much earlier.

Yep, but we didn't do it, see above.

A similar example is https://en.wikipedia.org/wiki/Special:ContentTranslation#suggestions.

I'd suggest not using that page for examples. First, it looks quite inconsistent with basically every other wikipage, which I'm not sure if it's a good thing. Second, the interface is custom-made for that specific page (using JavaScript). It does not use the pagination logic provided by MediaWiki core. It also does not use a table, so some things may be different. And actually, this one seems to use the JavaScript solution that I was mentioning above for emulating links; you can easily verify the drawbacks I was talking about if you try to right-click, ctrl-click, or middle-click those tiles.

Thanks for clarifying on answer #1. I don't think the engineers knew that the link would turn blue when you hover over. Pinging @cmelo and @Daimona for their thoughts.

On point #2: It was brought up in sprint planning yesterday that some people may assume that all actions that a user can perform would be in the kebab menu (including accessing the event details page). So there was a question about the choice to have one action (i.e., go to event details) be accessed via the title while other actions (such as delete an event page) are accessed via the kebab menu. In other words, could this be confusing to users? Any thoughts on this, @gonyeahialam? Thanks in advance!

@ifried What you described is similar to how it currently works. To access the event details you click on the table (or through the link depending on the discussions with the engineers), to access other actions (edit, close, delete and view event page) you click the kebab menu. We tested this and no confusion came up.

@Daimona @ifried The row in the table is a single unit so having the whole row clickable is the most intuitive option.
We can go with making the Event title a link and clickable since there are technical difficulties. But we would need to remove the blue hover state from the row and test this new interaction with users.

Also, if we make it a link on desktop what happens on mobile? People expect the whole area to be clickable and not just the title for such components on mobile.

Screenshot 2022-06-13 at 16.13.37.png (1×728 px, 132 KB)

Hey everyone. There are a few questions and comments going on here. I'll try to summarize them below:

As far as I understand, we have the following 3 options for allowing the organizer to access the event details page:

  • Option 1: The whole row is clickable and brings user to EventDetails
    • This is first choice recommended by design, and it was the behavior for the user testing
    • This is the most complex option according to the engineers, and it does not receive a strong recommendation from engineering because there are less choices for users (such as right-clicking, page preview, etc)
  • Option 2: The title of the event is clickable and brings user to EventDetails
    • This is the second choice from design, though there are some open questions about how this user experience would be handled on mobile
    • This seems to be recommended as a better option by engineers, since the user can right-click, see the link preview, and perform more actions
  • Option 3: There is an option in the kebab menu that brings user to EventDetails
    • This would require a new option in the kebab menu ('View Event Details'), which may or may not be preferable and it has not received any user testing

How do we feel about choosing Option 2 for V0, and then we can determine through V0 testing if we pivot to another option (or a mixed option such as using Option 2 and Option 3) for V1? What do people think, especially @gonyeahialam and @Daimona?

@Daimona @ifried The row in the table is a single unit so having the whole row clickable is the most intuitive option.

As I said, this is entirely possible, as long as we're comfortable with the drawbacks that come with it (I personally find it annoying when I can't right- or middle-click a link, but this may not be the same for everyone).

But we would need to remove the blue hover state from the row.

Why? I think the main reason why it's there is that you can easily see the whole row you're hovering on, since it's highlighted. It has nothing to do with links.

Also, if we make it a link on desktop what happens on mobile? People expect the whole area to be clickable and not just the title for such components on mobile.

I'm not sure about the mobile version, and I don't know if we can change the HTML of the page only for mobile. If we use the same table, there's going to be the same issue; otherwise, it could be simpler.

  • Option 1: The whole row is clickable and brings user to EventDetails [...]
    • This is the most complex option according to the engineers

It's not exactly complex; in fact, it may be quite easy to implement. I'm mostly concerned about its usability issues. Some of them can be mitigated with more JavaScript, which again shouldn't be hard, but is less maintainable.

How do we feel about choosing Option 2 for V0, and then we can determine through V0 testing if we pivot to another option (or a mixed option such as using Option 2 and Option 3) for V1? What do people think, especially @gonyeahialam and @Daimona?

SGTM.

@Daimona @ifried The row in the table is a single unit so having the whole row clickable is the most intuitive option.

As I said, this is entirely possible, as long as we're comfortable with the drawbacks that come with it (I personally find it annoying when I can't right- or middle-click a link, but this may not be the same for everyone).

I know I don't use these options much, so imo they are not essential... How would you use them in this contexte?

But we would need to remove the blue hover state from the row.

Why? I think the main reason why it's there is that you can easily see the whole row you're hovering on, since it's highlighted. It has nothing to do with links.

There is one problem is that if your entire row changes appearance, in people will believe the whole row is clickable. It's not just about seeing what tile you are on, but people's expectations of interactions. If they then click anywhere on the row and nothing happens, they might assume they cannot interact with the it. We would need to make it very clear that the title is clickable. Maybe having the blue hover state AND the Tittle blue and underlined ? @gonyeahialam I would favor a light shadowing of the row, and the title clearly ckickable if we are going with the title rather than row option.

Final thoughts: @ifried I am ok with option 2, with maybe a light drop shadow of the row (not a blue hover state that would be confusing for users)

@Daimona @ifried The row in the table is a single unit so having the whole row clickable is the most intuitive option.

As I said, this is entirely possible, as long as we're comfortable with the drawbacks that come with it (I personally find it annoying when I can't right- or middle-click a link, but this may not be the same for everyone).

I know I don't use these options much, so imo they are not essential... How would you use them in this contexte?

For instance, if I want to open the page in a new tab/window, or preview the URL that is going to open, or copy the link. These are the main things that come to mind, but there are certainly more; for instance, navigation with the keyboard could also be worse. I guess that if someone navigates with left-clicks only it doesn't feel like an essential feature, but for everyone else it feels pretty limiting and sometimes frustrating.

But we would need to remove the blue hover state from the row.

Why? I think the main reason why it's there is that you can easily see the whole row you're hovering on, since it's highlighted. It has nothing to do with links.

There is one problem is that if your entire row changes appearance, in people will believe the whole row is clickable. It's not just about seeing what tile you are on, but people's expectations of interactions.

But when you hover on the row the cursor remains the same (most likely an arrow), it doesn't change to a pointer (e.g., hand with finger pointing up), which is the standard visual cue for something clickable. If I see a table whose rows get a light background on hover but the cursor remains the same I wouldn't assume that the element is clickable, but only that the entire row is being highlighted for me to more easily see which line I'm currently on (e.g., if I want to read all columns sequentially in that row).

For V0, we decided that the title of the campaign event will be a link to the EventDetails page.

ifried renamed this task from View event action via kebab menu to Implement ability to view event page and eventdetails via 'my events' list.Jun 15 2022, 5:16 PM
ifried set the point value for this task to 2.
ifried updated the task description. (Show Details)

I've updated the AC for the no-JS case. Right now the 3 dots would bring the user to the EventDetails page, but if the event title becomes clickable that would be redundant, so we can change the link to point to the EditEvent page instead.

Change 811249 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Add "view event page" link to kebab menu

https://gerrit.wikimedia.org/r/811249

@Daimona I think it makes sense to bring the user to the EventDetails page when they click 'Manage Event,' but from there, they can go to the list of all their event registrations.

Change 811249 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add "view event page" link to kebab menu

https://gerrit.wikimedia.org/r/811249

@Daimona I think it makes sense to bring the user to the EventDetails page when they click 'Manage Event,' but from there, they can go to the list of all their event registrations.

For noJS, they can already access the event details by clicking the event name. So I think it's more useful if the "manage event" button has a different destination.

@Daimona and I discussed this, and we were referring to two different 'manage event' experiences. I was referring to the manage event button on the event page. I have created a separate ticket for this (T312126). And, as for the no-JS experience that was being referred to by Daimona, I agree that 'edit' is more useful than EventDetails since the user will be able to access EventDetails via the event title. As for closing the event, no-JS users can do it on the edit view. To delete the page, no-JS users can go directly to the special page for deletion.

@Daimona clicking on the event title in the table links to Special:EventRegistration/{id}. In the AC (and the comments on this ticket), clicking the event title in the table should link to EventDetails. Is EventRegistration the same as EventDetails?

@Daimona clicking on the event title in the table links to Special:EventRegistration/{id}. In the AC (and the comments on this ticket), clicking the event title in the table should link to EventDetails. Is EventRegistration the same as EventDetails?

Yes, sorry for not mentioning that. We're in the process of renaming the page, see T310201 and apologies for the confusion.

@Daimona clicking on the event title in the table links to Special:EventRegistration/{id}. In the AC (and the comments on this ticket), clicking the event title in the table should link to EventDetails. Is EventRegistration the same as EventDetails?

Yes, sorry for not mentioning that. We're in the process of renaming the page, see T310201 and apologies for the confusion.

👍

I have tested this, and it works as expected. I see the link to view the event page, which properly redirects me to the event page upon click. Meanwhile, clicking on the event title brings the user to the EventDetails page. For this reason, I'm marking this as Done.