Collection search page

[krgomez]

Would it be possible to create a collection specific search page for UAM:Art like the UAM:EH search page? We'd love to have this to link people over to for simpler searching. If possible, the fields we would like to have included are:

Catalog Number
Accession
Agent
Identification/Object Type
Materials
Object Title
Keywords
Description
Culture of Origin
Specific Locality
Any Geographic Element
Event Type

[Jegelewicz]

I didn't even know this existed!

You know - it seems like working this into #3262 might make more sense? We have a block for cultural, a block for art and a block for mineral?

[campmlc]

How hard is to make a custom search page? Can this just be UI - e.g. the same under the hood and expandable to full search page, but with custom fields displayed in the "simple" version interface at the institution/collection's discretion?

…

On Thu, Dec 3, 2020 at 5:14 PM Teresa Mayfield-Meyer < ***@***.***> wrote: * [EXTERNAL]* I didn't even know this existed! You know - it seems like working this into #3262 <#3262> might make more sense? We have a block for cultural, a block for art and a block for mineral? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3273 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7JBEHBKYZPPWQSOTZW5DSTASWJANCNFSM4UMUM2GA> .

[AJLinn]

@dustymc made that page for me and I usually send novices there first... plus it's on my email signature line. It's very helpful for keeping it simple.

[dustymc]

It's not terribly difficult to create custom pages. They do take maintenance which adds a continuous workload, but that's been minimal for the EH page.

Adding "panes" to the single search page is probably a bit less long-term maintenance, and I always like the idea of more eyes on shared forms when possible.

[AJLinn]

Adding "panes" to the single search page is probably a bit less long-term maintenance

Sounds like a good plan to me.
How will the use of different search panes impact our ability to search across collections? Will these only search a particular collection or will I still find walrus jawbones in archaeology, ethnology, and mammals? Or is that only with the regular search pane? Just wondering for bio folks who might be "enlightened" by the examples in art or ethno/history.

[dustymc]

The "panes in the one page" approach would make expanding collections a lot easier - the current implementation of "portals" just pre-selects collections, so (unlike your custom page) a user can simply un-select them if they wish.

The same mechanism that pre-selects collections might be used to pre-expand panes - so SpecimenSearch?guid_prefix=mine&panes=this,that might pre-select the "mine" collection and open the "this" and "that" panes. I hope I didn't just volunteer for something that isn't possible, but it seems like it should be....

I'm definitely a fan of anything that might expose unenlightened biologists to the idea that cultural collections contain various evidence of life from interesting times and places.

[Jegelewicz]

I hope I didn't just volunteer for something that isn't possible, but it seems like it should be....

HAHAHAHA! I think that about 10 times a day....

But seriously, searching in the biological pane doesn't HAVE to limit search to biological collections. It just makes it easier to search for biological stuff. The same goes for the cultural or mineral panes. Right?

[dustymc]

Correct, collections are only limited by explicitly passing collections to the search in some way. So my (fake) example above includes two types of parameters

• limit search to these collections (which a user can alter), and
• expose these panes (which a user can also - in theory! - alter)

I'm actually wondering if that search page could just be a LOT more dynamic - some sort of dropdown where you can pick panes for it to rebuild itself around, or something. That would open up the possibility of a "crazy thing that only ABC:XYZ does" pane, let users completely get rid of the panes they don't care about (instead of just minimizing), etc.

[Jegelewicz]

I'm actually wondering if that search page could just be a LOT more dynamic - some sort of dropdown where you can pick panes for it to rebuild itself around, or something.

This is what we need. Instead of just presenting all the possible fields you can search - provide a kind of guide to searching. BUT it would also be nice to be able to save your choices.....so you can return to the same search parameters over and over.

[campmlc]

That sounds like a great idea. A "customize your search" option?

…

On Thu, Dec 3, 2020 at 7:15 PM Teresa Mayfield-Meyer < ***@***.***> wrote: * [EXTERNAL]* I'm actually wondering if that search page could just be a LOT more dynamic - some sort of dropdown where you can pick panes for it to rebuild itself around, or something. This is what we need. Instead of just presenting all the possible fields you can search - provide a kind of guide to searching. BUT it would also be nice to be able to save your choices.....so you can return to the same search parameters over and over. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3273 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7JBAGHU722NLK4C43JNLSTBA4RANCNFSM4UMUM2GA> .

[Jegelewicz]

Oh wait - we already have that....YAY!

[dustymc]

Slightly crazier version of the crazy idea, which may or may not survive exposure to reality

1. Build giant search page that contains everything that can potentially be injected as "panes" - everything.
2. Hide it all.
3. Turn some stuff back on
   • Some minimalist defaults for users who have no customization requests
   • Some ability to select groups of related concepts (something like the "panes" thing now, but paneless)
   • Ability for individual users to show/hide individual "fields"
4. Provide a GET-based mechanism for controlling that.

SO...

The default page would look something like it does now, but WITHOUT the "panes" grouping things. (It's probably possible to keep the panes, but it would be a lot more processing, would take a lot of unnecessary screen real estate, and would look very weird for some states/users.)

A use can click some "customize" widget and turn on

1. Locality Junk, or
2. Just specloc and sea (and/or anything/nothing else)

Curators (or whomever) could "build custom pages" by forming URLs. search?opts=this,that,whatever,something would by default load the page with 4 search "fields" visible. (Redirects could be used to abstract that through /mysearchpage, I think.)

Unresolved:

There are a hundreds of search options, not all of which make sense in a UI. No user, especially a naive user, should have to sort through hundreds of options, nor should they be required to scroll past "sea" when they just want "state" (as they are in the panes approach). I'm not sure how to resolve those things; this would take some UI experimentation.

There are lots of dependencies. If we're not requiring collection (and we shouldn't, it prevents discovery by those unenlightened biologists) but we are allowing guid_prefix as a URL parameter (how portals work) then we're selecting things users can't see, which is evil. We either need a mechanism to resolve dependencies, or a simpler form that doesn't include them, or ??????????????

There may be various UI to get to the same point, and including them both would melt something interesting. Eg the EH page has "culture of origin" split out (certainly possible to retain that under this mechanism), but it's not clear how to resolve the possibility of having that beside a normal attribute search.

Is this worth further exploration, or do ya'll really like the "panes", or ????

[Jegelewicz]

Take a look at how WoRMS does it.

First there is just a simple search - one box, no fuss.

BUT you can do stuff if you use the tools:

But it's only a very small bit of stuff (or so it seems)

Selecting Advanced Search, get you "everything" except there are still limits set up top.

I've been stung by these, so we should be careful about where and how we include limitations.

However, I think this kind of process might work? But instead of just "Advanced Search" maybe there are a few "advanced" options:

Search all
Search biological collections
Search cultural collections
Search mineral collections

And then from there maybe some more refining before you are presented with every possible field?

[dustymc]

WoRMS

I certainly don't mind stealing good ideas from wherever we can find them, but it's important to remember that WoRMS entire content (predictably-organized taxa) is a tiny part of one of the dozens of Arctos "nodes" that search hits. A useful single-field search would be AWESOME, but I don't think I have the right magic. There are tools which search across databases, but they're generally disappointing to anyone who's ever used Google. You can Google-search Arctos, but they don't index everything so that's pretty limited. I'd love to explore that more, but it's not a simple UI problem.

Search biological collections
Search cultural collections
Search mineral collections

I still hate it - that precludes those unenlightened biologists from finding nirvana (or DNA in moccasins), and it precludes "cultural users" from finding https://arctos.database.museum/guid/UAM:Mamm:63998

[ewommack]

I think those single search fields can also be confusing for non-tech/museum/archive savvy people. I know a number of people who will give up right away if they do not find the field they want. They do not know to click the errors and more options.
Of course there is exactly the opposite too, people who get frustrated and terrified of too many options.

I suppose there must be a happy medium some where, that doesn't rely on a persons innate willingness to push buttons.

[Jegelewicz]

I'm actually wondering if that search page could just be a LOT more dynamic - some sort of dropdown where you can pick panes for it to rebuild itself around, or something.

Along with this - the search results need to be dynamic at a minimum, they should show the fields that were used in the search.

[dustymc]

merge-->#2745