@gonyeahialam: Thank you for these insights! Do you have any recommendations for how an editor can learn more about the criteria? Would it perhaps be a link at the bottom of the invitation list that says something like, "Learn more about how your invitation list was generated." Then, the link could bring them to a documentation page with information on the model and how the invitation list is generated.

I have updated the tooltip text to provide a summarized list of the criteria used to generate the scores, since we learned in usability tests that organizers want more information on how the scores were generated. I also removed the word "event," as this feature can be used for other use cases beyond events.

Whoever takes on this ticket should use the text in the AC and not in the design examples for implementation. Note that we may make further improvements to the explanatory text in the tooltip, but the text in the AC is sufficient for the MVP.

cc @gonyeahialam

Change #1052153 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Show invitation list results

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

In T364804#9919633, @ifried wrote:

I have updated the tooltip text to provide a summarized list of the criteria used to generate the scores, since we learned in usability tests that organizers want more information on how the scores were generated. I also removed the word "event," as this feature can be used for other use cases beyond events.

Whoever takes on this ticket should use the text in the AC and not in the design examples for implementation. Note that we may make further improvements to the explanatory text in the tooltip, but the text in the AC is sufficient for the MVP.

cc @gonyeahialam

We can go ahead with this for MVP but just a few suggestions for now or future improvements:

This new copy states the criteria but it doesn't explain the difference between Highly and recommended to invite. My suggested copy will be:
Highly recommended://These editors have higher values for the following criteria: the bytes they contributed to the articles, the number of edits they made to the articles, their overall edit count on the wikis, and how recently they have edited the wikis.//

Also if we have a specific period we are using to calculate the recent edits we should specify it, for example
....and how recently they have edited the wikis within the last 6 months.

Thanks for sharing this, @gonyeahialam! I agree that the tooltip text for Highly recommended and Recommended to invite are not very specific, but this was an intentional choice, since we may change how we calculate the score in the future. We wanted something that was more flexible in the interface text. Perhaps the solution is to provide more specific information in the documentation, which can be updated over time?

As for the specific suggested text you shared, a few things come to mind for me:

• If we say "higher values," do you think users will wonder, "Higher in relation to what?"
• I'm not sure if it is as accurate to say "These editors have higher values for the following criteria," since we weigh the criteria differently. You can see documentation on the score calculation and the fact that we weigh criteria differently here. We may also change how we weigh stuff in the future. So, in short, not all criteria are treated equally.
• As for the specific time period, we also may change how recently they have edited, so perhaps also best for general documentation?

Curious to hear your thoughts!

@ifried @gonyeahialam Just a heads up that this task is currently marked as ready/in progress, so it'd be nice if we could finalize the AC. Also a couple more questions:

• I would also like to ask what the page title would be. Should it be "<invitation list name> invitation list" as in the specs? I wonder if that might be a bit confusing, depending on the name of the list. Maybe we could add a colon after the list name?

Given that a user hovers over the tooltip

With OOUI, the explanatory text is only shown upon clicking the help icon, not on hover (AIUI).

The usernames should be sorted based on score. If there are 200 usernames in “Highly recommended,” then there should be no usernames in “Recommended to invite.”

In this scenario, should the empty sections be really empty, or should we remove them completely?

Responses below, @Daimona:

In T364804#9966056, @Daimona wrote:

@ifried @gonyeahialam Just a heads up that this task is currently marked as ready/in progress, so it'd be nice if we could finalize the AC.

Yup, I have made changes to the AC based on what you just shared. See below for details. Also, I see that @gonyeahialam has not responded to my last response to him yet on the copy text, but he said the current text is okay for MVP, and I think we should leave as is for the reasons I shared in my previous comment, so let's go ahead with it.

• I would also like to ask what the page title would be. Should it be "<invitation list name> invitation list" as in the specs? I wonder if that might be a bit confusing, depending on the name of the list. Maybe we could add a colon after the list name?

Yup. Thanks for catching this. Added title info to the AC, including the colon, as suggested.

Given that a user hovers over the tooltip

With OOUI, the explanatory text is only shown upon clicking the help icon, not on hover (AIUI).

Ah, okay, good to know! AC updated. Thanks.

The usernames should be sorted based on score. If there are 200 usernames in “Highly recommended,” then there should be no usernames in “Recommended to invite.”

In this scenario, should the empty sections be really empty, or should we remove them completely?

Remove the section completely. AC updated.

Thank you!

In T364804#9963673, @ifried wrote:

Thanks for sharing this, @gonyeahialam! I agree that the tooltip text for Highly recommended and Recommended to invite are not very specific, but this was an intentional choice, since we may change how we calculate the score in the future. We wanted something that was more flexible in the interface text. Perhaps the solution is to provide more specific information in the documentation, which can be updated over time?

As for the specific suggested text you shared, a few things come to mind for me:

• If we say "higher values," do you think users will wonder, "Higher in relation to what?"

By higher values, I meant in relation to the Recommended to invite.

But we can leave it as it is for the MVP

@gonyeahialam: Thanks for the response! To clarify, I know what you mean :) I just wondered if users would not understand what "higher" meant, but perhaps they would! Either way, thanks for clarifying that this works for MVP and we can look into tweaking the language when we get feedback after the release.

@Daimona: Let me know if this looks good to go, or if you have any other open questions or concerns. Thanks!

In T364804#9967500, @ifried wrote:

@Daimona: Let me know if this looks good to go, or if you have any other open questions or concerns. Thanks!

LGTM, I'll implement this as described in the AC and will ask any further questions as they arise.

Actually, yeah, I've got a question. What should happen when there are no users to invite?

Hey there, @Daimona & @gonyeahialam: I have updated the AC based on our discussions today; let me know what you think, and thank you both for all of the questions you raised & ideas you shared!

In T364804#9971301, @ifried wrote:

Hey there, @Daimona & @gonyeahialam: I have updated the AC based on our discussions today; let me know what you think, and thank you both for all of the questions you raised & ideas you shared!

Thank you, it looks good to me! Just two more things:

• Can we not hyperlink "invitation list criteria"? I think this will become redundant once we add a help link to this special page (which we also discussed yesterday). Speaking of which, should I create a task for that?
• For the "no editors generated" scenario, should the text be just plain text, or should it be inside a messagewidget, like the pending state? @gonyeahialam

Also one more: should any of the accordions be open by default?

In T364804#9974095, @Daimona wrote:

In T364804#9971301, @ifried wrote:

Hey there, @Daimona & @gonyeahialam: I have updated the AC based on our discussions today; let me know what you think, and thank you both for all of the questions you raised & ideas you shared!

Thank you, it looks good to me! Just two more things:

• Can we not hyperlink "invitation list criteria"? I think this will become redundant once we add a help link to this special page (which we also discussed yesterday). Speaking of which, should I create a task for that?

I wouldn't be redundant. It is good to have the help link on the special page but it is also best to surface the link where it is most likely to be needed. So when people see 'criteria' and they want to learn more they can immediately click on the link, it wouldn't be always obvious that they should click on the special page help link.

Also one more: should any of the accordions be open by default? - For the "no editors generated" scenario, should the text be just plain text, or should it be inside a messagewidget, like the pending state? @gonyeahialam
Let me get back to you on this.

Also one more: should any of the accordions be open by default?

If it is possible to choose different behaviours, can the Highly recommended be open and the other one be closed by default?

In T364804#9974351, @gonyeahialam wrote:

In T364804#9974095, @Daimona wrote:

• Can we not hyperlink "invitation list criteria"? I think this will become redundant once we add a help link to this special page (which we also discussed yesterday). Speaking of which, should I create a task for that?

I wouldn't be redundant. It is good to have the help link on the special page but it is also best to surface the link where it is most likely to be needed. So when people see 'criteria' and they want to learn more they can immediately click on the link, it wouldn't be always obvious that they should click on the special page help link.

I agree, but if we don't have such a page yet, that would become a blocker for this task.

Also one more: should any of the accordions be open by default?

If it is possible to choose different behaviours, can the Highly recommended be open and the other one be closed by default?

Yes, it is possible. I'll do this.

In T364804#9974535, @Daimona wrote:

In T364804#9974351, @gonyeahialam wrote:

In T364804#9974095, @Daimona wrote:

• Can we not hyperlink "invitation list criteria"? I think this will become redundant once we add a help link to this special page (which we also discussed yesterday). Speaking of which, should I create a task for that?

I wouldn't be redundant. It is good to have the help link on the special page but it is also best to surface the link where it is most likely to be needed. So when people see 'criteria' and they want to learn more they can immediately click on the link, it wouldn't be always obvious that they should click on the special page help link.

I agree, but if we don't have such a page yet, that would become a blocker for this task.

Yup. I agree that the 'Help' link is likely to be ignored or not noticed by users, whereas the informational text is likely to be read. So I would also vote to keep the hyperlink. My only concern is that we'll need to create the documentation, which doesn't exist yet, and I would like it to not be a blocker for the task. So how about I remove the link for this task and create a separate task to add in the link when the documentation has been created?

Meanwhile, I can begin working with @Udehb-WMF on Invitation List user documentation next week.

Also one more: should any of the accordions be open by default?

If it is possible to choose different behaviours, can the Highly recommended be open and the other one be closed by default?

Yes, it is possible. I'll do this.

@gonyeahialam, thanks for sharing this recommendation! Why do you think we should close recommended by default? Because we really want to encourage organizers to focus on the Highly Recommended? It sounds like it could be a good idea; I just wanted to hear some of your thinking on this, since it is also possible that organizers would just want to see the full list as the default, especially if the Highly Recommended list is quite short. Thanks in advance!

In T364804#9974535, @Daimona wrote:

In T364804#9974351, @gonyeahialam wrote:

In T364804#9974095, @Daimona wrote:

Also one more: should any of the accordions be open by default?

If it is possible to choose different behaviours, can the Highly recommended be open and the other one be closed by default?

Yes, it is possible. I'll do this.

But, if the "hightly recommended" section is empty and the "recommended" section is non-empty, then should the "recommended" accordion be open by default?

In T364804#9974565, @ifried wrote:

My only concern is that we'll need to create the documentation, which doesn't exist yet, and I would like it to not be a blocker for the task. So how about I remove the link for this task and create a separate task to add in the link when the documentation has been created?

