Users and User Stories
We would like to support different users with clear paths to follow in finding what they need in the CDAP documentation.
...
It's possible that certain users may fall into more than one category. For example, a User may want to install CDAP themselves, in a Standalone setting, as part of a review process, in order to evaluate its appropriateness for their situation before passing it to an Administrator/Operator for adding it to a cluster.
Different Paths
We can identify paths either by user or by theme, where the themes would be the interests listed above.
...
Of these different approaches, we currently employ all of these, and can suggest resources as the user advances in proficiency.
Two examples of this are the Python Documentation page and the Python Comprehensive Help page.
Another example is the documentation for the Django Project. It shows "The basics" and "Advanced" links for each thematic area.
Introduction Pages
Each manual and manual—and the Documentation itself has itself—has an "Introduction" page at the start.
Currently
...
These pages are a list of links with descriptions and important terms or phrases marked in bold:
Proposal
...
Have a tabbed panel that shows for different users user streams appropriate content (note: the content would not be a literal, ; that is a limitation of the current custom Sphinx extension used to illustrate this):
See http://builds.cask.co/artifact/CDAP-DQB31/shared/build-1/Docs-HTML/3.5.0-SNAPSHOT/en/index.html for an example of this.
- These tabbed panels could be used at the start of each Introduction.
- As with our existing
tabbed-parsed-literals, they would be synchronized, so that all would show the same tab, but with different content, in each area. - For each panel or "user stream" we could suggest a series of "The basics" and "Advanced" links.
- One panel could be a complete index, similar to what we have currently.
Other Ideas
Here are additional ideas that can be employed to help users find appropriate material:
- We list at the end of each Building Block page the examples that pertain to that building block; for example, Service Examples.
- We need to check that this list is up-to-date; and an easy way to help this is modify the Examples page to indicate for each example which building blocks it illustrates.
For example, we describe each example ("A variation of the WordCount example that operates on files. It demonstrates the usage of the FileSet dataset, including a service to upload and download files, and a MapReduce that operates over these files."), but this is too long and may be incomplete. A quick-to-read column with abbreviations might be better: all examples that demonstrate usage of a Stream or a MapReduce could be indicated by an "S" or "MR" in a column. - Each Building Block example section should have a link to the examples page.
- The availability of Training resources from Cask should be mentioned in the docs as a potential resource.
- Like the Django Project, we could have a section titled "How the documentation is organized" that explains how we intend people to navigate and use the docs. People might not read it, but it can help…