Becoming a Googler

Me visiting the Google Portland office

I often see tweets from people in the industry announcing major career changes; I never expected that I would be adding to this stream, but today I am. After more than 8 years at XWP/X-Team, I am starting at Google as of October 1st. I’m joining the Developer Relations team at Google to work on building a stronger web content ecosystem. In my new role I’ll be doing… many of the same things because I’m joining Google for the purpose of continuing to contribute to WordPress. While I have been doing that with the support of XWP, now I’ll be doing so with the backing of Google.

After working heavily on the WordPress 4.8 and 4.9 releases in 2017 (as well as previous core releases), I started transitioning a year ago to working on something very different. XWP started working with Google on a new phase for the AMP plugin and I led the engineering efforts. It was a refreshing change after years of working primarily on the Customizer: I realize now that I was on the verge of burnout at that time, and since we just did a major core release with Customizer improvements and because focus in core shifted fully to Gutenberg, I felt comfortable stepping away for a while to focus on AMP. After several months of working on AMP we then also started working on a PWA feature plugin which aims to bring progressive web app capabilities to core.

Working on AMP and PWA have felt like returning to my roots. Before XWP and before I was involved in WordPress even, I was really interested in open web standards. I contributed (with small acknowledgement) to the HTML5 spec by participating in the mailing list and creating a cross-browser implementation of Web Forms 2.0. I also created polyfills for CSS Transitions and CSS Gradients. I loved learning new cutting edge (progressive) technologies and then finding ways to implement them in projects, often requiring some creative solutions to get them to work in older browsers. (I used to take pride in my knowledge of IE6 workarounds.) I was an early adopter of Ajax, and I was an avid listener of the Audible Ajax podcast on the old Ajaxian blog; I loved that community that Ben and Dion created, and I loved contributing some things I hacked on. (Ben and Dion are both at Google now and I’ll be working in the Chrome team with them.)

My desire is to make as big an impact as possible. This is why I’m passionate about the open web. In publishing some project openly, I know that someone else can benefit from it and build upon it to make something new, just as I have benefited and built upon the projects of others. Everyone can contribute to building a better web. This is also a reason why I love WordPress: not only does it democratize publishing but it also democratizes development.

I’ve loved working at XWP because of our mission to build a better (open) web, and we have been doing so through WordPress. Over the years I’ve also been a big Google fan because of all they’ve done to invest in the open web. But I never thought that I’d get to work at Google, nor even that I’d want to. Nevertheless, this past year of working with Google has been a really great experience. I’ve been able to see first hand their commitment to the open web, and there was such a great alignment with XWP in having a shared mission to make it better. I’ve also been able to work with exciting technologies that serve toward this goal.

For many months I resisted the idea of applying at Google. I’ve invested many years working at  XWP and helping it to grow, and I have many relationships there which I value greatly. I’ve been able to contribute to building a better web at XWP and I could certainly continue to do so there. However, after Google I/O and WordCamp Europe I realized that at the current place in my career, I believe I’ll be able to grow more personally and have a greater impact if I start to contribute from Google while leveraging its support and resources. Additionally, there are others at XWP who can take my place and do more than I ever could to lead the company in technology and engineering; I have total confidence in them. While my relationships with XWPeople will change, they won’t end as I’ll be continuing to work with them on AMP, PWA, WordPress core, and other projects in the future. Read more about this new season for XWP.

So I’m going from working with Google to working at Google. For more see my Googler colleague Alberto Medina’s post about Web Content Ecosystems @ Google. I’ll be based out of Google’s Portland office so I’ll continue to be in PDX. I’m excited about this next chapter in my career and season in my life. Strangely enough, I’m really looking forward to taking TriMet and riding my bike each day to the office, as I’ve been working from home for the past 8 years (which I have loved, don’t get me wrong). But more so I’m looking forward to seeing how Google can build a better open web by investing in WordPress. I’m excited to be a part of it.

WordCamp Europe 2018 Recap: AMP and PWA

Recently I attended WCEU 2018 in Belgrade with quite a few colleagues from XWP. We were there in large part to promote the adoption of progressive technologies in WordPress. We spent a lot of our time at the Google booth where we had an area to talk about contributing to WordPress across a wide range of roles. I spent most of the time in the booth stationed at the AMP area talking about the new capabilities we recently published in the plugin’s v1.0-alpha1 release, and since then we’ve followed up by releasing v1.0-beta1.

I’m really excited about how the AMP plugin is turning out. It now enables you to create AMP-compatible themes in the WordPress way; your theme can render your site in AMP using the same templates and stylesheets you would use normally on a non-AMP site. There is complete visual parity between your AMP pages and your non-AMP pages, aside for some differences in embeds (compare this post with AMP and without AMP). This being the case, you don’t even need to have a non-AMP version of your site anymore (the Paired mode), as the Native mode can just serve your entire site in AMP (such as xwp.co). AMP restricts what HTML you can use in order to guarantee performance and security, and the plugin never serves a response that contains invalid AMP in it. The plugin has a validation workflow to identify what the AMP validation errors are, where they are coming from in the page, and which theme/plugin is to blame. Please try it out and refer to the wiki for all the details on how to leverage the new features, especially Adding Theme Support and Implementing Interactivity.

My colleagues Alberto Medina (of Google) and Thierry Muller (of XWP) gave a great talk on Progressive WordPress which also dove into why AMP is important and how the AMP plugin brings its benefits to WordPress:

And we were interviewed on the topic of Progressive WordPress by Sarah Gooding at WP Tavern:

WCEU Panel Discusses Progressive WordPress Themes, AMP, and Gutenberg

On the topic of Progressive Web Apps, after Matt Mullenweg’s keynote someone asked during the Q&A about about a future where WordPress could be used to create to create apps. Matt responded:

There’s very exciting technologies coming out of two big corporations, one of which is a sponsor of WordCamp Europe, thank you Google. […] The other thing coming from Google which is very very exciting since they also contribute to the largest open source browser which is chrome—progressive web apps. So there’s lots of technologies around there that I think could drastically speed up how wp-admin works in a way that makes it a much more app-like experience without it actually needing to be completely rewritten from the ground up. So I feel like there is an opportunity to get… sort of almost like a JavaScript app-like performance increases from the wp-admin in a mostly backwards-compatible way, with progressive web app technology. So that’s very very exciting. It’s also open standards. They’re being supported by many places. So I feel like there’s a time there when it looked pretty dark to be honest for the web, particularly around performance. Things were just going slower and of course we know users start to tend toward things that are faster. So the apps were winning. But between AMP, progressive web apps, and just all the improvements and optimizations that we’re making including things coming under the hood like PHP7, basically doubling performance of WordPress overnight. […] These things are making it so that we can a really competitive experience and I’m excited about the future of the web.

As I just tweeted, there is now a PWA feature plugin on the WordPress.org directory. Its purpose is to curate Progressive Web App capabilities for proposed merging into WordPress core: service workers, the web app manifest, and improved HTTPS support.

PWA

This PWA feature plugin is intended to equip and facilitate other plugins which implement PWA features. It’s not intended to negate any existing plugins with these features, but rather to allow such plugins (and themes) to work together seamlessly and expand upon them. The plugin’s first release (v0.1.0) includes support for the web app manifest and an API for themes and plugins to register scripts for service workers, of which two are installed: one for the frontend (scope: ~/) and one for the admin (scope: ~/wp-admin/). A next step for service workers in the PWA feature plugin is to integrate Workbox to provide a declarative WordPress PHP abstraction for managing the caching strategies for routes, with support for detecting conflicts. You can follow development and contribute to the plugin on GitHub.

Photos not taken by me are courtesy of Ryan Kienstra, Alberto Medina, and Paul Bakaus.

Spoken Word: Bringing Read-Along Speech Synthesis to the Web

Back in December 2009 I did a hackathon to create an HTML5 Audio Read-Along (demo) which highlighted the text of words spoken in the corresponding audio being played. To introduce the project I wrote:

Screenshot of ReadPlease 2003When I was in college, my most valuable tool for writing papers was a text-to-speech (TTS) program [ReadPlease 2003]. I could paste in a draft of my paper and it would highlight each word as it was spoken, so I could give my proof-reading eyes a break and do proof-listening while I read along; I caught many mistakes I would have missed. Likewise, for powering through course readings I would copy the material into the TTS program whenever possible and speed up the reading rate; because the words are highlighted, it’s easy to re-find your place if you look away and just listen for awhile. (I constantly use OS X’s selected-text speech feature, but unfortunately it does not highlight words). A decade after my college days, I would have hoped that such TTS read-alongs would have become common on the Web (though there is work-in-progress Chrome API and a W3C draft spec now under development), even as read-along apps are prolific in places like the Apple App Store for kids books.

As I further note in the project’s readme, the process I used to create this read-along demo was extremely tedious. It took me four hours to manually find the indices for a couple minutes of speech. I painstakingly obtained time indices for each word in a segment of speech audio to align with its corresponding text so that the text could be highlighted. Naturally my project was just intended as a demo and it is unreasonable to expect anyone else to go through the same process. Nevertheless, I think my proof of concept is compelling. I won second place in the HTML5 audio Dev Derby by Mozilla back in 2012.

Several years later I made Listenability which was an open source DIY clone of the now-defunct “SoundGecko” service. It allowed for you to create a podcast of articles that you sent to your blog and leveraged your system’s own speech synthesis to generate the podcast audio enclosure asynchronously. Daniel Bachhuber created SimpleTTS which integrates WordPress with the Amazon Polly text-to-speech to create the MP3 files and attached them to posts. His work was then followed-up with another Polly solution, this time being developed directly by AWS in partnership with WP Engine. These Polly integrations provide great ways to integrate speech synthesis into the publishing workflow.

Publishing text content in audio form provides key value for users because it introduces another mode for reading the content, but instead of reading with your eyes, you can read with your ears, such as while you are doing dishes or riding a bike. Speech synthesis makes audio scalable by automating the audio creation; it introduces your content into domains normally dominated by music, audiobooks, podcasts, and (oh yeah) radio.

The Amazon Polly solutions are great for when you want to publish audio as an alternative to the text. What they aren’t as great for is publishing audio alongside the text as I set out to demonstrate in the read-along experience in December 2009. (It is possible to implement a read-long with Polly using Speech Marks, but the aforementioned integrations don’t yet do so.) If there is an audio player sitting at the top of an article any you hit play, you can quickly lose your place in the text if you’re trying to read along since the currently-spoken words are not highlighted. Additionally, if you are reading the article with your eyes and then decide you want to switch to audio while you do the dishes, it is difficult to seek the audio content to the place where you last read in the text content. What I want to see is a multi-modal reading experience.

So in December 2017 I worked on another Christmas vacation project. Since Chrome, Firefox, and Safari now support an (experimental) Web Speech API with speech synthesis, you can now do text-to-speech in browsers using just the operating system’s own installed TTS voices (which are now excellent). With this it is possible to automate the read-along interface that I had created manually before. I call this new project Spoken Word. Here’s a video showing an example:

Here’s a full rundown of the features:

  • Uses local text-to-speech engine in user’s browser. Directly interfaces with the speechSynthesis browser API. Zero external requests or dependencies, so it works offline and there is no network latency.
  • Words are selected/highlighted as they are being spoken to allow you to read along.
  • Skips speaking elements that should not be read, including footnote superscripts (the sup element). These elements are configurable.
  • Pauses of different length added are between headings versus paragraphs.
  • Controls remain in view during playback, with each the current text being spoken persistently being scrolled into view. (Requires browser support for position:sticky.)
  • Back/forward controls allow you to skip to the next paragraph; when not speaking, the next paragraph to read will be selected entirely.
  • Select text to read from that point; click on text during speech to immediately change position.
  • Multi-lingual support, allowing embedded text with [lang] attribute to be spoken by the appropriate voice (assuming the user has it installed), switching to language voices in the middle of a sentence.
  • Settings for changing the default voice (for each language), along with settings for the rate of speech and its pitch. (Not supported by all engines.) Changes can be made while speaking.
  • Hit escape to pause during playback.
  • Speech preferences are persistently stored in localStorage, with changes synced across windows (of a given site).
  • Ability to use JS in standalone manner (such as in bookmarklet). Published on npm. Otherwise, it is primarily packaged as a WordPress plugin.
  • Known to work in the latest desktop versions of Chrome, Firefox, and Safari. (Tested on OSX.) It does not work reliably in mobile/touch browsers on Android or iOS, apparently due both to the (still experimental) speechSynthesis API not being implemented well enough on those systems and/or programmatic range selection does not work the same way as on desktop. For these reasons, the functionality is disabled by default on mobile operating systems.

Screenshots of the WordPress plugin with the Twenty Seventeen theme active:

You can try it out on a standalone example with some test content, or install the WordPress plugin on your own site (as it is installed here on my blog for this very article, but you need a desktop browser currently to see it).

For more details, see the GitHub project. Pull requests are welcome and the code is MIT licensed. I hope that this project inspires multi-modal read-along experiences to become common on the Web.

“Building with JavaScript in the Customizer” at WCUS 2017

At WordCamp US 2017 I gave a talk on “Building with JavaScript in the Customizer”. I was happy to have the opportunity to share the technical details on the Customizer’s architecture and JavaScript API, which saw many improvements in 4.9, in addition to being able to share the Customizer’s new user-facing features during State of the Word.

The video has been posted on WordPress.tv:

Some photos taken during my talk:

Here are the slides:

I want to convert the talk into a series of blog posts to dig into more of the details and provide more examples, but I probably won’t get to that until 2018.