The auto-expand behavior, in general, is very jarring.
All sidebar movement due to hover is unexpected. It doesn’t visually read as an object that should/will expand.
Panel expansion causes the items within it to shift vertical location. Effect: “what I tried to point at before expansion is not what I’m pointing at after expansion.” I actively have to stop and reassess the entire panel, after it expands, to decide “what was I trying to point to again?” It definitely breaks my flowevery time I use it.
It would be less jarring, and just as useful, imho, if the unexpanded bar contained zero overlaid icons or text; if it was simply a colorful rectangle that would be better than today. As a user, I’d know: “hovering over the colorful rectangle will show me things I am looking for, in a reliable consistent order.” which I believe would be an improvement.
Collapsing sections does not mitigate the prior mentioned shift/mismatch/jarring effects.
Depending on pointer location the panel does get into a cycle of auto-expand/auto-hide, and flickers. (no debounce logic)
Azure Chipmunk
•
Aug 14
Also, this auto-expand in general is just very annoying. I’d like to turn it off, regardless of how the “cursor aim” thing is fixed. It’s too sensitive, and I’m just personally not a fan of auto-expanding sidebars in general. Regardless, please add a way to disable it in the settings.
Mateusz Koziorowski
Team•
Aug 17
Hi Zach, I'm Matt, product designer at Spacelift. Thanks for reporting the issue. A simple toggle to turn it off is the obvious fix, but I'm not sure it's the right one, and I'd rather understand the navigation problem underneath before we commit to anything. A few questions, answer whichever are easy:
Before this change, how did you keep the sidebar day to day: collapsed to icons, or expanded?
Which sections do you end up in most during a normal day?
When you need to get to one of them, what do you actually do? Curious whether you use the sidebar or have found faster routes.
Beyond auto-expand, is there anything else in the navigation that slows you down, or that you've built a workaround for?
Thank you in advance!
Azure Chipmunk
•
Aug 17
No problem, and happy to elaborate.
I always kept it collapsed to icons.
The majority of the time, stacks, but I’m the primary admin of our Spacelift org, so I’m often in pretty much every other section: contexts, policies, users, API keys, spaces, etc.
It depends.
I’m a heavy user of browser bookmarks, so most of the time I’ll probably already have a book for the place I’ll want to go, and just use that. See attached screenshot for an example)
However, if I’m already in the Spacelift UI, and I don’t need to keep the current tab around, and it’s a relatively “general” section (like “stacks” or “spaces”, and not some very specific search, or deeply nested section), I’ll use the sidebar.
I also have some custom browser “search engines” for things like searching for stacks by name or ID. So I can just start typing sl<space> and then the stack name to directly go to a search for that string.
Prior to the current redesign, not particularly. I’ve gotten used to the UI and know where everything else (or was), and could get to it pretty quickly. I generally only save (for example) stack searches that are frequently-used or have very-complex-to-recreate filters.
Mateusz Koziorowski
Team•
Aug 17
This is really useful, thank you. The bookmarks screenshot especially. Those nested folders that pop out without moving the parent are almost exactly the behavior you proposed in your original post, which makes a good case for it.
Two follow-ups:
What made you keep the sidebar collapsed to icons? Screen space, or less visual noise?
If the icon rail stayed where it is and the section you hovered opened next to it, so nothing under your cursor moved, would that cover it? Or is part of the appeal that nothing opens until you click?
Separate topic, but worth asking while you're here: you're organizing bookmarks by space (root, canary, and so on), and that's a dimension the sidebar doesn't really help with today. If you have thoughts on how you move between spaces, I'd like to hear them.
Azure Chipmunk
•
Aug 17
I greatly value horizontal screen real-estate, so mostly the first one.
I don’t mind the hover-over. But I tend to prefer slight delays to them. But that’s definitely something that’s personal preference, so hard to make everyone happy. What threw me off-guard for a moment is that the sections moved under my cursor on expand.
I actually just realized I can mostly replicate the previous behavior (albeit with an auto-expand, still) by collapsing all the sections:
This appears to be preserved across reloads.
I didn’t even realize I could collapse them. So maybe this suggestion really becomes: collapse them by default. And maybe adjust the highlighting so that when you hover over, the section isn’t “selected” (highlighted blue) until after the drawer expands.
I think what threw me off initially was that it looked like I had selected something (by hovering over it) but then that thing disappeared after the drawer expansion.
Azure Chipmunk
•
Aug 17
Oh, on that “spaces” topic: I don’t really view spaces in that way (“moving between them”). I don’t really see them as “folders” in a way. I see those bookmarks as “take me to the stack filter that shows stacks in space X” and not “take me to space X”. Since it’s really only the stack list for that space, not everything in that space. Contexts is a separate page, for example.
My above viewpoint is probably heavily informed by the fact that I’m an overall Spacelift root admin for our org, and I built the majority of our implementation. I tend to see stacks/contexts/etc in aggregate, and I don’t work in specific spaces most of the time. I work across the entire space tree frequently.
you're organizing bookmarks by space (root, canary, and so on)
In that particular example, those actually aren’t spaces; those are specific worker pools. We have a big “root” pool (in the root space) that acts as our “default” pool that all stacks use that don’t need to use some other specific worker pool (generally for last-mile networking reasons). That’s the root one there. The canary is a separate worker pool that only runs the stack that deploys the AWS resources for the root worker pool (which shouldn’t run on itself, for obvious reasons). It also acts as a canary for that Terraform module (if the root worker stack can run on the canary, then the change should be safe to apply on the root pool).
Mateusz Koziorowski
Team•
Aug 21
Good find, and it reframes the request. The real pain isn't auto-expand, it's the target moving under your cursor when the drawer opens. Collapsed by default, plus not highlighting a section until the drawer has finished expanding, would take most of that away.
Also telling that you didn't know sections could be collapsed at all. That's a finding on its own.
I've moved this to Gathering votes. Before we change a default for everyone, I want to know whether people want a setting or just want the default fixed.
Thanks again Zach, useful thread.
Azure Chipmunk
•
Aug 21
Before we change a default for everyone, I want to know whether people want a setting or just want the default fixed.
Honestly, having a setting for section collapse is mostly pointless if the collapsed state is preserved between sessions/tabs.
But it would be nice to have a setting to disable the auto-expand of the sidebar. That’s a pretty safe thing to do here, and would make me happy at the very least 😄 (and probably some others).
And changing the default is tricky, I get it (as someone who constantly deals with “user-facing backwards compatibility”). I think leaving the default as it is now is fine, as long as users can change it. Maybe an announcement in the next “updates” post thing? or add a pop-up the first time the user expands the sidebar after the setting is added? 🤷
Log in to comment and vote
Comments9
Sapphire Wind
Sep 17
The auto-expand behavior, in general, is very jarring.
All sidebar movement due to hover is unexpected. It doesn’t visually read as an object that should/will expand.
Panel expansion causes the items within it to shift vertical location.
Effect: “what I tried to point at before expansion is not what I’m pointing at after expansion.” I actively have to stop and reassess the entire panel, after it expands, to decide “what was I trying to point to again?” It definitely breaks my flow every time I use it.
It would be less jarring, and just as useful, imho, if the unexpanded bar contained zero overlaid icons or text; if it was simply a colorful rectangle that would be better than today. As a user, I’d know: “hovering over the colorful rectangle will show me things I am looking for, in a reliable consistent order.” which I believe would be an improvement.
Collapsing sections does not mitigate the prior mentioned shift/mismatch/jarring effects.
Depending on pointer location the panel does get into a cycle of auto-expand/auto-hide, and flickers. (no debounce logic)
Azure Chipmunk
Aug 14
Also, this auto-expand in general is just very annoying. I’d like to turn it off, regardless of how the “cursor aim” thing is fixed. It’s too sensitive, and I’m just personally not a fan of auto-expanding sidebars in general. Regardless, please add a way to disable it in the settings.
Mateusz Koziorowski
Aug 17
Hi Zach, I'm Matt, product designer at Spacelift. Thanks for reporting the issue. A simple toggle to turn it off is the obvious fix, but I'm not sure it's the right one, and I'd rather understand the navigation problem underneath before we commit to anything. A few questions, answer whichever are easy:
Before this change, how did you keep the sidebar day to day: collapsed to icons, or expanded?
Which sections do you end up in most during a normal day?
When you need to get to one of them, what do you actually do? Curious whether you use the sidebar or have found faster routes.
Beyond auto-expand, is there anything else in the navigation that slows you down, or that you've built a workaround for?
Thank you in advance!
Azure Chipmunk
Aug 17
No problem, and happy to elaborate.
I always kept it collapsed to icons.
The majority of the time, stacks, but I’m the primary admin of our Spacelift org, so I’m often in pretty much every other section: contexts, policies, users, API keys, spaces, etc.
It depends.
I’m a heavy user of browser bookmarks, so most of the time I’ll probably already have a book for the place I’ll want to go, and just use that. See attached screenshot for an example)
However, if I’m already in the Spacelift UI, and I don’t need to keep the current tab around, and it’s a relatively “general” section (like “stacks” or “spaces”, and not some very specific search, or deeply nested section), I’ll use the sidebar.
I also have some custom browser “search engines” for things like searching for stacks by name or ID. So I can just start typing
sl<space>and then the stack name to directly go to a search for that string.Prior to the current redesign, not particularly. I’ve gotten used to the UI and know where everything else (or was), and could get to it pretty quickly. I generally only save (for example) stack searches that are frequently-used or have very-complex-to-recreate filters.
Mateusz Koziorowski
Aug 17
This is really useful, thank you. The bookmarks screenshot especially. Those nested folders that pop out without moving the parent are almost exactly the behavior you proposed in your original post, which makes a good case for it.
Two follow-ups:
What made you keep the sidebar collapsed to icons? Screen space, or less visual noise?
If the icon rail stayed where it is and the section you hovered opened next to it, so nothing under your cursor moved, would that cover it? Or is part of the appeal that nothing opens until you click?
Separate topic, but worth asking while you're here: you're organizing bookmarks by space (root, canary, and so on), and that's a dimension the sidebar doesn't really help with today. If you have thoughts on how you move between spaces, I'd like to hear them.
Azure Chipmunk
Aug 17
I greatly value horizontal screen real-estate, so mostly the first one.
I don’t mind the hover-over. But I tend to prefer slight delays to them. But that’s definitely something that’s personal preference, so hard to make everyone happy. What threw me off-guard for a moment is that the sections moved under my cursor on expand.
I actually just realized I can mostly replicate the previous behavior (albeit with an auto-expand, still) by collapsing all the sections:
This appears to be preserved across reloads.
I didn’t even realize I could collapse them. So maybe this suggestion really becomes: collapse them by default. And maybe adjust the highlighting so that when you hover over, the section isn’t “selected” (highlighted blue) until after the drawer expands.
I think what threw me off initially was that it looked like I had selected something (by hovering over it) but then that thing disappeared after the drawer expansion.
Azure Chipmunk
Aug 17
Oh, on that “spaces” topic: I don’t really view spaces in that way (“moving between them”). I don’t really see them as “folders” in a way. I see those bookmarks as “take me to the stack filter that shows stacks in space X” and not “take me to space X”. Since it’s really only the stack list for that space, not everything in that space. Contexts is a separate page, for example.
My above viewpoint is probably heavily informed by the fact that I’m an overall Spacelift root admin for our org, and I built the majority of our implementation. I tend to see stacks/contexts/etc in aggregate, and I don’t work in specific spaces most of the time. I work across the entire space tree frequently.
In that particular example, those actually aren’t spaces; those are specific worker pools. We have a big “root” pool (in the
rootspace) that acts as our “default” pool that all stacks use that don’t need to use some other specific worker pool (generally for last-mile networking reasons). That’s therootone there. Thecanaryis a separate worker pool that only runs the stack that deploys the AWS resources for therootworker pool (which shouldn’t run on itself, for obvious reasons). It also acts as a canary for that Terraform module (if the root worker stack can run on the canary, then the change should be safe to apply on the root pool).Mateusz Koziorowski
Aug 21
Good find, and it reframes the request. The real pain isn't auto-expand, it's the target moving under your cursor when the drawer opens. Collapsed by default, plus not highlighting a section until the drawer has finished expanding, would take most of that away.
Also telling that you didn't know sections could be collapsed at all. That's a finding on its own.
I've moved this to Gathering votes. Before we change a default for everyone, I want to know whether people want a setting or just want the default fixed.
Thanks again Zach, useful thread.
Azure Chipmunk
Aug 21
Honestly, having a setting for section collapse is mostly pointless if the collapsed state is preserved between sessions/tabs.
But it would be nice to have a setting to disable the auto-expand of the sidebar. That’s a pretty safe thing to do here, and would make me happy at the very least 😄 (and probably some others).
And changing the default is tricky, I get it (as someone who constantly deals with “user-facing backwards compatibility”). I think leaving the default as it is now is fine, as long as users can change it. Maybe an announcement in the next “updates” post thing? or add a pop-up the first time the user expands the sidebar after the setting is added? 🤷