Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

(Draft in progress below ... not completed)

Purpose

The main purpose behind this requirement is to support a good user experience with online help, with task-specific content that is delivered electronically in the context of doing tasks within Kuali software, so the user does not have to navigate separately to find relevant help content.

In order to achieve this, we need to create/support an integrate-able help information architecture that makes it easy to create, update, maintain, translate and link high-quality help content with the logic/codebase.  

Detailed Description

Give a detailed description for the enhancement. Clearly describe all concerns, eliminating ambiguities.

(This section isn't done yet, but for now, see the Requirements Listing section below.)

Usage Scenarios

Include at least one usage scenario, from the user's task perspective, that might be helpful in understanding the issue:

Mocks and Diagrams

Include any mocks (for UI enhancements) or diagrams that might be helpful in understanding the issue:

Performance

If applicable, list expectations for performance (optimal and worst cases would be fine, give time in seconds):

References

Include links to other confluence pages or external resources that might be helpful for this issue:

Requirements Listing

The below is still work in progress:

Primary:
  • #1: Create a context-sensitive help information architecture, that supports field and object-level help (e.g., tool-tips), group-level help and page-level help in a floating help window that is tightly associated with the application window and will not go behind it in the active window order, and that can be pinned, moved aside of the active window (so as not to occlude the application content), resized (so as to better fit the viewing device), and closed.  Enable applications to choose which level(s) of the help content to implement.  For example, one application might need field-level help only, while another needs field-level and group-level help, while another needs field-level and page-level help.  It is also conceivable that an application team might feel they need all three levels, though we caution against making the user feel lost in too much information.  Ideally, the user interface to the application itself should be designed in such a way that it does not require a large amount of collateral information.
  • #2:  Create an integrate-able help information architecture that makes it easy to create, update, maintain, translate and link high-quality help content with the logic/codebase
    • That is separable from the logic/code-base (related to the requirement for Centralized Message Repository).
    • That is achieved through linking field, group, and page-level help "hooks" into the logic/code-base to the appropriate anchor-points in the help  architecture.  This could be to anchor points within a single online help structure / flow, to deliver the right information from within the larger information space.  Note that this represents a step towards, but is not the same thing as, full convergence that unifies all help and electronic documentation into a single, coherent document/flow, that can also be accessed in modular, topical, fashion.   The main requirement is to support a good user experience with online help, with task-specific content that is delivered electronically in the context of doing tasks within Kuali software, so the user does not have to navigate separately to find relevant help content.
  • #3:  Support these aspects through use of open and community-source architecture and authoring tools, that support the Java space, but also support the integration/use of the output from any authoring tools that output into standard HTML source.  This includes WYSIWYG authoring capability, to be able to create and assess the effectiveness of the user experience, with the content style and presentation aspects, within the context that users will view it.
Secondary:
  • #4:  Create an online help architecture that fully converges the aspect of online help with the aspect of electronic documentation.
      
    If this is achieved, it is conceivable that all user help and user documentation could be from the same source - there would be no duplication of effort required to create, update or maintain the content.
      
    The primary requirement even in #4 is that when accessing task-oriented help (such as field-level, group-level), the potential unity with all user help information is achieved in a way that does not lead the user to become lost within a larger online documentation structure.  See the usage scenarios, and the mocks and diagrams sections above (these are coming).
      
    This type of converged overall help/documentation structure must support the following:
    • table of contents - Accordion-style expandable table of contents in left sidebar
    • help index - Alphabetical index
    • help search - Great search capability with highlighted hits
    • help glossary
    • hyper-linked cross-references within and across the help content and these constructs.
    • The information in this converged overall form must be printable, with pagination cues (page numbers printed).
    • Ability to save help topics to Favorites for infrequent tasks
    • Feedback e-mail capability

Dependencies

List any functional or technical work that must be completed before work on this item can begin:

  1. item

Issues

List any issues that need to be resolved before work on this item can begin:

Functional:
  1. item
  2. item
Technical:
  1. item
  2. item

Checkoff

Functional Analysis Complete? No (completed by SME)

Needs Review by KAI? No (completed by SME)

Technical Analysis Complete? No (completed by DM)

Needs Review by KTI? No (completed by DM)

Estimate: 30 hours (completed by DM)

Technical Design: Link Here (completed by DM)

Jira: Link Here (completed by SME)

Final Documentation: Link Here (completed by DM)

  • No labels