Our vision is to be the go-to resource for design for other teams across the WordPress open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project.
A few weeks ago, we introduced the new Openverse identity as the beginning of a redesign journey, where we placed the search engine within the WordPress ecosystem. Since then, we have been working on a new interface that consolidates the new brand and puts consistency with WordPress at the forefront.
You may have heard about Openverse during State of the Word 2021, which is perfect timing to dive into what’s coming next for Openverse.
Audio. The new content type
The goal of Openverse is to catalog all openly-licensed content, not just images. To start this journey, we decided to include audio results as a new content type that many creators use for various purposes. This integration demanded designing an interactive audio player component with multiple variants and accessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) as a primary concern. Even when Openverse spans a simple flow, the audio browsing experience is completely different from searching for an image.
We wanted to keep the interface as clean as possible, but the vibrance of the brand colors also excited us. For this reason, we used our brand yellow for the active, ‘playing’ state. Its boldness really shines when interacting with the component.
At the same time, we wanted to highlight the artwork that creators added to their audio, whether album artwork, a podcast logo, or an image taken during a field recording, for example. For audio tracks without artwork, we plan to design a default image that uses the spectral data of the audio file to add randomness.
We will post about that in the following weeks.
A gallery for all content
Audio and images were mentioned as relevant content types by our users during the interviews we ran. For that reason, we explored the idea of having a gallery showing all content results to exhibit the strength and flexibility of Openverse. There aren’t many search engines, to our knowledge, that integrate results from different media types, and we’re excited by future possibilities like multimedia user collections.
Imagine a biology teacher making a collection of images of crows; audio files of crow calls; and 3D models of the skeletal structure of a crow’s wing!
The resulting gallery challenged us to make a simple yet interactive page to preview audio and dig into the content details.
Browsing results without leaving
Since time ago, we have been hesitant about the idea of seeing the content details as a modal. The page view provides a straightforward navigation and interaction experience when opening the source site and copying the attribution info. However, it felt as leaving the search results page and splitting the browsing experience into separated moments.
The new modal looks clean, and the main content is even more predominant. On images, the showcase space is modest, whereas audio fills the modal width to allow a seamless experience. The result details are clustered in sections, and the vertical lecture is flexible to varying heights.
I would love to dive into other changes like the new headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes., the symbol animation when loading content, and all the accessibility challenges when designing the audio states. But for now, this snap summarizes the essence of the new Openverse.
We are looking forward to putting this redesign online and seeing what people come with. This step, after the brand work, is a solid one towards a future where Openverse offers a space for creators to use openly-licensed content.
It’s about that time again: time to start creating the About page for WordPress 5.9.
I took a first pass on the About page using some preliminary copy that’s loosely based on the script for the recent Introducing WordPress 5.9 video. Here’s a link to this draft as a Google doc — all are welcome to view, edit, or comment there directly!
In addition to the page content, I’ve also mocked up a couple of different visual directions for the headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. artwork.
Direction 1 is inspired by jazz album covers and classic movie posters (particularly by this movie poster design by Saul Bass):
The next steps from a design POV would be to create new header artwork in whichever style we choose for the other section pages (Credits, Freedoms, and Privacy). I’d also like to look into how the chosen look & feel could potentially be utilized for the Dashboard page to help create visual consistency between the two sections.
The featured content is still TBD but hopefully this first draft can help get the conversation going! Design feedback is very much welcome at this stage — please comment on the Trac ticket with your thoughts and ideas. 🙂
This post presents an analysis that Channing Ritter and I have made of the Cover and Image blocks and offers some ideas to improve the user workflow and streamline some of the basic operations, like cropping, image placements, and rotation.
We’ll also offer an idea to integrate Fill modes into Cover blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. settings. The designs, prototypes, and an analysis of the current functionalities are available on this Figma file.
Our intention with this exploration is twofold. We’d like to:
Simplify the way Image and Cover blocks work.
Offer image editing functionalities so that users don’t need to resort to outside tools.
Before we present our designs, let’s see some of the current problems with the cropping tool.
The first one we encounter when using this tool appears right after the user clicks the crop icon. We go from this toolbar:
To this one:
We think this change is quite disorienting because the toolbar gets reorganized, adding new icons and removing the cropping and link icons in a very abrupt way. We’ll show a possible solution to this problem in a minute.
But there are some other problems with the cropping functionality. Let’s see a video of the cropping tool in action:
As you can see in the previous video:
It’s impossible to revert a change made inside the cropping mode. Clicking “apply” inside this mode essentially creates a new image and replaces the original one. This means that every time users make a change and go back to the cropping mode, they can only edit the new cropped image.
The rotation option is limited to just 90º increments.
The zoom only allows zooming in, and it only goes from 100% to 300%.
In order to zoom in, the user needs to click the crop icon.
But the main problem is that the cropping mode works in a convoluted way: instead of selecting a rectangle and extracting the content inside, the cropping tool defines a viewport (using the set “Aspect ratio”) that will be used for the crop. Users can move the image inside, but this movement is restricted to one direction and limited by the outer bounding box of the block.
Once the user applies a crop to the image, the image then expands to fill up the entire space of the block using the selected aspect ratio. This is confusing since the user sometimes interacts with a small image that suddenly grows and fills the whole block.
A solution to the problem we mentioned above about the confusing toolbar could be to use dedicated toolbars for certain groups of actions.
These new toolbars would present a title indicating that the user is now inside a different mode, the set of options for the functionality, and links to apply and discard the changes.
It could look like this:
And here’s a list of explorations we did for the placement of the elements:
We’ve created three walkthroughs that explain several aspects of our proposal:
How to integrate the cropping tool and other editing background functionalities inside the Cover block.
How different Fill Modes could work.
How could we add the cropping tool inside the Image Block.
These prototypes are self-guided, just open each of them and advance to the next slide clicking each screen. A series of notes will explain each concept.
A question we haven’t addressed on this exploration is what happens with the focal point functionality this block offers.
On the one hand, it could make sense to keep this feature, because it allows centering an image that is larger than its container. On the other hand, however, this block’s new background editing capabilities would make it very easy to enter inside the Edit background mode, reposition the image or crop it, and apply the changes.
We hope you like these explorations and help us with comments and suggestions.
FSE Outreach Program coordinator Anne McCarthy facilitated a recent call for responses (a slight change in format from the recurring FSE calls for testing) on the topic of blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. theme switching, which officially kicked off the process of “thinking long term about what folks would want to be able to have across themes.” According to Anne’s follow up summary:
When it came to ideas for how to best manage the switching process, it quickly became clear that there’s a balance to strike between not adding too much friction to the process while also offering users options to pick and choose what can come with them when they switch.
The call for replies resulted in some imaginative descriptions of how this all could work. The responses also raise some important questions: what role should themes play in the world of block themes, especially when users may want to mix & match styles and layouts from different themes? What does switching themes mean in this context, when you might be able to use aspects from several different themes?
I used some of the responses to Anne’s post as a starting point for a blue-sky exploration around what theme switching might look like in a world of highly flexible themes that — in the true spirit of WordPress — can be hacked and cobbled together to your heart’s content.
The flows shown below stem from on an ongoing series of posts by Javier Arce and I that explore the possibility of introducing a GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/-style mosaic interface across WordPress screens — including, for example, on the Appearance/Themes page. This is a thought experiment that we are excited to share more widely — please feel free to leave comments on the blog posts or message us directly in the Making WordPress Slack!
Redesign the current Live Preview theme switching flow to incorporate a process similar to multi-entity saving
Entry point: Appearance/Themes
First, I explored the most literal translation of the current theme switching flow as it exists today while incorporating the top bar and other familiar Gutenberg components.
Just like the Live Preview functionality works now, we could utilize a CustomizerCustomizerTool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.-like preview that would allow users to preview and navigate the site before activating the changes. Selections regarding which styles and layouts to activate could be made in a sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. panel, similar to the one used for multi-entity saving.
Like the current flow, the default behavior is a one-click activation that would switch styles and layouts to the new theme’s defaults (or to the user’s prior customizations of that theme’s templates, where applicable). This is based on the assumption that the majority of users will want to switch everything to the new theme’s look — but the activation panel also provides an opportunity to offer more granular selections.
We could utilize the thumbnail preview that appears within the Global Styles panel, and there could be a toggle allowing you to switch between the theme being previewed and the active theme on your site.
From there, it would be possible to drill down into more nuanced selections. For example, you might want to keep certain aspects of your active styles (e.g., just the color or typography) and have those be activated rather than the new theme’s defaults. Similar selections could be made for the layout by picking and choosing which Templates and Template parts to keep active on your site when switching.
A fun variation on this idea is to utilize a slider for comparing the before and after layouts (similar to an Image Compare block):
Make Theme management accessible directly from the Site Editor
Entry point: Global Styles panel
What if block theme switching could be integrated directly within the site editing flow? For example, a modal containing the Appearance/Themes page could be directly accessible from the Global Styles sidebar. This would allow theme switching to happen more seamlessly without ever leaving the site editor, and hopefully turn the sometimes stressful moment of theme switching into something more akin to changing settings — it’s a low effort modal to close, reopen, and keep tinkering with.
Reconceptualize themes to emphasize styles (with optional or de-emphasized Templates)
Entry point: Global Styles panel
The last idea takes inspiration from a super interesting alternate range of color schemes shipping with the upcoming Twenty Twenty-Two theme. What if changing themes was about swapping styles, withtemplate changes becoming something more seamlessly intertwined with existing editing flows? For example, maybe you could browse Template parts from other themes via the inserter or an in-canvas selector.
In this case, navigation between theme styles could happen directly from within the Global Styles panel. Utilizing the current Global Styles navigation pattern, perhaps you could drill down further to adjust and fine-tune after selecting a theme style.
While there’s a lot left unexplored in these flows, I hope these sketches can help serve as a starting point for design discussions around things we would like to see in the future of block theme switching! A great next step would be to start narrowing in on an iterative pathway towards enabling the mixing-and-matching of block themes — at the moment of the theme switch and potentially beyond.
We had our team meeting a few days ago (Oct 6) in #design on Slack. One of the topics was around the scheduling of our meetings. Currently, we do a weekly meeting with the last meeting of the month being on Zoom.
One of the agenda items for our meeting was to discuss moving to a bi-weekly schedule. Since everyone in attendance seemed to be in favor of the change we’ll be starting this new schedule immediately. Next week (Oct 13) there will be no formal meeting. Our next meeting (Oct 20) will take place at the normal time (18:00 UTC) and will be on Zoom.
While there will be less formal, synchronous time, I encourage everyone to continue to share progress, suggest issues, and ask for help in #design on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. at any time.
In addition to informal Slack chatter, there’s also some ongoing “Hallway Hangout” sessions happening throughout each week. These casual hangout sessions usually take place on Zoom and topics vary. Sometimes they are planned ahead, and other times they’re spur of the moment sessions announced in Slack.
Come join us in Slack and I hope to see you at a future meeting.
Our monthly “Show & Tell” Zoom call took place yesterday. This video chat is a place for designers to share their in-progress work and an opportunity for anyone to give feedback.
This months chat covered the following:
@karmatosed is planning to look into blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. support and will likely have a #hallway-hangout soon.
@javiarce shared his designs for background images.
If you’ve ever used WordPress to create a blog post, web page, or any other type of document, then you are likely familiar with the Inspector SidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.. The sidebar shows you information and controls related to the either the selected blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience., or the document itself.
The sidebar hasn’t changed very much over the years, and in many ways still resembles the pre-GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ (Classic) WordPress editor. Here’s a side-by-side of the sidebar in the classic and block editors:
Over on GithubGitHubGitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, there’s an overview of design updates to the sidebar. The designs focus on block controls, specifically typography, color, and dimensions. The issue does propose a component system of controls for things like inputs, dropdowns, and sliders, but doesn’t explore how this system could apply to the document controls shown above.
Since we’re talking about sidebar controls, I think it’s helpful to also include the design of the so-called “Global Styles” project outlined on Github. This design uses a multi-level, nested interface to group controls into Color, Typography, and Layout sections.
With all this in mind, I’ve been looking at the document sidebar and how it could be improved. For this first pass, I’m focused on the “Status & visibility” and “Permalink” sections. Here’s a look at the current design alongside my proposed changes:
There’s quite a few changes. The first, and maybe most obvious is the lack of an accordion interface containing all the controls. Instead, controls are shown and hidden using the ellipses menu; Open the menu and you can choose what controls are hidden or shown. This reduces the overall footprint of the controls, but also allows people to customize the sidebar to their specific needs.
This menu is also a convenient place to find features and functions like viewing the document’s history, renaming the document, reverting publish documents to draft, and moving the document to trashTrashTrash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days..
At the top of the section is the current document’s title. Here’s how that could look with a few different titles.
The title itself could also be interactive, and allow for renaming the document directly from the sidebar. This is helpful as the editor’s canvas may not always include the document title. You could initiate renaming from the ellipses menu, or double-click on the title itself.
Each control within the list would be clickable, opening a popover with more information and controls to change the value.
Here’s how each control’s popover would look:
There’s a lot more to do with the remainder of the document controls, like improving categories, tags, and the featured imageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. controls. But for now, I think this is a good start and can hopefully lead towards improvements across the rest of the document sidebar.
WordPress 5.8 (released last week 🎉) brings the power of GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ blocks to widgetWidgetA WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. areas — which means highly customizable layout and styling options, and a more WYSIWYGWhat You See Is What You GetWhat You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. editing experience. I made a test site based on oldie-but-goodie Twenty Sixteen theme, which has 3 separate widget areas to work with. In this post, I’ll highlight a few cool things that are now possible to do with your widgets, and a take a look at where things may be heading next.
Create interesting visual effects with overlapping layouts and Duotone images
Appearance-wise, users have a lot more control over widgets areas than ever before — especially through the use of blocks with tons of customization options like the Cover and Image blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.. Here’s what I’m able to create in the classic widgets editor (above) versus what I’m able to create in the new block-based widget editor (below).
Intersperse widgets and custom code throughout your visual designs
Container blocks like Cover and Columns make it really easy to weave dynamic or interactive elements into your designs. While dynamic/interactive elements are sort of a given for many types of widgets, the block versions of widgets can be easily wrapped and layered within container blocks to more fully integrate them into your layout.
In the example below, I tried placing a Search block in front of a Cover block, which creates a nice layered effect. I also tried inserting Custom HTMLHTMLHTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. blocks within a Columns block to display different messaging depending on the time of day. (jQuery script here)
Use traditional widget layouts (or not) with lots of flexibility over title and structure
Classic widgets have always had a lockup that includes a widget title. One cool thing about having blocks in widget areas is that you have complete flexibility over how titles appear. For example, you might choose to have a title over every widget, you might only want one title at the top of each widget area, or your design might not need titles at all.
Note: Some themes, like Twenty Twenty-One, are designed to flow content horizontally within widget areas. If you’re having trouble with a theme splitting your layout into columns, you could try keeping the lockup together by containing it within a Group block.
Copy & paste existing layouts from the WordPress Pattern Directory
While patterns haven’t been fully integrated into the widget editors yet, one thing you can do is copy and paste patterns from the game-changing new WordPress Pattern Directory into your site’s widget areas. I used this horizontal call to action pattern from the directory almost exactly as is, with minor color and copy adjustments:
Inserting widget patterns
There is some early discussions about how patterns can begin to be integrated into the widget editors in GitHub issue #26170. Some of the conversation has been around introducing a Patterns tab into the inserter, which would allow users to browse patterns the same way as in the post editor.
A couple of goals for introducing pattern insertion UIUIUI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. into the widget editors are:
Display patterns that make sense to use in a constrained sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. or footer area, depending on the type of widget area being edited.
Surface patterns in a extra discoverable way for users (including classic widget users who want to quickly recreate a traditional layout).
Based on this, I’ve been exploring ways that patterns could be surfaced in the quick inserter as a default/resting state as soon as the popover is opened:
How would you like to see patterns incorporated into the new block-based widget editors? Join the discussion by opening a new issue on GitHub or commenting below!
Welcome to a new installment of the series where I look at the current state of GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ blocks and propose improvements.
In my previous post, I talked about the Table blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.. This time I’ll be discussing another important component: the Search block.
Since search is a central activity for blogs and other sites that index content, it’s essential to give users the ability to customize the appearance of their search bars so that they don’t look alien or feel disconnected from the design of their sites.
The Search block options are pretty limited at the moment, and the block can only offer a short range of styles. The good news is that just by adding a small group of settings (many of which already exist for other blocks), users will be able to customize their search boxes in many different ways:
With that in mind, let’s have a look at this block.
The current toolbar has three main buttons that perform the following actions:
Showing and hiding the search label.
Changing the position of the search button (outside, inside, or no button).
Toggling between a search button with text or an icon.
To be more consistent with the way other blocks present the options and also to simplify the toolbar, we could move the second and third buttons (“Change button position” and “Use the button with icon”) from the toolbar to the sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.. In the case of “Use button with icon”, I think this is not a primary action, and also the icon itself doesn’t convey the actual operation behind the button.
We could also add a setting to modify the alignment of the text inside the input field and the position of the text button. Controlling the alignment would allow users to create bars like these ones:
For languages that use right to left scripts like Arabic, Hebrew, or Urdu, we automatically switch the alignment of the text and the position of the search button.
To allow having styles that use the writing direction defined by the language, we could offer four alignment options:
Default (it uses the direction of the selected language)
The last three options would overwrite the direction defined by the selected language.
Let’s review how the sidebar could look like and the sections that it would include:
When users add a new search bar, they’ll get the default setting (Button outside), but will have the other styles visible on their sidebars for a quick switch.
This section would allow adjusting the general width of the block (a feature that is currently present) and also toggling the following settings:
The icon inside the search input.
The icon inside the search button.
Here is a list of variations that those two settings would produce:
In this section, users could change the padding of the item and also affect the spacing (the distance between the button and the input field).
There’s an interesting conversation around contextual padding controls in this GitHub issue, which could probably be applied to this block.
Depending on the style (button outside or button inside) the padding could behave differently:
If the style button outside is selected, the padding will affect both the input field and the button.
If the style button inside is selected, the padding will affect the outermost element.
The spacing setting could also be adjusted using a handle in the block itself. The control between the input field and the button would change the spacing, whereas the control in the button would allow resizing the whole block (which is the current behaviour).
I think we should allow users to modify the border of the input field and the button independently for each of the four sides. That would give them great control to create different styles. For instance, they could create search bars with just a bottom border.
There’s an open PR that deals with border color support and border style here.
Depending on what element is selected, the typography section would affect the font and style of the input field, the text button, or the label.
Like in the typography section, this one would affect the text and background colors of both the input and the button (again, depending on the selection).
As I mentioned at the beginning of this post, if we implement these changes, users will be able to customize their search bars in many different and exciting ways and have more control over the design of their sites.
Drag and drop is known for being one of the most intuitive interaction patterns there is. One behavior that users might expect to find in GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ is the ability to create side-by-side images by dragging and dropping an image next to an existing one.
Note: This behavior has previously been explored in GitHubGitHubGitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue #13202 and perhaps elsewhere!
The Current Behavior
Right now in Gutenberg, you can drag an image on top of an existing Image blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience., which will upload the new image and replace the current one. The drop zone covers the full area of the block and is indicated by a blue overlay color with a CTA.
Image block and Gallery block with drop zone overlay shown at 75% opacity.
The drop zone looks exactly the same on the Gallery block, covering the full area of the block, but the behavior is slightly different there. Instead of replacing, the new image is added to the gallery.
The current overlay behavior works great for each of these singular interactions. The key design challenge is finding a way to offer both options so that a user can replace an image or add another image within a single drag motion.
Transforming an Image block into a Gallery block
The blue overlay color could be reserved for replacing an image, with a new treatment introduced for transforming the Image block into a Gallery block to achieve a side-by-side effect. I used a 4px vertical line to indicate the position of the new image — this is the same visual treatment used for the “move to” indicator (but I can also see a conceptual argument for using a 1px line like the sibling inserter).
We could show a snack bar after the user completes the transform via drag and drop, as it’s not explicitly clear that this action will change the block type. A snack bar offers the opportunity to undo the transform, and could also be a way to call more attention to the new block type through the use of a block icon.
Adding and replacing images in the Gallery block
It would be nice to extend the same behavior to the Gallery block so that a user can seamlessly go from one image to two images, and from two images to three images, using the exact same interaction pattern. This could be a part of larger efforts to unify the Image block and Gallery block more closely.
I imagine this could work by identifying separate drag zones within the area of the existing image for replacing/transforming but it would be helpful to play around with this in a PR to see what feels right.
Another option that would introduce slightly more friction to this interaction would be for the transform-related drop zones to only “unlock” after a long hover over the area. In this scenario, a quick drag and drop would always default to an image replacement with a longer hover opening up additional options (but I think the simpler interaction described above is closer to the expected behavior).
Use drag and drop to transform an Image block → Gallery block #32819
Unify drag and drop behavior across Image block and Gallery block #32820
Please feel free to leave a comment below or drop a message in the #design channel on the Making WordPress SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. Looking forward to hearing your feedback, thanks for reading!