Change Name of "Page" Content-Type to "Basic Page"

Maybe rename it to "Basic Page" so that people understand it's not the only type of page, but is just the basic way to create a new page on the site?

Maybe it's how your using it that is confusing. I'm no Drupler but I always explain it as something that doesn't change and has a static address.

Where I've found the confusion comes in is saying it's similar to a story. This is how I explain it in WordPress as well. Yes it doesn't have to fit my definition, however I've found that creating additional content types so that a Page is only used as a Page (doesn't change often and has a static address) seems to be understandable. This helped me to understand as well.

The following is very clearly written when you go to add new content ( Drupal 7 dev version)

# Article
Use articles for time-specific content like news, press releases or blog posts.

# Page
Use pages for your static content, such as an 'About us' page.

The accompanying texts clarify the use, and if they not the text can be easily changed for your clients according as you feel appropriate. Probably the introduction of 'Article' and the descriptive texts came after much debates and discussions.

That said, very personally I believe Story was quite OK, irrespective of what the user tests may have said, and Page may have been better called Article. Story better in the sense, that what hits front page or headline are called Stories, top stories are common terms in real world.

When you enable blog which is not enabled by default, these texts become

* Article
Use articles for time-specific content like news, press releases or blog posts.
* Blog entry
Use for multi-user blogs. Every user gets a personal blog.
* Page
Use pages for your static content, such as an 'About us' page.

Now this gets somewhat confusing as Article is stated to be for 'blog posts' and again Blog entry is for blog. What was probably meant was blog posts in Article is for single user blog posts.

In final thought what I feel is little longish names are the best - they will probably be never accepted because they are two words long (wait! Blog entry is also two word, hmm, but perhaps not that longish?) - these longish names are longish but they offer best clarity and brevity

# Front-page content
Use for what you show on your front page assuming that a standard home page is your front page

# Other contents
Use for other pages like 'About us' 'Contact us' 'FAQ' and you can link these from the menu

For most users "Article ~= Story". If we had both Story and Article on a site I think it would drastically increase confusion.

I don't think "page" is a great word, but I can't think of anything better.

I'm -1 on the idea of changing away from page until we get something better.

So, when you have Blog enabled also, this finally looks like

# Front-page content
Use for what you show on your front page assuming that a standard home page is your front page

#Blog entry
Use for multi-user blogs. Every user gets a personal blog, in which each new post is a Blog entry.

# Other contents
Use for other pages like 'About us' 'Contact us' 'FAQ' and you can link these from the menu

When I was a fresh newbie I found Drupal's structure of contents most helpful - it helped to instantly create front page matters, set per-user blogs, create wiki, and create a forum.

"no content-types pre-configured" is very problematic. It fails to directly provide "Add content" (Add content link or button) and folks keep on wondering what to do. Users are familiar with filling a box with title and some content and that's it. Not everybody is developer-minded or learner-minded. If they are at all confused by the Story/Article/Page enigma this phase passes off soon. Any other phase takes longer or can take longer or may be impassable pushing them to other less complex CMSes.

Any thing in Drupal whether it is a content of any content-type or whether it is Views (but is Views exactly for newbies we are discussing?) or OG or whatever can be promoted to front page, CAN BE, but that is not the default behavior. The default behavior is Article is promoted to front page, Page is not.

"Front-page content" (not "front-page") stands for that "workflow and byline defaults" and the accompanying text "Use for what you show on your front page assuming that a standard home page is your front page" details or explains that a little bit more.

Is there any typical common use of Article other than front page? Obviously one can create Articles and disable front page promotion so that they appear as Pages but at first go telling or explaining this is complex.

So may be then, based on what you find terrible, things should be

# Article
Use articles for content like news, announcements, top stories. By default these appear on front page.

#Blog entry
Use for multi-user blogs. Every user gets a personal blog, in which each new post is a Blog entry.

# Other contents
Use for other pages like 'About us' 'Contact us' 'FAQ' and you can link these from the menu

Bottom line is this: All the descriptions of what makes a page a page, and an article an article are subjective to the settings for each content type. Also these types may be freely deleted and changed and replaced. Therefore:

What this issue is really about is that some users don't understand what creating a new Page on their website means. To me this falls under the duty of the descriptive text to clarify the role of these different content types.

I would also give renaming 'page' a huge -1. You just aren't going to find something that fits better. Extending the descriptive text is a different story.

I few weeks ago, I was talking to one of our interns and trying to explain a particular issue. I realized that I used the word "page" three times in one sentence to refer to three different things. (I believe page node type, page.tpl.php, and the $page flag in node rendering.) I've been meaning to submit an issue about it but keep forgetting, so thanks Shai for beating me to it! :-)

At Palantir, our old CMS used the term "General page" for what Drupal calls "Page" nodes. I'm torn on eliminating the "page" word entirely. For a first time user it does give some indication of where to get started, even if it's slightly misleading.

Perhaps "General content"?

We did indeed see in usability testing that the word "Page" confuses people. Primarily, it confuses people who are used to a "Page" being something in a tool like Dreamweaver or Front Page: everything from the top-left corner of the browser window to the bottom-right. A "web page" on the Internet is inclusive of the header, sidebars, etc. Not just the page content.

That being said, I am honestly not sure what we would change it to. "Static content" would be technically accurate, but a tremendous WTF for both new and existing users. WordPress also uses "Page" just as Drupal does, so there is support out there for our current wording.

Primarily, this seems to be an education issue with people not grasping the difference between a dynanic content management system that runs chunks of content through a site-wide template and a static HTML site where each individual page is independently its own thing. Our best bet is likely to try and make this distinction more clear to newbies, although I'm not sure the description of the Page type is the best place to do it.

As I said I as newbie, or even those whom I know, as newbies had NO problem with "Page" or even "Story". The killing of Story is very sad to me , and if Page is killed it will be sadder.

I am not sure about Static content, because apart from English, in several other languages it will mean something that cannot be ever edited again, while in practice the use cases of Page like About us or FAQ can change or often change.

I will rather go for
# Other contents
Use for other pages like 'About us' 'Contact us' 'FAQ' and you can link these from the menu

and yes, the descriptive text is important because that is an important guide here, and precisely that can represent the most use of the Page like creating an About us and linking from menu.

The other way for going is describing everything as Page and assigning it numbers BUT with fuller descriptive texts - this is a cold laboratory way. Like

--------------------
# Page Type 1
Use for articles for content like news, announcements, top stories. By default these appear on front page.

# Page Type 2
Use for multi-user blogs. Every user gets a personal blog, in which each new post is a Blog entry.

# Page Type 3
Use for other pages like 'About us' 'Contact us' 'FAQ' and you can link these from your site's menu

You can also create your own Page type by creating your own field labels, fields etc [here] or by clicking the tab at top right. You can create front-page publish option for any of these you wish.

------------------

Oh Yes, WP using it means many users are already familiar with the word Page and what it does. And Drupal can stay well with Page.

I think both "page" and "story" are pretty clear and easy to follow. Page is for everything that is not a story and other types ie general info page, etc. A story is something that you tell or share, like a blog post, article, etc.

I vote for leaving them as they are :)

@espirates - Info page is also something that is shared :) BUT Story has been already been changed to the much colder word Article in Drupal 7 dev version. Is there any vote ?! If so I also do the same as you - leave them as they are :)

We have real-world testing data from various university usability studies to show that story was confusing and article was not. I don't see a reason to reverse this decision, no.

ok :)
No problem. I was just saying what espirates said - "vote"
While other CMSes do have excellent vote options from front page for such issues and which actually brings MORE real world data than university studies in certain cases, Drupal keeps out vote which I believe have been kept out for good and sufficient reasons.

Article is already in Drupal 7, and I do not think anything much is coming out of this issue, so I said "If there is any vote" :)

Some facts -

Two large CMSes - WP and Elgg ,and perhaps many others, already use the word Page.

When I post a front page Story (Article) that acts as announcement (and indeed Announcement posts are made in the home page often) I am serving some vital Info ( Information, the way you mean it) . So this is in conflict - what do I use Story (Article) or Page/Info to serve a piece of info/information ?

Edited - to remove the wrong message by me on Info

Some facts -

Two large CMSes - WP and Elgg ,and perhaps many others, already use the word Page.

When I post a front page Story (Article) that acts as announcement (and indeed Announcement posts are made in the home page often) I am serving some vital Info ( Information, the way you mean it) . So this is in conflict - what do I use Story (Article) or Page/Info to serve a piece of info/information ?

I think Page can be confusing for some (it wasn't for me personally) but what is better? I don't believe that using 'Info' will help at all.

@kaakuu I think trying to use the notion that Info means informal is off the mark. Info is in common use as an abbreviation for Information. I don't believe that this should be an argument against using Info.

Why I don't believe that Info is the right solution is that you could put many things on this page that isn't considered Information.

I think in the end that despite the confusion around Page, there isn't a better alternative that I can see. Better documentation of the content types for new users could be a way forward.

If there was to be no content types as default, what about a walk through for first time users as part of the install process? They could select from "predefined content types" and get what exists now (perhaps with additional explanation of the content types) or "create their own". It might be a good option for developers who usually delete the default types to start afresh. When creating their first new content type, extended help could be provided.

Why is "Page" needed at all? People can create an "About" page using the "article" content-type. Just uncheck "promote to front" and add it to your primary links? Voila

It sort of messes the site's structure, when I list contents of content-type Story or make a search on the type Story - this "page" will also show up, which is not what I may want.

Which is why that is already done for me by the default install :)

It is good that I have to take minimal steps in those directions and devote MORE time to get real contents and users for my site.

I agree that the goal of the default installation profile is to remove steps that the majority of site builders are going to do, not add to them.

Shai, you say:

Why is "Page" needed at all? People can create an "About" page using the "article" content-type. Just uncheck "promote to front" and add it to your primary links? Voila.

Sure, for you and I it's "just" a matter of unchecking promote to front page and adding it to the primary links. But try watching a new user attempt to figure this out on their own.

a) They have no idea what menus are.
b) Let alone the distinction between primary and secondary links.
c) They don't know that nodes have publishing options.
d) Even if they do manage to figure that much out, they have no idea what "promote to front page" actually means.
e) They will not be able to recover from the situation of their About Us content showing up in the same list as their "Hot deals this weekend" content.
f) They will also have no idea how to shut off the annoying "Submitted by admin on 2009/06/13" from the top which makes no sense on static content.
g) So their first experience with Drupal will be wandering aimlessly around the admin panel for 20-30 minutes being frustrated.

It used to be that Story and Page were the same. Over the past few releases we've been steadily making them different, to conform to what we've widely seen are user expectations for how these two types of content should differ from one another. I don't see a compelling reason to reverse this direction, especially given that competing CMSes offer the distinction between "Blog" or "Article" and "Page" out of the box, so users will expect to see this here.

Re: most of #28:

I've no problem expanding the documentation for new users. But why are you advocating un-doing progress we've made in matching end-user expectations with the difference between a 'Page' and a 'Story/Article' instead of advocating that Drupal ships with a page like http://support.wordpress.com/post-vs-page/ which explains the difference, as well as the fact that these options are configurable? Seems like that way we could help people with the learning curve and not break the mental model of people coming to Drupal from other CMSes, and not create a bunch of annoying extra work for people who already know what they're doing (and the difference between Page/Article) and just want to use the Default profile as a starting point for their site.

We shouldn't be asking the question, "What is the best name of a content-type for 'About' pages and their ilk?" Rather, we should be asking the question, "What is the least bad alternative to replace 'Page' because we know it is confusing?"

Crell's concerns from #11 and reiterated and elaborated by me in #18 have not been addressed.

AFAIK, every reply has addressed this. They've all basically said, "Yep, it sure is confusing, but 'Page' is what users expect to see based on their experiences with other CMS platforms, so I do not support changing it."

Crell's #11 is dealing with themer-related WTFs. I've no argument that the distinction between page.tpl.php, node-page.tpl.php and $page are confusing. I have a big argument with the presumption that the way to solve this is to introduce a WTF to every end-user of Drupal because the theme system is confusing. No, thanks.

#18 gives a good run-down of many places where we could try and come up with a new word to mean "this entire thing in my browser window" (maybe 'screen' or 'web page'?). However, that doesn't support changing the content type 'Page' (a word instantly recognizable to every end user) to 'Info' (an ambiguous word that doesn't remotely describe what it does and the default configuration differences therein).

is less likely to happen because of the new "Find Content" link.

Find content link was always there, perhaps in a more simpler "Content" link. It may have helped university test users but the bar is a toggle bar which will already be disabled by Admin menu users, which is among the top 3 or 4 highest usage as well as prepacked with vastly advertised distros like Acquia.
Moreover users like me who find it obtrusive because at standard 800 resolutions it occupies almost 1/3rd of screen real estate with other chrome with lots of useless empty and depressing grey space just toggle it off :)

What can help here is either a longish name or the accompanying descriptive text as suggested above like making the descriptive text
"Make pages like About us, Contact, FAQ and you link these from the menu"

What can help here is a little more intelligent status message after the Page is created - instead of 'your page has been created', it should be like "your page has been created, if you have not already linked it to the menu, you may want to do so, so that your users can actually see the page."

Change Name of "Page" Content-Type to "Info" or "General Content"

Stories are general content, specially all the stories that are not sticky. Typical "about us" page is other content or sometimes even special content.

Wordpress or Elgg (its a giant too) or e107 or others using Page does not mean we have to use it but the fact that its usage is somewhat confirmed and accepted in the net.

"Page" is simply confusing, because it uses a word that already has common usage in referring to websites: page in a more general sense, having a distinct URL.

In common parlance, "page" is used to refer to what in Drupal we might call a view, a panel, a profile, an admin screen. Using the word "page" to describe a pre-existing node type just asks for confusion.

Call it "static". Call it "example". Call it "node". Since nodes is nodes is nodes, I'm not sure what to call it, but I do believe that calling it something that gets confused with something else is a mistake.

And this is Drupal, where past practice has not prevented improvements and sometimes radical changes.

+1 to changing it. Big time!

@Laura

Call it "static". Call it "example". Call it "node".

Compare this two

Please visit our "About us" page
Please visit the "Contact us" page
Please visit the FAQ page

and

Please visit our About us "static"/ "example"/ "node".
Please visit the "Contact us" "static"/ "example"/ "node".
Please visit the FAQ "static"/ "example"/ "node".

You see Page is in common use and Page in Drupal actually helps to create that type of Page.

@kaakuu Your examples are precisely why I feel the "page" node type should be renamed or dropped.

"Contact us" page is actually not a node, it's a contact form generated by a different module. "Page" node does not create this.

"FAQ" page is not a node, it's a view or a custom display page generated by the FAQ module. "Page" node does not normally create this.

"About us" page might be a node, but doesn't have to be.

You see, calling all the different URLs on a website "page" is something everybody does. Having a "page" node type misleads, and adds to confusion. Just look at how this thread is going. People are having to qualify what they mean by "page" all the time. It's confusing as hell! @crell is right on this.

@Laura

Your examples are precisely why I feel the "page" node type should be renamed or dropped.

I beg to disagree. Precisely I feel for those examples and other reasons as well Page may continue if not some terms like "Other content"

"Contact us" page is actually not a node, it's a contact form generated by a different module. "Page" node does not create this.

When you use a form it can be a form. In many cases its a Page in html that writes the brick-and-mortar address of a company, names and emails of contact departments, list of relevant phone numbers etc, perhaps the link to the contact form and sometimes even a link to chat.

"FAQ" page is not a node, it's a view or a custom display page generated by the FAQ module. "Page" node does not normally create this.

A small to medium sized FAQ or FAQ on a brochure site is a Page. I have never used FAQ module, which in any case is used by a meager 7000 or so users, considering FAQ is there almost on all sites

"About us" page might be a node, but doesn't have to be.

Nothing has to be this or that BUT it usually is :)

Is there any concrete suggestion from you like #7 or #13 ?

If you suggest at this stage you should suggest something concrete, the exact word you want, and then it can be debated if that word serves the purpose better than the word 'Page'

Of all the suggestions, I think "static" is the best. Either that, or drop "page" and don't replace it at all.

Keeping "page" just gives people a false sense of what "page" does because it conflates the node concept with the already much more prevalent concept that a web "page" is anything you find at a unique URL.

I will again reiterate my recommendation for "General content". It has no built-in implication of what it is or does other than "blob of stuff", which is precisely what "page" nodes are currently. It really cannot be confused with any other part of Drupal. And it introduces the concept of "content", which we hammer people with throughout the rest of the admin.

Perhaps we should ask Leisa to weigh in here, seeing as how she does this professionally and most of the people in this thread do not. :-)

I could go with @crell's suggestion of "general content" for the reasons he states.

This issue has changed title so many times which perhaps show how unstable all these new names can be.
Can there be anything more professional than hugely successful CMSes like WP, Elgg, e107 etc? I think their usage of Page is proof-of-concept that this works. They must have passed through intense external or internal debates to reach this usage. "General content" on final thought does not appeal to me as general content can apply to all the stories in a site OR textual content as in contrast to media content.
Page in Drupal allows to add selective sections like About us or Contact etc which are rather not general but components with those distinct heads (About, Contact etc) and contents of highly selective purposes.

@#19

kaakuu stated:

Info is actually short form of Informal - http://dictionary.reference.com/browse/info
while About us or Contact us are formal data

Just as a clarification, the term "info" does not stand for "informal." As stated on the page that they referenced, it is an informal word meaning "information."

@scoutbaker - I apologize. That has been removed by me. Since that will be no longer in this thread there is no point in further bringing that up :)

I have already said why I do not favor "General Content" and why/how "Page" is in very common usage in the CMS world.

There is no "Views" in the other CMS, though WP is reaching something like that via Pods but that is a "probably" and out of scope for this discussion. What I believe about Views and Page is that it is

# Views is more intuitive than one having to go to create a content-type just after install
# the user has already learned some Drupal ways when he is into Views
# the user wants to setup some webpages instantly after install and he may not be in a need or mood to learn
# views is often managed by more of developer-built sites or those who have financial support to hire
# default Drupal should be very easy for the masses like install, click, add content AND not a teaching room at the outset
# I even believe that default Drupal should start the add content page with 5 types - Story, Blog, Book, Forum, Page - making lesser options or being "lightweight" is counter-intuitive and counter productive here BUT this again are my personal beliefs and out of scope of this thread

I am fine with "Page" OR "Other contents" but possibly not with General content

Leaving out the names BUT keeping a good description and asking to fill up the name at the time when you visit the Add Content page (as opposed to the time of install) can be another option of course :) with suggestion of possible names in the descriptive texts.

96,000 + web sites pinged drupal.org and reported they have the Views module for Drupal 6 turned on

On an average there are 170,000 plus Drupal users very month. How many have complained about "Page"?
Test beds can sometimes create notoriously non issues out of issues. Your experience with users or test users who came to learn Drupal can vary widely with mine.

-1 for me. I already have a major site that will have trouble because it has a content type named "article." The only saving grace is that Aquia is probably going to have to fix it.

There is some historical "baggage" that should remain, and the content type names is one of them.

"-1 for me. I already have a major site that will have trouble because it has a content type named "article." The only saving grace is that Aquia is probably going to have to fix it."

Nothing changes on update. This change is only for new Drupal sites who choose the "Default" installation profile during installation. Same as the change discussed here. There is absolutely nothing that stops anyone from using the "Expert" profile and not making a "Page" type at all.

"What other CMSes do" is, honestly, not a big concern to me. OK, WP uses the word "page". Do they use it in the same way we do? Do we know if they have usability issues with their usage of it? Does the question even apply given that WP and Drupal are extremely different systems with different workflows they're optimized for, despite the trade press always talking about Joomla, WP, and Drupal as if they were identical open source offerings?

No, we don't know that. What we do know is that we have both experimental and anecdotal evidence that "Page" is a poor name for a node type in Drupal as it is far too overloaded a word in Drupal. To me, the only question is what we change it to, not whether or not we change it. For that, to be honest, I will defer to someone who actually has training or experience in usability over the "will of the mob", as the mob tends to suck at usability decisions. (I actually do have training in usability, but haven't worked in that field in long enough that I am admittedly rusty.)

over the "will of the mob", as the mob tends to suck at usability decisions.

LOL. Are we just mob and nothing else? Do we suck at usability decisions? I wonder and so does some real contributors. "Mob" gave you the CMS, "mob" uses the CMS either freely or helps drupal firms make money, and the "mob" has so far no significant complaint on the term "Page"

This thread is going nowhere and I think I have made some good points, which in summary are

# Keep Page as it is, or
# Make it "Other contents" with proper descriptive text & status message to add it to menu, or
# Keep the name blank with a good blob of text and suggestive names, asking to fill it up at the time of visit to Add content page, with show/hide descriptive text options

I will now stick out of this addictive issue or similar addictive but non-productive-for-me issues and will be more interested in what I can get for my ultimate end users whose participation make or break a site.

Peace and cheers!

Honestly, what we probably need are some "real world" user tests with Drupal and several different options, and then try and derive from that what caused the least / most confusion among a wide range of users, but especially including those who had never used Drupal before. My hunch based on my participation in other tests of this nature is that people coming from other CMSes (and people who get frustrated with the limitations of WP and come to Drupal in search of something more flexible is a non-trivial amount of our audience) will not understand what to do if they can't scan for the word "Page". My other hunch is that "General content" or "Info" will not make this initial confusion problem any better, and will only raise even more questions. But the bottom line is we won't know without real-world testing, unless Leisa & co. have a quick "Oh, we already have data for this and it's blah" answer.

However, since this ultimately whatever we decide here is at best just going to change a string, and there are literally hundreds of other issues in the queue that involve more far-reaching changes and therefore need to be resolved before 9/1 or not at all for D7, it'd be lovely to see even 1/1000th of the ferocious energy going into this issue on some of the other, more pressing issues in the queue. This issue can always be revisited after code freeze, and maybe some of the folks strongly advocating for a change can head up some crowd-sourced usability testing.

Amen to that, webchick!

Today is the first time I have done more than skim each message of this thread as it popped into my "In" box. Having just now read this thread from top to bottom, I am quite amazed to note how strongly people insist that "Page" be changed to one thing or another — not that we look for a better term for "Page," but that this specific word be chosen.

"Let us vote!" some have said. "We use this all the time; we should be the ones to decide!"

No, not really. I still have a ton to learn about setting up and managing the back end of Web sites, but one field I do know fairly well is usability testing. I'm not the world's foremost expert in usability testing, but it is a large part of what I do in my day job. And the first lesson usability testing offers each of us who dabbles in site design is that performance trumps preference every time.

A vote will tell us what all the people who participate in that poll prefer. Every usability expert has a plethora of tales of sites gone wrong because they were designed according to the users' stated preferences. In other words, when people who use a program or Web site a lot say, "It would be better if it were designed this way," they are usually wrong. Not only does it turn out to be worse for other users, but frequently — perhaps usually — it turns out to be worse for the people who suggested that specific "improvement" themselves.

I admire the approach the Drupal community has taken in moving from D5 and D6 to D7:

1. Through valid usability testing, find out whether the current setup works.
2. To the extent that is doesn't work, identify the problems and their source.
3. Prioritize those problems according to their impact on usability and the likelihood of solving them.
4. Identify potential solutions to those problems.
5. Finally, test those proposed solutions just as the original setup was tested.
6. If a proposed solution proves its worth, implement it. Otherwise, continue identifying potential solutions and testing them until something truly better than the original setup is found.

Admittedly, this process has not been followed exclusively, but it seems to me that the community has been remarkably consistent in following it. Together, the third and sixth steps of this process have made the work towards D7 a purposeful march towards excellence rather than a helter-skelter scamper through the wilderness.

And webchick is right that we should follow the same process here.

Is "Page" a terrible label? Probably. It still gives me a "WTF?" moment.

Would "Info" or "General Content" be better? Not likely. In this short discussion, we have seen that each gives at least a few of us "WTF?" moments of their own.

But, more to the point, there is not one bit of information obtained through valid usability testing that says either of those terms — or anything else, for that matter — would work better than "Page." And each word proposed needs to pass that testing not only in English but also when translated into literally a world of other languages, to ensure that no developers will be more confused by the new term than they are now.

Which might leave us to conclude that "Page" is to Drupal what Winston Churchill said democracy is to government: the worst possible option, except for all the others.

Let's not change it until we know that our change will actually be an improvement.

Honestly, what we probably need are some "real world" user tests with Drupal and several different options, and then try and derive from that what caused the least / most confusion among a wide range of users, but especially including those who had never used Drupal before.
-webchick

My usability anecdata on this comes from dealing with clients for whom Drupal is new, plus working with Drupal-expert colleagues in discussing site architecture.

"This page is a view. This page is a panel. This page is a profile. This page is a page."

Huh?

We end up stumbling over the words. The words get in the way of the concepts we're trying to communicate. "Yeah, but you didn't come up with the better solution!" Okay, but maybe we're asking the wrong question.

Nodes are nodes and not fish. When talking about pages we constantly and repeatedly have to clarify what kind of "page" we're talking about. Why? Because Drupal, which has in many ways reinvented how websites are architected, clings to a 1994 concept of a web "page" and applies it to a node type, which is not by any definition a web page. That node type is still a node, still can be embedded into views, panels, blocks and so on. And can contain views and fields and even other pages (as in page nodes). A node simply is not a page, even though it can pretend to be.

If we really need a page object (as in an object with a unique URI that is the only way it can be consumed) then that's a separate issue.

@webchick and others -

I have been using Drupal for some time now and I still find the fact that it is called a page very confusing. Page implies (to me and I think others) the whole unit. I think that something like Page Content or General Content would work very well. Many of us probably change the names of content types to fit our specific implementations but we need to find something that is intuitive out of the box. General Content or Just Content would get my vote.

I'm not really interested at all in votes, I'm interested in data.

Set up a Drupal site with two content types: {whatever} and Article. Tell someone who's never used Drupal before to create an "About us" page. Video tape their screen/voice while they're doing it (with their consent), take notes on what happened, and put it on YouTube so the rest of us can see.

@webchick: Is this how "Article" was chosen? I personally was shocked and confused by it the first time I saw it.

The fact is that there really is no difference between "Article" and "Page" (or whatever you choose), so is it even really necessary to have two content types by default? What would happen to your test if there was no choice to have to make? I'm going to hazard a guess that the new Drupal user would actually be much happier not making the choice at all. And the experienced Drupal user is probably converting a site and may be really confused that all his/her "Story" content is now called "Article" and "Page" content is something else -- unless the old types are not converted (I haven't tried an upgrade yet).

@webchick: Is this how "Article" was chosen? I personally was shocked and confused by it the first time I saw it.

This change had consensus by basically everyone in the issue, and was further backed up by formal usability studies, yes.

The fact is that there really is no difference between "Article" and "Page" (or whatever you choose), so is it even really necessary to have two content types by default?

There are differences. Page doesn't promote to front page, has authoring info turned off, and doesn't allow comments. If #351249: Finer control over the Parent Menu select box gets in with a 'required' checkbox, I would love to apply that to Page as well (and remove menu selection from article). Every site I've ever built has needed a content type with exactly these features, so I see no particular reason to give people more work to do out of the box.

My experiences are different, but that's fine. Perhaps, then the key to a name is in the settings choices (as there is still no difference in the content type itself).

NancyDru: Existing sites will be unaffected by Story->Article and by anything that happens as a result of this issue as well. This is just the default install profile, nothing else.

Cliff: As both you and webchick have noted, while we seem to have a data that "Page" is a poor name we don't have good data on what a better name would be. Since you work in web usability, would you be able to put together some testing to determine a better name? I'd rather not leave this until the next time we have a big sponsored usability lab available, as there will be legitimately larger fish to fry at that point.

And then there is the problem for converted sites that already have "story" and "page" that will continue to exist and confuse people... Oh, well...

I'll say I'm perfectly happy with the word "page" as used by Drupal. It's used in many other platforms and is, in my mind, perfectly understandable. (And the help text in the 'node/add' page works well.)

Other terms just seem clumsy. "Static Content" "General Page" "General Content" "Sergeant Node" - I can see more problems coming from a name change than without. Do they really mean anything differently than "page" to most users?

Since the first release that "Page" was part of Drupal, has it been a showstopper for anyone? Do people look at it and say "Oh, a page. I don't know what to do. Guess I'll have to try Joomla."

It really does seem like much ado about nothing.

As for changing "story" to "article" that I can agree with.

Most of my clients are not at all computer literate. I have one who continued to add pages to WP instead of a blog post. You think taxonomy is hard to explain, I still can't get her to understand the difference between tag & category. This isn't someone who's going to come to Drupal anytime soon. However I finally was able to explain the page versus post, by saying "a page doesn't change, and nothing drops on top of it."

I guess the point I'm trying to make is the initial word is for someone who doesn't want to read a ton of information, they just want their site up. Is it really going to confuse someone who understands that everything is a node and what you call it doesn't matter? Or someone who wants to understand how it actually works? I don't think so. Anyone to already understands, it matters not at all, anyone who wants to understand can find the information.

Someone with no understanding of how Drupal works doesn't understand that there is actually no page in existence that it's built when it's accessed. They think it's a "page" sitting somewhere. Here are some of the terms I've heard:
Yeah I just want a standard page
a regular page
you know just a page

This doesn't mean they won't learn about it, but they don't want to learn 1st. They just want to put something together and feel like they have accomplished something.

They also barely have an understanding of the word content.

For the person that wants to understand, there is plenty of information out there. I think the word page works for someone who doesn't understand the structure.

I believe the majority of people I work with would understand:
Use pages for your static content, such as an 'About us' page.

I however would remove the words time-specific from:
Use articles for time-specific content like news, press releases or blog posts.

WTF is time-specific ;-)

Yes, I was much like that when I first came to Drupal with a static HTML site to convert. "Page" made more sense to me than "story" at the time. It wasn't until I finally figured out a simple taxonomy that "story" made any sense to me. But I still didn't want anything being promoted to the front "page" because that was originally supposed to be static; as a matter of fact, on that site, other than some blocks, that page is still largely static, although it is now a "story" and there are two other little "story" pieces (also pretty much static) that have joined it.

@Crell (#60): Doubtful that I would have time and resources to orchestrate that test, but I'll mull it over. Who knows what I might think of?

@laura s (#54): I hope you'll take the next-to-last paragraph of that post and work the gist of it into Drupal docs wherever it is that we explain what a "node" is. That would help so many newbies — and seasoned vets — get it. (In fact, I think I just did. Now could you come up with something for "taxonomy"?)

Oh, and I just now finally learned what "My issues" was all about, so I'll be following discussion less haphazardly now.

I think you can kill "Page" because "Story" makes sense (it's a real content-type) and if page wasn't an option, Story (or "article") would solve the problem.

Want to build a page that shows textual content... that's an article (which is a better title than "Story" in my opinion).

Want to build a page that is a view of diverse node types? That's a page-view. It could include stories, no problem.

Then you'd have story.tpl.php view-something-or-other.tpl.php and page.tpl.php (page.tpl.php denoting the DISPLAY VEHICLE as you mentioned).

To me it's a no-brainer. If we were starting over from scratch, "Page" would not likely be even discussed as a content-type along side story, event, etc.

That's my $0.02!

-1

This is a silly idea - webchick is absolutely right way up there about gradually building expectations of what each of the core content types are.

@Shai, the only thing that needs to change is people's concept about what a 'page' is from a CMS point of view.

It's not silly. At all. It's about removing ambiguous choices that get in the way and cause mental friction, especially for new users, especially on first time use. These unnecessary choices are exactly what makes Drupal hard to use for newbies. In that sense this is not a trivial issue, either.

…the only thing that needs to change is people's concept about what a 'page' is from a CMS point of view.

Right, how is changing the mental model of what a page is in a CMS 'the only thing'? "You know, it's called a page, we know you think about it as a page, but it's not really a page, you only have to think about it differently than you do now, but we'll still call it a page"? How is keeping a content type named 'Page' any help in this? Why make this a problem of the user? Instead we should remove the cause for confusion.

The problem is not in wether it's useful to have a general content type 'page' by default in itself. The problem is that new people don't know which to choose when confronted with the article vs. page choice. Where the page choice has the unfortunate consequence of not being promoted to the front page, effectively making it disappear. The 'find content' link in the toolbar will help with this, but it's still weird behaviour. We should avoid that pitfall.

Even if new users are looking for 'page', it's just to ambiguous a term in a Drupal context. Do we really think that if somebody can't find 'Page', she won't dare to create an 'Article'? It'll be much much easier to choose between 'article' and 'picture' for example.

We're argueing back and forth about the name. There is no good name for this general content container. "General content" is silly and more an expression of Drupal not wanting to make assumptions on usage than a helpful label. Hopelesly politically correct I'd say, only 1 step away from you know, "stuff".

I would still suggest to remove it and maybe, maybe suggest somewhere in the interface text that this might be a first useful content *type* you might want to create yourself.

From a Drupal CMS point of view, a "page" is about four different things. Regardless of what mental model someone comes into Drupal with, that's a WTF.

the page choice has the unfortunate consequence of not being promoted to the front page, effectively making it disappear.

This is OT from the topic of this thread, but I think an ideal solution for this wtf problem (which exists regardless of whether we ship with page or not) is adding a "Required" checkbox to the menu settings at admin/structure/types/manage/XXX. Then it would not be possible to create content that gets totally lost.

I feel that having Article & Page for someone completely new to working in a CMS covers the two type of content that a simple user will want. Whether they are using them correctly or not isn't the issue. The issue imho is will they be able to create what they want to. If they don't understand what a CMS actual is, but know they want something that changes, and adapts, they start from a place of wanting static and non-static. Even if a page content type isn't really static, it will give them the "feel" and actual presentation easily of a static page. I haven't heard a single suggestion that would mean that to someone who doesn't understand that there isn't anything static period. However the feel of that is there with the two default content types. Neither article, story, or general content would sound like what someone wants if they want to create a about page, home page, services page, bio page. Someone new sees these as static, and will not think that they are an article or story, and would have a questioning look on their face on general content. General content? Isn't that what my articles are? General, or do I us that when I don't want to add a tag or category and they are just general information I want to share?

However as page is part of all of those examples of what most people look for to create. I believe they would be less likely to not find what they need, leaving the page a page and not have it promoted.

Uhoh! Looks like a shout-out. ;-)

Although I'm loathe to appeal to WordPress for our decisions, in this case it may be instructive. They use the words 'post' and 'page' in the WordPress UI to distinguish the different content types.

We face a complicated decision for a couple of reasons:

• Creating a node -- regardless of its content type -- does result in a new page being created on the site with the url www.example.com/node/123, or whatever the node ID is.
• Having a particular type of node whose only job is to cause the creation of a standalone page with some static content does make sense -- that's a useful feature regardless of what we call it.
• The confusion (at least as I see it) comes from the fact that creating a 'page' in this way, whether you do it with a Page Node in Drupal or a Page Post in WordPress, comes from the fact that you can't "hijack" the entire page, blowing away the navigation and headers and so on by pasting an entire HTML document into the node's body.

That final part is really a doosie, and it cuts to the heart of the "CMS/Dynamic webapp" question. There aren't really any true static "pages" in something like WordPress, Joomla!, or Drupal. If we rename 'page' we need to keep in mind that while the terminology is confusing, by creating a page node they are creating a page -- but it's a page that automatically gets extras like navigation, headers, and sidebars from the theme without any extra intervention.

I tend towards the idea that better explanation of the term 'page' can help, but unless I'm mistaken D7's "basic stripped down" profile already comes without a page content type -- or is it that it ONLY includes the page content type? I'll need to double check.

The "minimal" profile comes with /no/ content types. Or much of anything, really. :) It's the "framework" version of Drupal.

The "default" profile has both "Page" and "Article" (formerly "Story"). As of yesterday, Page and Article are even more different in the default profile, in that Article now has both a "Tags" and "Image" field, where Page just has Title and Body.

Oh. Something else that's been discussed earlier is adding a dedicated "Image" content type. Unfortunately, I don't see how we can do that until Views (or equivalent) gets into core. That would allow us to ship with a photo gallery, which is the primary use for an image type. In core right now, all you'd get is a front page with mixed images and articles, which is pretty meh.

As for the Views page issue, imho the use of the term page is the same as the use of a content type page. You have a specific place to go (url) to see what it is you are creating. Whether you're creating it with Views, or by creating the content yourself (content type page), you need to give it a url to see it. I don't think it's confusing at all, and personally that's how I understood it when I've used Views. I'm creating content that will be seen as a page even though it doesn't actually exist as a "page." To see a page you need to create a url for it, applies in both these instances.

I'm creating content with the content type Page
I want people to see this content as a (page)

I'm creating content with Views
I want people to see this content as a (page)

Again, once people are familiar with the concept, and creating new content types, they are understanding the concept and what something is called all becomes mute. This comes back to the purpose of my suggestion being for "what are people looking for when they don't understand the basic structure of drupal, and just want to create something."

As for the theme, I don't understand any of that, nor have I ever attempted to change anything, so before even giving an answer I'd have to know what page.tpl.php is and how it's used. If page.page.tpl.php means what a page would look like if it was a page content type or if page.article.tpl.php is for what a page would look like if it was an article content type, then I think again this fits in with the page content type and how many people new to a CMS understand what a "page" is. Having said that, maybe this is the one to change if it doesn't apply to a "page" and what a "page" would look like when it's displayed. I also feel anyone who is going to make changes to any of these files would 1st try to understand what the parts and pieces mean and look for that information. This would not be the person who we are talking about in the above examples. Anyone who understands php and how it applies in themeing understands that we're not dealing with static content, so have a basic understanding of a page isn't really a page i.e. static html e.g. about page, bio, services, etc.

If it needs to be different then the other page's then call it General Page. ;-)

@shai

There is still option that an intermediary can change the word 'page' for her clients. But in English as in many other languages there are plenty of words with double or triple meanings. May be the correction should start from there ? There are more learners of the language than of Drupal.
To me this appears as a geeky concern, apart from 'some test' users or 'some other' users this has not been a real issue as appears from the issue lists. There are much more serious and much more needed concerns, imho. Many of the users are accustomed with 'page', so changing this breaks 'things' for them, many of future users, according to you, will be confused, so not changing will break things for them. Its a 50-50 situation? There are 100-0 situations which needs tackling first, imho.

Continue the debate, I am sorry for the interruption but could not help as this dead issue keeps popping up in the tracker with no means to delete it.

@shai I'm not saying this removes all the confusion. Or solves the disambiguation of the word. To me that is another animal completely. The people I've worked with don't care how something works, or what is making it work. They don't want me to explain it. They just want me to tell them how to do X. What happens to make X works doesn't matter to them. They are focused on their business, don't want to have to learn about something else, they want a website where they can put up their information, and don't want to spend time to understand how it works. I've had a hard time learning how to build in Drupal, I do like to understand, there is no way I would use D6 for any of my current clients and it's why I use WP for them. I'm hoping that D7 is different (and from what I've seen it is). For me and my clients Page works the best of all the suggestions I've seen. I'm not saying it is the best, or it works in other ways for other end users. However the other end users (not someone who doesn't care to learn and/or someone very new to web design/development) the disambiguation of the word page can be explained in documentation, or just further learning of how things work. Better documentation for Drupal is also crucial imho.

I believe page gives a good starting point, and the ability to add other content types solves the other issue where they say well I don't want an article really or a page, then moves to creating something new to use. My experience/suggestions are coming from people who want a blog type content with something that also allows them to have "static" pages. I would love to use Drupal because they also could use the ability to grow beyond both those content types; they hold conferences, events, radio programs, etc. and I know that drupal has the ability to add all of those pieces into a much more full and complex site.

All of this is why I vote no, don't change the name :)

Reading through this issue, it seems like complete agreement is going to be difficult. However, a possible compromise might be to keep "Page" but put an adjective in front...? That way, the word "page" is still there for users who are scanning for it, but it is also distinguishable from the 18 million other uses of the word "page" throughout Drupal.

Looking through this issue for specific suggestions that were already made along those lines (as well as adding a few new ones), we might have:

• Anchor page
• Basic page
• General page
• Informational page
• Page content
• Simple page
• Standalone page
• Static page
• (something else?)

I think that choosing something like one of those would at least help solve the original problem, and in a way that probably still has a shot at getting into Drupal 7 without the massive amounts of usability testing that a move completely away from "page" would likely require.

Or "Standard page".

'Basic page' is good.

- Anchor page
+ Basic page
+ General page
- Informational page
+ Page content
+ Simple page
- Standalone page
- Static page
- Standard page

+ I like, - I don't ;-)
Not sure how we would vote on this. I'm currently leaning toward the terms Basic or Simple page for two reasons. It has the word page in it, and the words basic & simple indicates it's not fancy and might lead someone to ask the question "well what else could I do", which would then bring them back to drupal.org to learn more about adding content types, yet for someone who didn't want to learn more they have what they can use to create a simple or basic page.

I could definitely live with "Basic page," if that's the consensus (which it appears is slowly materializing). It keeps the "keyword" people will be searching for, while differentiating it from the "browser window page" itself.

If we couple this change with keeping "page" as the machine-readable type name, while we don't address Crell's concerns about page.tpl.php vs. node-page.tpl.php confusion, we also don't invalidate 10 years' worth of documentation. It feels pretty late in the cycle to be doing that (though something to perhaps explore in D8), so I'd go with just a change of the human-readable name.

Is changing it in default.install enough then?

Status.

Shai: I'm assuming Webchick refers to documentation in the form of all the Drupal books, blog posts etc.

We are past the point of API changes in D7, so changing the machine-readable name is a no-go. Can revisit in D8.

I'm not sure why the test bot is choking on this patch, but I suspect that there may be tests that are explicitly checking for a link called "Page" or similar.

Yeah, it is pretty unfortunate when you can't change a simple string without breaking 27 tests :( Anyway, this should get most (hopefully all) of them.

Regarding the machine-readable name, it doesn't seem to me like changing that would really constitute an API change? It's added by an install profile, so if there's a module out there that is trying to rely on its existence, they've got serious problems. (Changing it could legitimately break a module's tests, I guess, just like it's now breaking core's, but that seems relatively low risk.)

Yeah, it is the test breakage I'm concerned with. Last I checked, contrib tests were making heavy use of drupalPost('node/add/page', ...) and the like.

If the consensus is that we go with 'basic_page' for the machine readable name, though, I guess we could bloat the size of this patch by another 500K fixing all of the places in core that make this assumption. :P I'm just not sure that page.tpl.php vs. node-basic-page.tpl.php is going to make things sufficiently less confusing to justify the pain.

Oh. And themers have started porting too, so node-page.tpl.php -> node-basic-page.tpl.php screws them as well.

Just wanted to weigh in as another person who feels that "Page" is confusing, for all the reasons mentioned above. I found this thread as I was writing up user documentation on how to create content for a site, and kept stumbling over how to differentiate "Page" the content type from "page" of the site. +1 for disambiguity!

(And as an aside, +1 on article too. When I started using Drupal one of the biggest stumbling blocks for me was what the heck a "story" was and why you would want any content that wasn't a "page" (because I was thinking "web page" not "Drupal content-type page.") Only once I started site building and theming did the difference become clear. So in my mind changing these terms will reduce the learning curve for new folks, both end users and designer/developers.)

"Basic page" works for me. For the machine name, I see webchick's point about not changing the machine name; I suppose I can go either way there. If it changes, though, I would echo Shai's comment that it should not contain a hyphen or underscore. Those are already highly confusing, and I try to avoid them entirely in node machine names. So it's either "Basic page / page" or "Basic page / basicpage".

The latter would be more complete, but I see webchick's point about how large that patch could be at this point as so many things assumes the presence of a node type named "page" for testing code or defaults or such. (Except for one of my modules that presumes the presence of "story" for defaults, which even my sites don't tend to have. Figures. :-) I'll have to change that anyway for D7, but it's an easy change so I'm not particularly worried.)

Basic page works for me too.

I'd tend towards leaving the machine name as is - we have 'Blog entry' / blog already - it can be useful to have views which use the content type machine name as an argument ('page' looks a lot nicer for that than 'basic-page'), updating all those tests will be a pain and potentially break a lot of pending test patches.

The patch in #103 still applies, but didn't come back green for some reason. I'm reuploading it again for testing.

It sounds like there's fairly wide agreement here. If the testbot says it good, can we mark it RTBC?

Yep, test hunks make me sad, but that's not for this issue.

Lets do this

If there is a Basic Page what shall be called Advanced Page ? I mean advanced users or even new users may look for advanced page and find none!

I like the simpler machine name - 'Forum topic' has a machine name of 'forum', this seems fine to me, easier to type, better for views arguments etc.

The template suggestions issue is interesting, but that's a lot further up the learning curve than creating a page then trying to add views or forms to it (as we saw in usability testing) - so I'd rather we got 'Basic page' in - since that doesn't create new WTFs, even if there's possible enhancements to be made in D8 to remove remaining ones left in, given it's already December 1st here.

I agree with that, but it's a developer/themer experience issue as opposed to UX, and we're about six weeks past DX freeze at this point. Changing the machine name also means potentially breaking any contrib module tests which rely on the default profile (quite likely given how many core tests do), so while it's crap that we've had simpletest in core for a year and still have dozens of tests making bad assumptions, I don't think it's worth the potential pain to change the machine name at this point.

Boy, December was a rough month. :P

I'm pretty sure this needs a re-roll. But let's go ahead and try this change this release. (the name change, not the machine-name change)

I don't think it's going to ultimately address the root confusion about the word "page", but it at least gives us one simple way to help clarify meaning: "No, no. BASIC page, not X page..."

testbot, please review :)

Maybe has something to do with this #638496: Random failures in dblog tests ?
I asked for a retest

These were the files he was chanching
*****************************

Index: modules/filter/filter.test
Index: modules/locale/locale.test
Index: modules/node/node.test
Index: modules/php/php.test
Index: modules/search/search.test
Index: modules/taxonomy/taxonomy.test
Index: modules/translation/translation.test
Index: modules/trigger/trigger.test
Index: modules/upload/upload.test
Index: profiles/default/default.install

These are the files you changed
************************
Index: modules/filter/filter.test
Index: modules/locale/locale.test
Index: modules/node/node.test
Index: modules/php/php.test
Index: modules/statistics/statistics.admin.inc
Index: modules/statistics/statistics.pages.inc
Index: modules/taxonomy/taxonomy.test
Index: modules/translation/translation.test
Index: modules/trigger/trigger.test
Index: profiles/standard/standard.install

Different names, different files, so it can be that the file size is different, im gonna check it manually

Ok, the only difference I can see is that the

Index: modules/statistics/statistics.admin.inc
Index: modules/statistics/statistics.pages.inc

are added

and that the search tests are missing (if they still exist)

WTF is wrong with the testbot and the language thing. This is the 4th patch I have to retest...

And i'll review your patches again.

Now everything of #110 is in the patch!
Good job!

This needs a re-roll again (already!). Sorry, but I absolutely had to commit #571654: Revert node titles as fields since that was an major API change.

The 'bundle' comes from the Field API, so I believe it should always be the machine-readable name (i.e., 'page').

Thanks for bringing this one home!

I went ahead and committed this, since we hit a rare period where test bot was happy. :D If there are additional fixes to be made, go ahead and file follow-up patches here.

Great work on this, folks! I think this is a small but important improvement in helping to reduce first-time user confusion. In D8, we can perhaps explore other options to help reduce themer confusion as well.

Just wanted to say thanks to all the people involved in changing the node type name 'Page' to something else.
With some hundered hours of Drupal training behind me I (too) can testify that there are people finding the term confusing.

Interesting reading in this thread!