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

[mediawiki/extensions/CampaignEvents@master] Create SpecialGenerateInvitationList

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

Hi @ifried and @gonyeahialam, there are 2 things that come up on code reviews, that I need your feedback on:

• The default behavior of OOUI is to add * for required fields, and not for optional fields, so it was suggested to remove the word "(optional)" from the sentence below:
  • Event page (optional) this is how it is on the prototype, I agree that for OOUI we should remove the "(optional)" part since this is the default
• The placeholders are in the design specs only, and not in the AC. Can we confirm whether they should be included, and if their texts have been reviewed?

In T356679#9836963, @cmelo wrote:

Hi @ifried and @gonyeahialam, there are 2 things that come up on code reviews, that I need your feedback on:

• The default behavior of OOUI is to add * for required fields, and not for optional fields, so it was suggested to remove the word "(optional)" from the sentence below:
  • Event page (optional) this is how it is on the prototype, I agree that for OOUI we should remove the "(optional)" part since this is the default

The design follows the Wikimedia style guide form guidelines for this. If it is a challenge to do it this way then go with the defaults.

• The placeholders are in the design specs only, and not in the AC. Can we confirm whether they should be included, and if their texts have been reviewed?

They should be included. I don't know if @ilana has reviewed them. Here they are for easy reference:

Invitation list name
e.g WIki Loves Wiki 2024 Invitation List

Event page (optional)
e.g WIki Loves Wiki 2024

Article list
e.g
Jean Pliya
Chanceline Mevowanou
Benoît Dato

In T356679#9838830, @gonyeahialam wrote:

In T356679#9836963, @cmelo wrote:

Hi @ifried and @gonyeahialam, there are 2 things that come up on code reviews, that I need your feedback on:

• The default behavior of OOUI is to add * for required fields, and not for optional fields, so it was suggested to remove the word "(optional)" from the sentence below:
  • Event page (optional) this is how it is on the prototype, I agree that for OOUI we should remove the "(optional)" part since this is the default

The design follows the Wikimedia style guide form guidelines for this. If it is a challenge to do it this way then go with the defaults.

• The placeholders are in the design specs only, and not in the AC. Can we confirm whether they should be included, and if their texts have been reviewed?

They should be included. I don't know if @ifried has reviewed them. Here they are for easy reference:

Invitation list name
e.g WIki Loves Wiki 2024 Invitation List

Event page (optional)
e.g WIki Loves Wiki 2024

Article list
e.g
Jean Pliya
Chanceline Mevowanou
Benoît Dato

Thanks, @gonyeahialam, it is already done this way, I just need to confirm if it was validated, because this came up in a comment on code review.

Hi @cmelo & @gonyeahialam, I have some comments on the placeholders; let me know what you think:

For the invitation and event name titles, I don't think we should include a date, such as "2024," since it will soon seem outdated. Also, although I understand the purpose of writing "Wiki Loves Wiki," it seems like it could confuse people. They may wonder, "What is Wiki Loves Wiki?," if they are unfamiliar with Wiki Loves events or don't know if/how their event needs to be similar to a Wiki Loves event. So perhaps we can have something more generic, such as:

• My Event Invitation List
• My Event

For the article list name, I don't think we should have actual articles listed because that seems to advertise certain articles in the interface. For example, one of the articles has been flagged as having issues on French Wikipedia. I think we should have something more neutral and generic, like:

• Article 1
• Article 2
• Article 3

I haven't received a response from @gonyeahialam, but I'm being bold and just updating the AC. Please do feel free to comment if you have any suggestions or thoughts though, Gregory.

cc @cmelo: Let me know if you have any questions; thanks!

In T356679#9840479, @ifried wrote:

Hi @cmelo & @gonyeahialam, I have some comments on the placeholders; let me know what you think:

For the invitation and event name titles, I don't think we should include a date, such as "2024," since it will soon seem outdated. Also, although I understand the purpose of writing "Wiki Loves Wiki," it seems like it could confuse people. They may wonder, "What is Wiki Loves Wiki?," if they are unfamiliar with Wiki Loves events or don't know if/how their event needs to be similar to a Wiki Loves event. So perhaps we can have something more generic, such as:

• My Event Invitation List
• My Event

For the article list name, I don't think we should have actual articles listed because that seems to advertise certain articles in the interface. For example, one of the articles has been flagged as having issues on French Wikipedia. I think we should have something more neutral and generic, like:

• Article 1
• Article 2
• Article 3

I have been thinking about this. We are aiming to create a balance between being too specific and too generic. The goal with the placeholder here is to convey the format of the input and an example of the input. For the Article list, Article 1 2 3 convey the format(each on new lines) but doesn't give an example. To not look like we are advertising an article, we can use some generic article titles like Sun, Moon, House. For Invitation list name, we can leave it as My Event Invitation List. For the Event page, the label may already be confusing because it doesn't state what exactly you should input, is it the event name or url. In this case it is actually the Event page title you are inputting which may not be the same as the Event name. Perhaps the placeholder can be use instead to give a hint such as "Enter the title of your event page". In summary my suggestions are:

Invitation list name
My Event Invitation List

Event page (optional)
Enter the title of your event page

Article list
Sun
Moon
House

In T356679#9849885, @gonyeahialam wrote:

In T356679#9840479, @ifried wrote:

Hi @cmelo & @gonyeahialam, I have some comments on the placeholders; let me know what you think:

For the invitation and event name titles, I don't think we should include a date, such as "2024," since it will soon seem outdated. Also, although I understand the purpose of writing "Wiki Loves Wiki," it seems like it could confuse people. They may wonder, "What is Wiki Loves Wiki?," if they are unfamiliar with Wiki Loves events or don't know if/how their event needs to be similar to a Wiki Loves event. So perhaps we can have something more generic, such as:

• My Event Invitation List
• My Event

For the article list name, I don't think we should have actual articles listed because that seems to advertise certain articles in the interface. For example, one of the articles has been flagged as having issues on French Wikipedia. I think we should have something more neutral and generic, like:

• Article 1
• Article 2
• Article 3

I have been thinking about this. We are aiming to create a balance between being too specific and too generic. The goal with the placeholder here is to convey the format of the input and an example of the input. For the Article list, Article 1 2 3 convey the format(each on new lines) but doesn't give an example. To not look like we are advertising an article, we can use some generic article titles like Sun, Moon, House. For Invitation list name, we can leave it as My Event Invitation List. For the Event page, the label may already be confusing because it doesn't state what exactly you should input, is it the event name or url. In this case it is actually the Event page title you are inputting which may not be the same as the Event name. Perhaps the placeholder can be use instead to give a hint such as "Enter the title of your event page". In summary my suggestions are:

Invitation list name
My Event Invitation List

Event page (optional)
Enter the title of your event page

Article list
Sun
Moon
House

Both options SGTM, wondering which one we should use.
cc: @ifried

Hi @gonyeahialam! Thanks for these suggestions.

Yes, I think an alternative is to have neutral article names, like "Sun" and "Moon." That works for me. However, I do think we should strive for consistency. I think it is confusing if we have an example ("My Event Invitation List") in one case and a description of how to enter in information ("Enter the title of your event page") in another case. We should pick one format and stick to it. Which format do you recommend, from a UX perspective? I still feel like my suggestions above are the most straight-forward.

As for the event page, if that is unclear, maybe we should just update the label? For example, "Event page title"

@ifried Let's go ahead with you initial suggestion for the Event page field. If there is confusion reported or observed in the feedback survey or usability test then we can change it.

In summary:

Invitation list name
My Event Invitation List

Event page (optional)
My Event

Article list
Sun
Moon
House

In T356679#9855550, @gonyeahialam wrote:

@ifried Let's go ahead with you initial suggestion for the Event page field. If there is confusion reported or observed in the feedback survey or usability test then we can change it.

In summary:

Invitation list name
My Event Invitation List

Event page (optional)
My Event

Article list
Sun
Moon
House

Just one note on this, the default used is just the first word with the first letter uppercase, so it will be:
Invitation list name
My event invitation list

Event page
My event

Article list
Sun
Moon
House

Also, the "(optional)" on Event page field should be removed since the default is to not use it on OOUI, so basically the required fields will have a * and the optional not.

cc: @gonyeahialam @ifried

Sounds good to me; thank you! I will update the AC.

To be able to test it locally, you need to add the below to your LocalSettings.php:

$wgCampaignEventsEnableSpecialGenerateInvitationList = true;

• Whether the page is enabled for that wiki or not

$wgCampaignEventsShowSpecialGenerateInvitationList = true;

• If this is false it is like the page not even exist, and will not be listed on the list of special pages on: Special:SpecialPages

cc: @vaughnwalters

Hi @ifried, while adding the feature flag for this special page, some questions come up on code review:

• What to do with the other special pages (Special:MyInvitationLists and Special:InvitationList) on wikis where you can't generate invitation lists.
  • First question on this, just to confirm: Are we still blocking some wikis to have this enabled?
  • If the above is yes, should they be hidden altogether or display a message saying that this feature is not available on this wiki?
• Do we need a feature flag to enable these pages by wiki?
  • Like available on meta but not on other wiki e.g.

These answers would allow us to more accurately scope this flag.

Hello, @cmelo! Yes, ideally, we would want to allow wikis to decide if they want Event Invitations. For some wikis (for example, Meta-Wiki), it does not seem like it would be a very useful feature. For some other wikis, they may want Event Registration, but they may not want Event Invitations (for example), so we would like for them to choose which features they want turned on and off. So, my first choice would be to allow each wiki to choose if it is enabled.

However, I think we also discussed in the past that it may add extra complexity to allow each wiki to turn it on/off. Also, in the future, we could handle the situation of wikis turning features on/off via Community Configuration. So, would an easier alternative to be to have the extension released to all Wikipedia wikis that have the CampaignEvents extension enabled as default, but they have the option to hide it if they do not want it?

So, I see a few options (and there are probably more options, but these are just a few of them):

• Option 1: We turn on Event Invitations for all wikis that have the extension enabled by default
• Option 2: We turn on Event Invitations for no wikis that have the extension enabled by default, but we can enable it on individual wikis that request it
• Option 3: We turn on Event Invitations for only Wikipedia wikis by default

To me, Option 2, followed by Option 3, is the probably the best. Option 2 offers us the most flexibility in our communication with communities in getting the extension enabled. I'm not as interested in Option 1, since the extension is already enabled on Meta-Wiki and it already has many users with the organizer right on the wiki; I don't think we need to try to convince that community to enable a new feature/power to organizers on Meta-Wiki, when the actual feature itself will be of minimal value.

@Udehb-WMF @EUwandu-WMF & @Sadads, I'm curious about what you think about the question of whether Event Invitations should be enabled on all wikis (by default) that have the CampaignEvents extension enabled. Eventually, we will want this to be chosen by wikis via Community Configuration, but we need to make a decision in the meantime. Maybe there is a better way to think about this, so I would love to hear your perspectives!

In T356679#9869645, @ifried wrote:

Hello, @cmelo! Yes, ideally, we would want to allow wikis to decide if they want Event Invitations. For some wikis (for example, Meta-Wiki), it does not seem like it would be a very useful feature. For some other wikis, they may want Event Registration, but they may not want Event Invitations (for example), so we would like for them to choose which features they want turned on and off. So, my first choice would be to allow each wiki to choose if it is enabled.

However, I think we also discussed in the past that it may add extra complexity to allow each wiki to turn it on/off. Also, in the future, we could handle the situation of wikis turning features on/off via Community Configuration. So, would an easier alternative to be to have the extension released to all Wikipedia wikis that have the CampaignEvents extension enabled as default, but they have the option to hide it if they do not want it?

So, I see a few options (and there are probably more options, but these are just a few of them):

• Option 1: We turn on Event Invitations for all wikis that have the extension enabled by default
• Option 2: We turn on Event Invitations for no wikis that have the extension enabled by default, but we can enable it on individual wikis that request it
• Option 3: We turn on Event Invitations for only Wikipedia wikis by default

To me, Option 2, followed by Option 3, is the probably the best. Option 2 offers us the most flexibility in our communication with communities in getting the extension enabled. I'm not as interested in Option 1, since the extension is already enabled on Meta-Wiki and it already has many users with the organizer right on the wiki; I don't think we need to try to convince that community to enable a new feature/power to organizers on Meta-Wiki, when the actual feature itself will be of minimal value.

@Udehb-WMF @EUwandu-WMF & @Sadads, I'm curious about what you think about the question of whether Event Invitations should be enabled on all wikis (by default) that have the CampaignEvents extension enabled. Eventually, we will want this to be chosen by wikis via Community Configuration, but we need to make a decision in the meantime. Maybe there is a better way to think about this, so I would love to hear your perspectives!

Thanks @ifried options 2 sounds followed by option 3 also sounds to be the best option for me, I will implement it this way for now, but we can change if needed

@ifried one last question on this, should we have a custom message for when Event Invitations is not enabled on a wiki rather than just show an empty page?

The current behavior on this is: If the extension is not enabled on a wiki, and you go to this page, you see the page title: Generate invitation list
and an empty page, so on code review we are also wondering if we should add a message like: "This feature is not enabled on this wiki." or even completely hide the special page when not enabled.

Thanks for flagging this; and we discussed this in backlog refinement today, @cmelo! Yes, I think we should have one main message for all circumstances, which is "Invitation Lists is not enabled on this wiki." I have updated T365068 with this information.

I would also include a link to where the user can request turning it on -- until it gets turned on in Event Registration -- the tendency of organizers is not to always know how to triage these kinds of problems, so a link to either Community Configuration discussion (eventually) or in the short term a phabricator ticket for requesting to turn on the tools for the language might be helpful.

Thanks for sharing this, @Sadads! We were actually talking about this exact topic today in a team meeting. We were debating back and forth about how to do this/if we should do this. And, yes, in the future, we could include a link to Community Configuration documentation... but what do we do in the meantime? We could potentially write our own documentation for something like, "How to request features for the CampaignEvents extension," which includes best practices like starting a discussion on your local wiki. But so much of it comes down to local wikis, and we didn't think it would even be common for someone to go to a special page for Invitation Lists on a wiki where the feature is not enabled... so we were thinking of maybe just waiting to include the link when Community Configuration is ready for the CampaignEvents extension? Anyway, that was a ramble, but I am curious to hear your thoughts!

In T356679#9886018, @ifried wrote:

Thanks for flagging this; and we discussed this in backlog refinement today, @cmelo! Yes, I think we should have one main message for all circumstances, which is "Invitation Lists is not enabled on this wiki." I have updated T365068 with this information.

Thank you, @ifried, I have added it, but when I was adding a new question come up which is:

• Will this message be shown to any logged in user or only to users that have the organizer right?
• If we show this message only to users that have the organizer right, what should we show to users that do not have the organizer right?

I was checking other special pages, and when a logged in user (that does not have the organizer right) tries to access the SpecialEditEventRegistration/{id}, it shows a message in red saying:

• You are not allowed to edit this event registration.
• 

And when the user goes to Special:DeleteEventRegistration/1 the message is a little bit different in message and UI

So I am wondering what should we do for each of the scenarios below:

• Invitation list is enabled and the user who is accessing the page has the organizer right, then we show the for to generate the invitation list
  • 
• Invitation list is not enabled and the user who is accessing the page has the organizer right, then we show the notice message
  • 
• Invitation list is enabled and the user who is accessing the page doesn't have the organizer right, then we show the not allowed error message (My proposal)
  • 
• Invitation list is not enabled and the user who is accessing the page doesn't have the organizer right, then what should we do?
  • Show the error message?
  • Show the notice message?
  • Show a different message?

Also, I think that T365068 could be merged with this task

Preliminary feedback from the Usability test for the Invitation lists MVP
(Urgent feedback that needs to be worked on for people to be able to use the tool.)

• Some participants misunderstood the Invitation list name field to be where they add their own invitation list(list of editors to invite) rather where they write the name of their invitation list
• Most participants thought they are to enter the event page URL instead of the event page name in the Event page field
• Participants understood the how to input the article list but many didn't understand the purpose. They thought the list will be sent to participants for them to know the articles to be worked on during the event. They also didn't know to exclude redlinks.

In T356679#9888678, @gonyeahialam wrote:

Preliminary feedback from the Usability test for the Invitation lists MVP
(Urgent feedback that needs to be worked on for people to be able to use the tool.)

• Some participants misunderstood the Invitation list name field to be where they add their own invitation list(list of editors to invite) rather where they write the name of their invitation list
• Most participants thought they are to enter the event page URL instead of the event page name in the Event page field
• Participants understood the how to input the article list but many didn't understand the purpose. They thought the list will be sent to participants for them to know the articles to be worked on during the event. They also didn't know to exclude redlinks.

Thanks @gonyeahialam, should we mark this task as blocked?

@cmelo I don't think so. Are you already done with development of this? The changes are only copy changes.

In T356679#9888770, @gonyeahialam wrote:

@cmelo I don't think so. Are you already done with development of this? The changes are only copy changes.

Ok, Yes, almost done, just need a decision on the scenarios I shared on my last comment

Let's take those decisions on the scenarios, Claudio mentions. He can then deliver this first version. We can then add take the time to think through changes to address the usability feedback and iterate on the first version.

What do you all think?
cc: @cmelo @gonyeahialam @ifried

Hello, @VPuffetMichel, @gonyeahialam, and @cmelo! Gregory added this information because I asked him to add in what he considered urgent notes on improvements into the related Phabricator tickets, based on the usability test findings, for stuff that he would strongly recommend to be included in the MVP. Since this ticket is almost done, we have added these notes to a new ticket for improvements to the Special:GenerateInvitationList (T367436), which can be worked on immediately post-MVP, but we can consider his suggestions for the MVP for work that has not not been done yet.

Hello, @cmelo! Here is what I think:

• If the feature is not enabled on the wiki: We should show the same message to all users (whether or not they have the event organizer right), which will be: "This wiki does not have Invitation Lists enabled." I think this information is useful, regardless of whether or not someone has the organizer right, and it keeps things simple.
• If the feature is enabled on a wiki, but someone does not have the organizer right: We can go with your recommendation, but we should tweak the language to the following: You are not allowed to use Invitation Lists.

What do you think?

Also, cc @gonyeahialam for your visibility and in case you have any suggestions

Hey @ifried, I have two minor questions that came up in code review.

1. Should the two notices ("This wiki does not have invitation lists enabled" and "You are not allowed to use invitation lists") end with a full stop? This isn't very clear in the AC.
2. What should happen if a logged-out user visits the Special:GenerateInvitationList page and the feature is not enabled? Should we tell them that the feature is disabled, or should we ask them to login, and then tell them that it's disabled? I think the first, but I'd like to hear your thoughts on this.

Hello, @Daimona:

1. Yes, they should with a full stop because they are complete sentences. Thanks for checking in about this!
2. Yes, in cases when the feature is not enabled on a wiki, the user should see the same message, whether or not they are logged in. I have updated the AC.

But one thing occurred to me: I don't think we currently cover in the AC cases in which the wiki has the feature enabled, but the user is not logged in (so we don't yet know if they can access the feature or not). The best behavior would probably be to have a message for that too, such as: "Please login to see if you can access invitation lists." Is there a default way that the code is currently handling this?

Thanks, @ifried and @Daimona,

1. Yes, they should with a full stop because they are complete sentences. Thanks for checking in about this!

This is done now

2. Yes, in cases when the feature is not enabled on a wiki, the user should see the same message, whether or not they are logged in. I have updated the AC.

I will add it, thanks

But one thing occurred to me: I don't think we currently cover in the AC cases in which the wiki has the feature enabled, but the user is not logged in (so we don't yet know if they can access the feature or not). The best behavior would probably be to have a message for that too, such as: "Please login to see if you can access invitation lists." Is there a default way that the code is currently handling this?

At the moment, if the user is not logged in and tries to access Special:GenerateInvitationList, the user is redirect the to login page.

Should we change it to show this message instead:

• Please login to see if you can access invitation lists.

?

Ah, I think redirecting the user to the login page is better than a message that *tells* them to login, so we can keep the current behavior, @cmelo. But to clarify: Is this behavior only for cases when the user is not logged in and the extension is enabled on the wiki? I am asking because I think this would be appropriate behavior for when the extension is enabled, but it would not be appropriate behavior if the extension is not enabled.

In T356679#9901158, @ifried wrote:

Ah, I think redirecting the user to the login page is better than a message that *tells* them to login, so we can keep the current behavior, @cmelo. But to clarify: Is this behavior only for cases when the user is not logged in and the extension is enabled on the wiki? I am asking because I think this would be appropriate behavior for when the extension is enabled, but it would not be appropriate behavior if the extension is not enabled.

Thanks @ifried, it is the same behavior for both cases, but we can change it not redirect when the invitation list is disabled.

Just to be sure, you mean the invitation list is not enabled, right?
I am asking because you mention the extension been disabled or enabled, but if the extension is disabled on a wiki this special page does not exist there.

Yes, sorry! The feature enabled/disabled, yes! :) @cmelo

And, cool, I will update the AC :)

Change #1036181 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Create SpecialGenerateInvitationList

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

$wgCampaignEventsEnableEventInvitation = true; enable the invitation list on the wiki
$wgCampaignEventsShowEventInvitationSpecialPages = true; feature flag to hide/show the invitation list special pages

Acceptance Criteria:

• Given that an organizer has the Event Organizer right on the wiki,
  • ✅ They should be able to access Special:GenerateInvitationList
• Special:GenerateInvitationList should have the following sections:
  • ✅ Field label: "Invitation list name"
    • ✅ Placeholder: My event invitation list
    • 
  • ✅ Field label: "Event page"
    • ✅ Placeholder: Event:My event
    • 
  • ✅ Section label: "Article list"
    • ✅ Placeholder: Sun Moon House (separated by lines between each article name)
    • 
  • Explanatory text, which reads:
    • ✅ "Enter the names of up to 300 articles that cover the topics of your event. Each article should be on a new line."
    • 
  • ✅ There should be a button: "Generate"
  • 
  • ❌ See note at the bottom of this comment, it should be a full width button on mobile breakpoint
• Given that a user accesses a special page associated with Invitation Lists,
  • And the wiki does not have Invitation Lists enabled,
    • And the user is either logged in or logged out,
      • ❌ They should see the following message: This wiki does not have invitation lists enabled.
      • 
      • The message does display, but it should be lists instead of list
• Given that a user accesses a special page associated with Invitation Lists,
  • And the wiki has Invitation Lists enabled,
    • And the user does not have the Event organizer right,
      • ✅ They should see the following message: You are not allowed to use invitation lists.
      • 
• Given that a user accesses a special page associated with Invitation Lists,
  • And the wiki has Invitation Lists enabled,
    • And the user is logged out,
      • ✅ They should be redirected to login.
• ✅ Put a feature flag for the page

@cmelo there are only two small UI things that need fixed:

1. The generate button should be full width on mobile

comp	build

2. lists just needs to be plural in the copy This wiki does not have invitation lists enabled.

In T356679#9910863, @vaughnwalters wrote:

1. The generate button should be full width on mobile

Earlier today we were talking about this in the context of T364791. @gonyeahialam Could you provide more information about this behaviour of the buttons? It doesn't seem to be the default in OOUI or Codex HTMLForm.

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

[mediawiki/extensions/CampaignEvents@master] Fix typo

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

Thanks @vaughnwalters

In T356679#9910863, @vaughnwalters wrote:

• 
• ❌ See note at the bottom of this comment, it should be a full width button on mobile breakpoint

On this one I have the same question @Daimona wrote above

• Given that a user accesses a special page associated with Invitation Lists,
  • And the wiki does not have Invitation Lists enabled,
    • And the user is either logged in or logged out,
      • ❌ They should see the following message: This wiki does not have invitation lists enabled.
      • 
      • The message does display, but it should be lists instead of list

Done in this patch

Change #1049083 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Fix typo

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

In T356679#9910912, @Daimona wrote:

In T356679#9910863, @vaughnwalters wrote:

1. The generate button should be full width on mobile

Earlier today we were talking about this in the context of T364791. @gonyeahialam Could you provide more information about this behaviour of the buttons? It doesn't seem to be the default in OOUI or Codex HTMLForm.

That's the documented behaviour as shown in
https://doc.wikimedia.org/codex/latest/style-guide/constructing-forms.html#responsive-behavior

In T356679#9918820, @gonyeahialam wrote:

In T356679#9910912, @Daimona wrote:

In T356679#9910863, @vaughnwalters wrote:

1. The generate button should be full width on mobile

Earlier today we were talking about this in the context of T364791. @gonyeahialam Could you provide more information about this behaviour of the buttons? It doesn't seem to be the default in OOUI or Codex HTMLForm.

That's the documented behaviour as shown in
https://doc.wikimedia.org/codex/latest/style-guide/constructing-forms.html#responsive-behavior

Thanks, @gonyeahialam, since this documented behavior is for codex, I think we shouldn't do it now, because we are using OOUI and this is not the default behavior on OOUI.

I have added this ticket to the agenda for the design + engineering meeting tomorrow; cc @cmelo & @gonyeahialam

In T356679#9921928, @cmelo wrote:

In T356679#9918820, @gonyeahialam wrote:

In T356679#9910912, @Daimona wrote:

In T356679#9910863, @vaughnwalters wrote:

1. The generate button should be full width on mobile

Earlier today we were talking about this in the context of T364791. @gonyeahialam Could you provide more information about this behaviour of the buttons? It doesn't seem to be the default in OOUI or Codex HTMLForm.

That's the documented behaviour as shown in
https://doc.wikimedia.org/codex/latest/style-guide/constructing-forms.html#responsive-behavior

Thanks, @gonyeahialam, since this documented behavior is for codex, I think we shouldn't do it now, because we are using OOUI and this is not the default behavior on OOUI.

We decided to keep it as it is, moving this back to qa @vaughnwalters

• Given that a user accesses a special page associated with Invitation Lists,
  • And the wiki does not have Invitation Lists enabled,
    • And the user is either logged in or logged out,
      • ❌ They should see the following message: This wiki does not have invitation lists enabled.
      • 
      • The message does display, but it should be lists instead of list

Done in this patch

✅ They should see the following message: This wiki does not have invitation lists enabled.

The copy is fixed now, so I am moving this to design sign off. See T356679#9910863 for the rest of the testing notes.