Page tree
Skip to end of metadata
Go to start of metadata

Questions concerning feature UXPROD-3569 - Getting issue details... STATUS

QuestionAnswerAction Item

Currently there is a filtering (facet-like) functionality implemented for Effective location (item) field within Browse call numbers. Does it work sufficiently? How it's supposed to be changed by adding ability to browse by call number type? How this functionality supposed to correlate with existing one conceptually and from UI/UX perspective?

  • Is Effective location (item) filter working sufficiently: After testing, it appears that all of the items in that effective location do show, except the page defaults to the last page of results; I am assuming that this should instead default to the first page of results. This may be a bug introduced in Orchid; not showing in Nolana bugfest. Otherwise functions as expected.
  • How is it supposed to change: The user should be able to filter by both Effective location (item) and Call number type (item). 
  • Christine Schultz-Richert to follow-up with Magda to determine if this was intentional or if a new story should be added to change this behavior

Is it possible to have multiple call number types for one item? How this going to be counted in facets (will it be counted multiple times for one item)?

  • No, it is not possible to have multiple call number types for one item. Each item will have a single call number type - this type may be null as it is not required.

  • You are correct however, that an Instance may have multiple call number types assigned - meaning that the holdings attached to that Instance may have different call number types.


What is the difference between Search by Effective call number (item), shelving order and Browse call number functionalities? Is it supposed to get Search by effective call number changed as well as Browsing afterwards?

  • Conceptual difference: Is this question referring to the conceptual difference between the two functionalities? If so, Browse by call number is effectively creating a "Shelf List" which contains items in the same order in which they would appear on the physical shelves. Therefore, the search string may or may not match a specific call number, and it'll show where that search string would appear in the order of call numbers
  • Functional difference: If this is about the mechanics of the two functionalities, for some reason, the Search functionality is searching a different field on the Item record - the "Shelving order" field, and the Browse functionality is looking at the "Effective Call Number Field" but sorting the results by the "Shelving order" field.
    • For Browsing purposes, the "Shelving order" field is calculated for each effective call number based on the call number type. If there is no call number type/"Other scheme" call number type, it will just sort alphanumerically
  • Connection between functionality: As of now, there is no connection between the two functionalities When the user selects an item in the browse results, it will take them to the search pane with the shelving order call number populated as the search term.


How should look like (mock-ups / wireframes are welcome) browsing with ability of facet selection items by call number types? How current UI/UX will be changed?

Two possible approaches:

1) Add new browse options

2) Create new facet

Collapsed filters:

Expanded filters:


Is it fixed amount of call number types aggregations or always computed depends on present items with corresponding call number types?

  • Is this question asking if the options on the facet should be only contain the call number types that are assigned to items? If so, yes, the dropdown should only contain call number types that are assigned to items. The dropdown should not contain any call number types that have not been assigned to any item in Inventory
  • Fixed list of call number types should show on single-select dropdown (see above mockups):
    • Dewey
    • LC
    • Local
    • NLM
    • Other scheme
    • SuDoc

Heorhii Namchuk - major change here


"The schema type will be determined by the value of the call number type" - does that mean dynamic computation of call number type all the time? Or is it possible to setup type during data import?

  • This means that the call number type that would appear on the dropdown for call number browse would be the same call number type on the Item record.


"If the call number is not provided the default search will be Other scheme" - is it possible to provide more details here?

  • This means that if there is no call number type provided on the Item record, we should consider it call number type "Other scheme"
  • Additionally, if the call number is not on the above list (#5) it should be considered type "Other scheme"

Browsing by call number types had been developed before. The question is where the development stopped and what conceptual trade-offs were taken?

  • I am not familiar with any previous attempts to browse by call numbers; the creation of the "Shelving order" field was, however, built on existing code that originally created the Shelving order for LC call numbers, but then was extended to include other call numbers. Is this what you're referring to? 

How is call number type currently ingested / computed during the DI?

  • Currently, when MARC bibliographic records are imported via Data Import, the Instance-level classification type is derived from the contents of the call number field in the bibliographic record. However, Browse functionality is considering the item effective call number, not the classification number on the Instance record.
  • I believe there are plans to derive the holdings call number type (and therefore the effective item call number type if null on the item record), but currently MARC holdings created upon data import will receive a null value for call number type


Will it be possible to choose multiple facets / filters by call number type (e.g.: LC and Dewey Decimal) and continue browsing by selected criteria?

  • The user should be able to continue browsing by selected criteria
  • We can assume that the user should be able to choose multiple facets by call number type Heorhii Namchuk - I have since confirmed that the user should only be able to select one call number type for browsing, but it is not required to be selected

Any impact on the solution creation / evaluation from the document Classification and Call number handling in Data Import? What should be considered from one (if at all) during the design?

  • My assumption is that we don't have to consider this document because our work in this feature will not require deriving the call number and there can only be a single call number type

  • No labels