Browse Prior Art Database

Comparison tool - Application Screen with Documentation

IP.com Disclosure Number: IPCOM000238433D
Publication Date: 2014-Aug-26
Document File: 2 page(s) / 49K

Publishing Venue

The IP.com Prior Art Database

Abstract

A synchronyzing tool to bring product documentation inline with that of the development UI screens.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

Comparison tool - Application Screen with Documentation
The information developers are constantly having issues synchronizing the application / product screen with that of the documentation. In case of a huge product, there are loads of screens each in turn varying in complexity. Every small change in the UI is not communicated to the information development team. The information developers must manually open the latest build and compare every time, which may not be feasible considering timeline and resource constraints. When the development teams are distributed across different geographies and time zones, this task becomes even more time consuming and cumbersome. If there is a lapse in this task, the document description of UI controls will not match the actual screen and the end customers get impacted. It also spoils the reputation of the company and increases product PMRs. There will be more feedback / comments and the L2 customer support team must work extra hours fixing problems.

The solution to this challenge is to develop a tool that will synchronize the product documentation with that of development UI screens.

It can be applied to any XML based authoring, however, I have used DITA throughout this publication to explain the operations of the tool.

The tool will compare the document source files (dita, ditamap format), checked into the repository management / configuration management tools (for example, IDCMS filenet, CMVC), with that of the build UI properties file. After comparing the two, it will display the list of discrepancies.

The tool high level steps involved in performing this operation are as follows:

1. Open the DITA file (or any XML markup authoring language) and pull out UI related markup or tag items. DITA will be filled with different kinds of markups. Examples of dita markups:

,

                             . We can keep a record of the template blueprint inside XLS or db record, that is, information on what markup is used for which UI control element. We can update the template from time to time.

2. Open the latest build of the development from the server location.

3. Consider all the UI related tags pulled out from the DITA file and individually run a scan across the build properties file.

4. If the word within a UI tag does not exist in the properties file, then pull out close matches from the properties file and display them in the tool.

5. The user can select a suggestion and click Replace. It must pull out all tags of the same word and replace with the value suggested by the user.

6. If Replace All is selected, the tool must run through all the DITA files within that folder individually, search fo...