Make it easier to build page structures

Oh, this would be so great to do. This should help users get a grasp on the page, node, menu and block concepts much much quicker.

http://drupal.org/node/273137 is at least related to this.

The content type description for Page should use 'home page' instead of 'front page'.

I'd like to see help and descriptions get simpler and shorter in Drupal, so may I suggest:

Use a page for content that doesn't change often, such as an About us section. Organize multiple pages into a hierarchy and it automatically generates a menu. Pages do not appear on the home page by default.

Create an article for posting time sensitive content such as announcements, press releases or blog entries. Articles are automatically featured on the site's initial home page. Tagging and comments are enabled by default.

I like this a lot. The Book module is pretty hard to identify as what you need, since most of the time the structured pages you will write have little to do with the concept of a paper book or even an e-book. Enabling it by default and using it for things like welcome and about us pages will make site navigation easier.

I might suggest also enabling the path module by default and allowing URL aliases for book pages, but that's another matter.

Works great, but there is some improvement possible in the content type descriptions. A few commas are out of place ("A page, has something."), and the "default settings" part is unnecessarily wordy. It merely indicates that the settings can be changed by the admin, which the user (who actually sees this description, and can't usually change the settings) doesn't care about. Also, the users are likely to be more interested in what the article does, rather than what we think it can be used for (that's up to them). So that should come first, and the suggestions second.

I'd suggest something like this:

An article is automatically featured on the site's initial home page and allows tagging and comments by default. It is suitable for suitable for posting press releases, site announcements or blog entries.

A page can be organized into hierarchies called books, providing a simple navigation system for organizing and reviewing structured content. It does not appear on the front page, and does not allow comments. It is suitable for information that changes infrequently, such as an About us section.

In #279390: Book module workflow improvements, I suggested an alternative route, which is to force (or suggest energetically) the creation of menu items for "Page" contents. That would insure that users organize their pages at creation time. Coupled with #279399: Breadcrumbs are only taken from one menu, we could have a powerful "User" menu separate from the "Admin" menu.

The difference between stories and pages will be:

• Stories are (by default) promoted to the front page and are sorted by their creation date
• Pages are (by default) organized hierarchically in a menu

From #2:

Pages do not appear on the front page by default, and can be organized into hierarchies called books

According to the goal of the patch this means "must be organized into book hierarchies". And a book hierarchy has both hierarchy and order.

While I support the idea that pages will end up in a menu automatically (and thus won't get lost), I don't like the fact that every page will have a next and previous link by default. Pages may have a hierarchy, but they may not have an order.

So I would prefer the suggestion in #10.

Won't be able to test this til tomorrow. If someone manages to test it before me, it seems important that they do this.
1. Create traditional book pages on a drupal 6 install.
2. Update to drupal 7.
3. Make sure that the book content type is still usable, and working properly on the drupal 7 install.
There's a possibility that drupal may refresh content types, and eat the book content type on sites that were developed to use it. I don't think its going to be treated as just another user created content type be default.

The difference between stories and pages will be:

* Stories are (by default) promoted to the front page and are sorted by their creation date
* Pages are (by default) organized hierarchically in a menu

Drupal 7 calls them articles. That change is already in. :)

I'm also in agreement with #10 and #279390: Book module workflow improvements. My reasoning is the same as in #12.

Tested:

• Updating a site that already has book.module:
  • Installed D6 site with book.module.
  • Created pages, book pages.
  • Updated to patched D7.
  • Outcome: Page and Book page content types are both still available, pages are still pages, books are still books.
• Updating a site that did not have book.module:
  • Installed D6 site.
  • Created pages.
  • Updated to patched D7.
  • Outcome: Page is still available as a content type, and pages still have the 'page' type.
  • Installed book.module (here's where it gets interesting)
  • Outcome:The old page content type has been silently replaced with the type added by book.module. The new description is displayed. The Page I created still has the 'page' content type, and is now a book page. It can be added to an outline.

So no content is lost, and all is as expected. Since both the page and the book content type are created in D6+ as custom types, they remain as they were when they were created. The only "collision" that happens is that in an upgraded D6 site, a newly installed book.module will replace the existing page content type and all pages become book pages. I didn't test what this will do to customized settings on the page type. (For example, if the admin made pages automatically go to the front page in D6, this might be reset by enabling book.module in D7.)

I felt the descriptions could use a tweak in wording and tense. I also think certain features should be explained at that point. Others such as comment settings seem less important. Kinda struggled with how to best put the distinction between the two content types in the first sentences. Not certain "timely" is the right word... But i'm a bit neurotic.

<em>Pages</em> are ideal for content that remains relevant over time; for example, an “About us”, or “Website Policies” page. By default, pages will not appear on the front page. Pages can either stand alone, or be organized into navigable hierarchies. For example, an “About Us” page might contain child pages titled “Executive team”, and “Board members”. Use the outline field, or tab to enable and edit these hierarchies. 

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

I really question the merit of using the term "book" at all in the interface, since the metaphor isn't crystal clear, and it only seems to serve as more drupal lingo that begs for explanation in one place or another. I noticed this when I wrote " Use the outline field, or tab to enable and edit these hierarchies. " The fieldset is called "Book outline" -- which is kinda weird. Also, books should send that outline field to very top of the page -- i'd prefer that it is left open -- below the title and above the menu settings. I wrote a patch for this that never got committed last release cycle: http://drupal.org/node/199992

Book module does some things that are not really what a new user would want - i.e. extra navigation links at the bottom. I think the suggestion of pushing the users to create a menu link for each page node and make sure it's going into the primary links (now called "Main menu") would really be what users expect.

What if they need more than a single page? Any reasonable user will probably attempt to file a sub page using the menu system (I've seen this mistake over and over again, and the results are really bizarre and frustrating to new users). They'll find out that a) it didn't work, b) they can no longer find their page. So then perhaps they move the menu to the sidebar (most never make it that far, instead they come let me know that the website isn't working... a lot of people don't have me on their payrolls though...) -- and they'll find something that sort of works -- but its annoying, unwieldy, and odd since we have a module that does exactly what they want already -- and does it well.

Stuff we should consider adding in this patch:
1. Settings that make the up,down, left, right book navigation optional (i'd say even turned off by default on new installs, unless we can make it easier on the eye. )
2. In the book controls fieldset, "Book outline" is a really weird way to say "Outline". I think a lot of people will mistake "outline" to mean what it meant in english class -- or worse, what Microsoft word means by "outline"-- and never pay much attention to it as a result. At the very least, the word "book" will serve to confuse in the context, imho. User will think, "What's a book?" to which the "drupal way" would be to put "RTFM" somewhere in the field description. That kinda sucks. Page hierarchy might be a better label... both for the local task, and the fieldset.
3. Always provide the "add child page" link to pages -- and automatically make the source page a top level book if it isn't already. The point of this is to give users an easy clue on how to add a page beneath a page.

<em>Pages</em> are ideal for content that remains relevant over time; for example, an “About us”, or “Website Policies” page. By default, pages will not appear on the front page. Pages can either stand alone, or be organized into navigable hierarchies. For example, an “About Us” page might contain child pages titled “Executive team”, and “Board members”. Use the outline field, or tab to enable and edit these hierarchies.

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

Awesome. This solves all that I stumbled over in #8. A few more brainstorming suggestions:

- remains relevant over time -> "static content"? I'm not sure if that word is widely used.
- not sure if the "Website Policies" example adds much that "About Us" doesn't - another opportunity to shorten, maybe.
- use the outline field, or tab to has either one comma too much or one too little...
- sorted by most recent -> "starting with the most recent" / "sorted by recency", except recency isn't a word. ;)
- Articles can be tagged and organized into categories.?

I'm really fond of this patch now, and hope it gets in! As long as we scare away users with all that tech-speak, we're selling (well, giving away) Drupal dreadfully under value.

Then point them to the excellent Node Relativity module. You can create the child pages from the parent page.

You can do the same with the book module, and that is in core. Should we not recommend the use of core whenever it is sufficient, to avoid the inevitable burden of deploying contrib and waiting for compatibility updates?

I'd just like to echo pwoalin's comment that adding to a menu is essentially what users are trying to do when they structure their content (I made a similar comment here: UMN Usability: Content types descriptions tweaks). I think the best place for these links to go is the "main menu", as to avoid the other issue that catch has raised with the "dumping ground" that is the navigation menu.

Is the reasoning here for moving away from the menu system that the UI there is insufficient? Shouldn't that be addressed, rather than scraping menus in favor of the book functionality? At some point most users are going to have to start messing with the menu system, so why not start them off with the first piece of content they create?

This looks like it needs some reviving.

To recap (executive summary):

The objective is to make it easier for users to structure their static pages and make them navigable/visible.

The two different approaches we have are as follows:

1. Boost the book module. Switch it on for pages by default, so users can create outlines, and (this is the logical consequence) enable the book navigation block by default, so users can immediately find what they made.
2. Boost the menu OTF feature. Force, default or strongly encourage the user to use it, causing a menu item to get automatically created for static pages in the main navigation menu.

The change is postponed indefinitely, since

• it is postponed against two widely distinct issues, only one of which is relevant, depending on which approach is taken (menu OTF or book module #279390: Book module workflow improvements)
• it is postponed against an issue that is postponed against another (#273137: Split Navigation to User and Administration menu against #279399: Breadcrumbs are only taken from one menu).
• none of these issues are close to a patch, and all of them are several months inactive

In other words, unless we actively look at this now, it is going to fall off the radar for another year.

The two fixes are not mutually exclusive, but they are redundant, and likely to confuse people even more when used together ("Why is my page now listed in Book Navigation *and* my Administration menu? And why is it called Book Navigation when I'm just writing an About Us page, or why is it in the Admin menu when it's supposed to be for users, not me?")

However, it also has the potential for vastly improving usability and we should definitely revisit it.

Also, while both of the other ideas would improve this one, neither of them is strictly necessary for examining this (after all, a patch was already ready and tested), so I'm daring to punt this back to active and hoping it catches more eyes.

See : http://drupal.org/node/395968

-1 for the promotion of the book module as a replacement for the page content type as suggest by some above.

Of the 50 or so sites that we have completed over the last year, only 1 site had the book module enabled. I found the theming on the advanced side for newbies and I may have missed something at the time, but I had to clone the structure into the menu system anyway so that the custom dynamic drop downs would continue working. [Typically, I was pushed for time so it was the fastest option to manually duplicate the structure rather than do the research in to how to do this properly.]

To help with the creation of new content that requires menu entries, I created the Create related content module as a way to circumnavigate this issue. It adds the options to create child/sibling nodes via a form that is used to post this info onto the standard "create content" form. It initially seemed like a hack, but I rarely use the standard "create content" form by itself now. It is the preferred method that the clients use to create pages too.

Moving to 8.x since the related issue #395968: Remove the 'Page' content type from default install profile is targeted to 8.x