Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

50%
+0 −0
Q&A Presenting documentation for a large software product

As another answer noted, landing pages are of limited utility -- you need them, but you shouldn't assume people will start there. It sounds like your modules are all inter-related, even if one cus...

posted 7y ago by Monica Cellio‭  ·  last activity 5y ago by System‭

Answer
#3: Attribution notice added by user avatar System‭ · 2019-12-08T06:25:17Z (almost 5 years ago)
Source: https://writers.stackexchange.com/a/27872
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision by (deleted user) · 2019-12-08T06:25:17Z (almost 5 years ago)
As [another answer](https://writers.stackexchange.com/a/27869/1993) noted, landing pages are of limited utility -- you need them, but you shouldn't assume people will start there.

It sounds like your modules are all inter-related, even if one customer won't necessarily use all of them. (You mentioned linking between them, for example.) So another approach you can take is: one big HTML doc set, organized by component. This [example](https://my.vertica.com/docs/8.1.x/HTML/index.htm) was generated from Flare, and you can link to [individual](https://my.vertica.com/docs/8.1.x/HTML/index.htm#Authoring/HadoopIntegrationGuide/HadoopIntegrationGuide.htm) [modules](https://my.vertica.com/docs/8.1.x/HTML/index.htm#Authoring/ManagementConsole/UsingManagementConsole.htm) [within](https://my.vertica.com/docs/8.1.x/HTML/index.htm#Authoring/ExtendingVertica/ExtendingVertica.htm) [the](https://my.vertica.com/docs/8.1.x/HTML/index.htm#Authoring/KafkaIntegrationGuide/KafkaIntegrationGuide.htm) [set](https://my.vertica.com/docs/8.1.x/HTML/index.htm#Authoring/R-SDK/OverviewRSDK.htm) and still generate individual PDFs if you like. The benefit of the single HTML document set, as opposed to 30 different documents (HTML or otherwise), is that once you're in, you can easily see and navigate to anything else. That's a lot easier for the reader than having to go back to a landing page and choose a different module.

You might be concerned about the length of the list. How concerned you should be depends on the number of modules and how your readers access your documentation; more fits when using a browser on a full-size monitor than fits on a tablet, for instance. If you think you have too many modules to show on-screen in a single list like the TOC in the docs I linked, you have a few choices:

- Use scrolling. If you also put your most important or popular modules first, this isn't necessarily bad.

- If your modules fall into logical groups, add top-level categories to the TOC with the modules under them. As with the subtopics in the docs I linked to, expansion should be "in place" and durable. Over time much of the TOC might end up expanded and thus need scrolling, but that's ok because the user did it (and can undo it). But if your users won't be able to guess which of your few top-level topics is the right place to look, adding such groups might add more frustration than benefit.

- Support per-user customization. This won't help with people coming in from Google, but if you have user data, you can use it. If your documentation is behind a sign-in form (not a recommendation, but if you do...), you might know which modules that user is using -- so put those ones first. Or maybe you allow users to customize the view explicitly -- removing a module from the list makes it go away for that session. (Consider a "reset" link in that case so they can recover from errors.)

#1: Imported from external source by user avatar System‭ · 2017-05-02T18:38:10Z (over 7 years ago)
Original score: 1