Page MenuHomePhabricator

Add support for start/end times in Programs Dashboard
Closed, ResolvedPublic8 Estimated Story Points

Description

Right now, the dashboard does not have a start or end time. We need to be able to have start and end times:

  • displayed for participants on the dashboard
  • displayed in the on wiki event page
  • and in the system to calculate the metrics at the top of the course page.

Current state:

Wireframe with time and time zone:

Event Timeline

Abit created this task.Feb 2 2016, 6:07 PM
Abit raised the priority of this task from to Needs Triage.
Abit updated the task description. (Show Details)
Abit moved this task to Backlog on the Education-Program-Dashboard board.
Abit added a subscriber: Abit.
Restricted Application added subscribers: StudiesWorld, Base, Aklapper. · View Herald TranscriptFeb 2 2016, 6:07 PM
Abit renamed this task from Allow program to be only 1 day log and include start/end times {add} to Allow program to be only 1 day log and include start/end times {add} {mvp}.Feb 2 2016, 6:08 PM
Abit set Security to None.
Abit renamed this task from Allow program to be only 1 day log and include start/end times {add} {mvp} to Allow program to be only 1 day log and include start/end times {ax} {mvp}.Feb 2 2016, 6:23 PM
Abit renamed this task from Allow program to be only 1 day log and include start/end times {ax} {mvp} to Allow program to be only 1 day long and include start/end times {ax} {mvp}.Feb 3 2016, 7:17 PM

A couple of notes:

  • The only reason it won't let you have a one-day project is because of front-end validation, which at some points tries to enforce a minimum of 1 week. I don't think that's necessary for Wiki Ed's purposes any longer, because of other changes in the course creation flow that make it unlikely for users to simply skip setting dates altogether (and end up with a course that starts and ends on the day it was created).
  • The date handling — for the calendar widget as well as the calculations of which days a course meets — has some bugs related to courses that start and end the same date, which I just noticed when trying this out. (It's possible to set the dates like that after the course is initially created.) I'll file those when I get a chance. In general, our front-end date handling is pretty messy — and also relatively expensive, in terms of javascript processing. There's a lot of room for improvement in how the dashboard frontend does date-related calcuations.
  • There are no major blockers to making the metrics limit calculations to a datetime range (instead of just a date range, as now). But, do we really want to limit metrics calculations to (for example) the five hour window between the start and end of an event, and not count anything participants do the rest of the day? Is that how programs currently report outputs for things like an Edit-A-Thon?
Abit added a comment.Feb 12 2016, 5:20 PM

But, do we really want to limit metrics calculations to (for example) the five hour window between the start and end of an event, and not count anything participants do the rest of the day? Is that how programs currently report outputs for things like an Edit-A-Thon?

It is how we ask that global metrics are calculated (for an editathon or any other program). This also becomes a bigger issue in writing contests, which can be cutthroat up to the deadline, and judging could be messed up if submissions after the deadline are included.

I know that the WMF puts pressure on groups to wrap up events within a day but I do not think this is a thoughtful way of measuring impact or an idea with community support.

The reason for the date tracking is a desire to prove a relationship between event funding and event impact. Right now, I do not believe that enough events are funded to justify trying to establish a workflow around establishing diligence in giving event grants. It is almost certainly true that more money is invested in reviewing events than actually having events, and until it happens that the money spent on direct impact exceeds money spent on administration, it is hard for me to understand why the natural workflow ought to be impeded or restricted for the sake of understanding budgets on the scale of coffee and maybe community center rental.

If I were designing this, I would make "tracking dates" an easy to change field. It is important to get attendee names, but it can happen that not until long after the event do the organizers know what dates they want to claim as impact dates. It could be 24 hours, or it might be a week, or more likely (especially with new users who signed on during the event) they might wish to claim years after the event. Wikipedia's recruitment period is often years, and conversion sometimes can be traced to particular events years before the conversion.

Ijon claimed this task.Apr 1 2016, 9:10 AM
DannyH moved this task from New & TBD Tickets to Programs + User groups on the Community-Tech board.
DannyH added a subscriber: DannyH.

This sounds like 2 separate tasks:

  • Allow programs to be only 1 day long (a simple fix to the existing code)
  • Add support for start and end times (new interface and some refactoring of existing code and interfaces)

@Bluerasberry: I'm afraid I don't understand how your comments are related to this bug. What does "establishing a workflow around establishing diligence in giving event grants" have to do with letting people set the time period for their event to less than a week? A lot of 1-day events don't even get grants. Why should we force them all to be at least a week long?

Also just created:
T140306 - Add support for setting the time zone of a program

kaldari renamed this task from Allow program to be only 1 day long and include start/end times {ax} {mvp} to Add support for start/end times in Programs Dashboard.Jul 19 2016, 5:15 PM
kaldari edited projects, added Community-Tech-Sprint; removed Community-Tech.
kaldari updated the task description. (Show Details)

I like that wireframe!

This may be helpful for the styling: https://dashboard.wikiedu.org/styleguide.

Here's root of that UI: https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/app/assets/javascripts/components/course_creator/course_creator.jsx

Note that default_course_type === 'ClassroomProgramCourse' is the basis for switching between the course-oriented version (for Wiki Ed) and the event-oriented version (for the programs dashboard).

These values would also need to be editable from the Details component (and should not show up for the ClassroomProgramCourse type). See https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/app/assets/javascripts/components/overview/details.cjsx

DannyH removed Ijon as the assignee of this task.Jul 26 2016, 12:17 AM
DannyH triaged this task as Medium priority.
DannyH added a subscriber: Ijon.
DannyH set the point value for this task to 8.Aug 23 2016, 5:39 PM
DannyH moved this task from To Be Estimated/Discussed to Estimated on the Community-Tech board.
DannyH raised the priority of this task from Medium to High.Aug 30 2016, 5:19 PM
MusikAnimal moved this task from Ready to In Development on the Community-Tech-Sprint board.
Base added a comment.Sep 6 2016, 5:10 PM

Don't know if it's worth mentioning but took a look at the design suggested and thought about it: start and end date/time are not always in the same timezone. Like CEE Spring in Ukraine this year started by EET (UTC+2) and finished by EEST (UTC+3) due to DST. So perhaps hidden by default but there should be a separate timezone field for the end point accessible too.

Don't know if it's worth mentioning but took a look at the design suggested and thought about it: start and end date/time are not always in the same timezone. Like CEE Spring in Ukraine this year started by EET (UTC+2) and finished by EEST (UTC+3) due to DST. So perhaps hidden by default but there should be a separate timezone field for the end point accessible too.

Ah, working around DST is very tricky! Timezone support is next on the list with T140306 and we'll definitely have to keep this in mind. Thanks

So I toyed around with several UI ideas and found this to be the most intuitive and aesthetically pleasing:

This just makes the hours/minutes a dropdown, meaning we can cut corners and not have to write validations, etc, and I think it looks quite nice. Wanted to run this by you all before I get into more coding. Note for some users AM/PM may not be desirable. We could add some i18n checks to determine whether to show it, but I figure 24 hour works just as well. @Ragesoss @DannyH what do you think?

@MusikAnimal: I like this. If we're going to ship this before adding full timezone support, though, then we need to add some explicit indication that the time should be specified in UTC.

@MusikAnimal: I like this. If we're going to ship this before adding full timezone support, though, then we need to add some explicit indication that the time should be specified in UTC.

Hopefully we can ship both in tandem, but I suppose that depends on how badly people need the start/end times and the work involved in adding timezone support. I see we're using moment.js, maybe we could look into moment-timezone as well, but at the cost of 2.7KB of JavaScript.

Our javascripts are pretty big already. I won't sweat an extra 2.7KB. But we'll definitely need to let the user set / change the timezone explicitly, even if moment-timezone is helping us out by setting a default based on client-side timezone inference.

@Ragesoss I've created a PR for what I have so far, just to illustrate my approach (this is far from a working prototype): https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/951/files

Basically everything will be moment objects, which we need to convert when we fetch the data from the server. With that we should be able to safely do date manipulations and have it all be saved in the same field in the database. Any feedback is appreciated. I did something very similar at my last gig and it worked for us, also using moment/React/Rails/etc.

Also I'm amazed it only took a few hours before there were conflicts with master! =P I was thinking it might be wise to partition this task into smaller deployments, perhaps starting with the database migration. That seems like the most risky to me... The date to datetime seems safe, we just need to backfill end dates to be at 23:59:59 so they are at the end of the day. Once we have that cleared up, we can do some backend work to put everything in place before adding the time pickers to the UI.

MusikAnimal closed this task as Resolved.Sep 30 2016, 8:12 PM

Reviewed by @Ragesoss and deployed to Outreach Dashboard! :D

Abit awarded a token.Oct 3 2016, 2:56 PM
DannyH moved this task from Estimated to Archive on the Community-Tech board.Oct 11 2016, 8:56 PM