Inserter: Add tabs at the bottom #1325
Comments
jasmussen
added
General Interface
|
Tabs with words + categories inside tabs 💯 Aside: the recency list is meant to be linear recency or weighted recency? |
No strong opinions. Probably best discussed on #888, but the goal it needs to solve is virtually the same as the "Recent" tab on classic emoji inserters:
Edit: "Show me your recent emoji tab and I'll tell you who you are", right? |
|
Instead of "Blocks", what about "All"? |
If it doesn't include Embeds, is it really "All"? |
|
I believe "Blocks" is a simple and clear label that end users will find easy to understand. The logic for me is they're not "Recent" or "Embeds" - they're all the other Blocks you can use. |
Right, I think it can work. My only concern was that Embeds are also blocks. What if we labelled the Embeds tab "Embed Blocks"? Seems like we can make room for it. |
Maybe in English, but not in many other languages. |
|
Have you also considered adding collapsible functionality to the headings in the Blocks tab (FORMATTING, IMAGES & GALLERIES, WIDGETS). Could be an easy way to give easier access to the item you are looking to select when working on a small mobile screen. |
I don't think novice WP users will see that distinction. Time will tell, but I expect users will end up talking about arranging Text Blocks or adding a Gallery Block. Emded is to me the logical label for something you embed in your post. I understand to a Developer it's also just another Block but for a new WP user I think Embed would tell the story. |
|
Sounds good, let's go with Blocks for now. |
afercia
added
the
[Focus] Accessibility (a11y)
|
It would be great to consider to implement the tabs as a real ARIA tabbed interface, see https://www.w3.org/TR/wai-aria-practices/#tabpanel Aside: "embed" is a terrible term to translate in my language and I guess in many other languages too. Please, let's try to make an effort to find some simpler, more intuitive term 🙂 |
|
@jasmussen thanks for splitting this out into a separate ticket! I'll keep an eye on it to see if there's anything else that can be done. |
|
Re-adding my comments from the previous issue. After sleeping on it, I still think we could potentially avoid a more complex tabbed interface by considering how embeds are approached: I think there's a massive amount of cognitive load to scan the amount of embeds as they currently exist, particularly when considering that each embed requires the same input once you've selected it (a URL). I understand the "mystery meat" embed approach, but I think a simplified approach would go a long way to fulfilling the "effortless" portion of editor focus:
I think this is a pattern that is reflected in other services (Facebook comes immediately to mind when pasting links into updates). This approach would alleviate dependency on search as well, or perhaps, change search so that when searching "Vine," the embed block would show. |
|
@nic-bertino you make some great points here. When I look at the embed tab, there IS a lot to go through, and many of the services aren't relevant to me. There are probably only 5-10 of the embed services that I'd EVER use as a WordPress user. I created a wireframe based on what you described. Is this what you're trying to say?
A couple thoughts:
Thoughts? cc @jasmussen for feedback |
|
I just saw the comments from Joen on #1289 (comment). Didn't realize the question had already been answered! Sounds like it's a no go to hide all the Embed options, and instead we want to make them more visible. |
|
@jwold thank you for taking the time to articulate this in a wire. It's very close, but I think I would just leave the Embed list item as it stands right now. An opportunity to get into the "mystery meat" might be in the unfilled block, where you could provide a few embed examples or links to the full list. Just a thought. Also regarding mystery meat: has there been any discussion about transitioning certain content into blocks from other blocks? For example: If I'm typing in Freeform and I paste an Instagram link, should the UI inform me that support exists for this type of content as an embed (and give me the opportunity to convert it into one)? I think this might be a good way to discover the vast amount of embed support that exists. |
|
@nic-bertino you're welcome! Just wanted to clarify a few things:
|
|
Regarding the "mystery meat", one could also argue that WordPress allows embedding almost everything and thus there's no need to show all these embed options at once. They feel kinda overwhelming. Similar to a "Recent" tab it might make sense to at least separate embeds into "Popular" and "All" sections. |
|
I think we should try and build this interface, because from the clickable prototype it feels like it solves the cognitive load problem of having so many embeds, which I agree is heavy. But the embed aliases, that's something I'm very bullish on. When the focus areas were announced, fixing the mystery meat embed discovery problem was one of the key foundational issues we were asked to solve:
Mystery meat navigation refers to the concept of a feature being hidden until you discover it. In the case of oembeds, it's "paste and hope". Everyone commenting on this thread are power users, so we know how oembeds work. But I suspect even we didn't know you could embed everything that's now surfaced in the inserter. We get a number of direct user facing benefits by surfacing embed aliases:
It feels hard to argue against having these embed blocks at all. So instead I'm happy to see so much focus on instead making the inserter manageable. Because this is something we'll want to do regardless — if you think there are many blocks now, wait until plugins start adding blocks. We need a scalable interface, regardless of embed aliases, and tabs, headings and recency feels like great first steps. @swissspidy's suggestion of having categories of embeds is a good idea! Though I'm reluctant to be the arbiter of which embeds are popular and which aren't ;) — though perhaps we could categorize in "video", "posts", "other" maybe? Another suggestion is to make sure the generic embed block is prepopulated in the Recent tab. Perhaps always there. |
Could you see a design where the search is above the tabs?
Open to other suggestions 👍 |
Many discussions in the archive, but it's so vast now that it's hard to dig up the specific ones. Also, paste work is ongoing right now. There's likely to be one set of features for paste at launch, and then iterative improvements down the road. I agree it'd be cool if when you pasted an instagram URL, we could suggest it be embedded as a block. Only a technical & resources question, in my mind, the idea is good! |
|
Great points on moving forward with the interface we have. We can definitely iterate on it in the future as we see the need for making it more robust. |
@jasmussen at WCEU contributor day @mtias, @nb and I were discussing a bit this, and it really depends on what we want as the main inserter feature. We should maybe try to clarify what is the main feature as first thing. Is it the search? Then I'm not entirely sure why it should be at the bottom 🙂 In this case, if the search is the "main thing" yes, I'd say moving it to the top would be the best option. We've also discussed to implement an a-z filtering feature (I think there's an issue for this), meaning:
However, I'm wondering how this a-z focusing and the search could work with tabs.
Worth noting the emoji inserter "things" at the bottom are not real "tabs": they're sort of in-page anchors and clicking them just makes the inserter scroll at the corresponding category position. |
|
One thing to consider with tabs and names is internationalization. This will look bad fairly quickly in many languages. |
@mtias we can safely allow for 13 characters in each tab (including 1 capitalized character). Is that unrealistic for some languages?
|
|
@nic-bertino great job on the wireframe, that added a lot of clarity to what you were trying to say. Low fidelity is perfect! :) Based on the conversations we've had so far I think we're going to go ahead and push forward with the tab interface at the moment. With that said, your wireframe got me thinking. What if we tried something like:
|
|
As already mentioned in a previous comment, I'd like to remind that tabs should be placed at the top (or on the left), in any case before the tab panels in the source order. Placing them after breaks the expected keyboard interaction and it's a blocker for accessibility. See the spec and especially the ARIA Authoring Practices: |
|
Why not remove all embed blocks and leave just one with similar info comment form has under "allowed HTML tags and attributes note", "allowed embeds Animoto, Cloudup, CollegeHumor.....etc"." |
|
@StaggerLeee See #1325 (comment) for a mockup for this. |
|
Looks nice. If this choice, make those buttons in one row 100% width. Otherways I personally think you focus to much on mobile Users/Editors. We desktop Users are somehow second class citizens, :) |
|
Here's an evolution of @jwold's design. Thoughts?
|
|
Could this perhaps go hand in hand with #1497? What would that look like? |
|
@mtias any thoughts on reconciling tabs with a single column? To me the font size and block item spacing addresses the issue moreso than one column. Though I'm not opposed to a single column. |
|
The blue shape is (more or less) consistent with what WP already uses so it looks good to me! |
|
Maybe the active tab could have a white background, to make it a little more obvious? And then the contents of the that tab would then bleed into the active tab (without the 1px border-top), if that makes any sense. |
I love it. Great work.
I think this could work.
I would tend to agree. Although one column could still work. |
|
It would be great to test a few versions of this:
Looking at the emoji picker on macOS, keyboard navigation would probably mean that using tab I can jump between sections and the arrow keys would select different blocks in the list. In that case, 1) is basically useless as it would take a while until you get to the tabs. Until you're there you already went through all the blocks using the keyboard. Not really ideal. The same goes with 4), just with the search. |
|
I'm not married to tabs at the bottom, they could probably work on the top also. Then they might hide entirely when you start searching. But I think tabs is a great way to scale up to potentially hundreds of blocks, rather than having one long list that scrolls. |
|
@jasmussen would you mind if I open a separate issue to consider to move tabs to the top and try to explain the expected keyboard interaction? I'd like to avoid to make this issue too long and unmanageable 🙂 |
|
Not at all. I think this is something we'll want to address regardless, because of the focus being set on the search box. On a long document you'll sometimes have the inserter open upwards, and if I understand correctly in that case we'll want the search box at the bottom, correct? |
|
FYI I've just added a new UI concept for the inserter interface on #1497 |
|
If this version of the inserter wins out, it would be nice to reorganize the "Common" elements so that text-based elements are on the left, photo blocks on the right. This would give the list a better sense of visual order. Current: Reorganized: |
|
Great point on reorganizing a bit. But we are also looking at some recency, see #888.
Just to expand on that a little, I think we'll want to try the tab interface for a while. But in using this, testing it, if we find the need to go single column or with one of the other approaches suggested, then we'll absolutely revisit. |
|
Can we try and see how the tabs will look like in other languages? Some languages have longer translations... tabs will probably break. German is one of the languages where some words are typically longer. @ocean90 or @swissspidy when you have a chance, please let us know how
|
|
@afercia I think this time we can keep it short in german, like in |
|
Last resort, which we should try to avoid, is icons only on the tabs. Before we reach that point we can explore smaller fonts, careful labeling, and a maximum inserter dialog width of 360px as defined by mobile. |
|
Closing as fixed for now. There's talk of having tabs on the side, but let's explore that in a separate issue. |
Extracted from #983 (comment), let's add tabs to the inserter. Mockup:
Clickable prototype.
As part of this effort, we are rearranging things a bit. We are starting with three tabs:
(We might want to rename Blocks, because they're all blocks? Any suggestions? It's essentially everything but the embeds)
The Block tab has categories:
If we want to tackle the "recency" as a a separate PR (such as #888), we can rename the "Recent" tab to "Common" for now, but let's remove the Freeform block from that.
CC and props: @jwold
The text was updated successfully, but these errors were encountered: