Closed bloodearnest closed 1 month ago
Quick mock up with the current/previous links and a couple of backends. We'll display any backends for which jobs have been run for this workspace.
Sounds sensible - how about very briefly user testing this mock up to check it makes sense to people?
I think inverting the order is a good idea, i.e. published -> released -> level 4.
I do wonder if we'd want to break it up more clearly, so a separate card for "Published", "Released", and "Level 4"?
Poor use of the term mock up from me, this was just to show how many items we're looking at, not a design idea! I've asked @tomodwyer to take a pass at the UI as well.
User testing might give us some inspiration about how to make our releases / publications / etc terminology a bit clearer
I have some ideas and will try to get a mockup in front of users before the Christmas break.
Closing as we've already done a lot of this and most of the rest is covered in #1261 .
We need to improve the links to various levels of releases:
1) We should add more explainer text for each type of release link, particularly explaining about VPN/RDP access needed for each level 4.
2) We should disable links that have no data, rather than hide them, to avoid confusion and provide early feedback of availability of that kind of release data. We could also disable if the user doesn't have permission, but it might be better to let them click and get an explicit permission denied page, as thats argubly a cleaner UX, as well as implementation.
3) We should include shortcut links to for the most common use case, e.g.
4) We should include some summary info in the link text, e.g. "Current Releases (34 files)", "Latest published outputs (0 files)" or similar.
5) Level 4 links should be split out to per backend links
HEAD $LEVEL_4_URL/workspace/$WORKSPACE/current
request returns 200.