-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Create unified UI for block variants #783
Comments
Thanks for doing this! I think there's a good idea here. It might need a little fine tuning, but your point is well made. |
Glad you think so. The mockup is not good, I just hope it can help clarify the intend of the ticket. |
Inspired by your mockups, @mrwweb, here are some adjustments to the "style picker": Can also potentially be applied to headings, though that's less certain: |
This is way better! I like it, and it seems like a good way forward. I'm glad you included headings though, because I actually think that's the one thing that shouldn't use this feature (possibly the source of the uncertainty you mention). Heading hierarchy levels are explicitly not styles and so I worry about displaying them in an identical way. I think this has come up quite a few times in previous discussions. Headings are an admittedly special case, but I'd love for that to mean they get unique handling somehow. (see this core ticket for relevant discussion). Possibly something more like the "merged" layout in the OP screenshot would actually make sense? To give some other ideas of times where I think stylistic (not semantic!) block variants could be used:
All of the above are changing the style of a singular semantic element. |
Will the user know the difference between blockquote variants and heading variants? They both change the style of the element. The user will probably not know about the semantic meaning of headings, so is it important to differentiate heading variants visually in the UI? |
@drw158 While user's may not be able to articulate the differences, I still think it's important for the editor to lead user's toward good, semantic formatting decisions. Doing so makes content significantly more accessible, future-proof (theme changes), portable (email, feed readers, "readability" mode, copy & paste), consistent, etc. (I expand on these thoughts in "A WordPress Formatting Manifesto".) One thing I've experimented with in a plugin is displaying headings with hierarchy-implying dashes: Any way this editor can encourage technically sound decision—even if the user doesn't understand them!—is a win. Final thought: I also think that making it easy to create and use inline (#773) and block variants (like "warning" and "disclaimer" paragraph styles) will further discourage abuse of headings for formatting! |
I think things have been iterated on here enough to close this, however if I am mistaken please let me know. |
@mtias @karmatosed @jasmussen @melchoyce The decision was made in #5360 to reopen this ticket. Could one of you do that? Once that happens, I'm happy to try to post a summary of the conversation there unless someone knows of a way to move the relevant comments. |
Re-opened! |
As mentioned above, this ticket was reopened in light of a number of folks pushing for this feature on #5360. Here is a brief (as possible) summary and excerpts of key points made on that thread. (The conversation started with this comment comment.) This comment tries to summarize the conversation so far so it can be continued here. Summary of Proposal
Why This Would Be Useful
Examples of Block Style Variants
Code Ideas Two rough ideas for what registering a style might look like from @mrwweb (heavily inspired by the TinyMCE styleselect API in WordPress):
and from @felixarntz (more like other Gutenberg theme features):
Both focus on providing a name/CSS class pairing scoped to a block type. @chrisvanpatten suggested adding a way to register a preview image of the style. Potential Designs Beyond what's contained in this thread, @melchoyce and @chrisvanpatten did some research on what other systems use for style variations. @chrisvanpatten suggested this sidebar layout for selecting variations: @mrwweb made both an inline and sidebar option for selecting variations: Concerns/Questions Current concerns about this idea from @karmatosed:
and @mtias:
So there you have it. Discuss! |
Thanks for re-opening this. I really don't like adding to the sidebar. I think having it right in the toolbar was the right first path. |
@karmatosed Any reason for disliking the sidebar displacement? I know you've expressed concern about the sidebar getting cluttered, but maybe there's more specific reasoning on this specific issue. I've put a fair amount of thought into the two placements I proposed. Many Pros for one are Cons for the other and vice-versa. Inline Toolbar
Sidebar (not necessarily where shown)
I hadn't quite every articulated the "inline vs. block styles" distinction before (2nd pro of sidebar above), but I find that personally quite compelling. What do others think? |
I'm also not convinced that the sidebar is a bad spot for this (there's a fair amount of prior art where these types of tools fit into a sidebar), but I can appreciate the concern about the sidebar getting to cluttered (a somewhat inevitable situation as plugins start targeting the inspector, but I understand wanting to avoid core contributing to the chaos and setting the example). Is there a path forward where Block Transforms and this Style Selector (or whatever it gets called) are part of the same tool? I had expressed issue on the other ticket that they're fulfilling different purposes — Block Transforms are changing semantics, while Style Selection is purely aesthetic — but I also suspect that to an end user, they might make sense grouped together. (As a somewhat-related note, is there any centralised documentation on human-interface guidelines, that helps explain what types of controls and options are appropriate on the block or in the inspector? I think having a sense of the design team's overall philosophy regarding these choices would not only be helpful for this particular ticket, but also more broadly for those of us working on developing plugins to integrate with Gutenberg, and also make it easier to standardise some of these choices in existing core blocks.) |
In response to myself, I remembered that @gziolo posted an interesting screenshot of a combined Heading Size and Transformation dropdown over in #6781 (comment) In this case, the dropdown would obviously change more than just a CSS class (the |
Thanks for pushing this forward @mrwweb! I think the inline toolbar as placement for the variant control makes sense, mainly for the easy access to it. While most of the controls in the toolbar are not for the entire block, but rather for specific block content marked, the block type selector is also part of the toolbar, and I think it is intuitive to have the variant/style selector right beside this. My only argument for the sidebar is that the Advanced CSS class text input, which technically does the same is also part of the sidebar. However, this is a technical background and not a UX one - plus that CSS field is technical and indeed advanced anyway. So I hardly even consider this a pro argument. |
Great discussion, solid ideas. It seems clear that we all want the same on a high level:
The traditional editor interface for transformations, perhaps, is this dropdown: From a certain point of view, that interface shows both variants and transformations. It's also _two clicks, one to invoke the dropdown, one to choose it. It's also arrow-keyboardable. Given we are building a block editor, perhaps it's worth looking at the block insertion interface for inspiration. That's the same two clicks — click top left button, click block to insert. Recently we also added a visual cue for what a block looks like — shown both large and small, gray for core block and optionally brand-colored if a 3rd party block. In the past tickets were opened asking for a more clear "block indicator", so it was easy to see which block you were working with — our solution to that, so far, has been the description in the inspector: It feels like we have an opportunity here, to tie a bunch of things together at once. What if we:
I've been working out the above in a discussion with @karmatosed based on this thread, she has mockups to post too. But here's one approach that embraces the above. There's the block chip. It doubles as a block type indicator. We'd also want to use this design in the Block Settings description. Click it, to open this:
I also made another mockup that takes more direct inspiration from the Block Library design:
Thoughts? |
Some interesting takes to this. As @jasmussen mentioned I also have some ideas on this and have been working through some suggestions - it's kind of interesting to see how we've all taken different approaches here. I have take a little more unifying route by reusing the library format for blocks. This builds on my work in #7227 where I am suggesting we bring the block library into play for transforms and unify the interface a little. My suggestion would build on from that unification and have them appear right in the library. I feel this avoids bringing in yet another interface and helps unify the experience a little. There could be an issue with that extra click to get into the accordion so we in this case could break the model and have it use a scrollbar. I would want proof this is an issue though and if it is maybe we have to consider what we do in library. The benefits of having one place using the same UI here are consistency but also ease of use. The same thing looks like well the same thing. It also should avoid us having to add more toolbar hooks. Noting I am also calling them styles as to me that's what they are. I also kept the drop down indicator as without it I felt no call to click or interact. |
Love love love this!
Perhaps the accordion could be used but all the panels default to being open, instead of only the first panel? Fundamentally does the same thing, but still allows people to collapse a panel if they want. |
@karmatosed That looks great!
Back in #6781 I suggested replacing the transform/style-switcher icon with something like this: (The "H" being the icon of the Heading block in this case, but would in general be the icon of the current block.) I am not sure that this design would work with the recent additions of background styling for block icons, though. |
Good designs in here! I would definitely try to stick to existing UI for this yeah, so using the block library feels natural. From a consistency viewpoint it's a little strange that the layout changes between the block changer and block inserter to include the styles. I wonder if we could combine these two? So style variants would be a 'property' of a block, a coat of paint so to speak, but we could present these in the library as full individual blocks, if you follow me. So instead of inserting |
I think the other tradeoff is that the user has the opportunity to skip over the default styling more easily. At least as a design in my eyes, I value the ability to add variations, but also think they should be used with a purpose and the default should be the most-frequently used block for consistency's sake. Just a thought.
Good metaphor. That's useful :) |
I feel like that could get very crowded very fast. As it is, finding a specific block in the inserter can be a bit overwhelming. |
closed by #7362 |
Coming out of #773 and relating to other issues like #317, #728, and especially #522. There seems to be a need for a consistent style for choosing between variations on a type of block (e.g. the two types of blockquotes). I can't find a ticket tackling this across all blocks, so I hope this is an appropriate new ticket.
Right now, the convention appears to be numbered styles:
However, that is really similar to how Heading hierarchical levels are communicated and I also don't think that solution can scale.
If there are 6 blockquote styles, remembering which is which will be very challenging. Nielsen Norman Group's recommendation for interface design is to never use an icon without a text label. That's obviously not feasible for a project like this, but I really think block variations are a moment where the recommendation deserves heeding.
Here's a terrible mockup:
Hopefully that at least communicates the idea. In my experience, naming variations like this also increases consistency of formatting across the site—to the great benefit of the user—since styles are somewhat more semantic (think of "Warning" or "Disclaimer" paragraph styles instead of P1, P2, etc.).
We're building a system here to help people communicate, not just format text in a vacuum. I think this change will improve that experience greatly.
The text was updated successfully, but these errors were encountered: