@ifried I'm still not 100% convinced about T317708#8288897. Maybe we could talk about it next week?

@Daimona Sure. You're referring to how the URL should/should not be entered, right? I'm flexible to various options on this. We can discuss it next week. We can also talk about it during estimation today, if you would like.

In T317708#8290490, @ifried wrote:

@Daimona Sure. You're referring to how the URL should/should not be entered, right? I'm flexible to various options on this. We can discuss it next week. We can also talk about it during estimation today, if you would like.

Yes, because we don't really need the URL, but only the event identifier (which should be the last part of the URL). And yeah, definitely open to talking about this today!

@gonyeahialam can you add the updated images/wireframe examples? thanks!

If the UI in the task description would be difficult to implement here is an alternative version

On hover:

Link to Design specs

Estimated asynchronously.

In T317708#8294084, @gonyeahialam wrote:

If the UI in the task description would be difficult to implement here is an alternative version

On hover:

Link to Design specs

Thanks @gonyeahialam, we decide to use the alternative version, I will update the acceptance criteria.

Question: as per T320434#8741708, we will need to show when the tool was last synchronized, and whether it completed successfully. Is this something we should show near the form field, or do we only need to show it elsewhere (see T334142)?

A few notes on the prototype given what we learned and decided since October '22:

• Organizers would not be entering the course URL, but rather the course slug (shown in the management interface of the course); I think this would be a simple wording change.
• The AC say «Tooltip text should read: "Usernames of publicly registered participants are automatically sent to the tracking tool link specified."», but that's not consistent with the prototype below, where this text is shown below the field. I would like to confirm that we want both the tooltip and the info text below, and update the AC accordingly (or that the AC are actually correct, and then the difference with the prototype should be pointed out in the task description)
• We would also have to show two additional pieces of information, as per T320434#8760793 and previous comment: the date & time of the last synchronization with the tool, and, if the last update failed, a warning notice informing the organizer that the tool is not in sync with the event. We do not have prototypes for these AFAIK. We may also decide to put this information elsewhere depending on our decision on T334142.
• As described in T331940, we need to inform organizers that private participants are not synced with the dashboard. Maybe we could just modify the info text to say "Usernames of publicly registered participants..."?

In T317708#8866064, @Daimona wrote:

A few notes on the prototype given what we learned and decided since October '22:

• Organizers would not be entering the course URL, but rather the course slug (shown in the management interface of the course); I think this would be a simple wording change.

Can you share a screenshot or describe how to access the course slug?
Why is the slug being used instead of the URL?

• The AC say «Tooltip text should read: "Usernames of publicly registered participants are automatically sent to the tracking tool link specified."», but that's not consistent with the prototype below, where this text is shown below the field. I would like to confirm that we want both the tooltip and the info text below, and update the AC accordingly (or that the AC are actually correct, and then the difference with the prototype should be pointed out in the task description)

Is the course slug a link?

• We would also have to show two additional pieces of information, as per T320434#8760793 and previous comment: the date & time of the last synchronization with the tool, and, if the last update failed, a warning notice informing the organizer that the tool is not in sync with the event. We do not have prototypes for these AFAIK. We may also decide to put this information elsewhere depending on our decision on T334142.

Why do we need to show this information to the organiser?
We probably need to show it at a more visible place such as event details or the participants list.

• As described in T331940, we need to inform organizers that private participants are not synced with the dashboard. Maybe we could just modify the info text to say "Usernames of publicly registered participants..."?

I wonder what would be the organizer's reaction to this. The information on the dashboard helps them monitor contributions and measure the impact of their event.

In T317708#8882730, @gonyeahialam wrote:

In T317708#8866064, @Daimona wrote:

• Organizers would not be entering the course URL, but rather the course slug (shown in the management interface of the course); I think this would be a simple wording change.

Can you share a screenshot or describe how to access the course slug?

I'm sure I saw it in the interface when I was testing it the other day, it's in a box on the right. However, I'm no longer able to find it; probably just because I'm not very familiar with the dashboard. @Ragesoss Could you help us with this? Also, the slug can always be copied from the URL, so for instance if the URL of the course is https://dashboard-testing.wikiedu.org/courses/Daimona/Test1, the course slug will be Daimona/Test1.

Why is the slug being used instead of the URL?

That's something I remember discussing in a meeting a few months ago, but apparently this was not recorded on phab. In short, it's because we aren't really using the URL, only the slug, and the fact that the base URL of the dashboard is determined in the site configuration, and it's not something users can change.

