Remove the 'Page' content type from default install profile

Subscribing. In testing, most people grasped what an 'article' was. Another issue was that some of the more experienced users seemed to be completely locked in to page vs. article - i.e. to promote an article to the front page, they deleted the 'page' and pasted into an 'article' rather than just switching the publishing options. So our descriptions currently lock people in to certain habits rather than showing them the flexibility.

"Some users believe that pages might be containers for articles."

Yeah, let's kill Page. That will make room for these users' conceptual model to be correct.

Agreed. "Page" is the most vague term in the whole web. But what about the use case page currently caters for: static, brochureware type of content ("About" page, "Mission" page etc.)? One of the reasons page exists is it gives a clear signal "we support different types of content for your different needs".

Our means doing this is set Article and Page up with different type descriptions (what users skip), presence of tags, "promote to front page" and "display post information" settings. But most of this differentiation is hidden and do not really provide difference in experience -- meaning users do not perceive Article and Page as we want them to: containers for "quickly updating" and "static" information.

So:
1) We need to show first users that drupal is flexible and allows creating (almost) any type of content
2) Historically we used article and page for this (and before that bunch of other types I am not able to remember)
3) As content types are introduced in D6 and now fields are in core and CCK is likely to follow, the old approach to showcase Drupal's flexible approach to content with just 2 preset content types hides most of Drupal potential.
4) We need something better but what? I am not sure providing tiny link here and there will cut it, the promotion of Drupal's content types should be integral part of install/1st user experience. Should it be part of setup wizard | welcome page | node/add?

So, +1 removing Page type, but in needs to be replaced by "that something" what properly promotes Drupal Content Power.

Subscribing. I love this idea. The concept of page is completely vague and can mean any number of things. As catch said during user testing we had people who expected this to be a type of 'container' for other things, like articles.

kika: Honestly I don't think we need two different types of content in the default install profile. Currently it's there primarily to show users that you can create more, but I think this could easily be fixed by adding a "Create a new content type" for users with the appropriate permission on the node/add page.

Additionally I think most users do see page/article as "quickly updating" vs. "static" content.. in fact at UB I'd say it was one of the only differences they perceived. However, once they started playing around with them, they were confused because the two content types are essentially the exact same thing. Because of this I'd say until we add fields additional fields to page/article all we're really doing is confusing users about the differences. Sure we have the tags vocabulary, but that's the only visible difference between page/article (people RARELY see promoted to front page). Until we're actually putting fields to use, I don't think it makes sense to have two different content types by default.

I'm not sure I've wrapped my head around the larger goal here.

To me, it seems evident that:
- the difficulty we have in creating good descriptions speaks to the difficulty in describing the differences between the two types, and content types in general.
- 'Page' is horribly overloaded and if we could come up with a better term, we should use it (just as we did with the switch from Story -> Article). Unfortunately, after ten minutes of reviewing my thesaurus, I don't yet have a better term.

I don't understand how removing Page helps with Page being badly named. In my non-scientific, out-of-my-butt statistical sample, 100% of sites still require some sort of static-page-like content type. I'm not sure it would be a usability win to remove something that I see most sites requiring.

There must be something here I haven't understood yet.

I agree with keith.smith. The reason that I see for the two content types is because they serve different purposes. I can agree with renaming Page if we can come up with something that makes sense.

I haven't reviewed the D7 text about each type, but if that is simple and conicise enough, it should help people to understand the difference.

And from my own experience, every site I have created (not many admittedly) has used the Page content, and none have used Article. If only one is to stay, then I vote for Page, as we can create a default content type that will fit for most sites easily, but an Article will likely need to be modified.

I agree with Keith.
Already millions of Drupal users have been successfully using the various main content types :
story, page, blog, image
One of the first and fast reason that got hooked me to Drupal was that it provided all these basic necessities out of the box. Later I found that many users have thought likewise.

Is not "use" by all these thousands users over so many months and years statistically much, much more significant than a "small" usability test or two and hither-thither comments of drupal being difficult ?

The usabilty tests report about users who form really very very small sample, that also are localized - it does not take into account the multitude of users spanning across multiple nations who actually use Druapl and will continue to use Drupal. The real usabilty views can come from scanning the forums where you won't find much complaint about Page being Page. Lab generated results are too insufficient and sort of raise 'much ado about nothing'. Rather than these so called usabilty test if we really mean to find "usabilty factor" we should do proper database mining of the thousand of forum posts by real users, a proper mining by professional houses who do this sort of mining can tell the facts, and if done it will be found amazingly different from these usabilty test hypes.

node/add clearly says Page
If you want to add a static page, like a contact page or an about page, use a page.

I think and support 'page' should be there.

"Already millions of Drupal users have been successfully using the various main content types"
How do you know? Have you asked all of them? All the Drupal users I know delete or rename the core-provided content types to something meaningful for the site they're building.

Forum users are in most cases already using Drupal, in this case we're talking about optimising the 'default' profile for new installations which ships with Drupal 7. This profile isn't designed for existing users, it's designed for people installing Drupal for the first time.

What someone posts in a forum after using Drupal for a few hours or weeks is never going to be the same as watching them for the first 90 minutes after downloading Drupal. Before you're so quick to dismiss testing, have you even looked at the reports?

All the Drupal users I know delete or rename the core-provided content types to something meaningful for the site they're building.

What do they rename them to? Maybe there are some good suggestions in there that we could use?

So far all the alternative suggestions I've come up with for Page sound obscure and I _really_ wish I could come up with a better name.

Anyway, back to this issue. I agree that we need a way for people to become aware of content type creation, as its one of Drupal's strengths. We could remove both Page and Article and require everyone to create a new content type as one of the first steps after installation. I don't really see deleting just Page and using Article for page-like content, because Article wouldn't have the appropriate promotion settings, etc. Plus, Article doesn't feel right semantically, IMO.

Lets not start a flame.

Be objective / constructive about the socalled "usability" tests.

Those who are using drupal DID install it for the first time, and many new users report in the forum while they are still "new". Their reports, if a proper datamining is done ( whats your opinion on this ?) can be a better guide as to what to offer users who install it for the first time.

I have looked at the reports - ask any Statistics expert ( stats was my subject) they are just insignificant in this huge drupal sceanrio - you cannot even mimick something close by 'asking' or 'creating' test users in a lab.

Page already states nicely what it is for, DOES NOT IT ?

I take time to scan many new drupal sites that come up. And all the drupal users I have asked do use Page. If there were plenty of deletions of "page" or problems with it you would have got report in the forums, which is the best judge. I do read the forums even when I am not writing here.

Do you think 90 minutes is enough and should be our goal for understanding Drupal - its not a toy like Joomla neither its an aircraft that it wil need years. Given fair and reasonable time, it is the easiest as it is now.
In comparison, as someone mentioned it, see geeklog typo - how self explanatory drupal is in comparison.

Proof is in the pudding. No one [edited on objection below] will listen I know but be sure this i"usabilty" will not raise Drupal usage or its popularity - come back to this page after 5 years , the result will be there.
No use arguing counter arguing now.

>We could remove both Page and Article and require everyone to create a new content type as one of >the first steps after installation.

I hope this is something not seriously said. if we are speaking of 90 minute follks they will be HELL confused as to do what - most people are looking for solutions out of the box. If they are not looking for OOB like developers, they are pretty geek enough talready o understand what a page is.

While CCK or creating content type is a strength of drupal, its a novelty to damn new users or users from other cms-s - they are to confuse this "create a new content type" like anything. Donot destroy the ease of Drupal by bringing in more complexity in the name of "usability". If you say Joomla has more usage it is because of more positive help in their forums that newbies get, more themes and modules from the beginning, they were an early player in this and an early player has the number advantage.

I think we're fixing the wrong problem. Drupal has a great system to allow you to create custom content types and provides two of them as examples, but it's not clear 1) That they are just examples and 2) what is different about them.

I don't think it makes sense to ship with no examples and if we ship with only one we will have to argue about which to provide. But I think two things will vastly improve the way this works:

1) Add some explanatory text to make it clear that these are just two examples and that they can be used or deleted and any number of other types can be created.

2) Make it more clear what is different about them, NOT by trying to further change the descriptions, which has been tried and doesn't work very well, but by showing more about the differences we can't see -- the promotion and author settings and differences in permissions and fields -- to help indicate the reasons why you might have more than one content type.

3) Make it more clear WHY you might use different content types, maybe with a prominent link at the top of the page labeled 'Why use different content types?" which could link to a detailed explanation of the ways that having different content types can be useful.

Make it more clear what is different about them, NOT by trying to further change the descriptions, which has been tried and doesn't work very well, but by showing more about the differences we can't see -- the promotion and author settings and differences in permissions and fields -- to help indicate the reasons why you might have more than one content type.

Well said and appropriately said, I agree. +1 for this.

Worth mentioning that currently node/add says
Page - If you want to add a static page, like a contact page or an about page, use a page.
Story - are articles in their simplest form ... may be used as a personal blog or for news articles.
while
Blog entry - .. Each member of the site may create and maintain a blog. ( which is not possible out of the box by page/story)

I think the current descriptions fairly well say what is what!

@misty3, any good statistician will tell you there's a difference between quantitative and qualitative studies. You've offered nothing constructive here apart from saying that usability testing is useless and painting those of us who attended as 'hype'-mongers and 'propagandists', you should reconsider your interactions on this issue.

Make it more clear what is different about them, NOT by trying to further change the descriptions, which has been tried and doesn't work very well, but by showing more about the differences we can't see -- the promotion and author settings and differences in permissions and fields -- to help indicate the reasons why you might have more than one content type.

The other thread changing the descriptions again does exactly this - saying what the settings are, didn't get much review though.

because Article wouldn't have the appropriate promotion settings, etc

Except it's configurable per-node. We actually had one user delete their 'article' and add it again as a 'page, just to remove it from the front page, had they attempted the same task with only 'article', I think it's likely they would've found the setting, rather than reading the descriptions verbatim. Intermediate users who'd been using Drupal for a while were completely tied to the descriptions - not much indication that they were simply examples which could be modified at will.

Either way, I think we should kill page, it can't stay as it is - and come up with something new (or more than one) in a new issue, so here's a patch.

Marking as needs review, if only to see all the test failures which rely on it being there.

This issue has made me want to explore alternative methods for delivering help to first-time users: #397430: Implement cross-reference links that refer to logically closely related functions.

>>any good statistician will tell you there's a difference between quantitative and qualitative studies

Statistician always makes us aware not to rely on false positive and false negative result.
The sampling or number of lab users is both quantitatively and qualitaively insignificant.
But who am I to say ? If Dries and team or Drupal and team is OK with this, fine.
I find this 'new' approach to disturb timetested well settled stuffs more obtrusive than my language which I edited.

>> You've offered nothing constructive here apart from saying
Pointing out a false premise is enough construction. As I said Time is the best teller and time will tell who is right.

>> kill
Instead of killing page I like this http://drupal.org/node/397430 and this should be the way to do things.

>> you should reconsider your interactions on this issue.

I reconsider : lets have a vote or poll in this issue because

* There has been no serious problem reported in the forum about page that is statistically significant.
* Page has been historically and otherwise integral part of Drupal till Drupal 6x as well as ?version7 that is/was being tested - this has also contributed in part to the Drupal success so far ( a spoke in the wheel)
* Page clearly says what it does
* Dropping it completely or Creating something alternative DOES NOT GUARANTEE user pleasure and superb ease
* Consider upgrade problems from previous versions Page to suddenly no page

So, come - lets have a poll. Take it to frontpage please !!

Here's what I was thinking about. I've added what I think is a better description to the top of the content types overview page and added more info about how each type is set up. This addresses several things:

1) There is a lot of confusion about the difference between the content types overview page and the create content page because they are so similar. This makes the content types overview page into a real content types administration page.

2) The summary info and operations are created as hooks so that other modules can add them to this page as needed. This will be nice for CCK, for instance, which had no way to add a 'manage fields' link to the page other than to completely re-create the whole thing.

3) With the summary information, it's easier to see how the content types are different and some of the ways you might want to use them differently.

4) This also provides a place for summary information, like a summary list of permission settings for the content type (as an example of how it could be used).

I'm attaching a patch and some screen shots, with and without the CCK UI installed.

I like that a lot - probably deserves its own issue though - could you post one up, then I think we should probably postpone this based on the outcome of that.

Good idea. In first glance I feel having permissions there is a bit overkill. What's the usecase?

Just throwing ideas out right now, mostly just that there is no place now that you can easily see just the permissions for a specific content type, so we could show it here.

And also by showing permissions here we make it clear that a difference in permissions is one of the differences between content types. And the fact that I need different permissions is often the reason I create a new content type.

I removed the permissions for now (agree it might be too much) and have created a new issue for the Content types overview re-design at #398344: Redesign Content Types Overview.

I agree that it is hard to tell the difference between a page and article at first glance. What options could be set in an install profile to differentiate? Off the top of my head, articles can have a vocabulary, comments enabled and publish to the home page be default. This isn't enough to be obvious to all users. What about adding an option for menus to work differently on a per content type basis? For example, pages will almost always be in a menu while articles or blog posts are almost always managed through Views or /node. It would be helpful to hide the menu fieldset for articles to stress that they don't go in the menu while pages do. This is a common form_alter that I apply for usability.

Keep in mind that whatever you change to differentiate the types by changing default settings cannot be added to the descriptions, because the descriptions will become incorrect if someone later changes the settings. So no matter what you do to differentiate them cannot really help much in solving this problem. That was my purpose in displaying the settings instead of describing them.

I know that my suggestion is probably controversial, but I disagree that it is more confusing than a long description that tries to describe the differences. I think a list of settings is much easier to scan that a 'wall of words' that tries to describe how things are set up. The list of settings would only show up on the Content Types overview, not in the Create Content page. Currently the same information, the end user description, shows up in both places, which is actually a bit odd and not necessarily the best outcome. It confused people in the usability studies to see the 'same' screen in more than one place.

Actually I'm not opposed to only showing one content type in the initial install with a better description of how and why you could use other content types, but I still think that showing settings provides additional context to help them see that those settings are the kind of things might be changed, and also provides much more useful information to established sites with lots of content types.

The Content types overview screen needs to be useful both to first time users on a new install and to existing sites that have already made changes and perhaps added new content types, *AND* the description also has to make sense in the 'Create Content' page. It's very hard to create a single description that will work equally well in all these contexts, which is part of the reason we're struggling.

I like the idea of showing settings (karen's). And of setting up page and article with different default settings (pages showing up in menus, articles promoted to front page).

Maybe is permissions is one of the key reasons to make a new content type, pickig another default content type to illustrate that would help too....

Or maybe there is a way to create a bunch of different content types shipped with d7, like.. Article, static page, member only article, image, etc...

I wonder if it would also help to have a enable/disable check box next to each default (also using Karens displayig settings idea) and a create custom content type link. Or maybe a delete link next to thencontent type... Hmm but that would be merging the manage content types page and the create conent page.. Which someone already mentioned confused people by having two screens that are prety much the same.

Maybe the manage content types and the create conent screens could be merged and be the same?

Probably not... As some roles will be able to create content, and other roles will be able to manage conent types.

I've confused myself!

Sorry, I am a bit de-railed on where this discussion is going - we are talking about adding more destinction by displaying it diffrently. Looking at how people read the text during the test, I don't think that is going to make a diffrence, since at start they are not familiar with drupals nomenclature and displaying it to them here, might make it even more confusing.

I am still for removing "page" as content type, since the value it supposedly adds (we got content types) is not clear to people.

Please move all discussion about overview content types, to that place.

I agree with Karens.

If "the value it (page) supposedly adds (we got content types) is not clear to people." will 'content-types' and 'creating new content-type' be clear to people, particularly new people ?
Do we mean sort-of-geeky things like CCK will be clearer than pre-set content-types ? Really ?

I very much suggest keeping the two content types. They cover the two most basic needs of a content management system: Static and news content. You may kill the article type with just as much justification as the page type. Relabel them if you believe they are confusing, but please don't destroy the functionality.

One argument to kill the content type is based on the horrendous descriptions they have now. So fix the descriptions. You can explain the two types in a few words. Nick Lewis, catch and I each made suggestions for a better descriptive text here (#279333: Make it easier to build page structures, see #2, #8, #18).

this is quite a discussion. personally, have never used the story type or article, but page--i know what that is and use it always. everyone sees things in their own perspective which makes this very difficult to form a community agreement. as long as there is a 'key' to explain to people what the content types are actually used for as they may end up with unrecognizable names to some folks.
i will shut up and regress to my cave.

Many non-techie people are already familiar with the Post/Page distinction from WordPress and similar systems. As Arancaytar said: "They cover the two most basic needs of a CMS." I don't think there's anything wrong with having these two content types by default, as long as the descriptions are better and don't reference each other.

While I think the approach to this issue in #279333: Make it easier to build page structures is a bit overkill, since "books" are themselves super-confusing to new users, the descriptions Nick Lewis gives in #18 of that issue provided a good starting point.

What about something like:

<em>Pages</em> are ideal for content that remains relevant over time; for example, an “About Us” or “Contact” page. By default, pages will not appear on the front page. 

<em>Articles</em> are ideal for time-sensitive content, such as a blog entry or press release. By default, articles appear on the front page, most recent first. Tags may be used to organize articles into categories.

KarenS's work on making the defaults settings for content types show up on the create content page might be combined with rewriting the descriptions. If her work went in, we could trim the descriptions of Page and Article to one sentence each. Maybe there could also be a way to hide the content descriptions & default settings, similarly to how module descriptions can be hidden on /admin.

I have never liked the Story/Article content type, since it has little (in my opinion) to differentiate it from the Blog content type, except for the fact that it is enabled by default in core. But I have used the Page content type on a regular basis in both Drupal 5 & 6. It was one of the first things that I understood about Drupal - a generic content type for rarely changing content, like an "About Us" or "Contact" page.

I thought of an interesting idea, though it's probably out of scope for this issue: If it confuses people that "Pages" don't show up anywhere on the site by default, make it so when you submit a Page, you are prompted as to whether you want to add it to a menu. This could be either a modal dialog or a two-step form. That way, Pages could easily be added to main navigation, etc., without having to fiddle around with the book hierarchy, as was suggested in #279333: Make it easier to build page structures.

Looks like we're keeping pages, so marking this as duplicate of #233200: Content types descriptions tweaks which cleans up the descriptions.

It isn't really a duplicate, doesn't solve the problem.

For cross-referencing purposes I'm adding a link to an issue that will change the name of the Page content-type.

I think Yoroy's desire here was to change the install flow, and with @Karens' suggestions, the content-type administration, in a way that users would more likely learn about what a content-type is in the process of setting up a site. I am much in agreement with that approach as well. However, the issue I started is simply trying to change the name of "Page" in order to better deal with a host of disambiguation issues. Anyway, that issue is at: #542972: Change Name of "Page" Content-Type to "Basic Page"

Can't we just rename 'Page' to 'Static Page'? Seems like that simple word addition should clear up a lot of confusion...

a thought..
I just realized that I use article for site users to create content, but page is for admin only. I suppose there would be a way to control it in permissions if page goes away to keep static(page) publishing under control, control menu creation on article i guess.
end of thought..

interesting discussion

@Alex UA: That would make sense. Currently however, #542972: Change Name of "Page" Content-Type to "Basic Page" changed the name of the page content type to "Basic Page". I think Static Page is better (although I think Article/Page was actually sufficient since WordPress gets away with just Post/Page). Thus, I still stand by what I said in #36.

Static page has been discussed before, at least one issue with that is that 'static page' can also mean a .html file in a directory, also just because a page isn't time-sensitive doesn't make it static.

More importantly, we are in UI Freeeeez

@catch, Bojhan: I wasn't proposing that it be changed now. That was why I didn't move this back to 7.x.

Can we close this out? In more recent testing, it seems like people got the difference between "Basic page" and "Article." Articles are now quite different, as they have tagging and images auto-enabled, and creating an "About Us" page falls under the 99% use case so I'd hate to cripple the standard profile by forcing people to grok content types in order to do such a basic operation.