However, one part that regressed in my opinion is the visibility of block/input steps. Previously, they had a big padlock icon that stood out. Now, it’s hard to distinguish between those and regular paused steps:
We have builds that contain a lot of unblockable steps, and I think this new look makes it difficult to scan the build and identify those steps. I read the blog post about how in the new look for failed jobs, the fat colored block around the icon is meant to stand out. May I propose a similar treatment for block steps, something like:
Maybe even with a padlock icon, like it was before.
First of all welcome to Buildkite community and thank you for reaching out to us to share your feedback on the Build Header Redesign
We shared this feedback with our UI team who will check on this and we will get back with our response on this. Thank you once again for sharing your feedback.
Hey Andy! Thanks for the feedback, it’s really appreciated. You’re absolutely right about block step visibility — we missed the mark there, but it’s something we’re planning on updating as a fast-follow. Your suggestion of following the failed style is great, how would you feel about the following:
Hey, I think that looks great! I hadn’t thought of using purple, or putting the big-colored icon on the right side, but I love how those stand out, in a way that isn’t a red “WARNING WARNING”.
Just to clarify, in your mockup, is the “Release Notes” step a block step, or a command step that was now unblocked by clicking “Deploy to Prod”? I ask because if it was a block (or input) step, I would have expected it to start with the purple arrow treatment, whereas if “Release Notes” was a command step, then the mockup seems to imply that actively running steps also get the purple arrow (since it only got the arrow once “Deploy to Prod” got unblocked), which seems a bit loud.
For what it’s worth, I would much rather that only currently blocked steps to get the purple arrow, and actively running steps continue to have the orange-yellow spinner.
I don’t know if this matters, but our pipeline topology is rather complex, so we’ve been trying to use input steps exclusively, rather than block steps. That way, we can better reason about the step dependencies. Therefore, I just wanted to call that out to make sure whatever you go with works with both types of steps.
Awesome, thanks Andy! My prototype was messy and misleading, sorry. Having discussed this internally today, a better demon would be something like this (below), where only currently blocked steps get the purple treatment (you can also see an unblocked step bottom row). Does this match your expectation?
I suppose this mockup doesn’t depict steps that would get unblocked by clicking the purple buttons? For example, this is what things look like today:
Where the “Command step” is initially “paused” because it depends on “Input step”, and after “Input step” is unblocked, then it transitions to the dashed scheduled/waiting state, and then to the orange spinner.
I’m assuming that in your proposal, the only difference at all would be that the “Input step” will get the purple arrow treatment while it’s still blocked. If that’s the case, that looks good to me, and I’m sure our customers would be happy with the clearer UI.
Correct, only the “Input step” would change visually to become purple (for visibility) — everything else should remain the same. This is being worked on as we speak
