2018-11-5 Resource Access Meeting Notes

Date

05 Nov 2018

Attendees

Discussion tems

Time	Item	Who	Description	Goals
5min	Housekeeping	Emma Boettcher	Notetaker -
	Notices	Darcy Branchini
25min	Item States - states history	Emma Boettcher		Determine scope of states history: Availability as well as Process? What information? How far back?

Meeting Outcomes

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	Because... Because...	e.g. mock-up, JIRA issue
Requests	Cate Boerema (Deactivated)	Q4 2018 Q1 2019	Agreed that, for Requests, it would be appropriate to show no request results by default (similar to Users)	Better to show none than all Most common workflow is to look up a specific request		David Bottorff also said that, for paging request report by csv, we should add an additional Requests filter: Filter requests by item's primary service point. For something you are doing several times a day, exporting csv and filtering from there is too many steps. David also said that you are really probably going to want a more automated report for paging requests eventually (but the csv export is probably fine for v1) Cate explained that we do have a feature in the backlog for a "proper" in-app report (UXPROD-923) Cate said she would add story for the item's SP filter, but, upon further reflection, it might make more sense to just hold off on that, as UXPROD-923 should provide the more automated workflow that is desired. Comment on this page if you have concerns with this approach (David Bottorff or others).
Notices
Item states	Emma Boettcher	Q1 2019 (or later)	When displaying states history, unify availability & process in one column	Maximize information shown (both Availability & Process) without jumping back and forth between multiple timelines		Discussed use cases & other questions of scope for item states history: reviewing history of requests (Needed For) will be useful, and so will showing the full history (as opposed to system cutting it off arbitrarily) The decision reached introduces a new pattern to the wireframes - could we use this elsewhere? No conclusion

Notes

Cate view requests

how to view requests, default behavior like users app where nothing is shown - yes this is okay
needs filter for paging for service point equal to the effective location
need for eventual in app report for paging and other workflows

Darcy notices

notices related to loans specifically
individual policies vs notice policy is tying in notice policies via circulation rules versus some of them in the loan policy
cheryl-ability to resuse notice policy in multiple loan policies, no loss anywhere
notice policy allows for chronological view and likely allows better swap out when recall notice policy is needed
conclusion is that notice policy is the way to go
template feedback how does the recurring option work

missing the start trigger for upon/before/after
then recurring
do you need the until

multiple untils, but would this be a logic implied policies, etc.

does anyone need/want recurring, perhaps but maybe not on regular intervals, could just add multiple upons
we don't want the until because it should know the events that would cause this to not happen
use of fields/tokens for things like "number of days", "amount of fine accrued at this time" will reduce the number of different notices (courtesy 1, 2, 3)
do we like the ability to set a recurring notice? as long as there is a starting event trigger YES

Emma item state history

less time sensitive
display of three item states
how would this concept work with displaying the state history of an item?
is state history of availability, date and time, service point, source
Is "what process was it in" a question
can show a second block for an item's process but this seems confusing because of multiple timelines
is there a way to unify this information?
Show in process (which process) in parenthesis, consensus is that this is okay
some updates and processes won't have a service point, but that's ok
there should never be a point where you can't see the history, display in reverse chronological order and if necessary truncate display by letting it scroll down off the page or display X rows at a time by dropdown menu
history of requests as well? requests and needed for? is this also needed? yes in some fashion
could you click on process or needed for status to get to history of process or history of requests
this would live on the item record
is the date of a process relevant, should it be treated as separate columns for availability and process and dates?
Emma will revisit and revise and will revisit