A very tricky part of core has always been the teaser/summary, our changes in Drupal 7 where positive but we are still not quite there. The label “Edit Summary” was confusing to many new and existing users. The label “Edit Summary” did not make clear about what is it’s functionality. Some participants did understand the functionality once they clicked on it but most of them were not completely clear or had more questions about how it works.

What do you think “Edit Summary” is?
“It is a summary of content for search engine spiders” (Existing user, participant 4)
“It is a summary of edits” [Participant assumed this to be the revision log because she is an active wiki user and on the wiki, “Edit Summary” refers to the summary of the edits to a particular content] (Existing user, participant 5)

It seems like we need to do further iterations to make this usable, it seems like much of the confusion was about the labeling and the help text seems to communicate what we want to do with just a label.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ryan.armstrong’s picture

I definitely think we need to come up with a better term for it, and perhaps have some hint text on how to use it.

One popular method would be to have a little speech bubble with a ? in it, that when you clicked it, a little pop up appeared with helper text. That way if someone wasn't clear what it did by it's title, they would immediately know to click that little help button to get clarification.

I would definitely be against getting rid of it, as I, and clients of mine use it a lot. But I do think it should be minimized by default as it is now. Also, it might be nice if when you create a new content type, you have the ability to control the creation of the body field, including choosing either a plain textarea, or a textarea with summary. That would be a good place to educate people as to what it does.

Finally, in addition, or in lieu of text, perhaps a visual aid on what it does. When I did my UX session with the user who was confused by the user was confused by the summary because that exact phrase meant something different in the wiki community. When I visually showed her what it did, it clicked immediately.

RobW’s picture

OK, good point, let's fix it up. The problem seems to be two parts:

The word Summary can be confusing or inaccurate.

The field is actually an alternate view mode of a long text area. Sometimes it might be used as a summary, sometimes a teaser, sometimes as something different. The description needs to be more specific without being too long.

Possible solutions: "Teaser", "Preview Version".

The word Edit in this context can be ambiguous

Is it an adjective or a verb?

Possible solutions: "Add a [noun]", "Click to add [noun]", "Create custom [noun]".

My suggestions aren't the most exciting, let's get some more.

ryan.armstrong’s picture

I like 'Teaser' as that seems to be the most common use of this feature. I can't think of a better noun than that.

One thing I have been thinking of is what about contextually setting up the link? This is something that Apple has been very good about in their UI guidelines. Whenever possible, they recommend setting the text of a button to be a specific description of what that button will do. Unlike other UIs that you 'Ok/Cancel' or 'Yes/No' all the time, you'll often see buttons that say 'Save your work/Discard Changes'

What about something similar for this button. If there isn't a teaser or [noun] already, it will say 'Add a [noun].' If there is content in the field, have it change to 'Edit your [noun]' THat way, it will be much more clear what that button does in the appropriate context. It would be relatively simple with JS and I think it would make things much clearer.

RobW’s picture

Nice point, Ryan. Once there is content in the field isn't it expanded by default? In that case the label of the text area will say "[Noun]", the action link should say "hide [noun]", and after it's hidden I would think it should say "show [Noun]".

Teaser is probably better than Summary, but the more I think about it, the box is not necessarily either of those. It's content available for display on an alternate view mode of a long text area. If there's any way we can describe this without being verbose I think we should.

"Short Version of [Fieldname]" is almost better than "Teaser", but would need some help text. Something like "Can be displayed in alternate content views, including teasers and summaries". I'm dead set against adding help text in 99.99% of cases, we should be cutting back on the redic verboseness of help text as much as possible in D8, but maybe this is one of those 0.01% times.

RobW’s picture

In general I think your suggestion of specific action descriptors would improve Drupal's usability by leaps and bounds, and maybe deserves it's own issue.

dcmistry’s picture

Other possible solutions:

- "Edit the teaser"
- "Edit the summary"

IMO, the "the" makes all the difference. ;)

dawehner’s picture

Component: base system » node system
Issue summary: View changes

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

Version: 8.1.x-dev » 8.2.x-dev
Issue tags: +ux-interfacetext

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

simohell’s picture

Component: node system » field_ui.module
Issue tags: +Accessibility
FileSize
57.92 KB
59.42 KB
55.07 KB

This issue is important but has changed a lot over the years.

With Drupal 11 and several versions before that we can have had several fields in the same node with a summary each. The teaser metafore is no longer present. However I see that the label "Summary" is not properly connected to it's "parent" field whenever the summary is not closed. Having an option to close the summary also seems to be theme dependant.

This seems to be an accessibility issue as well as in at least some situation the user might not know wether the summary above or directly below the long text field is the on that summarises that specific field.

I guess the Summary label should always have some reference to the main field label.

I would expect this issue belongs to fields but is also relevant for a number of themes.

Attaching screenshots from Olivero and Claro.

Edit form with several long text with summary -fields with summary open in Claro


Edit form with several long text with summary -fields with summary closed in Claro
Edit form with several long text with summary -fields in Olivero.
simohell’s picture

Component: field_ui.module » node system
simohell’s picture

We discussed this issue at the usability meeting #3417104: Drupal Usability Meeting 2024-02-02 where we agreed that a simple text change is not a sufficient improvement. At the meeting were present @benjifisher @shaal @ simohell @worldlinemine @duncancm and @rkoller.

We came up with a suggestion to

  1. wrap summary and full text into a fieldset
    (we noted that fieldset stlyles may be too sublte for proper accessibility, but that is another issue)
  2. use field name as the label for the fieldset
  3. label text areas as summary and full text

Summary and trimmed are terms that are used by field display add teaser is a standard view mode that implements displaying the summary and/or trimmed version.

Full text is referenced by the summary description but not present at form.

If we don't want to have the summary field always displayed, we can place it inside a details element. On content creation the details element should be open. On my opinion editing content it should be closed to save space if no summary text was added and open if a summary text was added.

benjifisher’s picture

One point that came up in the usability meeting (Comment #26) is that there are use cases for having more than one long-text-with-summary field, or a multi-valued field. I have never seen it, and I do not think it meets the threshold of the 80% use case, but it does come up.

The current link to open the summary form was probably the only way to do it when this form was first designed. That was a long time ago. I think we should use a standard <details> element now that we can.

Probably the summary should be hidden by default, at least when it is empty. That is the least disruptive change from the current behavior.