Please note: This video presents our optimal vision for this feature in FOLIO; What you see in this prototype is what we are working towards in the long run, and might not all be present in the first, developed version. Please help us improve it — share your questions, constructive feedback and ideas in the comments below.
There is something that feels just a little off about this, and I can’t quite put my finger on it. Maybe it is the distinction between “Local” and “KB” as sources? What would happen if there was another source of Codex records – say the local institutional repository, for instance. Would it show up alongside “Local” and “KB”? Maybe “Local” isn’t the right label; would something like “Stacks” (as in items located in the physical stacks) be more descriptive of what is in that Codex source?
@peter, Local is the label for the ‘Local inventory’ and that is more than just items located in physical stacks. But the name ‘Local’ is definitely not written in stone, if we can think of something more eloquent.
For alpha the codex Search will search across one Local inventory, the Inventory app (latest prototype: http://ux.folio.org/prototype/en/inventory?view=full) AND one KB, the eHolding app (latest prototype: https://folio.frontside.io/). Later we’ll implements multiple Local(s) and KB(s).
Thank you @peter for this feedback!
For the label naming, we do think about what’s more descriptive for both “Local” and “KB”, and I kinda like the idea of the “Stacks” metaphor! What do you think @Charlotte_Whitt?
Also, for the future multiple sources display issue, we actually did a quick exploration of a drop-down menu UI to see if that works or not. (Please check these attachments) Any feedback is welcome 
What Charlotte said. The distinction is between metadata stored locally and metadata accessed from a remote (3rd party) KB, not between Physical and E-resources. That said, KB vs Local seems like they are not really parallel labels, since you can consider local metadata storehouses to be KBs as well. Remote vs Local doesn’t seem like it would work since that could be confused with offsite storage. External vs Internal? Other ideas?
Reconciling multiple metadata sources for the same content (e.g. eContent that has an internally-stored MARC record as well as external KB data) still seems like an important question to me, but that’s a separate issue.
Thanks @Charlotte_Whitt, @Kimie_OuYang and @Ann-Marie. These replies help.
That is good context to have. I knew for the early versions we were setting our scope for just one of each. In my imagination I was trying to think of what this user interface would look like in cases where we had more than one inventory app and one eHolidings app.
Ah, that is helpful. Yes, I can see where in a future implementation there can be more than one of each type under that button. May I suggest adding – when we get to the future implementation – a shorthand like (3/3) or (3 of 3) with each button to show that all or some subset of app sources are being searched?
– so thinking ahead to a time when we’ve added consortial functionality, the consortial catalog would be considered a KB-Remote-External Codex source? Also thinking about remote storage facilities where the inventory is stored in automated retrieval systems; that is an external Codex source?
I guess I’m just not sure the distinction between Local-Internal versus KB-Remote-External is all that meaningful.
From Peter:
I guess I’m just not sure the distinction between Local-Internal versus KB-Remote-External is all that meaningful.
A-M:
I know. That’s been niggling at me all morning. There’s definitely value in being able to set the scope of one’s search. Not sure that internal/external or KB/Inventory is the best way, especially as we add more local metadata sources, more remote KBs, and more consortial support - like Peter mentions. Maybe a dropdown or radio button option that allows you to search across all available metadata sources or just the selected one(s)?
We should realize that the same staff may not be working across all of these data sources, as well. Sure, in the “one inventory, one KB” scenario, we are likely talking about library print resources (local) and licensed electronic content (KB). But if we are adding other local or network-based data sources, it may support specialized operations such as special collections, content repository, learning objects repo, data set repo, etc, etc, etc. So, an operator may want to search all content, or set up semi-permanent filters on the searches.
If we take this just a bit further, its possible to think about different administrative units on campus, not just the library, may have uses for a folio installation. A bit of thought about how the interface handles this sort of flexibility now probably helps.
Yes, exactly – if I’m working at the Library’s Remote Storage Facility or the Archives, I may want to default my scope to just that particular metadata store, not the whole “local” metadata.
A-M
For what it’s worth, I’m not a huge fan of metaphor-based names like “Stacks”. I’d prefer to name a thing according to what it is rather than what it reminds me of.
I am wondering if you have considered that there might be hundreds/thousands of hits in the search results box. is that pane resizable? are the data elements that appear there customizable? Libraries do a lot of work with info from the “brief display,” however that’s defined.
Hi @pattywanninger, thanks for your comments and suggestions.
We have been thinking of search results when returning big numbers, as e.g. when being hundreds, and even thousands of hits. We here have the situation that the ‘hit count’ can not be exact for the Inventory app, when we have more than 1000 hits. And for the KB, where we right now have only the eHoldings app, here we can be exact up to 10,000 hits. In near future we’ll also perform search across multiple KB sources, and then the situation can be that we don’t know precisely how they behave. These are all questions our UX designers are considering and working on how to solve in the best way.
Re. the second pane - yes this is to be resizable 
