WordPress.org

Making WordPress.org

Opened 8 months ago

Last modified 6 weeks ago

#3117 new enhancement

Schedule: Support sessions that span multiple time slots

Reported by: mrwweb Owned by:
Milestone: Priority: normal
Component: WordCamp Site & Plugins Keywords: needs-patch
Cc:

Description

Between workshops, contributor tracks, and more, it's quite common for a session lengths to differ and overlap. You can see many examples of this in the WordCamp Seattle 2017 schedule.

Currently, WordCamp site themers are required to create hacky CSS rules that fake the appearance of extended sessions. This is inconvenient and time-consuming. Further, the accessibility of such a display is almost certainly worse than it would be with a properly implemented rowspan.

While this will almost certainly be complicated, a scheduling interface that incorporates an end time or some other method for spanning time slots should be supported to improve administration, theming, accessibility, and the overall usability of the [schedule] shortcode output.

Attachments (4)

3117.diff (10.3 KB) - added by iandunn 6 weeks ago.
Render grid schedule based on feature flag, copy static markup/css from codepen
3117.2.diff (12.4 KB) - added by iandunn 6 weeks ago.
Dynamically generate markup/css
3117.3.diff (13.4 KB) - added by iandunn 6 weeks ago.
Create rows for every 5 minutes; remove duplicate sessions
3117.4.diff (13.6 KB) - added by iandunn 6 weeks ago.
Minor iteration on 3.diff

Download all attachments as: .zip

Change History (21)

#1 @coreymckrill
8 months ago

  • Keywords needs-patch added
  • Summary changed from Support sessions that span multiple time slots to Schedule: Support sessions that span multiple time slots
  • Type changed from defect to enhancement

I wonder if this would be an opportunity to rethink the [schedule] output entirely, to use Flexbox or something instead of tables. Thoughts, @mrwweb ?

#2 @mrwweb
8 months ago

That sounds great. I've never looked at the code before so I don't know what's in there.

Calculating what a "slot" is and how many slots a session spans seems like a fairly complicated thing and I'm not sure how that would work. The user-friendly backend solution would be to enter a start time and then either an end time or session length. However, with both tables and grid, asking for a "rowspan" would be easier to layout but require experimentation from the editor. The former is trickier but probably the way to go.

The WC Seattle 2017 schedule provides a lot of useful scenarios that anything new should be able to handle:

  • Session spanning all tracks in one time slot
  • Session spanning some but not all tracks in one time slot
  • Session spanning multiple time slots (WP 101 workshop)
  • Session spanning multiple time slots and ending at a time that doesn't align with other time slots (JavaScript workshop)
  • Unequal time slots (1 hr session - 30 min lunch - 1 hr session) with heights that communicate relative difference.

Making the markup accessible should be a high priority if rewritten. (The current table leaves a lot to be desired). This would definitely be a use-case for grid and not flexbox if not done with a table. That said, improved table markup might actually be fairly accessible as long as table headings are implemented correctly. Otherwise, the times for each session will need to be hidden somewhere in the markup so they're announced with each session.

Potentially relevant resources for Grid:

Finally, for sighted users, it's important that it's possible to style borders and/or striped rows on the sessions table (again, see the linked example) in order to enable easy scanning of the schedule.

Before going any further, people should scan other camps in order to find other valuable edge-cases the [schedule] shortcode should support.

This ticket was mentioned in Slack in #meta-wordcamp by coreymckrill. View the logs.


7 months ago

#4 follow-up: @coreymckrill
7 months ago

This ticket was discussed in the WordCamp.org ticket scrub today. We agreed that more research is needed to settle on a good approach to this.

@mrwweb do you have any examples of other implementations of schedule layouts that might be a good starting point for this?

#5 @mrwweb
7 months ago

If you're looking for code examples, I still haven't found any.

Since it was mentioned in the chat, the WordCamp Berlin is another example of a calendar that ran into this issue.

To try to help frame the issues, in my mind, the primary questions are:

  1. Is the session defined by a length or end time?
  2. Is the markup with tables, flexbox, or CSS Grid?

For question 1, I suspect the interface should be as user-friendly as possible and then the code will probably convert to a session length.

