Site editing IA concepts: How to surface and access new features

Co-wrote (and designed) with @jameskoster.

We are at a point in the GutenbergGutenberg The 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/ development where we have many new features to help people visually create, edit, and manage their site. These include, but are not limited to:

• Pages & posts: Add and edit with blocks and patterns.
• Template editing: the ability to customise theme templates, and create new templates ad hoc.
• Styles: change the color, fonts, and layout across your site.
• Template parts: Create and edit headers, footers, and other areas.

More features continue to be added and @jameskoster and I have been iterating on how we can surface these new features in a way that is both intuitive for new users and familiar to existing users. To keep the scope focused, we looked at the features in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. today along with the ones that are being worked on to be considered for the 5.9 version of WP, according to this post while keeping the near future in mind as well.

To set some context

If you are already using the Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, you may be familiar with the Site Editor menu item. This is where most of these new features can be found during development. While this works for the purpose of development, “Site Editing” is a broad expression that essentially spans the entirety of site management activities in WordPress. Do we want to begin down this path towards a single page app-like experience, or would it be better to keep things separate for now? It’s time to explore and design the IA (information architecture) so that we can begin to paint a picture of how we might merge this exciting functionality in to core.

Idea: Appearance Menu

Try the prototype out here or scroll through a description of it below:

Click on Appearance and you see Editor (beta) menu item. This keeps the concept of updating your look and feel of your site within the Appearance menu item, where current users are used to going to Customize. It is also intuitive for new users and matches the iterative approach product development has taken.

From there, you are brought to the homepage of your site, where you can immediately start to edit it – whether its a static page or your latest posts. Example of the latter: 

From here, if you click on the W menu in the upper left corner, it opens a menu where you would be able to access Styles and Templates. And if you have any – other template parts. This navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site. feels light right now but as more functionality gets added, this navigation could scale and grow along side it. For example, you can imagine that you’d have direct access to editing your posts and pages within here as well.

Click on Styles to update the colors, typography, and layout of your site. This also shows what a welcome guide could look like, which could be useful for big new features.

If you open the W menu again and click on Templates, you’ll view a list of all the templates you can now edit visually: 

Idea: Separate

Try the prototype here or scroll through a description of it below:

An alternative concept would be to keep template and content editing separate for now, but still bring some of the most compelling template editing functionality (like direct manipulation of headers and footers) to the post editor.

With this approach you’d edit posts and pages the way you always have, but when you open the editor there would a new option to view the full layout:

With the layout visible it becomes possible to customize the site headerHeader The 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., footer, and any other blocks that make up the underlying template. You would also be able to invoke the Styles panel to further refine the look and feel of your site.

Theme editing has always lived in the Appearance section of the navigation, so in this concept that is where you’d go to customise and create new templates.

Template editing can be a complex exercise, so to help narrow the scope this concept keeps content and template editing separate. So instead of being populated by actual content, blocks like Post Title and Post Content display simple placeholders to help you identify them.

In the future it would be interesting to explore options that enable users to load compatible content in to the template while editing to help with testing, but it’s not essential at this stage.

One trade-off with this approach is that in order to allow users to visually edit their home page when it is set to display latest posts, we’d need to introduce a placeholder “page” in the pages list:

This somewhat breaks the idea of keeping content and template editing separate, since visiting the latest posts “page” (and the “Posts page” for that matter) on the frontend will resolve to display the home or index template. Whether this trade-off is worth making may require further technical investigation and perhaps a round of usability testing, but it’s worth noting that a similar placeholder is already utilised when you create a “Posts page” in partnership with a static home page.

---

Curious to hear your thoughts on these ideas and alternative proposals!