• The AC say «Tooltip text should read: "Usernames of publicly registered participants are automatically sent to the tracking tool link specified."», but that's not consistent with the prototype below, where this text is shown below the field. I would like to confirm that we want both the tooltip and the info text below, and update the AC accordingly (or that the AC are actually correct, and then the difference with the prototype should be pointed out in the task description)

Is the course slug a link?

No, it's just a string made of (name of institution) + (name of the course), as shown above.

• We would also have to show two additional pieces of information, as per T320434#8760793 and previous comment: the date & time of the last synchronization with the tool, and, if the last update failed, a warning notice informing the organizer that the tool is not in sync with the event. We do not have prototypes for these AFAIK. We may also decide to put this information elsewhere depending on our decision on T334142.

Why do we need to show this information to the organiser?

Because otherwise they would have no way to know if the syncing with a tool is (still) working or not.

We probably need to show it at a more visible place such as event details or the participants list.

Yup, and that's also kind of what T334142 aims to define.

• As described in T331940, we need to inform organizers that private participants are not synced with the dashboard. Maybe we could just modify the info text to say "Usernames of publicly registered participants..."?

I wonder what would be the organizer's reaction to this. The information on the dashboard helps them monitor contributions and measure the impact of their event.

That's correct, but private participants cannot be synchronized, else their usernames will become available to the public. This is something we decided a few months ago with Ilana, and there isn't much we can change about this, so we decided that providing an accurate explanation of this fact would be sufficient.

I think this will be a lot easier for organizers if it can accept either a course slug or a URL. There's no obvious way to get the slug except by cutting it of the URL, but the pattern should be easy to handle; it's just [domain]/courses/[slug] or [domain]/courses/[slug]/home.

Decisions from today's engineering + design meeting:

• Organizers would not be entering the course URL, but rather the course slug (shown in the management interface of the course); I think this would be a simple wording change.

The form field will accept the course URL and extract the slug from it, with proper error handling (e.g., in case of mismatching URLs).

• The AC say «Tooltip text should read: "Usernames of publicly registered participants are automatically sent to the tracking tool link specified."», but that's not consistent with the prototype below, where this text is shown below the field. I would like to confirm that we want both the tooltip and the info text below, and update the AC accordingly (or that the AC are actually correct, and then the difference with the prototype should be pointed out in the task description)

@gonyeahialam to review this again and provide updated prototype.

• We would also have to show two additional pieces of information, as per T320434#8760793 and previous comment: the date & time of the last synchronization with the tool, and, if the last update failed, a warning notice informing the organizer that the tool is not in sync with the event. We do not have prototypes for these AFAIK. We may also decide to put this information elsewhere depending on our decision on T334142.

We will show this information somewhere; either here, in EventDetails, or both. @gonyeahialam to review these options and provide updated prototypes.

• As described in T331940, we need to inform organizers that private participants are not synced with the dashboard. Maybe we could just modify the info text to say "Usernames of publicly registered participants..."?

Yes, changing the help text like that is what we will do.

Design update:
Design spec

@Daimona

In T317708#8903072, @gonyeahialam wrote:

Design update:
Design spec

Thank you, a few notes about the updated prototypes:

• No other field has the "(optional)" label, including the chat group link shown in the prototypes. Can it be removed? We generally do the opposite, i.e. mark required fields with an asterisk icon (ex).
• As previously decided (T317708#8893233), the label should read "Usernames of publicly registered participants ..."
• In the prototype, we have a help text below the field and one in a tooltip. As previously mentioned, this is not supported by the form-building core logic. We can have either an inline help text (in grey, smaller font below the field, like for the "organizers" field in the registration form), or a popup help text (appears when clicking a button with the info icon, like for the "event page" and "group chat invite" fields in the registration form). However, these options are mutually exclusive; we can decide where the help is displayed, but there can only be a single help text. AFAICS, the closest thing we can do is add an OOUI notice after the field, but it'll look like this, which is not quite what we want:

• No other field has the "(optional)" label, including the chat group link shown in the prototypes. Can it be removed? We generally do the opposite, i.e. mark required fields with an asterisk icon (ex).

I would get back to you on this.

• As previously decided (T317708#8893233), the label should read "Usernames of publicly registered participants ..."
• In the prototype, we have a help text below the field and one in a tooltip. As previously mentioned, this is not supported by the form-building core logic. We can have either an inline help text (in grey, smaller font below the field, like for the "organizers" field in the registration form), or a popup help text (appears when clicking a button with the info icon, like for the "event page" and "group chat invite" fields in the registration form). However, these options are mutually exclusive; we can decide where the help is displayed, but there can only be a single help text. AFAICS, the closest thing we can do is add an OOUI notice after the field, but it'll look like this, which is not quite what we want:

We can remove the tooltip, I have modified the helper text to contain the key information in the tooltip @Daimona

@gonyeahialam What should the error message be if the URL isn't valid? This could happen due to a variety of reasons, such as:

• URL points to a site that is not a WikiEdu Dashboard
• URL points to an instance of the WikiEdu Dashboard that we don't support
• URL points to the right site but it doesn't have a tool ID in it
• URL is otherwise lacking some pieces of data

In case it help, we're able to provide the user with a template for what the URL should look like, so that the message would be something like:

The URL should be like this: https://dashboard-testing.wikiedu.org/courses/Institution/CourseName

where "Organizer" and "CourseName" are not literals, but would have to be replaced with the specific values for each course. However, I'm not sure if this would be clear enough, and how to make it simpler for organizers to understand.

In T317708#8939319, @Daimona wrote:

@gonyeahialam What should the error message be if the URL isn't valid? This could happen due to a variety of reasons, such as:

• URL points to a site that is not a WikiEdu Dashboard
• URL points to an instance of the WikiEdu Dashboard that we don't support
• URL points to the right site but it doesn't have a tool ID in it
• URL is otherwise lacking some pieces of data

When the URL isn't valid, is the system able to detect which of the above reasons caused it?

In T317708#8945887, @gonyeahialam wrote:

In T317708#8939319, @Daimona wrote:

@gonyeahialam What should the error message be if the URL isn't valid? This could happen due to a variety of reasons, such as:

• URL points to a site that is not a WikiEdu Dashboard
• URL points to an instance of the WikiEdu Dashboard that we don't support
• URL points to the right site but it doesn't have a tool ID in it
• URL is otherwise lacking some pieces of data

When the URL isn't valid, is the system able to detect which of the above reasons caused it?

In part, yes, but if we don't recognize the URL there's no way to tell if the site is a Dashboard instance or not. In particular, the value is rejected if one of the following conditions is met:

• The value is not a URL (but rather some random gibberish); this shouldn't really happen though, as the browser's built-in validation should make sure that the value is at least a valid URL.
• The wrong URL protocol is used, i.e., not HTTP or HTTPS
• URL points to a site other than the configured Dashboard instance
• URL points to the homepage of the configured Dashboard instance (and not to a specific course)
• URL points to the configured Dashboard instance, but not to the page of a specific course

But I guess these might be too technical for the average user.

@Daimona can this validation happen inline or does the user need to submit before validating the URL?

In T317708#8946512, @gonyeahialam wrote:

@Daimona can this validation happen inline or does the user need to submit before validating the URL?

The validation will happen when the form is submitted. Doing it inline would, on its own, be probably more complex than this task as a whole.

What do you think about this error message @Daimona:

It seems like the URL you've entered might not be complete or in the correct format. Your URL should look like this:

• https://dashboard.wikiedu.org/courses/[Institution Name]/[Course Name]
• https://outreachdashboard.wmflabs.org/courses/[Institution Name]/[Program Title]

For instance: https://outreachdashboard.wmflabs.org/courses/Tochiprecious/SheSaid_Nigeria_2021
Could you please double-check your URL and try again?

(Personally I always feel a bit not taken seriously when reading longer error messages with questions, instead of direct instructions like The provided URL could not be set. The URL should have the following format: [...] Please check the URL and try again. Might be just me though.)

We discussed this today, the key discussion points were:

• Only one Dashboard URL will be supported, so there should be a single example
• We should probably use a fake course for the example, as to remain neutral and avoid linking to real events by real people
• The message should be shorter and more direct, if possible (basically what @Aklapper said above)
• I wondered if using square brackets (or any other symbol really) to mark the parts of the URL that need to be replaced could potentially be confusing (i.e., if it was sufficiently clear that the symbols should not be part of the final URL). We agreed that the presence of an explicit example link should help with this

My understanding is that @gonyeahialam is working on an updated copy incorporating these suggestions, right?

Here is an updated format message @Daimona, you mentioned you would create the fake program on the Dashboard to replace the example below:

The provided URL is not in the correct format. Your URL should be in this format:
https://outreachdashboard.wmflabs.org/courses/[Institution Name]/[Program Title]
E.g. https://outreachdashboard.wmflabs.org/courses/Tochiprecious/SheSaid_Nigeria_2021

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

[mediawiki/extensions/CampaignEvents@master] Add fields to the registration form for tracking tools

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

Change 930213 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add fields to the registration form for tracking tools

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

Organizers can add tracking tools to an event from

✅ Special:EnableEventRegistration
{F37123642}

✅ and Special:EditEventRegistration

🚫 Though I have found that these do not always add all of the participants of an event, even if publicly registered and haven't yet been able to figure out why. Here is one example where I edited an event that didn't previously have a tracking link, and only two of the three participants were correctly conveyed over to the P and E dashboard:
{F37123664}

🚫 **Label should be "Programs and Events Dashboard link"**
AC: Programs and Events Dashboard link
Current build: Programs & Events Dashboard link - need to either update the AC or just change & to and in the build

✅ There should be a text field for entering the URL of the course
✅ Help text should read: "Usernames of publicly registered participants would be automatically sent to the Dashboard. This tool helps you monitor their contributions and measure the impact of your campaign event.

🚫 text should have a link appended to it, with the text "Learn more" and the URL: https://meta.wikimedia.org/wiki/Special:MyLanguage/Programs%20&%20Events%20Dashboard
AC link: https://meta.wikimedia.org/wiki/Special:MyLanguage/Programs%20&%20Events%20Dashboard
Link in build: https://meta.wikimedia.org/wiki/Special:MyLanguage/Programs_%26_Events_Dashboard
These go to the same place though - I am not sure if there is a functional difference at all in these links? It either needs updated or the AC needs changed.

A couple of small notes on the error message, the formatting breaks down at smaller break points:

@gonyeahialam @Daimona Should we wrap this line so it breaks where the form fields end on larger break points?

@gonyeahialam did we determine if the (Optional) should be there or not for the text field?

In T317708#8979600, @vaughnwalters wrote:

🚫 Though I have found that these do not always add all of the participants of an event, even if publicly registered and haven't yet been able to figure out why. Here is one example where I edited an event that didn't previously have a tracking link, and only two of the three participants were correctly conveyed over to the P and E dashboard:
{F37123664}

I'm unable to see this file (I think you may have to attach it to the task or sth), but I'm assuming it's similar to F37123707. One thing to keep in mind (that I forgot to mention explicitly) is that we're actually tricking the Dashboard into thinking we're calling it from a Wikimedia wikis. When you pass it a username, it thinks that it's a real username used by someone in Wikimedia wikis. That is not the case though, because these are just usernames in your local. A consequence of this is that you can have a username which exists locally, but not in Wikimedia wikis, like Vtest in your example. If a user doesn't exist, it won't be synced in the dashboard. Note that this won't happen in production, because a user can only register for an event (and thus be synced with the dashboard) if they actually have an account.

🚫 **Label should be "Programs and Events Dashboard link"**
AC: Programs and Events Dashboard link
Current build: Programs & Events Dashboard link - need to either update the AC or just change & to and in the build

Same as T318828#8980560.

🚫 text should have a link appended to it, with the text "Learn more" and the URL: https://meta.wikimedia.org/wiki/Special:MyLanguage/Programs%20&%20Events%20Dashboard
AC link: https://meta.wikimedia.org/wiki/Special:MyLanguage/Programs%20&%20Events%20Dashboard
Link in build: https://meta.wikimedia.org/wiki/Special:MyLanguage/Programs_%26_Events_Dashboard
These go to the same place though - I am not sure if there is a functional difference at all in these links? It either needs updated or the AC needs changed.

I'll update the AC, the one with underscores is the canonical URL format.

A couple of small notes on the error message, the formatting breaks down at smaller break points:

Hmmm that's a consequence of having a long-ish URL in there. I'm unsure what the best solution would be here.

@gonyeahialam @Daimona Should we wrap this line so it breaks where the form fields end on larger break points?

Good point! Maybe? But that would have to be implemented in core, so if we want to do that, I'll file a task against MediaWiki-HTMLForm

@gonyeahialam did we determine if the (Optional) should be there or not for the text field?

I'll let Gregory give you a full answer, but I remember discussing this. In short, we generally don't put "(optional)" in the labels of optional form fields; instead, we mark the fields that are required (e.g., with the asterisk icon inside the field, see timezone field). Also, no other optional field in this form says "optional" (e.g., meeting URL, chat link).

In T317708#8980659, @Daimona wrote:

In T317708#8979600, @vaughnwalters wrote:

Though I have found that these do not always add all of the participants of an event, even if publicly registered and haven't yet been able to figure out why. Here is one example where I edited an event that didn't previously have a tracking link, and only two of the three participants were correctly conveyed over to the P and E dashboard:
{F37123664}

I'm unable to see this file (I think you may have to attach it to the task or sth), but I'm assuming it's similar to F37123707. One thing to keep in mind (that I forgot to mention explicitly) is that we're actually tricking the Dashboard into thinking we're calling it from a Wikimedia wikis. When you pass it a username, it thinks that it's a real username used by someone in Wikimedia wikis. That is not the case though, because these are just usernames in your local. A consequence of this is that you can have a username which exists locally, but not in Wikimedia wikis, like Vtest in your example. If a user doesn't exist, it won't be synced in the dashboard. Note that this won't happen in production, because a user can only register for an event (and thus be synced with the dashboard) if they actually have an account.

✅ Ah, this is the case. This makes sense, I just didn't realize how it was working on local.

Label should be "Programs and Events Dashboard link"

AC: Programs and Events Dashboard link
Current build: Programs & Events Dashboard link - need to either update the AC or just change & to and in the build

Same as T318828#8980560.

✅ Confirmed that it should be Programs & Events Dashboard link - I updated the AC to reflect this.

I'm sending this to design sign off with a few remaining questions for @gonyeahialam if you have thoughts on how we should address the following, and we can create new tasks for those if necessary. Including @Daimona's responses to my notes as well.

A couple of small notes on the error message, the formatting breaks down at smaller break points:

Hmmm that's a consequence of having a long-ish URL in there. I'm unsure what the best solution would be here.

@gonyeahialam @Daimona Should we wrap this line so it breaks where the form fields end on larger break points?

Good point! Maybe? But that would have to be implemented in core, so if we want to do that, I'll file a task against MediaWiki-HTMLForm

@gonyeahialam did we determine if the (Optional) should be there or not for the text field?

I'll let Gregory give you a full answer, but I remember discussing this. In short, we generally don't put "(optional)" in the labels of optional form fields; instead, we mark the fields that are required (e.g., with the asterisk icon inside the field, see timezone field). Also, no other optional field in this form says "optional" (e.g., meeting URL, chat link).

@vaughnwalters @Daimona

In T317708#8983279, @vaughnwalters wrote:

A couple of small notes on the error message, the formatting breaks down at smaller break points:

Hmmm that's a consequence of having a long-ish URL in there. I'm unsure what the best solution would be here.

Why do the other texts wrap except for the URL? What would happen on mobile web?

@gonyeahialam @Daimona Should we wrap this line so it breaks where the form fields end on larger break points?

Good point! Maybe? But that would have to be implemented in the core, so if we want to do that, I'll file a task against MediaWiki-HTMLForm

Yes, it should break where the form field ends and not extend the length of the page.
@Daimona how is it implemented in the account creation page

@gonyeahialam did we determine if the (Optional) should be there or not for the text field?

I'll let Gregory give you a full answer, but I remember discussing this. In short, we generally don't put "(optional)" in the labels of optional form fields; instead, we mark the fields that are required (e.g., with the asterisk icon inside the field, see timezone field). Also, no other optional field in this form says "optional" (e.g., meeting URL, chat link).

@vaughnwalters the optional text can be removed for this.

In T317708#8984869, @gonyeahialam wrote:

@vaughnwalters @Daimona

In T317708#8983279, @vaughnwalters wrote:

A couple of small notes on the error message, the formatting breaks down at smaller break points:

Hmmm that's a consequence of having a long-ish URL in there. I'm unsure what the best solution would be here.

Why do the other texts wrap except for the URL? What would happen on mobile web?

Because the URL has not spaces in it, and therefore no place where it can be wrapped automatically (unless we force it). On mobile it looks good for some reason.

@gonyeahialam @Daimona Should we wrap this line so it breaks where the form fields end on larger break points?

Good point! Maybe? But that would have to be implemented in the core, so if we want to do that, I'll file a task against MediaWiki-HTMLForm

Yes, it should break where the form field ends and not extend the length of the page.

T340973: HTMLForm help text should have a max-width

@Daimona how is it implemented in the account creation page

Those are not help texts, they're just stray paragraphs between form fields that are not attached to any specific field.

A couple of small notes on the error message, the formatting breaks down at smaller break points:

Hmmm that's a consequence of having a long-ish URL in there. I'm unsure what the best solution would be here.

Why do the other texts wrap except for the URL? What would happen on mobile web?

Because the URL has not spaces in it, and therefore no place where it can be wrapped automatically (unless we force it). On mobile it looks good for some reason.

@vaughnwalters how did you get this error? Did you decrease the width of the browser? @Daimona should we file a task for this?

In T317708#8989764, @gonyeahialam wrote:

@vaughnwalters how did you get this error? Did you decrease the width of the browser?

Yes, this can be reproduced by resizing the browser window.

@Daimona should we file a task for this?

T341130