[Proposed Feature] Last modified entry in the web interface

[calebrob6]

Description of Feature:
I'd love to see a last modified datetime for each file/repo on the web interface.

What value is this feature adding to Source Cooperative?
This would let me quickly see if the data in a repo has been updated recently. E.g. I just looked at https://source.coop/planet/disasterdata to check on the new data that Planet has released for the wildfires in France. I want to know whether they updated the main catalog.json also, and a Last modified: <sometime earlier today> would let me parse this at a glance. It would also be helpful to see as a signal of activity. If I visit a repo and it hasn't been modified in a few years, then I know it is likely not maintained.

[jedsundwall]

This should also be available programmatically. Whatever object-level metadata we display should also be available as a json blob via a predictable URL

[jedsundwall]

Note also that objects aren't "modified" but rewritten to object storage. In any event, we should make it clear when any object has been written or re-written, and we should make that clear at the product level as well.

[alukach]

#470 adds the last-modified value, and in doing so makes the row's real problem visible: the right-hand cluster has no structure. Size, date and the buttons were never organised, so the date is just the fifth thing in a run. Four ways out, drawn at the component's real measurements (26.4px rows, 8.8px gaps, radius 0), all shown in edit mode since that's the busiest case.

@jedsundwall @LanesGood @tylere @PowerChell — which of these is worth building?

Today
1. Size, date, the download/copy pair and delete all sit in one flex at the same 8.8px gap — no seam where data ends and controls begin. 2. Both values are variable-width and right-packed, so the date lands at a different x on every row. Nothing scans vertically down 250 files. 3. The solid download button is the loudest thing on every file row, once per file. 4. Folders carry no size and no date, so folder rows and file rows have different silhouettes.

A · Aligned columns, quiet actions — recommended
Fixed-width, right-aligned size and date columns so values line up down the list; a 30px gap before the controls; buttons drop to a ghost weight until the row is hovered or focused (row two is shown hovered). Row height and component shape are untouched. Tradeoff: hover-only actions need a keyboard and touch answer — :focus-within, and permanent buttons on coarse pointers. Below ~640px the columns have to collapse.

B · Two-line rows
The name keeps line one; size · date drop to a second line indented to the name's text edge. Folders stay one line, so the list separates them by height instead of by an empty right-hand side. Tradeoff: a file row goes 26.4px → 46px, so a screen holds about half as many files, and two row heights mean the virtualizer's itemHeight stops being one number. Best of the four on a phone.

C · Table with a header
Named columns, rules between rows, and a sort affordance on Modified. An em dash marks what a folder doesn't have rather than leaving two holes — a deliberate change from today, where a folder renders nothing. Tradeoff: the header only earns its keep if the columns actually sort; otherwise it's chrome above a three-item folder. Heaviest change here — the listing stops being a list of links.

D · One action, the rest in a menu
Option A's columns, but a file row carries two controls instead of three: download stays on the row, copy and delete move behind the dots (menu shown open on row four). Puts some friction in front of the one irreversible action. Tradeoff: copying a URL becomes two clicks instead of one — plausibly the most-used control in a data catalog. Only worth it if copy is rarer than it looks.

All four keep the tooltip with the exact UTC timestamp that #470 already adds. Happy to build whichever wins; A is the smallest diff and the one I'd pick.

[LanesGood]

I'm a fan of option C and D combined - a table with the single action button, and other actions in an expandable menu. I believe the original design was created to parallel the design of github as much as possible; github's repo display already is a table, just without header text cells. It's nice to be able to use these to control sorting if that is desired by users. If we want to avoid the new column header design, Option D seems to me the greatest improvement.