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...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

+1 for this, especially now it's possible to post books that don't have any outline whatsoever. Why not '#collapsed' => FALSE though?

Nick Lewis’s picture

Being 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.

Pancho’s picture

Status: Needs review » Needs work

I'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:

  • We could move up the "Book outline" fieldset only for content type "Book page". This would be inconsistent though and people might be searching the "Book outline" in the wrong place.
  • We could reconsider making the "Menu settings" fieldset that prominent. From my perspective "Menu settings" belongs to all the other fieldsets down there in the form. Making one fieldset far more prominent than all the others would only make sense, if it is mandatory (which it is not) or suggested over other categorazation or hierarchy structures like book, path, taxonomy (which it is neither, as it depends on the overall structure).
catch’s picture

I prefer #2 - although I'm sure that was introduced in D6 for similar reasons to this issue.

cburschka’s picture

Quick 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...

+  if ($form_id == 'forum_node_form') {
+    // Make the vocabulary required for 'real' forum-nodes.
+    $vid = variable_get('forum_nav_vocabulary', '');
+    $form['taxonomy'][$vid]['#required'] = TRUE;
+    $form['taxonomy'][$vid]['#options'][''] = t('- Please choose -');
+  }

...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.

cburschka’s picture

I 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...

Sutharsan’s picture

Component: book.module » usability

Moving all usability issues to Drupal - component usability.

dpearcefl’s picture

Component: usability » other
Assigned: Nick Lewis » Unassigned
Status: Needs work » Postponed (maintainer needs more info)

Is this issue fixed in the latest D6? is there any interest in pursuing this issue?

dpearcefl’s picture

Status: Postponed (maintainer needs more info) » Needs work

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.