As things are now in the d.o Handbook, each page can be a member of exactly one Book outline.

As we discussed at the Vancouver docs meeting 2010, we would eventually like to have the ability to make different maps/outlines containing the same content arranged in different ways, because sometimes the same topic belongs in multiple places.

There may be some existing modules that we could use to achieve this:

Nodequeue -- maybe -- is it hierarchical/outline organized, and can one node be in multiple queues?

Kristoff VanTomme (whose name I may have misspelled) has created some mapping software for Drupal that he demonstrated in a recent Dojo presentation, which allows you to drag and drop nodes into an outline/map.

Maybe other projects exist as well?

The next task would be to try out some of the existing things, and see what they can do. Eventually we would want to install whatever the tool is (hopefully we won't have to build it), and import the existing Books on d.o into this tool as the initial maps, and then provide a way for others to make and share different types of maps (I'm just brainstorming here):
- handbooks
- tutorials (these might be linear rather than hierarchical, as in "study these pages in this order to learn about this")
- mini-handbooks
- Lists a la Amazon
- etc.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

LeeHunter’s picture

Wow. Your "lists a la Amazon" idea might be really interesting.

Imagine if any user could:

A) Flag a collection of favorite pages and then
B) Rearrange those pages into a map that either makes sense for their personal use *OR* can provide as a mini-guide for others (maybe for training clients or coworkers).

In other words, on the user profile page a user could maintain their own collection of custom handbooks ("My Quickstart Guide to the Ten Best Modules" or whatever) which they can share as a link.

jhodgdon’s picture

Right. Once we have the ability to create our own maps, I don't see why we'd need to restrict that ability to docs admins, as long as we don't promote personal maps as being official.

When you're viewing a book on Amazon, I think there's an area that says what lists the book is in, and that's a useful feature. We should be able to do something similar if people can create their own maps? I would think, anyway.

So I guess another couple of items for the spec:
- We (doc admins) need to be able to designate some maps as "official". Maps people create would be "personal" until otherwise marked.
- Ability to list all the maps (personal or official) that a page is in, as a block on that page
- Ability to keep a map open somewhere (frames?) while you navigate through it, and not be dumped into a different map as you go. This is necessary because a single page can belong to more than one map, and you need to be able to follow a map. Currently a page is in only one book outline, so this is not an issue -- we just display The Outlline when you are on a page.

kvantomme’s picture

The module we are using for the DITA maps is graphmind a Flex UI that uses the .mm mindmap format from Freemind. It would need a bit of polish, but it could definitely be integrated as a stand alone upgrade.

The module makes a mindmap that you can export and open in Freemind a very popular free and open source desktop application, I just checked and there is an encoding bug in the url of the exported nodes, but that should be easy to fix. #999350: encoding bug in the url of the exported nodes

The UI could probably use a bit of polish:

We probably should build a couple of views that can be used in the mindmap with arguments to collect nodes with a certain keyword (that functionality is there, just need to create the specific views we want).

If we cheat a little we might even be able to transform the existing docs into single element DITA topics (e.g. put everything from the node body into a topic body without doing any additional structuring). It would be the equivalent of a kitten genocide in the eyes of the DITA crowd, but if it helps us take a first step, I would definitely consider it. Than gradually we can start splitting up the documentation pages into structured DITA topics.

That way we could also start using the Open Toolkit export functionality from day 1 and generate custom PDF and help files from the mindmaps (images will be harder to fix though).

jhodgdon’s picture

Hmmm. For the drupal.org Handbook, I think we need a solution that saves the map in the Drupal database, not in an external site's pet format, or in a separate file. Is that possible with your module? I don't think we'd be opposed to being able to export into the .mm format, but I don't think we would want to store in that format. Not sure...

I also think that we need to think about how we would want to collect the nodes to map. Possibly we'd want to be able to go through the d.o site and somehow bookmark pages to collect, and then later reorganize them into a sequence or outline? Unsure on that idea.

The other thing to keep in mind is that right now, DITA structuring of the Handbook pages is not even on our horizon as a goal. Having multiple maps for the same content is on our horizon as a goal. Let's keep this issue focused on that for now.

Thanks!

jhodgdon’s picture

Latest specification ideas:

  1. A map would be composed of items. Items could be: (1) nodes (2) external URLs (3) headings [plain text, not links, used to organize items but not pages themselves]. Maps are ordered lists of items, hierarchical or flat. We might want to restrict to just Book Page nodes. There would be a default display of a map, which would just show it as an outline of headings and links on a single page.
  2. Users would be able to flag nodes on d.o by clicking on an "Add to cart" type of link [not sure what the appropriate link text would be - add to map heap? add to mappables?]. [This could be accomplished with an existing module, such as voting API or favorites or flag, I think.] When viewing a node, this link would be visible. Also useful if it's visible in search results.
  3. When a user is ready to create a map, they would go to a page that would show them all the items they have added to their "cart" (or whatever it's called), and give them the ability to arrange them in a "map". Ideally, there would be a drag-drop interface as well as a more accessible non-JS or non-drag interface. You could also add new items and delete existing items. Putting an item into a map would not necessarily clear it from the "cart", so a "clear cart" button might also be useful. Some cart browsing tools (order by when added to cart, title, and not sure what else) might also be useful.
  4. A user could make as many maps as they wanted. When created, they would be private, until the user decided to publish them. They would be shown on their user profile.
  5. Admins could designate some maps as "official".
  6. When viewing a node that has been added to one or more maps:
    • Blocks on the sidebar (probably collapsible) would show the public/user and official maps this node is part of, so you could navigate through your choice of maps. This would replace the current book nav we have now on the right sidebar. We'd probably just make this visible on Book Page nodes.
    • If the node is part of any official map, the immediate child pages of the current node in the map would be shown in a block that we would normally put at the bottom of the page (to replace the book nav child page listing we have now). Again, we'd probably just make this visible on Book Page nodes.
  7. We need the ability to convert an existing Book outline to a map.
  8. It might be useful to have a taxonomy of map types:
    - handbooks
    - tutorials (these might be linear rather than hierarchical, as in "study these pages in this order to learn about this")
    - mini-handbooks
    - Lists a la Amazon
    - etc.
  9. Possible feature: ability to navigate through a map using frames - map would stay visible in one pane, with the page content in the other pane. I'm sure frames are uncouth and stuff, but I am not sure how to keep the same map visible all the time otherwise? Maybe a cookie or GET variable could maintain the state and keep that map open?
kvantomme’s picture

reply on #4

storage
I'm not sure what you mean with stored in Drupal, right now Graphmind works with .mm XML stored in Drupal nodes, so the data is stored in the Drupal database. You of course need to parse the XML to get to the relationships.

Other parallel storage options
If you would like to have the relationships accessible without parsing XML, the options for hierarchy mapping in popular Drupal hierarchy systems would be:

  • The book module, but we would have to develop a multi-hierarchy system that keeps track of what map generated what link, which would need serious rethinking of the architecture of the module.
  • We could work through taxonomy, and map the mindmap relations onto a taxonomy that contains all the nodes of the docs generated through http://drupal.org/project/nat and than use the multi-hierarchy feature in taxonomy. But I'm pretty sure that this would not scale and again you would loose individual map contexts.
  • Another obvious candidate is the menu system, but again that would not scale and it would require
  • The best option however would be to make the .mm format a working format only and do actual storage in an RDF triple store. That would open a ton of new possibilities (e.g. compose maps based on popular relationships). We've been playing with the idea, and I'm getting really excited when I think about this, but it would require considerable development work and it's not something that will happen any time soon unless we have somebody pay the bills and I can make this the job of one of our developers.

    DITA format
    As a first step, I was thinking of an XSLT transformation that dynamically turns the html into DITA attributes and than dumps the whole thing into a DITA topic body. The HTML version would remain the primary source for the documentation. So it wouldn't require a giant transformation job, but still let us have the fancy export options. Than we can do a slow transition to a more structured format using the poorman's DITA CCK forms we developed. But we can discuss this in a separate issue.

    map this button
    It's possible to use a 'map this' flag and than import the flagged nodes using Graphmind Views integration.

    In the near term I would keep the book outline as a master map that contains all the topics. So I wouldn't turn the book outline into a mindmap at this point. Making a graphmind plugin that can manage book outlines is possible but would require a bit more work and this is not really on our roadmap now.

    kvantomme’s picture

    reply for #5

    1. Graphmind let's you add both text entries and Drupal entities (currently nodes, users, comments), the latter can be done through the Views integration. Making an automated system that could collect headings would be harder, if you go through that trouble you better also do the link. Potentially you could do a special Views query that generates a list of all the headings of a node as children of that node in the mindmap (but this is quite a bit of work). Graphmind mindmaps are hierarchies, but a hierarchy of 1 deep is a flat list. With the views query integration you can restrict to specific content types, or whatever else you want to set as filters in your views. Currently graphmind maps are viewed in the flex editor, you could however also make an XSLT transformation that converts the map into an html page.
    2. The "add to map" link could be a flag that is imported into Graphmind with a Views query. You could display a block with all the currently flagged nodes (table view with remove flag link next to the node title). You could use the Views "Search: Links to" argument to make a block that displays what maps are referencing a given node. Right now I don't think we index mindmaps though.
    3. When a user is done collecting links, they go into graphmind, right click and select the "added to map view" for importing items into the mindmap. Than they have the full drag and drop functionality. Right now, the system does not degrade, it requires Flex. You could however also export your flagged items into a flat list through a fallback mechanism. Adding additional items to a map can happen in the UI either by hand (right click > add Drupal item > node > NID) or through Views (e.g. from the flag system or with a view that searches for the argument you fill in or for a certain taxonomy term argument). We could add a remove all flags link, to start collecting again.
    4. The mindmaps would remain unpublished until otherwise set by the user. We should have a "publish" link on the node so that the user doesn't have to go into the edit mode to do this. We could have a view with a user's maps on their user profile (or on a separate tab).
    5. Admins could promote maps through a "promote" flag only available for admins. All users could bookmark maps through a bookmark flag.
    6. When viewing a node that has been added to one or more maps:
      • A block with the Views "Search: Links to" argument could show the public/user and official maps this node is part of, so you could find maps that use a certain node. We could sort the maps according to user feedback (e.g. voting, amounts of people that bookmarked a map, official maps on top, ...).
      • We could make a block that parses official maps a node is part off and uses that information to recreate the book navigation system (parent, children, next and previous links).
    7. Conversion of a book outline to a map could be done using an adapted version of the Graphmind taxonomy plugin but I'm not sure how much work that would be.
    8. Taxonomy of map types sounds really cool! (handbooks, mini-handbooks, Lists a la Amazon). With the linear tutorials I think you mean learning trajectories, I would still keep them in maps, since it's easier for people to parse the 6-7 children links bundles than a long flat list.
    9. When you click on a node in a map, the link could be opened in a modalframe. When you close it you go back to the map.

    This all sounds really feasible with Graphmind, the biggest change would be the add-on of a third mode for Graphmind:

    1. xml edit - this is the current edit screen - this could be used as the degraded edit option, potentially we could autogenerate a map based on flagged items.
    2. graphmind view/edit - this is the current view screen - users with appropriate privileges can edit the map
    3. xhtml view - used as fallback and for indexing (Google and Drupal search) - XSLT transformation of the .mm XML in the mindmap

    We would also need to create a book to mindmap plugin for Graphmind, need to check about this with itarato.

    jhodgdon’s picture

    Thanks Kristof!

    A few random notes:
    - I don't think we really care what format the maps are stored in, as long as they are in the database, so that sounds like it's not an issue. I'd misunderstood what you were saying initially about .mm files, apparently.
    - I don't think using a Flash interface for editing will fly (everything else we do is JavaScript), and we definitely would not adopt something that wasn't accessible under WCAG standards.
    - Is Graphmind using any external library code, and if so, is it open-source with a compatible license?
    - I definitely agree that we would want both linear and hierarchical maps to be stored/managed the same way.
    - The Graphmind project page has a security warning on it that sounds really dangerous - obviously we would need that to be cleared up before we'd be able to use the module. It isn't OK if a map would show people information they don't otherwise have information to view.
    - That security warning makes it sound like the map is storing information that is duplicated elsewhere in the database. That is generally not a great idea... What information is actually stored in the map? I was assuming that a map would be a collection of links and link titles.

    Anyway... It sounds like the specs I laid out in #4 are clear to you, and I think they reflect what we would like to work towards. If your module gets us all or most of the way there, then we'd be likely to adopt it (at least as a starting point). It sounds like you are continuing to work on this project, so hopefully you'll keep us posted.

    kvantomme’s picture

    • Right now Graphmind is Flex, we have been thinking about making a JS HTML(5) version, but that would be a considerable investment that will probably not happen unless someone makes it our daytime job, or we make it into a GSoC project (one of my colleagues would definitely be interested in that). But I don't get why a module with a Flex GUI is a no go. The server side is PHP.
    • Graphmind's Flex code depends on the Flex SDK which is MPL so we can't redistribute it together with GPL licensed code however, on the Adobe forums you can find the following http://forums.adobe.com/message/1144578?tstart=0 :
      "If your application is just the output of Flex then you don't have a license problem (as the output code is not affected by the MPL). If you are looking to redistribute the SDK itself you would have a problem, we are not GPL compatible in that regard." Graphmind is available as a Drupal module with the Flex output included on drupal.org. You can see it as a resource much like an image, the program with which you created the image does not have to be GPL for it to be includable in a GPL licensed project. The Flex source code however is also available on GitHub (right now doesn't have a clear license message yet).
    • The security warning is probably too scary, when you use views to pull in data into the map you can include entities that only you have access to, the titles of these with some of their metadata are than stored into the mindmap. If than a user with less privileges sees the map, there is no permission check (like we do have in the menu system) that only shows those mindmap items that you have access to. Sometimes the title of a page can be sufficient to break some level of confidentiality, that is why we have the warning. On Drupal.org however I can't see how this could be an issue. If a user copies the title to a node into an overview node you also don't do a permission check and potential clean up on the content level.
    • The map can contain attributes, if it is generated from a Drupal entity these attributes contain a bunch of metadata from the object. I've now posted #1003744: making the security warning no longer necessary with a potential solution for that issue.

    I really love this dialogue! Your feedback has helped me understand a few issues that we hadn't find a way to solve before :)

    kvantomme’s picture

    About WCAG, the graphical drag and drop UI would not be available, but I can't see how you could make that work with JS either. The XHTML view that I suggested in #7 would however be accessible. If we than also have a fallback option that dumps the flagged nodes in the right format, but without the drag and drop UI, I think we would be in the clear.

    jhodgdon’s picture

    Re: dialog: That is why we have issues and a Drupal community. Glad it is helping to move your project forward! :)

    RE: security: I don't think that the module should generate links to nodes that the user does not have permission to view. This could come up on d.o - such as unpublished nodes, which I can see but most users cannot. I agree that on d.o it is probably not a big deal to display a saved node title, but on the other hand, I am not necessarily convinced that storing a node title in a map is a good idea. If someone updates the node and changes the title, would we want the map to still use the previous title or to get the updated title? I'm not sure what the answer to that is, but if the node title was stored in the map, it for sure wouldn't get the new title.

    Re: flex and licensing - I am not sure about this, will have to confer with someone else about it. Agreed that the editor used for creation of code has no bearing on licensing, and we would only be distributing the flex code, not the SDK. WordPress has similar licensing, and definitely distributes with some Flex code, so it is probably OK, assuming that you wrote the Flex code and it isn't a derivative of some other work that has a different license.

    RE: WCAG - we have ways in Drupal 7 currently to degrade drag-and-drop interfaces (e.g. Menu editor) for non-JS/non-visual users. Hopefully a JS version of the mapping tool could reuse some of the menu editor code, since it is also hierarchical and WCAG-compliant (at least, I believe it is in D7 - a lot of work was done in D7 to make it WCAG compliant, and I believe the results were satisfactory). I wouldn't want the fallback editor to require specialized knowledge of how to type in accurate and valid XML following a particular schema, if that is what you were suggesting. That would not be very nice, since visual users would have a UI that would require a lot less knowledge and care.

    kvantomme’s picture

    The .mm XML can be seen as a cached version of the map, Graphmind currently has a refresh feature that reloads the attributes of a Drupal entity, maybe we could do a force refresh at some point, so that the titles get updated.

    I see 3 strategies for getting around the access permission issue:
    -do on the fly rendering at every request straight from the source data (this would be pretty expensive, but could potentially be done through a forced map refresh with the current user's permissions).
    -do on the fly rendering based on an abstraction layer that acts as a caching layer of the meta data, and that contains the relationships generated in maps and the permissions to that information (e.g. an RDF triple store, this would allow us to do really cool stuff like aggregated maps that show most popular relationships)
    -set permissions on a map level, (e.g. different roles, specific users) and only load content that is accessible by that role. I'm pretty sure that the services module does not support this at this point (user centric permission model).

    I guess we should have a closer look at the menu system and how this issue is solved there.

    The D7 WCAG drag and drop solution is table based, and is IMHO at least for mindmaps inferior to the 2D drag and drop in Graphmind. I think 2D content is going to be an issue for visually impaired browsers, but we could implement the lineair D7 drag and drop UI on the fall back option.

    arianek’s picture

    Issue tags: +DITA

    hey - just catching up on reading through some of these issues...

    i'm just wondering, can you summarize all of the additional modules and libraries that would need to be installed for what's proposed here? we'll need to vet this with someone from infra (likely drumm) before we go much further. it sounded like there was big hesitations to install new modules that are for specific purposes (ie. not useful outside of docs) on d.o, so would rather run this by them sooner than later!

    Itangalo’s picture

    It feels a bit dangerous to throw myself into this discussion, but it seems to me that the book management described in this thread could be accomplished with DraggableViews as base. I hope to return soon with a proof of concept, to show what I mean.

    Cheers,

    Itangalo’s picture

    Ok, so now there's a quick demonstration (and a downloadable feature) available at http://nodeone.se/blogg/managing-multiple-book-structures-with-draggable.... It uses DraggableViews to manage book structures in two different ways:

    * Managing collections in 'book container' nodes, which you can create as many as you want of
    * Managing collections with a flag, meaning one collection per user

    I hope it can be of some use or inspiration, though some details obviously remain to sort out.

    Cheers,

    jhodgdon’s picture

    Hi Itangalo!

    This looks great, at least as a start! I watched the screencast and I agree with everything you said about the pluses and minuses. We have proposed specs above for what we need on d.o in comment #5, and I agree that this system could probably be made to satisfy all or most of that specification.

    One comment: I like the idea of flagging things for the collection... One thing I can see that would be nice is a way to take the flagged "my collection" and turn it into a formal Book Collection node that others could see. Also, I think users might need/want to have multiple lists.

    Itangalo’s picture

    Glad to hear that you like the sketch! That inspires me to work further with it.

    I don't know when it will be, but when I do I will get a plan for all the features in #5 – and in particular discuss any of the features I don't know how to accomplish.

    I had actually already been thinking of a way to convert a flagged collection into a collection managed in a book container – at the same time emptying the flag list. (I see it as 'saving' the list.) I think book containers is the only reasonable way to manage multiple lists per user – but I'll give a bit more thought before saying anything for certain.

    Cheers!

    jhodgdon’s picture

    Agreed with comments in #17. Sounds like the right approach to me. Looking forward to seeing more!

    arianek’s picture

    @ltangalo - just caught up on this and watched the demo. it looks very straight forward! is it only using flag + draggable views?

    i couldn't quite tell, but this *does* support an individual book node being part of multiple lists, yes? i think that's one of the most important parts.

    and as far as the html output and theming, we can find help to improve that if this looks promising. should we give it some more time, or run it by drumm for some input from the infra side?

    jhodgdon’s picture

    arianek: to answer your question, I believe that the way this is set up, the Book node has a multiple-valued noderef to the book container nodes, so each book can be made to be part of many containers/maps.

    Itangalo’s picture

    @arianek + jhogdon: Yep, that's right! The nodes being collected in books can belong to multiple book collections, and just as Jennifer says it is a node reference managing this.

    arianek’s picture

    ok, that's darned cool. it seems too easy... are there any catches or drawbacks aside from the theming? is it a big performance drag if we allow the per user ones?

    jhodgdon’s picture

    One concern I have (besides it not being quite all there as far as satisfying the specs yet, which I think it has the potential to do)... scalability. We have some books on d.o that have quite a lot of nodes in them. Is it possible to build books with very large numbers of nodes with this system?

    Itangalo’s picture

    FileSize
    13.15 KB

    Ok, I had a new proof of concept created last night!

    There's a screencast describing it at http://vimeo.com/18460761

    Attached is a feature with all the configuration from the demonstration. If you want to use it, you should use the patch for DraggableViews at http://drupal.org/node/594086#comment-3902010 and also the custom mini-module included in the attachment.

    Cheers!

    Edit: Anyone interested in more technical details can have a look (and laugh) at http://vimeo.com/18463048

    jhodgdon’s picture

    Itangalo: What new features are in the latest proof of concept? We're excited you're doing this, and I certainly encourage you to post updates on your progress... But I personally might not make time to watch every screencast, without a hint of what exciting new feature I'll be able to see in action. :)

    Itangalo’s picture

    Ah, good point there.
    I'll get back with a compact list of features, but on my schedule for now is sleeping.

    Cheers,

    arianek’s picture

    THIS IS AWESOME!!!!!!!! i just watched this with my mouth open exclaiming (to an empty room) how great this is! quite different from the original, and i think really, really practical. simple and completely useful.

    can you provide a list of modules we'd need to add so i can ping an infra team person and see if this is realistic?

    i've tweeted the link to the video as well, hoping some others will provide feedback. thanks so much for the work, i am really hoping we might be able to implement this after a little more review from various people/teams and discussions about who should have access to what (assuming others support as well). it definitely addresses the book outline needs in even more depth than i had thought was possible!

    so exciting!

    Itangalo’s picture

    @arianek: Wow! Thanks a bunch! Here's a technical declaration of contents, and also some notes that are good to be aware of when considering this for any production site.

    The projects (and modules) needed for this to work are, in drush language:
    * cck (content nodereference optionwidgets text)
    * content_access
    * draggableviews
    * flag-2.0-beta4
    * rules
    * views
    * views_bulk_operations
    (+ features, ctools and strongarm if you want the functionality exportable, which I recommend)

    NOTE:
    * It is Flag 2 that's used in this proof of concept, which is necessary for exportability. It might be possible to use a voting module such as Mark instead, though.
    * DraggableViews is patched with patch from #594086: respect for relationships?. This patch is not yet suitable for a production site.
    * There are a few ugly custom PHP arguments used in Views, which I don't recommend use on a production site. Most or all of these could be removed on sites using Panels and Page manager.
    * There is also the custom mini-module, with one hook_form_alter and one hook_nodeapi.

    Itangalo’s picture

    @jhogdon: Here's a declaration of content from a feature perspective:

    * It is possible to use flags to add favourite documentation items to a personal list.
    * It is possible to create book-like collections, containing node references to items the collection should include.
    * It is possible to set collections as private or public. Default is private.
    * It is possible to create a new collection based on your private list.
    * It is possible to arrange items in a collection in a tree structure using drag-and-drop.
    * When viewing an item in the context of a collection, all the items in the collection are displayed in a block.
    * When viewing an item, all (public) collections it belongs to are displayed in a block. Each collection name is a link to viewing the current item in the context of the other collection.
    * When viewing a collection, all items within it are displayed in a block.
    * It is possible to use flags to add favourite collections to a personal list.
    * There are blocks showing favourite items and favourite collections.

    All functionality is built with standard Drupal tools, making it easy to extend it with more documentation node types, taxonomy terms, et cetera.

    NOTE:
    There is still no previous/next functionality when browsing items in the context of a collection. I've had quite a look around (for client project), and my conclusion is that there is no module available supporting the kind of paging functionality this feature needs.
    It would probably not be a big thing to write such a module as a Views plugin, and I hope to file an issue at Custom Pagers soon to start discussing this.

    Cheers!

    lisarex’s picture

    Wow, this is radical stuff!! (I watched the screencast in #24). I think Itangalo is on the right track.

    I think this could be great for the individual that spends a lot of time in documentation pages and/or wants to compile custom collections of docs nodes. However, we should just be cautious that we don't overwhelm the casual user or otherwise impact their ability to navigate to what they need. A lot of our docs titles are really long so we would probably want to look towards a customized display/theme for docs pages?

    Has there been an in-depth research on how various categories of users use the docs pages? And their typical mindset, habits etc when they are looking for and at docs pages? I know for many, they arrive at a docs page is via deliberate Google search :D If we know more about what people need, it can help us shape the best experience for them.

    I'd be happy to lead that little usability study :) ---> and will start a new issue for it

    jhodgdon’s picture

    Priority: Normal » Major

    I'm upping priority on the highest-priority issues for docs team infrastructure.

    RE #30 - We definitely need to think about making the pages more modular and titles better, in conjunction with this. And I think we will mostly promote the "main" or "sanctioned" navigation/maps, which hopefully will not overwhelm users. I suggested above that other maps could be collapsed?

    Usability study - good idea, please tag the issue "docsyvr2010" and maybe some of the other tags here.

    agentrickard’s picture

    You might also look at http://drupal.org/project/skeleton, which allows for the creation, management and duplication of book outlines.

    In effect, you create a Book "skeleton" once, with the node setup and hierarchy you want. Even sample data if you like. Then others can clone that skeleton to auto-generate new "instances" of the book.

    It has a much smaller dependency stack than @Itanglo's solution, and I wonder how much of his approach should be rolled into that module, which has been around since Drupal 5, and which devientintegral has done some excellent work, especially with Token integration.

    jhodgdon’s picture

    agentrickard: does it have a nice UI?

    agentrickard’s picture

    Dunno. It's a multistep process, which I think needs some of the new UX love to add drag-n-drop hotness.

    agentrickard’s picture

    Bah, my quick test failed, so maybe it's no use to you.

    Itangalo’s picture

    @agentrickard: As far as I can interpret the Skeleton module, it does not allow a book page to be in multiple books. Am I missing something?

    @anyone:
    The dependency stack for the proof of concept could definately be a problem. The biggest one is probably DraggableViews itself – the other modules could probably be replaced pretty easily with some custom coding if that's preferrable. But DraggableViews is pretty heavy.

    A larger problem, though, is how arguments are managed in some of the views used for the feature. I wouldn't like to recommend PHP in configuration. :-(
    I'm looking into ways of changing that into some custom but solid code – I'll write back if I come up with something good.

    Also, the pager problem is still left. Regardless of solution, I think there will be need of new pager functionality if a node is to appear in more than one book-like collection.

    Cheers!

    drumm’s picture

    Adding modules like draggable views is certainly possible, with good reasons. The main concern is stability & maintainability, once something is added, it probably won't go away. Upgrading to Drupal 7 is important at the moment, that will be happening in the coming months.

    Overall, this feels a bit heavy. For Drupal.org, the access control is not needed, and probably won't happen. Node access control tends to consume resources. I think it would be good to keep book module running the basic hierarchy, since it is already doing a decent job of it.

    jhodgdon’s picture

    I don't think we want to keep book module running the basic hierarchy. Even as things are now, we could use the one-node-multiple-places feature in the main documentation books, and that was actually the main purpose of this idea. The fact that others could make outlines is just a pleasant side effect.

    lisarex’s picture

    I've create the issue for usability testing/user research here: #1024642: Do some usability testing and user research on how people use d.o. Documentation

    arianek’s picture

    Component: Other documentation issues » Docs Infrastructure
    Itangalo’s picture

    Component: Docs Infrastructure » Correction/Clarification

    @drumm: I've been digging some more into how to display multiple hierarchies, and I'm persuing an alternative track that puts all book-like structures in a single menu. This would be a *really* big menu, with possibly thousands of entries, but it would allow relying on standard menu items for other functionality (which could be really good for future features).

    The track would probably need the Menu Block module, to cut out the slice of the menu that represents the current book-like structure.

    Two questions to someone who seems to know a bit about drupal.org infrastructure AND performance issues:

    1. Would it be bad for d.o to have a menu with thousands of entries?
    2. Would it be bad for d.o to have Menu Block installed? (Or is it perhaps already installed?)

    jhodgdon’s picture

    Component: Correction/Clarification » Docs infrastructure

    Changing component back. The component "docs infrastructure" doesn't seem to want to be selected in the comment box.

    agentrickard’s picture

    Menus with thousands of entries are a very bad idea, for scalability reasons. The memory required to build the menu cache is overwhelming.

    Add to that that Drupal's UIs don't scale to handle that many items. Menu overview screens, for instance, are not paginated and use jQuery, which will crash or freeze most browsers.

    Trust me. I've had to work around this issue.

    jhodgdon’s picture

    Yes, pagination would be something to consider in the UI. We definitely have some book outlines that are quite large.

    Itangalo’s picture

    @kenrickard & jhogdon: Thanks for quick reply! I'll add that to my list of pieces-of-knowledge for Drupal scalability.

    I'll abandon that track, and pursue the other one. A lot of things at work hinders me from spending the time I want on this issue, but I will post here when I have something new to show/tell/ask.

    agentrickard’s picture

    I do actually have a module for D6 (unreleased and not recommended for d.o.) that paginated the menu form. It also turns the menu node selection form into an autocomplete. Both are needed to work around the issue of the memory required to load and parse a really large menu.

    Itangalo’s picture

    @agentrickard: I suspect that the there will be problems when caches are cleared and the menus have to be rebuilt – not only when they are called. :-/

    agentrickard’s picture

    Yes. Definitely.

    lisarex’s picture

    Should we talk about nodequeue as a possible solution? Yes, nodes can definitely appear in multiple nodequeues and the maintainer ezra-g is my colleague at GVS so I feel confident about suggesting this again.ezra-g can weigh in if needed.

    Itangalo’s picture

    Yes, I think Nodequeue could be of help. It wouldn't solve the problem with menus and hierachies, but it would allow collecting book pages (as an alternative to using node references).

    So far the only sensible solution to managing the hierarchy is DraggableViews, but Nodequeue integrates well with Views so these should be combinable.

    A positive thing with using node references instead of Nodequeue would be that you have a natural way of making collections of collections (just by grouping collection nodes), while it is much more difficult to make groups of several nodequeues. This isn't a functionality that is asked for, but I can guess that it will become relevant to tag collections.

    Gosh, I wish I could spend some time on this. *grump*

    jhodgdon’s picture

    Itangalo: What do you mean by "It souldn't solve the problem with menus and hierarchies?" If nodequeue does not support hierarchical outlines, then that wouldn't really help us. We definitely need an outline structure. I don't know enough about Nodequeue to know if it does or not.

    Itangalo’s picture

    @jhogdon: I haven't used Nodequeue for some months, but as far as I know it doesn't support hierarchies -- that will have to be done in some other way. Sorry for being unclear on this point.

    @anyone:
    The options I see for managing *multiple* hierarchies are:

    A) DraggableViews. This module supports managing hierarchies with the help of node references, book structures, taxonomy parents and also by a native parent handler. I'm pretty sure the native parent handler is the best choice for us.
    B) Node references. This would pretty quickly become a mess, since one book page can have multiple parents and we would need to know which parent belongs to which book. (At least I can't think of a way to do it.)
    C) Taxonomy terms. This has the same drawback as node references, but also an additional drawback as we would need to associate each book page with a unique taxonomy term. Yuk.
    D) Menu items. This *could* be a pretty good choice, if it wasn't for the fact that we would have a ton of menu entries -- with the performance drawbacks described in previous comments.

    Those are, I think, the only multiple-hierarchy options I can think of in Drupal 6 (excluding mind-boggling edge cases).

    If I'm right -- and I'd be glad to get more options -- then DraggableViews is the only sensible choice.
    If so, then a solution would most likely look essentially like the feature provided in #24.

    What should be done to improve the feature is:

    * There should be a proper argument handler in Views, to get rid of ugly PHP code in configuration. (After writing my previous comment I spent half an hour or so trying to write this, but I really didn't get anywhere. I'll have to get some help to sort that one out.)
    * There should be a nice forward/back navigation. If we settle for a jump menu it could be implemented directly using CTools, but otherwise new code is needed. I'm dreaming of implementing this as a Views style (#1016874: Ideas for Custom Pagers 2), but time will tell.
    * The DraggableViews table-style lists should be changed to a menu-style list, with collapsible sections and the active section open.

    Features like private lists and quick lists are optional and should of course be discussed.

    jhodgdon’s picture

    Nice analysis! Sounds like there is a roadmap for what needs to be done...

    Itangalo’s picture

    FileSize
    4.36 KB

    I got some time to play with this problem this weekend, and it actually resulted in something useful!

    Attached is working concept for using Views to create pagers, as described in point two in #52. The module provides a Views style plugin for creating a pager – using fields in the view to recognise paths and setting previous/next texts.

    For some reason my screen capturing software won't really cooperate with me, but I'll make a new attempt after posting this comment. Hope to be back soon with a video that quickly explains what this is all about.

    //Johan Falk

    EDIT: All right! It is so much better when screencasts have sound.
    http://vimeo.com/20433175
    http://www.archive.org/details/PocPutAPagerOnAnythingYouLikeWithFreePage...

    EDIT 2: If anyone is interested in more details, there is now a blog post describing the module at http://nodeone.se/blogg/put-a-pager-on-anything-you-like-with-free-pager...

    Anonymous’s picture

    Hi Itangalo

    Congratulations for FreePager

    Is it possible to drupal 7?

    Best regards
    ArchGalileu

    www.gasparsantos.eu
    www.cameratanovnorte.eu
    www.quartetodouro.eu

    servantleader’s picture

    When will FreePager be an official module on Drupal.org? I have been looking for a module exactly like this and was about to start writing one myself. Great job.

    Itangalo’s picture

    @servantleader: I'm happy to make a sandbox project as soon as I get the time to learn the sandboxy thingy.

    If you already know how to do this, feel free to put up the code and hack away. (But please add me as a co-maintainer.)

    I don't think it is appropriate to make it a full Drupal project until someone who knows Views plugins better than me has had a look at a few things (like making a preprocess function work, and making the view empty if the current URL doesn't match the URL list). But a sandbox project could be started right away.

    @ArchGalileu: A Drupal 7 version won't be planned until there is a real version for Drupal 6, at least from my part. The igniter for this project is having a pager in documentation with multiple outlines here on drupal.org, which means that it is Drupal 6 that is the focus. However, if anyone is interested in porting to Drupal 7 I'll try to help.

    arianek’s picture

    So, I think this stuff is totally awesome. But I know there's still the issue of introducing a number of new modules to d.o which is a hurdle (or possibly barrier). We should try and talk between whoever is around this week (jhodgdon, drumm, itangalo, lisarex, rfay, maybe try and snag webchick too) about how possible this is.

    We'd also need to start hashing out some ideas about:
    - permissions etc. as far as using custom collections, and whether those should become shared outlines
    - theming
    - structure would be totally managed by draggable views (not book outline) so would need some kind of migration script for the outline
    - need to do the patch for draggable views to not use *all* arguments, but only one to track different collections

    And coincidentally once this was done, we would then be in a position to migrate out of book module completely since we would not require any of its functionality.

    Itangalo’s picture

    Wohoo! I got more good stuff done.
    I just completed a module that solves issue 1 from #52 – it transforms a nid argument in Views to a string including nids for all referenced nids (for a selected node reference field). It is available at the drupal.org sanbox: http://drupal.org/sandbox/itangalo/1083254

    It should be combined with some functions that allow you to use another argument as default argument in Views – I'll have a look around and see if that module hasn't already been created.

    Still left to do: A good patch for DraggableViews.

    @arianek: I fully agree that it would be a good thing to talk and see if it is at all possible to get functionality like this into drupal.org. Meeting here at DrupalCon seems like a good idea – maybe a BoF about this?

    arianek’s picture

    w00t! if most of us are still here Friday, could talk at the docs sprint for a bit?

    Itangalo’s picture

    ...and for information, the Free pager module is now available as a sandbox project at http://drupal.org/sandbox/itangalo/1083296.

    Itangalo’s picture

    Left to do before this feature works in a clean way (according to #52)

    * Good patch to DraggableViews, to restrict which arguments are used for storing order/parent.
    * A small Views default argument plugin, to allow reading NID from arg(2).
    * Someone with experience of coding Views style plugins should review Freepager.

    Note: If for any reason docs pages were to be moved to documentation.drupal.org, this feature can be drastically simplified by using Page manager in CTools – basically all the problems with letting Views create default arguments would disappear.

    jhodgdon’s picture

    So Itangalo - I think we are going to need to have an outline/map maker in Core for the new d8 help system. Obviously, DraggableViews is not in Core. Any suggestions as to how we might accomplish this?

    Itangalo’s picture

    Woaa. You're absolutely right. This kind of help system would be really nice to have in core – so far I have mostly just thought about drupal.org.

    *think, think*

    I think I see three different approaches to how this could be implemented in a future core:

    1) Including Views and DraggableViews in core. This will not happen.
    2) Improving the Book module to allow multiple outlines. This would be a sensible improvement, but on the other hand also kind of weird if you can get the same functionality from DraggableViews.
    3) We could also have a stripped-down help handler in core, which gets automatically upgraded if you install DraggableViews. This seems to me the most reasonable solution.

    One might also consider using the Book module more or less as it is right now – without allowing pages to be in multiple outlines. Though the help/docs pages on drupal.org really could use multiple outlines, there is probably no need to implement this in a local Drupal installation – there are no overlapping page collections. However, this approach would probably create a mess if you want to change to more sophisticated help page handling in the future.

    There are really some overlaps between this issue and #1031972: Discussion: What would a better help system for D8 be?. The solutions for both issues must work together.

    jhodgdon’s picture

    Right, that's what I'm thinking - #1031972: Discussion: What would a better help system for D8 be?. I think that if we want to have a good help system in core, it needs the ability to have multiple outlines. I will update the specs there shortly. The help system there will not probably be using the Book module, but maybe we could have a generic map maker in Core and the Book module could use that as well as the help system? Hmmm... (wheels of ideas grinding in my head...)

    lisarex’s picture

    Itangalo, this looks really awesome. Looking forward to testing it out. Glad to see this is moving forward...

    arianek’s picture

    Just catching up - I really like the idea of merging the effort on these two issues to get something useful into core for books too and/or having some nicer nav in the Help system. Very interesting...

    One question about the latest prototype: have we now lost the ability to do per-user custom outlines (and to share those)? I thought that was an absolutely great feature that a lot of people would love to have on d.o.

    ps. I now believe you are both the views master and the screencast master. So awesome being able to see screencasts of the functionality for those who aren't able to (or interested enough to) apply the patches. :)

    Itangalo’s picture

    I'm sketching on some new ideas for these two issues in combination – right now only at a concept level (no examples to show).

    The idea I have is to have a "global reference field", where you can reference to something like http://drupal.org/documentation/modules/field. If there is a page on your site with this global reference value, it will be the target of the reference. If not, you can either visit the external source or download the page locally to your site. (This should be extendable to allow fetching pages without actually having to visit them.)

    As before, there is an entity to create collections – a (sortable) list of global references.

    I hope to discuss these ideas with heyrocker (Greg Dunlap) pretty soon – he's the man when it comes to staging and deployment (which this actually is a case of). If anyone has comments or ideas before I get back with heyrocker's feedback, I'd of course be happy to take part of them.

    Note: I don't think it is reasonable to add the capacity to manage hierarchical structures in Drupal core – this would be duplicating too much functionality that is (and most likely should be) in contrib land. It should, however, be possible to download a module or two and convert the plain lists of global references into tree structures.

    @arianek: The ability to create your own collections is not forgotten, just moved to the background for some time. It is a fairly straight-forward process, and I feel it is more urgent to investigate how to actually store these collections without having to download 30 modules. And thanks for very kind words about Views and screencasts!

    arianek’s picture

    Sounds great! I concur that hierarchical structures in core isn't *necessary* (and if we wanted it, I tend to think it would make the most sense to work on improving book module anyway).

    ps. yay for per-user collections still being in the plan. :)

    jhodgdon’s picture

    Actually, I'm pretty sure we *do* need the ability in core to create hierarchical structures. We have at least two versions in core now: Menu and Book. We will need this ability also for Help in D8, according to the latest plans.

    If we can't have the ability to make Help outlines in Core, then we should rethink the plan for help in D8 now. Itangalo: why did you say in comment #68 that it is not possible in Core?

    Itangalo’s picture

    @jhogdon: "Itangalo: why did you say in comment #68 that it is not possible in Core?"

    What I meant was that it is not currently possible (in core) to create the kind of hierarchical structures we would want to use – like using one piece of content multiple outlines.

    The menu system *does* allow this, in a pretty difficult-to-manage way, but if we want to use the same solution on D8 installations as on drupal.org handbooks, want to stay away from using the menu. (Unless we accept thusands of menu items to rebuild on each cache clear, that is.)

    Maybe the book module should be changed/improved, as has been suggested – allowing an item to be used in more than one outline. That would proably require a quite heavy rewrite of the module, but it makes sense if we want hierarchical help structures in core.
    Maybe there is a clever way of re-using menus for creating the outlines, but I don't really see how that could be done. (Ideas are appreciated.)

    @jhogdon: How important is it to have hierarchical structures on help pages in core? Wouldn't forward/next navigation be sufficient for a core installation?

    LeeHunter’s picture

    It's actually a little surprising to me that something like this isn't already in core, since one of the most important reasons to use a content management system (at least for some organizations) is to achieve independence of content and structure. If a piece of content can only belong to one structure, independence is not there.

    Forward/next navigation is not enough for a help system. When a user resorts to help, they are almost always looking for specific information, so some kind of overview (table of contents) is really important in helping them zero in on what might actually be useful.

    jhodgdon’s picture

    Agreed. We absolutely need to have hierarchical structure navigation in core for the d8 help initiative.

    Itangalo’s picture

    Yes. You're both right.

    After some hours of thinking, I'm convinced that this should be a core feature, and that it is surprising that we don't already have it.

    I think a good approach is to extend the sorting of Drupal's standard multiple-value fields to incorporate hierarchical sorting as well. I don't have any skills in JavaScript or writing entity fields (or widgets), so I don't think I'll be able to make a proof of concept within a forseeable time.

    I'll write again after our morning meeting here at NodeOne, with some more information about ability to import and sync help pages.

    Itangalo’s picture

    Ok, here's some clarifications and more ideas to #68 – after talking to heyrocker.
    I think important parts of how to manage help and documentation pages are covered by the following setup:

    1) An entity 'docs collection', that works much in the same way as the current Book page node – with the important difference that the entity itself contains references to all the docs pages it contains. (In the current Book module, nodes themselves declare which book they belong to – which is why a page can't be in more than one book.)

    2) An entity 'docs page', the structure of which is yet up for discussion. (The structure of the docs pages is not important for this solution, and it could even be used for many different entity types at the same time.)

    3) A field 'docs reference', being in docs collections to refer to docs pages. This field has a number of important properties:
    3a) The link value stored in the field is a (kind of) global reference, like http://drupal.org/documentation/modules/field (or http://drupal.org/node/648220).
    3b) The link displayed in the field depends on whether there is a local copy of the globally referenced entity: if so, the local link is used; if not, some different things may happen (depending on field/widget settings):
    i) A link to the remote entity is displayed.
    ii) A link for downloading the remote entity is displayed.
    iii) The remote entity is automatically downloaded, and a local link is displayed.
    iv) The user gets to choose whether to visit the remote entity or download it.

    3c) When editing a docs collection, the field entries cannot only be sorted in an order, but also in a hierarchy.
    3d) In the field settings there is an option "Create a block for navigating these items", creating a block analogue to the blocks available for books. (A menu, without using the Menu module.)
    3e) Each field creates a block "Collections where this item appears". This block links to all collections where a viewed docs page appear (except for the docs collection currently viewed, if any).

    4) When viewing a docs page, there must be a context set to know which collection is active. (This could be decided by using a path on the form docs/page-id/collection-id, or some other way.)

    5) When viewing a docs page in the context of a collection, there should be previous/next/up links, just as with books.

    Some additional comments

    * The solution above does not incorporate translations of docs pages, but could probably be extended in a fairly straight-forward way to do this.
    * The solution above should be possible to implement as contrib for D7, and it should be possible to implement as part of D8 core (as an updated Book module).
    * The solution above does not solve the problem of how to include links to docs pages at certain page elements, or on certain pages. But I'm fairly confident that it will work with whatever system we come up with to manage this.
    * Creating your own private collections, and turning them into shared collections is not covered in the solution above, but it can quite easily be extended to do this (with contrib modules). (Fear not, arianek!)
    * According to heyrocker, 3a and 3b is more or less how the Deploy module currently works (but it also has a lot of smart extra stuff). Heyrocker also says that Deploy has a pretty hairy problem since it can't make assumptions about the nodes/entities it is deploying, but since we will know what docs pages look like we have a big advantage. I think it is reasonable to use Deploy (or parts of it) to manage pushing and pulling of content makes very much sense. Deploy is not ready for D7, though.

    arianek’s picture

    3B: "depends on whether there is a local copy of the globally referenced entity" ....so, can someone techier than me briefly explain what this whole local vs remote entity business is about? i am not quite grasping it.

    otherwise that really sounds great - and i think it would be FANTASTIC if we not only ended up with a solution for d.o docs and possibly also help, but also for the poor neglected book module. it would be really cool to give it some cool functionality that would make it actually useful again! that said, i don't want to heap too much into this initiative, but... yah, i'm all for it if that's possibly a way to approach this.

    jhodgdon’s picture

    RE #76 - I think this is referring to the idea that if you are importing help docs from help.d.o or some other site, you might or might not have a local copy of the doc. If each doc has a universally unique ID (rather than just a node ID, which obviously is not unique from site to site), then you would know whether you have a local copy of that particular doc with that particular universal ID.

    arianek’s picture

    aha. got it. thanks :)

    rfay’s picture

    subscribing - way cool

    yoroy’s picture

    Subscribe with a request for a summary of current issue status :)

    arianek’s picture

    @yoroy - see:
    http://drupal.org/node/995370#comment-4248512 for working specs
    http://drupal.org/node/995370#comment-4176208 for itangalo's sandbox
    http://drupal.org/node/995370#comment-4143898 for most recent screencast of prototypes

    :)

    Itangalo’s picture

    Also @yoroy:

    The prototype is in Drupal 6, to fit on current d.o. Since then the focus has shifted to Drupal 7 and possibly Drupal 8 – which makes the prototype only useful for visualizing documentation features.

    There is currently only concepts available for D7/D8, no code or configuration. jhogdon has summarized this thread and #1031972: Discussion: What would a better help system for D8 be? at http://drupal.org/node/1095012.

    @arianek: Should I continue to work with the prototype for managing help pages on d.o? (For me these two issues have become one and the same, but I now realize that they might not have to be.)

    arianek’s picture

    Eep. I'm going to defer to @jhodgdon here. She's basically the mastermind of how these might intertwine. For me from docs team perspective, priority is definitely the online documentation on d.o (and the help system is a separate core initiative). But I realize they are pretty well aligned, so I wouldn't want to say that one is more important if it should hamper efforts on the other!

    jhodgdon’s picture

    d.o is planning to move to d7 at some point, but I don't know what the time frame is.

    Given that, my preference would be to develop a d6 or d7 contrib module that is core-worthy. Then we can (a) add it as d6 contrib to d.o to deal with our current doc books needs (b) add it to the (hopefully) help.drupal.org doc server for the d8 help initiaive, as a d7 contrib module (at least I bet the help server will be a d7 platform), and (c) add it to core for others to use on their sites to build help and books.

    If the d.o migration to d7 time frame is soon enough, then we could skip the need for a d6 contrib module in (a) because it would be d7.

    Itangalo’s picture

    @arianek + jhodgdon: Thanks for quick feedback. You're doing a great job.

    Itangalo’s picture

    For information: I have started some experimental work on a D7 entity field, for connecting local docs pages with (for example) docs on help.drupal.org. I'll post an example when I have something useful to show.

    arianek’s picture

    this is already so much awesomer than i had hoped, the d7 options make me giddy. :)

    definitely think we should build for 6 but it couldn't hurt to have an idea of how this would migrate before building the final version.

    Itangalo’s picture

    Update: I have now started a sandbox project to create and manage references internally on a site as well as to remote entities (such as help pages on drupal.org).

    It can be found here: http://drupal.org/sandbox/itangalo/1112890 ("URL IDs and Lazy URL ID Reference")

    From the project description (modified to apply to help.drupal.org):

    The URL ID module provides a field that gives an entity a 'global' ID, based on the domain name, entity name and entity id (such as 'http://example.com/node/1').
    The idea is that remote entities can be downloaded, inheriting the remote URL ID – a node could have the URL ID 'http://help.drupal.org/node/123'.

    The Lazy URL ID Reference module provides a lazy-loading reference field, utilizing URL IDs. The idea is to refer to a URL ID such as 'http://help.drupal.org/node/123'. If there is a local entity with this URL ID, the reference field will point to it (eg. node/456), if not, it will point to the remote source (eg. 'http://help.drupal.org/node/123').
    Furthermore, URL ID fields have fetchers – plugins that allow fetching remote data and saving it locally. These fetchers can also affect the reference link, for example by automatically download the referenced entity, or to redirect to the remote source.

    Itangalo’s picture

    Reply to myself in #68: There are more alternatives for creating hierarchical structures than I was aware of – http://groups.drupal.org/node/23899

    I will check out the Tree module, since it (at least at a first glance) seems similar to what we want.

    The chase goes on.

    arianek’s picture

    still reading... ;) @itangalo - i talked to our dev team about a bunch of this and a couple seemed interested with the help system and possibly this stuff. would you be interested in a co-conspirator for doing the prototyping if i could find someone? or is it easier to do this solo?

    lisarex’s picture

    Found this old issue.... possibly will be implemented for D8! #5901: Let a book page appear in multiple books

    Glad this issue is progressing!

    Itangalo’s picture

    @arianek: I would be very happy to be a co-consiprator!

    @all: I've been mixing up this issue with stuff over at #1031972: Discussion: What would a better help system for D8 be?. I will from now on use this thread only for discussing multiple help outlines on current drupal.org. So there.

    Itangalo’s picture

    @lisarex: Wow! Thanks a bunch! This is great stuff, and great stuff to know.

    Coornail’s picture

    I tried the feature in #24, and maybe I'm missing something, but I found some issues:
    The feature did not include the module called "Custom", this didn't seem crucial, so I just removed from the .info file.

    But the bigger problem is that you cannot assign a book item to multiple collections (actually you can, but you cannot order them properly):
    * Create a collection named Test1 with items A and B
    * Create an another collection named Test2 with items A and C
    * Order Test1, put A as a parent of B
    * Order Test2, put C as a parent of A
    * Now if you go back to Test1, the order is messed up.

    Itangalo’s picture

    @Coornail: Thanks for pointing out the (hopefully invalid) dependency on custom.module.

    Did you patch DraggableViews with the indicated patch? You will need that in order for the sorting to work well between collections.

    It's been a while since I looked at this. I've been thinking of changing the approach to having a field sorting in the node edit page that allows tree structures. It makes sense to keep it all on the same page, and it would make some things easier – but I haven't even started looking at how the sorting functionality for multiple-value fields work.
    One day.

    Coornail’s picture

    Don't worry about the custom.module thing, turns out I screwed up somehow...

    I did patch the DraggableViews, and I think it still does not work.

    kvantomme’s picture

    Earlier my colleague Coornail bumped into some serious limitations of the above configuration stack. We now started working on this problem again, this time as a stand-alone "outline entity" for our work on topicforge.net:

    • Users can create as many outlines as they want
    • Topics (or other nodes/entities) can be part of as many outlines as wanted
    • The outline editor uses the same drag and drop JQ magic that drives the Drupal menu system
    • A user can select an outline context that will generate a navigation system, much like the book module now generates, but with the possibility to switch outlines
    • Entities can be added to an outline through an autocomplete field
    • Entities can be added from the search interface

    It's still work in progress, but I guess we might have a working demo by the end of next week or something.

    jhodgdon’s picture

    Sounds good -- is this what Tamas was working on and demoed at DrupalCon London?

    Better yet than a working demo - can you make it a sandbox project on d.o? :)

    kvantomme’s picture

    This is a continuation of that work, but now also with book-like navigation. It's designed as an API and we are creating a first implementation for our own Topic entities (that are site specific). I'll check with the colleagues if we could put something that works with nodes into a sandbox project.

    jhodgdon’s picture

    Actually, we probably want:
    a) D6 version to work with nodes (for the community docs)
    b) D7 version to work with nodes or other entities (for the d8 help/d7 help authoring/curated docs)

    Thanks!

    jhodgdon’s picture

    Although if a D6 version is not feasible, the drive to port drupal.org to D7 has kind of started, so we could perhaps wait for the community docs to have multiple outlines until that happens. Maybe. :)

    jhodgdon’s picture

    And if the d7/entities version isn't going to be possible, please let me know that too. We are moving forward on plans for the d8 help system, and we're going to need to have something for multiple outlines that can go into core. I'm trying to get the pieces together over the next few months... Is this something you, Tamas, or someone else on your staff would be willing to take to completion, or do I need to find someone else to work on it?

    temaruk’s picture

    Some information on what we do:

    I am developing an API module that abstracts away the book-like navigation (prev/up/next, children, map/outline) from the book module, and from nodes. A provided example implementation should be using the node entity. This module would provide only the interface for navigation, the underlying data structures are up to the implementing module.

    The basic idea/assumption is that there would be a 'collection entity' and a 'content entity'. The collection would contain the content (or rather references) in a hierarchical data structure. Then the API module would either ask for an easily iterable data structure of the collection or for the 'prev/next/...' content in the context of the collection. The idea and the implementation is still very plastic, there are issues, but I already have a proof of concept. I am working on making it as general as possible, so that it could be put out at least as a sandbox project, and hopefully could give ideas to others.

    At the same time, I am working together with Tamas on topicforge.net, and the need for node entity independent book-like navigation came up there. And as Kristof said, we have an outline entity. With some changes it could be a general purpose collection entity, that allows multiple outlines/maps using different combinations of the same content. Combined with the book-like navigation API module we could have something interesting as a result.

    All of this is obviously D7.

    Do you see a potential in these ideas? Could this be something useful for the help system improvements?

    kvantomme’s picture

    I don't think we'll be building a D6 version, but we will build a D7 version, so yes you can count on our team to do so (see also comment by temaruk above). I also think the colleagues would love to adapt this for D8 core.

    Itangalo’s picture

    @temaruk: I definately think this sounds useful.

    I know there is some work going on to make the Book module allow pages to exist in multiple books – maybe your work could be of help there as well. (To me it sounds that you have built a better version of the Book module, but I don't know its internals very well.) The issue is found at #5901: Let a book page appear in multiple books. (Note the low node number!)

    jhodgdon’s picture

    #103 sounds good. One thing to consider in your work is what happens if you land on a particular page that happens to be part of several outlines - how do you display this in a way that is not too confusing to a user?

    temaruk’s picture

    An additional navigational element could be an outline switcher block (list/drop-down), showing favourite/promoted/official/personal/etc... outlines. Then there could be a block that shows if the actual page (content) is shown without context (not in an outline), also a list of outlines that this content is part of.

    kvantomme’s picture

    This is the mockup we are working towards, ideally it would be possible to add views to settings of the outline navigation system, so that the dropdown can show any type of content you can get into a views list.

    jhodgdon’s picture

    Yeah, that looks like the right direction! So at any time you would have chosen a particular collection/map/outline to navigate in, and this would be remembered (via a cookie presumably)? That sounds like a good way to go.

    kvantomme’s picture

    Right now we are using the URL to store the outline context.

    jhodgdon’s picture

    Yeah, URL query args are an even better idea. :)

    jhodgdon’s picture

    sun just alerted me to this new module, which may do all or most of what we want here:
    http://drupal.org/project/entity_tree

    Itangalo’s picture

    /me puts entity_tree on the list of modules to check out.

    kvantomme’s picture

    It seems that it could potentially be interesting to use the materialized path methodology that CHX is using. We've mostly focused on UI and interaction options, seems he has on scalability and speed. We should combine the efforts.

    Itangalo’s picture

    Report from #113: I just checked out Entity Tree, and can report that it is far from being usable right now. (I had to git clone it, since there is no release, and the .info file isn't even complete. There was quite a bit of code in the .module file, but I wouldn't trust the module until at all until it at least can be enabled.)

    Itangalo’s picture

    ...and here's another module that also seems promising but doesn't (yet) deliver: Treeable fields. It allows multiple-value fields to be sorted in tree structure, not only in order. That would be really nice to allow collections to collect content in a structured way.

    I also looked for patches at #5901: Let a book page appear in multiple books, but the issue seems to have stopped.

    jhodgdon’s picture

    Issue tags: -drupal.org documentation tools +valid issue

    Tagging so it doesn't get picked up by #1421874: [meta] Documentation Issue Queue Cleanup

    jhodgdon’s picture

    A site for making outlines on-line that looks like a good model:
    http://checkvist.com
    (not, as far as I know, a Drupal module)

    LeeHunter’s picture

    Issue summary: View changes
    Issue tags: +Usability