Skip to end of metadata
Go to start of metadata

Purpose

User can go backward/forward through their task progression using the standard browser back and forward buttons.

Detailed Description

  • User can go backward/forward through their task progression. 
  • Not required that view-only forms (lookups, inquiries, etc.) are stored in memory to support this.  Is OK to store just the call to these instances, to be able to re-call.
  • Required that edit-capable forms that have new user data entered (but not yet saved) be stored in memory (or the choices/data the user entered be stored in a plug-in or other construct and repopulated when the form is brought back up) so that the user can go back/forward to it, not losing the data/selections they've already made.
    • Field and field group states (input field content and checkbox states, etc.)
    • column sort states
    • facets chosen
    • filters chosen
    • lightbox states
    • help window states
    • progressive disclosure states
    • expand/collapse states
    • tab states 
    • (not tooltip states)
    • (not keyboard focus/mouse hover states)
  • OK for there to be a finite # of back-tracks that are stored (typical in browser settings).
    • OK to remove from memory when # exceeded, in first in/first out order.
    • Prior to removing a form (or js store of content for a form) that has user data / selections, issue message that form will be deleted in x minutes unless you re-enter it or increase the limit on # of forms that can be stored).

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

See also KAI Review - 4-12-2012.

Requirements Listing

List all requirements (individual verifiable statements) that indicate whether the work for this item has been complete. If there are requirements that are not essential to the functionality but would be nice to have if time allows, enter those under 'Secondary':

Primary:
  1. KS Developer quote: “Need an OnLeaveEvent that we can use to tack on some js functions that user has enacted so that it can be captured in the browser’s history and viewed with a backbutton view.”
  2. For pages that have user selections and data entered:  KS Developer quote:  “Preserve facet and pagination choices - solution could be as simple as having a jQuery plugin that stores choices and reapplies those choices":
    • Field and field group states (input field content and checkbox states, etc.)
    • column sort states
    • facets chosen
    • filters chosen
    • lightbox states
    • help window states
    • progressive disclosure states
    • expand/collapse states
    • tab states 
    • (not tooltip states)
    • (not keyboard focus/mouse hover states)
  3. Not required that view-only forms (lookups, inquiries, etc.) are stored in memory to support this.  Is OK to store just the call to these instances, to be able to re-call them from the server (with fresh/current data).
  4. OK for there to be a finite # of back-tracks that are stored (typical in browser settings). 
  5. If applications will have to do custom work in order to support the back button (rather than just inherit it from KRAD), enable applications to set the # of back-tracks to zero. 
Secondary:
  1. item
  2. item

Dependencies

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

  1. Note:  This is for a later milestone or Rice release, but the requirements are pulled together now as these have implications for the 2.2 milestone 1 work on performance improvements.

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

QA or Regression Testing Plan

List steps needed to test the basic functionality of this update, enhancement, bug fix

  1. test/steps
  2. test/steps

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)

Added to QA: No (completed by SME)

  • No labels