Versions Compared

Old Version 19

changes.mady.by.user Lisa McColl

Saved on

compared with

New Version Current

changes.mady.by.user Annalisa Di Sabato

Saved on

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

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

Filip Jakobsen, Annalisa Di Sabato, Tiziana Possemato

@Cult will do a write up of the 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. This table is an attempt to encapsulate the discussion:

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

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

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

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.

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

Search Settings Screen

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.




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




High

This is already accounted for in the UI designs:


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.


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.

...