-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Wide layout makes some pages hard to read + some inconsistencies #7096
Comments
I don't think the wide layout is a big deal based on what I see above. There are not long sentences of text. |
On this view - sure. But please check other views in Domain Management. Clicking on one of those domains leads to a detailed view that has already been reported by @mtias in #1737 as hard to read. Making it wide would just exacerbate the problem: The DNS editor also looks "bloated" when set to wide and inconsistent with other views such as Settings (which are not wide): cc @breezyskies |
I actually think it seems unexpected that these pages are shown together in the first place. "Plans" has its own sidebar item and so does "Domains." So when you click on these sibling options you navigate to a totally different section. They even have different homes in the URL. Why don't we just separate them? It looks like we could do this by removing the "my plan" and "plans" link from the domain pages and removing "domains" and "google apps" from the plans pages. Both sections would feel a little more logical (IMHO) and you could go back to the narrow pages for domains. |
@rralian I think the design goal with the Plans navigation was to actually bring them closer and eventually remove domains from the sidebar. (It makes even more sense when you consider it domains a la carte aren't around anymore.) |
Yeah, it does. Even if there aren't full "sentences" there, there's still the separation of actions (label on the left, actions on the right) which makes the UI disconnected. As a rough rule of thumb, consider a maximum width of a "column" around 600-700px. What's the need here of going that wide? |
I see, thanks for your eyes. 👀
The new plans page needs to be wider otherwise the plans would be too crammed on each other. I would make it even wider but we don't have more space. |
The plans page can go wider, and we can keep the other pages in a more restricted view. We already have sections that go wider and other that don't. The issue might just be a jumpy top navigation, so we might think something that is able to satisfy both. Another way would be to design the Domain Management page to go on two columns beyond a certain size. |
We are running into this in quite a few sections. We probably should figure out something where section nav is always full-width (perhaps even anchored to the page) and content can be whatever the content needs. |
That could be a good idea, and in line with our app-like approach. Something like a Marginless Tab Bar: |
Yes. Wonder what other designers think of it. cc @rickybanister @shaunandrews @adambbecker |
I'm totally on board with ditching our max-width where it makes sense. I proposed a PR (#3312 in pre-oss) that did this a long time ago, but there was some push-back about the width of screens changing as you move around Calypso — this didn't bother me then, and still doesn't bother me now. Fixing the section nav (and always having it be consistent in its 100% - sidebar width) would help with the different widths between screens, as there would be a consistent element. |
Yes, if we can figure out something for section nav that works, it becomes less of an issue whether the content has different widths, in my opinion. The biggest problem right now is that navigation jumps when you go from a wide width section to a narrow width section or to a full width section. (Examples: "/posts" and "/posts/drafts"; this case with domains, from themes to any other section, etc.) |
Ooh, yeah I'd definitely love to explore ditching any I think that's @folletto's idea about a docked "Marginless Tab Bar" is totally a method by which we can explore further, especially since it's moves us towards more of an app-like layout which I've always wanted to move towards. In the short term however, I've found that letting the content extend to StatsPostsSettingsPluginsThat would basically be changing this line to |
The "docked section nav" looks like a potentially good solution that could be applied in a few places that are having this issue. There are going to be some sections that don't make sense at full width, so this would be good to have regardless of domains specifically.
We've had several discussions about moving domains into settings (p6qnuF-HG-p2). @adambbecker also did some great concept work around this. However, this does need testing. Domains aren't a la carte anymore, but it's very likely they are still a major driver of plan sales. (Another consideration here has been the cart, which is shared between the plans and domains in the current section nav. Not a deal breaker but needs more thought.) |
Related notes from a recent #dogfooding session by @beaulebens
Here's a screencast I took today, showing how jarring it can be as you move down the sidebar menu items: |
See also #3920 "Stats: Enable Full-Width Layout" |
There is still some inconsistency in Calypso widths, for example (clicking down the sidebar):
|
@fditrapani, would be great to tackle this one along with the Domain Management revamp 🙏 |
Marking this as wontfix - this needs to be tackled on a higher/more general level and there does not appear there's appetite for that. |
@klimeryk found a bug with the wide layout redesigned plans use (p1469651926001040-slack-calypso). The Domain Management doesn't use wide layout as shown on the screenshot below:
What is more, even if we made it wide layout, @klimeryk notes that it will be hard to read. The "Domains" tab uses wide layout and it's hard to read, too (according to him):
While the initial issue can be fixed quite easily, I'd like to have a few designers look at these things and judge whether it's really hard to read with the wide layout or not. And if yes, what would be the best remedy for it.
The text was updated successfully, but these errors were encountered: