Problem/Motivation

"Display mode" versus "View mode". It's confusing to new (and experienced) uses to have two terms for the same thing, let's at least make the D8 user interface consistent and go with "Display mode". When configuring the field formatter for an entity reference field, the phrase "View mode" is used:

View mode occurrence

I realize that the phrase "view mode" is used extensively in the code base for variables and comments, but I think it is important that we stay consistent in the user interface. Since we now have "Structure | Display modes", it seems reasonable that we should stay consistent in the user interface.

Proposed resolution

Make "View mode" go away.

Remaining tasks

Search the code base, substitute "View mode" for "Display mode".

User interface changes

Just some minor text changes.

API changes

None.

Data model changes

None.

Comments

ultimike created an issue. See original summary.

ultimike’s picture

Issue summary: View changes
StatusFileSize
new14.53 KB
ultimike’s picture

Issue summary: View changes
nod_’s picture

Issue tags: +Usability
davidhernandez’s picture

I approve of making this consistent. I'm constantly saying display mode, because that is what is in the UI, and then have to correct myself.

ultimike’s picture

Hmm - now I'm second-guessing myself on this, mainly after someone pointed out to me that there are actually two types of "Display modes" according to the Drupal 8 UI. Navigate on over to "Structure | Display modes" and you'll see two options: "Form modes" and "View modes". This implies that "View modes" are a subset of "Display modes", which would then make the "View mode" label when modifying an entity reference field formatter correct.

Is this thinking correct? Does the display mode "hierarchy" look like this?

  • Display modes
    • Form modes
      • User
        • Register
    • View modes
      • Content
        • Full content
        • Teaser
        • ...
      • Custom block
        • Full
      • ...

-mike

pguillard’s picture

Assigned: Unassigned » pguillard
pguillard’s picture

Assigned: pguillard » Unassigned
Status: Active » Needs review
StatusFileSize
new28.38 KB

First proposition

Status: Needs review » Needs work

The last submitted patch, 8: eradicate_term_view_mode-2567763-8.patch, failed testing.

The last submitted patch, 8: eradicate_term_view_mode-2567763-8.patch, failed testing.

pguillard’s picture

Status: Needs work » Needs review
StatusFileSize
new182.67 KB
new150.6 KB

A lot of replacements were missing. Now this is maybe too much..

Status: Needs review » Needs work

The last submitted patch, 11: eradicate_term_view_mode-2567763-11.patch, failed testing.

The last submitted patch, 11: eradicate_term_view_mode-2567763-11.patch, failed testing.

yoroy’s picture

I think #6 correctly describes the current situation. It's not ideal though to emphasise the differences and have different terms for what are basically variations on a theme. I do prefer "display" over "view".

Maybe "Form display mode" and "Content display mode" would work better.

Bojhan’s picture

Let's do it.

Bojhan’s picture

Title: Eradicate the term "View mode" in lieu of "Display mode" » Change "View mode" to "Display mode"
davidhernandez’s picture

#14 sounds good.

yched’s picture

StatusFileSize
new15.27 KB

Yes, basically, there are "view modes" and "form modes", the common denomination being "display mode".

There are not many places in the UI where we talk about "display modes" generally, UIs are usually about one or the other specifically (displaying an entity render, or an entity form).
But one of them is admin/structure/display-modes, since it's the entry point in the IA tree that lets you administer both :

Display modes admin

Not sure what we'd do on that page if we decide to rename "View modes" to "Display modes" :-)

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.

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

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should 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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.

yoroy’s picture

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

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.

robbt’s picture

I think that this could definitely be improved because using View Mode for content displays is easy to confuse with the Views module. It also makes it harder for people to find documentation for how to use custom view modes because of the language similarity in terms of search.

On the main admin page we have Display modes
Configure what displays are available for your content and forms.

So we utilize the term content on the top link but inside it shows

Form modes
Manage custom form modes.

View modes
Manage custom view modes.

Which requires a leap of logic to go from content to View Modes

The more consistent terminology I'd suggest would be to change the language to
Form Display modes - Manage custom form display modes
and
Content Display modes
Manage custom display modes for content.

The other issue is that if someone isn't completely familiar with Drupal there is no obvious way to utilize the display modes once they're created. Instead you have to know that you have to go to Admin -> Content Types -> Select a Content Type on the list -> Manage Fields then scroll to the Manage display tab or click the drop down and select Manage Display and then expand the Custom Display settings and you can get a checkbox for the various view modes.

Then all the UI provides is an ability to select different fields that could be displayed and you still I would assume need to create a custom twig template for this view mode (or use a module like display mode) if you want to customize how it's displayed. As far as I can find there is no documentation for how to do this on Drupal.org -> https://www.drupal.org/docs/drupal-apis/entity-api/display-modes-view-mo...

Display and View are synonymous to someone who doesn't know Drupal where as View and Views are two core Drupal concepts and it is very easy for someone to get the two confused if they're searching documentation.

There are very few Custom Form Display Modes whereas a lot of View Modes are provided by default.

So I think that even as #18 suggests that there is a problem with showing Display Modes and then Form Display Modes and View Display Modes - just substituting either Content Display modes or just having the default Display Mode be content and then Form be a specialized type of Display mode does not seem like a problem to me.

The biggest challenge at this point would be confusion from eliminating "view modes" and using "display modes" instead for existing developers but I think that lowering the cognitive load and overloading of the word view would be worth it.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.