Server-Based Map System for Dynamic Help Documentation

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Software product re-packaging and documentation pose significant costs and overheads, especially with the shift to component-based software and global development, and existing help systems are either too tightly or loosely coupled, making it difficult to update and maintain product information.

Innovation Solution

A server-based map system that uses identifiers to dynamically link to help pages, allowing for easy updating of file names and locations, and a document map console for visual mapping and monitoring of content access, enabling reusable and consistent context-sensitive help across different software components and environments.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If context-sensitive help systems are tightly coupled with software, then ease of access to help information is improved, but adaptability to different software components and re-packaging is worsened

Engineering Contradiction:

Improveease of access to help informationVSAvoidadaptability to different software components

Core Design Contradiction:

Ease of operationVSAdaptability or versatility

Solution Approach 1:

The help system is segmented into separate components: the software application, the help content files, and the mapping infrastructure. The map file separates the connection between software component identifiers and help content locations, allowing independent modification of each component without affecting others.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

A map file acts as an intermediary layer between the software application and the help content. This map file contains mappings between component identifiers and help file locations, enabling the system to resolve help requests dynamically without tight coupling between the application and help content.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If help systems are loosely coupled (e.g., printed books or server-based), then adaptability to different software components is improved, but ease of access to context-sensitive help is worsened

Engineering Contradiction:

Improveadaptability to different software componentsVSAvoidease of access to context-sensitive help

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The help system uses dynamic mapping through map files that can be updated without recompiling or reconfiguring the software. The mappings between component identifiers and help content locations are stored in a flexible format that allows runtime updates and modifications.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The map file serves as a flexible intermediary that enables loose coupling while maintaining ease of access. It translates component identifiers from the software into help content locations, providing both adaptability and quick access without requiring tight integration.

Inventive Principle:

Principle #24Intermediary (Mediator)

3Adaptability or versatility

If product information is updated frequently, then adaptability to changing software components is improved, but device complexity and maintenance overhead are worsened

Engineering Contradiction:

Improveability to update product informationVSAvoidcomplexity of maintaining help systems

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system uses map files as simplified copies or representations of the relationships between software components and help content. These map files can be generated automatically or manually and serve as a lightweight mechanism for managing help information without complex infrastructure.

Inventive Principle:

Principle #26Copying

Solution Approach 2:

The help system enables self-service updates through the map file mechanism. When software components change, the corresponding help mappings can be updated independently without requiring complex reconfiguration or centralized infrastructure changes.

Inventive Principle:

Principle #25Self-service

4Adaptability or versatility

If help content is customized for different software packages, then adaptability to customer requirements is improved, but manufacturing cost and overhead are worsened

Engineering Contradiction:

Improveability to re-package software productsVSAvoidcost of maintaining documentation

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The map file format and approach serve multiple functions: they work with different software components, support various help content formats, and enable both context-sensitive and general help delivery. This universal approach eliminates the need for separate documentation systems for different software packages.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system enables customization through parameter changes in the map files rather than creating entirely separate documentation systems. By modifying the mappings between component identifiers and help content locations, different software packages can be supported with the same base help content infrastructure.

Inventive Principle:

Principle #35Parameter changes

Data Source

PatentUS8230043B2Documentation process for invoking help from a server

Publication Date: 2012.07.24 ORACLE INT CORP

AI summary

The use of a map at a server allows flexibility to the operation of a help system.