|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).
|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