Please use this forum to add comments and questions about the Biotics Threat Calculator
implementation introduced in yesterday's webinar. We would like all feedback by the end of the day on Monday, February 4.

Here are notes from the webinar along with detailed implementation proposals from NatureServe Central. We will update the implementation details if warranted by feedback from users.

Proposed Threat Calculator implementation in Biotics – Demo

The recording can be downloaded from Training Webinars transfer site or accessed via this link: https://register.gotowebinar.com/recording/6283836892622703106. The chat log is below.

Reminder that this was a demo of functionality not yet released. The plan is for it to go out in the next release (Feb. 27) after the feedback you've provided has been incorporated.

1. Individual threat impact calculation (calculates when scope and severity are entered)

a. How should application respond if existing Calculated Impact value is incorrect given the existing Scope, Severity, and Timing values? Note that any of the 4 fields could be incorrect; Impact is not necessarily the incorrectly entered value.

example: Scope and Severity calculate to Low rather than Medium

example: Scope and Severity are blank but Calculated Impact is populated

Reason this can happen: Until now, Calculated Impact was a manually editable field. So data could have been incorrectly entered or accidentally updated, or a batch update from Excel Rank Calculator could have been incorrect.

What we heard:

After some consideration of an automatic update of Calculated Impact, there seemed to be a consensus that an automatic update should not happen, especially given the fact that it could be Scope or Severity that are incorrect. Instead, there should be a warning with an explanation.

Request: Is it possible to create QC queries to find cases where previously entered calculated impact is incorrect for that scope/severity/timing? So we don’t have to wait to find these cases till next edit? Answer: Yes!

Suggested implementation specifics:

Display a Warning when the record is first opened, and insert red text above the grid explaining the problem. This would work similarly to our other warnings, as illustrated in this example unrelated to ranking or threats, but without the checkbox:

b. Is a Date Stored field needed?

What we heard: Nothing! So we will not add this. Rationale: Threats are evaluated as part of rank review and while we do not track dates for individual factor changes, we do track any factor changes in the rank factor date/author field.

2. Calculation of Overall Threat Impact (adjust as new individual threats are added to the grid), and Store as Calculated Threat button [note: field label will change to Stored Calculated Overall Threat Impact).

What we heard:

1. Some found the 3 overall threat impact fields confusing. NatureServe Central note: please look at the last comment in https://bioticssupport.natureserve.org/support/discussions/topics/322929 and see if this helps. We think putting a box around the Automatically Calculated and Stored Calculated fields, like we did for the rank calculations (see screenshot below) may help too.

2. Some thought Stored Calculated Overall Threat Impact should automatically update. NatureServe Central note: We think a better understanding of why there are 3 fields (see previous bullet) might help show why we are resistant to this idea.

3. Some wanted to change wording on the button to Accept, others disagreed. NatureServe Central note: we prefer to keep it consistent with rank calculation button

Suggested implementation specifics:

NatureServe would prefer to keep this as demoed, except with a box added around the Automatically Calculated and Stored Calculated fields, to keep it consistent with the rank calculation button and fields. For comparison, here is a rank calculation screenshot:

3. Rollup of lower level threats

If there is exactly one level 2 threat under a level 1 threat, its scope, severity, and timing values will automatically update in top-level threat record. The top-level threats can be edited independently; when this is done, the lower level threats are not updated. 

If there is exactly one level 3 threat under a level 2 threat, its scope, severity, and timing values will automatically update in in the level 2 threat record (and the level 1 threat record will likewise be updated if there is only one level 2 threat). 

a. How should application behave when there is more than one level 2 or level 3 threat under a top-level threat?

What we heard

1. Ideas for how to present on the screen that manual rollup is needed (NatureServe Central prefer options d or e):

a. Warning or pop-up reminder to check top level threat when lower level values change

b. Pop-up as soon as a second lower level threat is added

c. Remove values from top level threat when lower level values change 

d. Make top level red when lower level values change

Suggested implementation specifics:

We suggest a hybrid of above (if possible): a pop-up as soon as a second lower level threat is added, and make top level red when lower level values change.

b. How should application behave when a higher level threat is modified such that it no longer coincides with lower level threats? (Rollup works from lower level threats up, but not in reverse.)

Suggested implementation specifics:

We suggest a warning message: “Check for consistency among threat levels” upon the editing of a level 1 threat which has level 2,3, threat(s).

4. Level 1 Threats rows are the ones used in the Overall Threat calculation. Should they stand out in some way?

What we heard:

Yes! Highlight or bold 

Suggested implementation specifics:

We would like to proceed with bold, because highlighting used when user selects a row. We are hoping that this is feasible for the developers!

ITEMS NOT DIRECTLY RELATED TO this implementation:

is there a past webinar on implementation of other rank calculator elements: We have not found one yet. We'll post here if/when we do.

Tracking threats over time: A tracking table would be unwieldy. Audit log queries can be used instead. We will provide one.

EO Threats: use Data Manager forum to continue this discussion [not applicable to threats calculator implementation at element level]

Online Help Fix: 2^nd paragraph in Scope, Severity and Timing needs to be removed, along with some additional edits.

Generation Length: may already be a JIRA ticket, but NatureServe Central Science staff are all in agreement that this should be added to CAG and maybe CAx tables. Data model changes not fully worked out yet.

Addition of threat check box to element reference grid: data model change that can be requested.  Note that references can and should be cited in the threat summary and added to the element references grid.

EORank Calculator: Geoff Hammerson and BC developed an Element Occurrence Viability Calculator for grizzly bear populations that can be shared with those who want it. It was modified from the Excel rank calculator.It uses Population Size, Threat, Isolation, and Trend to calculate an R(1-5) rank. R5 being Excellent Viability - Secure, to R1 being Probably Not Viable - Critically Imperiled.

Chat log