Categories
Religion

SantaGate

There’s an important conversation about Xmas happening in the open-source community right now.

VS Code (a very popular code editor made by Microsoft) received a festive beta update, in which the Settings icon was adorned with a Santa hat. Shortly after, a GitHub issue was opened describing the symbol as “very offensive”, and the Santa hat was promptly removed.

There’s a great write up on the community backlash to this decision, and Microsoft’s response, on Visual Studio Magazine. I wanted to step into the conversation with my Jewish perspective.

Important note: My particular take on this, especially toward the end, differs from mainstream Judaism. Which should be unsurprising. If there’s one thing Jews can agree on its that we don’t agree.

The Ghost of Xmas Past

You might have noticed that Jews tend to prefer the styling “Xmas” to “Christmas”. That’s because for us, the “Christ” part of Christmas is closely associated with violent anti-Semitism.

For many Jews, Santa is a modern day representation of Saint Nicholas – an icon, and reminder, of Christianity.

I won’t go into detail here (Sefaria has a great writeup on Christian anti-Semitism), except to say that we’ve suffered Crusades, pogroms, the Inquisition, blood libels, forced conversions, and the Holocaust – all in the name of Christ.

So, of course, when we see a hat synonymous with Christmas, we make a connection with that traumatic history.

To me, Santa’s uniform isn’t anywhere near as offensive as a swastika, but it’s on the same spectrum.

I don’t want to dwell on this, though. It’s what we call p’shat – the plain sense of things. There’s another layer that I think could be helpful to unpack.

Downward Pressure

Another aspect of the Jewish relationship with Xmas is the idea of living as a minority within a dominant culture.

As Jews in the West, we see Xmas everywhere at this time of year. It’s impossible to avoid. Our kids are taught Xmas songs in school and we are bombarded with Xmas trees and Santas while grocery shopping.

Nobody complains about this, it’s just part of living in the West. In fact, Jews are better off in the West than anywhere else in the world we’ve tried to call home (outside of Israel). We love it here!

But when thinking about embracing our own culture, and passing it on to our children, there is a very real challenge to “rise above” the dominant culture that surrounds us.

We try to make Chanukah even more fun and exciting. For example, Chanukah never included presents until it started competing with Xmas (now we have 8 nights of presents!).

If we don’t make an effort, Chanukah would be drowned out in the noise of Xmas. It’s this constant downward pressure from the dominant culture that can cause frustration and angst, and maybe even result in an anti-Santa GitHub issue.

Quick aside: The Chanukah story – the story of the Maccabees – is all about a Jewish minority fighting against the dominant culture.

Against Insularity

One way that Jewish communities protect their Chanukiot (Chanukah menorahs) from being out-shined by Xmas lights is by retreating into private communities. We send our kids to Jewish schools, eat in Jewish restaurants, arrange Jewish marriages, and try to have as little to do with non-Jews as possible.

This strategy has worked great so far. There aren’t very many cultures around today as ancient as ours (though there are a few).

I have to wonder, though, whether our insularity might have nudged our neighbours a little in the direction of jingoism.

My kids don’t go to a Jewish school. This means that my wife and I have to make a huge effort at home to teach them about Jewish culture, history, language, art, and tradition.

But it also means that every other kid at their school knows a Jew.

Personal story time: I cried during school assembly this year.

Instead of an Xmas carol, my son’s entire class sang I have a little dreidel. They all learned a few Hebrew letters and the Chanukah story. How can anyone harbour anti-Semitic hatred after embracing their Jewish friend like that?

It’s become glaringly obvious to me that the pathway to peace is integration, not insularity.¹

Techno-Optimism

The progressivism² at play – both at our school and in the VS Code Github repo – has become the norm in tech communities. Microsoft recognised their mistake, and rather than ignore it (or worse cry war on christmas), they fixed it and apologised.

I don’t think that would have happened when I was a kid. Maybe not even 10 years ago. We’re living in a moment where the world is expected to not only “cater for”, but embrace the needs and nuances of minorities³.

And credit where credit’s due – we wouldn’t be here without LGBTQ activists, Me Too, and Black Twitter.

We have, at times, overbalanced. There have been extreme cases of call-out and cancel culture that caused more harm than good. But there’s something profoundly good at the heart of this simple idea which (I hope) has finally begun to sink in:

Do to others as you would have them do to you.


1. Integration is not the same thing as assimilation. As Jews, we have a G-d given mandate to be uniquely “separate”. I’m talking about rainbow, not beige.

2. I like to thing of it as “Anti-Otherising” – making a concerted effort to make outsiders feel welcome. I don’t know of a better word, though.

3. Again – my lack of adequate language is at play here. My intention is to include the momentum of feminism in this, though women are not a minority. The term “under-privileged” doesn’t work here either, because Jews are very privileged. Jews (especially Ashkenazim) sit in a very difficult to describe place – to the far right we’re wolves in white skin, but to the far left we’re the at the zenith of white privilege.

Categories
WordPress

🧂

Reflecting on the topics I’ve covered on this blog recently, I can’t help but notice that my tone has been pretty salty lately. Despite receiving a ton of positive feedback on my writing (thank you!), I’m personally disappointed that I’ve not been more constructive.

In a recent Twitter thread with Birgit Pauli-Haack (whom I really admire) I came to realise that I was just having a whinge, and not providing any productive feedback. Birgit and Mark – I apologise.

This grouchy attitude really runs contrary to how I usually think. I try to be a “if you don’t like it, fix it” kinda guy.

As an aside, I’ve evolved my thinking on the problem with Gutenberg development. The issue is not just that key decisions about the future of WordPress are facilitated through a developer tool¹ – the issue is that nobody is proactively seeking input from the WordPress users who aren’t involved in core development.

One of the things I love about the WordPress community is that there’s a culture of “we’ll hear you out”. When an irritated crazy with an axe to grind joins the Core Dev Meeting on Slack, it’s always handled with grace and care. Criticism rarely results in controversial political encounters.

I think this comes from the top. Listening, recognising, responding in a politically sensitive way – that’s one of Matt Mullenweg’s superpowers. You should see this guy deftly manoeuvre through questions from the floor during a State of the Word address. It’s impressive!

Maybe we’ve gotten too good at handling criticism? In an open source project the size of WordPress, critics are numerous and persistent. Out of necessity, we’ve become experts at hiding negative sentiment in plain sight.

For example, nobody seems to be talking about this:

The Classic Editor, used to disable Gutenberg, is the fourth most popular plugin. And consider me suspicious about Contact Form 7 taking that top spot.

It seems like simply noticing and writing about problems with the WordPress project² doesn’t really achieve much. So in the future, I’ll attempt to include a practical aspect to my writing.

For example, I might write about how it’s nearly impossible for plugin authors to have a clear picture of how (or even how many) people use their plugin, due to restrictions in the plugin guidelines. With this post, I could include a functional workaround – a loophole in the guidelines, based on examples from Jetpack and Woo.

In this manner, I hope to keep writing here, and hopefully have more of a positive impact on the ecosystem³.


1. Don’t try to convince me that GitHub isn’t a developer tool. I know discussions also happen on the Make blog and Slack, but it’s all funnelled back to GitHub for the real decision making.

2. Insularity from users; power dynamics with Automattic; plugin guideline hypocrisies (looking at you Jetpack); Envato’s enduring WordCamp ban; developer-centric decision making; the list goes on.

3. Can anyone recommend a good footnotes plugin?

Categories
Facebook

Fs in the Chat

Not sure why I’m writing this. It feels like I’m screaming into the void. Am I being petulant? Am I naive? Over-reacting?

This week Facebook wrote about updating the privacy policy for Oculus. And holy shit are we headed for a fucked-up dystopian nightmare.

The day has finally arrived.

We all saw it coming, when Facebook acquired Oculus in 2014.

We saw it coming, when WhatsApp cofounder Brian Acton left Facebook with his famous #deletefacebook tweet.

We saw it coming, when the Instagram cofounders suddenly quit their jobs at Facebook, saying “No one ever leaves a job because everything’s awesome, right?”.

We fucking saw it coming when one by one, the original founders of Oculus all left, including the beloved Oculus CTO John Carmack, just one month ago.

I saw it coming, which is why I never linked my Oculus Go to a Facebook account (spoiler alert: I don’t have one). There was only one feature that I couldn’t use (Oculus Rooms), but the rest worked fine, and there was no Facebook privacy policy that I had to sign.

But that’s all about to change.

Oculus announced, in a very broadly worded policy update, that it will start tracking VR usage data, and sharing that data with Facebook, in order to serve you ads across its numerous platforms.

As part of these changes, Facebook will now use information about your Oculus activity … to help provide [social features] and more relevant content, including ads.

Oculus Blog, December 11, 2019

Icing on the cake: in order to connect to multiplayer on the Oculus platform, you’ll need a Facebook account.

Fire Flames GIF - Find & Share on GIPHY
Kill it with fire.

Let’s talk about what VR data includes, right now:

  • Attention detection (what’s you’re paying attention to)
  • Gait detection (how you walk is as personally identifiable as your fingerprint)
  • Analytics (what you’re playing, how long)
  • Room coordinates (the shape of your home)

And let’s talk about what VR data includes when the Oculus Quest 2 is released:

  • Gaze detection (what you’re looking at)
  • High resolution photos of your retinas
  • Object detection (the real-world things you have in your house)

Maybe you look at this list and respond like this guy:

Who am I kidding? David is probably right. This “experiment” with privacy was doomed from the start. Crazy to think we could ever go toe-to-toe against corporate capitalist America!

It paints a pretty bleak picture of the future. You can’t beat an algorithm that’s trained to defeat your impulse control, by designing psychologically manipulative ads made specifically for your psychological profile.

So what can you do? You could boycott (I do), but with Facebook selling the Oculus Quest at a loss, that’s just a stand of principle, not effective group action.

Here’s hoping we all drown in rising boiled oceans before Mark Zuckerberg becomes the immortal sentient AI overlord of Earth.

Categories
WordPress

Block Based Themes

Who decides the future of themes in WordPress?

I remember back when Gutenberg was still in beta, we were talking a lot about what the block editor would mean for the future of WordPress.

Would blocks be distributed in themes, or in plugins? What would Gutenberg look like if it were combined with the Customiser? Should widgets be blocks (and if so, what about the header logo, or copyright colophon)?

This week we started to get some early rumblings of answers to these questions. Riad Benguella created a Pull Request to the Gutenberg GitHub repo, proposing an experiment for completely block based themes.

It described something very important! The future of themes in WordPress! Unfortunately, it was published on GitHub, and to read it, you needed to view the changeset and parse the markdown. Of course, the WP community doesn’t read every new PR that comes through the Gutenberg repo – so this could have easily flew under the radar.

But we got lucky – it caught the attention of Justin Tadlock over on WP Tavern, which drew some attention to the PR.

This Pull Request has been met with a considerable degree of concern. I wanted to take the time to write about this from the perspective of:

  1. What does this experiment look like?
  2. Why is there resistance to the idea?
  3. Where do we go from here?

What does this experiment look like?

Sorry Riad! I think a large part of the problem here is that this first documentation on block based themes is actually quite difficult to understand. I spoke to a few different people who couldn’t quite wrap their head around it.

Here’s my interpretation:

Let’s start by imagining that blocks could be used as widgets. You could add, say, a Quote block to any one of your widget areas.

Actually, you don’t have to imagine this – just activate the Gutenberg plugin and enable Widgets under Gutenberg > Experiments.

Okay, makes sense so far. Now imagine replacing your footer with a widget area. Chances are, your footer already contains one, so this shouldn’t be too hard. But instead of a © section at the bottom, imagine this is a paragraph block instead, and there’s an interface in the WP Admin to change the text displayed here.

Now, did you know that in the latest version of Gutenberg there’s a “Navigation” block? This is what it looks like:

So, now we could easily replace the navigation in our header with a widget area, and insert the Navigation block. While we’re there, we could insert our logo as an image block, and align it to the left.

At this point, the name “Widget Area” isn’t such a great fit. Let’s call it a “Template Part” instead. We’ll have Template Parts like Header, Footer, and Sidebar.

Hey, now that we’re thinking about it, don’t forget that WordPress 5.3 introduced Group blocks. We could use these to do something pretty cool…

Start with a completely blank page. Nothing on it – no header, no sidebar, nothing. We could add a group block to the top, and make that our Header Template Part. Then below that we could add another Group Block, and expect the Post Title and Post Content to be added there. Maybe another Group Block next, and put Comments in that. Let’s finish off with a Group block for the Sidebar Template Part, and then a Footer Group.

We’ll call it “single”. It will be structured something like…

  • Group block
    • Header Template Part
      • “Logo” image block
      • Navigation block
  • Group block
    • Post Title block
    • Post Content block
  • Group block
    • Comments block
  • Group block
    • Sidebar Template Part
      • Search block
      • Categories block
  • Group block
    • Footer Template Part
      • “Copyright” paragraph block

(Notice our Template Parts are kind of like reusable block groups.)

This is called a Block Template. We could create it in some sort of Template Editor in the WP-Admin, and export it to be used as a theme.

So themes would be responsible for three things:

Style

This includes the structure of how the Template Parts fit together visually, as well as styles for all blocks (they might even be styled differently in different Template Parts).

Block Templates

Not dissimilar to current theme templates, and maintaining adherence to the Template Hierarchy, these describe the overall structure of the page, in the language of blocks (especially Group blocks) and Template Parts.

Template Parts

The theme should probably add some default blocks: a logo and navigation to the header, and a paragraph with copyright text to the footer. Even though these blocks could be easily changed and removed by the user, the theme should include a starting point. These defaults belong in a Template Part, and the Template Part is included inside a Block Template.

Hopefully that makes things a little clearer! For those of us who have been using traditional WordPress templating for the past decade or more, this is quite a tough change to wrap your head around. 💫😵💫

Why is there resistance to the idea?

Aah… politics. Unsurprisingly, there’s some #wpdrama going down because of this proposal. Some of it is based on simple misunderstanding (a.k.a. poor communication), but there’s more to it than that.

The subtext here is that Riad works for Automattic. I won’t dive into the history of WordPress and Automattic, suffice to say that their CEO leads the WordPress project¹, and as such, there is a constant concern from the community when Automattic approaches conflict-of-interest boundaries.

So, when an Automattician makes a giant proposal on the future of theming in WordPress, which gets merged into the Gutenberg project the very next day², I think it’s very reasonable that people are concerned.

Here’s a timeline of how it went down³:

September 5: Automattician Matías Ventura publishes a Make WordPress post describing full site editing with blocks. It’s met with a lot of positivity, but doesn’t include much detail on technical implementation.

September 23: Google employee Felix Arntz created an Issue in the Gutenberg Github repo describing Matías’ post. The 15 comments on that issue (before the PR on December 4) were all made by Automattic or Google employees.

December 4: Automattician Riad Benguella creates a PR for documenting the experiment. There is some early concern from Joy Reynolds (a well-known WordPress core contributor), but there’s no time to discuss it further, because…

December 5: Automattician Enrique Piqueras approves the PR just 24 hours later!

December 5: Riad merges the PR (the day after it’s proposed).

Notice a pattern?

The people with power all work for Automattic and Google.

It seems fairly clear to me why there is so much resistance to the idea. I believe it’s because:

  1. The experiment was poorly explained, and widely misunderstood.
  2. There wasn’t any opportunity to understand the technical implementation.
  3. There wasn’t any opportunity to discuss it either.
  4. The whole project is being rushed through by Automattic (with some help from Google).
  5. Feedback / concern is being brushed aside or hand-waved away, instead of properly discussed.

December 5: Hours after this PR is approved, Derek Hermann chimes in. Derek has been contributing to WordPress for years. Over that time he was a feature lead on the Customiser, worked with me to build Tide, and has been very active in Gutenberg’s development. He’s also the CTO of XWP (one of the largest WordPress VIP agencies in the world).

Derek has some real concerns, and lots of questions, which Matías tries his best to answer (although to be honest, Matías’ answers left me even more confused). Derek’s Github comments get lots of 👍 and ❤️ support. Even so, nothing changes.

Derek’s most important question is this one:

You have to research what the users want, not what the team wants to build. Where is your research?

Which brings me to…

Where do we go from here?

Alright, now we start to get into the territory of my opinion. Of course, you’re entitled to agree or disagree – take it up with me on Twitter if you like.

So, in my opinion, the entire experiment should be reverted.

The perception is that Automattic is working on Block Template themes in the shadows. Why? Do they see themselves as pioneering a future that we don’t yet know we need?

The rest of us need to be looped in to the decision making process.

Reword the document in this PR as a proposal, and post it on Make WordPress for feedback. The first Make WordPress post from Matías contained very few technical details.

Allow time for discussion! Put it on the agenda for the Editor Chats that happen every week.

Help the community to understand what this looks like – because clearly nobody does right now.

Most importantly, research how Users, Agencies, and Theme Designers want to engage with themes in WordPress. Make a decision based on that research, not based on a handful developers best guesses at how a block based themes should be implemented technically.

Merely asking for feedback is just not good enough. If nobody responds, that doesn’t mean you get to decide for yourself. That’s not how research works.

Maybe a developer tool isn’t the best place to ask for feedback on the future of WordPress. We can’t expect our community to learn GitHub, and follow the discussions happening across nearly 20,000 issues.

Maybe, if we facilitate a friendly, open, and wide-reaching dialog, we might arrive at different conclusions.


Important note: Nobody involved here is being intentionally malicious or hostile. I believe we have a problem with structure and power dynamics, which is what I’m trying to call attention to (not the individual developers).

I reached out to Matías and Riad and get their feedback before publishing this article.

Riad also offered these thoughts:

The reality is that I’d love more contributors that are non-Automatticians, but the reality is that a big part of WordPress contributors today are Automatticians. If you’d like to join our team and work with us to improve the proposal or change it you’re welcome.

There’s no shadow here . This was discussed for more than a year now in different Github issues by different people and regularly on #core-editor weekly meetings (which I invite you to join to discuss the proposal and help).

In chatting with Matías, he noted that the proposal for block templates has been discussed for a really long time in multiple places — there are GitHub issues from all the way back to 2017.


1. Matt Mullenweg, CEO of Automattic and co-founder of WordPress, is known as the “Benevolent Dictator for Life” of the WordPress project.

2. Actually, the experiment itself was merged a while ago – what we’re talking about here is only the documentation about the experiment. To be aware that any of this was happening, you’d have to be following along on GitHub.

The reason this PR was noticed was because the part that got merged was Documentation – thankfully a bit easier to understand than trying to string together multiple conversations between PRs, issues, and code. Even as it was, though, this could have easily gone under the radar if it weren’t for Justin picking it up on the Tavern.

3. There was also a call for feedback published on the Make WordPress blog, on November 3. I didn’t include it in the timeline because block based themes are just one line item among many – easily lost on a Make post that seems to have gone mostly unnoticed.

Categories
WordPress

WP Notify

I just learned about a proposal from Jonathan Bossenger to implement better notifications in WordPress.

You can read up on it for yourself, but I thought it would be helpful (for myself as much as anyone) to add some context, and explain why it’s so important.

What would WP Notify do?

If added to core, WP Notify would:

1. Provide developers with a Notifications API to surface new Notifications to the user, and handle their state (e.g. “dismissed”)

2. Introduce a Unified Notification Format (fixing the current visual mess of having boxes everywhere)

3. Group notifications together in a Notifications Hub (such as a menu item in the Admin Bar)¹


Technical Part.

The current notifications in WordPress are a hack at best. You need to write all the HTML for the notification wrapper, and use a specific CSS class to get it to show up.

Something like:

add_action( 'admin_notices', function() {
	<div class="notice is-dismissible">
		<h2><?php esc_html_e( 'We come in peace.', 'my-plugin' ); ?></h2>
		<p>🖖 <?php esc_html_e( 'Live long and prosper.', 'my-plugin' ); ?></p>
	</div>
} );

That’s just to show the notice. You’ve also got to save whether the notice has been dismissed.


I’ve got some personal history tied up in WordPress notifications. Joshua Wold and I spent a lot of time designing a notifications solution for Stream (which never came to be).

Then, in 2016, I gave a talk at WordCamp Sydney containing this screenshot.

What we’re looking at here is a brand new WordPress install after installing just 5 plugins. It’s a mess!

Now, a common Notifications API in WordPress won’t fix this entirely, but it could improve it a lot. The most interesting idea is to group notifications together in the Admin Bar.

This could produce a UI similar to the way Yoast handles notifications (see the screenshot above). It would also restrict notifications to:

  • A limited amount of text (280 characters, for example)
  • An icon

Notifications in WordPress can be grouped into a few categories:

Action

The plugin wants the user to take an action (often required before the plugin can be fully functional). For example, adding an API Key to Akisment, or connecting Jetpack. Sometimes it’s an optional action, such as taking a survey.

Onboarding

The plugin wants to teach the user about a feature, and so it shows a notice (usually contextual to where the feature exists) with some help text.

Informative

The plugin has detected information about WordPress which it wants to surface to the user. For example, Yoast detecting that search engine indexing is disallowed.

Results

The user has taken an action, and the plugin wants to notify them about the result (e.g. Post Saved, or Error Saving Post).

Advertisements

The plugin wants to show the user information about a paid upgrade or a current sale (please, no!).


While grouping notifications together into a single Notifications Hub would help reduce a lot of visual clutter, not all of these notification types belong in a Notifications Hub.

HubNotification Type
Action
Onboarding
Informative
Results
Advertisements

Onboarding notifications nearly always need to be shown in context. These are typically inserted into the UI, intentionally interrupting the user journey.

Results are a little different to other notifications in that they’re not usually persistent. They only need to be shown once, and automatically dismissed. Gutenberg’s notifications implementation does this really nicely.

Advertisements could exist in a Notifications Hub, but probably won’t. These notifications are all about grabbing a user’s attention, and grouping with other notifications isn’t a great way of doing that.


Given that only a few types of Notifications that would make use of a Hub (and even then, only at the plugin developers discretion), is WP Notify worth pursuing?

To answer this, I installed the 20 most popular plugins and catalogued the notification types I encountered. By collecting this data, we can see what percentage of notifications would be “captured” in a Notifications Hub area.

Notification TypeCount%
✅ Action1033%
❌ Onboarding620%
✅ Informative930%
❌ Results27%
❌ Advertisements310%

Of all notifications that I encountered, 19 / 30 (63%) could belong in a Notifications Hub


One interesting side note: Due to the brief usage of each plugin, I’m sure I missed many “Results” notifications, such as notifications shown when saving settings.

Should WP Notify provide a method for developers to show this style of transient notification, separately to the “grouped” Notifications Hub?


If you’d like to be involved in making this proposal a reality, you can get involved by joining the #feature-notifications channel in the WordPress Slack.

This is a great opportunity to get involved in WordPress core development, especially for UX / UI designers who want to have a hugely positive impact toward a distributed and open web.


1. There is some concern that the admin bar might not be the best place to show notifications. It’s already crowded, hard to use on mobile, and sometimes hidden on the frontend.

2. In these tests, the average amount of notifications displayed (after only a few minutes of usage) is 1.5 notifications per plugin.