Voting starts in March for the Drupal Association Board election.
This is part of. Original statement: "In the process of making docs clearer they are community-maintained, we decided we should have some kind of new navigation (maybe)."
Contents of this issue
This issue concerns improving the features d.o offers to users (and maintainers) to discover, explore and move among the documentation pages. These existing and proposed features include:
- Doc page nav: The navigation features on individual pages. Currently a list of child pages within the content body, and an abbreviated non-interactive tree in the right column.
- Search: d.o's search, and google/bing etc
- Tags, tag search
- Doc map: Stand-alone page with complete table-of-contents tree (not currently implemented)
The overall set of "navigation" features should support the following activities, and make them faster, easier, and/or more possible than they are now:
- Find documentation again that you have seen before
- "Find documentation on a topic": This could be supported through search (both on-site, and google etc) and navigating through the book outlines.
- Find a place to put information: If you have some information that you want to get into the documentation, you need to find where it should go (on an existing page, or as a child of an existing page). This is similar to finding information on a particular topic, but not necessarily the same, since presumably you are talking about a more experienced user who has read the docs before. They still would either use search or hierarchy navigation to find the docs they have seen before.
- "Understand and explore the conceptual and documentation landscape":. (Loosely: "Browsing") Provide the user the ability to comprehend the broad expanse of all topics, and the scope and organization of the documentation that covers those topics. Allow the user to progressively reveal finer-level concepts, while, to the extent possible, retaining in view the larger context. Beyond ordinary readers, doc maintainers need the same facility to be able assess and maintain the documentation structure.
- If the complete doc landscape is too large or slow to present on each individual doc page, then some additional "doc map" page(s) could be provided to serve this purpose.
- For each doc page: "Where am I?", "Go nearby" and "continue reading": From each doc page, allow the user to know where they are, and to proceed incrementally through the docs to conceptually nearby or sequential pages:
- Show location within hierarchy (links to ancestors)
- Links to subsidiary pages that explain more details.
- Links to broader pages that put the current page into context.
- Links to preceding pages that introduce topics used on the current page
- Links to succeeding pages that follow on from the current page
- "Find related pages, elsewhere in the hierarchy" . Suggest pages covering related topics
- Could be implemented via specific links in the content (as now)
- Could use keyword tags [which we have, but pages are not widely tagged with keywords]
- Visual design: Amount of space used on page
- Obviousness without explanation
- How much clicking and scrolling required
- Accessibility: people with vision/mobility limitations must also be able to use the navigation
- Bandwidth required
- Computation required in client browser
- Implementation difficulty level (and likelihood)
Candidate alternatives and examples
Most of the suggestions to date are for alternative navigation widgets for doc pages. These are all listed below, with screenshots. In general, these alternatives vary along a number of dimensions:
- Choice of how many pages are shown, and which ones.
- Interactivity (expand/collapse)
- Browsability (Does widget show all pages?)
- Scalability (Even if a mock-up is attractive, can it handle a collection the size of d.o docs?)
- Use of space on the page
- Implementation effort required
Table of alternatives and their characteristics
Current drupal.org docs navigation
Displays a dropdown list of page titles, using dotted numbers (like 3.5.2) to indicate hierarchy. Displays the entire hierarchy of this site (169 pages) -- not so practical for 8000 pages. In addition, this navigator is supplemented by a link to a doc containing the entire site as a single document (~400k).
- References: #112
- Jakon Nielsen: Mega Drop-Down Navigation Menus Work Well
- Main innovation is to display "large number" (say, a few dozen) of items using multiple columns, or at least spread out in 2D on the menu surface.
- Not clear how this applies to displaying doc page navigation
"Tidy collapsed menu"
References: #32, #96, #120:
Live example at open atrium docs: https://community.openatrium.com/documentation-en/
Hybrid between list and tree. Initially displays list of top-level items. Clicking on an item's [+] will hide the other items at that level, change the single selected item into a "header", and reveal its children. User can continue to drill down by clicking on the children's [+], or zoom out by clicking on any level of header. (Bug/inconsistency: clicking on the lowest header actually navigates the browser to the associated hyperlink, instead of collapsing the tree.) Browsability note: Because only one list of siblings appears at a time, user loses most of
existing context on each click.
Scrolling list box
"How about a scrolling list box (like a multiple-select box) with a "Go" button for navigation? It could have just a few elements in it, and wouldn't drop down." Not specified in author's proposal which pages to display in the listbox, or whether any hierarchy would be shown. Need more detail.
MSDN gives three different options for navigation, which can be selected via the "options" (gear icon) menu.
- Lightweight: Displays a non-interactive "outline" view of the contents, which displays only the current page's ancestors and children. No siblings of the current page, nor siblings of ancestors.
- ScriptFree: Displays a column divided vertically into three areas:
- List of ancestors
- List of children
- List of peers
Expandable tree able to show the entire hierarchy of MSDN docs. Clicked branches retrieve data for children via Ajax.
Displays a non-interactive "outline" view of the contents, which displays only the current page's ancestors and children. No siblings of the current page, nor siblings of ancestors.
Displays a column divided vertically into three areas:
- List of ancestors
- List of children
- List of peers
#117 probably refers to the Lightweight mode of MSDN, and is mocked up as a drupal version in the screenshot below, though this mockup actually includes siblings of the current page's great-great-grandparents (children of the book's top level), which MSDN-Lightweight does not.
Stand-alone Documentation Map page
This proposal envisions a separate page which presents an expandable/collapsible tree of the complete documentation hierarchy. The main aim of this complete is to provide the support for "Understand and explore the conceptual and documentation landscape".
By being a separate page, it can afford the bandwidth and delay entailed by the large amount of data required for the whole tree. In concept, this is very similar to MSDN-Classic's tree.
Prototypes, using actual d.o data:http://grahamwideman.wikispaces.com/Drupal+docs+by+book
#120 This does not attempt to support any of the objectives listed in the requirements, but does fully satisfy the constraints on space, performance and implementation
So far, we have reached consensus that we would like to adopt a "MSDN Classic" navigation. This should help with several of the uses above (finding information by navigating through the hierarchy, and understanding the landscape). There's now a separate issue for figuring this out:
Still to be resolved: Can we also do something to help with:
- find related information in other places
- understand the overall picture