...
| Notetaker | Jennifer Eustis | |||||||||||||
| General |
This seems to make sense. We have cancelled some of our meetings. Can we keep the time slot? For example, today we fill in the total amount of time. Do we have to take into account time zones? For example, this would affect those in the western part of the US. One Stanford person said 8:30 am is fine. If we keep the 90 min. reserved for this zoom room, then if we don't use the full 90 min. we leave early until we really know we don't need this much time. Can we do a Slack poll? Yes a poll seems good. We'll keep it at 90 min. and leave early when we have a shorter agenda. For recordings, how long do we keep them? Some recordings might be worth keeping for longer. These are being automatically uploaded. Even with the demos, our recordings become obsolete. We will delete old content before 2021. All the meeting minutes are saved. We can establish a routine like where we keep only the 2 current years. Does it serve any purpose to take attendance? Do people do it because it is part of the default template? Some of the subgroups have the list of the main participants. Should we do a main participants page and have a note about keeping this info updated? On the Home Page we have a list of SME's which hasn't been updated. For each institution, Charlotte can pull out the IndexData people and each institution could do the same. If you need the ability to edit, contact Felix or Raegan with your name and affiliation. A message will be sent to Slack and email. We will remove the table from the template and just update the list of functional experts. | |||||||||||||
| Announcements |
| |||||||||||||
| PC update | This week was also the SIG updates. There's nothing new for MM to highlight. There were some questions about a translations app that you can find more details in the notes. There was a demo some time ago. The biggest things was to be able to switch languages easily. The translation of reference values would be great. Charlotte will reach out to Peter about these translations of reference values. | |||||||||||||
| Release Notes/Changes | ||||||||||||||
| Item. Possible spec bug - numberOfPieces field defined as string type |
In the Item record the data property Number of pieces implemented as a string data element. It has been suggested this should be changed to a integer (numeric) value. Question: has any implementing libraries used this data property to provide extra information e.g. 5(1 workbook, 3 hand outs, 1 diagram)? Reporting SIG has found that this is a string and not a number meaning you can have text and numbers. Is this used as only a number? You might want to reach out to acquisitions. Some people use text in addition to numbers. Some interpret the field has being able to take both text and numbers. This is a string element. Charlotte will get back to the Reporting SIG on this. | |||||||||||||
| Inventory. Current UI display limitation |
Review current UI display limitation with the holdings accordion and item list in the top of the instance - causes some unforeseen limitations. Discuss expectations short term, long term Right now, it's impossible to implement the change wanted that is described in the issue's comment. Can we live with only the instance that is shown as marked as suppressed from discovery? This seems fine if there was only one holdings that is suppressed. For the 5C, we can have an instance record with 5 holdings. This could be problematic to know when holdings are suppressed. The top instance would be suppressed. The issue is that from the result list you can't see if holdings and items are suppressed. We can use our time better to re-evaluate the result list. Let's not change the UI right now and focus on UXPROD-491. We have no commitment on when we will work on the result list. This hasn't disappeared from the instance (this being suppressed from discovery). If it is in the holdings record, you can't see it in the result list. You just need to click to see where it is suppressed. For Chicago, this is preferred behavior. For now, this change would be expensive. We can wait until we can get to UXPROD-491. Many agree with this now and focus focusing on 491. | |||||||||||||
| Bulk edit update | Lotus status update and plans for Morning Glory The in-app approach will be developed for Morning Glory. Performance testing will also be done for Morning Glory. Will you leave behind the csv? The long term plan is to have both csv and in-app approaches. These will be separated by permission sets. | |||||||||||||
Create/edit of Bound-with
|
Present UX work for Create and edit of bound-with: UX work for Create and edit of bound-with | |||||||||||||
postponed to next week...