@ifried So once the editors usernames are generated organizers will have to copy them and paste them into the mass message tool?

There may be a need for the generated list to persist/be saved, that is, organizers will be able to come back and view the editor list multiple times. This is necessary because organizers may not send the messages immediately after the list is generated. Also, because the mass message is capped at about 20 per day.
cc @ifried @Daimona

@gonyeahialam Organizers will not all use the same method for sending invitations, most likely. They can either use email (wikimail) or user talk page messages to invite editors. There are 2 main tools for sending mass emails (massmailer and massenmail). To send talk page messages, they can either individually go to each user's talk page & post an invitation or they send invitations to many user talk page at once if they have the MassMessage right on the wiki where they are posting the invitations.

It is important to note that it is unlikely that organizers will simply copy/paste the full list into an email tool. Rather, we learned that organizers first review the list we give them and then they make their own judgment calls about who to invite based on various criteria, such as: whether the user was already invited or already joined, whether the user is one of the organizers, and by looking at the edit history of the users and what they see about themselves on their user pages. If you would like to learn more about how organizers make these decisions, I recommend that you talk to the ambassadors to learn more.

Exploring ideas on event invitation flow.
The generated editor list will need to be saved so that organizers can review and send invites over a period of time, they will likely not do it immediately after the list is generated.
Also, we may need to allow organizers to generate multiple lists - for organizers organizing multiple events or in case the first list is not enough and organizers want to generate more with another worklist.

Such a flow could look like this:

This screen shows an option to create a new invitation, it shows a list of past invitation lists, including one that is still pending(yet to be generated)	When you click on a new list you see this screen with a form to fill in necessary details	After you have submitted the work list you see a copy at the bottom of this screen telling you how long it will take and how you will be notified. It also has a cancel button	When the invitation list is ready you see this screen

@Daimona @ifried Let me know your thoughts on this early flow ideas

@Daimona @MHorsey-WMF @cmelo Let me know your technical feedback on the flow and features

In T361029#9693502, @gonyeahialam wrote:

The generated editor list will need to be saved so that organizers can review and send invites over a period of time, they will likely not do it immediately after the list is generated.

I think a key question is what kind of storage we want. I assume we don't need want to persist the data indefinitely.

After you have submitted the work list you see a copy at the bottom of this screen telling you how long it will take and how you will be notified.

this might be hard to estimate.

In T361029#9701518, @Daimona wrote:

In T361029#9693502, @gonyeahialam wrote:

The generated editor list will need to be saved so that organizers can review and send invites over a period of time, they will likely not do it immediately after the list is generated.

I think a key question is what kind of storage we want. I assume we don't need want to persist the data indefinitely.

I was thinking of storing the data till the event ends but if the event isn't using Events Registration tool we wouldn't have that information. Perhaps we use 90days.

After you have submitted the work list you see a copy at the bottom of this screen telling you how long it will take and how you will be notified.

this might be hard to estimate.

So it isn't fixed? What determines how long the invitation list processing duration is?
My idea is that we notify the organisers via email, echo or other means when their invitation list is ready

Eng-Design Meeting Notes

Early Design explorations - Wireframes

Claudio: It is impossible to know how long it will take to generate an invitation list. It could be seconds or it could be hours, depending on how long it would take. So we cannot say “24 hours” for example.
Gregory: In that case, it is really important to inform the organizer, perhaps via echo or email. What is the best way? What is technically feasible? Can the process be canceled?
Claudio: I think email is the best way. When the event invitation list is being generated -> we have a job that is being run, and when we configure it to the app, we will add the request to the schedule of the queue -> it could run every hour, every 5 mins, all depends on what decision we make -> if you generate it, i am not sure if you can cancel it; i don’t know but potentially not possible to cancel
Euphemia: Do we need to send 1 or 2 emails? One email to say that the list is being generated/in progress and one to say that the list is ready?
Claudio: I don’t know if we need both.
Ilana: for now, we are thinking an on-wiki notification that says the list will be generated and then they get an email when it is ready
Euphemia: i think it would be less frustrating for organizers if they get 2 emails.
Ilana: This could be an additional feature we work on post-MVP (i.e., an email sent to organizers that says that the list is being processed and they will get another email when the list is ready)
What estimate of a time range for the list being ready can we give to organizers? What is the maximum time for generating the list?
Claudio: We can have an estimate of the time; we need to discuss this in our next engineering meeting; if we run this job every minute, and let’s say we have a list of 100 articles, we can do some tests to give an estimate
Claudio: Will we have a limit for how many articles they add in?
Ilana: Yes. We can get a number from Campaigns Programs and then confirm that it works with engineering. We don’t know the number yet, but we can get it.
Gregory: Organizers may be generating multiple lists (for example, they have multiple events happening at the same time on one wiki, or they have the organizer right on multiple wikis and they are organizing a global event). If they have multiple lists, they would want to display it on a page.
Claudio:
Do we need multiple lists per one event?
Ilana: I think we should start with one list per event for MVP. But we can explore expanding this later.
Do we want to store the worklists?
Ilana: Yes, we may want to because we may later do a worklist project.

Action items

• Ilana talks to Campaigns Programs on a reasonable article limit for worklists for event invitations
• Engineers to conduct some tests to see how long it would take to generate an invitation list (average and maximum)
• Engineers to investigate how we can store worklists
• Gregory to share designs with ambassadors to collect feedback

Some quick notes:

In T361029#9726720, @gonyeahialam wrote:

Gregory: In that case, it is really important to inform the organizer, perhaps via echo or email. What is the best way? What is technically feasible?

We have a standard way of notifying users and that is Echo. I don't think any other option should be considered at all.

Can the process be canceled?

Maybe, if needed. But I'm not sure how useful it might be.

it could run every hour, every 5 mins, all depends on what decision we make [...] if we run this job every minute

The job is pushed to the job queue, and then it gets executed as soon as there are resources for it. This is out of our control.

We have a standard way of notifying users and that is Echo. I don't think any other option should be considered at all.

Why can't any other option like email be considered (in addition to echo) or do you get an email version for the echo? @Daimona

In T361029#9739724, @gonyeahialam wrote:

We have a standard way of notifying users and that is Echo. I don't think any other option should be considered at all.

Why can't any other option like email be considered (in addition to echo) or do you get an email version for the echo? @Daimona

You can choose to get either a web notification or an email from Echo (or both)

@Daimona What are the accepted ways to separate the article titles in the text input fields? Note: Some articles have commas in their names.

In T361029#9758051, @gonyeahialam wrote:

@Daimona What are the accepted ways to separate the article titles in the text input fields? Note: Some articles have commas in their names.

I think newline-separated would be the most standard and clearest way. Anything in-line (such as commas, pipes, middots; or "interactive" such as TagMultiselect) wouldn't work well with worklist having more than a handful of pages. The textarea in F47344528 seems fine.

Earlier in the week, I shared a video walkthrough of the current design of event invitation with the ambassadors and others - Georges, Bachounda, Isabel, Alex and Benedict.

Summary of feedback

General Impressions

• "In general though its very thoughtful, I like it a lot"
• "I like pretty much the flow since it seems to be clear and simple."
• "On a first sight, it seems simple to use"
• "Direct, simple, intuitive"
• "The procedure is simple and practical"

Specific Suggestions/Feedback

Article Input

• Alex suggests avoiding commas to separate article titles due to the potential for confusion, recommending the use of new lines or pipes instead.
• Benedict appreciates the initial page design but suggests improving the clarity of the article input limit. He notes potential confusion with the current wording, which might imply a necessity to input up to 50 articles. Instead, he recommends stating clearly that organizers can input "1 - 50 articles,"

Access to Previous Lists

• Benedict particularly appreciates the ability for organizers to access previous lists generated.

Multiple Invitation Lists

• Alex notes the potential need for generating multiple event lists, especially when the initial list does not meet needs. He also suggests a limit on the number of lists generated per event.

Integration with Event Registration

• Alex proposes that invitation lists should be derived from already created event pages, ensuring coherence between events and their invitations.
• Mohammed questions whether the invitation tool will be integrated event registration and therefore make asking for event url obsolete.

Pending Message

• Alex supports the idea of a pending message with follow-up notifications, viewing it as a foundation for future features like report generation.

Notifications

• Alex and Isabel favor starting with echo notifications that can trigger emails, with Isabel suggesting that notification preferences should be configurable by the user.
• Georges prefers direct email notifications due to contributors' infrequent wiki checks.

Using the Invitation List

• Isabel and Mohammed emphasize the utility of exporting the invitation list to Excel for easier management and external communication. Isabel shares from personal experience the benefits of such a feature for organizing and tracking invitations.
• Mohammed also sees the need for features to filter and select users from the list, using it for mailing purposes.
• Benedict suggests adding a "copy" button to the interface to allow organizers to easily copy names from the generated list

Some Todos based on the feedback

Design

• Use newline as the way to separate articles in the article input [Done]
• Explore the integration of Event invitation and Event registration, present and discuss with team.
• Explore ideas on how to ease invitation list management [Doing]
  • Exporting list to use externally
  • Filtering and managing editor list within event invitation.

Team

• If necessary, discuss if we want to add multiple event lists to MVP

Engineering

• I believe we can implement the default echo notification behaviour where it also triggers an email notification

@VPuffetMichel @ifried @MHorsey-WMF @Daimona @cmelo Please review the last two messages

Current design

@ifried We can share it with the community while I continue to get more feedback, iterate, explore and also start work on the desktop version.

I am currently exploring how to handle errors in articles inputted. If out 50 articles entered 5 were not recognized, the tool doesn't need to prevent the organizers from going ahead with generating the invitation list with the remaining.
I am thinking about how we can inform the organizer that some articles have an error and give them the option to either fix the errors or go ahead to generate the list. The two ideas I have come up with so far:

Idea 1	Idea 2
Upon submission of the form, a warning notice is shown below the form field. The organizer is informed of the wrong articles and told to correct or go ahead and submit. Ideally this error handling should happen before form submission, is this possible? There will be some inconsistencies if it happens after form submission: First, a warning message doesn't normally prevent submission only an error.	Show a dialog to inform the organizer of the wrong articles with the option to go back and correct or go ahead and submit.

Let me know your thoughts @VPuffetMichel @ifried @MHorsey-WMF @Daimona @cmelo @ifried

In T361029#9768968, @gonyeahialam wrote:

Current design

A few comments:

• We need to think about the title of the page. Both the "internal" Special:XYZ name and the user-facing title. Just "event invitation" doesn't seem to agree well with a page where you can generate and see multiple lits.
• The standard input field for pages takes the page name, not the URL
• Re "the process typically takes 1 hour": to be investigated in T362896, but I'm not sure if we can be this specific, as there's likely going to be high variance.
• Re "notified by email": it would scale better if we just omitted the "by email" part. Assuming that we'll use Echo, users can choose how to be notified, if at all. Even if we choose to only allow emails for now, we wouldn't have to change the wording again later.
• What is "search editor list" for? I assume we'll display everyone in the page, right? And that there's going to be a limit on how many people can be extracted.
• I don't see this in the feedback above (T361029#9768926) but I clearly remember someone asking for user "tool" links along with each username (user page, contribs, talk; presumably the standard user tool links shown on Special:Log, action=history, etc.)
• Depending on whether we are going to use Codex for this page, the cards shown in the last example may or may not be possible to implement.

In T361029#9774986, @gonyeahialam wrote:

I am thinking about how we can inform the organizer that some articles have an error and give them the option to either fix the errors or go ahead to generate the list. The two ideas I have come up with so far: [...]

I think idea 1 would be more consistent with the other forms

Ideally this error handling should happen before form submission, is this possible?

Depends on how many articles we want to allow. If it's too many, it would be too expensive.

@Daimona

The standard input field for pages takes the page name, not the URL

Are you referring to the Event page URL? You mean you can just input the page name instead of the URL. If so, would it work for pages of different namespaces (e.g event pages not in the Event names space)

Re "notified by email": it would scale better if we just omitted the "by email" part. Assuming that we'll use Echo, users can choose how to be notified, if at all. Even if we choose to only allow emails for now, we wouldn't have to change the wording again later.

Just telling them that they will be notified may not be clear enough as they may not know where to expect that notification

What is "search editor list" for? I assume we'll display everyone in the page, right? And that there's going to be a limit on how many people can be extracted.

Have we decided on a limit yet? The search is to find specific editors for for example find specific persons you don't want to invite that are on the list. But this may be of low priority since we don't have messaging integrated yet and since we may fix a limit.

I don't see this in the feedback above (T361029#9768926) but I clearly remember someone asking for user "tool" links along with each username (user page, contribs, talk; presumably the standard user tool links shown on Special:Log, action=history, etc.)

I don't think we are doing this for the MVP cc @ifried

Depending on whether we are going to use Codex for this page, the cards shown in the last example may or may not be possible to implement.

We could implement it as a border box with only the event title being clickable.

In T361029#9774986, @gonyeahialam wrote:
I am thinking about how we can inform the organizer that some articles have an error and give them the option to either fix the errors or go ahead to generate the list. The two ideas I have come up with so far: [...]

I think idea 1 would be more consistent with the other forms

Ideally this error handling should happen before form submission, is this possible?

Depends on how many articles we want to allow. If it's too many, it would be too expensive.

If the form validation doesn't happen before submission then it will no longer be consistent with other forms.

In T361029#9778918, @gonyeahialam wrote:

The standard input field for pages takes the page name, not the URL

Are you referring to the Event page URL? You mean you can just input the page name instead of the URL. If so, would it work for pages of different namespaces (e.g event pages not in the Event names space)

Yes to all your questions.

Re "notified by email": it would scale better if we just omitted the "by email" part. Assuming that we'll use Echo, users can choose how to be notified, if at all. Even if we choose to only allow emails for now, we wouldn't have to change the wording again later.

Just telling them that they will be notified may not be clear enough as they may not know where to expect that notification

Yeah, I was thinking about adding a link to Special:Preferences#mw-prefsection-echo in that message. The point being, it's the user who decides where they'll receive the notification.

What is "search editor list" for? I assume we'll display everyone in the page, right? And that there's going to be a limit on how many people can be extracted.

Have we decided on a limit yet? The search is to find specific editors for for example find specific persons you don't want to invite that are on the list. But this may be of low priority since we don't have messaging integrated yet and since we may fix a limit.

I don't think we do, and I would also like to talk about limits (not just # of editors but also articles).

I am thinking about how we can inform the organizer that some articles have an error and give them the option to either fix the errors or go ahead to generate the list. The two ideas I have come up with so far: [...]

I think idea 1 would be more consistent with the other forms

Ideally this error handling should happen before form submission, is this possible?

Depends on how many articles we want to allow. If it's too many, it would be too expensive.

If the form validation doesn't happen before submission then it will no longer be consistent with other forms.

What other forms? Almost every other form we have has post-submit validation, the main exception being the "Message participants" feature.

What other forms? Almost every other form we have has post-submit validation, the main exception being the "Message participants" feature.

@Daimona I am referring to showing a warning message post validation. It is only error messages we do this for. Warning messages do not prevent form submission.

In T361029#9768926, @gonyeahialam wrote:

Earlier in the week, I shared a video walkthrough of the current design of event invitation with the ambassadors and others - Georges, Bachounda, Isabel, Alex and Benedict.

Summary of feedback

General Impressions

Updated this to include Benedict's feedback which just came in.

In T361029#9779124, @gonyeahialam wrote:

What other forms? Almost every other form we have has post-submit validation, the main exception being the "Message participants" feature.

@Daimona I am referring to showing a warning message post validation. It is only error messages we do this for. Warning messages do not prevent form submission.

Ah yeah, that makes sense, sorry.

In the past, I mentioned the need to provide a way to make the post-invitation list generation activities (sending messages) easier since we are not working on messaging yet.

This was also one of the major themes from the feedback form ambassadors T361029#9768926:

Using the Invitation List

• Isabel and Mohammed emphasize the utility of exporting the invitation list to Excel for easier management and external communication. Isabel shares from personal experience the benefits of such a feature for organizing and tracking invitations.
• Mohammed also sees the need for features to filter and select users from the list, using it for mailing purposes.
• Benedict suggests adding a "copy" button to the interface to allow organizers to easily copy names from the generated list

Some Todos based on the feedback
Design

• Explore ideas on how to ease invitation list management [Doing]
  • Exporting list to use externally
  • Filtering and managing editor list within event invitation.

Exploration
I explored related design ideas for this:

Idea 1	Idea 2a	Idea 2b
Download the invitation list as a spreadsheet or CSV	Bulk copying all editors usernames at once, enhancing efficiency for organizers who don’t need to filter the list	Bulk copying usernames of selected editors - For those who review and refine the list, provide the ability to select specific editors and copy their usernames and paste into their chosen messaging tool.

To find the best solution for this, I categorised the organizers actions/jobs into groups:

1. Organizers who send invites to the individual invitees user talk page
2. Organizers who send mass invites (via MassMessage, Massenmail...) without reviewing the list
3. Organizers who review the editor list and send mass invites.
   • 3a. Organizers who do just the above.
   • 3b. Organizers who do the above and more complex tasks like organizing and tracking invitations

To serve this 3 organizer jobs groups, a combination of Idea 1 and Idea 2a as shown below will be a great solution for an MVP or first version that balances usability, organizers needs and time/build effort. We can then incorporate other features post MVP or when we add messaging.

• For Group 1, they can click on the editor individual usernames and access whatever they want.
• For Group 2, since they don't review the editors they can copy all the usernames and transfer to whatever messaging tool.
• For Group 3, for organizers who need to review the invite list and perform more complex tasks like organizing and tracking invitations can export the list to excel where they have more features for complex actions.

This categorization above ensures each group of organizers have the right level of ease/difficulty to perform their tasks for this MVP or till we implement messaging. For example, for an organizer who just wants to send mass invites to all editors in the list, downloading a CSV file, uploading it to a spreadsheet then copying and pasting it to to a tool like massenmail will be quite complex and stressful. Such an organizer just needs to copy the usernames from our tool and paste it in the messaging tool.

If we want to create a separate experience for Group 3a and 3b and if build effort wasn't much of a challenge we can implement a combination of Idea 1 and Idea 2b as shown below, where those who want to review and send invites without any other complex actions can do this without having to download a csv and upload/open in a spreadsheet. They can review the editors, use the checkbox to unselect the editors they don't want, copy the remaining selected editors and paste into their messaging tool.

Recommendations
So these are my design options to improve the invitation list management, with a preference for Option 1 for the MVP.

Option 1	Option2
Combination of Idea 1 and 2a	Combination of Idea 1 and 2b

cc @VPuffetMichel @ifried @MHorsey-WMF @Daimona @cmelo

Latest design iteration

Recommendations
So these are my design options to improve the invitation list management, with a preference for Option 1 for the MVP.

Option 1	Option2
Combination of Idea 1 and 2a	Combination of Idea 1 and 2b

cc @VPuffetMichel @ifried @MHorsey-WMF @Daimona @cmelo

Your recommendations look good to me, @gonyeahialam. In terms of complexity, the option with the checkboxes is more complex for sure, but I don't think it adds a big effort. I would say it would add 1 or 2 extra days to implement it rather than the option without the checkboxes.

In addition to grouping users by 3 categories, this will not satisfy the thirst for finding the right participant.
I suggest a broader view
based on the assumption that the list of articles already exists in the desired language, because I remember the case of creating a non-existent article or one to be translated.

I would have done my analysis according to
User to exclude
 me
 Team
 Admins
 Bots
 Language
Activities User
 Last edit
on article list
 Edits nbr
 Last edit

Honestly, I'd like to go deeper into filtering, a filter like this will be a great help // once the list has been generated

Recommendations
So these are my design options to improve the invitation list management, with a preference for Option 1 for the MVP.

Option 1	Option2
Combination of Idea 1 and 2a	Combination of Idea 1 and 2b

Assuming the Implementation of either of the two options wouldn't be an issue, I prefer the Option 2 because it gives the organizers the ability to only copy the names of users they probably haven't already sent the invite to. they could also choose to copy all. That choice I think will be much appreciated.

In T361029#9780822, @gonyeahialam wrote:

So these are my design options to improve the invitation list management, with a preference for Option 1 for the MVP.

Option 1	Option2
Combination of Idea 1 and 2a	Combination of Idea 1 and 2b

One question about option 1: are the "copy usernames" buttons for the mobile version only? On desktop, I assume you could just select the list and copy, right? Especially if there's going to be a limit on the number of users that will be shown.

Re option 2: usernames are typically user page links. Also, I think the original request was to add user talk and contribs links; those could use the standard user tool links format:

Also the same question as option 1 re "copy" button.

Re option 2: usernames are typically user page links. Also, I think the original request was to add user talk and contribs links; those could use the standard user tool links format

@Daimona Something like this?

In T361029#9790519, @gonyeahialam wrote:

Re option 2: usernames are typically user page links. Also, I think the original request was to add user talk and contribs links; those could use the standard user tool links format

@Daimona Something like this?

Yeah. I'm not sure how much of the default style we may be able to change, but you got the idea.

Latest design

@gonyeahialam I think we can mark this ticket as Resolved, since the preliminary design explorations are complete and the engineers are starting to develop the feature. If we have further iterations of the designs, they can be handled within the tickets for the engineering work or in separate tasks. Do you agree?

Latest design for Desktop and Mobile

In T361029#9839078, @ifried wrote:

@gonyeahialam I think we can mark this ticket as Resolved, since the preliminary design explorations are complete and the engineers are starting to develop the feature. If we have further iterations of the designs, they can be handled within the tickets for the engineering work or in separate tasks. Do you agree?

Yes