Story to Article seems to have been a good move (and people who haven't tried out a new D6 yet keep suggesting it again all over the place).
However page is still there, and according to both UMN and UB testing, causes conceptual problems for a lot of people.
I took a quick look at wordpress - which has 'posts' and 'pages', here's what they've got to say for themselves:
http://codex.wordpress.org/Pages
There's also a slightly dusty patch here to rewrite the descriptions (again): http://drupal.org/node/233200 and which I'm planning to resurrect.
Nick Lewis also suggested throwing away 'pages' as they are now, and letting the book module take it over - then we get hierarchy built in. Note wordpress appears to offer some kind of page hierarchy out of the box.
We could enable the book module by default (a renaming wouldn't hurt, but that's another issue), and then make that the second content type - would be much more differentiated compared to 'article'. Note that there's already tags by default for articles in D7, and soon there'll be an 'expert' install profile with almost nothing in it - so we should feel free to bloat the default install profile a little bit for central issues like these. I've used book module for an about section on one site, so does Rain City Studios - and that's what we're currently telling people to use 'page' for. Seems like a good start to me.
Comments
While I strongly support the
While I strongly support the change from "story" to "article", I still think "page" should be the same. The reason is general perception of the users to "page" is quite stable and widespread (from the other CMS, like WordPress as you mentioned).
From my previous experience, users may be unsure what "page" is at first but after heard or seen a bit more explaination (like "static page" or "web page"), they tend to get it suddenly. It's somewhat conventional wisdom.
I think what Nick Lewis
I think what Nick Lewis suggested, is keeping 'page' - but having it book enabled by default, so it's got some hierarchy built in as opposed to just being a cck node type with pretty much nothing else.
Correct. I've seen a lot of
Correct. I've seen a lot of people attempt to emulate the book module, using pages, menu items, and sheer determination. That approach works pretty horribly, and leads to confusion within the admin interface (usually, they get really confused about menus, and how they relate to blocks... if they can't find a page in their menu, they freak out, and think the machine ate it sometimes...).
They are usually just trying to link pages together, into some sort of section[and often realize this midway into adding content], -- so when I introduce them to the book module, it always puts a smile on their face. You see that look in their eye that says, "yes, this is what i had wanted... this is something i can work with..."
Pages without the book module are about as worthless as stories out of the box. Either they can't be found by default [the lucky users never figure out the menus], or they get thrown into '/node' -- which one of my former clients nicknamed 'the blog barf page' :-)
With book pages taking over for pages, our default content types all have a clear purpose, and distinct behavior:
1. Pages are "static" content that can be put into hierarchies, and are linked together by various navigation elements
2. Blog entries act like a blog.
3. forums act and look like forums.
There is still the issue of the "blog barf" front page will muddy up the behaviors of these content types by default. Almost no one wants it as their front page if they are trying to build something other than a blog. But that's another big discussion.
++++++++++++++++++++++++++++++++
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
++++++++++++++++++++++++++++++++
work: http://www.onnetworks.com
blog: http://nicklewis.org
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
nice!
Seems like the patch would be remove page, enable book module tweak descriptions a bit, maybe enable the book navigation block as well. Now the 'expert/ (empty) install profile's in, shouldn't be too much of an issue to add something extra to the default one.
update: posted an initial patch here: http://drupal.org/node/279333
book vs menu trim
While I have also seen the smiles of delight on the faces of heretofore befuddled users when presented with the comforting hierarchy (and its accompanying block structure) of the book, I have seen cases where the book goes too far --
Not every user (or site) wants the previous/next navigation of the book. Additionally, the "up" link present when you have three or more levels within a book gets very confusing.
A nice middle ground: the menu_trim module at http://drupal.org/project/menu_trim
Using this module, you can specify a menu (and accompanying block) for pages, or any node type. So, it gives you the menu, it gives you the ability to structure pages in a block, without specifying a forward/next sequence --
And this still retains Nick's three points, with our default content types all having a clear purpose and behavior.
Obviously, as menu_trim is outside core, and book is part of core, this presents a whole different set of issues.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
While the book module has
While the book module has it's own UI issues, I'd say menu's are considerably worse at the moment - mainly the issue of adding a menu item from the node page, and that it's a dumping ground for all kinds of non-content stuff. I opened an issue to move /admin into it's own top level menu - but a first look at this and it looks like a lot of trouble: http://drupal.org/node/279399
menu_trim, to me, looks like book module without actually being book module - not tried it though.
yeah, and yeah
Agreed, both book and menu have ui issues --
The thing I like about menu_trim is that it solves the problem of context-specific blocks, specifically with regard to primary links -- it really simplifies navigation, and when used in conjunction with primary links it makes the process of building out a site structure (close to) intuitive -- create content --> add to menu --> context specific blocks automagically appear -- in some ways, very similar to book.
RE your issue at 279399, one of the first things I do when building/delivering a site is disable the navigation menu and create custom menus based on user stories. At the very least, I split off /admin to its own block --
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
It's a question of time
Dates are important for article because their content is often relevant only when they are published. On the other hand pages are usually created to last and serve as a reference.
Or I could say: articles are timely, pages are timeless.
I like the move from story to article too, but I'm not sure about pages. Is there a better way to describe a basic content?
I agree the term 'page' can be misleading, as I think for most people any content displayed at a given URL is a 'web page'.
A physical book contains pages, but does the analogy really help explain what the book module is? After all you can add any content type to a book, not only 'pages'. The name 'book page' is also confusing, because you could use one that just acts as a 'book cover' and add only other content types to it. In fact that's how I've always used it so far.
Isn't content displayed in
Isn't content displayed in reverse chronological order the definition of a blog? Yet, to a lot of people, the word "blog" is a turn off; blogs are for amateurs, not for serious people, so their thinking goes.
If we do have an "article" content type, it needs to behave differently than blog entries. One possible idea is to provide a vocabulary called "sections" with prepopulated terms -- such as "Case Studies", "Annoucements", "Press releases". Add help text at certain points, instructing users how to change, or add the names. These sections would behave a lot like taxonomy_menu, only would use the path 'articles'.
This content type assumes there are multiple authors working under the supervision of an editor of sorts. So moderation settings would be turned on by default.
Something along those lines would cover a very common need users have -- and would differentiate the content type from the more layed back "blog" content type.
This is not a simple suggestion to implement, there's a lot of details that would need to be addressed. I don't know whether drupal core needs a new article module, but then again, does it need a forum module either? Personally, i think drupal is better suited for sections of articles than it is for forums.
++++++++++++++++++++++++++++++++
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
++++++++++++++++++++++++++++++++
work: http://www.onnetworks.com
blog: http
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
IMO 'article' means 'single
IMO 'article' means 'single user blog' - which could be expanded out later of course. blog.module is only useful if you're doing multi user blogs - and IMO there's no need for it to be in core (or at least it should be renamed to make it's purpose clear) - issue for that here: http://drupal.org/node/233301
We've got a default 'tags' vocabulary now. Sounds like you'd want to add a fixed vocabulary as well?
Keep 'page' - but having it
This could really work because:
So, just merging the page and book page contenttypes would already be a big win I think.
…
(Now, my next suggestion would be to make the 'Welcome to your new Drupal site" screen the first Page of a simple 'getting started' book. Just that welcome page and maybe another four pages to expand on the four steps that are mentioned in the welcome page (configure, customize, build, create content). This book could even have an entry in the primary or secondary menu. Even more useful triggers for users to explore the menu system and block administration. Because the content of these pages is 'help' we can use the actual content to explain exactly what's going on.) But that's another issue :)
I like the getting started
I like the getting started book idea a lot!
A link to it in the primary menu would also somewhat solve the "front page instructions disappear" problem. Even if you delete the menu entries the pages can still be reached via the node admin page.
Adding links to primary and secondary menu would be better, as an example of what can be done. This is important as IIRC by default in D6 only the navigation menu is visible.
patch now here:
patch now here: http://drupal.org/node/279333
Probably a bit late here
How about creating a default vocabulary of only page nodes (eg. 'Pages') by default when the taxonomy module is activated in Drupal? On enabling the book module, a child term of 'Pages' called 'Book Pages' could be created to handle book content instead of a whole new content type for something thats more or less the same as a normal page node?
Could the book nav block be modded into picking up child terms of the 'Book Pages' term in the vocabulary.
The remaining pages created by users that are not classified as 'Book Pages' could fall into a parent term called 'Site Pages' or a more appropriately titled name. Having all pages (that are not book pages) by default fall into a miscellaneous category could make them easier to search out/organize later when the content organization of the site needs updating.
While widely used page based content (ie. as defined earlier as relatively unchanged content whose 'recentness' of publication has no weight and in some cases the older content is more likely to be wanted/encouraged to be found earlier) such as FAQs could be handled by the book module, I'd rather have a first level vocabulary term of FAQ based pages on a site as a sibling vocabulary term of Books with both vocabulary terms as child term of 'Pages' rather than Faqs a child term of Books. I also find it a bit strange that book pages cannot be found when one visits example.com/admin/content/taxonomy
Could the navigation function provided by the book module be used/cloned/hooked into as a separate nav tool for FAQ pages and miscellaneous pages? While it is easier right now (configuration wise to enable content navigation) for FAQs to be a child term of books (the book taxonomy is a bit confusing since it isn't found in the taxonomy , it'd be more extensible to have the book modules navigation treat all the immediate child terms of a dedicated page taxonomy as navigable content.
A bit more off topic: How about a dedicated article vocabulary (the tag vocabulary can continue to be used across content types although I think every content type should have a vocabulary all to itself with a default term for unorganized content) as well where articles with no user defined taxonomy terms are automatically assigned a 'unorganized' tag? That could help users quickly check (assuming they have a tag cloud in which clicking the word unorganized leads them to a list of all unorganized content) which articles have a taxonomy term and which don't instead of scrolling through every blog post to check for whether tags have been assigned or not (a bit of a selfish request since I don't tag newly created entries that often yet later on I wish did.) A view could be built to display all articles without a tag but I don' think that many lightweight users of Drupal would go through the footwork of configuring views just to find untagged content. Having every content type automatically set up its own vocabulary and having all uncategorized content of that content type fall into an 'unorganized' term would boost Drupal's user friendliness.
Off topic again:
The Menu Module could automatically assign all tagged pages a menu entry. First level terms for page based content, such as 'Books' and 'FAQs' can be given a first level menu entry and their child/grandchild terms can be given second/third level menu entries. The 'Unorganized' menu link could be hidden from site visitors but enabled for admins/user roles with the relevant permissions to organize content.