I see some flaws with that.
Dev files need to always be local. Placing on a network share for the purposes of using RoboHelp to compile or generate is risky business and may explode in your face. LMS to me means Learning Management System. Those are typically used for eLearning. RoboHelp does help systems. Captivate does eLearning. So you are losing me with your LMS reference.
When ready to review with the customer, the would use the registration tool to push the project to preview.
I'm lost. What "registration tool" are you even referring to here? Or is this what you are planning on creating and that's what you are choosing to call it?
The app would call the RH command prompt using a server side technology, in my case .NET, and supply the necessary arguments and push the generated project to preview.
There is no "preview" of projects. Preview of individual topics, sure. But not for a project. There is only compile or generate to create the final output.
Once it had been reviewed and ready, then the user could push to production.
Sounds like what one might typically accomplish using RoboHelp in a typical development cycle. You edit content on the local hard drive. If a review is needed, you compile or generate the content and place the output on a server. After approval is complete the content is then copied to the production server.
Sure sounds like you are attempting to reinvent the wheel in many situations here.
Helpful and Handy Links
Thanks for the quick replay Captiv8r!
I apologize for not being more concise. For the sake of argument, lets say I have the following assumptions:
- 100k plus users (content viewers)
- 7 server environment (1 - dev with daily backups, 2 preview and 3 production loadbalanced servers)
- Issues with knowledge management - orphaned help topics and RoboHelp projects, etc...
- Lack of reporting capabilities
- Lack of evaluation capabilities - comments and ratings
- No "email to friend" feature
- RoboHelp developers
- use local machines, but when finished or need to collaborate store files on the dev server - understand you concern, but with daily backups for finished projects, we don't really have to worry too much.
- Are not technical - can develop content, but can't write scripts to include in their projects. However, they can function within the IDE and include scripts written by others.
What I'm trying to decide is whether or not to build an application that can mitigate the above problems within the above contraints and resources.
My idea is to create an EPSS (Electronic Performance Support System/Solution), not an LMS - sorry poor use of the term. Also the term "registration tool" is just a generic term to indicate the purpose - to capture meta data associated with the RoboHelp project and register it in a database.
The flow would be as follows:
- Developer does the preliminaries - analysis, documenting structure, help topic names, etc...
- Developer registers meta data associated with knowledge management - i.e. developers name, project information, various keystakeholders, description, dates, whether to include other features when published like comments, ratings, etc...
- App registers the data in the database, creates a folder on the development server with the appropriate permissions and emails the developer with the development directory they're to store the content when ready.
- Once the developer and stakeholders reconcile the developer will go back to the tool and indicate it is ready for production and push it on through.
Hopefully it is more clear. Do you see any value in it considering the above assumptions?
Thanks again for you comments.