Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Link to the zoom-meeting:  https://zoom.us/j/119772606

Link to the wireframes: UX Design Proposed

Link to the discussed document: https://drive.google.com/file/d/1cN_jz4Xl4lgHMBpHSvk0AwCrKKoXxGkH/view?usp=sharing open?id=167ar6mT-wwaTdrt_-6Ud3Z5npkZ4VFv-icyxCGV_2iQ

Discussion items

Work in Progress - I will dress up this notes later today. LM 

Item

Who

Notes

Introduction
@Cult staff met with Filip to discuss the UX proposal. Filip stated in the course of his discussion with @Cult, that four major issues arose that need to be resolved before development can begin on this proposal.
Questions and Answers about the UX for MARCcat

@Cult will do a write up of the out standing outstanding questions, and send out to the group to get feedback and discuss all together during this meeting.

Tiziana shared the screen displaying the UX design proposed.

  1. Search & Filtering
    • Tiziana reviewed her understanding of the requested functionality and confirmed that MARCCat can be designed to accommodate these features.
    • Do we want a "fixed filter" or a "sensitive" filter? (domanda)
    • Format type:
    • Method: Each topic gets its own page, to which the group can contribute feedback.

______________________________

?????? What do we want in the drop downs?

    • Subject
    • Begins with

____________________________________

Do you prefer to have a fixed filter, or sensitive filter - one that changes based on format selected.

Sarah - Do not need right away

____________________

What headlines should display? What options should show under these? Truncated with ability to open to see more? On this screen we're seeing just placeholders, this needs to be thought out.

___________________________________

2. Screen 2
Image Removed

Locating duplicate records in the system. If one of the filters in the search/filter pain could help identify duplicates. the dropdown showing at the bottom, if all of the fields meet those conditions ("and") then the duplicates will display. The idea of this, in combination with batch editing, duplicate records would be able to be located, then resolved in whatever way.

Tiziana? - Is it possible to have and example? Lisa will send an example. Tiziana is looking for clarity on what is wanted. Sarah pointed out that this is a lower priority.

____________________________________________________________________

Screen 3: Library wide defined, not at the user level. Agreed it should function this way.

Image Removed

_____________________________________________________________

Screen 4: No questions/issues

Image Removed

_______________________________________

Screen 5: Is it necessary to have the ability to apply this sophisticated logic - one that is applied to Fixed Field and positional tags. How important is this? If yes, then @Cult needs a list of possible tags.

This comes into play when verifying headings.

"Not necessary for version 1, but very nice to have. Nice to come back to - do not focus on at this point.."

Image Removed

_________________________________________

Screen 6: Do you want to search and retrieve both authority and bibliographic records, using specific filter? Answer: This is already in the UI. The check boxes and filters are already available.

Image Removed

Image Removed

Screen 7: Is this enough information?

Image Removed

  1. More discussion is needed about this "Heading" Function.

Screen 8: Tiziana will ask Filip about this on Monday.

Image Removed

Do we want to display the bib fields in the results? There are times, for example when searching through everything, that the bib field may not be as obvious as this example.

Do the Bib fields need to display in the 2nd pane? Chicago and Jacquie - We don't need to see the bib fields in the brief results. What is showing is sufficient.

Next step

This table is an attempt to encapsulate the discussion:

IssuePriorityMore information needed?
Fixed Filter or Sensitive FilterLowNot at the moment
Left navigation: Search Fields

Image Added
HighYes. The MARCcat Group needs to define what will appear in this drop down menu. (Or, isn't this decided in the Institution settings? - Lisa's question)
Left navigation: Type of search

Image Added
HighMARCcat group needs to establish what these will be (and what the expect outcomes will be? - Do we need this now? - Lisa's questions)
Filter categories

Image Added
HighWhat categories and subcategories would the MARCcat group like to see here?
Locating Duplicate Records - The displayed drop down menu would call and "AND" logic to help libraries identify potential duplicate records, setting their own criteria for what that may be.

Image Added
LowLisa will send Tiziana examples of what her institutions considers duplicate records that are currently in their catalog.

Search Settings Screen

Image Added
HighThis will be set at the institution level, not at a single user level. The group agreed it should function this way.

Application of a sophisticated logic, one that will enable fixed field positional tags to be used.

Image Added




Low@Cult will need a list of all of the possible positions and tags that may be needed

Search retrieving both bibliographic and authority records

Image Added




High

This is already accounted for in the UI designs:Image Added


The group is in agreement that this is a good feature.


Results List: Is this enough information? Would we want to see in the results list (second pane), the list of bibliographic MARC fields that were retrieved? Note, they will be seen in the third pane.

Image Added

The results list is good the way it is. There is no need to see the bibliographic fields in the Results pane when they are being shown in the third display pane.













Examples

Lisa McColl McColl

Attached is a MARC file with two records, sent from Lisa.

 “Both of these records are currently in our catalog and are Cambridge ebooks for the same title. The first record in the file, came into our catalog during our migration in 2014 to OLE. The second record was imported in 2016 in a batch that  was part of a new collection of Cambridge ebooks we added into our catalog. The import process, which matches on the 035 and 019 fields, should have seen the duplicate OCLC number, but it didn't.

So, this is a duplication that crept into our catalog that we do not want there. Now that I look at these and the model we worked on with Filip, I don't think that model would work the way I would want it to in this case. I think I would need an "OR" type of logic, such as "If a value held in either ($a 035 *OR* $z 035 *OR* $a 019) from one record is the same as a value held in ($a 035 *OR* $z 035 *OR* $a 019)  in another record or records, display the results."

Next step

A working document that outlines the information @Cult needs from this group will be created. The group members will be asked to contribute to that document.



Attendees

...