Problem/Motivation

Since the Page Title element is now a block, we can configure the block settings from the contextual block links.
If we want to hide the title from one specific page a common flow would be to use the contextual link from the page title (block). This however brings you to the 'general' page title block settings which apply to all page title blocks, instead of settings for that specific title.
The page title is part of the content, and as such when the user goes to edit it their first expectation is without doubt that they are changing something that will effect this piece of content only. This way an author or editor could easily inadvertently hide many or all of the page titles on their site.

Proposed resolution

  • Hide the contextual 'configure block' link for the page title block.
  • Long term solution: figure out simple action to hide specific page title

Remaining tasks

  • Hide the contextual 'configure block' link for the page title block.

User interface changes

  • Hide the contextual 'configure block' link for the page title block.

API changes

None

Data model changes

None

Original report by [tkoleary] / Steps to reproduce

Say I'm an author and I created a basic page. In the body I want two "chunks" of content side-by-side, each with a heading and a paragraph. The headings are equally important and together describe what the page is about so I don't need to see the page title which is redundant.

I find the page title block contextual link click "configure", and see a field labeled "Title". Getting rid of the title is what I want to do so I think "well maybe 'display title'" should be unchecked, but it's already unchecked. Instead I try deleting the contents of the field, but I get an error. I try typing "none" in the field and click save. This still does not hide the title.

Seeing "visibility" I think maybe I can use that to make the title invisible. In the first tab I see "content types, not restricted". I'm editing a basic page so I check "basic page". That doesn't work, so I try checking "Article" unchecking "basic page" and saving.

The title is now hidden. Problem solved. I close the browser window because that's the only Drupal task I needed to do today.

Do you see where this is going?

Several hours later an editor gets an angry call from the boss that none of the basic pages on the site has a title. The editor frantically goes to the site to try to diagnose the problem. First she goes around the site and sees that there are no titles. Then she edits a basic page to see if it still has a title, it does. Next goes to display modes to see if the title field is hidden there, it's not.

Finally, she asks one of her Drupal people what to do. They remind her that "page title" was made into a block in Drupal 8. She goes to the block UI to see if she can find "Page title" but it is not there (she ignores the block named "none" because that's not what sh's looking for). Assuming the page title block has been removed she clicks "place block" to put it back. She places the block and moves it to the top of the region.

Returning to the site she views a basic page and sees that the title is now visible. Problem solved!

Hours later she receives another angry call from the boss "All the articles on the site have two titles!" etc. etc.

As you can see there are a boatload of leaky abstraction problems here. The users expectation when clicking a contextual link is that they are changing something about the content they are looking at, not the configuration for the whole site.

Until we come up with a better solution that maps directly to that use case (I what to hide the title for this node), I propose we remove the contextual link for the page title block.

Files: 

Comments

tkoleary created an issue. See original summary.

tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
cilefen’s picture

Component: block.module » theme system
Status: Needs work » Active

I am moving this to the "theme system" component because that is where the issue was that made the title a block, if memory serves. I am setting the status to "Active" because there is no patch.

dawehner’s picture

Title: Page title block is a "leaky abstraction" » Contextual links on Page title block are confusing

The title didn't told me anything.

cilefen’s picture

The issue summary reveals the proposal at the bottom: "... remove the contextual link for the page title block", so I have tagged it "Needs issue summary update". A rewrite with the template and the original report intact at the bottom as supporting information would be great. I am tagging this Novice because a novice can rewrite the issue summary.

dawehner’s picture

Yeah the issue summary is targeted for native english speakers that don't have a problem with reading a long test

davidhernandez’s picture

This isn't a theme system issue. This is an issue with block management, label naming, etc.

The conversion to blocks was put in theme system because the basis for it was removing the variables from the page templates.

dawehner’s picture

Component: theme system » contextual.module

Yeah I guess blocks/contextual links needs to be able to opt out from each other.

mallezie’s picture

I've edited the issue summary and created a follow up feature request for the specific use case

mallezie’s picture

tkoleary’s picture

After thinking about this over the weekend It occurred to me this might be an opportunity to establish a good global pattern for the implementation of contextual links.

We already saw a similar problem to this one in the Minnesota study where the new user clicking on the contextual link in the front page view is brought to the views UI which produced the response: "This makes me want to never touch Drupal again." #2497361: [meta] Fix issues found during UMN Usability Testing 2015 This suggests to me that we should tread much more carefully with contextual links and use them only under certain conditions. We should keep in mind that contextual links were introduced to give authors an "outside in" way to immediately edit content they see on a page, not as a universal shortcut to the configuration of anything on the site. To use them in that way quickly opens the pandoras box of leaky abstractions. To avoid that we could employ the following rule for all contextual links:

Contextual links should generally be present on the front end for the editing or configuration of primary discrete pieces of content and not for configuration that will alter the display of more than one piece of content unless selection triggers an initial warning that indicates the scope of the change.

Example of a "primary discrete" piece of content

