Our developer team customized the API for our needs. We wanted the FM content to be transformed to XML, and viewable as both HTML and PDF.
The L0 headings were our left navigation “category” and each L1 or L2New Topic was a standalone HTML page.
SOLR is an open-source Java search server. Solr is for indexing text. Because our database contains documents with lots of unstructured text (not fields/columns), it speeds up search. SOLR fully indexes all the HTML content (and PDFs) on our sub-domain to make it searchable. It allows you to programmatic retrieve data quickly with the same speed as something on the first page or something off page 900,050.
Marketing used the SOLR for searchability in their Resource Center. And Support integrated it with Salesforce so that Support engineers couls have our content at their fingertips.
We could only use png images.
content and portal strategy resulted in findability Top-level organization: https://www.paloaltonetworks.com/documentation
WHY A NEW DOCUMENTATION STRATEGY?
• In FY2012 there were 6,948 calls to support for help configuring the product.
• Customers and partners report that they are unable to find the content that
they need and, often, if they do find the content, it is for the wrong OS
• There is a large amount of documentation produced by various groups
throughout Palo Alto Networks, but it is difficult to find what exists and harder
yet to keep it up-to-date. There is also a lot of duplicate content because
employees have no visibility into what already exists.
• We do not have all of the content expected of an Enterprise-level company.
Page 4 |
TOP PROBLEMS WE IDENTIFIED
Top Problems with Existing Strategy
Customers do not know where or what type of document—admin guide, tech note, knowledge point
article—to look in to find the content they need. Often the complete information they need to solve a
problem or perform a task is stored in multiple locations and documents.
Customers are unable to figure out how to configure our products and end up calling support.
Content is not easily searchable by product or version.
Customers don’t always know what they need to search for and our documentation does not provide the
context or navigational mechanisms to help them pick up the “scent” of the information they are looking for.
Content can be contributed by any internal user, but isn’t maintained or translated.
Customers are not able to find quick answers to the questions they have when trying to perform a task or
troubleshoot a problem.
Not all users like content in the same format. Users who are used to the “Google” model want to be able to
search for content within a web-based system. Other users prefer to be able to take content offline, either as
a printed document or a PDF, and read it as a unit.
Official documentation for all products was in a single admin guide and only provided information on the
fields available on each screen, not on the tasks users need to perform to do their jobs.
CONCLUSIONS FROM ANALYSIS OF PROBLEMS
We had two high-priority problems to solve:
Page 7 |
Top Problems Solution
Accessibility/Findability Create a centralized doc portal with
dynamic linking to other content.
Content Quality Transition to topic-based content
architecture and write, write, write.
• Option 1: Traditional Web Help—Use an off-the-shelf help authoring tool to
create single source documentation in various outputs and host it on a site
that is accessible from the support and/or www.paloaltonetworks.com site.
• Option 2: Integrated Web Help—Use an off-the-shelf help authoring tool to
compile a linked help system that is then integrated into the support site using
the Jive API.
• Option 3: Company-Wide Content Management and Publishing Solution—
Use of a CMS to author and store, all content authored company-wide and
publish to various channels.
Page 13 |
Solution Requirements Web
Users should not have to look on multiple sites for content.
Employees should be able to see what information exists.
Customers should have content that helps them understand how to
configure our products without calling support.
Content must be easily searchable by product or version.
Content can be contributed by any internal user.
Collaborative review of content (including translated).
Content must dynamically link to content in other channels.
Content must be searchable from the KnowledgeBase (Jive).
Content must be searchable from www.paloaltonetworks.com.
We must be able to update in one place, publish in many.
We require multiple output formats from single set of source files.
DRIVERS FOR CONTENT STRATEGY
• Problem statement evaluation dictated a move to task-based content.
• CQ5 not ideal for authoring large amounts of content.
• Very small team to manage portal development and write all new content.
• We needed to deliver LOTS of content while the portal was being developed.
• Decision: Continue to write in FrameMaker and develop a custom
FrameMaker to CQ5 API that would map our FrameMaker paragraph,
character, and table styles to CSS.
Page 20 |
• Hybrid content model: Content would flow-like a book, but individual topics
would stand alone.
• Think of content in categories, not chapters.
• Topics defined by head levels (Chapter heads, L1 heads, optional at L2).
• Focus on complete workflows instead of discrete tasks.
• Facet-driven: We would tag topics to reveal relationships within content
authored in a book construct and allow users to narrow to find what they need.
• SEO optimized.
• Prioritize based on customer need (SalesForce data).
Page 21 |