Page tree
Skip to end of metadata
Go to start of metadata

Date

Attendees

Discussion tems

TimeItemWhoDescriptionGoals
5minHousekeeping
  • Notetaker -


NoticesDarcy Branchini

25minItem States - states historyEmma 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/finesNamee.g. Q4 2018, Q1 2019Clearly stated decision
  • Because...
  • Because...
e.g. mock-up, JIRA issue
RequestsCate Boerema

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 statesEmma BoettcherQ1 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