Skip to content
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

Having two types of quote is confusing #11610

Open
sarahmonster opened this issue Nov 8, 2018 · 29 comments
Open

Having two types of quote is confusing #11610

sarahmonster opened this issue Nov 8, 2018 · 29 comments
Labels
[Block] Pullquote Affects the Pullquote Block [Block] Quote Affects the Quote Block Needs Dev Ready for, and needs developer efforts [Type] Enhancement A suggestion for improvement.
Milestone

Comments

@sarahmonster
Copy link
Member

We have two different quotes available: a quote and a pullquote. Technically, the idea is that a quote is something someone else said, and a pullquote is a piece of text from the text of your article, pulled out to give it emphasis as a graphic element.

Our descriptions do indicate this difference—the pullquote is described as "Give special visual emphasis to a quote from your text."—but then we undercut that a bit by offering a citation for the quote, which isn't generally used with a pullquote. From a user perspective, this makes it seem as though both blocks are used for the same purpose, but offer slightly different styling. But then each block also has style variations—so there's lots of potential here for user confusion.

There's also a semantic difference between the two, where a quote is a <blockquote> element and a pullquote is an <figure> element, but that is largely invisible to the majority of users.

It's also been identified as a point of confusion in usability testing: https://make.wordpress.org/test/2017/12/06/wcus-gutenberg-testing-volunteer-feedback/ and it threw me off as well when I first tested these blocks myself.