For markup, tables can theoretically be semantically correct, but the current one isn't and it'll take a lot of work to make them better. Flexbox is intended for linear presentations of items so doesn't really correspond with the idea of a multi-dimensional calendar grid. CSS Grid likely makes the most sense and I still think the "fixed" grid example given previously may suggest a good way to handle this. Grid also has a really big advantage of being easier to make response as tables are a pain for that.

Getting some input from the accessibility team for code implementation would be valuable.

#6 @iandunn
7 months ago

One thing we'll need to keep in mind is back-compat, since most camps have custom CSS that's tied to the current markup.

That doesn't necessarily mean that we can't re-do it, but if we do, we'll need to keep the one one around and setup a feature flag so that old sites continue using the table, and new site use the new markup.

#7 in reply to: ↑ 4 @mrwweb
7 months ago

Replying to coreymckrill:

@mrwweb do you have any examples of other implementations of schedule layouts that might be a good starting point for this?

I never was able to find one, so here is a front-end proof of concept! Honestly, I'm quite happy with it. It doesn't 100% cover all the edge cases I could think of (specifically a session spanning multiple non-contiguous tracks), but it's a huge improvement on the current schedule. (I assume the accessibility of this new schedule is also much better though I'd love some feedback on that too.)

I haven't looked at the code that outputs the schedule, but I get the sense it could handle the requirements of this new way of laying sessions out.

Feedback welcome. Feel free to fork the pen and improve on it.


New CSS grid-based layout:

https://cldup.com/y5feAJGGq6.png

Small-screen view & no-grid-support fallback:

https://cldup.com/JmeT0tAJTS.png

This ticket was mentioned in Slack in #meta-wordcamp by mrwweb. View the logs.


7 months ago

This ticket was mentioned in Slack in #meta-wordcamp by coreymckrill. View the logs.


6 months ago

@iandunn
6 weeks ago

Render grid schedule based on feature flag, copy static markup/css from codepen

#11 @iandunn
6 weeks ago

3117.diff is a very rough first pass, to illustrate how the feature flag could work. In my local environment I ran wp wc-misc set-skip-feature-flag css-grid-schedule 70, so that all of the sites with IDs <= 70 will us the old schedule, and all the ones > 70 will use the new one. See wp help wc-misc set-skip-feature-flag. You can also just change that to if ( true ) { for easier local testing.

I copied over the markup and styles from the CodePen above, but didn't have time to start converting it to being generated dynamically.

Another back-compat consideration is the personalized schedule builder from #2733. I don't think that'll pose a big problem, but it'll definitely need to be part of the testing process.

@iandunn
6 weeks ago

Dynamically generate markup/css

#12 @iandunn
6 weeks ago

3117.2.diff is a rough pass at dynamically generating the markup and CSS, but it doesn't correctly set the grid-column value for each div.session.

@iandunn
6 weeks ago

Create rows for every 5 minutes; remove duplicate sessions

@iandunn
6 weeks ago

Minor iteration on 3.diff

This ticket was mentioned in Slack in #meta-wordcamp by iandunn. View the logs.


6 weeks ago

#14 @iandunn
6 weeks ago

This should probably output the session categories in addition to the session tracks.

It seems like it'd be better to do that in actual markup, rather than with CSS content, but I don't remember the reasons why we used content for the table schedule. It was added in r500 for #353. @nvwd, do you have any thoughts on using markup vs content? I'm curious if you do as well, @mrwweb.

It seems like markup is more semantic/accessible, and it also allows for multiple categories. CSS content overrides previous categories, although I guess we could change data-track-title to include all the category names.

https://wordpress.slack.com/archives/C08M59V3P/p1523525100000375

This ticket was mentioned in Slack in #meta-wordcamp by iandunn. View the logs.


6 weeks ago

#16 @nvwd
6 weeks ago

I don't have a reason to use one over the other. Switching to markup seems like a good thing.

Love the use of CSS grid here.

#17 @mrwweb
6 weeks ago

Categories should definitely be in the source. They'll be more flexible to style (they should have a wrapper with a unique class) and for accessibility purposes, you can't rely on the content property to be announced to all screen readers. (At least that's my historical memory.)

I could imagine a shortcode parameter to show/hide categories might be useful if we think not everyone would want them visible. (And if implemented, there should NOT be equivalent options to hide track and time unless they're left in the source and hidden accessibly, since those pieces of info are critical to finding the session.)

Note: See TracTickets for help on using tickets.