1. Background
We would like to combine existing User guide and Admin guide currently in PDF form into a single HTML master site
This master HTML site will support filtering content on two dimensions:
Role of the user (currently product support Administrator, Data Analyst, Data Engineer, Data Steward and Data Catalog Manager roles)
Product Type (as a part of upcoming release, we are splitting product into two products: Unifi Data Catalog and Unifi Data Platform
We launch a new release every 6 week. Thus while new master HTML site is getting built, you will have to also work on including documentation for new releases in this master HTML site.

2. Questions to Answer
Proposed Tools/ Architectures for migrating PDF docs to HTML for the first time
Proposed Architecture for making changes for the future/ongoing  releases
Architecture for filtering master content based on role and product type
Tentative Project plan / Timeline for project
(Please note that based on the architecture/tools used, the Product UI engineers and/or our Website agency can help for implementing filter logic).

3. Questions to Answer
Proposed Tools/ Architectures for migrating PDF docs to HTML for the first time
Proposed Architecture for making changes for the future/ongoing  releases
Architecture for filtering master content based on role and product type
Tentative Project plan / Timeline for project
(Please note that based on the architecture/tools used, the Product UI engineers and/or our Website agency can help for implementing filter logic).

4. Tools MadCap Flare for website development
Output possibilities from one source file
Online: HTML5, Clean XHTML, Eclipse Help, WebHelp Plus
Print: PDF, XPS, Adobe FrameMaker, Microsoft Word
Mobile: Responsive HTML5, ePub, Webhelp Mobile
Desktop: HTML Help, Dotnet Help, DITA, Webhelp Air
It plays well with others (uses CSS and XML)
If you want to change the look of the site, you can do it all at once across all documents in the project. Templates, header definition, body definition, etc.
The possibility of easy localization (translators prefer Flare)
Searching through discussions online, I find that MadCap Flare is preferred by other technical writers for website development.

5. Tools Snagit-for screen capture and editing
This is by far the most feature-rich and time saving tool for screen captures, and the only one that also edits on the fly
Microsoft Word-for conversion from Google Docs to MadCap Flare
I suspect this is the easiest way to do it
Local backup software if you don’t have it already. (Web based and local.) For web-based I prefer CrashPlan.
The only copy should never be only on my computer
Maybe a different hosting service for subdomain
If they do not offer what we need for password protected access, password generation and ing client. Also client control over password generation within their account access.

6. Filtering Two tiers Product type Role
The product type can be a password protected section of the site that they are given access to once they pay for the product. This can be generated and sent to them by , allowing them to change their password and other important information. We give them this.
The roll, if you want each roll to have its own protected section, will require the client to have the ability to create protected sections.
These roll username/password combinations could be sent out when the client purchases the product
The client could be given the ability to create their own username/password combinations for their employees-likely more coding involved.
There may be other pre-packaged solutions through the cPanel or other scripts or server side programs already created.

7. Tools
Option #2
The User Guide could be incorporated into context specific help documentation. It could be online or packaged in the program.
Whatever page of the service someone is using, there will be a help link specific to that page. This is very user friendly for those getting to know the system.
It saves a lot on technical support calls. Even for those who call, the service representative can have them click on the help file right there and lead them through to a solution.

8. Timeline (95+86=181 pages)
Coming up to speed with MadCap Flare (I have a beginner’s knowledge)-Weeks to start to get used to all the most useful functions.
Getting used to the hosting situation (Days or weeks)
How much will I be involved on the backend? This will affect the timeline.
Getting to know the products more. Reading the docs will help and working with the platform personally. (Weeks, but much will be done while working on the rest)
Importing into MadCap Flare (if that is our solution)-Quick-Hours
Deciding on look and formatting options. Do we have anyone who specializes in graphics? Weeks, but it will be interspersed with other writing and formatting. Add three weeks.
Breaking the larger documents into smaller docs and creating a tree structure. Add three weeks.

9. Timeline
Deciding on and implementing a navigation method (top menu, sidebar, breakcrumbs, combination)-A month
Linking everything together
Redoing screenshots so they are in a higher definition. There are a lot of screenshots. Three weeks
Reading piece by peace and revising as needed. This could be time consuming, but worth it. Three months, but much if it will be done while doing other parts.
At times getting clarification from SME’s about a feature. Add one week.
Meetings to attend, docs to update every six weeks. Two weeks.

10. Timeline My guess = 8 months
With a review process in place (SME’s, legal, etc.)
= 9 or 10 months

11. Note: Version Control Matters
This means each time a major update is made, the project is saved with a different name. There should be a document with this information which is always being updated by me. Older versions are always saved.
Date
Version
Author(s)
Notes
12/16/2016
0.1
Joe Rodriguez
First draft
05/08/2017
1.0
Initial release
08/10/2017
1.1
Updated specs for new release