I think it would be fine if you could create a placeholder for the documentation page (under https://www.mediawiki.org/wiki/Help:Extension:CampaignEvents), so I could link it (and it's fine if it's still empty).

Also summarizing the other open questions:

• Whether the introductory text should be in a messagewidget when no users generated.
• Whether "recommended to invite" should be open by default when there are no highly recommended users.

Also: we need an actual tooltip/alt label for both "info" buttons, so that the purpose of the button is understood by screen readers etc. Something like "Help" or "More information" would do.

Actually one more challenge. The CSS-only version of the accordion component does not seem to support actions. I tried a DIY implementation but clicking the button results in the accordion expanding as well. Also, even in OOUI, the popup button is a JS widget and we're currently refraining from adding JS widgets to this page due to T351818. Could we use the accordion description instead?

@Daimona We should use the message component, I was just thinking what message type will be appropriate here - notice, warning or error. I decided to go with 'warning' based on the reasons I describe below, let me know your thoughts.

While an "error" message might seem fitting at first, it could be perceived negatively by the user, implying that the user has done something wrong or a system error has occurred. In this case, the "no results" state is a natural outcome of the search criteria and not an error in the system or by the user.

A "notice" message doesn't seem appropriate for the "no results" state, because it is used alert a reader to important and neutral, but non-urgent, information. It wouldn't sufficiently emphasize the user's inability to proceed with the intended task of sending invitations, leading the user to potentially overlook the fact that they need to adjust their inputs - article list. And also because it is has same design and appearance as the pending state message users may not easily notice a change in the state.

A "warning" message conveys a sense of urgency and encourages the user to take action, which is crucial when the user can't progress as intended - send invites. A "notice" message, on the other hand, can be perceived as simply informative, leading the user to potentially overlook the fact that they need to adjust their criteria or try a different approach.

Therefore, a "warning" message offers the most appropriate balance of informing the user about the "no results" scenario while also prompting them to take action to resolve the issue.	I wonder if an MVP solution would be to give them a link that takes them back to GenerateInvitation List but in edit mode with there previous inputs. But if not feasible or out of scope we will need to add the article list to this 'no results' state so organizers can reference it when creating a new list.	We will also need to update the labels in the MyInvitationLists page T356683 by using the 'notice' type for processing/pending state and 'warning' type for no results cc @MHorsey-WMF

In T364804#9975308, @Daimona wrote:

Actually one more challenge. The CSS-only version of the accordion component does not seem to support actions. I tried a DIY implementation but clicking the button results in the accordion expanding as well. Also, even in OOUI, the popup button is a JS widget and we're currently refraining from adding JS widgets to this page due to T351818. Could we use the accordion description instead?

I don't understand the task you mentioned here "we're currently refraining from adding JS widgets to this page due to T351818". Can't we see how we can implement this as you described for OOUI?

If it is added in the description there is going to be a lot of text visible always on the page as I have shown below including the recently updated text for the top of this page.

@gonyeahialam, thanks for sharing this recommendation! Why do you think we should close recommended by default? Because we really want to encourage organizers to focus on the Highly Recommended? It sounds like it could be a good idea; I just wanted to hear some of your thinking on this, since it is also possible that organizers would just want to see the full list as the default, especially if the Highly Recommended list is quite short. Thanks in advance!

@ifried The accordion is to ease the navigating between the Highly recommended and Recommended categories when the lists are long and reduce the amount of info that is display on the page at once. The best approach for this will be to close both by default so the organizer can have an overview and know that there are two sections, and choose to open them as they please. But it may not be best to have it close by default for first time users who may not know what to expect.
So a compromise may be to show the Highly recommended and close the Recommended but this will mean that first time users wouldn't know that there is another section except they scroll down depending on the length. 2nd time users can easily close the Highly and open the Recommended as they please.

In T364804#9977060, @gonyeahialam wrote:

@Daimona We should use the message component, I was just thinking what message type will be appropriate here - notice, warning or error. I decided to go with 'warning' based on the reasons I describe below, let me know your thoughts.

I originally thought we could use the notice type, but after reading your comment, I think warning is a better choice.

I wonder if an MVP solution would be to give them a link that takes them back to GenerateInvitation List but in edit mode with there previous inputs. But if not feasible or out of scope we will need to add the article list to this 'no results' state so organizers can reference it when creating a new list.

It might be doable but not super simple. I would go with a generic link to Special:GenerateInvitation as in the AC for now.

In T364804#9977142, @gonyeahialam wrote:

In T364804#9975308, @Daimona wrote:

Actually one more challenge. The CSS-only version of the accordion component does not seem to support actions. I tried a DIY implementation but clicking the button results in the accordion expanding as well. Also, even in OOUI, the popup button is a JS widget and we're currently refraining from adding JS widgets to this page due to T351818. Could we use the accordion description instead?

I don't understand the task you mentioned here "we're currently refraining from adding JS widgets to this page due to T351818". Can't we see how we can implement this as you described for OOUI?

Due to technical reason, we would need to work on T351818 (which has already been pushed back enough) before we add JavaScript code to new pages. PopupButtonWidget (used in the prototype) is a JavaScript widget, so it would be nice if we could do without it for the time being (the plan is to work on T351818 once the invitation list MVP is done).

If it is added in the description there is going to be a lot of text visible always on the page as I have shown below including the recently updated text for the top of this page.

This is true. I'm not sure how to proceed, though.

If it is added in the description there is going to be a lot of text visible always on the page as I have shown below including the recently updated text for the top of this page.

This is true. I'm not sure how to proceed, though.

@Daimona

Perhaps we need to review the 3 copies again and see where we can shorten or combine cc @ifried

@Daimona & @gonyeahialam:

• I have created the documentation page draft: https://www.mediawiki.org/wiki/Help:Extension:CampaignEvents/Invitation_lists
• Let's not rewrite the copy; we need to move forward, and I think the current copy works for the MVP.
• If there are no 'Highly recommended' editors in the invitation list: Yes, I think 'Recommended to invite' should be opened by default, but I am concerned that the user experience may be a bit confusing if one section is opened and one is closed. I think it makes more sense to be consistent with them both opened or both closed (since it may seem like part of the list is hidden otherwise).
• I think 'More information' works for the tooltip labels

In T364804#9978069, @ifried wrote:

• Let's not rewrite the copy; we need to move forward, and I think the current copy works for the MVP.

I agree that it's probably better not to rewrite the copy, I don't know how to move forward. The proposed approach with the info popup doesn't seem to be possible without JavaScript. And on top of that, it seems like actions are not supported in CSS-only accordions, which means the solution would still involve a decent amount of DIY. I'll look into this again and see what can be done.

In T364804#9978432, @Daimona wrote:

In T364804#9978069, @ifried wrote:

• Let's not rewrite the copy; we need to move forward, and I think the current copy works for the MVP.

I agree that it's probably better not to rewrite the copy, I don't know how to move forward. The proposed approach with the info popup doesn't seem to be possible without JavaScript. And on top of that, it seems like actions are not supported in CSS-only accordions, which means the solution would still involve a decent amount of DIY. I'll look into this again and see what can be done.

If you find no work-around, I think we can leave it in the description for the MVP @Daimona

I added that the message type for no contributors should be warning to the task description.

Thank you for updating the AC, @Daimona! Confirming that it looks good to me.

I've looked into the popup thing again. First of all, Codex does not seem to have that popup component: T363375. Also, as I mentioned above, the OOUI version only exists in JavaScript and I'd rather not use it for now. So, for this first version I have the following 2 proposals:

Option 1: Use a normal OOUI button + the browser's builtin tooltip

This works without JavaScript, but the tooltip appears on hover and to repeat, it's the built-in browser tooltip. This tooltip would not be accessible on mobile. Clicking on the icon would toggle the accordion (and close the tooltip if it was open).

Option 2: Use accordion description

As discussed above.

Once T351818 is resolved, we should be able to improve option 1 and make it more similar to the prototype. @gonyeahialam @ifried Which one do you prefer?

Thanks for investigating this & breaking down the options, @Daimona! I prefer accordion description because a) I think the tooltip should work on mobile, b) I think users are more likely to see it/read it, and c) I think it actually looks better. @gonyeahialam, what do you think?

I explored the accordion description above T364804#9977142, the only challenge I had with it is that it makes page text heavy combined with the other texts on the page. The tooltip was preferable because this information is not very important for it to be constantly visible especially for returning users. But in light of the current constraints the accordion description is the better solution so we can go with it.

@Daimona @ifried another thing I mentioned above is that we will also need to add the 'view article list' when no editors are generated so that organizers can reference it when creating a new list.

In T364804#9986643, @gonyeahialam wrote:

@Daimona @ifried another thing I mentioned above is that we will also need to add the 'view article list' when no editors are generated so that organizers can reference it when creating a new list.

I think it was already implicit in the previous AC, but I've made it more clear.

Change #1052153 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Display invitation list on Special:InvitationList

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

As an organizer, I want to see an Invitation List of who is recommended to be invited to my event, so that I can review the list and choose people to invite and, therefore, have more people attend my event who are passionate about the topics it covers.

Acceptance Criteria:

• Given that the an invitation list is ready for the organizer,
  • ✅ They should see it on Special:InvitationList/<invitationlistid>
  • ✅ The title of the page should be: [Invitation list name]: Invitation list
  • Below the title, the user should see the following text:
    • ❌ [number] editors generated, based on the following criteria: the bytes they contributed to the articles, the number of edits they made to the articles, their overall edit count on the wikis, and how recently they have edited the wikis.
      • Currently says editors found instead of editors generated. Need to change AC?
      • 
  • ✅ They should see a maximum of 200 editors who are categorized into “Highly recommended to invite” and “Recommended to invite.”
    • ✅ Highly recommended to invite can be those who scored between 70 and 100.
    • ✅ Recommended to invite can be between 25 and 69.
      • Note: These ranges can also be changed over time, but we can start with these. We will not display the scores associated with the users.
  • ✅ The usernames should be sorted based on score. If there are 200 usernames in “Highly recommended,” then there should be no section for “Recommended to invite.”
  • 
  • ✅ The "highly recommended" accordion should be open by default, the "recommended" one closed. However, if there's no "highly recommended" section, then the "recommended" accordion should be open by default instead.
  • 
  • The "highly recommended" accordion should have the following description:
    • ✅ These editors received a high invitation list ranking, so they are more likely to be interested in joining your activity.
  • The "recommended" accordion should have the following description:
    • ✅ These editors received a mid-range invitation list ranking, but they still may be interested in joining your activity.
    • 
  • ✅ Below, there should be another accordion labeled "View article list", which contains the full worklist. This accordion should be closed by default, and is always shown regardless of the number of editors.
  • 
  • ✅ Only the organizer who requested the Invitation List can view it.
  • 
