Skip to content

Review "Parcels" page

As per #355 (comment 85168).

The "Parcels" page is for:

  • External Users & Beamline Users
    • to have an overview of the status of the parcels linked to investigations in which they participate;
    • to find and access parcels quickly without having to go through the investigations' pages.
  • Safety Users
    • to find and access "READY FOR SAFETY CHECK" parcels to approve/refuse them.
  • Stores Users
    • to find and access "SENT" and "BACK TO STORES" parcels to mark them as received or sent back (though they would most often scan the QR code and land on the parcel's page directly).

According to these needs (if I haven't missed any), on this particular page, users do not need:

  • to create a parcel,
  • to edit a parcel or its content,
  • to see every single piece of information associated with the parcel (like addresses or status history),
  • to change a parcel's status (arguable, see last section below).

What they do need, however is:

  • to see an overview of each parcel (ideally based on their roles, but that's for later),
  • to be able to search, filter and sort parcels,
  • to be able to easily navigate to a parcel's page (and back) to edit it, change its status and see everything not displayed on the table.

What this means for the UI, in my opinion:

  • The table needs to show, as it does now:
    • the parcel's core info: name, proposal, beamline, start date
    • a summary of the content of the parcel (number of items of each type, dangerous goods)
    • the current status
    • what is to be done with the parcel after the experiment.
  • Ideally, the table should be customised based on the user's role (long term goal). But for now, if more information needs to be displayed (description, storage condition, etc.), then we could let the content of each column/row take up a bit more space -- for instance, we could have a column called "Parcel summary" that regroups the parcel's core info on multiple lines. If something is important enough to be displayed on this page, then having to expand each row to see it is counter productive.
  • The number of parcels per "page" should be increased drastically. (They are fetched all at once anyway, but that's another problem.)
  • Clicking on a row (and also on a "Show" link in the last column) should navigate to the parcel's page, where users can edit the parcel and its content, change its status, access its status history, etc.
  • The state of the table (page, search terms, status filter) should be persisted in the URL so that users return to this state when they navigate to a parcel's page and back.
  • A parcel's page should link back to the "Parcels" page. The filters could remain in the URL so that the parcel page knows when and how to link back to the "Parcels" page.

Arguable user needs

Some features, in my opinion, don't belong to this page because they don't answer real user needs.

Safety users

I don't think safety users need to be able to "batch-review" parcels, that is, to approve/refuse them right on the "Parcels" page. We need input from safety on this, but my feeling is that they'll need to check every aspect of the parcel before approving it, so it's not something that can be done quickly.

If navigation and persistence are well implemented, I think they would prefer visiting each parcel's page independently in order to review it thoroughly. This means that the "Parcels" page doesn't need to provide a way:

  • to approve/refuse parcels;
  • to see the content of the parcels in detail.
Stores users

Stores users will typically scan the QR code and land directly on the parcel's page. For the rare cases when they'd search for a parcel manually on the "Parcels" page (because they don't have access to a phone or scanner, which, after having met with them, I can affirm is unlikely), I don't think visiting the parcel's page in order to change its status is a big deal.

Therefore, I don't think the "Parcels" page needs to provide a way:

  • to mark a parcel as received or sent back.

Other users

There doesn't seem to be a case when users would need to save a click and be able to change the status of a parcel right from the "Parcels" page. I think providing this feature on the "Parcels" would actually lead to more errors from unintentional clicks.

Edited by Axel Bocciarelli