Content types descriptions tweaks

I like these. I wasn't sure that I would, since changing these in http://drupal.org/node/89196 was such a long process, but these are very good.

A few comments though:
- one of the descriptions has a two-character space in the middle.
- when all core modules (or even part of them) are enabled, page and article will be substantially different from the other types, sacrificing consistency for usability.
- the bit about changing the content types or the description is really true for all content types, not just page and article. Having this called out on page and article and not others (when more modules are enabled) may imply that you can't do this for the other types.

How about just adding the "You may edit or delete this content type (and this description) to suit your needs, or add a new one." to the top (above the content types list) instead.

As an aside, you say "As well, '..similar in form to a..' tended to result in a lot of reading up and down between the two, hence why I just stuck the differences up front in the patch."

Reading your patch, I was struck by how I didn't miss that part of the descriptions at all. They really read better without it. It seems like there was some reason that clause seemed important at the time, but I can't think of it now.

So we need some good help text at the top of the page, that explains content types and provides a link to edit them. The part that references changing them should be wrapped in a conditional so that it only appears if someone has rights to follow the link. Or maybe all of the help needs to be that way. In your testing, you were simulating an administrative task, and I see the problem relative to that. I'm not sure that the same help text would be as useful or appropriate for non-administrative users. (And, actually, this is a good reason not to include it in the content type descriptions themselves, as it could not be conditional there.)

Is there a reason why the text

You may edit or delete this content type (and this description) to suit your needs, or add a new one.")

should be listed on each content type and not, for example, on the top of the "node/add" page in a form such as:

Below are the content types currently available on [this site]. You may edit or delete these content types (and descriptions), add new fields to them, or create new content types to suit your needs.

One of my slight annoyances with the help text is the amount of repetition, which, imo, increases the likelihood that people will just scan or skip over the help text/descriptions.

I also like the suggestion that only people with administer content types should see the text about editing, deleting, adding content types.

I agree with #4. If the user has permission, show "You may edit..." on top of Create content-page (/node/add) with a link to edit them (/admin/content/types). (These paths are for Drupal 6).
At the top of /admin/content/types there is already (Drupal 6) a short text about content types in general, and on the row for each type there is an edit-link (so I guess there is no need to mention on top that they can be edited). So I only think a text like the one in #4 need to be added on /node/add.
Apart from that, I like the content type descriptions suggested in the patch.
I apologize if me using Drupal 6 made the comment irrelevant.

For those who find it hard to read or apply patches, could somebody post the actual suggested descriptions please? Thank you!

Moving all usability issues to Drupal - component usability.

I had a patch ready when I found this issue. The current descriptions are annoying. Let's do this step by step.

yoroy, this is the new text in the patch:

A page, has default settings suitable for posting information that rarely changes, such as an "About us" section of a website. A page is not featured on the site's initial home page, and does not allow visitor comments by default. You may edit or delete this content type (and this description) to suit your needs, or add a new one.

An article, has default settings suitable for posting press releases, site announcements, and informal blog-like entries. An article is automatically featured on the site's initial home page and allows comments by default. You may edit or delete this content type (and this description) to suit your needs, or add a new one.

I would make it even more concise, and leave out the "default settings". It may be a bit too technical for and users. And the difference in default settings is the sole reason for having two different content types in core anyway.

A page is a simple content type, suitable for displaying information that rarely changes, such as an "About us" section.

An article is suitable for displaying up-to-date content that engages website visitors, such as news, announcements, or informal blog-like entries. An article is like a page, but is by default featured on the home page, shows the author and creation date, and allows comments.

What about setting the "Page" content type to have a menu item created by default? It seems that all the examples I'm usually given on what a Page is meant to be (including the description above) are pages that would usually require a menu item, so why not have it add those items by default? This would have the extra benefit of introducing the users to the menu system as soon as they start creating content, which could possibly help with the "where'd my content go?" problems that were talked about in the usability sprint.

It seems to me that Article and Page are still too closely related, even with the descriptions above, to make them both useful for most users.

catch: replace 'page' with 'book page' issue is here: http://drupal.org/node/279333
That one is postponed because of http://drupal.org/node/279390 ("book module doesn't create hierarchies for book pages (or pages) by default - you have to go into the book fieldset, make a new book, and then it'll create the hierarchy - otherwise you just get a regular old page.")

Nice to see Alex came up with basically the same idea, I still like it a lot as well. It's out of scope of this issue, but it would influence the wording…

@catch- the question I have is: should non-admins (or at least a member of some elevated group) be allowed to create pages by default? I have never created or worked with a Drupal site that allowed non-admins to create pages, and the way I read the description (i.e. creating a section for the site that rarely changes) it seems that only admins or trusted users should really be creating pages anyway. The issue there is that there isn't an admin or trusted user group by default (anyone know if this has been raised as an issue in the drupal issue queue? if not, I'll open one, as it is always a bit annoying to have to create an admin/trusted group every single time I build a site).

@yoroy- yeah, I didn't mean to drag it off topic, I suppose I have a few new issues to open up.

Closed #232294: Naming and description of node types can be much less confusing as a duplicate, contains much discussion though.

This issue was identified at the UB Usability Testing: http://www.drupalusability.org/node/70

Still, will we ever get these decriptions distinct enough without writing a complete novel?

The testing showed that people don't know why or how to choose between the two. I really think it would be much more effective to enable only 1 (one!) content type in a default install and add some helpful text that invites people to create their own "my awesome content type". It will expose users to this cool Drupal feature in the right context and "my content type" will be a much stronger incentive to go and grasp the concept than this vague distinction between page and story.

Thoughts? ( I know it's quite out of scope of the original issue but let's focus on fixing the actual problem, not the symptoms)

I am on the same page as yoroy, to me the distinctions between the two right now an a functional level are almost the same - we need to go either to just one content type and invite people to create an own. Or actually provide different fields with fields in core.

Perhaps we should get rid of the name "Page" for a content type. It is too generic. Everything is a page. Even the home page is a page. Naming one content type "Page" suggests other content types are not pages.

Content type names should be clear enough for most users not to have to read the description at all.

"Static page"?

#395968: Remove the 'Page' content type from default install profile

subscribe

I like these tweaks a lot. I'd almost RTBC this if the word "Pages" was italicized similar to "Articles".

In the original issue where these were modified (#89196: String freeze: Provide better content type descriptions) I think some decisions were made to make all the available content types in core reasonably parallel. Just addressing Article and Page in this issue may lead to some slight inconsistencies with the other possible types (like Forum entry or Poll or something). For instance, Article and Page will mention that their descriptions can be edited, while the other ones won't. The other descriptions refer to these as singular; these tweaks use plural. However, keeping these things completely parallel is what has lead to the somewhat stilted nature of the current descriptions.

Can somebody please explain the logic of taking out page, instead of story? Sure, every node (and some views) on Drupal are "pages", which is why for someone just starting that word makes sense, since every page would be that content type. A story on the other hand is completely irrelevant to most projects (I have never used it, nor have I ever worked on a site that uses it), and makes it seem like Drupal is about fluffy first-person content rather than a serious platform for content management.

A big -1 from me for removing the page content type, and a +1 for removing story instead.

Trying to omit some needless words and actually explain what the initial home page is and how to edit a content type:

Use Articles for time-specific content like news and press releases. They are automatically featured on the initial home page and comments and tagging are enabled.
Change these settings.

Use Pages for your static content, such as an "About us" page. They do not appear on the initial home page and comments are disabled. Change these settings.

The problem with trying to describe the settings is that the settings can be changed, which will then make the descriptions incorrect. It also creates a 'wall of words' to try to describe all those things. I think a better fix is to *show* the current settings in a list, which is what I was trying to do in #398344: Redesign Content Types Overview. That way they will still be correct if the settings change, plus I think it is easier to distinguish the differences in items in a list than pick them out of a long sentence.

Yep. Am also much in Favor of one-sentence-descriptions for the content types overview. Maybe we also produce some for Blog and Book Content Types as those are also core. The same descriptions could help on the modules page because people might want to enable e.g. blog module and get trapped by the classical error - you do not need blog Module for blogging.

So how about these:

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

Page
looks fine like written by catch

Book:
Books have a built-in hierarchical navigation. Use for How-to's or Tutorials.

Blog:
Use for Multi-User blogs. Every user has his own blog.

I am wondering if a reference to Wiki-like structures for Book Content Type is rather confusing. What is your experience - do first-time think of Wikis using Book?

Wew, one sentence descriptions! It's looking good.

"Their own blog" isn't grammatically correct technically. How about "his or her own blog" ?

O.K. here is my patch. Catch - Did I get you right you right in just radically putting in the one-line descriptions?
Anyway - I did that.

- Deleted rant - about missing hint that patches are sent to testbed automatically if they meet the criteria - I guess this is they must be cvs diffs that are made from drupal root directory.

Any Volunteers to update the handbook about that?

If you set the status to "needs review" that is

yes please.

O.K. let's get this done.

If we include Blog and Book in the default profile, does this mean that they are activated by default if you use this profile?

Or is there a way to import the texts but not activate the content types/ Book / Blog module? (array values)

Ok, lets cary this home. I will be available to write a patch to do it, but eigentor if you can update it. I dont think it activates them by default.

Rerolled, now including Book and Blog content types.

OK, tripped by lacking IQ. Rerolled after having a helpful tip from catch.

O.K. Next attemt. A silly st() instead of t() cracked blog module in the last one.

Rerolled, witch catch's corrections. Argh wrong captitalising is the hardest-to-lose error in written english. We Krauts capitalise everything.

And once more: Had forgotten the description for Book Content Type.

Argh, argh lots of wrong capitalisations, Apostrophs... Redone, just ignore the other patches. Sorry for my bad written English. And now also UTF-8 encoded.

Committed to CVS HEAD. Thanks!