• Given that the an invitation list request generates no contributors,
  • They should see the following warning message on Special:InvitationList/<invitationlistid>,
    • ✅ No editors meet the invitation list criteria from your article list. You can create a new invitation list with a new article list.
      • ✅ "invitation list criteria" should link to documentation on score calculation: https://www.mediawiki.org/wiki/Help:Extension:CampaignEvents/Invitation_lists
      • It is correctly linked, but the page is just a draft right now.
        
      • "Create a new invitation list" should link to Special:GenerateInvitationList
      • 
• ❌ Tooltip label can be 'More information'
  • No tooltip shown
  • 
• ✅ No search functionality for MVP

@Daimona The large bulk of this is working as expected. Two things are noted above, and I'm not sure if either of them actually need to be fixed, might just be the AC needs adjusted. Sorry for the delay in testing this - took a bit for me to figure out how the tables were storing this so I could just edit it with SQL queries instead of selenium tests.

In T364804#10025531, @vaughnwalters wrote:

• Below the title, the user should see the following text:
  • ❌ [number] editors generated, based on the following criteria: the bytes they contributed to the articles, the number of edits they made to the articles, their overall edit count on the wikis, and how recently they have edited the wikis.
    • Currently says editors found instead of editors generated. Need to change AC?

This was changed in T370443, which came after this task here.

• ❌ Tooltip label can be 'More information'
  • No tooltip shown

That's a leftover from old AC, I'll remove it now.

In T364804#10025614, @Daimona wrote:

In T364804#10025531, @vaughnwalters wrote:

• Below the title, the user should see the following text:
  • ❌ [number] editors generated, based on the following criteria: the bytes they contributed to the articles, the number of edits they made to the articles, their overall edit count on the wikis, and how recently they have edited the wikis.
    • Currently says editors found instead of editors generated. Need to change AC?

This was changed in T370443, which came after this task here.

• ❌ Tooltip label can be 'More information'
  • No tooltip shown

That's a leftover from old AC, I'll remove it now.

Okay great, sending this to design sign off then.