Enhancement - Search results for Geography, Localities, Events

[sharpphyl]

Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html

Is your feature request related to a problem? Please describe. The results display for Collecting Event|Locality|Geography could be more user friendly

1. Provide option to hide empty columns as available with the bulkloader. Even with a large screen, the current view requires constant scrolling right and left.

Full Screen with empty columns and font too small to read

Legible view start

Scroll further right to see the remaining columns

Scroll back to select the entry and try to stay on the same line.

Note that the results for Geography are compressed to fit the size of the screen but the results for Events and Localities are not - possibly because there are more columns. This could be an alternative approach.

Geography fits within the screen

and the contents adjust with the screen size

2. Move the number of results to be directly under the option to Show more rows. Currently, you have to scroll to the bottom to find out how many results there are, then back up to adjust how many to Show. Volunteers frequently don't even see that there are more results on multiple pages. Optionally, change the amount in Show to the maximum of 100 with the option to show fewer.

3. Add the collecting event number as a column. Currently, you have to open a catalog record or edit the event to get the number. Volunteers without geography authority have to open a catalog record to copy the event ID. With geography authority, you still have to open the event or catalog record.

Describe what you're trying to accomplish Make the search and results easier to use and reduce scrolling and opening and closing multiple records to get needed data.

Describe the solution you'd like See above suggestions

Describe alternatives you've considered Do nothing. The system works but it isn't as user friendly as it could be

Additional context

Priority Normal but nice

[dustymc]

hide empty columns

I think that's workable - I'd personally hate it, I want the layout to be predictable, but if there's an audience we can try it. But see below.

more columns. This could be an alternative approach.

If you mean remove anything that might have data in any particular view, I don't think that's workable - anything can separate some object from others, everything's important to some user, maybe especially if they don't think they need to see it.

Move the number of results

That should be a larger discussion - if we're going to do something with that, we should do it everywhere that library is used. (Assuming that's possible, I'm not 100% sure.)

change the amount in Show to the maximum of ...

If you have users failing to get through ten records to find what they need, making them get through 100 doesn't seem productive?

In any case, I can set that to remember your rowcount.

Add the collecting event number as a column

I'm scared to ask what you're doing with that. It's not a stable identifier, it shouldn't be expected to still exist by the time you've copied it, it's not in that UI for that reason.

ave to open a catalog record

The details links expose IDs in the URL.

@Nicole-Ridgwell-NMMNHS anything you'd like to see different on place.cfm?

[sharpphyl]

hide empty columns

I think that's workable

That would be a big help.

The details links expose IDs in the URL.

Thanks. I hadn't noticed that.

In any case, I can set that to remember your rowcount.

That would be a good solution.

I'm scared to ask what you're doing with that.

We're using it to pull/sync data into the data entry form when an identical collecting event already exists.

[Nicole-Ridgwell-NMMNHS]

anything you'd like to see different on place.cfm?

I'd like to be able to control what columns are visible. Although I usually just download the data because I need to sort through locality attributes.

[dustymc]

?control what columns are visible

Elaborate? That seems dangerous to me - eg, turn off (quad, elevation, whatever), select one of the apparently-identical things (because the differentiator is hidden), end up with data you didn't know you were choosing. What am I not understanding?

[Nicole-Ridgwell-NMMNHS]

It would be nice to turn off fields like geography authority that I don't need to see so that I can see other columns without having to scroll.

[dustymc]

From https://github.com/ArctosDB/arctos/issues/4939

It would be helpful for all searches but most importantly for Locality and Events search add two buttons like those on the bulkloader display: "Hide Empty Columns" and "Show all Columns."

Put data that tends to be less variable at the far right of the screen: e.g., Geography Authority, Geo WKT, Locality Footprint, Datum, Georef Source, Georef Protocol. This would put some of the variable data we're searching for (Depth, Lat/Long, Verbatim Locality, Verbatim Date, Began and Ended Date) closer to the Control column.

[sharpphyl]

Aha! I thought I had asked for these enhancements a long time ago but couldn't find the issue. Thanks!

The issue seems to be at a standstill. Do you need more details from us on what we're looking for, @dustymc?

[dustymc]

I'm still not convinced that hiding any data results in safe behavior (see lots of recent 'geog says island and data suggests everyone just outright ignores island' and such discussions), but ordering columns (if its technically plausible) and hiding empty columns (again some potential technical constraints - I'd have to check if unexposed pages might have data and such) seems safe enough and needs sorted out for https://github.com/ArctosDB/arctos/issues/2745, going next task to see what happens.

[sharpphyl]

needs sorted out for https://github.com/ArctosDB/arctos/issues/2745

Sounds like a much bigger issue than just this, but thanks for considering.

[sharpphyl]

I'm still not convinced that hiding any data results in safe behavior

I don't think any of us are suggesting that we hide any data. But we are suggesting that empty columns just make it more difficult to find the data we need. And the order of the columns does not put the most important data in the most visible places. It hard to even follow the line from the far-right columns back to the far-left "pick" column.

You closed #4349 which had some of the same enhancement requests. The requests remain. The UI remains awkward to use. Sort of functional but so difficult to use that we often don't find existing localities/events that we should select. Where are enhancements like this in the queue or do they need committee approval?

[dustymc]

queue

I think after The Plan, which is actively making things much more homogeneous and makes cleaner UI seem all the more practical, but you tell me.

[Nicole-Ridgwell-NMMNHS]

after The Plan

That seems fine to me.

[dustymc]

The Plan means that there are no longer unpredictable patterns of usage in assertable data. I'm going active with the idea that users can read instructions, know what they need, and that the data are no longer riddled with traps.

[dustymc]

This is functional in test (https://arctos-test.tacc.utexas.edu/place.cfm?sch=locality) and could use testing. There's still some debug code on and things might move around and such, but I think the core is solid and extra eyeballs would be useful at this point.

This is a complete redesign, which as above I hope will serve as a foundation and guide for https://github.com/ArctosDB/arctos/issues/2745. In part, that means it's fully customizable and responsive. It will deal with uselessly minimalist...

or overwhelmingly comprehensive

and (except for the horrid header), it'll do all of that on mobile

Provide option to hide

You must have one column visible or it'll revert to defaults. Otherwise - have fun!

"Hide Empty Columns" and "Show all Columns."

There's a check all/none option in customize (for the search form and results), and the column selection supports click-shift-click multiselect.

Move the number of results to be directly under the option to Show more rows.

Counter is at the top.

Add the collecting event number as a column.

Done. The volatility is documented, users can do with that what they will.

often don''t find existing localities/events that we should select.

Do we need better documentation regarding naming localities and events?

[Nicole-Ridgwell-NMMNHS]

Looks great to me. There is still the issue that users without edit locality access cannot download flat attributes. Can that be fixed with this or is that a separate issue?

[dustymc]

download flat attributes

I think that's separate/an extension, but I'm definitely up for clever ideas.

I haven't done anything logged out yet, whatever's there will probably change.

[Nicole-Ridgwell-NMMNHS]

download flat attributes

I think that's separate/an extension, but I'm definitely up for clever ideas.

Is there any particular reason this is different for operators with edit locality vs operators without edit locality?

[dustymc]

@Nicole-Ridgwell-NMMNHS am I not seeing something or is that a wishlist?

In general downloads are restricted to users, but not necessarily operators - I don't think I see any reason to do otherwise here.

I think we can push locality (and event) attributes to a parts-like structure, with

• locality_id (for those who like to live dangerously), locality_name (for those who might actually put things back together), attribute_type, att.....

per line.

Shall I?

[dustymc]

AHA! I found your button! That probably has to be limited to "us" - it's slow, it only works in a fairly narrow set of circumstances, it has no metadata. Can I replace it with what I proposed above? Same data (and more), different structure.

[Nicole-Ridgwell-NMMNHS]

Can I replace it with what I proposed above?

So this would move locality attributes out of the json blob in search results?

[dustymc]

search results?

No. I'm up for anything there, but it's got to wok with datatables (unless someone has some new tech to offer, I certainly don't know of anything more capable), and it's got to function when someone adds 300 attributes, 57 of the same type, to some event - and puts it under a locality in the same condition. (That is, any number of "columns," lots of which might share names.)

I'm proposing three download options:

• download whatever you've got on in the table (potentially including attributes as JSON)
• download locality attributes (with locality identifiers) as rows
• download event attributes (with event identifiers) as rows

I think that's worked relatively well with parts (which have a similar flattening-resistant structure). It's handles the example above easily - you get one file with 300 rows and an event identifier and another with however many locality attributes and locality identifiers.

I'm of course up for anything else, but don't have any great ideas.

[Nicole-Ridgwell-NMMNHS]

download locality attributes (with locality identifiers) as rows

For the most part this would actually be a lot more work for me than download flat attributes. For locality reports, which I run very frequently, I'd basically have to do a bunch of very complicated excel to recreate the report that download flat attributes already gives me. Part of the reason I wanted other operators (such as our federal partners) to have access to download flat attributes is so that they would have easier access to the data, but this solution would not achieve that.

[dustymc]

It's a little mangled at the moment, but I'm working on just allowing all three options - I'm not sure how sustainable the flat "works when it works" thing is long-term, but it's easy enough to leave it alone for now.

As for to whom those options are available, I sorta want to ask @ArctosDB/arctos-working-group-officers for a policy on downloads, but I've also got a browser extension that lets me pull most any table as CSV (and so maybe we should drop the pointless hoop-jumping on catalog records??) Unless someone stops me like NOW the two normalized download buttons will be available to anyone with a username - not "operators" (who have some sort of granted access, at least in my head).

I think I'll probably advocate to keep the flat attributes thing internal because it works only in a limited scope and the performance will always be dicey, but that's not chiseled in stone either. Can you (have you?) just give your agency folks some limited access (coldfusion_user probably does it), or would you like that to be public as well?

[dustymc]

The table that controls customization is https://docs.google.com/spreadsheets/d/1szMntM7GlsDgakfhNEJ7yiU4ZHjDZ2qVFu-8Nz6sYJQ/edit#gid=1243144525 - please ask before changing if you aren't sure what something does.

[Nicole-Ridgwell-NMMNHS]

some limited access

they do have coldfusion_user

[sharpphyl]

Definitely an improvement and better use of the space and I especially like that the results are visible without having to scroll below the immediately visible screen. It's much easier to deal with as it's not a pop-up. Thanks for moving the number of entries to right above the results and adding the collecting event and locality IDs.

It would still be helpful to have a "hide empty columns" button like on the bulkloader especially on the Event search which demands side-to-side scrolling often, for us, past lots of empty columns. Geography source could be the last column instead of the second column.

Even without these small upgrades, it's way better and, for us, it's a GO! Thanks!

[dustymc]

hide

You can turn things off, and what has data should now be predictable thanks to The Plan.

could be the last

You can put it wherever you want.

[sharpphyl]

I don't think I'm correctly logged into test so I'm seeing the public view. With the ability to hide and rearrange columns, it definitely addresses our concerns. Look forward to seeing it in production.

[sharpphyl]

@dustymc We've been using this for a week and it's SO much easier to use. Thanks so much for all the effort you put into changing it.

@Jegelewicz Is any documentation planned? We'll develop instructions for our volunteers, but that's not always what's needed in the How Tos or Tutorials (which still show the old data entry screen).

[Jegelewicz]

@sharpphyl nobody has time for documentation :-(

If you wouldn't mind sharing whatever you guys develop, I can transform it for a How-To or at least put it on my list of things to get into documentation!

[sharpphyl]

For sure, I'll send a copy of what we create to you.