This has come up in earlier issues (#5947), but it might be worth revisiting for 5.0 in order to reduce unnecessary user confusion.

Pullquotes work really nicely in print, where layouts are fixed, but they make less sense on the web, where people are increasingly reading on mobile devices and duplicating content is a bit weird. There are also accessibility concerns if people are using pullquote for its intended purpose, and duplicating their content. (I think we'd want to add an role="presentation" aria-hidden="true" to the containing <figure>, but @tofumatt may know better there.)

My recommendation would be to remove or hide the pullquote block for now, since its functionality can eventually be replicated by a container block and a nested quote, and it introduces needless confusion for the majority of users.

Failing that, we should at least remove the citation from the pullquote block. Since the intention of a pullquote is to quote from the article itself, a citation doesn't make sense in this context. We may also want to consider the accessibility implications of pullquotes being used for their intended purpose.

@sarahmonster sarahmonster added [Type] Enhancement A suggestion for improvement. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Block] Quote Affects the Quote Block [Block] Pullquote Affects the Pullquote Block labels Nov 8, 2018
This was referenced Nov 8, 2018
@colorful-tones
Copy link
Member

I agree with all the observations above.

I would speculate that the existence of both the Pullquote and the Quote likely stem from a handful of requests to allow for more customization of quotes (in general sense). Whereas, the Quote block existed first, and then there was perceived enough customization requests so that the Pullquote was then created to address. Again, total speculation, but worth stating (in my opinion). 🙈 🙉

The biggest difference between the two blocks (besides the semantic HTML output noted by @sarahmonster) are their customization options.

The Quote block just has one Style option: "Regular" or "Large"

Quote block's Style options

Whereas the Pullquote has multiple options: Style: "Regular" or "Solid Color" and Color Settings: "Main Color" (color picker) and "Text Color"

Pullquote block's multiple options

The existence of the Pullquote block is confusing. However, both the Quote and Pullquote block's options offer quote (in general sense of term) affordances, which should likely be merged. So that, the Pullquote should be removed, but the setting options ("Main Color", "Text Color") could be merged into the Quote block. So that the Quote block would have all of these options:

  • Text Settings: Font Size: Normal, Medium, Large, Huge / Specific Value (similar to current Paragraph block)
  • Style: Regular or Solid Color
  • Color Settings: Main Color and Text Color

However, I think these settings should be prioritized for 5.0 release. So that the simpler the better. I would remove Pullquote, leave Quote options as is, and incorporate Pullquote's options in to Quote as phase 2.

@karmatosed karmatosed added the Needs Design Feedback Needs general design feedback. label Nov 15, 2018
@karmatosed
Copy link
Member

I have seen the pullquote used a fair bit, which makes me wonder if a style makes sense. I don't see a case for removing pullquote in 5.0 as that time has also passed right now, however let's think about iteration.

@Presskopp
Copy link
Contributor

The whole concept about quotes is confusing and even useless. What is the (special) empasis the block help text is talking about? Making it italic? The preview does not work for me and I could make a long list of things I don't like about it.

image
image

The 'italic' button does nothing in quotes - confusing. A quote can't be non-italic? Where are the quotation marks? What's so special in special visual emphasis of a pullquote, I/we don't have a clue how to translate the help texts for german in a meaningful, helping way etc, etc.

@mcsf
Copy link
Contributor

mcsf commented Nov 16, 2018

What is the (special) empasis the block help text is talking about? Making it italic?

The first thing about quotes is document semantics. Internally, a quote uses HTML's blockquote tag, and optionally the cite tag, as it should. Externally, this means that most users will see something that looks like a quote, but it also means that users that use assistive technologies (a11y) will still be informed that a particular piece of content is a quote. Internally, it means that a content creator can specify their intent by way of choosing the Quote block, and from that intent Gutenberg will provide a specific experimence for quotes. Finally, a proper semantic document is nicer for machines to parse and thus contributes to better Search-Engine Optimisation (SEO).

Perhaps the mistake was in using "emphasis" (and "visual"?) in the copy. /cc @alexislloyd @mtias

The preview does not work for me and I could make a long list of things I don't like about it.

This sounds like a separate issue.

The 'italic' button does nothing in quotes - confusing. A quote can't be non-italic?

A quote can be rendered in any way, but this is up for the theme to decide. If the theme doesn't have an opinion, then the Quote block provides default styles which happen to use italics.

Where are the quotation marks?

These can be introduced by the theme via CSS (typically using the ::before or ::after pseudo-elements).

What's so special in special visual emphasis of a pullquote, I/we don't have a clue how to translate the help texts for german in a meaningful, helping way etc, etc.

It seems like the focus of confusion here is the fact a distinction is made between Quote and Pull quote, correct? That, I agree, is worth debating, and indeed is the subject of this issue.

@karmatosed karmatosed added this to the WordPress 5.0.1 milestone Nov 22, 2018
@mtias mtias modified the milestones: WordPress 5.0.1, Future: 5.1 Nov 30, 2018
@timwright12
Copy link
Contributor

I don't think either item should be removed from the UI as they both have a semantic and editorial purpose and if they're combined into the same block we're likely to see a higher level of misuse in the editorial output leaning towards whatever the default state is.

From an HTML standpoint, using a figure element as a pull quote wrapper seems to align with the specification:

The figure element represents some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

However, I don't think nesting a blockquote is correct, which is why the citation is coming through. Everything I've researched so far has not contained a nested blockquote/citation, but rather just paragraph text. This would be more like an optional caption situation rather than a normal citation.

Adding role="presentation" and aria-hidden="true" to the wrapping element feels a little heavy handed to me since aria-hidden will remove it from screen readers without setting the role.

I'm torn on this one, because If something is represented visually, unless it is purely for presentation it should be communicated to screen readers and I do believe there's editorial value in a pull quote, or they wouldn't be used.

I would lean towards one of these as a solution/action item for this ticket:
Option 1: Make the pull quote more visible

<figure role="region" aria-label="Pull Quote">
  <p>Pull quote content here</p>
  <figcation>optional caption here</figcaption>
</figure>

Option 2: Make the pull quote less visible

<figure aria-hidden="true">
  <p>Pull quote content here</p>
  <figcation>optional caption here</figcaption>
</figure>

Both options also remove the nested blockquote. Personally, I do think there is value in presenting pull quotes to assistive technology, the same way there's value in using it for a sighted user; so I would lean towards Option 1 rather than removing the content. But I would love to hear other thoughts @sarahmonster @colorful-tones @mcsf @tofumatt

@mcsf
Copy link
Contributor

mcsf commented Jan 21, 2019

Thanks for your comment, @timwright12. Between the two, I'd also lean towards option 1: keep things visible and be more explicit about the nature of the element for screen readers.

However, I'm not sure we should drop blockquote from the figure. Can you expand on that?

@timwright12
Copy link
Contributor

Since a pull quote is unlike a blockquote, where the content is jus something repeated from another part of the article (and can be removed without affecting the content flow), the figure element and optional figcation communicate the correct semantics rather than using a blockquote, which is for someone other than the author of the article, and needs a citation.

@mcsf
Copy link
Contributor

mcsf commented Jan 23, 2019

That's a good point and a way to clearly distinguish Pullquote from Quote. I'll let others weigh in.

@colorful-tones
Copy link
Member

Pull Quotes are an artifact of the print era and will likely only be used by a small, niche group. Which leaves the majority of non-technical editors and users who do not necessarily care about semantics and will just default to using the Quote block, because they need a quote. Unless, they're feeling adventurous and realize that the Pull Quote has more customization options, and will then exploit it for those features with disregard for semantics.

Really, all that 👆 is pure speculation and user persona assumptions, which can only be solved with some solid user testing to see some metrics on what people are using them for, and why.

Further reading up on the concept of Pull Quotes produces some interesting nuances:

Make pull quotes stand apart from the accompanying text. Set the pull quote apart by using a different typeface, setting it off by rules or in a shaded box. Try using oversized quotation marks or aligning it to the right or having it cross two columns of text.

-- Jacci Howard Bear. "How To Use Pull-quotes to Add Visual Flare to Articles". Updated February 11, 2019. Lifewire.com

Or

TIP: Pull-quotes should grab the reader’s attention, not play tug-o’-war with it. Limit pull-quotes to one to a page to keep your layout from becoming too busy.

-- Ilene Strizver. "Pull-quotes". www.fonts.com. Archived from the original on 17 July 2010. Retrieved 2012-07-09.

Or

A disadvantage of pull quotes as a design element is that they can disrupt the reading process of readers invested in reading the text sequentially by drawing attention to ghost fragments out of context. At the other extreme, when pull quotes are used to break up what would otherwise be a formless wall of text, pull quote can serve as visual landmarks to help the reader maintain a sense of sequence and place.

-- Wikipedia contributors. (2018, June 18). Pull quote. In Wikipedia, The Free Encyclopedia. Retrieved 14:11, February 12, 2019, from https://en.wikipedia.org/w/index.php?title=Pull_quote&oldid=846430528

So, it seems the context of pull quote usage is quite important. Visual impact can serve as either a hindrance or promotion of the contained text. There is also SEO implications to consider: duplicate content.

Since Pull Quotes exist in Gutenberg and are not likely to go away. It does seem best to leverage <figure> to capture the semantic meaning. I too am on the fence though about how and whether we should be highlighting the content for screen reading technologies.

If we're highlighting the quoted text to merely provide a visual relief from a "formless wall of text". Then I might lean more towards @timwright12 's Option 2:

<figure aria-hidden="true">
  <p>Pull quote content here</p>
  <figcation>optional caption here</figcaption>
</figure>

But I do not want to be exclusionary and I do not use screen reading technology in my every day experience with the web.

@mcsf
Copy link
Contributor

mcsf commented Feb 15, 2019

Thanks for the comprehensive reply.

I am sure Pull Quotes will be used in many different ways. Although in its original print form it meant to repeat text from the body, we can't guarantee that, nor impose it on users. For that reason, I'm reticent about making Pull Quotes invisible to screen-reading devices. I wouldn't oppose to making that an advanced block option, though. Thoughts, @sarahmonster and @karmatosed?

@afercia
Copy link
Contributor

afercia commented Feb 24, 2019

Removing the accessibility label, as it's not strictly related.

@afercia afercia removed the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Feb 24, 2019
@karmatosed
Copy link
Member

karmatosed commented Feb 25, 2019

I still feel that if we have a more than one quote, it should be a style. I can see a path where someone looks for 'quote' and applies 'pullquote' as a style variant.

@mapk
Copy link
Contributor

mapk commented Apr 5, 2019

I'm all for keeping both the Pullquote block and the Quote block based on @timwright12's comment above. I agree that we should remove both the blockquote and the citation from being nested in the pullquote. And if there's still value for sight-impaired users, then Tim's option 1 makes sense.

Option 1

<figure role="region" aria-label="Pull Quote">
  <p>Pull quote content here</p>
  <figcation>optional caption here</figcaption>
</figure>

Let's go this route for now.

@campaignupgrade
Copy link

campaignupgrade commented Dec 31, 2021

@colorful-tones analysis looks correct; a quote is for where a passage or speaker is being cited verbatim. A pull quote is a duplicate of text found elsewhere in the content but displayed in a graphical fashion.

However there is an issue with the <figure> tag. Google will index the <figure> tag as part of the article because a <figure> is content that is considered supplementary or at least tangentially related to the primary content, such as a chart, graph, or image. Duplicating content may have a negative effect on SEO.

On the other hand an <aside> is considered non-content for indexing purposes and will be ignored. Though Google officially suggests <aside> tags will be treated as tangential content, testing has shown that Google generally ignores<aside> content.

The HTML spec supports <aside> as the wrapper for pull quotes:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

@carolinan
Copy link
Contributor

With the update of the quote block to use inner blocks and with added block supports for styling, I think it is time to reconsider deprecating or at least hiding the pull quote block in the inserter.

@carolinan
Copy link
Contributor

carolinan commented Jan 25, 2024

I still feel that this pullquote block should be deprecated, perhaps I am having an off day but there are 30 Trac tickets with reports about bugs with the bundled themes and this block.

https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&summary=~pullquote&order=priority

@mtias
Copy link
Member

mtias commented Jul 2, 2024

@carolinan yeah, I think it's a fine time to deprecate.

@karmatosed
Copy link
Member

I fully support deprecating but would love to get a plan worked out as we do this, so thank you for raising this @carolinan and getting agreement @mtias. The plan itself would be what if any impact default themes would have around this. There has been a fair bit of patching up around those themes so far and ideally we need to review if:

  • The merging fixes all of those issues.
  • Fix ones it doesn't.

I am excited about doing that because it could move on quite a few issues at once along with this there is the opportunity for some styling clean up we should ticket for within those themes.

@carolinan
Copy link
Contributor

@t-hamano Do you want to work on this? If not I might try to use your post-author deprecation as an example.

@carolinan
Copy link
Contributor

we need to review if:

  • The merging fixes all of those issues.
  • Fix ones it doesn't.

Deprecating the pullquote would not fix existing issues, converting each block in the content is a manual process.
But we can decide to give those issues a lower priority.

@t-hamano
Copy link
Contributor

It seems that the addition of the Pullquote block was proposed in #547. That was 7 years ago, and it seems that the main purpose was to embellish the Quote block.

Now, the Quote block has almost the same block support as the Pullquote block, so I agree with deprecating the Pullquote block.

The big difference between the two blocks is that the Quote block does not support wide/full width. If the Pullquote block is to be deprecated, I think we should add wide/full width support to the Quote block before that.

Also, to be clear here, deprecating a block generally means that we cannot insert it from the inserter. Deprecated blocks already inserted in content will not break, and styles will be preserved.

cc @aaronrobertshaw - Because I think this issue will be relevant to moving forward with #43241

@aaronrobertshaw
Copy link
Contributor

Thanks for the ping 👍

Because I think this issue will be relevant to moving forward with #43241

It's a community effort to achieve more consistent design tooling across blocks. It will also take time and blocks will come and go. That shouldn't cause any issues though.

@mtias
Copy link
Member

mtias commented Jul 25, 2024

@t-hamano good call on supporting width alignments

@ramonjd
Copy link
Member

ramonjd commented Jul 26, 2024

+1 On deprecating the Pullquote block for reasons stated.

I think that the cite element has some semantic value for both <blockquote /> and inline text.

Maybe users could have the choice to apply it to any rich text?

I quickly added it to the formatting library to test:

Kapture.2024-07-26.at.11.51.21.mp4

Happy to get a PR up if folks think it's a worthy addition.

@carolinan
Copy link
Contributor

Please open separate issues for the quote block, otherwise the suggestions will get lost more easily.

@t-hamano
Copy link
Contributor

Is adding the cite element as inline formatting a prerequisite for deprecating the Pullquote block?

If not, I'd start by adding width support to the Quote block.

@ramonjd
Copy link
Member

ramonjd commented Jul 26, 2024

Is adding the cite element as inline formatting a prerequisite for deprecating the Pullquote block?

I don't think so. Feel free to go ahead 👍🏻

@t-hamano

This comment was marked as abuse.

@t-hamano
Copy link
Contributor

The following enhancements have been made to the Quote block:

By now, the block support in the Pullquote block should be fully supported in the Quote block as well.

Are there any other things we need to do to deprecate the Pullquote block?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Pullquote Affects the Pullquote Block [Block] Quote Affects the Quote Block Needs Dev Ready for, and needs developer efforts [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests