Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
For book node add/edit pages, the parent selection fieldset is the most important element, minus the body and title. But as of now, its hidden in a collapsed fieldset at the very bottom. Making matters worse, the menu selection fieldset is just below the title -- and it looks very similar to the book selection fieldset (people not familiar with drupal won't even know the difference.
Attached is a small patch to solve this problem. I also included before and after screenshots with thought bubbles for what new users are likely thinking...
Comment | File | Size | Author |
---|---|---|---|
bookusability-fix.gif | 27.9 KB | Nick Lewis | |
bookusability-problem.gif | 18.31 KB | Nick Lewis | |
bookusability.patch | 639 bytes | Nick Lewis | |
Comments
Comment #1
catch+1 for this, especially now it's possible to post books that don't have any outline whatsoever. Why not '#collapsed' => FALSE though?
Comment #2
Nick Lewis CreditAttribution: Nick Lewis commentedBeing able to open and close it doesn't seem necessary to me -- can't think of anything the user might gain from it (anyway you look at it, you'll have to scroll down a bit to hit the submit button or mess with another fieldset.)
I confess I'm biased against those collapsible field sets, too. They're use way to generally and hide things that really shouldn't be hidden (like the publishing status, and authoring, and date information).
Not a deal breaker though, if anyone thinks their important, I'd be happy to remove that line.
Comment #3
PanchoI'm not sure whether we want this to be that prominent on the edit page. Remember that not only "Book pages" but any other content type may be in a book outline now. This means that when creating a node of any content type that is allowed to be in a book outline, the "Book outline" fieldset will be displayed right under the title. More often than not, the new node won't be included in a book, so we don't want this to be prominent.
I see two ways:
Comment #4
catchI prefer #2 - although I'm sure that was introduced in D6 for similar reasons to this issue.
Comment #5
cburschkaQuick reminder: We had a similar discussion regarding the placement of the "Menu settings" fieldset in the first place. It was agreed that hard-coding this in the menu module was not good, as content types could be changed.
But the situation is different here. Unlike the menu module, but much like the forum module, the book module defines its content type. It also provides its features to other content types if desired. As the forum module is already giving special treatment to its own node forms...
...I'm sure that the book module could make a similar adaptation on the book_node_form.
The book hierarchy is big, expanded and near the top for book pages, and an optional setting down in the fine print for non-book pages. That sounds intuitive.
Comment #6
cburschkaI was completely oblivious to the fact that not only does book.module now allow non-book nodes to be added to the hierarchy, it goes so far as to add the previously "native" book type as a generic content type handled by node. That means the book type is no longer hard-coded, and should not be hard-coded into this function either.
However, there is a "book_child_type" setting that appears to specify a "default" book page type which is added when you click the "Add child page" link. That type can be optionally reconfigured, too.
Am I right in assuming that if any content type deserves its book hierarchy fieldset to be especially prominent, it would be this "book_child_type"? If so, I'll patch form_alter accordingly...
Comment #7
Sutharsan CreditAttribution: Sutharsan commentedMoving all usability issues to Drupal - component usability.
Comment #8
dpearcefl CreditAttribution: dpearcefl commentedIs this issue fixed in the latest D6? is there any interest in pursuing this issue?
Comment #9
dpearcefl CreditAttribution: dpearcefl commented