Date
...
Time | Item | Who | Description | Goals/Info |
---|---|---|---|---|
2min | Administrivia | Andrea Loigman |
| |
20min | Item Status | Updates from item status group: tracking item status history | Review item status history wireframe. Solicit feedback/concerns on data captured/not captured in wireframe. | |
20min | Item records | Follow up on Fast Add records | - Review Kimie's new mockups for Check out page: https://drive.google.com/drive/folders/1yUAeP4cDMsexe1hy1IaFWdNh6GTfN8iL - Discuss Charlotte's proposal to have Fast adds identified by an Instance status value: https://issuesfolio-org.folioatlassian.orgnet/browse/UXPROD-1057?focusedCommentId=82440&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-82440 - Discuss how we might set the defaults for Instance status and, possibly, suppress from discovery for Fast add. | |
10min | Item Search | Item search and select popup follow up | https://issuesfolio-org.folioatlassian.orgnet/browse/UXPROD-284 Revisit priority of this feature with SIG. Based on last conversation, it did not seem this was really a go-live blocker, as indicated by most institutions. We have confirmed with Dennis that this isn't an Acquisitions go-live blocker either. Can people adjust their rankings? |
...
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Reasoning | Link to supporting materials | Comments |
---|---|---|---|---|---|---|
e.g. loans, fees/fines | Name | e.g. Q4 2018, Q1 2019 | Clearly stated decision |
| e.g. mock-up, JIRA issue | |
item Item status | Emma Boettcher | Display all item states information together if pertinent at Check In | Gives the user the most context for what they're doing as they check in items | Needs more attention to design, usability testing |
Notes
Item status display upon checkin (Emma):
What should happen when an item being discharged has multiple actionable components? Should the system simultaneously display all components (available; needed for; process) with a single modal allowing the operator to continue or cancel the discharge? Or is it preferable to display one component at a time, with a corresponding modal?
- Consensus is that all three components should display at once, with a single modal, to give the operator a clear picture of what is happening to the book. Ideally, the button labels should convey the consequences of each choice.
- If the book has an outstanding request, that component should be made more prominent
- If the discharge is cancelled, that action should be logged
- We recommend that simultaneous display vs. sequential display of status components be user tested
Creating On-the-fly records (Kimie and Cate):
Refers to UXPROD-1057. In situations where the operator must create a record in order to check it out or put it on reserve, where should the action button ("New Fast-add Record") be located? What apps need to have this functionality?
- For checkouts (such as for circulating a new issue of a journal), the group agreed that it should be located in the Checkout App, preferably below the topmost section, nearer to the Search section rather than where the End Session button is.
- For creating equipment or personal copy records, the button needs to be part of the Inventory App, but must be structured in such a way that users can be blocked from blanket permissions to create standard records in Inventory. This might be be accomplished by defining a special space within Inventory.
- Courses App should likewise have a Fast Add button that takes the operator to the Inventory app
- In all cases, a marker should be added to the record that indicates the record was created through Fast Add. There is a cataloging standard that distinguished between actual inventory and non-standard inventory.
- Fast Add records should have a Suppress from Discovery setting, configurable at the tenant level, which can be toggled on and off from the default setting
- The Fast Add function uses a form; the form should include a more obvious Check-in Note field
...
"Reason" was not needed as a table column on the Tracking status history UI. | There was enough information in other fields. | |||||
Fast add record | Cate Boerema (Deactivated) | "Suppress by discovery" should be checked by default for fast adds settings? | ||||
Fast add record | Cate Boerema (Deactivated) | The fast add record creation screen should show the instance status and make it editable. | If the fast add is a barcoded book that needs cataloging attention, then the status should reflect that. If the fast add is a laptop that doesn't need to go to cataloging, then it should have a different status. |
Notes
RA SIG meetings are cancelled for July 23 and 27.
Item Status Group report and questions (Emma):
Emma showed a mock-up of a "Tracking Status History" user interface.
- Emma asked what data was needed for this screen.
- As presented, it included the following fields: From, What, When, Field, Original Value, New value, App, Reason.
- The field names were taken from an old document so may need to be updated. UI testing process will show that.
- The table will not record anything if a status is not changed.
- There was discussion about whether it should include a where field and if the Reason field is valuable.
- As far as the RA SIG was concerned, the Reason field could go away.
Fast add record creation UI mock-ups (Kimie and Cate):
- There was general discussion about the UI of the screen.
- Cate specifically asked if the "New fast add record" button should be blue or white. The group said white.
Fast add record flagging (Cate)
- Fast add records will be flagged by the "Instance status" field. Such fields are specified by each institution in the Settings app.
- There will have to be added settings.
- Cate asked if if "Suppress by discovery" should be checked by default, in the Settings app, for fast add items. "Yes" was the consensus.
- Cate asked if the instance status field should show on the fast add record creation UI. The consensus was that it should be shown.
- Showing the status is important because people might want to change it. Not every fast add will need to go to cataloging or not go to cataloging. The record creator should be able to specify what instance status is appropriate.
- If people have the UI to change instance status, it should probably not list all possible statuses but only ones appropriate during fast adding. The problem with this is that it would require more developer time.
- Permissions related to creating fast adds will be the same as creating new items in the Inventory app. This could be a problem for some institutions but creating the feature will add software development time.
Item lookup at check out
- A past RA SIG meeting seemed to indicate that the ability to lookup an item by title in the Check Out app was not an MVP feature. That said, the JIRA ticket indicated it was for many institutions. Cate wanted to clarify if it was nor was not. There was no consensus. She emphasized that every institution should make sure the JIRA Tickets reflected what the institution wanted them to.