Bonjour, Nouveau – An introduction to the next template packs

The bp-nouveau team has spent more than a year working on the new template pack. As someone who hasn’t been deeply involved in the project, I wasn’t sure how to get the kind of high-level view needed to assess why a new template pack – and Nouveau in particular – is needed. So I figured I’d do some research and write up my findings, in the form of a pitch: Here are the problems that Nouveau aims to solve, and here’s how it solves them. With Hugo’s help, I’ve done just that. I hope this’ll be a helpful tool for the larger BP community to understand and to get excited about Nouveau.

The state of BuddyPress templating

One of the marquee features of BuddyPress 1.2 (alongside the Activity component and single-WP support!) was the new BuddyPress Default theme. The year was 2010, a time fondly recalled by lovers of jQuery-powered animations and background gradients. BuddyPress 1.7, released in 2013, boasted theme compatibility: headers, footers, and other boilerplate was to be provided by regular WordPress themes, while BP-specific markup was provided by a set of templates bundled with BuddyPress. The templates were called bp-legacy, indicating that they were derived about 90% from the older bp-default, and with a nod toward a future where bp-legacy was, in fact, relegated to legacy status.

That future has arrived more slowly than one might have hoped. Designing and building a new set of templates that’s worth shipping means revisiting BuddyPress with a fresh set of eyes – from the perspective of both users and developers. Given what we know about the social web in 2017, and given the nature of the sites that we know are built using BuddyPress, how best can we present BP-generated content like groups and profiles? Given the last seven years’ experience customizing and maintaining BP-powered sites, what have we learned about the features of template markup, CSS, and JavaScript that strike a balance between simplicity and ease of customization?

Bienvenue Nouveau

The BP Nouveau project attempts to address this problem with a new template pack meant to replay bp-legacy as the new default for BuddyPress installations. Nouveau has been written from scratch, to reflect modern aesthetics and conventions. Let’s look at some notable features of Nouveau, and the thought behind them.

Developer-facing and technical improvements

Modular, modern JavaScript
The problem: bp-legacy’s monster global.js file determines nearly all front-end functionality for BuddyPress. The single file makes it extremely difficult to override or modify individual bits of functionality. And the code itself is the result of 7+ years of accreted jQuery-based spaghetti, which has proved to be somewhat fragile and difficult to maintain.Nouveau’s solution:
1. The theme JS has been completely rewritten. Component-specific functionality is split into separate files: https://github.com/buddypress/next-template-packs/tree/master/bp-templates/bp-nouveau/js
2. Nouveau heavily leverages Underscore.js and Backbone. Backbone, which is designed to work with data collections, is a natural match for BP interfaces like the activity stream and the message inbox. These libraries are widely used in the WordPress Dashboard, making the technology familiar to WP developers.
Markup built for the contemporary web
The problem: Most of bp-legacy’s markup predates the conventions of modern site building. HTML5 conventions and accessibility features have been tacked on rather than part of the initial design. Conventions like CSS selectors have not been consistent through the history of the project, causing conflicts with other applications.Nouveau’s solution:
1. Markup has been rewritten to conform to semantic best practices, including proper element and selector use.
2. Accessibility and compatibility with modern/mobile browsers is taken into account.
3. Naming conventions are more consistent across templates.
More minimal styling for better theme compatibility
The problem: When bp-legacy was first conceived, it inherited all the highly opinionated styles of bp-default. Through a concerted effort, bp-legacy themes were “anonymized” over the course of several releases, so that fonts, form styling, and other conventions would be inherited from the WP theme. But the nature of bp-legacy’s markup and styles meant that a significant amount of additional styling was needed to fit nicely into WordPress’s default Twenty themes.Nouveau’s solution: The improved markup and styling has been written with an eye to universality. Elements are designed in such a way that they more elegantly inherit styles from the theme. This reduces the need for custom stylesheets when embedding in an existing theme, and reduces – or perhaps eliminates – the footprint of “companion stylesheets” in BuddyPress itself.
More consistent and flexible PHP template functions

The bp-legacy templates have evolved numerous techniques for adding navigation and action items that are often clever but also quite inconsistent. Some elements are invoked from directly within templates, while others are added via action hook. Some template functions make hard assumptions about the output, while others offer flexible parameters.Nouveau attempts to smooth these differences by introducing new template functions aimed at providing the greatest amount of flexibility for theme developers. Functions like bp_nouveau_activity_entry_buttons() and bp_nouveau_activity_comment_buttons() have rich function signatures and robust filters to allow for maximal control over these types of elements.

User-facing and front-end improvements

Customizer compatibility
The problem: bp-legacy predates the Customizer, so that any theme modifications had to be hardcoded in child themes, requiring a WP developer – or at least CSS knowledge – to make minor modifications.Nouveau’s solution: The behavior of a Nouveau-powered site can be modified extensively via the Customizer, including group/member front pages, the order of nav items, and one/two column layout selection. The integration provides a framework for more extensive Customizer functionality in future versions of BuddyPress.
Better differentiation of content types
The problem: bp-default and bp-legacy used mostly identical markup, styling, and design for different content types. Group directories and profiles looked exactly like member directories and profiles, and so on. This similarity leads to a tendency for confusion when new users approach BP, and it makes BP-powered sites feel less engaging and exciting by blending together fundamentally dissimilar types of content.Nouveau’s solution: Using the Customizer, site admins can select between various built-in layouts for content directories. For example, group directories might be distinguished from member directories by the former to a two-column layout but the latter to one-column.
A rethought Messages component
The problem: bp-default’s Messages interface felt like an afterthought, a tool for sending private messages that is somewhat slow and difficult to use.Nouveau’s solution: The Messages interface has been totally redesigned, leveraging Backbone and other JS technologies to feel more like a fast, highly responsive single-page app.

The future of Nouveau and bp-legacy

The current proposal is to merge Nouveau into BuddyPress. New installations of BP will have Nouveau activated by default. Upgrading installations of BP upgrading to will keep bp-legacy. A new admin tab will provide site admins with a UI for toggling between the two template packs.

Bp-legacy will continue to be actively maintained for at least a few more major releases. At some point in the upcoming six months, we’ll come up with a phased deprecation plan, describing a set of dates when bp-legacy will no longer receive new features, will no longer receive minor bug fixes, and so on.

#bp-nouveau

hnla 4:36 pm on April 12, 2017

@boone Many thanks for a studied and great overview, it succinctly puts the case for Nouveau, and I hope helps others to understand the benefits.
buddycore 6:47 pm on April 12, 2017

Look forward to delving in, brilliant post.
Brajesh 4:49 am on April 13, 2017

Thank you for sharing the details Boone. It is a great step to move forward but I have some inhibitions on the use of the backbone.js.

Even though it is used in WordPress, it is only used in some of the functionality in the backend. Adding a large framework like backbone on front end is not a good idea. As far as features are concerned, Vue suits BuddyPress use case better with lower size.

As far as jQuery goes, It is so pervasive that it will be loaded most of the time whether you use it or not in the theme. Using it in the theme helps us avoid the extra file load.
Backbone code is way more verbose than vue, if we are changing the framework, It should be certainly reconsidered. Not everyone who works with WordPress works with Backbone.js. The learning curve for backbone is much higher than some of the comparable frameworks.

In my personal view, I believe It will either create more copy/paste developers for BuddyPress or create a higher barrier for the entry of new theme developers. The goal should be to allow theme developers flexibility instead of going the early bootstrap ways(where all the bootstrap sites looked the same).
There is no issue in providing alternative templates if they provide better experience(and this pack indeed does), but forcing to use it and loading the extra js framework in the default core is not justified yet. The framework size is one of the reasons why I have been avoiding react powered plugins on WordPress sites. It is good to use a framework when you have the complete control, but that is not the case with most of the WordPress sites.
- hnla 7:09 am on April 18, 2017
  
  Hi Brajesh, you make some very good points here, that we need to consider.
- Boone B Gorges 6:46 pm on April 26, 2017
  
  Hi Brajesh – Thanks for the thoughtful comments.
  
  Your comment makes two related points, which I think are worth separating.
  
  First, you suggest that Backbone is inferior to some other similar libraries. You say that Backbone is “large”, but this needs some more clarification. In terms of file size, Backbone + Underscore, minified, is a much smaller download than Vue (which itself is much, much smaller than React). Arguments about file size, performance, etc would benefit from benchmarks.
  
  I think by “large” you probably mean something more like: more boilerplate is required (more “verbose”, as you put it). But, having spent a decent amount of time building in Vue, I’m not certain that this is objectively the case. Seeing a proof-of-concept here would be helpful: a smallish bit of Nouveau functionality built in Vue, which can be compared side-by-side with the corresponding Backbone implementation.
  
  The second point that I read in your comment is that Nouveau risks introducing confusion on behalf of site implementers and developers – more “copy and paste”. I agree, and I take this point to heart. But IMO this will be a result of moving to *any* declarative JS framework. So the question here is not whether Backbone is better than Vue (or whatever), but whether the trade-offs of a more maintainable, more modern, more testable, more concise front-end architecture are worth the potential trade-off of raising the barrier to entry for new developers. I think there are reasonable arguments on both sides of this question, and it may be healthy to have a larger conversation about them, but I feel that the benefits of a more modern framework far outweigh the downsides.
  
  Given the state of the Nouveau project, we also have to ask practical questions. The Nouveau we currently have is largely built using Backbone. In some abstract sense, one might argue that some other framework (or none at all) would’ve been better in certain ways. But the template we actually have is Nouveau. If someone – ahem 😉 – is stepping forward to do a rewrite, then it’s worth considering. Otherwise, absent some convincing argument that the current strategy is going to be more detrimental than not launching Nouveau at all, I don’t see that we have the option to change our JS strategy in a major way.
  
  To put the issue in some perspective, I’m hopeful that our ongoing work on BP’s internals, and especially the REST API, will make it easier to develop custom front-ends using modern frameworks. This should mean that Nouveau is state-of-the-art for a year or two, rather than for eight years, as in the case of bp-default. We can take the lessons learned during this process and apply them to whatever comes next.
Henry Wright 3:47 pm on April 18, 2017

Thanks for the write up Boone and Hugo, this looks like it’s going to be a huge hit when it drops in a future BP version.
Prometheus Fire 4:18 pm on April 18, 2017

This is nice and I’m eager to see how this develops further. There are some nice things being done here and this sounds like a very nice flagship update for BP. Thanks for all the hard work that you guys are doing here.
Pingback: Dev Chat Summaries for April 5 & 12, 2017 | BuddyPress Dev Updates