The contents of any field in an entity. While it is true that the title of an article, for example, may be re-used and therefore update other parts of the site—like as a teaser in a view—we can consider those things like display modes as "downstream" and the "Primary" version the full display of the entity. Our research shows that most users understand that editing an article will change the teaser.

Example of a "secondary discrete" piece of content

The contents of a field in an entity in any display mode other than full content. It would represent a leaky abstraction to allow users to in-place edit the title field of a teaser from a view, because the user lacks the context of the rest of the content to make good editorial decisions. Best practice would be to send the user to node/edit for the selected teaser and then return them to the view on save.

Example of "non-discrete" configuration

Configuration of views, content types, display modes, layouts, pages and page variants, the placement and visibility settings of blocks, image styles, vocabularies, terms, breakpoints, and anything else to which I can apply the heuristic "If I change the configuration it will affect more than one page in the site"

Exceptions

There are cases where it is commonly understood by users that changes will effect multiple pages in a site. These include: site name/logo/slogan, menus and links, breadcrumbs and other "global" types of blocks like social links, search form, and most footer content including powered by Drupal.

I think this is important enough that we might want to open a meta issue for it, especially given the new vectors for leaky abstraction which will be introduced through panels, page manager, panels IPE, etc.

dawehner’s picture

Sounds like a 9.x issue for me

tkoleary’s picture

@dawehner

Sounds like a 9.x issue for me

Do you mean:

A. the proposed resolution:

Hide the contextual 'configure block' link for the page title block.

B. The long term solution:

figure out simple action to hide specific page title

C. the meta comment:

Contextual links should generally be present on the front end for the editing or configuration of primary discrete pieces of content and not for configuration...

A. Is definitely 8.x since it adds nothing but only removes

B. May be 9.x core, but will certainly be possible in contrib as part of layout work @timplunket is doing (show/hide blocks for a specific entity)

C. Is a design guideline that should not require code, but will require consensus... in which case you might be right, but I hope not. :)

dawehner’s picture

The long term solution, but nevermind, I think those issues are not the place for me, no worries.

davidhernandez’s picture

> not as a universal shortcut to the configuration of anything on the site.

I agree with this. While editing myself, and working with other users, I get frustrated at the number of contextual links thrown all over the page. And I do agree that the scope of their change should be what is visually obvious from where you were/what you were editing. The problem though is how to reconcile that with editing of more generic blocks. For example, if you want to configure the search block that appears in the sidebar of every page, that isn't a "just on this page" kind of thing, and it's likely that isn't the person's intention. Or maybe that is exactly the kind of thing that shouldn't have a contextual link and only done from the block layout admin? The issue there is that some of the motivation was to make it easier to config things if you didn't know how to get to them. "I want to modify this thing. Where is it???" I'm not sure where the line is drawn.

> These include: site name/logo/slogan, menus and links, breadcrumbs and other "global" types of blocks like social links, search form, and most footer content including powered by Drupal.

Doesn't this create a significant inconsistency? In a default install we'd create more exceptions than not.

A. maybe 8.x but it depends on what would need to be modified to make this work. I know the contextual links were removed completely in Seven. That had to be done in preprocess to keep it specific to Seven, but that wouldn't be the same approach we'd want to take. I think we might be able to do this right in the page title block implementation code.

B. Can you clarify that sentence? I don't understand what it means compared to A.

C. Because of consensus, yes, but I don't know if it is prudent to make this kind of UX change during release, especially given it might not get properly settled until 8.2 or something. This is a product manager question.

tkoleary’s picture

@davidhernandez

if you want to configure the search block that appears in the sidebar of every page, that isn't a "just on this page" kind of thing, and it's likely that isn't the person's intention.

I think this is the kind of instance where if you do have the link it gets the "Changing this will affect other pages" warning, but as we move in the direction of in-place draggable blocks we should consider making a single page override the default.

That's really what "B" means. In it's simplest form it would mean reducing the form to a single checkbox "hide page title for this page".

Doesn't this create a significant inconsistency? In a default install we'd create more exceptions than not.

Perhaps, but every rule will have exceptions because people's understanding differs based on context and prior knowledge. Maybe one way to apply some consistency would be to simply provide contextual links to all system provided blocks that are not also fields of the main content ie. Page Title.

It's the fact that Page Title is part of the main content that is introducing the leaky abstraction here.

rootwork’s picture

It's the fact that Page Title is part of the main content that is introducing the leaky abstraction here.

Yes. And in fact the confusion from a new-ish Drupal site admin may be "why can't I move the title around like all the other fields?" first, and upon them finding the block config they might believe that's what it will let them do. So taking care of "A" will at least reduce confusion on moving the title block for all nodes. And figuring out a way to make "B" possible will at least give them the option of hiding the title selectively.

Ultimately I think the solution will be moving toward titles-as-fields (or perhaps an entity attribute called "title" that is simply automatically duplicated and rendered in a normal movable field), but presumably that will be the purview of Display Suite or something like it until 9.x.

cilefen’s picture

And in fact the confusion from a new-ish Drupal site admin may be "why can't I move the title around like all the other fields?"

#2353867: D8: Title does not appear as a field in Manage Display

Wim Leers’s picture

I think a key problem is that contextual links are both for authors and site builders. Really, it's for everything. I think *that* is a big part of the confusion.

rootwork’s picture

@Wim yeah that's a good point.

tkoleary’s picture

@rootwork

The simple solution to this in right now is to hide the page title block for only the node you want then simply type the title where you want it to be in the text and make it an H1 .page-title :)

As far as "moving around the fields" on a per node basis, that is now possible with Entity Embed, but it takes some configuration gymnastics to accomplish.

tkoleary’s picture

@wim

Incidentally, Entity Embed will embed all system blocks in the body, except page title. I wonder is that by design or a bug?

Wim Leers’s picture

#22:

The simple solution to this in right now is to hide the page title block for only the node you want then simply type the title where you want it to be in the text and make it an H1 .page-title :)

I don't quite understand this.

As far as "moving around the fields" on a per node basis, that is now possible with Entity Embed, but it takes some configuration gymnastics to accomplish.

You almost might simply not want to use fields then…


#23: Huh? That's weird. No idea.

rootwork’s picture

I'm sorry I sidetracked the conversation on this issue to talk about moving/hiding the title within entity fields. The proper place for that is #2353867: D8: Title does not appear as a field in Manage Display, thanks @cilefen for linking me to that.

Since #14 clarified this into three stages (not to say there's necessarily consensus we'd undertake each stage yet) should we start talking about whether:

A. the proposed resolution: Hide the contextual 'configure block' link for the page title block.

is a reasonable place to start, and whether it can be done in 8.x?

andypost’s picture

Category: Bug report » Task

Reading current IS is confusing and makes me want to set "Closed (works as designed)"

The only change I see is to hide confusing "Display title" checkbox in block settings for title block.

Everything at page is a block, title is not exception! That means every page block should have common way to configure.

tkoleary’s picture

@wim

I don't quite understand this.

Was kind of a joke. :) You can hide the page title block for one page and then just type a "title" in the body, but obviously that's potentially going to create a strange situation if the typed "title" is altered to diverge from the hidden page title.

Ultimately you should be able to embed the page title block in the body and move it around at will. Re: #23 I was able to get it to work but not every time. I think there are conflicts that have to do with either block visibility (I need to place the block in some region in Seven theme in order to see it in the wysiwyg) or with block instances (I get an error "Entity Embed cannot access the block" after i've placed a couple of instances. I'm going to copy this over to the Entity Embed queue for them to look over.

You almost might simply not want to use fields then…

Unless you want to use fields because you want something, an image, for instance, that appears halfway down the article, to be the image in the teaser.

tkoleary’s picture

Category: Task » Bug report

@andypost

That means every page block should have common way to configure.

That is not how the user understands this. The page title is part of the content, and as such when the user goes to edit it their first expectation is without doubt that they are changing something that will effect this piece of content only.

If you re-read the scenario you will see that—though somewhat complex—it clearly illustrates that an author or editor could easily inadvertently hide many or all of the page titles on their site. That kind of experience is most definitely a major usability bug.

andypost’s picture

@tkoleary Thanx, that explains better then summary I read twice.

So that mostly related to inline editing then blocks and contextual... and I'm sure that editors that going to that is not familiar with drupal, so they just need better docs about using Drupal and a page organization

mallezie’s picture

Issue summary: View changes

Updated IS, since last comments showed it wasn't clear yet.

tkoleary’s picture

@andypost

Well, yes, I've been told that I can be overly obtuse and long-winded in my descriptions. :)

andypost’s picture

@tkoleary the main reason I worried is that JS hard to maintain and test yet, that's why I'm to creep the scope

dawehner’s picture

Well, yes, I've been told that I can be overly obtuse and long-winded in my descriptions. :)

Well, the problem is that for any native english speaking person, this is like a trivial thing, but for people like @andypost and myself,
but actually much more to new people, it introduces a certain barrier to contributing

xjm’s picture

Issue tags: +Needs screenshots

Picture worth a thousand words and all.

yoroy’s picture

Version: 8.0.x-dev » 8.2.x-dev
alexpott’s picture

Issue tags: +Triaged D8 major

Discussed with @xjm and @catch. We agreed this is a major usability bug as contextual links are supposed to make things easier not harder.

tkoleary’s picture

This may be a good place to try out the "build" toggle Preston So has suggested. It extends beyond just the "page title" block but that block is just one example of what is really a broader problem.

Preston's idea was basically divid up the contextual links into "build" and "edit" tasks and have a "build" toggle next to the edit button that switches over to the build tasks. Importantly it's task, not role based which could quickly become confusing (though the "build" toggle itself may be configured to be hidden for some roles).

Examples:

Edit:

  • Edit content
  • Edit custom block content
  • Add content

Build:

  • Add/configure/delete block
  • Add/configure/delete view
  • Add/configure/delete menu
dbjpanda’s picture

dbjpanda’s picture

dbjpanda’s picture

Issue summary: View changes
FileSize
9.65 KB

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.