You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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)
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:
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.
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
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
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.
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)
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:
a.The rows are colour-coded OR show a padlock icon, which is unlocked or locked.
a. Editing existing activities
b. Adding new activities
c. Adding new biosphere flows
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
The text was updated successfully, but these errors were encountered: