Naming and description of node types can be much less confusing

Right, so I digged a bit deeper and found that the core of the problem with book page permissions is in fact content types...

A small introduction to content types in relation to core(optional) modules:

• Enabling the book module adds a whole new content type 'Book Page'.
• Enabling the blog module adds a new option: to create a 'Blog Entry' (=blog post in my vocabulary)

The inconsistency I find here is that the content type 'Book Page' seems to be directly bound to the book module, which it isn't, unlike the content type 'Blog Entry' which is directly bound to the blog module: One cannot delete the 'Blog Entry' content type at /admin/content/types but when the module is disabled it is gone. (unfortunately it is also impossible to edit any blog posts from that moment on, see below). So far, just observations, no bugs yet.

Now, however, when the book module is disabled at admin/build/modules, the content type 'Book Page' is still there. Apparently it was added permanently. This is not a bug! In fact it is great, because nodes of the type 'Book Page' don't become un-editable. The problem here is that after I have disabled, and optionally uninstalled the book module (which basically means, removing all book module data from nodes) I could go to content types and think: "Oh no, the book module is still not quite gone, now I have to remove this content type, because they forgot to code that in the uninstall process." Understandable, right? But not necessary. Unfortunately, after I delete the 'Book Page' content type all 'Book Pages' become un-editable. So here we have a problem: the relation of books with content types is confusing.

I think it is critically important to rewrite the description of the Book Page content type, which currently states:

A book page is a page of content, organized into a collection of related entries collectively known as a book. A book page automatically displays links to adjacent pages, providing a simple navigation system for organizing and reviewing structured content.(sic)

No wonder I deleted it after I disabled the book module: I tried to get rid of the book module, and it seemed logical that I had to get rid of Book Pages as well then! Instead it should say something like this:

A tree page is similar to a story except that it is by default not promoted to the front page. They are usually organized into a hierarchy of related pages known in Drupal as a book, but can also be used for content. This content type is always created when the book module is enabled.

It should be clear that the book module 'outlines' nodes into a hierarchy. What I would like to do is to rename the three content types Story, Page and Book Page to the following:

• Story can stay the same or be changed to Article, no preference from me.
• Page would become Static Page and
• Book Page would become Tree Page

The only difference between the 'Book/Tree Page' and the 'Story' type is that the Story is by default promoted to the front page! See also michaelkillian.com/tree for a demonstration of content types in Drupal.

The fact that the book module adds a new content type when it is created is great! Two content types to start with is confusing enough and we should keep it like that. The less change the better! But having both Book pages and Book modules which are not actually the same thing is just bloody confusing...

Okay, I'd like to limit my proposal to changing the description of the content type 'Book Page' as following:

"A book page is similar to an article/story except that it is by default not promoted to the front page. They are usually outlined into a hierarchy of pages, known in Drupal as a book. Book pages can also be used for independent content. This content type is always created when the book module is enabled."

A book page is a page of content, organized into a collection of related entries collectively known as a book. A book page automatically displays links to adjacent pages, providing a simple navigation system for organizing and reviewing structured content.(sic)

Out of curiosity, why do you include a sic here? If there is an error, please comment so that we can fix it. I've probably read it too many times to see it.

I think I just commented about another issue you were having on a won't fix thread about static pages.

Yay! Someone hears me :-)

Okay, the sic is there because book pages are not '[... is content], organized into a collection of...'. The correct form would be '[... is content], which can be organized into a collection of...'

The important bit here is that there is an action required to organize the node into a hierarchy: whether this is by clicking on 'add child page' or by selecting the place in the outline option when editing the node. The confusion starts when I go to /node/add/book and fill in the title and body and submit the node: I cannot find it in the book hierarchy :-| (I thought book pages are organized into a collection of related entries (a book) by Drupal?!' I hope you get what I mean.

This, however also brings up the issue that any node type can nowadays be part of an outline, right? (At least stories and pages I am sure of) So how does this relate to the other content types?

I don't agree with catch:

(about renaming the Book Page content type): Although, Chapter doesn't begin to describe the possibilities in the book module so that's a pretty bad idea.

I think the description of the book module should be completely omitted from the book content page and even the name of the type should change to something that is semantically less tied to the book module, as I explained before. I quite like Chapter. Maybe a problem with that could be that it's not that clear that a chapter can also exist outside a book... any ideas on this?

I apologize for writing such long posts, I don't have enough time to summarize myself. :-)

Yeah, you're right. Chapter sounds fine to me.
Generally I think we use the word Page far too often and we have this beautiful word node in Drupal which should be used instead of page in a lot of cases. I find in the content type description we were avoiding Drupal jargon and replacing it with just as difficult synonyms. I think it's fine to use difficult words, as long as we keep it consistent and don't call it promoting in one place and featuring in another. Also, content types should be node types really!

My proposal:

• Content type >> Node type
• Story >> Article node, (node/add/article)
• Page >> Static node, (node/add/static)
• Book page >> Chapter node, (node/add/chapter)
• featured to this site's initial home page >> promoted to the front node

New descriptions for node types:

• A static node is ideal for displaying information that rarely changes, such as an About us section of a website. By default a static node does not allow visitor comments, does not show the submission stamp and is not promoted to the front node (link to /node).
• An article node is ideal content that informs or engages website visitors, like press releases, site announcements, and informal blog-like entries. By default an article node allows comments, shows the author-date-time-submission-stamp and is promoted to the front node (link to /node).
• A chapter node is identical to an article node except that it is by default not promoted to the front page. Chapter nodes are often used to create and add to books(link to /admin/content/book). In Drupal, the book module maintains hierarchical, chapter-like relationships between nodes. The process of organizing these relations is called outlining in Drupal. Chapters can also be used for unorganized content. This content type is automatically created when the book module is enabled.

I highlighted the use of outlining in Drupal's jargon because the concept of a hierarchy is not really friendly with outlining somehow, at least that's what I find. Also I couldn't find any description on http://dictionary.reference.com/browse/outline that resembled Drupal's specific use of the word. I think it's fine to use it as long as we explain what we mean...

Heh.
I'm on board with what the structure-mongers here are saying - because I think in tech terms too.
But the talk over at What word should we use instead of "node" in end-user interface and documentation? is going directly at cross-purposes to this (IMO more accurate) terminology/documentation.

You guys should get together. I'll buy popcorn. :-B

First and foremost, LOL @ dman. Right on.

LindenLion @ 6: Eh. I see your point here, though that change is so subtle I had to read it several times to figure out the difference. But, yes, I see what you mean, though I really think that distinction is going to fly over most everyone's heads. (I know it did mine.)

Catch, et.al re: "chapters": I like chapters, in that it continues the book metaphor, though I wonder if it does not imply more than it needs. To me, a book page is just that -- a page in a book (note this is using page somewhat differently than we normally use it). If pages are arranged hierarchically, with several pages underneath a parent page, then that parent page could perhaps be a chapter.

LindenLion: note that as of yesterday or the day before, the type "story" has been renamed in Drupal 7 to "article".

keith, what do you mean with this:?

LindenLion @ 6: Eh. I see your point here, though that change is so subtle I had to read it several times to figure out the difference. But, yes, I see what you mean, though I really think that distinction is going to fly over most everyone's heads. (I know it did mine.)

Chapters imply some kind of hierarchy structure. I wouldn't start making the difference between chapters and pages as parent and child: a book can go 9 levels deep, and how do you name it then? Chapter node, if you ask me.

Story or article, doesn't make a difference for me :-) but I prefer article node over article!

• With my first point (though admittedly I could have worded it better), I just meant to say that I understand what you mean (when you talk, in #6, about a book page not being organized upon first creation), but believe it to be a subtle point that not many people will pick up on.
• On the chapters, I think the word chapter is ok, but could possibly imply more than we want. Maybe it doesn't. But, there's no denying that books have chapters and pages, so I don't know that one is better than the other (except that chapter is less overloaded than page).

On overall content type renaming:

• I see some value to using "node". I don't mind the word, but many people do. Returning it to use is likely to be quite a conversation.
• In general, I think that having two-part names for content type is very problematic. Your plurals get messed up. You have to italicize both words to make it clear that you are referring to them as an object. I know we have lots of two-word content types ("book page", "blog entry") but in every instance that complicates writing help text around them.

Totally agree with you catch! Chapter is still too close to the book. I think the whole book metaphor doesn't really work anymore. Books are not necessarily sorted in hierarchies! Maybe the books that developers read, but some books I read don't have complex hierarchy structures at all... I am all for moving towards a 'generic outlining module' (even though I wonder whether outline is the right word) and getting rid of the book metaphor altogether. It is very exceptional that people want to have actual Book Pages on the Web, but sometimes they do and that makes this metaphor literally confusing. It would make more sense to have generic node types.

Article(s) and Static Node(s) is in fact enough in my humble opinion. The only reason why you need another node type is because you don't want 'book pages' on the front node. But what about keeping it to two node types and having a prominent option checker box (like the starred message in Gmail) for promoting to the front node or not: no need for 'book pages'!

I appreciate your point about having one-worded names. I agree 'article node' is over the top. But what about 'Page'? Page means too many things, as we know. Does it mean the overall page or just the node part of the page?! Page, or even Static Page is just too confusing!

Who is actually MAKING Static Node content? Most likely not the users of a site but the administrators and THEY should know what a node is if they are going to use Drupal! So I think 'Static Node' is an accurate, fair and usable name! Also, by calling it Static Node, site administrators will understand quicker what a node is and that this node type is not intended for people's stories (because they should not have to know the word node).

About using two words here: I can't imagine it to be too difficult to make Static Node(s) plural, and about the italicizing: what if you have a non-breaking space between the two? Is there another problem as well with that?

If we are talking about hierarchies and organizing things into hierarchies, the vocabulary I can come up with that is familiar with everyone is: folders and filing. Everyone who uses computers knows that folders contain files and also a filing cabinet is a common English word! I would love to replace 'books' with 'folders' (which is much more generic and neutral towards it's content!) and replace 'outlining' with 'filing'. Go to http://thesaurus.reference.com/browse/file and check out noun1 and verb1 (1st and 3rd result) and then go to http://thesaurus.reference.com/browse/outline and compare...

This would be quite extra-ordinarily self-explanatory and would enable us to get rid of the metaphor (book) which doesn't work for alot of people.

To make it even clearer:
Make two basic node types: Article and Static Node. Every node type can have different content types.
So there could be:

• Articles, containing different varieties of articles;
• Essay, Snippet (max. length), Book Page, Chapter etc.

• Static Nodes, containing different varieties of nodes that are not submitted but created (by default only for 'Site Editors') like
• Abouts, FAQs, Forms etc.

Apart from that there could of course be the Poll node type, Image node type, and all kinds of types which need different fields. Do I make sense?

My new proposal:
(See above for reasoning)

• content type >> node type (template? I'll think about it!)
• Article >> Article
• Page >> Static Node
• Book Page >> Article (or sub-type of Article)
• featured to the home page >> promoted to the front node (prominent as the star option in Gmail when editing specific node types)
• book(s) >> folder(s)
• outlining >> filing

And write new node type descriptions of course...

Just referring to #13 and #6:

You might call it a subtlety. It actually took me more than a year to grasp that book pages have little to do with the book module... confusion leads to frustration leads to anger or action. The first reason why I came here is because I was frustrated by the create book page permission under node permissions which didn't make any sense to me and cluttered my mind space... So sometimes clutter is good: when it leads to cleanup of mess ;-)

Not to single out one of your ideas, but I rather like the

promoted to the front node (prominent as the star option in Gmail when editing specific node types)

I use the heck out of the star in GMail.

Of course, actually using a star would probably get confused with add-on rating modules, but there's possibilities here. Anyway, we can follow-up about this on another thread, to avoid this one veering off-track.

I am a bit of a beginner so if I am wrong ignore
I am trying out 6.1 and two book permissions seem to have been missed

currently
add content to books
administer book outlines

should be
add content any books
add content own books
administer any book outlines
administer own book outlines

If this is posted in wrong place sorry
lastly would a hack be possible to achieve
add content own books
administer own book outlines

While this issue drifted away from its original roots (ie. permissions scattered among specific module and node module), I'd like to add a note on the original route. It is a logical way forward for Drupal core modules to have their node types as node module managed content types, be it poll module, forum module or blog module. These are not yet node module managed, so they have their own permission settings. Hopefully these will move to node module, as they share lots of code, and cause confusions like this.

Moving issues from User experience project to Drupal core usability component.

Now that we have page and article and #233200: Content types descriptions tweaks has a patch I think this can be considered a dupe.