I couple of things here.
- Because of the way SharePoint checks in / out individual files, it is not best suited as a WebHelp output repository. WebHelp is a collections of files, each of which would require checking in / out as required. It would be a nightmare scenario.
- RoboHelp 10 only supports SharePoint 2010 - see SharePoint Integration in Adobe RoboHelp 10: An End-to-End Workflow « TechComm Central by Adobe for further details. However the workflows are better suited to resource management and source file control.
The alternative is to zip up your WebHelp and add that to SharePoint. The problem then is that the file would need unzipping before it could be viewed.
Colum, thank you. Just to clarify, when you mention "repository", do you mean it in the sense of version control, or just in the sense of a means of delivering webhelp content via the corporate intranet?
Sorry. Perhaps "directory" or "place" would have been a better choice of words. So I meant it in the sense of delivering the content. Even if you only have one topic in your help file, its WebHelp output can be hundreds of files. If you placed this output in SharePoint, they would all have to be uploaded as individual files, not as a collection of one output deliverable. What is more, no one would be able to display the help as a whole, just an individual file that was part of it.
Version control is different. This is exactly what SharePoint is designed for. It records an audit trail of each change made to a file (note the singular tense again). This is slightly different from source control though. RoboHelp 10 allows you to use SharePoint as a source control application by integrating its version control mechanism from within the RoboHelp UI. All the check ins and outs are done behind the scenes.
Hope this helps.
Right, we're OK for version control but as the Webhelp author I've been asked to explore the possibility of authoring with RH and then instead of publishing as I do now to a dedicated network server, somehow merging Webhelp with the corporate intranet, which is published using SharePoint.
From what you're saying, simply dumping Webhelp output into a SharePoint folder would not produce any useful result. From what I've read, though, a possible alternative is publishing HTML5 to SharePoint. Does that sound like a good way to go?
It depends on SharePoint security settings. If SharePoint is configured to let the browser open html files, it will work fine. You can just dump WebHelp without problems. And you don't need version control there. (Though you can check in/out an entire library through the library options.)
ASPX is a good alternative. I believe that if you choose 2010 output, it will work fine on 2013 as well.