Skip to content
This repository has been archived by the owner. It is now read-only.

Replace panels with menu-based front page content #62

Conversation

@celloexpressions
Copy link
Contributor

commented Sep 12, 2016

This is a rough first pass and needs design work. Pieces could potentially move into
core, particularly the nav menu walker. This also strips part of the old
approach, but we'll need significant cleanup and refactoring if we go
this route. I'll make a demo video tomorrow to illustrate the UX of this approach and the benefits of it.

We would also be able to build numerous enhancements off of this, such as selective refresh support, configuration options for the way each item displays, and UX improvements to explain how it works.

Rough first pass, needs design work. Pieces could potentially move into
core, particularly the nav menu walker. This also strips part of the old
approach, but we'll need significant cleanup and refactoring if we go
this route.
@melchoyce

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2016

Anyone with more GitHub experience know if when we merge, there's any way to put this into a new branch? That'll make it easier to test against the existing system.

@westonruter

This comment has been minimized.

Copy link
Member

commented Sep 12, 2016

Create a new branch off of master and then you can reassign this PR to be merged into that branch. This is a new capability in on GitHub. See https://github.com/blog/2224-change-the-base-branch-of-a-pull-request

@celloexpressions

This comment has been minimized.

Copy link
Contributor Author

commented Sep 12, 2016

Procrastinating... so here's a demo of this:

twentyseventeen-front-content-demo

Once the additional enhancements noted above are in place and the theme design is in place, this approach offers a lot of flexibility without introducing a brand new core UI. We can also go back to an ideal design and look at where we can extend the approach to add additional fields/settings where needed.

@WPDevHQ

This comment has been minimized.

Copy link

commented Sep 12, 2016

This is a much better approach than panels.

Opens up a whole new world for front page workflow.

@bappi

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2016

Looks amazing!

@samikeijonen

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2016

I like this approach. But could we just use WP_Query like explained in WP Theming article?

@grappler

This comment has been minimized.

Copy link
Member

commented Sep 12, 2016

The idea is great. I have reservations as I think that users will get confused how come the front page is a big menu. Another problem is that there is no way have additional options. The customizer is currently lacking in hooks to extend the menu or page meta to add things like page background etc.

@celloexpressions

This comment has been minimized.

Copy link
Contributor Author

commented Sep 12, 2016

I didn't put it in this initial pass, but we can use a fallback for the menus that displays help text in the customizer preview explaining how to show more content here, or to assign an empty menu to hide the notice (which would only be shown if is_customize_preview anyway).

For additional options, everything in the mockups for Twenty Seventeen can be supported with the menu item title, menu item description (sidebar pullquote/whatever content), and post featured image and content. I forgot that posts are shown as an example there via recent news - what about using a grid of the post images (if they have them) for the large image above them, then showing the individual titles and excerpts in the list as the mockups show @melchoyce? Services could also be a term, either pulling from posts, or a custom post type.

There is https://core.trac.wordpress.org/ticket/18584 for additional menu item fields, which could be used for additional per-item options in the future. Additional options that apply to all content here can (and probably should as they're theme-specific) live separately in a customizer section.

@WPDevHQ

This comment has been minimized.

Copy link

commented Sep 12, 2016

I've applied this patch here: http://www.wpdevhq.com/seventeen/ and it works as intended inline with the original design screenshots.

Can you explain this a little more please:

@todo design the different template part used here, for a grid view. This will probably show the featured image with the title and link them.

Is this intended to be part of the front page workflow or will it be added as a layout option and left as optional for child themers to implement?

@georgeolaru

This comment has been minimized.

Copy link

commented Sep 13, 2016

@celloexpressions great job with the prototype! I would not mix the "Menus" section and locations with the "Multi-Pages" section — instead, it would be great if we can offer a solution to make those "Multi-Pages" available through the standard Menus system and the "Front Page" selector.

@LittleBigThing

This comment has been minimized.

Copy link

commented Sep 13, 2016

Great idea, thanks @celloexpressions! Would it be possible to have a separate panel (e.g. Front page) with similar functionalities, but all streamlined for the homepage as suggested by @georgeolaru?

I suppose that we couldn't support all menu types like custom links, categories, tags and other taxonomies.

Recent posts would be cool (for example latest 2, 3 or 4 posts in a grid), but that could be based on the page that is selected to display posts as in themes like Pique.

@melchoyce

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

Using the menu paradigm for multi-panel pages is growing on me. That said, I wouldn't actually put them into the Menus panel — I don't think we should be mixing navigation and layout like that. It gets extra confusing because some of the menu options don't apply. Can we pull it out into its own Customizer panel?

@ianstewart

This comment has been minimized.

Copy link

commented Sep 13, 2016

+1 to Mel's comment there. It sums up my first reaction of, "Huh, this looks really cool and easy to use — but likely really confusing inside the menu panel."

@melchoyce

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

I forgot that posts are shown as an example there via recent news - what about using a grid of the post images (if they have them) for the large image above them, then showing the individual titles and excerpts in the list as the mockups show @melchoyce?

A standard grid of posts would be great for some themes, but in Twenty Seventeen's case I'd like to match the mockup and go vertical, one column.

Aside: it might be nice to include an option inside of the panel items to hide/show featured image, title, and excerpt, like Content Options.

Services could also be a term, either pulling from posts, or a custom post type.

I can see that working in general for this feature, but for the purposes of default Twenty Seventeen, the mockup is just showing plain page content. I don't think we should be shipping CPTs with a default theme.

@melchoyce

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

Sketching out some ideas...

img_6268

@georgeolaru

This comment has been minimized.

Copy link

commented Sep 13, 2016

@melchoyce @ianstewart I think the current @celloexpressions implementation was only to prove the concept. I posted a (visual) prototype on Trac which I think it would make more sense (moved everything in a new section and get rid of the standard menu options):
multi-pages--prototype

If we're going this way, there is one disadvantage over the Child-Pages System: the pages will not be organized in a hierarchical way in the admin, so you can easily see which panel belongs to the other, and they can easily mix as they are ordered by date. The only easy way to edit those pages would be only through the Customizer.
child-pages-hierarchy

Not sure if there is a simple solution to this, or we just need to make a compromise.

@mor10

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

Yes to using the established visual language and UI of the menu system (though expanded for this feature. The user flow of the menu feature is well established and understood by users, and has the core features we need. For this new functionality we should borrow and steal what's in the menu section and extend it for the "multi/mixed-content" feature.

@davidakennedy

This comment has been minimized.

Copy link
Collaborator

commented Sep 13, 2016

This looks really good, and I like the exploration. Like others, I have concerns about multi-page content being in the Menus panel.

I'd be afraid that users would get mixed up because that becomes a place where they manage both menus and content/layout, which are very different. I think it's good to use an interface users are familiar with, but having it within Menus could create the same issue that widgets have. They can be both very empowering and very confusing at the same time.

@mor10

This comment has been minimized.

Copy link
Contributor

commented Sep 14, 2016

Looking at this again, I would think this functionality is an ideal candidate for a core plugin. Having this ability in core will provide a native solution to a problem theme and plugin developers are currently creating all sorts of weird solutions for. Standardizing multi-content page building will ensure consistent behavior across themes, allow more themes to provide this feature out of the box, and (I assume) open new opportunities for themes and plugins that already offer some sort of multi-content / page builder functionality.

Just a thought.

@celloexpressions

This comment has been minimized.

Copy link
Contributor Author

commented Sep 14, 2016

@melchoyce for the multi-post items such as news, should the image above it pull from the most recent post with a featured image then?

The content options options generally make sense if the theme wants to support them, so the theme could add options like that in a separate section and apply them to all of the front page content. For example, it may make sense to provide a "full content" vs. "excerpt with read more links" option for single post objects, with multi-post objects always showing linked excerpts.

We can add support for recent posts (of a given type) by adding support for post type archives to the custom nav menu walker. That plus term support and single post support means users should be able to select exactly what they want here. With respect to custom post types the theme definitely wouldn't include anything, but this approach means that when plugins add custom types their content can easily be featured via this same UI. And this approach would be easy to leverage in other themes with full data portability via the menu.

I know that it would probably be better if this weren't located in menus and didn't say "menus" and have all of the associated menu fields. However, if we start going down that route, we are extremely unlikely to have something viable for 4.7. The underlying functionality for menus should be able to be extended in the customizer with new object making use of a similar UI, somewhat hackily and with someone taking a deep dive into the way menus work in the customizer. But once we start breaking out an entirely new feature, we also need to decide how the data storage scheme should be managed (the same as, or different from menus, possibly a taxonomy without the duplicated post type?). If we do that we need to develop a robust system for themes to use it on one or multiple pages, develop new terminology and core content structure concepts, and build out the corresponding UI.

Bringing menus into the customizer was a rigorous 18-month process, and we already had an existing core paradigm to work with. Developing something entirely new, even if based on menus, is not something that we should attempt to do in one release. Core is more likely to get stuck with something that we regret doing and are stuck maintaining forever. Making this type of a change to core is making the final decision that content should be pulled from post and term objects to build multi-content pages, complicating the potential to explore other ideas such as content blocks in the future. By keeping it theme-specific, and perhaps improving core support for themes doing this by adding the main functionality (the custom nav menu walker) to core, we can have a solid interim solution that core suggests as a possible solution while a larger process is undertaken to develop the ideal permanent approach to be taken in core. That would also give us Twenty Seventeen and other themes using this approach as a real-world trial of this idea before core commits to it forever. During this stage, we would need to compromise and keep it as an actual menu.

There are still ways to make the UX better if it is an actual menu. We can make liberal use of deep-linking and add buttons/links in all of the relevant places (such as the static front page section, and a placeholder within the preview). Those deep links could open up to the menu set to the location, or even create a new menu and assign it to the location, before opening the menu section to edit. We could even fake a top-level section that actually focuses the appropriate menu section if we really wanted to, but they'd exit out through menus and at a certain point we'd need to show users that that's where it is. We could look into preventing submenus on menus assigned to locations with only one level of depth supported. Menus aren't necessarily restricted to navigation, and in a lot of cases the way this homepage content is shown could be considered navigation, with the addition of excerpts and imagery. Menu item descriptions actually contained the excerpt of the associated post by default at one point.

I bring this up because we need to be mindful of future-compat and work within reasonable limitations with respect to what's feasible in core given our timeline. I'm sure that we can come up with ways to optimize the experience within those constraints, and user testing will help determine exactly where we can improve the workflow.

@LittleBigThing

This comment has been minimized.

Copy link

commented Sep 14, 2016

Suppose it would remain 'menu-like' for this theme. The 'page building' could be limited to the front page and a(n optional) scroll navigation could be added automatically when adding pages/sections (a one pager).
Wouldn't this make the experience - building the front page like menu's - more logical and maybe acceptable?

@joyously

This comment has been minimized.

Copy link

commented Sep 14, 2016

I'm having trouble understanding what the point of this is. The user can already put whatever they want into a static page and designate that as the front page. There is already a system in place for putting dynamic content into widget areas. Are you suggesting that this theme's front page is one big widget area? Why do we need new interfaces for that?
I would rather see some innovation in how taxonomies are presented, such as a category page that shows all the subcategories instead of just posts. This concept could be used similarly in the front page.

@BharatKaravadra

This comment has been minimized.

Copy link

commented Sep 15, 2016

There is a part of me that likes as many "gadgets" in the admin of a theme to help make the layout of media elements easier, and there is a part that also agrees with @joyously in that development time could be better used in other areas for which I cannot present an example at the moment.

The customizer seems to be a "visual editor" for the theme, albeit a simple on at the moment. Hence, unless the ability to customise layout is not possible or very difficult in the content editor, I again agree with @joyously in that time would better spent elsewhere.

Perhaps the customiser could be a forked project, sort of separate to the Core and the Theme, and a team and priorities could be assigned to that.

Anyway, enough from me on this as I am not part of official WordPress / Automattic, and it may be that these sort of decisions are best made by Theme and WordPress Core teams.

@karmatosed

This comment has been minimized.

Copy link
Member

commented Sep 23, 2016

I've been considering this a lot and will say firstly, we have to super careful about where we do discussions. I have personally been following:

https://core.trac.wordpress.org/ticket/37974

That has a rather confusing gif to demonstrate this from you @celloexpressions - I have no clue why you are linking the live preview there sorry. Only by coming over here did I gain more context. It also means that I was somewhat out of the loop. This conversation is important outside this theme so should continue on that trac ideally. Our point wasn't to just fix one theme but to find a method we add for all.

To that point, I see how people are leaning towards the menu interface. I caution on using something hidden within something that has a model of behaviour already. Menus are well menus, not panel builders or page content builders. That's perhaps why using the UI but not in the context of menus makes far more UX sense. Remember what we think works is influenced by our normal, not the user normal - we are not users.

I am very concerned with us shipping something that causes issues just to ship within date. If that's the case we should absolutely keep the panel approach we have as an option. It works, it has strong user testing behind it and changing it makes no sense just to do. We can't have release date and just shipping as an argument to do something as impactful as this.

That all said. I feel we need to user test benchmark the 3 leading options of doing this. I am aware to that to this for one may need a patch we do not have, lets discuss how we do that.

  • Menus in menus being used unlike menus but as panel builder
  • Menu UI being used outside as panel builder
  • Existing option panel builder

We should test exactly the same script for all and focus on discoverability. Without this we can't and shouldn't proclaim one method as better than the one we have with solid user testing already.

I also urge us to take this discussion back to trac, otherwise we aren't getting the eyeballs and input we should for this. To that point I've linked this discussion in trac. Lets keep it in one place. This duo place and fragmented discussion hurt my head which makes me think who else it confused. Even in trying to work it out, my responses were confused to other people. It's complicated but lets try and make it at least make sense.

@davidakennedy

This comment has been minimized.

Copy link
Collaborator

commented Sep 23, 2016

Lots of awesome work and ideas have been done here. Thank you, everyone!

In today's weekly meeting for Twenty Seventeen, the group decided to make #37974 the master ticket for making it easier to create a custom home page full of content from different sources.

See: https://make.wordpress.org/core/2016/09/23/twenty-seventeen-meeting-notes-sept-23-2016/

So let's move all discussion around there. That way, more people see it and we can focus and find the best solution.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.