[META] Status page improvements
Closed this issue · 38 comments
Just so we don't miss these pieces of feedback shared in #2090 and later:
- #2135
- #2132
- Contrast issues in migration details in dark mode: #2239
- Wheel-click or "Open link in new tab" action on any migration will take you back to the migrations overview, not the details: #2235
- Incident titles do not render backticks: #2229
- Migration details table loads up with all entries filtered out. Would be better to either show all by default, or at least print a message that says how many items are filtered out so users don't believe that there are no items: #2237
- add total children & sort feedstocks by it
- width of stacktrace foldout: #2230
- display paused migrators in status page
- fix "not redirecting properly" when using link to status page: #2235
- version status errors need same formatting w/ details as migration ones: #2234
- revisit colour scheme for migrator stati (c.f. here)
- consider changing progress bar to "PRs merged", not "PRs opened" (c.f. here)
@GabrielaVives proposed these UX improvements in #2090:
- Migration table sorts all categories (see alternative proposal with single row of titles above, and category separators)
- Migration details table colors, tooltips and visibility:
I'd like to have the number of children per feedstock in the migrator overviews again, and use that for sorting the tables (with a secondary sort based on the feedstock name; currently this is using reverse alphabetical sorting, which is weird). Even nicer would be to have clickable columns for sorting (e.g. one can choose between num_children and alphabetical; both have their uses).
I'd be nice to add search bars for the migrations and version status tables on the status page.
I consider the lack of number of total children to be a regression compared to the previous status page (and the reverse alphabetical ordering is annoying too). In particular, it's going to make it hard to know where to focus attention in a big migration like numpy (2800 feedstocks).
I noted this a month ago so I'm wondering if someone (@afshin?) still feel responsible for the new status page, or is this now up to us (=cf/core)?
Thanks for flagging that @h-vetinari. Let's see if I understood correctly. Sent #2176.
Just scrolling down to the incidents, I think we should remove the "major outage" / "maintenance" etc. from any incidents that have been resolved. Otherwise it looks confusing - there's a very loud colour saying "problem!", and then you need to read the date and realize it's not a problem anymore. Also there's still a "This is a test" major outage, which should just be removed.
The confusing bit is there is no separation between active and past incidents. They are all just incidents
Maybe we should just move past incidents somewhere else and just have a link there
Active ones show up at the very top. Maybe the bottom section should be called Past incidents?
That's certainly an option
Would note the current incident was also showing up at the bottom. So we may want to change that behavior if we retitle it
Is there an expiration period where some past incidents drop from the list?
oops, yes, some colspan needs a bump there
Observed an issue with how status incidents that include URLs are rendered (no hyperlink is added): #2181
I noticed that paused migrations do not show up in the status page. These should not be filtered out. Often, a pause is just to help debug something, including e.g. which set of feedstocks the migrator is targetting.
Also, I regularly get the following when I click on either of these:
I noticed that paused migrations do not show up in the status page.
Do you have an example of a paused migration (now or in the past)? Trying to find the bit to check in the JSON payloads.
the numpy2 migration was paused until ~12h ago - does that help? If not, we can merge conda-forge/conda-forge-pinning-feedstock#5855 as paused.
Hm, I see the paused: true part in the migration file, but the JSON payloads don't show anything that indicates the paused status as far as I can see. We might need to add that boolean somewhere. It even shows up as "closed" if paused, I think?
@jaimergp Concerning the paused migrators status, is it possible to have more information about it ?
That requires some backend work in the status payloads, I think. Let's prioritize other frontend-only fixes first. "version status errors need same formatting w/ details as migration ones" sounds simple. This is the problem:
I think we can use the same Markdown approach there.
@jaimergp Concerning the paused migrators status, is it possible to have more information about it ?
@HaudinFlorence FYI the backend work is ongoing: regro/cf-scripts#2886
Haven't been able to follow all the work going into the status page (aside from noticing some changes of course); in any case, thanks for the work on this! Table layout is currently broken though
Also, the apparent fix for the issue from this comment (links back to main status page not working) has only been working intermittently at best, and actually gotten worse recently in that it seems to redirect to a non-HTTPS page (sometimes).
That's so weird. The PR preview for the latest changes does render properly: https://deploy-preview-2250--conda-forge-previews.netlify.app/status/
It does look like that it did go through (logs), but I've retriggered it anyway. The tables are separate so I think it's deployed. But I don't understand why the header has moved up.
The separate tables with only one header was from #2248, so what I currently see deployed appears to be that PR's iteration.
That's my thinking too. That the gh-pages branch is suffering from some git weirdness... Let me debug locally with main and see if we can reset gh-pages.
Yea, can reproduce locally. main has this weird hybrid solution after the merge. We'll need to submit a PR to amend.
Should be working now.
Also, the apparent fix for the issue from this #2137 (comment) (links back to main status page not working) has only been working intermittently at best, and actually gotten worse recently in that it seems to redirect to a non-HTTPS page (sometimes).
I can't reproduce this :/ I do see that the breadcrumbs point to /status (no trailing slash). So maybe it's a redirect bug in the browser? Which one are you using @h-vetinari?
I confirm that you've fixed it!
I couldn't get the breadcrumb links to break in Firefox, Chrome, or Safari (on macOS).
Is there a chance you were hitting a version that was cached in your browser, @h-vetinari? The page has been simplified to basically have a static file for every single path, so the behavior you're seeing seems to me like a caching issue, perhaps.
Is there a chance you were hitting a version that was cached in your browser, @h-vetinari? The page has been simplified to basically have a static file for every single path, so the behavior you're seeing seems to me like a caching issue, perhaps.
I've noticed this over the last couple of days since the fix was deployed, and across a couple browser restarts. Now of course I cannot reproduce anymore either (though I could a couple hours ago), but I'll comment if it happens again. I'm on the latest Firefox btw.
Another useful thing for the status page would be adding a few more labels for context. For example it might help when in addition to priority we include the context where the issue is happening?
Alternatively we might consider giving the titles of issues more prominence instead of the labels. Looking at a recent outage am seeing major outage broadcast, but don't quite know what it is about without reading further. We could soften this the major portion to help people understand what they are looking at first
Full page:
I commented on the colour scheme changes elsewhere already, but I wanted to reiterate here that I don't see how various shades of grey are more accessible (e.g. for vision-impaired people)
than the much more distinct colours we had previously
I picked the colours from the bubbles1 and put them into aremycolorsaccessible (found by random googling as I was looking for turbo, more below), and while I can't vouch for their methodology, it has pretty clear opinions:
I'm certainly not a web developer, nor expert for UX and accessibility, but I do remember how google developed a new colormap (called "turbo") with accessibility in mind a while back, and naïvely taking that as a reference would seem like we should if anything have starker colours rather than more subdued ones:
Taking the values {0.0, 0.2, 0.4, 0.6, 0.8, 1.0} from their colourmap would give us 6 colours that are in some ways ideally spaced across various metrics (e.g. across various vision impairments, for details see article).
Footnotes
-
because it's hard for me to tell where e.g.
--ifm-color-emphasis-600is actually defined; some colours are defined incustom.css, but not all ↩
One other point that I think is confusing: the progress percentage of a migration should be "PRs merged", not "PRs opened". As an extreme example, the ruby migration looks almost done (14/16 opened), but only 2(!) have been merged. That migration has separate problems, but the point is that having a PR open says nothing about whether the migration is close to finished (aside perhaps from the POV of the bot, but that's not what users/maintainers are most interested in).
Thanks for the feedback @h-vetinari. I'll create new issues for your comments and reply there to keep things actionable.
I've closed this issue to better track what to do next. The original intent here was to collect existing feedback in the first PR, but we ended up collecting more items and was difficult to watch the discussion. Thanks everyone who reported their feedback and specially to @HaudinFlorence and @afshin who implemented the fixes!