Project: Transforming Book Module Into Robust Outliner for Drupal 6.0

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

With the interest expressed by Dojo members and the wider Drupal community in this project, we're moving forward. This wiki page is open to anyone to update as the project progresses. Feel free to leave comments as well.

Project Outline
One of the things mentioned by Dries in his "State of the Drupal" talk at OSCMS (watch the video here) was how nice it would be if book.module would turn into a more generic outline functionality, rather than being semi-attached to a specific node type. We're going to take on this task.

Project Deadline
The Drupal 6.0 code-freeze is on June 1st, meaning we need to have all features done by then, as only bugfixes are allowed beyond that point.

Issue Queue
We will be organizing by using Drupal.org's issue queue. Here is a direct link for the book component.

Notes/Resources:
* An existing 5.0 contrib module that implements generic outline functionalioty: http://drupal.org/project/outline
* Notes on how this should be developed by sepeck and eaton: http://lists.drupal.org/pipermail/development/2007-March/023188.html
* Existing code with new menu system: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/pwolanin/test/
* Partially done handbook pages on new menu system: http://drupal.org/node/102338
* Multiple menu support (chx and pwolanin will do this): http://drupal.org/node/137767 -- done!(sort of- see below)
* Re-parenting and caching for menu links: http://drupal.org/node/145058
* Make menu module work with new multiple menus: http://drupal.org/node/144753

Comments

module title? + ideas

pwolanin's picture

A philosophical point- should the module remain the "book" module or be renamed something like "outliner", "structure", "outline", etc?

Also, I think improving the UI will be at least as important (and difficult) as improving the underlying code. I'd really love to see some brainstorming and/or demo code for this aspect right away. For this, at least, the various versions of the outline module (including my sandbox) may be useful. In these, we treat each "book"/"outline" as a separate entity, so you can only reorganize a post within the current outline. If you move to a different outline, it shows up at the top and needs a second step to place it within that outline's hierarchy. Harder? Maybe- but also makes the UI cleaner by avoid a 100's long drop-down.

Obviously, another principle I tried to move towards is treating all node types the same (per partial CCK in 5.x core).

Finally, I saw the ability to set a default type for child nodes as really important. If this is automatically inherited for users without 'admin nodes' or some such, then it opens up all sorts of creative possibilities for site organization. As a trivial example, the admin creates a set of "chapter" nodes that are each of that node type. The admin then sets the default child page type for each of these to be "wiki", so authenticated users can all add and edit pages under each chapter, but can't add new chapters or edit the "chapter" pages.

Yes yes yes!

joshk's picture

A) I definitely agree that a rename is in order. We should throw it open to the community.

B) I'm definitely with you on the UI issues. Again, I think this is something to have a lot of discussion around. I would especially love it if we could track down great examples of outline-style organizing from other web systems. We'll need to develop our own code, but in terms of a spec I doubt there's much of a need to reinvent the wheel.

C) I definitely agree on having some functionality at the "volume" level. Child node types is a good one, as might be some access restrictions.

Good thoughts!

http://www.chapterthreellc.com | http://www.outlandishjosh.com

child type per node

pwolanin's picture

My suggestion is being able to set the child type per node, rather than per volume/outline.

Here's my thought on per volume/outline features: this was a point of disagreement between myself and Augustin(beginner). I think for a (lean) core module, it is sufficient to have the infrastructure (i.e. each node now has an associated outline ID) to enable per-outline features. Then contrib modules can build off this to (for example) do theme switching per outline. Basically, you could do a lot of the things the Organic groups module does, or that add-ons for it do.

UI examples

philippejadin's picture

We've tried different solutions with Thinkedit (a small cms). Here is our latest attempt : http://www.thinkedit.org/think/files/screenshots/thinkedit_structure3.jpg

Don't go this way I'd say :-/

For the UI, it should be as simple as possible. The way we did it makes it harder and harder when you have a deep tree with a lot of nodes. OTOH, it's not practical to open/close tree items if you don't use ajax (too much page refresh).

First do it with normal html, then add ajax for faster page refresh. Browsing a tree involves a lot of page refreshes. Use simple (non hierarchical) list to avoid user confusion. Add a breadcrumb :-)

The page could be structured like this :

  • breadcrumb
  • "up one level" link
  • list of items in the current path
  • buttons to attach existing node / new node / menu items

If you go the heavy ajax way, you can do neat things. My current favorite being : http://radiantcms.org/ (ror based cms, look at the demo)

just some $0.02 worth of toughts

poll

pwolanin's picture

just created a poll: http://groups.drupal.org/node/3941

If anyone has other suggestions that should be added, let me know.

There was some discussion

catch's picture

There was some discussion around allowing the outliner to include views and panels in it (and along those lines maybe taxonomy/term listings) - which would then open up situations like the ability to replace the default forum index with an "outline of views".

should be possible

pwolanin's picture

I think this should be possible if this module relies on the new menu system as I envision. the harder part will be figuring out a good UI to let this happen.

views and panels integration is huge!

OpenChimp's picture

The original discussion about this issue started http://groups.drupal.org/node/3791

I think it's really important to be able to include these types of pages in an outline system, since often the most important pages are these pages which organize the nodes in a way that users can quickly scan for the specific node they are looking for.

I'm glad to here that the system will most likely not have a problem implementing this feature.

Heres an idea - I might be game to help with.....

metzlerd's picture

Seems to me the magic is the data structure. So here goes. What about robbing a page from the node access api to create a node relations api in core. This was a brain drizzle I had while listening to the Lullabot folks talk about deprecating taxonomy and node_access.

New table: node_relations
realm varchar(255)?: the realm - so that modules can hook on this
rid : int(10) the root node of the book,
pid : int(10) the parent node id
cid : int(10) the child id of the book.
weight : int -- the usual drupal weight for organizing.

put some keys on this,
realm,pid,cid
realm,nid,cid,rid

Ok now with that in place. at same time (like we do with node_access) we populate the node_relation table based on a new hook.

Then we make the books module based on this general strategy.
Implement node_relations hook
Implement helper/theme functions to make menus, bookmarks as appropriate.
write a simple install_update functions to upgrade core tables from book.

With a root node (which doesn't have to be a separate content type). It should be pretty straightforward to determine how many breadcrumbs should be displayed, and generate a reasonable UI to determine book. The expense is the bulk update on root nodes when root nodes are moved into another tree.

Imagine being able to tie this to node_access for a cool value based security system. When you create node x, you have access to node y.

I'm great at db stuff but don't do much Jquery etc. I'd be willing to start hacking on this in my spare time :).

using the menu system

pwolanin's picture

Check out the patches here: http://drupal.org/node/137767

The goal is to make it so that the menu system will do much of the work, so this defines the essential things to store.

Also, we may want some new or additional fields, such as the path alias?

Pagers by default

morphir's picture

If you look at what people use book.module for, it's generally not writing an entire book, but an article with 3-10 pages.

If we had some pagers there by default in book module, I would find that very handy. And it would of course greatlyi improve usability.

See example:
http://www.raiden.net/?cat=2&aid=235&pid=1

Pager 1: A classic previous page | index | next page - non javascript(fallback for those who have not enabled js)
Pager 2: A drop-down box - that changes page/chapter on click.(with javascript)

A new name for book.module could be:
- Handbook.module (still a book, but smaller)
- Article.module (?)
- Editorial.module

Lastly, I would love to see a way to implement images in book.module by default. And then add some javascript behaviour on that image(think thickbox). Will there be a image module in D6?

use cases

pwolanin's picture

Since we are looking at a June code freeze, and the new menu system is still in progress (with the goal of tight integration by the book-module successor), image support is out of the realm of my consideration. Also, I think that would be bloat of a sort that's what we want for a core module.

Anyhow, ideally in Drupal 6 you;ll be able to install CCK, make your default book-node-type be one with an image field and be done with it.

Still want a jquery pager

morphir's picture

Pager 1 is of course in core already.

But I still feel we could need a Pager 2 (jquery drop dow select list). It wont happen in core this time, but can be a contrib module.
The reason I'am still pushing this is that many respected websites out there does provide this with articles that spans over several pages.

menu context

pwolanin's picture

Quick brain storm for those who have looked at the new menu module code. If we can share this functionality with book module, we can include non-node pages in the book hierarchy. While this is good, it leads to a problem- how does the book module know when we have navigated to that page via the book menu/hierarchy so that we can set the breadcrumb, etc? Would it be viable to save this link with a query string? For example, assume a page is in the navigation menu (like 'Recent posts') and we also want to have that in the hierarchy. The hyperlinklink in the book menu and in the book navigation could look like '/tracker?book=89' or some such. Is this way, you might be able to do something like include the same view (with different URL arguments) at differetn places in the hierarchy.

a request...

Veggieryan's picture

Im doing alot of work with bookexpand and its great how it allows you to filter by group.

Id love to see some integration with organic groups so that each group can have its own outline(s)

When adding content within the group the outline is filtered by groups...

This allows me to build menus and blocks per group which makes groups work like their own webpages.

what do you think?

Good idea

morphir's picture

A very good idea! Not as core material, but should fit nicely into the Organic Groups project.

This sounds kinda like a

btopro's picture

This sounds kinda like a project that I maintain called the outline designer.

http://drupal.org/project/outline_designer

I'm currently working on some OG integration as well and bumping it up to D6 shouldn't be that hard once I get a handle on D6 myself.


"Moodle? What's moodle?"

http://elearning.psu.edu/
http://elearning.psu.edu/projects
http://drupal.org/project/outline_designer
http://drupal.org/project/html_export

This could have applications

sbell22's picture

This could have applications beyond organic groups, into PIM-like applications on sites... heck, i have already been tempted to move my address book into a drupal sub-domain... there is a constant frustration amongst the gtd community as to the lack of any really good outlining tools, since the days of GrandView and Ecco... anyway great idea! Hope i can contribute too.