Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Spaces] UX improvements to spaces grid #188261
[Spaces] UX improvements to spaces grid #188261
Changes from 13 commits
5e33b47
4448f10
ce2ea9a
984fe8d
7efc162
f89bc41
ab60c1d
cae256c
2ba5bac
960d5c7
d803f65
1cc851c
36ecf51
1d62cb0
88496b0
c71ff03
47bd850
473c048
3f190bc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kevinsweet
You brought up a point about an overall goal to enforce more intentional navigation paths. In that regard, we maybe don't want to include a "Switch" action here to switch the user to another Space. We already have trained users to use the Space Selector: the drop-down in the top nav.
I would also mention one difference between how the Space Selector works:
I'll put this PR in Draft mode for us to discuss. I'd like to avoid having to "undo" things as we roll out the project. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally would vote for keeping the switch here too, because as Tim mentioned, it doesn't take the user away from their context or otherwise detract, given the way it's implemented here.
But also see your point Kevin. NOT having it here should not be a big problem either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll reach out to the folks involved in this project, and we'll use this comment to vote and make a decision.
👍🏻 = keep the "Switch" action
👎🏻 = remove it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upvoted to keep the switcher. IMO, while true this is a duplication of function, the user looking at the list of spaces is operating ON that list. Whether aware or not of the "active space" concept, their focus is on the list, not the breadcrumb bar. I'll draw a comparison to the Maximize button vs. double click on a title bar. Both accomplish the same thing. While dragging a window, the focus is on the title bar. Sure the user could drop it, navigate to the maximize button, and use that, but it's a cumbersome, disjointed experience.
Also, I believe this was discussed with Ryan during the design phase prior to engineering getting started and a decision was reached. That's why it appears in the design as it does. 🙂. Unless there is a dang good reason to change the design and jeopardize the MVP implementation, let's stick to the design.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... I don't follow. What's the point of a user being able to switch spaces and still be in space settings? It's the same screen, same menu with all the same options and controls, but now i'm in a different space in the background?
It's odd to mix these usually separate things "administration" and "navigation."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it is odd to mix them, but I think our case is a bit unusual. In our case the space is sort of a non hierarchical third dimension or "layer", and since the active space is different from all the others, it just... "feels" right to be able to control it from the list of spaces. Not having it there feels like something is missing and the normal space switcher combo feels too "far" from my focus. These are just my gut opinions, but it looks like the majority of folks have the same gut.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks all, for the discussion. I believe it was worth it: got to voice concerns and listen. We have a result from the vote: the Switch action will stay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice to see this one moving fwd at pace. Bigger picture wise I'm totally on board, but in future situations, we definitely need to be able to answer the question, "what exactly is distinct purpose of a given UI element, from the user point of view?" Otherwise we're just adding ui clutter/complexity for no reason. But ack: that kind of consideration should happen earlier in the process prior to dev, for sure 👍 Onward and upward - excited for this one 🚀