Editing "localities" is difficult

[dustymc]

SpecimenDetail - click Locality tab - try to fix something in the collecting event/locality/geology/geography stack.

http://handbook.arctosdb.org/how_to/How-to-Create-a-New-Collecting-Event-for-a-Locality.html
http://handbook.arctosdb.org/how_to/How-to-Edit-a-Specific-Locality.html
http://handbook.arctosdb.org/how_to/How-to-understand-the-Arctos-Locality-Model.html
http://handbook.arctosdb.org/how_to/How-to-Edit-a-Verbatim-Locality.html
http://handbook.arctosdb.org/how_to/How-to-Create-a-New-Specific-Locality.html
http://handbook.arctosdb.org/how_to/How-to-Reassign-Specimens-to-Another-Locality.html
http://handbook.arctosdb.org/how_to/How-to-Edit-Coordinates-and-Max-Error-of-a-Locality.html

How can we make the process better?

[AJLinn]

I would LOVE to make this process easier. With three specimen events for every object in my collection, editing or making new specimen events is a huge time-sink and a cumbersome process to teach to new operators. We may do it slightly differently from everyone else too, as we consider every single specimen event to be unique, unless someone bought a bunch of objects at the same time from the same source and donated them all together.

I certainly need some more tutoring on best practices for our particular use of specimen events & localities, as I think they're slightly different from how others use this. A good topic for a webinar...

[ebraker]

I think reassigning events/localities can be very confusing and error-generating, especially for newer operators. Perhaps we could simplify editing events and localities by adding a menu within the specimen record locality tab in the "this event [or this locality] contains" scary red box that provides an operator management action list.
E.g., A drop-down menu that once selected, opens up relevant fields to be edited (similar to entering coordinate values in data entry screen - the fields change based on the coord. system selected). Something like:

• "edit ALL records listed here" = would show the already-populated event (or locality) fields, and you would edit as usual and all records in the red scary box would receive updates
• "edit this specimen record ONLY" = displays 2 options: (1) move the selected (single) specimen record out of current event/locality and into an existing event/locality (using pick event/locality query) OR (2) edit current event/locality fields and save which automagically creates a new event/locality and moves the selected (single) specimen out of current event and into newly created event
• "edit MORE than one record contained in this [locality/event]" would have a 'pick specimen' query (as in the manage citations form) so that multiple specimens in the current event could be selected and pulled either into an (1) existing event/locality or (2) into the automagically created new event/locality
• editing actions could end with some sort of checkbox or prompt: "delete old collecting event from record(s)?" vs. "keep old collecting event in specimen record(s)"

I don't know if this makes sense or would jive with the multiple ways people use events and I am not attached to the above format. However, I am imagining something that concisely summarizes editing actions and keeps operators in one screen to minimize navigating in and out of multiple tabs and menus and avoids cloning, and where it is easy to pull a single specimen or a specific handful of specimens out of an event or locality containing multiple specimens. And yes, I agree with @AJLinn that we should add managing events/localities to the webinar list.

[campmlc]

The process of cloning collecting events to make a new one is particularly opaque. Nothing should involve having to leave the window you are in to go do something else somewhere else and then come back to finish. Clearly explained prompts and pop ups and drop downs are necessary. This is where having an outside review of our user interface eg IMLS would be very helpful.

…

On Dec 12, 2017 3:42 PM, "Emily Braker" ***@***.***> wrote: I think reassigning events/localities can be very confusing and error-generating, especially for newer operators. Perhaps we could simplify editing events and localities by adding a menu within the specimen record locality tab in the "this event [or this locality] contains" scary red box that provides an operator management action list. E.g., A drop-down menu that once selected, opens up relevant fields to be edited (similar to entering coordinate values in data entry screen - the fields change based on the coord. system selected). Something like: - "edit ALL records listed here" = would show the already-populated event (or locality) fields, and you would edit as usual and all records in the red scary box would receive updates - "edit this specimen record ONLY" = displays 2 options: (1) move the selected (single) specimen record out of current event/locality and into an existing event/locality (using pick event/locality query) OR (2) edit current event/locality fields and save which automagically creates a new event/locality and moves the selected (single) specimen out of current event and into newly created event - "edit MORE than one record contained in this [locality/event]" would have a 'pick specimen' query (as in the manage citations form) so that multiple specimens in the current event could be selected and pulled either into an (1) existing event/locality or (2) into the automagically created new event/locality - editing actions could end with some sort of checkbox or prompt: "delete old collecting event from record(s)?" vs. "keep old collecting event in specimen record(s)" I don't know if this makes sense or would jive with the multiple ways people use events and I am not attached to the above format. However, I am imagining something that concisely summarizes editing actions and keeps operators in one screen to minimize navigating in and out of multiple tabs and menus and avoids cloning, and where it is easy to pull a single specimen or a specific handful of specimens out of an event or locality containing multiple specimens. And yes, I agree with @AJLinn <https://github.com/ajlinn> that we should add managing events/localities to the webinar list. - — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1357 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOH0hB8flUyj1NyjeFWYC0XDyBkbA1fgks5s_wE3gaJpZM4Q_dvI> .

[dustymc]

So...

Current stuff remains - users with appropriate permissions and access can cascade locality/event changes, same as always.

And add two new widgets to the "specimen locality" form:

• move this specimen to its own locality stack (eg, you want to ADD data and keep the existing)
• move this specimen to it's own locality stack, and remove it from the current one (eg, you want to CHANGE data)

I think #865 is a pre-requirement; this seem destined to create duplicates, but I don't care if I can auto-merge them.

So the workflow would be...

• find a single specimen (in a shared locality/event) with a problem
• click one of the new buttons, make edits which affect only the single specimen (because it's in a new now-unshared locality/event)
• possibly change "acceptedness" (specimen event type and verification status #1023) to the locality stack you split off FROM, if you kept the original data. This could be implemented in lots of ways - eg, built into a "split this off" widget as an option. This would also provide an escape from the "lock [...] data across collections" concern mentioned in specimen event type and verification status #1023.
• potentially come back later to find the specimen in a shared locality/event stack, because you've made a duplicate (eg, by changing nothing, or by doing the same thing to multiple specimens) and duplicate localities #865 has auto-merged the new locality/event with similar data.

This would make locality_id and collecting_event_id even more ephemeral, but they each have a "nickname" option which provides stability on demand - I don't see any problems with that. The locality (and event once #1017 is implemented) history might be a bit more complicated - it would be easier to add/remove specimens from events/localities, so I'd expect that to happen more often. I don't think this is much of a problem either.

Seems workable to me. Thoughts?

[dustymc]

Procedure auto_merge_locality is running "on new stuff and recheck every month or so."

Check that it's keeping up if a new app is making duplicates.

[dustymc]

Back to next task re: #1705 (comment)

[dustymc]

Ref: email from @DerekSikes "higher geo locality record data fix request"

A bunch of specimens in localities which are also used by other collections (that do not want changes) need new geography. This seems like a good use case to develop the core code needed for a new single-specimen locality form.

For each specimen...

• "clone-with-changes" the entire locality stack. This will result in a new unused collecting event and locality, in this case with new geography
• update the specimen_event to use the new collecting_event
  • Curator has requested a change rather than addition for this, but a "keep the old specimen_event as unaccepted" option should exist
• let the cleanup scripts deal with the duplicate events and localities. This will create many of them, but the simple approach of just always making copies seems completely defensible in light of the continuous de-duplicater processes.

Bumping priority.

[dustymc]

There is a new form available in production, if you know where to look...

Random things I've addressed (or avoided...) from comments above:

we consider every single specimen event to be unique,

Structurally correct - specimen events are links, not shared.

unless someone bought a bunch of objects at the same time from the same source and donated them all together.

If you have eg, 2 things {event-typed} at the same place/time, the only way you can now keep them separate is by not doing a very good job of being consistent with your data (or naming the localities). IF you follow the guidelines and etc., the merger scripts will find and merge them, and you'll suddenly have about half as much data (for two specimens - it's a much more drastic reduction in your workload if there are hundreds) to manage, and perhaps some help in doing so. This is the idea that the new form is built on.

I think reassigning events/localities can be very confusing and error-generating, especially for newer operators.

Yup! I'm not sure if "we" will use what I've built, but it should be a very simple way for eg students to manage locality data without having scary rights or a deep understanding of a complex model. And there's no reason "we" shouldn't use it for one-off specimens, including those that are one-off because they have very precise data. Using it for shared localities should not be preferred, however.

"edit ALL records listed here" = would show the already-populated event (or locality) fields, and you would edit as usual and all records in the red scary box would receive updates

I've just left the old forms alone to do this.

"edit this specimen record ONLY" = displays 2 options: (1) move the selected (single) specimen record out of current event/locality and into an existing event/locality (using pick event/locality query) OR

I THINK that is straightfoward ("pick new event") from the current form so I've done nothing. I'm very up for better ideas.

(2) edit current event/locality fields and save which automagically creates a new event/locality and moves the selected (single) specimen out of current event and into newly created event

This is basically the new form, but it works for specimen events, not specimens.

"edit MORE than one record contained in this [locality/event]" would have a 'pick specimen' query (as in the manage citations form) so that multiple specimens in the current event could be selected and pulled either into an (1) existing event/locality or (2) into the automagically created new event/locality

This was not considered at all. You can get there fairly easily with current tools. We could talk radical ideas if this is a common need - eg, a 2-pane 'drag event to locality' form would be fun (and terrifying...) to write.

editing actions could end with some sort of checkbox or prompt: "delete old collecting event from record(s)?" vs. "keep old collecting event in specimen record(s)"

I think the idea is solid, but I don't much like the UI I came up with - anyone who really understands what it does probably won't much use the form. I'm tempted to default it to 'archive' mode, but I know someone would panic when they find 500 unaccepted events attached to a specimen.... Better ideas greatly appreciated. #2102 might help if we are up for 500 mostly-identical specimen-events.

I don't know if this makes sense or would jive with the multiple ways people use events and I am not attached to the above format. However, I am imagining something that concisely summarizes editing actions and keeps operators in one screen to minimize navigating in and out of multiple tabs and menus and avoids cloning, and where it is easy to pull a single specimen or a specific handful of specimens out of an event or locality containing multiple specimens. And yes, I agree with @AJLinn that we should add managing events/localities to the webinar list.

Yes I think there's plenty of room for Part 3!

The process of cloning collecting events to make a new one is particularly
opaque. Nothing should involve having to leave the window you are in to go
do something else somewhere else and then come back to finish. Clearly
explained prompts and pop ups and drop downs are necessary. This is where
having an outside review of our user interface eg IMLS would be very
helpful.

I would LOVE an external UI review, but I doubt that would help with this. I think useful suggestions would depend on someone understanding the model and how it's used. The two UI folks we've had help from did not get very deep into that; I think we are the experts.

In any case the details behind the new form are purposefully opaque, but the process of using it should be very straightforward.

Current stuff remains - users with appropriate permissions and access can cascade locality/event changes, same as always.

yes

And add two new widgets to the "specimen locality" form:
move this specimen to its own locality stack (eg, you want to ADD data and keep the existing)
>move this specimen to it's own locality stack, and remove it from the current one (eg, you want to CHANGE data)

One widget and a 'select how to save'

I think #865 is a pre-requirement; this seem destined to create duplicates, but I don't care if I can auto-merge them.

Yes, this thing makes (and orphans) lots of localities and events. I would recommend drastically reducing the time before events are considered for merge or deletion - it's currently 30 days - but someone asked for that lag.

So the workflow would be...
find a single specimen (in a shared locality/event) with a problem

Single specimen-event, and users don't need to worry about whether anything is shared or not (although you'll probably want to develop curatorial policies on this).

click one of the new buttons, make edits which affect only the single specimen (because it's in a new now-unshared locality/event)

Yes, but specimen-event, not specimen.

possibly change "acceptedness" (#1023) to the locality stack you split off FROM, if you kept the original data. This could be implemented in lots of ways - eg, built into a "split this off" widget as an option. This would also provide an escape from the "lock [...] data across collections" concern mentioned in #1023.

'to save..' sreenshot above.

potentially come back later to find the specimen in a shared locality/event stack, because you've made a duplicate (eg, by changing nothing, or by doing the same thing to multiple specimens) and #865 has auto-merged the new locality/event with similar data.

yes, if you're consistent the merger scripts will do their thing. We are appallingly inconsistent; we need to work on http://handbook.arctosdb.org/documentation/higher-geography.html#guidelines-for-assigning-geography-to-specimens and http://handbook.arctosdb.org/documentation/locality.html#specific-locality. ("No specific locality recorded" seems to reliably confuse geolocate, for example, even if the geography is fairly specific. I'm not sure how to get around that, but we should look for a way to do so - maybe work with GeoLocate to ignore that phrase??)

This would make locality_id and collecting_event_id even more ephemeral, but they each have a "nickname" option which provides stability on demand - I don't see any problems with that. The locality (and event once #1017 is implemented) history might be a bit more complicated - it would be easier to add/remove specimens from events/localities, so I'd expect that to happen more often. I don't think this is much of a problem either.

I think maintaining the history is the weakness in the current implementation. This app creates localities, so there's no history in them. Defaulting the save option to "add/archive" would 100% address this, but would potentially create a lot of unaccepted events. (Some users click save every few seconds...) I'm certainly OK with that if ya'll are - we can get the disk space it might eventually require, and we can "do less" with unaccepted events (although hiding them has caused problems before). Otherwise I think it's just going to come down to documentation and your policies/training. If we keep the two save modes, your techs should know when to use them.

http://handbook.arctosdb.org/how_to/How-to-Create-a-New-Collecting-Event-for-a-Locality.html

click, type, save - this creates new everything, but if you're consistent they'll be re-merged.

http://handbook.arctosdb.org/how_to/How-to-Edit-a-Specific-Locality.html

Don't - create new. ("We" still very much need this functionality and documentation, but new students may not.)

http://handbook.arctosdb.org/how_to/How-to-understand-the-Arctos-Locality-Model.html

Students now don't have to understand the locality model to safely update locality data for single specimens.

http://handbook.arctosdb.org/how_to/How-to-Edit-a-Verbatim-Locality.html

This seems like a good reason to default "add" with the new app - if we're editing verbatim we should be tracking that. (But reality....)

http://handbook.arctosdb.org/how_to/How-to-Create-a-New-Specific-Locality.html

click, type, save

http://handbook.arctosdb.org/how_to/How-to-Reassign-Specimens-to-Another-Locality.html

click, type, save

http://handbook.arctosdb.org/how_to/How-to-Edit-Coordinates-and-Max-Error-of-a-Locality.html

click, drag stuff on map, save (or "advanced mode"/old way: edit event, 'pick new locality')

You can access the new form from specimen-->locality-->[ o ]

It may be up and down - I'm still ironing out some wrinkles. Please gently test it out, and let me know of anything that could be better. I can make the link more obvious after we have vetted the form and the documentation is cleaned up.

[dustymc]

I'm interpreting the silence as enthusiastic approval after rigorous testing...

Links are decryptified, warnings are removed, closing.