I am migrating a series of Word document to Flare with the intent of delivering the content in HTML 5 top navigation. I work in a highly regulated industry. Each Word document is a repair procedure that has a document number, a version number, and a “last updated date”. Each document is approved by three people. When a technician performs a repair procedure, the technician must fill out a report and indicate on the report the document number and version number of the procedure that was followed.
I am not sure how to handle traceability with HTML output. One option is to indicate on the footer of the HTML page the file name of the repair procedure and the last updated date of the file. In addition, I will assign a document number (or release number is perhaps a better term) and a release date to the entire HTML output. See attached screen capture of footer.
Is there something better I should be doing? Thanks. Isabelle
Best practices – traceability – HTML output
Best practices – traceability – HTML output
You do not have the required permissions to view the files attached to this post.
Re: Best practices – traceability – HTML output
Hi Isabelle –
Based on your description I’d have to think you’re on the right track.
If it is your intention to output HTML5 which is used by the technician, with the idea that the technician then continues to do as he/she currently is doing - filling out a report and indicating on the report the document number and version number of the procedure that was followed – essentially all this means is that the report references a *unique identifier*. Therefore, each one of your HTML web pages simply needs a unique identifier. That could be a combination of text and variables that you could “set-and-forget”.
For example, your footer could contain two or more system variables such as the SourceFile, ShortDate and ShortTime. While the source file should remain constant, the date and time would change automatically after each build, ensuring the combination of those three variables are unique. If you have more than one project, then the variables could be preceded by static text such as the project name. Again, ensuring that the resulting string (project name plus variables) is unique.
The technician is then expected to transcribe (as they do now) the entire string into their report.
As far as associating your topics to a source word file and revision, that is something that could be held outside of Flare, such as in a spreadsheet, because the technician doesn’t need to know that data, true?
If that data is in fact needed by the tech (the person viewing the HTML output) you could have one topic with a table in it that acts as a cross reference. You would include column provisions for word document name, revision and so on and then another column with the help topic title (and hyperlink to it of course, just for good measure)
I hope this help.
Best of luck.
Based on your description I’d have to think you’re on the right track.
If it is your intention to output HTML5 which is used by the technician, with the idea that the technician then continues to do as he/she currently is doing - filling out a report and indicating on the report the document number and version number of the procedure that was followed – essentially all this means is that the report references a *unique identifier*. Therefore, each one of your HTML web pages simply needs a unique identifier. That could be a combination of text and variables that you could “set-and-forget”.
For example, your footer could contain two or more system variables such as the SourceFile, ShortDate and ShortTime. While the source file should remain constant, the date and time would change automatically after each build, ensuring the combination of those three variables are unique. If you have more than one project, then the variables could be preceded by static text such as the project name. Again, ensuring that the resulting string (project name plus variables) is unique.
The technician is then expected to transcribe (as they do now) the entire string into their report.
As far as associating your topics to a source word file and revision, that is something that could be held outside of Flare, such as in a spreadsheet, because the technician doesn’t need to know that data, true?
If that data is in fact needed by the tech (the person viewing the HTML output) you could have one topic with a table in it that acts as a cross reference. You would include column provisions for word document name, revision and so on and then another column with the help topic title (and hyperlink to it of course, just for good measure)
I hope this help.
Best of luck.
Re: Best practices – traceability – HTML output
Thank you for confirming I'm on the right track. I had not thought of using a prefix for the project - good idea. And I will link all the variables together with hyphens to make it easier for the technician to cut and paste from the website into the service report. Thanks!
Re: Best practices – traceability – HTML output
You're very welcome, Isabelle.IFU wrote:Thank you for confirming I'm on the right track. I had not thought of using a prefix for the project - good idea. And I will link all the variables together with hyphens to make it easier for the technician to cut and paste from the website into the service report. Thanks!