Re: Linking Between and Among Merged Responsive HTML5 Projects:
I am outputting to Responsive HTML5.
I need to:
1) Create a Master Project and Child Projects, and;
2) Create links between Child Projects under a single Master, or;
3) Create links from Child Projects to topics that reside natively in a Master Project
I have to build an (effectively infinite) online resource manual for a government division.
I'm at the beginning of this, building the master architecture.
There will be a great number of child projects, but they will need to point to (link to) certain pieces of information that they have in common across the board, such as:
a) Screenshots of a computer system used by gov workers
b) Descriptions of various pieces of legislation, etc
c) Code tables that workers have to refer to
d) Other "appendix"-type things
e) Descriptions of various gov-issued mailings, etc.
f) Variables and snippets and modular, reusable content that must be globally used or applied across the entire Master Project
So it may be that some of the things in the list above -- if I cannot link from child to child in a merged responsive html5 environment -- would better be included in a Master Project itself...in other words, linking from Child Project to topics in Master Project...but it seems common wisdom advises that a Master Project should be an empty shell, i.e. just a table of contents containing child projects.
What I've seen in the forum so far regarding linking between and among merged projects refers to chm files, which so far as I know so far, does not pertain to merged responsive html5 projects.
My understanding of the concept and sequencing of merged responsive html5 so far is this:
1) Create Master Project, with Child Projects (placeholders) in TOC
2) Generate/Publish the Master Project
2) This will create empty folders (i.e. vessels) for the child projects
3) Child projects must be generated directly and individually (i.e. poured into) those vessels, one by one
(It seems to me so far, at least, that I therefore cannot really merge source files, but rather in effect only merge output/product files...)
This is where I get tripped up, because of course I want to link from source files to source files, not source to output/product files, and I want to keep my paths relative, because I will initially have to publish to a "development" intranet address for SME review etc, and only later when everything is finalized, publish again to a "final" intranet address -- though I will incrementally and iteratively be publishing more and more child projects into more and more vessels added to the master project.
In my researching of merged projects so far, I see references to chm files (which don't seem to pertain to merged responsive html5) and also to linking to "remote topics," which also don't seem to pertain to merged responsive html5.
Any help toward a macro understanding of this is appreciated. Is it even possible for me, using merged responsive html5, to link between and among child projects under a single master -- or from child projects to topics contained natively in a master?
Thanks very much,
p.s. sorry for the verbosity!
Have a look at Peter Grainge's guide to merging webhelp - the initial setup is key. I basically have this setup for Multiscreen HTML5. I haven't tried with Responsive HTML5, but I believe it should work on the same principles.
Definitely download the demo projects and have a play, as the simple environment really helps get your head around how everything hangs together.
First I hope you will take a look at my instructions as that explains why not to have any content in the parent. Quite simply, links between parent and child will break in the output.
Second, you are right that it is a means of merging outputs rather than sharing content across multiple projects. For that you need to use the Resource Manager. That enables you to store content in a way that multiple projects can access. If you change the item anywhere, you get a warning that it is out of sync alerting you to the need to update all the projects that use it. You then regenerate and rebpublish those projects. Be aware the Resource Manager does not record where something is used so you need to either keep a record or update everything.
See www.grainge.org for RoboHelp and Authoring information
Thank you very much. I am just starting out with Robohelp, and am learning it on-the-job and on my own while under time pressures to produce product.
I was unaware of the Resource Manager until you told me. It is invaluable information.
I've been reading about it since receiving your reply. It looks like a powerful feature that is essential to the needs of my project(s).
Meaning, are the features, capabilities, and procedures generally cumulative from release to release -- or do I need to be careful when reading info about past releases and applying those procedures to the RH 2015 application?
I'm at the beginning (about three-four months in) of a massive and complex project that will include a lot of content re-use, so I need to exploit the full power and functionality of the RoboHelp application. At work, I am a one-man department. There is no one else who knows anything about this program, nor anyone who knows or wants to hear about issues involved in designing and delivering the product.
I know that getting the fundamentals of the underlying file structure right is critical (even without concerns and best practices about RoboHelp in particular), especially in view of trying to build my project(s) (and perhaps my department) as a scalable machine -- trying to future-proof the product to the extent possible, allow for future updates and releases, etc. (Additionally, I'm in a complicated IT environment, in a gov office, which involves lots of security, firewalls, secure intranets, etc.)
I ran into issues when I had been keeping some of my source files on a network drive. I have since moved everything to my local hard drive.
It seems that for optimal results, I should keep everything on my local hard drive. This includes Resource Manager shared files; I will keep them all on my hard drive.
I will generate my final output to a folder on my hard drive, copy it to a flash drive, and deliver it to the customer for uploading to the server/intranet.
I think the only book is Kevin Siegel's on his site at Iconlogic.com.
My site, Rick Stone's www.robowizard.com site and Willam van Weelden's www.wvanweelden.eu and www.helpessentials.com are all sources of information.
The procedures for creating merged help are much the same across for webhelp and HTML5 help. As to other similarities across versions, it varies. What you will find different is references to how to do something will change at RoboHelp 2015 because a ribbon was introduced. Also along the way, dialogs get changed. It's something you will have to muddle through.
Rick Stone also does online training so you might like to contact him on that.
See www.grainge.org for RoboHelp and Authoring information
Thank you. I will read that.
Am I to understand that, generally, procedures regarding WebHelp apply to Responsive HTML5 as well?
With regard to "Web Help" and "HTML5", in Robohelp terms WebHelp refers to a specific output that is different from HTML5 output. Broadly speaking they function similarly and have similar features, but not all capabilities in webhelp are available in Responsive HTML5 and vice versa. (And Multiscreen HTML5 is different again).
So if you read about something in webhelp it may not be available in HTML5.
For example, in RH11, webhelp has dynamic user-centric content, whereas Responsive HTML5 does not. (However, I believe similar functionality was added to Responsive HTML5 in RH2015.)