New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Block: Calendar #1462

Closed
melchoyce opened this Issue Jun 26, 2017 · 21 comments

Comments

@melchoyce
Copy link
Contributor

melchoyce commented Jun 26, 2017

Similar to: #1799, #1800, #1801
PRs where similar blocks are developed: #7966, #7875, #4501

Attributes

  • None, Left, Right, Center, Full Width?
  • Display full-width

States

Selected:

calendar

calendar block selected

Neutral (Full-Width):

calendar block unselected


Questions:

  • Should we include alignment?
  • If yes, should alignment be a default setting in the Block Level Formatting bar?
  • Are there any other settings that should be included?

Related to #1011.

@melchoyce melchoyce changed the title Widgets: Calendar Block Add Block: Calendar Jun 26, 2017

@nylen

This comment has been minimized.

Copy link
Member

nylen commented Jun 27, 2017

This seems like it would be more useful with a way to specify a list of events. A few possible ways that data could be specified:

  • Filter by post type, tag, category, etc.
  • Manual entry
  • Google calendar import
  • ICS file import
@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Jun 27, 2017

@nylen To clarify, this is a conversion of the Calendar widget, which is a calendar of your posts.

@marsjaninzmarsa

This comment has been minimized.

Copy link

marsjaninzmarsa commented Jun 30, 2017

@nylen most use cases I can think about requires support for at least CPT.

@folletto

This comment has been minimized.

Copy link

folletto commented Jul 3, 2017

Should we include alignment?

If we support it not being full width, I think supporting alignment makes sense. The two go hand in hand for me.

I'd also ask if we should make "full width" the default.

If yes, should alignment be a default setting in the Block Level Formatting bar?

Only if "full width" does.

Are there any other settings that should be included?

Some come to my mind, but I don't think they make sense for the first version. Mentioning still as might be useful for the discussion:

  1. Show a specific Month / Year
  2. Show only a specific Category
  3. Show only a specific Tag
  4. Show only a specific Post / Custom Post Type (as suggested by @marsjaninzmarsa)
  5. {{ Show only future posts (this is unsupported in WordPress, as future posts are automatically Scheduled instead of posted, but seems something that could build up to a nice way to feature future events for event sites) }}

Also given the discussion right above, I might suggest to change "Calendar" to "Posts Calendar" or something more specific?

Which leads me to another consideration: is the "Calendar" just an alternative view of the Posts List Archive (#1464)?

@westonruter

This comment has been minimized.

Copy link
Member

westonruter commented Jul 12, 2017

I believe this depends on having an endpoint for server-side rendering: #780

@karmatosed

This comment has been minimized.

Copy link
Member

karmatosed commented Sep 4, 2017

I think changing to 'Posts Calendar' makes sense. I've marked this as needing to get dev as I think it's ready for someone to dip in.

@karmatosed

This comment has been minimized.

Copy link
Member

karmatosed commented Nov 7, 2017

As the project moves towards merge proposal, we are moving issues that aren't needed for that to projects. This doesn't mean they won't get done, they totally can and that's why we're moving to projects. This allows us to focus on the issues that have to happen to Gutenberg. I am closing this but it will live in projects.

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Apr 27, 2018

Took a step back and rethought what a calendar block could look like if we started from scratch.

I focused on exploring the “what if’s” — what if you could schedule drafts from the Calendar block? What if you could reschedule posts?

You can view what I have here: https://cloudup.com/c3HqgFiImw5

Or walk through it in this prototype: https://wp.invisionapp.com/share/VHHNY6CQZGS#/screens

cc @mtias @karmatosed

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Apr 27, 2018

Worth reminding the date picker (see the "Calendar Popover Scheduled Edit DateTime" on cloudup) is not accessible and needs to be replaced by a more accessible solution. See #1311.

The multi-step "fly-out" are tricky to be made accessible but they can probably be treated as modals, correctly handling focus when moving from one step to the following step.

As per the content structure, it's important to take into consideration how the content will be perceived when linearized (that's the typical experience for keyboard users and assistive technology users):

screen shot 2018-04-27 at 18 04 53

Ideally the available actions, in this case "Cancel" and "Select" should be placed after the content, otherwise users would be forced to navigate backwards to operate on them.

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Apr 27, 2018

Thanks for your feedback, @afercia! We should definitely use whatever accessible calendar solution comes from #1311.

Ideally the available actions, in this case "Cancel" and "Select" should be placed after the content, otherwise users would be forced to navigate backwards to operate on them.

In this instance, do you think it's okay for the actions to visually appear at the top of the modal, as long as they're located correctly within the source order of the page?

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Apr 28, 2018

Thanks for your reply @melchoyce. FWIW I think your design is very elegant.

Re: ordering, another important a11y rule is that visual order should match the DOM order. Some references:

See also a couple related recommended techniques:

For clarity, the mismatch between visual and DOM order is considered non-conformant "when it affects meaning and operability" so the WCAG implicitly admit there may be cases where the mismatch is acceptable. However, in this case I'd say it does affect meaning.

Couple examples. As a screen reader user, I'd like to know where I am in the first place and what a specific "fly-out" is about as soon as I land on it. As a screen magnifier user, I see only a small portion of the page at a time, especially at a high level of magnification; when I'm operating in a "fly-out", especially if it's tall, I'd like to find the available actions where I'd expect them to be: after I've set my options or filled out a form.

So, from an accessibility perspective, ideally the "fly-out" should tell users "what" it's about as first thing.
In some cases it does, for example:

  • "Published" (a state)
  • "Add a Post" (name of the task)
    In other cases, it doesn't:
  • "Cancel" | "Schedule"
    In other cases it's a mix of the twos:
  • "Scheduled" | "Edit"

screen shot 2018-04-28 at 11 51 04

So I'd suggest to consider to always put a "title" at the top. This would be even more important when the "fly-outs" are part of a multi-step wizard.

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Apr 30, 2018

Looking at standardizing these popups:

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Apr 30, 2018

@afercia afercia referenced this issue May 1, 2018

Merged

Modal component #6261

4 of 4 tasks complete
@iseulde

This comment has been minimized.

Copy link
Member

iseulde commented Jan 14, 2019

Could this blocks be called "Post Calendar", to avoid confusion?

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Jan 28, 2019

@melchoyce, I have just checked the prototype you shared a long time ago. It looks quite complex for the first iteration. What would be the minimal version of Calendar of Posts? Should it be possible to switch between months or should we only render the current month?

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Jan 28, 2019

I have quickly enabled Calendar on my own website. This is what I see on the frontend:

screen shot 2019-01-28 at 10 54 37

Some observations:

  • it renders the current months by default with a link to the previous month with a post published
  • if I browser the post it sets the month for the calendar to align with the post, the same applies to archives
  • it links months to archive pages for months
  • it links days to archive pages for days

@gziolo gziolo removed the Needs Dev label Jan 28, 2019

@gziolo gziolo modified the milestones: Future, WordPress 5.x Jan 28, 2019

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Jan 28, 2019

The v1 should more closely match the initial mockup, which is a 1:1 port of the existing calendar widget. Visually, I figured we could reuse the styles for the datepicker component.

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Jan 30, 2019

Adding the Accessibility label in addition to the "needs..." one so the team can search for all the widget-blocks related issue in an easier way.

@jorgefilipecosta jorgefilipecosta self-assigned this Feb 4, 2019

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Feb 4, 2019

For clarity, here's what v1 should look like:

image

Phase 2 automation moved this from To Do to Done Feb 14, 2019

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Feb 14, 2019

@melchoyce I'm guessing you will want to open a new issue with some refinements planned for the future, right? :)

@melchoyce

This comment has been minimized.

Copy link
Contributor Author

melchoyce commented Feb 14, 2019

Yes, will do 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment