Drupal "rejection" of containment and usability issues

Annakan's picture

Drupal seems to not really like the notion of containment.
While I appreciate the "sea of node" approach as a base view on content that is structured by taxonomy, I think drupal carries it way too far.
And it means that with containment Drupal reject Context.
And a lots of usability issues stems from that.
A few come to my mind (and I am sure there is many more):
* Where did my content go ?,
* What can I add there ? (What can I do next)
* How do I start something
* My content appears in incontrollable place

I will try to illustrate my point with an example :

Let's take the book module for instance, because the book module as been designed to allow exactly such hierarchical structuring and the hoops you have to jump through to use it are a clear indication of what is wrong ;

To create a book you have to

1) Create a book aware content (better know what it is beforehand, not intuitive)
2) Come back to it (Where did it go ? ) and go to the structure tab
3) Select : create a NEW book (and good luck to you if you have already 100 books that populate the "book" box, how confusing can it be for a user ?)
4) Your content become the "preface" of the book (not the cover ;) )
5) THEN add new Child pages to the book (but only 9 levels depth ? why ? )
6) But you can't add Sibling pages .... :(
7) The pages you add will appear as free "leaves" in the content, for instance on the front page if your page type is of the "published on front page by defaut" kind, and above / before their "parent" page since they have been produced after it ....

This obviously IS NOT how a user would think about it
(Heck even I still find this awkward and can't imagine a way to explain it properly)

A user (and me ;) ) would like to:

1) Create a book (and this page would be the cover, to it would be attached properties likes page numbering, outline, thesaurus or global taxonomy, restricted content type allowed inside, etc...)
2) Add pages and chapters INSIDE the book of the type allowed by the book
3) On each page 3 buttons : Add page, Add chapter, Add sub-chapter (same level, a new sibling level of the parent level , a new sub level of the current level)

On the book parameter properties you could say if you want the book to publish its pages or only its cover an if you want the book "freshness" to be determined by pages being added or modfiied, who can change the cover, the properties and administrate chapters and pages ...

It would be so much more usable and "intuitive" for user don't we agree ?

BUT

This means that somehow a real concept of containment must be introduced somewhere...

It already made some appearance in the forum module anyway so maybe it is time for a generalized concept of node container or containment.

Maybe it is the role of an enhanced taxonomy, keeping structure and content separate could be a good and, it seems to me, drupalish idea. (Much better than a node of "type" container, containment would be attached by having a Container/ Structural type of taxonomy attached to any content type, obviously the root instance of a content type)

It means we need to had a generalized concept of properties to taxonomy terms and hierarchy but that would be a boon for many usages of taxonomy ....

Then we could provide a few "structural" taxonomy with semantic meaning (Book, discussion, forum, gallery, thesis, ....) and the relevant properties and behaviors linked to related content types (at least root content type), at least as a sample and starter kit.... letting CCK and people imagination mix and match content types and structural type and behaviors...

And then lots of other "how do you do that" problem could be solved by using rich metaphors that have more meaning for users and more guidance in usage (I can add page to a book but not a book or a forum to a book for instance, or maybe yes if it is an Enhanced Drupal Book ... depends but it is clear in the type definition) ...

And further more we could at last let go away the permission "by content type" stuff, that really does not cut it for any site with a moderately structured audience ...

No more "group" box in a group post box because I would be able to publish INSIDE a group
No More Input format box everywhere (or nowhere with some modules) but on a group by group, book by book, whatever by whatever basis

etc etc ...

Does it sounds stupid ?

Thanks a lot for your time.

Comments

I broadly agree

Caroline Pickering's picture

I broadly agree with you regrading the containment of content within a more conventional structure. Nodes work well for knowledge management systems (aka wikis) but for most websites a hierarchical structure with parent-child relationships is still closer to most peoples mental model of how information is organised.

I too believe metaphors are incredibly useful in enhancing usability. If modules elude to something else we are very familiar with (as in your example with the books module) then the user will expect certain things to happen, or be to be able to perform certain actions in a certain way. I think Drupal generally could benefit from a more extensive use of metaphors in it's UX design.

I couldn't agree more - with

pbowyer's picture

I couldn't agree more - with the current site I'm building I'm hitting all these issues, as the mental model when using Drupal is so unintuitive for anyone used to thinking in terms of a hierarchical structure and placing content in a section of the website.

Let's hope D7 solves this!

Mark Boulton Design Drupal 7 Project

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: