Please note: This video presents our optimal vision for this feature in FOLIO; What you see in this prototype is what we are working towards in the long run, and might not all be present in the first, developed version. Please help us improve it — share your questions, constructive feedback and ideas in the comments below.
Questions/Comments:
What does FOLIO do when an item is checked in that hasn’t been checked out? This happens inadvertently in some cases, but at many institutions items that are found around the building (on tables or in reshelving areas) are checked as a way counting in-house use of materials. This can be a very important use statistic and many libraries rely on it.
For Check out, check in scan etc. - why is the input field hidden? what other than barcode can we use for search? where is the fielded search?
For check-in, I would need to see the following fields at a minimum:
Thanks for your comments and questions, @andrealoigman 
Questions/Comments:
- What info is displaying for checked in items? Can we configure it?
We try to work with components on a system level. This sounds technical, but essentially it means, any thing (like a list, or button or dropdown) is defined in one, central place—so that, when we make it better, it improves everywhere. One of the basic ideas with lists in FOLIO is to let the user choose what data they would like to see in the list in question. The programmers making the given app needs to provide the data to toggle on and off, but in general, customizing what you see will be a standard feature of lists in the long run. Just like you know it from various multi-column interfaces that exist today. For this particular feature, it would be great to reach a consensus on what type of information should be shown by default, and which additional types of information should be able to be toggled on by the users.
**-- Notification about holds, needs for transit to other locations, workflow flags are essential. Title, call number, barcode, shelving location, are pretty standard, but different institutions may want to see other things. **
That’s a good start then for what the list should show! Thanks!
– When there are holds, need for transfer, etc. slips need to print out. How does that happen?
The idea is to have 2 levels of notifications: One kind that stops the flow and does not allow you to do anything else, another that merely gives you a note, but allows you to continue. Depending on how much of the Workflows + To-do apps we are able to implement in the short term, I am hoping that could handle some of the logic of who gets which tasks assigned. But this is definitely an area where we need to add a lot more detail.
- Can we see info about the returning patron? and can we configure that?
At the SIG meeting where this was discussed, we concluded that we do not need to show that, as I recall. If some institutions would like to show that, I suppose it could just be a column in the list? How would that work?
What does FOLIO do when an item is checked in that hasn’t been checked out? This happens inadvertently in some cases, but at many institutions items that are found around the building (on tables or in reshelving areas) are checked as a way counting in-house use of materials. This can be a very important use statistic and many libraries rely on it.
Good point. If we could make a spreadsheet or the like with all the different exceptions and challenges for check-in, I think that would be very useful. Perhaps this could be something we can bring up in the RA meeting when there is an open slot in the schedule ?
For Check out, check in scan etc. - why is the input field hidden? what other than barcode can we use for search? where is the fielded search?
The fielded search is not available in the three apps you mention. There will be an ability to open an input field, for e.g. cases where the barcode of an item will not register. We will try to include this in the next UX iterations.
A question for the subject matter experts on Check In:
Should the list of checked in items be able to be cleared and if so, when?
My initial thought is that the list should stay visible until the operator clears it, or when the session is terminated. Referring to another point mentioned above about being able to view who the patron was who returned the item, I do believe there should be an option to display that information. If that’s the case, it becomes very desirable to keep the list of checked-in items displayed until the operator clears it. Hope this makes sense.
I agree with Andrea (her comments are outside this thread for now) that it would nice to clear the list but as long as it clears automatically at the end of the session, it’s not a high priority.A small button would be fine.
Far more important will be the ability to backdate check-in. In other words, to select an override date and time in the past that is used instead of the system time when calculating overdue fines, etc. I bring that up here because the interface to select a backdate, a prominent way of displaying the selected backdate so staff can see what it is and that it’s in effect and a simple button to cancel the backdate and reset to the system time should have very high priority in terms of display real estate, certainly more than a “clear session” button (though they could be in the same general location along the top of the screen).
I’ll also add that some systems have a “timeout” feature for checkin and checkout sessions. This is very important for loans/checkout (as you don’t want to leave a user’s record up accidentally), but less so for the checkin screen. No need for a session to time out, in my opinion–the session can simply end when the app is closed.
I agree that the information should automatically clear when the app is closed. Also agree with not having a timed session for checkin screen. Screen should stay open and functioning until the app is closed. I second David’s comment on backdating. The ability to be able to modify the date and time an item is being checked in is critical.