search

CoderDojo / community-platform

Zen, the CoderDojo Community Platform!
https://zen.coderdojo.com
MIT License
121 stars 55 forks source link

Simplification and rebuild of "Create Event" form #1230

Closed conoramurphy-zz closed 4 years ago

conoramurphy-zz commented 5 years ago

Business Value Since 90% of user events are very simple 1 ticket type events. Our create event form should prioritise that, and allow some minor complexity as a secondary option

To-Do

Blogpost for launch https://coderdojo.com/?p=17691 (flag with Nuala)

Launched 2019-08-08 13:39:55.004+00

To monitor Old vs new events usage. support. 404 etc?

Designs https://share.goabstract.com/55e46582-889a-4085-bca6-82be52bf1afb

create create2

Linked Issues

Wardormeur commented 5 years ago

Question from Slack: Design for the date: datepicker vs 3 number fields ? Design for the hours: hourpicker vs 2 number fields ? What are the default values for the options from the current create event form? (notify on applicant and such)

Wardormeur commented 5 years ago

From https://github.com/CoderDojo/community-platform/issues/1259#issue-433321614, can you confirm that "Any unexpected ticket (coming from the old event UI) should be resetted to the 2 default ones" ?

conoramurphy-zz commented 5 years ago

Design for the date: datepicker vs 3 number fields ?

I don't really mind here. Are you saying 3 number fields is better or 3 number fields is easier (both valid)

Design for the hours: hourpicker vs 2 number fields ?

Same as above. Which do you rather and why. I just went with common styles used in google calendar.

From #1259 (comment), can you confirm that "Any unexpected ticket (coming from the old event UI) should be resetted to the 2 default ones" ?

Asked for clarification on that ticket

Wardormeur commented 5 years ago

Number fields are annoying for international, because of the ordering. However, date pickers are a generally hated component when it comes to UX. Same for time, annoying due to PM/AM only being an english thing. Thoughts @DanielBrierton ?

conoramurphy-zz commented 5 years ago

Talked about in Slack. Particularly gregwood confirmed that

date pickers (calendar dropdown type things) are dead annoying, inaccessible, hard to use on a phone, etc three fields for day, month and year are way easier to use. the month should be the names, not numbers maybe consider separating the Event date label heading into two: Event date and Event time

So I'll take another run at a version of the wireframe tomorrow.

Wardormeur commented 5 years ago

Bump on

What are the default values for the options from the current create event form? (notify on applicant, ticket approval, public event)

conoramurphy-zz commented 5 years ago

Make sense?

Wardormeur commented 5 years ago

We've looked into the librairies, and it seems that https://chronotruck.github.io/vue-ctk-date-time-picker/ is a decent solution if we're going the library way. My only issue with normal html fields comes down to handling PM/AM for time, and offering an experience which ease the input. Another alternative is the support of the native datepicker, but the support is not extroardinary (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local)

conoramurphy-zz commented 5 years ago

Screenshot 2019-05-01 at 14 32 04

This is basically what I'm thinking. A seperate date selector (as it's a single date not a range), and a time range selector. Does this work with the above library. Splitting them

Wardormeur commented 5 years ago

Natives splitting are documented here : https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date That might be an issue since native input for date/time don't work on IE. We can validate it, but that'll be an issue presenting the error message.

For vue-ctk-date-time-picker, the example for both scenario are displayed on the exact link I sent on the previous message. In the end, this doesn't describe the issue I'm facing @conoramurphy : what are we expecting the user to do with those inputs? Are they supposed to

conoramurphy-zz commented 5 years ago

The lack of Safari support would be more a blocker for native for me.

For the library can you point me to where that does a time range picker by itself? The ones I see are either range, or a time picker and the visual customiser blocks having both those options on at the same time.

Ideally the calendar picker would be

click day based on a visual calendar.

But I'm not overly opinionated here once it's clean and we're not making them do anything they shouldn't need to.

Wardormeur commented 5 years ago

Apologies, I didn't understand you wanted a time-range picker. This doesn't exists, not in native, not in this lib either. It's going to be 2 fields in both scenario.

conoramurphy-zz commented 5 years ago

Ok, then I'm happy with trying three different inputs. A [Calendar picker] [Start time picker] to [End time picker]

conoramurphy-zz commented 4 years ago

It's observed as working. Waiting until the end of August for monitoring results.

conoramurphy-zz commented 4 years ago

Statistical review Overall: event usage is up around 80% on last year, pre form launch it was up 30% oin last year month to month. 72.3% of events created on Zen post launch are with the new form. However of that 27.7% using the old form around 66% could be using the new form. Leaving 91% of events accounted for functionally with the new form.

The percentage of new clubs using events has gone up nearly 10% (depending on how you calculate it).

Review of the non-converted Out of the last 50 events created using the old form (all of these are in October). 67% do not need any special features. Possible reasons they used the old form are... translation issues, curiosity etc.

TBD