Terminology: figure out proper words to use in the UI for describing unpopulated layout vs. populated layout

Kevin posted this diagram for our understanding of the current state of things:

Gabor's version is this:

My proposal for the FRONTEND row of Gabor's diagram in #1 is Layout => Populated Layout => Landing Page.

1. This has the advantage that frontend and backend are using same terminology in first column.
2. I like how adding the word 'Populated' teaches the user that it is a layout PLUS some more stuff. I don't think that Template => Layout has the same teachability that Layout => Populated Layout does.
3. We are not overloading the term template. There are templates in Drupal that are not part of the payout system and it is a disservice to everyone to use the same name for things that are slightly different.

Chewing on this a bit more, but here's a copy paste of my initial thoughts in response to Gabors diagram in #1839278: Add layout template demonstration

…
Layout (amount and stacking of regions) -> Master page (or Template) -> Page
So, Layout > Master page > Page, or even
Template > Master page > Page

I imagine that permissions would let you protect editors from having to mess with the first 'layout' layer, leaving them with a Master page from which to create individual pages. Look at powerpoint and indesign for example, they both have this concept of Master pages.

Hmmm.

Of all the possible words to use in this context, I feel 'Layout' is the weakest when used as a noun. A certain layout is more the result from all the work you put into a creating a page then one of the ingredients you added in doing so.

Template > Master page > Page

I'm not fond of the 'landing page' either, it has quite different meanings depending who's talking about them. I understand this comes from the choice to rebrand 'creating content' as 'creating pages', which I'm also very sceptical about.

So… my main points would be:

- Try to avoid having to use 'Layout' as a noun in this triad
- Consider introducing 'Master pages'
- 'Landing pages' is iffy and seems a work-around label because 'page' is given away too early in the creatin stack (replacing 'content')

You create content, it lives on a page, which is based on a master page which is derived from a template.

I would suggest:

Page Template > Master Layout > Layout > Page

"Page Template" makes a distinction with the generic twig(or php) templates

"Page" makes sense because people will use that feature to create more than landing pages. In fact, I would than suggest to get rid of the Static Page content type and recommend to use this new feature to create static pages.

Anyway, these are very exciting developments.

A certain layout is more the result from all the work you put into a creating a page then one of the ingredients you added in doing so.

i agree entirely. which is why i LIKE the new proposal for how "Layout" should be used - which, unfortunately, that diagram might be obfuscating a bit. i'm more happy with it than anything else.

@moshe weitzman - i've been wary of peeing in the waters of the term 'template', especially given that it has ALL this meaning from other systems. but i don't really feel it's my decision to make, either. and when i ran it by JohnAlbin this morning, he was OK with it, because the essence of what's being done in those "template files with regions + metadata" is still very similar to the concept of a template.

the diagram in #1 suggests a relationship between a Layout and a Landing Page that wasn't what we'd discussed before: Landing Pages may clone (or more likely, copy-on-write) Layouts to provide sane defaults, but they do not *inherit* from them. there's just the one level of propagating inheritance, and that's from the master layouts.

@dodorama: depending on how other teams progress, the layout templates (wireframes) introduced might not only be used for laying out pages. They might be used to lay out your node displays as well for example. If that is to happen, "page template" would be a limiting term, since these templates would be used for other things as well. That is not certainly happening in Drupal 8 core though, it might easily happen early in Drupal 8 contrib.

it's also worth noting that the diagram is somewhat misleading in that there could be any number of implementations of 'Landing Page'-like things (inasmuch as they are Layouts placed at a static URL), whereas the earlier parts of the diagram are the stable parts of the API which we do not expect to be extended very much.

put another way, we're describing how one (or maybe two, if you count the red 'Layout' column) particular applications of the system work, not how the API itself works.

The words "layout" and "display" were only introduced to Drupal core code very recently and can still be changed to match terminology that makes UX sense.

strongly agreed. and with respect to Displays, at least, i was explicit from the outset that we could stand to have a better term.

Display vs. Layout vs. Whatever, I defer to the UX folks. We should make that sensible for end-users first, then model the API names accordingly. I don't much care which is which.

I will however echo the sentiment that "template" is already taken, and over-loading it to mean both "a *.html.twig file" and "a collection of a twig file, some meta data, some CSS, and some special markers" depending on context is begging for confusion. The former is already a broadly-understood definition in just about every framework and application in existence; challenging that prior art is a non-starter.

So we know that we're going to have "populated layouts" at the page level, and work is under way to have them at the entity level too.
Those will use the same notion of (unpopulated) layouts (possibly using the same collection, although in practice layouts that actually get used at the page level will be richer than those that get used for entities).

Those two levels will need similar-but-distinct UI screens (blocks admin NG vs. more or less Field UI's current "manage display" view modes config pages). So ideally the name for those would reflect that "similar-but-distinct"aspect.

Methinks "page display" and "entity display" work fairly well on that regard. Fit well in sentences.

Display vs. Layout vs. Whatever, I defer to the UX folks. We should make that sensible for end-users first, then model the API names accordingly. I don't much care which is which.

hear hear.

I will however echo the sentiment that "template" is already taken, and over-loading it to mean both "a *.html.twig file" and "a collection of a twig file, some meta data, some CSS, and some special markers" depending on context is begging for confusion.

yep, i've made the exact same argument. the irony here is that it's all the backend folks who're raising holy hell about this so far. JohnAlbin was cool with it.

we need more frontenders to weigh in.

Methinks "page display" and "entity display" work fairly well on that regard. Fit well in sentences.

no better than "Page Layout" and "Entity Layout", imo.

First, sorry this post is so long. Second, a bit of a preface.

Preface

a) I'm a front-end dev/designer and I don't hate 'template' applying to Gabor's wireframe concept.

b) Can we use user data to help choose our terminology? User research and testing might help us generate new terms and/or evaluate the ones we've come up with.

My 2¢

Our existing terms in this domain include 'layout', 'template' and 'page', and some are pretty fuzzy, as usual :)

'Layout' can mean either 'the arrangement of content on a page, excluding the content' or 'a particular page composition, including the content'. I lean towards the former, but if we can test this with a target audience, we should. Examples:

Cosmo totally stole that layout from Vogue" → arrangement only

That's a gorgeous layout" → the final effect, content and all

'Template' as a lay concept is pretty unambiguous. Common software like Word and PowerPoint provide 'templates': layouts with placeholder content. Example: "No one expects you to be a designer; just use one of Word's templates for your resumé." This is not a bad fit for what Gabor is calling 'populated wireframes'. They are 'layout + customizable content, but not the final thing'.

Finally, 'page'. For most web users, a 'page' is a 'webpage' is, absctractly, 'the content that I see at a given URL'. This seems to fit nicely with the notion of a 'final populated wireframe bound to a URL'. The term 'landing page' to me is confusing, because I think of a landing page as a special-case page designed as an entry point into the site, often from search results or advertising. We should be able to avoid using it here as long as we also avoid a Drupal-wide replacement of 'content' with 'page', which I was horrified to learn about from @yoroy in #3. I'm not just sceptical of that idea, I'm downright pitchfork-and-torch opposed (definitely a discussion for elsewhere).

So all of that thinking leads me to something like this:

layout > page template > page

Using the term 'page template' to refer to a 'populated wireframe' makes sense to me in the 'resumé template' sense. But if we need to differentiate the 'base' page template from a 'derived' page template, we have to be more precise. I independently thought of @yoroy's idea of 'master page', and that has nice symmetry with 'master blocks'. Updating, I got:

layout > master page template > page template > page

'Master page template' is a long-ass term for the root populated wireframe, though :(

I am inclined to agree with the direction of @moshe in #2. But I am also a little biased, because during our discussions I pointed to those terms. However, they seem to accurately describe what this is about - but they are not very slim, as it requires two words.

@yoroy Is correct in stating the "Master" has prominence in other models, I am however concerned that the "layout" is the only thing that triggers an "abstract" concept of layout + things in it. As opposed to something being the actual page. We need to make a really clear dividing line there, as anything with "page" in it - might trigger the expectation that it has a url etc. That label should be reserved only for the level that actually has that.

@Bojhan If I understand, you’re saying you prefer 'populated layout' to 'master page' because anything with 'page' can easily be mistaken for a final page with a URL. That's a good point. Actually, the term 'display' seems like it could have a similar problem.

I've discarded 'page template', too. By contrast with your point, I think that term is too easily interchangable with the unpopulated layout (see #4). Also, I neglected Gabor in #6 and yched in #11 pointing out that layouts could be used at the Entity (e.g. node) level as well. The logical extension of 'page template' for this use case would be '{entity type} template', e.g. 'article template' which really does sound confusing. sdboyer might be right about avoiding the term 'template'.

So, I'm with you: 'populated layout' is starting to sound like a good option (and can apply to both pages and entities).

I think display could work for populated layouts. we are already used to configure showing dynamic data by "displays" as in views and panels.

@dasjo: well, the point of this thread was not to figure out what we are already used to but to figure out what would make most sense :) Based on where the blocks work is going, Views might not have displays in themselves and the layout configuration system could take that role. Not sure we will get there, just trying to put this into perspective.

@Gabor: I get your point.

when comparing populated layout to for example display I feel that it depends on our logical approach.

thinking layout first populated layout is a good term (I just don't like it so much because of its length).

on the other hand I think a more logical approach is thinking content first. then its about configuring what to display and how to display it. applying a layout is part of that process but it will also involve other settings.

edit: @gabor: it is not clear to me, what exactly do you mean by "frontend" vs "backend". all this terminology basically affects drupal's administration interface (i'd call that backend). does this target a specific vocabulary for frontend-developers - if so, how will it affect them differently. or do you mean terminology in-code vs. on the user-interface?

I think #18 is more or less my feeling too.
The current Display is about "what to display, how and where". That's what we're aiming at with EntityDisplays too, btw.
The word "layout", whichever way we put it, is still very attached to the "where" part strictly.
Using "populated layout" to refer to the whole "what / how / where" seems backwards - "look, it's a 'where' with stuff in it" ?

More concretely, and if we come through with EntityDisplays / layouts, whatever word we pick here will be the one that's used on what is currently the "Manage Display" tab in node types UI. "Manage Populated Layouts" would be too long there, and i think "Manage Layouts" would be misleading.

one more note: i think introducing layouts gives site builders power, but should still be considered as a nice-to have / optional part. they will always need to show content in some way. being able to specify a layout shouldn't stand in the way when just wanting to display some content without having to worry about layout. i'd think of that as a default one-column layout being applied. hope i'm not sounding negative here and i'm very happy to see what you folks are creating.

maybe we could clarify the overall intended workflow a bit? to be honest, i'm not entirely familiar with the current plans, they might have changed from what was visible to me over the last months and the workflow that a panels user is used to.

i thought "display" would be a better fit, because as a site builder it seems more logical to me to configure "data sources" & "add pieces of content" in such context. thats like defining the "what". i agree with effulgentsia that layout might fit both "how" and "where".

btw. i'm not advocating for separating those steps. usually we want to add more content to an existing layout later on and the most easiest is if that possible directly from a central ui / i don't have to go back to the "what" step.

one more note: i think introducing layouts gives site builders power, but should still be considered as a nice-to have / optional part. they will always need to show content in some way. being able to specify a layout shouldn't stand in the way when just wanting to display some content without having to worry about layout. i'd think of that as a default one-column layout being applied. hope i'm not sounding negative here and i'm very happy to see what you folks are creating.

it's not optional, not really. this is how we'll be doing text/html.

however, there's a lot more to the system than what's being discussed here; we should keep it that way in order to keep this issue on track.

trying to put it briefly in perspective, though: "just wanting to display some content without worrying about a layout" is roughly equivalent to "just want to show some stuff without using page.tpl.php."

well folks, we're burning the midnight oil, here. we need a decision. or else the decision becomes mine de facto, since i'm writing the code :)

Sam, please do. Maybe re-read #13, 14 & 15 and just make the call.

I haven't had any brainwaves on this. Seconding yotoy’s #27.

I think layout is more associated with placement of content and the multi-word options just confuse matters.

With this in mind I'd go with "Template > Layout" or "Grid > Layout", although template seems like it would have more meaning to users.

I feel like we want to use terms that are short and commonly used. in this sense I think Template, Layout, Page is what we want.
In the backend we already using layout (the wireframes used to place content) and I will stick with it.
What in the backend is now called Display (pre-populated wireframe) are in fact very close to the Twig template files. in this sense I would call them Templates.

So my suggestion would be
Layout > (Master Template) > Template > Page

I feel like there's still a small window for me to weigh in, if it's closed then carry on, I don't want to derail any progress.

I have problems with the terms 'master' and 'display'. 'Master' is used to describe a different relationship in the real world and it's use in Views isn't entirely consistent with the relationship here.

I think prefexing the term with 'layout' is definitely a good choice, it creates a very strong unambiguous relationship between the two.

Pattern

A repeated decorative design.

We can change terminology well past feature freeze.

we can, and if we must, we shall, but i *hate* the thought of that patch. it's class names, it's interfaces, it's docblocks, its config namespaces, its docs on d.o...

we CAN do it. but let's just not have any illusions about how much work it would entail.

Well, #1839278: Add layout template demonstration is already committed, which exposes a UI for "Layouts" as "Templates".

Well, so far this ambiguity on naming has stalled this feature for 2 weeks, and we appear no closer to solving it than we were back on Nov. 15. :(

I really think the only way we're going to figure this out is by getting the UI done and in peoples' faces so we can test it. Without that, I think it's impossible to engage the people who we're worried about being confused over terminology. And yeah, that'll be a 2M patch, but we do have an army of newish contributors who would love to take something like that on, IMO. Test coverage should tell us if they missed anything.

@webchick - yep, it needs to be done and in peoples' faces, with some point in the future at which we revisit naming.

to that end, do we think it best that we defer ANY internal renaming until that point in the future, or that we catch up what we have right now to the current naming with the expectation of changing it again?

I lean towards just leaving things as-is for now, so we can move on this. But http://drupal.org/files/PageTerminology.jpg seems to imply the mis-match in front-end vs. back-end terminology might be a pretty big barrier to contribution so not sure.

IMO keep the proposed frontend "Template > Layout > Page(/Landing page)" and update the backend names to match. At least then we're all on the same page and can understand clearly what everyone is referring to. Then revisit after some user testing.

I am going to RTBC this decision to leave it as is, this is to be revisited after more thorough usability testing. For everyone to keep in mind, this is a temporary decision please don't shout at us when we do decide to change it :)

Uh. I'm unclear on what it currently is that we're leaving it on. :-) We're talking about new functionality we're introducing, so how does it already have a name?

@Crell Inception! I have no idea either, I just noticed angie mentioning its blocking the feature progression so I figured we can always talk labels later.

There's nothing to commit here; I'm not really sure what to do with this. Mark it postponed on blocks as plugins?

Doing that for now.

Oh, well. :\

Is D8 not going to have layouts anymore?

Was really looking forward to this. :`(

I'm going to mark this duplicate of #2811175: [plan] Add layouts to Drupal. If there's something here that needs to be revived for that initiative, it should be re-opened and moved back to 8.x - however things have changed a lot in the meantime.