You are here

Use Case Example: User-provided Feedback on the CyberGIS Gateway

About you


Name

Michalis Avraam

Overview

Title

User-provided Feedback on CyberGIS Gateway

Description

This Use Case provides a structure about how CyberGIS users (of any access level) can provide feedback about elements accessible to them in the gateway.

Initial Status

Actors

  1. Any user of the CyberGIS Gateway.
  2. Administrator(s) of elements accessible through the gateway.
  3. Gateway administrator(s).

Interfaces

There are 2 user interfaces needed:

  1. Public Access Interface (two components):
    1. Data input provided through the use of HTML (textbox) on Gateway – Public Access.
    2. Presentation of user-submitted content through HTML on Gateway – Public or Restricted Access.
  2. Administrative interface encompassing interfaces 1.a and 1.b, with additional functionality for editing and deleting feedback and setting preferences, using HTML – Private Access only.

JavaScript libraries provide the software interfaces – the functionality is offered by the PGIST code, hosted at the University of Washington. The following functions are needed:

  1. createConcern(Long bctId, String concern, String[] tags) : Provides the ability to create a concern and associated tags/keywords on a specific instance of the tool (BCT).
  2. save(Concern concern) : Provides saving functionality for a concern.
  3. getMyConcerns(BCT bct) : Provides current user’s concerns.
  4. getOthersConcerns(BCT bct, int count) : Provides (count) concerns by other users.
  5. Remaining 8+ functions available in BCTService.java

Preconditions

  1. An element of CyberGIS is accessible to any users.
  2. Element administrator(s) enable feedback by users.

Basic Flow

Step-by-step Workflow

  1. Public Access Workflow
    1. User is accessing any element of the CyberGIS Gateway.
    2. A button provides the user with an expanding view at the bottom of the element presentation (complete interface 1).
    3. User has the ability to view previously submitted feedback.
    4. User composes feedback in dedicated textbox provided by the interface.
    5. User submits feedback to the feedback mechanism, which acts according to the element’s administrator’s settings.
  2. Private Access Workflow
    1. Element administrator defines feedback preferences for their element.
    2. Administrator reviews provided feedback, and chooses to:
      1. Accept (enables public viewing).
      2. Reject (remains private).
    3. Administrator replies to feedback, either in private (message) or public (feedback).

Post Conditions

Possible states at the end of use case

  1. Public Access Workflow
    1. User provides feedback to element administrator(s).
    2. User possibly receives reply from element administrator(s).
    3. Element possibly has attached publicly viewable feedback if approved by element administrator(s).
  2. Private Access Workflow
    1. Administrator(s) receive feedback by user(s).
    2. Administrator(s) moderate feedback.
    3. Administrators reply to user-submitted feedback as appropriate.