Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overview of design: read-only / editable databases and activities #7

Open
tmillross opened this issue Apr 25, 2018 · 2 comments
Open

Comments

@tmillross
Copy link

tmillross commented Apr 25, 2018

This is a brief description of the design plan for distinguishing when the interface is read-only and when edits can be made by the user to particular activity-related fields. Design adheres to to #6 and addresses ideas on "separation between data exploration and editing" raised here. The more detailed behaviour in psudocode is described in subsequent issues.

  1. Two layers of protection from accidental user data edits: at the [project&]database level, and the activity level
    a. When database is set to editable, the user then has the ability to set a specific activity to editable
    b. Once activity is editable, user interface data modifications are synced with the activity database (usually JSON file) in real time: the state of the interface is always consistent with the data state in memory or on disk
    c. Thus, there is no “save” button required (or associated extra user click-action)
  2. A user may still make a change to a field accidentally once the fields are editable
    a. Under this circumstance, they can identify that this change has been made
    b. And ideally be able to undo/revert the change, either automatically or manually

Behaviour as experienced by user:

  1. In database list, a checkbox in column “Read Only” is visible, default = checked
    a.The rows are colour-coded OR show a padlock icon, which is unlocked or locked.
  2. When read-only, no changes can be made to any data within that database. This includes:
    a. Editing existing activities
    b. Adding new activities
    c. Adding new biosphere flows
  3. On open activity panels (on the left), a checkbox: “Read Only” is visible, default = checked
    a. The checkbox is ‘greyed out’ when the database the activity belongs to is read-only
    b. A tooltip informs the user why it is grey
    c. When unchecked (clicked) for a visible (open) activity, specific data fields in the tables below become editable
  4. Changed data is recognisable and reversible as described in Tracking GUI changes to activity data #10
@aj-9636
Copy link

aj-9636 commented Apr 30, 2018

Suggestion: 4. Edited data have different color from unchanged data.

@tmillross
Copy link
Author

Good point - added a new number 4 referencing those features

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants