Problem Validation: What other information is useful in the dependency proxy UI
Context
In #250865 (closed), we proposed adding a list of image tags that have been cached using the dependency proxy. This is a helpful MVC, but there are several open questions about what comes next. For example:
Questions I'd like to explore:
- how relevant showing how "fresh" an item is in the cache?
- what are reasons they are viewing the Dependency Proxy UI?
- what information is missing? (e.g. manifests and blobs..)
- what is their understanding of how the TTL works? I keep forgetting that the 90 day time resets when accessed.
- what do they need to see:
read_at
,created_at
, or both? Why?
Proposal
Put together a discussion guide and interview users of the dependency proxy to answer the above questions and use that research to fuel a new design/feature for the dependency proxy.
Hypothesis
- People visiting the UI will be double-checking that something they recently published is in the cache.
- People visiting the UI will be browsing what's in there.
- The best way to order the list of tags in the UI is by most recent activity.
- As long as users are not having problems with rate limiting or slow builds they don't need to how long the tag has left in the cache
Option 1: We don't know enough about why our users view the UI so we remove the field(s) from the UI for now
Option 2: We show the most recent activity in this field conditionally.
If the tag was just published, the UI says "Cached at" with the created_at
attribute.
If the tag was just accessed the UI says "Accessed at" or "Read at" using the read_at
attribute
Option 3: we show both the created_at
and read_at
in the UI.