Does design approve of how the engineers will be changing the UI of the sections in the form?

• Engineering notes: Personally, I don't think we have a proposal. Instead, I'd like to know from design how should the section look like given what we can do. For reference, you can find an example of form with sections here (you need to have some pages from different namespaces in your watchlist to view it properly).

• Design answer: Having rectangles separating each section will make the UI look clogged up and more difficult for users to easily process the information on the page. I have two suggestions:
  • Use bold free text
  • Use sections but hide the rectangles and remove indentation

@Daimona @cmelo will this be feasible?

In T301692#7788569, @gonyeahialam wrote:

Does design approve of how the engineers will be changing the UI of the sections in the form?

• Engineering notes: Personally, I don't think we have a proposal. Instead, I'd like to know from design how should the section look like given what we can do. For reference, you can find an example of form with sections here (you need to have some pages from different namespaces in your watchlist to view it properly).

• Design answer: Having rectangles separating each section will make the UI look clogged up and more difficult for users to easily process the information on the page. I have two suggestions:
  • Use bold free text
  • Use sections but hide the rectangles and remove indentation

@Daimona @cmelo will this be feasible?

Yes, both are doable.

Do we need the "preview event page" feature for V0? (CC @ifried too)

• Engineering notes: This seems fairly hard to implement, especially the way it's presented in the prototype.

• Design answer: The Preview feature shows users what their event page is going to look like when they enable registrations, this helps them cross-check and confirm the information they entered. Preview is also important since Event Center is a new tool, users will be exploring this tool with curiosity, with questions and judgment on whether this will meet their needs and what it will look like. Giving them a glimpse of what it will look like and how it will meet their needs will motivate them to jump in with both feet confidently.

Since it is difficult to implement, it is okay to move it to V1. cc @ifried @cmelo @Daimona

In T301692#7788590, @Daimona wrote:

In T301692#7788569, @gonyeahialam wrote:

Does design approve of how the engineers will be changing the UI of the sections in the form?

• Engineering notes: Personally, I don't think we have a proposal. Instead, I'd like to know from design how should the section look like given what we can do. For reference, you can find an example of form with sections here (you need to have some pages from different namespaces in your watchlist to view it properly).

• Design answer: Having rectangles separating each section will make the UI look clogged up and more difficult for users to easily process the information on the page. I have two suggestions:
  • Use bold free text
  • Use sections but hide the rectangles and remove indentation

@Daimona @cmelo will this be feasible?

Yes, both are doable.

I guess we can go ahead and mark this as answered @ldelench_wmf

• Icons in the text fields (URL and address): are they important?
  • Engineering notes: This is currently not possible, but the needed core change should be relatively easy to write, so we can do that if design thinks this is important for V0.

• Design answer: Icons are especially important for the input fields that do not have labels on top (URL and Address). Icons will help convey visually what users are expected to input in addition to the placeholder text (which normally disappears once you start typing).

Since it isn't difficult to implement, I recommend we put it in V0. cc @Daimona @cmelo

In T301692#7788647, @gonyeahialam wrote:

• Icons in the text fields (URL and address): are they important?
  • Engineering notes: This is currently not possible, but the needed core change should be relatively easy to write, so we can do that if design thinks this is important for V0.

• Design answer: Icons are especially important for the input fields that do not have labels on top (URL and Address).

Note that these fields do have labels. I guess it may be possible to remove the labels, but I think that's bad for accessibility.

Radio button for event type: no empty state – is that ok? It will, by default, select the "first" radio button.

• Engineering notes: This behaviour may or may not be a bug. There's already a task for it: T207475. I don't think this can be fixed without a core/OOUI change.

• Design answer: Can you confirm if it is intentional or a bug? The description in the task you linked seems to suggest a bug. We can go ahead with selecting the first option as default pending whenever this is resolved or if we get negative user feedback from V0. If we are going with using Physical event as the default option then it should be made the first so users can easily notice it has been pre-selected when scanning the form. @Daimona @cmelo

In T301692#7788829, @gonyeahialam wrote:

• Design answer: Can you confirm if it is intentional or a bug? The description in the task you linked seems to suggest a bug. We can go ahead with selecting the first option as default pending whenever this is resolved or if we get negative user feedback from V0. If we are going with using Physical event as the default option then it should be made the first so users can easily notice it has been pre-selected when scanning the form. @Daimona @cmelo

It does look like a bug. At this point, my suggestion would be to do nothing and wait for it to be fixed.

Are we keeping date/time/timezone within the same field, or separate fields?

• Engineering notes: date+time in the same field would be preferred, because that's the widget that MW provides when you need both a date and a time, and is used consistently across the interface (whereas I couldn't find any usage of a time-only field). Also, a single field is slightly easier to handle on the backend, and it's less work for message translators.

Design answer: Time Input though a minor element can be a major frustration or drop-off point if not done well. A time input should clearly communicate that it is a time input, communicate the format(12/24HR, AM/PM), and how to interact with it without much effort or trial and error on the part of the user. In the suggested Time input above it is difficult to identify that there is a time input and what format it is in until after some trial and error.
There seem to be only a few places on-wiki that require users to input time. For a page like ours which will be getting much traffic, it is important the time picker is improved. 2 ideas I have in mind are:

• Separate the time from the date and let it have its own label. Remove the 'seconds' field, it is not needed in this use-case, and leaving it there makes the form more complex. If possible add a placeholder text like 23:00, this shows it is a time input and communicates the format.

• Alternatively, remove time from the date component and make use of the Combobox widget for time, it shows a drop-down of suggestions and still allows you to type freely. The dropdown will contain a list of times from 01:00 AM to 12:00 AM with 30 mins intervals. This idea meets the criteria for a good time input I mentioned above although may be less technically feasible than idea 1.

@Daimona @cmelo

In T301692#7789383, @Daimona wrote:

In T301692#7788829, @gonyeahialam wrote:

• Design answer: Can you confirm if it is intentional or a bug? The description in the task you linked seems to suggest a bug. We can go ahead with selecting the first option as default pending whenever this is resolved or if we get negative user feedback from V0. If we are going with using Physical event as the default option then it should be made the first so users can easily notice it has been pre-selected when scanning the form. @Daimona @cmelo

It does look like a bug. At this point, my suggestion would be to do nothing and wait for it to be fixed.

Okay.

@Daimona @ldelench_wmf Can we mark this as answered with the final decision as: Go ahead with selecting the first option as default pending whenever this is resolved (or if we get major negative user feedback in the future). If we are going with using Physical event as the default option then it should be made the first so users can easily notice it has been pre-selected when scanning the form.

Timezone fields: Is it okay if the organizer can only add time in UTC?

• Engineering notes: it may be possible to make the timezone customizable within the datetime field, but that's an OOUI core change. Alternatively, we can have a separate field for specifying a timezone, which would be easier to do but potentially less clear.

Timezone fields: how might we circumvent the “Z” (which is UTC)?

• Engineering notes: Unsure about the meaning of this question.

Design answer: In the design, the timezone that appears in the form is the timezone on their user account and not necessarily UTC. The goal of this is to make it clear to organizers the timezone that the time selected for their event is in and give them the ability to change it. This is important because Wiki uses the UTC timezone by default and you have to intentionally go to settings to change it to your timezone. I don't know if there is a more comprehensive timezone dropdown value set that has the time zone and location like this:

If there are major technical issues with the above solution, we can make the organizer only be able to add time in the default timezone of their account although not preferable based on the reasons stated above.

It is also important to show participants the timezone that the time of the event they want to attend is in since Wiki doesn't automatically detect the timezone of site visitors. This ensures participants don't erroneously assume that the time they are seeing is in their timezone. For logged-out participants, show the default timezone on-wiki. For logged-in participants show the timezone on their account.
@cmelo @Daimona

In T301692#7788656, @Daimona wrote:

In T301692#7788647, @gonyeahialam wrote:

• Icons in the text fields (URL and address): are they important?
  • Engineering notes: This is currently not possible, but the needed core change should be relatively easy to write, so we can do that if design thinks this is important for V0.

• Design answer: Icons are especially important for the input fields that do not have labels on top (URL and Address).

Note that these fields do have labels. I guess it may be possible to remove the labels, but I think that's bad for accessibility.

@gonyeahialam Could you please confirm that this is high priority even if the fields have labels?

In T301692#7789393, @gonyeahialam wrote:

Are we keeping date/time/timezone within the same field, or separate fields?

• Engineering notes: date+time in the same field would be preferred, because that's the widget that MW provides when you need both a date and a time, and is used consistently across the interface (whereas I couldn't find any usage of a time-only field). Also, a single field is slightly easier to handle on the backend, and it's less work for message translators.

Design answer: Time Input though a minor element can be a major frustration or drop-off point if not done well. A time input should clearly communicate that it is a time input, communicate the format(12/24HR, AM/PM), and how to interact with it without much effort or trial and error on the part of the user. In the suggested Time input above it is difficult to identify that there is a time input and what format it is in until after some trial and error.

I think these are valid concerns, but should not be addressed by us. If the datetime input field that we have has issues, they should be addressed within MediaWiki core so that everyone can benefit from those changes. Note, the widget in question is not part of the base OOUI library and I don't know what team owns it.

• Separate the time from the date and let it have its own label. Remove the 'seconds' field, it is not needed in this use-case, and leaving it there makes the form more complex. If possible add a placeholder text like 23:00, this shows it is a time input and communicates the format.

Removing the seconds is currently not possible. The placeholder should be there, but currently it doesn't seem to work; I've filed T304232.

• Alternatively, remove time from the date component and make use of the Combobox widget for time, it shows a drop-down of suggestions and still allows you to type freely. The dropdown will contain a list of times from 01:00 AM to 12:00 AM with 30 mins intervals. This idea meets the criteria for a good time input I mentioned above although may be less technically feasible than idea 1.

That might be doable but it's most certainly not straightforward and I'd rather improve the core widget per above.

In T301692#7789436, @gonyeahialam wrote:

Timezone fields: Is it okay if the organizer can only add time in UTC?

• Engineering notes: it may be possible to make the timezone customizable within the datetime field, but that's an OOUI core change. Alternatively, we can have a separate field for specifying a timezone, which would be easier to do but potentially less clear.

Timezone fields: how might we circumvent the “Z” (which is UTC)?

• Engineering notes: Unsure about the meaning of this question.

Design answer: In the design, the timezone that appears in the form is the timezone on their user account and not necessarily UTC.

Having a more sensible timezone default makes sense, I even filed T198403 a few years ago.

The goal of this is to make it clear to organizers the timezone that the time selected for their event is in and give them the ability to change it. This is important because Wiki uses the UTC timezone by default and you have to intentionally go to settings to change it to your timezone. I don't know if there is a more comprehensive timezone dropdown value set that has the time zone and location like this:
If not we can use the default on-wiki dropdown value-set under preferences on-wiki:

The only timezone input that I'm aware of is the one in the user preferences, and we would need to change the code a bit to make it reusable. Note that this holds true regardless of how we implement the date/time fields. The simplest alternative that I can think of is that in the datetime field currently used in the demo, we could replace the Z with UTC +0 where the +0 part is free-text (editable). Still a core change, but a simpler one.

It is also important to show participants the timezone that the time of the event they want to attend is in since Wiki doesn't automatically detect the timezone of site visitors. This ensures participants don't erroneously assume that the time they are seeing is in their timezone. For logged-out participants, show the default timezone on-wiki. For logged-in participants show the timezone on their account.

Yep, this was already planned at some engineering meeting and should be trivial to do.

In T301692#7788656, @Daimona wrote:

In T301692#7788647, @gonyeahialam wrote:

• Icons in the text fields (URL and address): are they important?
  • Engineering notes: This is currently not possible, but the needed core change should be relatively easy to write, so we can do that if design thinks this is important for V0.

• Design answer: Icons are especially important for the input fields that do not have labels on top (URL and Address).

Note that these fields do have labels. I guess it may be possible to remove the labels, but I think that's bad for accessibility.

Adding labels on top makes the URL and/or address look like separate questions on their own, it doesn't show that they are under the Location radio buttons and change depending on which option is selected. Adding the label this way will even be more confusing in mobile where the radio buttons will be vertically stacked instead of horizontally as shown in desktop

@Daimona Tackling this can be moved to V1 if it is a technical challenge. We also need to have an additional discussion on how you intend to handle the address input.

In T301692#7793143, @gonyeahialam wrote:

Adding labels on top makes the URL and/or address look like separate questions on their own, it doesn't show that they are under the Location radio buttons and change depending on which option is selected. Adding the label this way will even be more confusing in mobile where the radio buttons will be vertically stacked instead of horizontally as shown in desktop

Would form sections mitigate this, by making it clearer that the text fields depend on the radio?

For accessibility, the label of a text input can be hidden if there is enough context around it. In this case, we have the Location section title, the radio button title (e.g Online event), the icon, and placeholder text which gives context to it in absence of the label. Also, the label is only hidden visually but hidden in a way that it is still captured by screen readers, text to speech, and other assistive technology https://www.w3.org/WAI/tutorials/forms/labels/#note-on-hiding-elements.

@Daimona Tackling this can be moved to V1 if it is a technical challenge. We also need to have an additional discussion on how you intend to handle the address input.

Screen readers were not my only concern re accessibility; the combination of semi-hidden labels and icons may (or may not) be enough to mitigate the accessibility issues, but I think perhaps it could be considered for V1 then? It would be much easier if this could be resolved by keeping the labels and using form sections to clarify which fields are related.

In T301692#7788656, @Daimona wrote:

In T301692#7788647, @gonyeahialam wrote:

• Icons in the text fields (URL and address): are they important?
  • Engineering notes: This is currently not possible, but the needed core change should be relatively easy to write, so we can do that if design thinks this is important for V0.

• Design answer: Icons are especially important for the input fields that do not have labels on top (URL and Address).

Note that these fields do have labels. I guess it may be possible to remove the labels, but I think that's bad for accessibility.

I think we should maintain the labels too, I agree that removing the labels is bad for accessibility.

In T301692#7794946, @cmelo wrote:

In T301692#7788656, @Daimona wrote:

In T301692#7788647, @gonyeahialam wrote:

• Icons in the text fields (URL and address): are they important?
  • Engineering notes: This is currently not possible, but the needed core change should be relatively easy to write, so we can do that if design thinks this is important for V0.

• Design answer: Icons are especially important for the input fields that do not have labels on top (URL and Address).

Note that these fields do have labels. I guess it may be possible to remove the labels, but I think that's bad for accessibility.

I think we should maintain the labels too, I agree that removing the labels is bad for accessibility.

@cmelo @Daimona Let us keep the labels and add the icons.

@gonyeahialam One more question about the "infobox" that appears on event pages (this one). How should it look like when the address is very long? I assume some real addressed will be much longer than "NGHub" and I'd like to get an idea of what the layout would be in that case.

In T301692#7797849, @Daimona wrote:

@gonyeahialam One more question about the "infobox" that appears on event pages (this one). How should it look like when the address is very long? I assume some real addressed will be much longer than "NGHub" and I'd like to get an idea of what the layout would be in that case.

Also: if the user does not have JavaScript enabled we cannot show a modal when they click on "More details". What should happen then? My proposals:

1. By default, the "more details" button would be hidden and the infobox would contain more information already visible. If JS is enabled, we hide that information and show the button instead.
2. By default "More details" would be a normal link to another page (which one?) with info about the event. If JS is enabled, we change the link into a button that opens a modal.

I prefer (2.) but I'm not sure which page we should link to. At some point we will need to have pages with info about a specific event (e.g., when we implement the agenda, you would click on an event and you're sent to that page), but I don't think I've seen it in the wireframes for V0, right?

In T301692#7797849, @Daimona wrote:

@gonyeahialam One more question about the "infobox" that appears on event pages (this one). How should it look like when the address is very long? I assume some real addressed will be much longer than "NGHub" and I'd like to get an idea of what the layout would be in that case.

I will get back to you on this

In T301692#7789393, @gonyeahialam wrote:

Are we keeping date/time/timezone within the same field, or separate fields?

• Engineering notes: date+time in the same field would be preferred, because that's the widget that MW provides when you need both a date and a time, and is used consistently across the interface (whereas I couldn't find any usage of a time-only field). Also, a single field is slightly easier to handle on the backend, and it's less work for message translators.

Design answer: Time Input though a minor element can be a major frustration or drop-off point if not done well. A time input should clearly communicate that it is a time input, communicate the format(12/24HR, AM/PM), and how to interact with it without much effort or trial and error on the part of the user. In the suggested Time input above it is difficult to identify that there is a time input and what format it is in until after some trial and error.

I think these are valid concerns, but should not be addressed by us. If the datetime input field that we have has issues, they should be addressed within MediaWiki core so that everyone can benefit from those changes. Note, the widget in question is not part of the base OOUI library and I don't know what team owns it.

• Separate the time from the date and let it have its own label. Remove the 'seconds' field, it is not needed in this use-case, and leaving it there makes the form more complex. If possible add a placeholder text like 23:00, this shows it is a time input and communicates the format.

Removing the seconds is currently not possible. The placeholder should be there, but currently it doesn't seem to work; I've filed T304232.

• Alternatively, remove time from the date component and make use of the Combobox widget for time, it shows a drop-down of suggestions and still allows you to type freely. The dropdown will contain a list of times from 01:00 AM to 12:00 AM with 30 mins intervals. This idea meets the criteria for a good time input I mentioned above although may be less technically feasible than idea 1.

That might be doable but it's most certainly not straightforward and I'd rather improve the core widget per above.

@Daimona Since it is currently not possible to remove the seconds and the placeholders are not working, for this version can we at least separate time from the date so it is a bit more understandable while we await changes to the core widget.

Do we need to change the special change the special page text to be something like event center?

• Engineering notes: This is doable with a hack but I'd recommend against that. Namespace tabs are there for a reason, and they appear on every page of the site. Hijacking their content seems inconsistent with the experience that user gets everywhere else. If we need a navigation menu, we can add that separately. In general, if we need more elements, we can add them. But changing the nstab sounds wrong to me.

• Design answer: To make the decision on whether to add the special page title we need to ask questions like:
  1. What was the goal of having the special page title on every special page?
  2. What problem does it solve?