Well, for starters it seems like we are advertising internally, and a little externally, that Google is a great way to find EMC documentation now, which does work fantastically with the current HTML ViPR and SRM documentation.  I noticed that for the latest release of VIPR Controller (2.3) a lot of the documentation has moved to PDF only and now I can barely find anything I need when I need it.  I don't even know what document to look in half of the time because the document itself is overly broad...

For example: how do I discover a Windows host and what are the requirements to make that work?   Is the answer in the "EMC ViPR Controller 2.3 Virtual Data Center Requirements and Information Guide"?  Or in the "EMC ViPR Controller 2.3 User Interface Virtual Data Center Configuration Guide"?  It turns out that the answer is mostly in Requirements Guide, but those instructions are clearly not complete because I have yet to successfully discover a Windows host with those instructions at any customer site (separate issue I know)...

In contrast, if I flip to ViPR 2.2, I can find "Add Hosts and Clusters, Windows" as a hyperlink in the root catalog and bam.. It's up..  Oh and if you search Google for that..  You get the old 2.2 or 2.0 html documentation because the 2.3 pdf docs aren't being indexed by Google. (Example: http://lmgtfy.com/?q=vipr+add+host+windows&l=1). 

I've heard from my own customers that they like the HTML docs because they are easy to navigate to find what they need.   Personally, as someone who has a lot of familiarity with ViPR, I find the PDF documents frustrating because it consistently takes me longer to find what I need.

That said, PDF versions of the docs, or a large PDF with multiple HTML docs bundled together is useful for reading offline.  The PDFs should always be indexable/searchable and need to allow for copy/paste to get text out of the doc to be truly useful.

Another thing that we should do is have a link to the documentation from within the VIPR UI and SRM UI.. ie: for whatever version of software I'm running, (eg: VIPR 2.3 or SRM 3.6, when I click documentation in the software UI, it should open a new browser window directly to the ECN Documentation index for VIPR 2.3 or SRM 3.6, respectively).

Lastly, wherever the Document Index is hosted (ie: ViPR 2.3 html index is served from http://community.emc.com) the PDF files and any other downloadable docs need to be hosted within the same realm rather than redirecting to https://developer-content.emc.com for example (ie: the VIPR Support Matrix PDF) which causes all sorts of login and SSO issues.  And customers then have to create a new account on the Developer Network (in this case) before they can then download the PDF.  Lame!

Anyway, you asked..  Moving from PDF to HTML in previous versions of SRM and VIPR docs was the right direction.  Moving away from HTML is the wrong direction.

Thanks!

Now that the documentation has moved out of powerlink/ support.emc.com it can be easier to search thanks to google being able to index it now. The search in support.emc.com still sucks.  And I am still not happy that I need to change realms between community/dev/support  .emc.com to find what I am after. Especially that the downloading document problems and salesforce loops still exist and seem to be caused by realm changes.

I do not agree that HTML docs make it easier to find what you need. I am doing fine with the PDF docs and google can index them all the same.

It is common for an older document to have a higher ranking in google because it has stronger rating which is why this stuff should remain in support.emc so that we can make use of the version selection on the left hand side when I go to a products documentation page before I search.

As soon as a new version comes out the first thing I do is download all the PDF documentation so its indexed on my local machine and searching is fast. I will then quickly review the TOCs so I can see if anything new/ important is added. These are large, complex products and its never going to be easy to find what you want without some upfront effort to understand at a high level what each document is for.

I prefer the "Portfolio" bundles. I can be assured that everything I need to know is located in those PDFs and not have to worry that some important scrap of information has been put on communities or developer. I don' like the current trend of the documentation being fragmented and spewed all over the place.

I have never used the in product HTML documentation and I hope I never will need to.

I would love to say I like both, but the html experience is poor and makes me always prefer the pdf versions. As already mentioned, the domain switching experience always gives grief. If you could make the html a more simpler single-stop landing page, with a button to easily pull down a pdf version (without all the hoop jumping), you would probably meet everyone's expectations.Currently all pages are in English, so why the intermediate step? Language could be retrieved via the user profile.

For those I ask, pdf is the version of choice - mainly because of the issues listed above and the superior offline ability using pdfs.

Hello, Rich.

Thank you for quick, and thoughtful, response to my question. Your suggestion to have a link from the software to the correct version of the Doc Index is a great one, and I have passed it on.

I would like to talk to you further about some of the customers who have commented on using HTML.  Please send me email at barbara.liberty@emc.com. 

Thanks,

-- Barbara

Hi Barbara.

I'm an EMCer - in Professional Services. I'm an SA on ASD/SDS products - especially SRM, which was the first to go down this road I believe.

When entering a html document, you always have to then select the "English" language link. I have only ever seen English, so whilst I appreciate that it is intended for future translations, I think you should miss that step and automatically detect the user's language. Once in the html page, then yes, a simple button export/save of the pdf right from there would be ideal. It should also not demand further connections - the pdf should be exported from there with the current content of the pages. It would also help if the pdf had a "date made" comment on its front page as well being marked reference only - so we have an idea of when the copy of the content was created. I have (in another life) helped with ISO document standards and when you export or print from a page of content, it should be clearly labelled as such. The html can be updated on demand, so any copies of the content (saved to pdf) should make the consumer aware that they only had a 'point in time' copy made at a certain time - it may now be out of date. On some kind of periodic basis, the entire html structure should either be exported in to a pdf set, or made available as a complete "local" copy. Offline access to the information is often required and probably the more usual method of consuming this information.

Business purposes for pdfs are easy to list, yet I find it difficult to list many for html. Navigation & indexing are the same. Perhaps the major benefit is that html content can be kept current and therefore accurate, quickly updating it based on demand. Standard issued pdfs will always lag behind.

Hi, IQ_Brent.

So, if I understand your usage scenario, you immediately download all documentation as PDF so that it is available locally for fast searching.  You want the information for reference anyway, and you utilize either the TOC's or PDF searching to find subsequent answers to questions.  You don't Google a task or business problem to find the answer in EMC documentation. Is this a correct interpretation?

I did  note your point about the need to know about and change realms to find information which, in addition to be cumbersome, can create concern that you are actually finding everything that may be relevant.

May I ask what your role (e.g., storage administrator, system administrator, etc.) is?

Thank you for sharing your experience and requirements with me.

-- Barbara

Hi, Ken,

Thanks for the prompt response.  Couple of questions for you, if you don't mind:

1.  What is "poor" about the HTML experience specifically? Is it that, because you ultimately want PDF for the purposes you describe ... and if you had a one button PDF button to get the full doc download from the HTML being viewed, you would be happier?  Or, is there more about HTML that you find missing?

2.  You described the business purpose for PDF.  Do you have one (or more) for HTML?

3.  Are you an EMC customer?

Thank you again,

Barbara

Thank you very much for sharing, Ken.  It is helpful and I appreciate it.

As far as user experience, in my opinion HTML is superior in every way.  I prefer it over PDF because I can use all my standard tools that I use for everything else to:

1. Take notes with, for example Evernote's browser plugins
2. Copy/paste commands examples into Notepad++/Atom/IntelliJ/etc without weird character encoding problems
   • PDFs are notoriously difficult to actively use in the field and require 3rd-party software beyond "just a browser"
3. Browse/search/bookmark around the docs using familiar behaviors and muscle memory
4. Avoid all the weird quirks and gotchas of PDF internal vs. external links and content