-
Notifications
You must be signed in to change notification settings - Fork 4.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
Revisit Global Styles IA #47369
Comments
This is a good take-away, and I think worth digging into. Before we change the IA, it seems like the consistency you are exploring between panels and GS sections, seems worth refining a bit. That seems to be the biggest discrepancy right now. If you dive into Global Styles → Blocks → Button, you'll see this: Note: Typography, Colors, Border, Layout. Compare that with the panels in the post editor inspector: Note: Color, Typography, Dimensions, Border. Moreover, the dimensions tools have been shoved into the Layout panel, because there isn't a "Dimensions" section. That disconnect is improved in your mockup here, because what panels exist for a block map to panels in global styles. There's some sense to this, not just for the consistency, but also because it allows the very important preview at the top to sit in a stable place across all styles you can change. Right now it's animated and duplicated because you have to drill into sections instead of working with panels: That being said, I think it's important to be careful here. I know that the waterfall section navigation was a key aspect to get right for global styles, so it would be good to revisit those original goals before we drop it in favor of panels. It's probably fine, because it's not all the way across, it's just Blocks > Block, but nevertheless good to be sure of. Furthermore, we can probably start with unifying panels with GS sections before even changing that, that seems valuable on its own. On a detail, I don't love that the block preview goes edge to edge. It does give us 32px more horizontal space to work with, but it disconnects from the theme stylecard. It might also not scale too well to moving into the dark material to the left of the browse view, which is still something being explored. |
Great feedback/thoughts @jasmussen! I think this work could be split into two main projects. The first, which is #47348, is focused on unifying local/global editing of block styles like you mentioned. The second, which is this issue, is focused on updating the IA.
I'm sure there is a way we can break this work down further if needed. It looks like @youknowriad has explored started to explore technical details |
Coming back to this, I think it requires a little more thought mostly because setting background colour within elements still feels a little off. |
I have an alternative viewpoint here. As a non-designer builder of WordPress pages, I often do not take the time to modify the design of a single element as the @SaxonF says. Probably mostly a difference in competence and goals. What I actually do on my sites, is look for good typography, and look for good colors. Here's a 40 second clip of me modifying a site with an older customizer theme, Go. I often bring this theme up as a comparison to FSE, because in Go they have 5 presets for typography (Traditional, Modern, Trendy, Welcoming and Playful) and each of the typography settings has 4 color palettes. They also have a Spacing control. So in that way, they are dealing with the same 3 major areas as FSE and doing it with a simplified version of style variations. The thing that this theme does, is it allows for the three different major areas of Full Site Editing to be changed independently, with logical presets from the designer. Using this theme my workflow is almost the complete opposite to what SaxonF describes. Instead of trying to style 1 single element completely to build a style from, I'm looking for a style preset that meets 90% of my needs and then only tweaking from there. Maybe I set my typography for the whole site, then I pick a color pallette I like mostly, and then change a color or two. My WordPress role is working with Undergrads who are creating websites, so my preference for simplicity comes from seeing non-designer end users struggle. Recording.4.mp4 |
Noting some feedback related to the current experience from the FSE Outreach Program's Build A Block Theme exploration:
Edited to add additional feedback from the same exploration related to this:
|
I've been working with theme builders this week and a related comment came up, specific to wanting to edit typography and colors in the same panel. |
@jameskoster I really like the way you are splitting those up, and I made a similar comment a year ago. Once I have done anything on my site, I get really anxious around those preset buttons. What I do now is once a design has been mostly locked, I install the build a block theme plugin from core and save my current settings as a preset. If I've done any amount of customization, the change everything at once is no longer an option. However, if I knew that what I was doing would only impact typography or impact colors without typography, then it would be much more approachable. |
Adding |
Had a quick conversation around these, and we discussed how background color, gradient, and image, are all parts of the same, and it may be good as a minimal step towards better global styles IA, to just add a “Background” item here that combine these three (right now "Background" lives under "Color). For example the sizing controls and repeat options that exist in context of the new background image tools, but in fact they affect the background gradient as well. This is the case both for global styles, and for the Group block tools. |
Sharing a rough mockup from a recent PR: styles.mp4It's missing some pieces (Revisions, Additional CSS, Preview toggle (Stylebook vs Site)) but might inspire other ideas. It's an in-the-clouds exploration of how the global styles iA might be re-organised so that levels in the UI match the granularity of edit capabilities. Broad-strokes changes like choosing a style variation or changing the overall color palette are given greater prominence than—for example—changing individual color values |
I just got to say that I enjoy seeing the above exploration! Continuing from there thinking further it would be good to save a style as if it was a full site style pattern. |
Many bits to like here, nice work, nice prototype. The only thing I'm not too sure about is changing the style variation card itself. Although there are things to like about your appearance here too, there's something more whimsical about the current Aa and two dots. If some paddings were adjusted, perhaps the dot sizes, I wonder if that older card could still work here? |
@jasmussen for sure. A lot of the visuals need tidying up, ideally making use of existing components where possible. The main focus of the mockup was to explore the iA. |
The IA can work like that well enough, I suspect beyond the base usability (which is being well tested in @jorgefilipecosta's PR), it will come down to exactly such details. There are also a couple of visual rivers in this particular icon+text+helptext+chevron setup: Nothing that can't be fixed through some careful tuning give or take what the components allow, or just adjusting the particular help text (for example seeking shorter help text, at most 1 line for each). |
What problem does this address?
The current GS IA looks like:
This has always felt a tiny bit strange to me because I often just want to focus on styling an element in its entirety (typography and colours) as opposed to focusing on a single style first.
What is your proposed solution?
ia-revamp.mp4
An alternative IA might be:
Define your presets/foundation then apply them to your site. Setting block presets like palettes is done while editing the block itself.
I've also moved style variation name to the top which we can use to show whether a variation has been modified and if so more closely map the "reset to defaults" action (right now its in top ellipsis). This could be split out into its own issue if we think it makes sense.
This is partially a follow up to #47348 which aims to unify local and global block style inspectors.
cc @WordPress/gutenberg-design
The text was updated successfully, but these errors were encountered: