Friday, October 27, 2017

My Answer to the Question that Never is Dumb

I had a meeting on Wednesday with the team leads in one of the teams in my department. I showed them my structure and how their content would fit in. I was asked one very difficult question, but I answered it well.

I was asked, "Can you print all of this?" I smiled.

It's the same thing I have been hearing for the 20ish years in my career - online is fine, but I want a piece of paper. The trick with my disaster recovery documentation is that I am curating, if you will, content in various file formats into a single museum, if you will, with my RoboHelp projects.

Let me walk you through my morning ritual. After I start up my laptop, I navigate to a folder on my Desktop that has a shortcut to the folder that contains a batch file with the following commands. To run the MS DOS batch file, I double-click it:

REM | 20171027 - The purpose of this file is to get all the files in the s:\disaster recovery planning folder
REM | with these file types:
REM | *.csv
REM | *.jpg
REM | *.png
REM | *.ppt
REM | *.pptx
REM | *.pdf
REM | *.txt
REM | *.vsd
REM | *.vsdx
REM | *.vsdm
REM | *.xls
REM | *.xlsx
REM | *.zip
REM | to the local c:\rh\drm\[filetype] folder so that when I generate
REM | the DRM project, the most up-to-date files are included.
Cd\
C:
del c:\rh\drm\csv\*.* /q
del c:\rh\drm\jpg\*.* /q
del c:\rh\drm\png\*.* /q
del c:\rh\drm\ppt\*.* /q
del c:\rh\drm\pdf\*.* /q
del c:\rh\drm\txt\*.* /q
del c:\rh\drm\vsd\*.* /q
del c:\rh\drm\xls\*.* /q
del c:\rh\drm\zip\*.* /q
REM | Begin CSV Files
xcopy "s:\Disaster Recovery Planning\*.csv" /s C:\RH\drm\csv
xcopy "s:\Disaster Recovery Planning\*.jpg" /s C:\RH\drm\jpg
xcopy "s:\Disaster Recovery Planning\*.png" /s C:\RH\drm\png
xcopy "s:\Disaster Recovery Planning\*.ppt" /s C:\RH\drm\ppt
xcopy "s:\Disaster Recovery Planning\*.pptx" /s C:\RH\drm\ppt
xcopy "s:\Disaster Recovery Planning\*.pdf" /s C:\RH\drm\pdf
xcopy "s:\Disaster Recovery Planning\*.txt" /s C:\RH\drm\txt
xcopy "s:\Disaster Recovery Planning\*.vsd" /s C:\RH\drm\vsd
xcopy "s:\Disaster Recovery Planning\*.vsdx" /s C:\RH\drm\vsd
xcopy "s:\Disaster Recovery Planning\*.vsdm" /s C:\RH\drm\vsd
xcopy "s:\Disaster Recovery Planning\*.xls" /s C:\RH\drm\xls
xcopy "s:\Disaster Recovery Planning\*.xlsx" /s C:\RH\drm\xls
xcopy "s:\Disaster Recovery Planning\*.zip" /s C:\RH\drm\zip
REM | Get a List of files that start with "z_obsolete*.* so they can be deleted........
dir "c:\rh\drm\z_Obsolete*.*" >c:\rh\drm\zzzzzzzzzzzzzzz_obsolete_AllFileTypes_fp.txt

When those commands are done, I open SearchMyFiles.exe to find all of the files in these directories:

c:\rh\drm\csv, c:\rh\drm\jpg, c:\rh\drm\png, c:\rh\drm\ppt, c:\rh\drm\pdf, c:\rh\drm\txt, c:\rh\drm\vsd, c:\rh\drm\xls, c:\rh\drm\zip

Here's a screenshot of my SearchMyFiles.exe window:


When those file types have been found, I select each group of files in Searchmyfiles.exe cut the files and paste them into the appropriate sub-folder, as shown below, repeating the process of selecting, then cutting, 9 times, so that each of the 9 file types I'm working with are moved into the appropriate sub-folder in my RoboHelp projects directory structure:


When that process is complete, I open Remove Empty Directories and, with the c:\rh\drm folder specified, I click Scan Folders to find the empty folders and then, to clear out the empty directories in the c:\rh\drm folder, I click Delete Folders to delete the folders:


When that process is complete, I navigate to the c:\rh folder that contains a batch file with the following commands. To run the MS DOS batch file, I double-click it:to the C:\RH folder and run a DOS batch file with these commands:

for /d %%X in (*) do "b:\Program Files\7-Zip\7z.exe" a "%%X.zip" "%%X\" -mx=5
cd\
c:
cd c:\rh
SET Today=%Date:~10,4%_%Date:~4,2%_%Date:~7,2%
ren _root.zip %TODAY%_root.zip
ren CORS.zip %TODAY%_CORS.zip
ren CSSfiles.zip %TODAY%_CSSFILES.zip
ren CSt.zip %TODAY%_CSt.zip
ren CTSNWGroupSupportDocumentation.zip %TODAY%_CTSNWGroupSupportDocumentation.zip
ren drm.zip %TODAY%_drm.zip
ren EpicWordDocs.zip %TODAY%_EpicWordDocs.zip
ren ESC.zip %TODAY%_ESC.zip
ren import_test_files.zip %TODAY%_import_test_files.zip
ren JavaScript.zip %TODAY%_javascript.zip
ren RemoteDesktop.zip %TODAY%_RemoteDesktop.zip
ren scripts.zip %TODAY%_scripts.zip
ren Worddocs.zip %TODAY%_Worddocs.zip
rem | don't forget to change the month number in the next line every 30ish days!
cd\
s:
md "S:\Technical Documentation\_storage\2017\2017_10\%TODAY%"
move c:\rh\%TODAY%_*.zip "S:\Technical Documentation\_storage\2017\2017_10\%TODAY%"

THEN, and only THEN, do I open up my disaster recovery project in RoboHelp and resume my work.

So, back to the question about printing all of this content, here's the rub. RoboHelp is the Help Authoring Tool (HAT) I am using right now. I chose RoboHelp primarily because of its functionality to link to MS Word files and to import the following file types:


I chose RoboHelp over Madcap Flare because of I didn't want to continuously import content into the tool. I have an issue with that. The issue is that once a file is imported into Madcap Flare or RoboHelp or Doc-To-Help, the content becomes part of the project and not easily editable / maintained by anyone other than me. RoboHelp doesn't have the ability to link to other file types, though, which is the same issue that I had with Flare.

Take PDFs, for example. I'm working with PDFs that reside in the folders in the s:\disaster recovery planning folder that someone, other than me, put into that folder. Because I don't own the content within it, I didn't want to import those files into my project - there was no reason to do so. When the PDF is changed by someone else, I would have no way to know and, on top of that, I would have to repeat the import process.

That comes back to RoboHelp's ability to link to the MS Word files in the folder. So while RoboHelp's ability to link to MS Word documents works slick, for the other file types, RoboHelp holds no advantage over Madcap Flare. Thus, my solution for any non-MS Word file type has been to create HTML files for each 'area' (generic term) with links to the csv, jpg, png, ppt, pdf, txt, vsd, xls, and zip files that the team would need in a disaster situation. I have some long-term plans, which include not using the file names as the link syntax to improve user-friendliness. This is a snapshot of what I have created thus far:


Going back to Wednesday, after the meeting with that team, I happened to see the manager in the hallway. I asked how he thought the meeting went and he responded it had gone very well and he thanked me for giving his team the context for what this effort in the department involves. I brought up the idea about being able to print the content and he had a good thought about it. He said that the responsibility for making the content 'print-ready' is on his team. As we discussed it, it became clear that my role is to provide the link to their files. That means the team's files, whether they are XLS or VSD, need to be 'print-ready' so that when I link to them and they are opened, the files are ready to be printed. So, yes, in a disaster situation, there will be a way to print the content, but it's going to be dependent upon the XLS & VSD files being print-ready, which I won't control. It was a good discussion and I felt like I had another shot of 'professional vindication,' which I don't believe can ever be overdone!

No comments: