Common sense is good; enough of it is genius
Lots of things have happened in the last two years. And that has percolated through all aspects of life for me: relationships, work, priorities, and so much more. Now I am here, today, with all the learnings and changes, and excited about what is coming our way.
One of the things that resulted from all this, is a renewed desire of activating my creative output. This means that I am determined to start writing frequently about everything. This is the beginning.
This post summarizes a recent talk Jeanny Haliman and myself gave at AMP Conf, 2019: Enabling first-class AMP experiences on WordPress is one of the ways the AMP Project aims to bring a user-first experience to websites and content on the web. The Official AMP Plugin for WordPress (WordPress.org, Github) integrates AMP content creation seamlessly with standard WordPress content creation workflows. In this talk we describe in detail how the AMP plugin for WordPress works, how to take advantage of it, and showcase some salient success stories of WordPress sites using the plugin in the wild.
WordPress is a Content Management System (CMS), which means that it is a software platform that adds layers of abstraction on top of the web to facilitate the creation, management, and publishing of content on the web. It is certainly one of the largest players in the CMS space, with about 33% of the whole web being powered by WordPress sites today.
Building AMP-first WordPress sites on CMS platforms such as WordPress encompasses a spectrum between a fully manual process, where we as developers do all the work, and a fully automatic process, where the platform, with a combination of core functionality and extensions does all the work for us.
The reality of what is feasible today is a balance point somewhere in this spectrum, where a large part of the process can be automated, and there is a part of the process that requires developer intervention. The exact location of this point, is determined by the status of the ecosystem in terms of AMP compatibility, and therefore, as the WordPress ecosystem evolves, the location of that balance point moves towards maximizing automation and minimizing developer interventionThe key enabling technology influencing AMP compatibility in the WordPress ecosystem is the official AMP plugin for WordPress (WordPress.org, Github).
The Official AMP plugin is an extension to the WordPress platform, which plays three main roles:
To fulfill these roles the plugin implements four main areas of functionality:
All this functionality is part of the assisted generation capabilities of the plugin; we don’t have to worry about them and we can focus instead on the parts of the process that require developer intervention.
In WordPress, the look and feel of a site is controlled by a collection of template files, which when combined together, form what is called the theme of the site. The AMP plugin can be configured to interact with the theme of a site in three different ways:
In native mode, the plugin essentially integrates AMP as the framework for your WordPress site. It reuses the theme’s templates and styles to render AMP responses. This means that your site is AMP-first and your canonical URLs are AMP!
Depending on the theme and plugins being used, a varying level of development work may be needed. The AMP plugin helps us by doing most of the work automatically, and this part corresponds to the minimum developer intervention needed to reach full AMP compatibility.
There may be cases where it is not possible to get all the components for a given content type to be AMP compatible at a given time. In these cases, you can either opt out of AMP of those content types or you can leverage the plugin Transitional Mode.
In transitional mode (formerly called Paired mode) the plugin also reuses the active theme’s templates, but it renders AMP and non-AMP responses. Although there are two versions of the content, your site’s theme is used in both cases, and you as a developer have control of what is generated for either case.
This mode is called transitional because it is intended to provide you with a migration path, to progressively expand the AMP compatibility of your content, until you can switch easily to native mode.
There are cases where we may want to provide an AMP experience to our users, but don’t have the resources to carry out the development work needed for the native of transitional modes. In these cases, we can take advantage of the plugin Reader Mode.
In Reader Mode (formerly called Reader mode), the plugin generates AMP content using separate simplified templates that are neat and light but may not match the design of the underlying theme of your site. This mode is useful for providing basic AMP experiences, but we don’t actually recommended it because transitioning to AMP-first experiences in WordPress is getting easier and easier.
Now that we understand the different template modes let’s go over the development workflow for building AMP-first sites in WordPress.
The workflow for developing AMP-first sites in WordPress encompasses three main tasks:
The AMP plugin does all the work on identifying and contextualizing validation errors. And it also does quite a bit of the work needed on the AMPification part, by automatically generating AMP-compatible components, or automatically removing offending components (with user consent).
This screenshot gives you a glimpse of content creation and editing in WordPress. In the WordPress editor, everything is a block. The blue rectangle here is a Custom HTML block we added to our content. And in that block a piece of code is added which violates AMP rules.
When we update the post, the plugin flags the error, in the context of the block, as well as a clear warning notice on top that alerts about problems in this particular content as well as in other parts of the site.
Contextualizing the error in this case is easy since we have it in front of us. But in WordPress, code can be generated in a variety of ways and keeping track of the sources of specific errors is one of the most difficult parts of AMP development in a CMS such as WordPress. The good news is that the plugin does all the work needed to contextualize errors.
The plugin hooks its functionality into the content generation mechanisms of WordPress and annotates the generated markup with HTML comments. When a validation error is encountered, the plugin walks the DOM tree back to determine from the HTML comments the source of the error and other contextual information. Each URLs affected by a given validation error is associated with the same validation error object.
Once the plugin has identified and contextualized existing errors, the question is what to do about them?
The plugin can be configured to do one of two things:
But the ultimate decision about what to do with identified errors is taken by the developer.
As a developer, you can decide to either:
The plugin exposes these capabilities via a compatibility tool that puts at the fingertips of developers all the information gathered on the identification and contextualization of errors. In a nutshell, the compatibility tool exposes:
At this point you should have a good sense of the capabilities of the plugin and the elements of the workflow for developing AMP-first sites in WordPress. Let’s go now over a simple but real-world example of making a theme AMP compatible.
As we mentioned before, depending on the characteristics of your theme, the level of work required to achieve this would vary. But although this example is not too complex, it will give you a clear sense of the workflow you should follow for making your theme AMP-first.
We start with a theme has been tested and it has functional fallbacks so that it works well when JavaScript is disabled in the browser.
In our example we start with the Twenty Thirteen Core theme, which is a classic, simple WordPress theme, with a site identity section, a hamburger menu, search bar, some content embeds such as YouTube and Twitter, widgets, and features like that. To test this example yourself, get a brand new WordPress install, install the AMP plugin for WordPress, and the Twenty Thirteen Core theme.
The first step is to activate the AMP plugin in our admin screen and configure the plugin to operate in Transitional mode to progressively make the theme AMP-compatible and once we get to full AMP compatibility we can switch to Native mode. We configure it also to not remove automatically any offending markup, because we want to analyze each validation error to understand it and fix it.
Once we Save the configuration, we can see the plugin telling us that there are some validation issues we need to investigate and fix.
The next step is to take a look at the content of our site and see where the validation errors are coming from.
We pick a specific post. Since the plugin is configured in transitional mode, we land on the non-AMP version of the post, which has the functionality we get from the 2013 theme.
We have access to the AMP version of the post from the Admin bar, and when we try to go to the AMP version, the plugin tells us the AMP version is not valid.
We can then go to the compatibility tool to see the errors and all their contextual information. There you can see the errors in red, which means the plugin did not remove the offending markup elements. Notice as well on the right sidebar, that AMP is disabled for this post, which means AMP content will not be served.
We will not dive into analyzing the errors now for the sake of time and space, but we can get you a summary of what is happening. If we look at the source and type columns in the compatibility tool, we see that there are:
The next step is to isolate the errors, by letting the plugin remove the offending elements, and then look in detail at our theme to see what visual or functional disparities exist, if any.
To isolate the effect of individual errors, we mark all errors as “Accepted”, which tells the plugin to remove the offending elements. And then we use the preview functionality, which allows to analyze the effect of the plugin actions without actually applying the changes to the post.
Notice that by doing this we have made the post to be valid AMP, but we need to ensure there is no broken functionality or visual disparities. In this case, we checked the post and found that everything is good, except for the hamburger menu that was broken by the removal of one of the theme JS scripts which provided that functionality.
The next step is to make the fixes in the theme to remove the causes of the errors and implement the functionality of the hamburger menu in a way that is AMP compatible.
In the style.css file, we first remove the CSS viewport at rules that are not needed.
In the functions file of the theme we implement a function to check when AMP content is being requested and use it to wrap the parts of the theme where the JS files are being enqueued and prevent that from happening on AMP responses.
Then we add theme support to tell the plugin to handle the hamburger menu conversion. Most themes include some custom JavaScript to support presenting the nav menu. Since the implementation looks very similar for most themes, we added support in the AMP plugin to provide an AMP compatible implementation. To leverage that functionality:
// Add AMP theme support for responsive navigation menu
add_theme_support(
'amp',
array(
'paired' => true,
'nav_menu_toggle' => array(
'nav_container_id' => 'site-navigation',
'nav_container_toggle_class' => 'toggled-on',
'menu_button_xpath' => '<xpath to button>',
'menu_button_toggle_class' => 'menu-toggle',
)
)
);Where we pass the “amp” parameter to the add_theme_support functio, and an array of additional parameters extending AMP support:
The next step is to verify the fixes.
To verify the fixes, we trigger a recheck of the post in the compatibility tool, and see that all the errors are gone. Finally, we review the functionality of the post and ensure that everything is in order, including the functionality of the hamburger menu.
At this point the AMP and non-AMP versions of our 2013 theme are identical both in terms of functionality and look-and-feel. Therefore, there is no need to keep both and we can graduate our site to Native Mode. As you can see in the video this is as simple as changing the value of the parameter paired passed to the add_theme_support function from true to false.
In this post we provided a concise yet extensive description of the official AMP plugin for WordPress, with details on its functionality, how its capabilities fit in the developing AMP-first sites in WordPress, and went over a simplified but representative example of how to make a theme AMP compatible.
To learn more about the AMP plugin please check the plugin product site, and follow the development of the project on Github.
This post summarizes a recent talk Weston Ruter and myself gave at Chrome Dev Summit , 2018: Content Management Systems (CMS) are software platforms designed to simplify the creation and management of websites and their content. Nowadays, about 50% of websites are powered by some sort of CMS platform. Below, we discuss our experience moving a complex CMS (i.e. WordPress) forward along the Progressive Web Road by integrating modern capabilities (e.g. Service Worker API) and progressive technologies (e.g. AMP) into its platform and ecosystem, and how the lessons learned can be applied to other CMSes.
As web developers our goal is to maximize the joy our users feel when engaging with the websites we build or the web content we create and publish on the web. And although User Experience is a complex matter, there are common elements in web experiences that users love. Specifically, users love…
The good news is that we can build experiences that fulfill these pillars if we take advantage of modern capabilities the web has to offer. Doing this is what we call Progressive Web Development: developing user-first experiences using modern development workflows and APIs, following coding and performance best practices, and taking advantage of incentive mechanisms (e.g. engagement increases) and validation structures (e.g. performance budgets and others) which are available to us.
The way we go about taking advantage of Progressive Web Development depends on how we go about our creative process in the web.
The things we create on the web fall in a general sense into two areas. On one hand, we can build websites or web apps from scratch, in which case we have full control of the creative journey: from the build process, to the functionality, to the look-and-feel, of our website or web app. On the other hand, we can use some kind of Content Management System, or CMS for short, which are Software platforms providing layers of abstraction and capabilities to make easier to create, publish, and consume digital content on the web.
The first route gives us a lot of power and flexibility, but it is also it requires quite a bit of expertise and resources. The second route, allows us to take advantage of the functionality provided by a CMS, but the experience we provide to our users depends a great deal on the specifics of the CMS we choose.
Nowadays the majority of experiences in the web are created, published, and consumed via some kind of CMS: More than 50% of the web is powered by some form of CMS; and this year there was an 11% YoY growth! [bit.ly/w3tech-stats]. And there are many other platforms that do not consider themselves CMSes but also provide similar capabilities that allow users to create and publish content on the web easily. Therefore, this number is actually much higher in reality.
In practical terms, this means that the CMS space is highly populated and complex. There are many CMS options out there for users to choose from and they come in many shapes and forms, varying across dimensions such as: Static vs. Dynamic, Proprietary vs. Open Source, Special Purpose vs. General Purpose, and others.
But although there are differences between them, they also share lots of commonalities, and many of them face common challenges when it comes to integrating progressive web capabilities into their platforms. To reason about how to tackle such challenges across the CMS space, it is useful to abstract our thinking about these platforms in terms of the fundamental components that make them.
Each CMS has in one way or another a set of components that form a unique ecosystem. There are usually the following components:
A platform Core: which encompasses the main functionality provided by the platform; a mechanism for extending the core functionality of the platform. Such extensions are known as modules, plugins, and themes; a community of developers who are in charge of implementing and evolving both the core and the extensions for the platform; and a user base who either create content on the platform, or consume content from the platform, or both.
When we talk about progressive CMSes, we are referring to bringing the pillars of PWD to the components of a CMS Ecosystem; specifically, things such as:
In order for a CMS to fulfill its potential, all these components need to walk together along the progressive road.
In this post we will describe specific results of efforts our team has been pursuing in the context of a specific CMS, and we will touch upon some of the great work being done by other players in the CMS space.
Our team has been pursuing efforts to bring progressive web technologies to the WordPress ecosystem. WordPress is certainly one of the most influential CMSes out there, as reflected by the fact that it powers about ? of the web today. Given the size and complexity of this ecosystem, addressing its challenges will not only have an impact on a very large swath of the web, but it will also help us to shed light on how to address similar challenges in other CMSes.
Our goals are two fold: to tackle the challenges for the WordPress ecosystem, and to distill and generalize the learnings and solutions we gather along the way and bring them over to other CMSes in the form of objective guidance, tutorials, and technology transfers. Our approach to achieve these goals consists of two parts:
AMP is a web component library, together with a runtime system and a validation framework. AMP provides, out of the box, a set of capabilities and optimizations addressing essential aspects of high-quality web experiences. These include:
Enabling AMP content creation in WordPress means that WordPress developers can take advantage of these capabilities without deviating from their standard content creation workflow in the platform. Such integration has been enabled via the official AMP plugin for WordPress, which is currently at version 1.0-RC2 (available on Github), and version 1.0-stable will be released at the end of this month (November, 2018).
To enable WordPress developers to take advantage of AMP’s capabilities, AMP content creation must be seamlessly integrated into the standard content creation workflow in WordPress. We can envision a path where AMP-compatible markup is generated by WordPress core itself, as an option, similarly to what happened when HTML5 became a thing. Alternatively, such seamless integration can be achieved by a plugin.
The official AMP Plugin for WordPress is a product designed to fulfill two main roles. First, to enhance the development process of AMP experiences in WordPress, such as AMP-compatible plugins and themes. And second, to ensure that AMP compatibility is maintained as a site evolves, so that no invalid AMP is ever served.
The plugin is not a turn-key solution to the “how to AMPlify my site” problem; instead, the AMP plugin functionality substitutes AMP components for their corresponding HTML ones where required and possible (img => amp-img, video => amp-video, etc.), and it aids the development process by exposing sources of validation errors, providing tools to understand the context of such validation errors (e.g. preview integration), and ensuring that only AMP-valid content is ever served for a given WordPress site. These capabilities make it easier for developers to build high-quality AMP experiences (e.g. full sites) and AMP-related solutions (e.g. editors); and enable the ecosystem of developers making themes (e.g. Genesis) and plugins (e.g. Jetpack), to tackle AMP development in a WordPress way, that is, in a way that is integrated with the regular WordPress development workflow and theme/plugin ecosystem.
In its second role, the plugin functions as key enabling component ensuring a site states AMP compatible by keeping developers, implementers, and site owners, always aware of the compatibility status of their site.
The plugin provides all its functionality in an opt-in manner. And users that do opt-in have the option of enabling AMP only on specific sections of their site, and also disable AMP at a granular level (e.g. on a single post).
The second part of our approach to bringing Progressive Web Development into WordPress consists of integrating modern web APIs and capabilities into the WordPress core platform. We want the WordPress platform to support natively things such as: Service Workers, Offline access, Streaming, background sync, etc. The goal of such integration is to provide a consistent and unified approach for WordPress developers to easily access these APIs and capabilities as they develop core functionality, as well as themes or plugins.
In addition to our work on AMP for WordPress, our team focused this year on devising and implementing the integration of some of these building blocks into the WordPress platform, and we did this with an emphasis on doing it in a way that is seamlessly integrated to how things work in the WordPress platform.
The Service Worker API is at the center of many of the advanced capabilities we want to enable natively in WordPress. Nowadays, it is certainly possible to use Service Workers in WordPress, but doing so poses several fundamental challenges that need to be addressed.
First, there needs to be a unified API access for creating and manipulating service workers in WordPress. Without it, if multiple plugins and themes want to leverage the capabilities of this API, they would have to do all the work by themselves, not able to take advantage of any reusability, and running the risk of having collisions among multiple service workers installed on a site, which is not allowed by the API.
Second, providing access to the Service Worker API is just one part of the solution needed; programming the logic of Service Workers is by far not a trivial task. If we want all developers to take advantage of the power offered by Service Workers, an abstraction layer must be added in WordPress that makes doing so easier for developers.
Finally, one of the virtues of WordPress is the flexibility and versatility of its extension mechanism: plugins and themes. The challenge is that these extensions are not sandboxed and consequently, it is very difficult to implement advanced capabilities such as the App Shell model in WordPress because down the road additional plugins can be installed and they can alter/modify the content of a site in ways that breaks these capabilities.
To address these challenges, we have implemented abstractions in WordPress to integrate the Service Worker API into WordPress in a way that is applicable not only to WordPress but also to other CMSes. These abstractions cover three main aspects:
Once service workers are accessible in a unified way, many advanced capabilities are enabled. Some of them are the App Shell model, and offline access capabilities.
One of such capabilities is the app shell model. An app shell facilitates features such as seamless page transitions and offline interactions, similar to the experiences provided by native applications. But implementing an app shell is normally very challenging to do in WordPress due to the lack of sandboxing between plugins and themes.
This is where AMP plugin plays a key role because it enables the enforcing of constraints to ensure that the content on a site behaves in a way that doesn’t break the app shell model, while also ensuring the content loads in a performant way. Furthermore, AMP pages are also specifically designed to be embedded in this way via the Shadow DOM API.
In this demo site we have a WordPress site using the default theme and implementing the App Shell model. Pay attention to the fun spinning logo. Notice what happens when we click to navigate to the “About” page and other pages in the nav menu:
To give you a glimpse of how this is accomplished on the user side, here are some snippets of code any WordPress developer would use in order to take advantage of the capabilities provided by the integration of Service Workers into WordPress core.
First of all, to address the problem of no sandboxing, we leveraged the AMP plugin to make all pages of a site available in AMP. This can be done with a standard add_theme_support() call.
Second, we introduced a way of specifying the dynamic part of the template which changes as you navigate the site. Specifically you can see this via these two function calls placed before and after the content.
And lastly, we extended the AMP plugin to add logic to the page as well as the service worker to implement the app shell. All a theme has to do is to opt-in with another add_theme_support() call like you see here.
The bottom line from these examples is that the complexities of dealing with Service Workers are abstracted away from the theme developer and absorbed directly by the platform.
Beyond the app shell model, the service worker is useful for many other advanced capabilities. As mentioned previously, the service worker also enables offline access.
WordPress themes include a 404 template which is served when the site can’t locate the requested content. We’ve extended the WordPress template system to introduce an offline template which is served when the user’s browser can’t access the site. Thus, in addition to a 404.php template, WordPress theme developers just have to add an offline.php like to their site in order to customize the user experience when facing the loss of connectivity.
The service worker is also useful to cache content the user has visited (or may visit) so that if connectivity is lost, they can continue accessing that part of the site’s content when they are offline. In the snippet above, you can see how the stale-while-revalidate serving strategy is added for navigation requests, so that anything previously visited will continue to be available.
When the user wants to provide a comment on an article but are offline when they try to submit it, the service worker can intercept the request and replay it later via background sync when the user is back online. The developer doesn’t have to do anything as all this happens by default.
The CMS space is moving forward steadily along the progressive web road. Google is working and supporting many of the platforms in this space to help them accelerate their pace, and we are seeing great advances by several of them. Including…
It is exciting to see platforms like these becoming more progressive, and we are looking forward to continued progress by all of them.
We have made significant progress on our efforts in the WordPress ecosystem, but there is still some way to go to get to where we really want to be. We are continuing our efforts described in this post, including the following aspects.
The AMP plugin for WordPress is available on Github today. If you are WordPress developer, the plugin gives you the tools and support you need to make your themes and plugins fully AMP compatible. We are working on expanding the integration of AMP content creation in WordPress, especially in the context of Gutenberg, which is the new editing experience in WordPress.
The integration of the Service Worker API and other PWA capabilities into WordPress core is well underway. These capabilities are currently available as a Feature Plugin, which you can download and experiment with today. We are continuing this effort, and we are working with Automattic and others in the WordPress ecosystem to get the integration merged into core some time not too far in 2019
Finally, we are continuing working with the WordPress ecosystem to help them take advantage of progressive technologies at all levels of their ecosystem.
I have written before about Google’s Progressive Web vision, the work being pursued by the Web Content Ecosystems team, and our commitment to contribute to the advancement of WordPress along the Progressive web road. Our team has spent a lot of time learning about WordPress internals and architecture over the last year, and we are growing to expand our efforts. I am super excited to announce something you may have already heard: Weston Ruter and Thierry Muller have joined the Web Content Ecosystems team at Google!
Weston and Thierry bring many years of combined hands-on experience across different areas of WordPress, including aspects such as managing core releases, extensive experience with core development, building popular frameworks and plugins, and both are strong advocates of the open web. WordPress has been steadily advancing in long strides along the progressive web path and I’m definitely excited for what we’ll be able to contribute in the year(s) ahead, with Weston and Thierry on board. Having them as part of our team, will accelerate the pace of advancing WordPress in particular, and the Web content ecosystem in general, along the progressive web development road. Weston, Thierry, welcome onboard!
At Google we are pursuing efforts that champion awesome user experiences across all platforms in the Content Management Systems (CMS) space. One of those efforts focuses specifically on the WordPress platform. As part of Google’s commitment to these efforts, we are growing a team focused on WordPress Developer Relations. The goal of this team is to pursue scalable WordPress development efforts laser-focused on two main areas:
If you are a strong WordPress developer, you love the web in general and WordPress in particular, and you feel passionate about contributing to making those platforms better, you may be interested in joining our team. That would be awesome! And if you decide to do that, you must go through the interview process at Google.
The WordPress Developer Relations team we are building is part of our Web Content Ecosystems initiative, which itself is part of the Developer Relations (aka DevRel) part of Google.
DevRel at Google is engineering-driven, and therefore the interviews for the positions related to (WordPress) Developer Relations at Google are technical interviews. In this post I offer my perspective into what these interviews are all about, what do they seek to achieve, and how to go about preparing for one. This guidance is applicable to most technical DevRel interviews settings at Google, not only the ones for our roles.
Every interview and interviewer at Google is different, but the interview process is in general well defined. In a nutshell, the process is a technical interview with the majority of questions focused on the basics and fundamentals of the skills associated with a given role. The interview process also seeks to get a glimpse of how you think, how you approach problems and unknowns, and how you interact with your interviewer.
An interview for a DevRel position has two main components, with varying degrees of weight and volume depending on the specific role: Developer Advocacy and Engineering Skills. Once you engage with the interview process, you will be guided to which is the right balance according to the position you are interviewing for.
In the context of developer advocacy, there will be some questions related to areas such as communication skills, community engagement experience, and other questions related to open source projects that you have been involved with, and the development of APIs to be used by the developer’s community. We are looking for strong communicators: engineers that like to engage with community efforts, ideally have a track record of collaborative work, and have a voice in the community — past talks, presentations, etc., are all strong assets. Furthermore, you need to feel comfortable in this role, as you’ll be expected to represent Google around the world — that’s a key requirement.
And in the context of engineering skills there will be a number of technical coding questions related to software development knowledge (algorithms, coding, design); this is where an understanding of fundamental algorithms and data structures is important.
Succeeding in an interview depends on many factors and I know many extraordinary people that have failed interviews at Google and elsewhere. So, failure is not an option, but it is a possibility. And preparing well is the best we can do to maximize the chance of success.
If you have been involved in the WordPress developer’s community, or have been developing on the WordPress platform for a while, you likely understand the advocacy aspects entailed in working with such an open, large, and vibrant community. But in any case, once you engage with the interview process, your recruiter will give you details on what to expect.
Preparing for the engineering part of the interview is in certain ways harder because it involves bringing to your head’s cache memory the fundamentals of Computer Science. This approach to interviews is effective but it is not perfect. Several of the best engineers I know have no formal CS background, and in spite of being able to build a castle on a browser, they can too be vulnerable to this part of the interview process. Nevertheless, knowing this, and no matter what your background is, you can prepare well for an interview anywhere. If you are a good developer, you certainly know the fundamentals, even if the names you use for them are different. Let’s roll up our sleeves, and prepare well.
You should know at least one programming language very well; if you are a WordPress developer, that language would likely be PHP. Since WordPress Developer Relations is part of Web Content Ecosystems, candidates are expected to understand at a good level of depth the fundamentals of the web: the DOM, HTML, CSS, and JavaScript. For example, an understanding of what kind of data structure should be used to implement a DOM abstraction is expected; as well as why having async and await language structures in a language for the web (e.g. JS) would be necessary and important.
In most interviews you will be expected to write code in one way or another. In a phone interview you may write the code on a Google doc; whereas in an onsite interview you will write code on a whiteboard. For many people it is often challenging to write code on a medium other than an editor/IDE. It is very important that you practice writing code on paper or on a whiteboard as you study.
Regarding the code you will be asked to write, it will be expected that you know a fair amount of details about your favorite programming language. Your code should be well written, consistently styled, and as close to compilable as possible. This does not mean that you will fail if you forget a semicolon or an indentation, but coding style and approach are important signals of how you work.
Depending on the role you are interviewing for you will be expected to know more or less about API’s, OOD/OOP, how to test your code, as well as coming up with corner cases and edge cases for your and other people’s code. My approach to this is: prepare as if I was interviewing for the highest level I can possibly seek; doing that forces me to do my best and be as strongly prepared as possible. I am totally fine being over-prepared for an interview because that mitigates the anxiety and pressure I (and others) experience during interviews
I like to think of engineering jobs as jobs in the construction industry; I mean the jobs of the folks that actually build things. All the things we know: algorithms, data structures, design strategies, etc., are tools at our disposal in a toolbox. When you are asked a technical problem your task is two-fold:
Part of your goal in preparing for a technical interview is to make sure you understand the fundamental tools that should be part of the engineering toolbox to fulfill the role you are seeking. If you want to build a wooden house, you better have some nails and a hammer in that toolbox.
You should study up on as many data structures as possible, including those such as Arrays, Stacks, Queues, Hashing, Dictionary, Trees, Binary Trees, Heaps, and Graphs. Ideally you should know these data structures well, the runtime complexity for most their operations, and what algorithms tend to go along with each of them. Knowing this enables you to identify patterns in problems and map them to a domain where the application of a given technique is easier. For example, many problems become easier to solve once their input has been sorted, effectively enabling the application of sub-linear searching strategies (i.e. Binary Search); where easier means, for example, bringing down a quadratic, O(n^2)), time complexity to a more manageable (i.e. O(nlogn)) one for very large input datasets.
Keep in mind that the interviewer will be evaluating not only your technical abilities but also how you approach questions, how you derive the answers, how you communicate, and how you interact with them. We don’t expect you to know the answer to every problem thrown at you in an interview setting; that’s not how the real-world works. We are trying to assess whether we would be willing to sit with you side-by-side in the future and work on a problem that neither of us knows the answer to: we want to see what tools you have in your toolbox, how you use them, and how you handle uncertainty. And at the same time, the interview is an opportunity for you to get a sense of how it would be to work with a Googler.
During the interview make sure to ask questions any time you need clarity. Don’t worry if you don’t know something at first. In such cases, the technique I apply is to bring the problem specification to its fundamental components and engage with the interviewer to clarify what is needed. Often interview questions are deliberately underspecified because interviewers are looking to see how you engage the problem and find a solution. The goal is to show that your answers are organized, demonstrate that you follow a process, and that you take risks and edge cases into account, and can clearly communicate your ideas.
When you are developing an answer to any question it is very important to talk aloud through your thought process. The way I have done it in the past, is to keep the reasoning dialogue in my head flowing with the speakers on. I ask questions aloud to myself (i.e. with constraint X, then I may have options Y and Z; let’s see what happens if…).
Notice that more often than not, a perfect solution is not the ultimate goal. It is very valuable to arrive to a suboptimal solution following a solid reasoning path, and then understand the parts of the solution that could be improved. Therefore, do not hesitate to build upon your answer/solution if you think of ways it can be improved or more efficient. In many cases, the first answer that springs to mind may not be the best or the most elegant solution but it opens the path to arrive at a better solution; refine your answers as you feel necessary. Also, often the interviewer points out with questions towards aspects that may require attention; reasoning about those cases with the interviewer is very useful as well.
It is true that the interview process for tech roles in general is often a grueling experience for many; it has certainly been that way for me sometimes. Nevertheless, understanding what the interview process is all about, and preparing very well prior to tackling it, makes the chances of succeeding much higher and, at the very least, guarantees that you gain the most towards your career capital no matter the outcome.
If you navigate to whatwebcando.today, you will see which Web APIs are currently natively supported by the browser you are using. Although there is some variability between browsers, the important thing to realize is the number and richness of the web APIs that are standard today. With them we can implement awesome and complex web experiences running natively on web technologies: from accessing device features such as vibration signals, the gyroscope and others, to providing native-app-like features such as offline access and add-to-homescreen functionality, to you name it. Even Virtual and Augmented Reality is a thing in the web today.
One drawback of this richness in web capabilities is how complex it has become to develop web experiences that truly take advantage of what the platform has to offer. As the capabilities and complexity of the web platform have increased, there has been as well an expansion in what we call the Capability/Usage Gap, or C/U Gap for short: the difference between what can be done in the web vs. what is actually done in the Web.
In the early stages of the history of web development, say circa 1999, arguably this gap was not too big; we basically needed to master HTML and CSS, we had to develop only for a single target form factor (Desktop!), and the communication networks, albeit slow, were stable and more predictable. Now here we are in 2018: the web platform has evolved significantly; there has been an explosion on the number of development tools, frameworks, and other technologies; there seems to be a myriad of target device types to develop for; and the underlying networks servicing our web sites and apps are challenged and unpredictable. Sustainably mastering and leveraging this contemporary development landscape is really challenging.
The existence of a large C/U gap has serious collateral effects that hinder the mission and success of the web ecosystem. In essence, without exploiting the capabilities of the web platform it is very difficult to sustainably develop and maintain web sites and apps that fulfill the pillars of delightful user experiences. We see quite a bit of evidence of this in the results of studies showing the prevalence of web experiences that exhibit poor load time performance (e.g. 19 seconds to load on 3G; 75% of mobile sites take 10+ seconds to load), and/or poor runtime performance (e.g. unresponsive pages, content shifting, and other misbehaviors). And the bad news is that users don’t like these behaviors at all, as evidenced by the results of studies showing an impact on the revenue potential of sites (e.g. high abandonment rates for slow sites, and inverse correlations between conversions and load time, as well as between revenue and load time).
But perhaps the worst collateral effect of a wide C/U gap is what is known in Sociology as the Matthew Effect of Accumulated Advantage, which in our context essentially means that given the complexity of the development landscape in the web ecosystem, it is implicitly entailed that developers that are super stars, or organizations that can afford large and high-quality engineering teams, are the only ones who can really take advantage of what the web platform has to offer; and that is not what the web is all about.
The bottom line is that we must strive to close the C/U gap in every way we can to make our users happy, support developers’ ability to monetize their sites; and democratize the building of delightful user experiences on the web. There seem to be two main roads towards achieving that goal: the all-developers-do-the-right-thing road; and (2) the progressive-web-ecosystem road.
In a way, the former is the road most traveled: the web capabilities, tools and frameworks, and coding/performance best practices, are all there for us to take advantage of them, and there are lots of advice and guidance to do so; in principle we all could just “do the right thing”. However, that is way easier said than done. This road is loaded with tons of power and flexibility, but also with tons of complexity and cumbersomeness which are hard to master sustainably. Therefore there should be alternatives in the web ecosystem where doing the right thing and providing delightful experiences is easy.
The second road to closing the C/U gap is enabled by what we call a progressive web ecosystem; that is, a web ecosystem encompassing the following aspects:
In a progressive web ecosystem, doing the right thing is easy because the underlying platform is advanced and ever evolving, there are tools and frameworks that pack a punch of capabilities with high usability and efficiency, and we, as a community, can do what humans do best, learn and improve our platform, tools, and frameworks. After that, repeat.
The Web is a complex system composed of many interrelated and interacting parts. To reason about where to focus our efforts to close the C/U gap, it is useful to think about the web ecosystem in terms of a simple model consisting of three layers.
The top layer is composed of a federation of content ecosystems, all interrelated and interacting, giving us the perception of “the whole world wide web” as a thing. The middle layer is composed by Content Management Systems, or CMSes, which are software platforms designed to simplify the creation and management of sites and their content. Notice that the model’s top layer is divided into two equally sized sets; this is because, nowadays, about 50% of sites are powered by some sort of CMS platform, and the other 50% is powered by a variety of configurations of tools and frameworks. And the bottom layer, usually referred to as the web platform, encompasses all the capabilities of the web exposed via browser implementations of Web APIs.
Efforts to close the C/U gap must be pursued across all these layers and at Google we are indeed pursuing significant efforts along all dimensions of the web ecosystem. One of the specific efforts we are pursuing focuses on closing the C/U gap on the CMS part of this model. All CMSes are important and we want all of them to become progressive platforms. In this post we focus specifically on WordPress.
A progressive web ecosystem encompasses the notion of Progressive Web Development: the development of user-first web experiences using modern web capabilities, and coding and performance best practices. The key aspect of this definition is the “user first” part; the core of progressive web development is all about User eXperience; it is all about how our users feel when navigating and engaging with the content and web experiences we create.
When we talk about progressive WordPress we are referring to a WordPress platform where: modern development workflows, coding and performance best practices, and the use of modern Web APIs are commonplace, standard things; that is, a WordPress platform where doing the right thing, and creating user-first experiences is easy.
Now, given the size and scope of the WordPress ecosystem, how can we advance quickly along the Progressive WordPress road? Here is where the Accelerated Mobile Pages project, or AMP for short, enters the game. AMP is an open source library which makes it easy to build web pages and full sites that offer compelling experiences and load near instantaneously. In a nutshell, what AMP does is to provide, out of the box, a powerful set of capabilities and optimizations that address three essential aspects in the development of delightful experiences: load time performance (i.e. near-instant first visit load times); runtime performance (i.e. no un-responsive content); and usability (i.e. no content shifting). Check the documentation to learn more about the AMP project.
If we could integrate AMP into the WordPress platform, we would put at the fingertips of all WordPress developers the ability to take advantage of the efficiency and speed of AMP with minimal effort. That is, AMP brings home the coding and performance best practices part of the progressive WordPress equation. And this is exactly what we have been working on.
In WordPress everything happens in one of three places: in the WordPress core platform; in Themes, which have to do with the look-and-feel of sites; and in Plugins, which have to do with extending the functionality of the WordPress platform. When we talk about AMP in WordPress, we are referring to the capabilities of an AMP Plugin, and the interaction of that plugin with the other components composing a site, such as the underlying theme and the other plugins installed.
The official WordPress plugin enabling AMP in WordPress was pioneered by an open source AMP Plugin initially developed by Automattic. This plugin was created at a very early stage of AMP, as WordPress was one of the earliest adopters of the project. It provided what we call a paired-mode, where for a given content post there was also an AMP version of it based on simple template parts. This mode did a great job enabling AMP on a large number of sites, but it had the main limitation that without significant engineering efforts, the resulting experience suffered from significant visual gaps between the AMP and non-AMP versions of the content, and significant functional gaps between the two versions (e.g. no hamburger menu, no ‘Load updates” button, etc.).
As the result of a joint effort between Automattic, XWP, and Google, the plugin has evolved significantly and steadily and now there is no need for a paired mode because the plugin generates experiences without neither functional nor visual gaps between the AMP and non-AMP versions. The latest version of the plugin, 1.0, effectively brings the power and efficiency of AMP to WordPress via a seamless integration with the standard WordPress content creation flow.
The AMP plugin will reach version 1.0 with an ETA of December 2018, and this version includes:
With v1.0, WordPress developers get significant support making it easier to create native AMP experiences without sacrificing neither the fidelity and functionality of their content, nor the flexibility of the WordPress platform.
The first step towards native AMP WordPress sites is a fully AMP compatible WordPress theme. In our AMP Conference talk, we showed such a theme for a native AMP News site:
Also, in our Google I/O talk you can get a glimpse of an all-AMP WordPress theme, built leveraging the capabilities of the new Gutenberg editing workflow:
And also, we described a summary of the process required to convert the 2015 WordPress theme to become all AMP. In this case, the plugin’s capabilities did most of the work, the whole process entailed only three steps:
Without trying hard to tune the performance of this site, we observe good Lighthouse scores for the native AMP News WordPress site, influenced by the coding and performance best practices enabled by AMP.
And here you can see the demonstration of the Adventures Travel site, showing a native AMP theme fully developed using Gutenberg.
We have made significant progress along the progressive WordPress road with the advances in the plugin and its integration with the platform. Still, there is quite a bit of work ahead of us to further advance along the progressive WordPress road. The main areas we are focusing our efforts are: enabling the AMP Shell Architecture in WordPress to enhance the user experience beyond first visits, on the user’s onwards journey; providing a Progressive Theme Boilerplate/starter kit, to facilitate building progressive themes from scratch; and adding quality incentives to the ecosystem, to empower developers and site owners to develop and choose themes and plugins based on user-centric metrics, rather that just public’s opinion. A little more specifically:
The App Shell navigation model is a pattern for architecting sites in a way where the static elements in a page can be cached easily, and therefore loaded reliably and instantly on navigations; and the non-static components of the page can be loaded dynamically.
Enabling the App Shell Architecture in WordPress would enable several benefits and capabilities to sites, such as: reliable performance that is consistently fast, native-like interactions, and a reduction in data consumption. And this work involves the integration of the Service Worker API into WordPress core. Very excited about this effort!
One of the key elements in a progressive web is tooling to help developers do the right thing in an easier and faster way. An important tool to have in the toolbox of WordPress developers is one that facilitates the development of Progressive WordPress themes. Our colleagues at LinkedIn Learning have been busy developing a Progressive WordPress Theme Boilerplate, which is a theme development starter kit that makes it easier for WordPress theme developers to get from 0 to a fully progressive theme. The boilerplate comes out of the box with:
The main developer of this project, Morten Rand-Hendricksen, who is also a Senior Staff Instructor at LinkedIn learning, will be publishing soon a course on the LinkedIn Learning platform which will teach all about this boilerplate; and that particular course is going to be free. Don’t miss it!
One of WordPress major virtues is the flexibility of the platform. As a developer you can accomplish basically anything you can imagine; this is demonstrated by the large and ever expanding ecosystem of plugins available to add functionality and customize your website in a myriad of ways. However, this same virtue can also turn into one of the major challenges of the platform. Even taking into account plugins that are very good (i.e. follow coding/performance best practices and coexist nicely with other site components), the likelihood of having plugins colliding in their interactions (or impacting performance) when jointly activated in a site, is definitely not negligible.
We can deal with this challenge by introducing to the WordPress ecosystem tools that facilitate the verification of well-defined quality standards to allow developers to measure how good their products are in terms of UX-related metrics, and empower WordPress site owners to make choices about which plugins and themes to use, based on actual quality as opposed to only on popularity. We are pursuing efforts in this area, for example in the context of projects such as XWP’s Tide and Lighthouse.
Success on the web is all about building user-first experiences: it is all about UX. WordPress is an amazing platform and we are striving to close the Capabilities/Usage gap and enable content creation and consumption flows satisfying the pillars of delightful experiences. v1.0, the latest version of the official AMP plugin (currently in alpha), brings the power and efficiency of AMP to WordPress via a seamless integration with the standard WordPress content creation flow effectively enabling native AMP experiences in WordPress without compromising content fidelity or surrendering the flexibility of the WordPress platform.
Stay tuned for new developments in the areas we mention in this post. We will participating in WordCamp EU in Belgrade this year where we will talk and show the latest progress on our efforts. Hope to see you there!
If you only have one minute to read this post, here is the gist of it: WordPress users can get a first-class AMP experience without compromising the fidelity of their content or surrendering the flexibility of the WordPress platform. Get a glimpse of what is possible with AMP in WordPress by watching our AMP Conf 2018 talk! https://youtu.be/GGS-tKTXw4Y If you have a few extra minutes, follow me to the next paragraphs to learn more about the state of AMP in WordPress.
In a nutshell, WordPress is: a Content Management System (CMS) for websites; the largest player in the CMS space with ~59% of market share, powering about ? of the web; and a thriving ecosystem of plugins, themes, hosting providers, agencies, freelancers, all working together on the creation of WordPress-powered content. But when I think about WordPress I think about one thing: there are many users publishing and consuming content via WordPress-powered sites, and all of them should get an awesome UX on the platform.
And since AMP is all about enabling an awesome (fast) User eXperience to all users, in this post we discuss two things: (1) the case for AMP in WordPress; and (2) the state of the art of AMP in the WordPress Ecosystem. Curious? Read on!
One of WordPress major virtues is the flexibility of the platform. You can accomplish basically anything you can imagine, as demonstrated by the large and ever expanding ecosystem of plugins available to add functionality and customize your website in a myriad of ways. However, this same virtue can also turn into one of the major challenges of the platform. Even taking into account plugins that are very good (i.e. follow coding/performance best practices and coexist nicely with other site components), the likelihood of having plugins colliding in their interactions (or impacting performance) when jointly activated in a site, is definitely not negligible.
This virtue/challenge duality of the WordPress ecosystem has its parallel in the open-web web publishing ecosystem. In the latter, there is nothing restricting a web developer to hamper the performance of a site by following counterproductive coding practices (e.g. loading scripts synchronously, render-blocking CSS). And even if the developer builds a site impeccably, adding a third-party JS library could spell a performance disaster.
AMP emerged as a response to that reality, bringing forward effective design principles and control mechanisms that enable sites to offer predictable performance. The effectiveness of AMP and its impact on UX is demonstrated by plenty of data and examples in the wild. And WordPress publishers would also benefit greatly from having more control of the UX of their sites. This could be achieved by adopting coding and performance best practices in WordPress development, and integrating AMP with the WordPress ecosystem to make the WordPress platform more performant.
The plugin work for enabling AMP in WordPress described in this post, was pioneered by the AMP Plugin initially developed by Automattic. Subsequently Google and XWP joint the open source development effort to help evolve the plugin significantly. Want to know what is possible with AMP and WordPress nowadays? Let’s see!
The initial goal of the AMP plugin was to enable AMP for WordPress.com VIP sites. It certainly met its goals for VIP, and it was also adopted at some level by the general WordPress community either directly, or through other plugins built on top of it. In the context of its initial objectives, the main characteristics of the early versions of the AMP plugin make sense:
These characteristics worked well for sites that have good engineering support to tailor the AMP content to their needs. However, at a larger scale, the adoption of the plugin was more challenging because the baseline capabilities did not offer enough functional and visual parity between the two versions.
Google and Automattic started working together last year with the goal of bringing the AMP plugin to its maximum expression, and enable a rich AMP experience for all WordPress sites. A few months after, XWP engineering team also joined the project to push for the same goals with the expanded scope of integrating modern web technologies in general into the WordPress ecosystem. And since everything is open source, the WordPress community has also been part of this work through many contributions. In the past few months versions 0.5 and 0.6 of the plugin were released, including bug fixes, expanded support for embeds, support for pages, parity with AMP library specification, better configuration capabilities, and much more. And after these, we have focused on one of our main initial goals; since the beginning we have had our sight set on enabling an organic AMP experience in WordPress; that is, an experience where there is no need for a pair mode (unless applied by choice) because there are no gaps, either functional or visually, between the AMP and non-AMP versions of content published in WordPress. Without such a gap, WordPress publishers are able to publish a single version of their content which is beautiful, feature-rich, all-around WordPress, and runs at the speed of AMP! We call this an all-AMP experience.
The aforementioned pair mode approach makes sense when there are functional and visual gaps between the AMP and non-AMP versions of a given content. In such a case the pair mode keeps a “version” of the original content and an AMP’d version of it. By enhancing the AMP plugin and devising the right mechanisms for theme/plugin integration, we can eliminate these functional and visual gaps an enable WordPress sites to offer a single, all-AMP experience.
An all AMP experience in a WordPress site requires: (1) a plugin that enables a seamless integration of AMP into WordPress; (2) a theme that integrates nicely with AMP (adds AMP theme support); and (3) the seamless coexistence of third-party plugins in an all-AMP site.
We have made good progress on the plugin work and by the time you are reading this post, many goodies will be available in version 0.7 of the plugin (release). We have also made progress on defining an approach for building progressive themes; that is, themes built following the latest coding and performance best practices, leveraging as much as possible progressive technologies in the web platform, and integrated seamlessly with the AMP plugin. The result on this work was presented at AMP Conf (video), and a prototype of an AMP-Compatible theme is available, and you can experience it live as well. And the cherry on top of the cake, is the work by Morten Rand-Hendricksen on the development of a Progressive Theme Boilerplate project, which enables theme developers to go from 0 to starter progressive theme in an easy way. Today, a native AMP experience in WordPress is possible! On the theme side of the story, native AMP support is enabled by:
And on the AMP plugin side of the story, the seamless integration of AMP into the WordPress workflow is enabled by:
The combination of these features and capabilities allows WordPress publishers to run a pristine WordPress site that is all-AMP! The following screenshot shows a demo of an all-AMP WordPress site; there is no pair mode, and look at the console!
AMP integration with the WordPress ecosystem has come a long way. But there is still quite a bit of work ahead of us; very exciting work indeed! Some of the main areas currently capturing our focus include:
Advances in the web platform all aim at improving the user experience along different dimensions. AMP design premises focus on the performance of the mobile web and the associated quality of the perceived user experience. With the AMP plugin and a modern approach to building themes, WordPress-powered publishers are able to leverage the performance and ecosystem advantages to be gained from using AMP. There is still quite a bit of work to be done. These are very exciting times to be a web developer, and also a WordPress developer! We are certainly excited as we continue advancing towards our goals and unlock the even greater potential of the WordPress platform. And remember: everything we are working on is open source, including AMP! All the work described in this post is the result of a great collaboration between Automattic, XWP, Google, and the WordPress community. Want to help? Join the effort and participate with your contributions, feedback, and engagement!
At Google we care deeply about the long-term success of the open web: we work on the core technologies and standards that power the web platform, we develop and maintain the Google Chrome browser, and we build tools and frameworks to help developers build amazing experiences on the web — just to name a few. As a result, it shouldn’t come as a surprise that we are also huge fans of WordPress, which enables publishers to easily create and deliver rich web content to users all around the world.
Taking a guess, I would say the above is not a big shock or surprise. However, did you know that Google is also actively engaged and looking for expert WordPress developers to support and accelerate success of the WordPress ecosystem? It’s true, and it could be you!
The web platform has been evolving rapidly in recent years and it continues to evolve as we speak; the bar for web experiences has been raised significantly. This is reflected by all the buzz around the term Progressive Web Apps, which essentially refers to websites (and web apps) built using the latest capabilities supported by the Web platform; things like Service Workers, Push Notifications, identity management, security, etc. Similarly, the evolution of the platform defined by the WordPress ecosystem has being evolving as well at an accelerated pace.
The goal of our team is to help bring these two worlds together and work with both the WordPress community and core developers, and the web platform developers to enable amazing user experiences on the web — powered by WordPress.
Our WordPress vision covers a lot of exciting work across the full breadth of the WordPress ecosystem: collaborating on WP core, developing themes, plugins, and WP-tailored tools and infrastructure, and engaging with the broader WordPress community of publishers.
Sounds interesting? Come join our amazing Google Developer Relations team. We’re looking for passionate WordPress experts, developers, and advocates that are willing to roll up their sleeves and help us with:
Some examples tasks that are part of our daily job are…
Hopefully this description gives you a good idea of the scope and vision of the WordPress-related work we are pursuing in the Web Content Ecosystems Team at Google. Aren’t you super curious and excited? I am!
Are you passionate about WordPress and its ecosystem? Do you have strong expertise developing with WordPress? Are you interested in getting involved in projects aimed at making WordPress better at all levels? If your answers to these questions are on the affirmative quadrant you may be interested in joining Google to work with us. Looking forward to hearing from you!
[This post was originally posted at Torque’s magazine]
Google participated at WordCamp US 2017 with a booth centered around performance. One side of the booth showed a data-driven glimpse into the state of the WordPress ecosystem in terms of key performance metrics and coding best practices, as well as the use of tooling (e.g. WebPageTest/Lighthouse) for assessing the performance characteristics of specific WordPress sites. The other side was shared with the excellent XWP engineering team, where they showcased a new auditing tool we’ve been collaborating with them called Tide, which enables quality assessment of plugins and themes.
Our goal was to engage with the WordPress community and start a discussion around the performance of the WordPress ecosystem, and we consider the event a success! The experience was superb, and here is our perspective of it.
The CMS space encompasses an important cross section of the web; there are a plethora of players out there, and many of them offer pretty cool technologies. In terms of functionality and capabilities WordPress has strong similarities with other CMSes on the market, but arguably there are a few things that set the WordPress ecosystem apart:
But in essence, the missions of Google and WordPress are naturally aligned. A central part of Google’s mission is to contribute to the prevalence of a healthy, flourishing, and vibrant web. We are investing significant efforts and resources to help bringing a delightful (i.e. user-friendly, fast, engaging) user experience to all users: everywhere, on every device, and over any connection. Similarly, a central part of WordPress’s founding mission is democratizing web publishing, which itself implies providing an awesome UX on WordPress-powered sites for all users: content creators, site owners, developers, and content consumers. Therefore, by working together we can double down on our efforts and accelerate the success of our overlapping missions.
Google has always been very supportive of efforts to enable a better web. This year we kicked off a concerted effort aimed at tailoring our guidance in our areas of expertise in the broader web (tooling, data, scalability, systems infrastructure, progressive technologies, and performance) to accelerate the adoption of modern web technologies and coding best practices in the WordPress ecosystem. Early on in this effort we realized that the way to go is engaging with the WordPress ecosystem, in the same way that we engage with any ecosystem in the web: bringing our voice and our receptiveness to the WordPress table, and finding solutions to every requirement with joint efforts.
Our presence at WordCamp advanced our goals significantly. We spent two dense days talking nonstop about performance; looking at data showing performance gaps between WordPress and the broader web; telling about the capabilities and data sets available for all to start gaining a deeper understanding of performance at all levels; looking at detailed performance of many WordPress sites owned by the attendees using essential performance analysis tools such as WebPageTest and Lighthouse; and our XWP colleagues showcased and demoed Tide, an audit tool enabling everyone to check the analysis results for 40K+ audited plugins. Tide was also introduced to all attendees by Matt Mullenweg at the State of the Word; we are excited about the great reception of Tide and about its roadmap for 2018 — it will be a critical piece of the WordPress ecosystem.
We also learned and got important feedback from a wide range of attendees, freelance developers, consultants, and site owners from all walks of life. One piece of valuable feedback was related to the frustration and feelings of powerlessness from WordPress developers who feel the pressure from clients to add features, which most of the time come in the form of plugins, and not having a way to determine if the addition of a given plugin will adversely affect the performance of the site they are building. This particular issue is what the Tide project addresses: to empower developers and site owners to choose plugins that are both feature-rich and performant.
And to wrap up we attended Contributor’s day, an awesome experience as well; open source at its best. I would say that every open source community, at the scale of WordPress, would benefit from the community organizing wisdom of the WordPress community.
The web platform has been evolving rapidly in recent years and it continues to evolve as we speak; the bar for web experiences has been raised significantly. This is reflected by all the buzz around the term Progressive Web Apps, which essentially refers to websites (and web apps) built using the latest capabilities supported by the Web platform; things like Service Workers, Push Notifications, identity management, security, etc. We will continue working with the WordPress community, combining our areas of expertise, to accelerate the integration of these modern technologies into WordPress and evolve the ecosystem at par with the evolution of the broader web. Some of the efforts that are on their way include:
Being part of WordCamp US this year was a superb experience. We are excited and committed to working with experts in the WordPress ecosystem, including Automattic, XWP, WP Engine, 10Up, and others, as well as with the many core contributors in the WordPress developers community, to help moving WordPress forward. Stay tuned!
Google participated at this year’s WordCamp US, in Nashville, TN. One of the aspects that impressed me the most was the last day of the event, Contributor’s Day; a full day when part of the WordPress community convenes to contribute with WordPress. This is how it works.The WordPress open source community is organized as a group of teams; each with an area of specialty: Design, Mobile, Accessibility, etc. Contributor’s Day is a day when contributors get together to work on projects and teams of their choosing. Some are long time seasoned contributors, while others are newcomers that want to learn how to contribute back to WordPress and do so for the first time. At the end of the day, a long line forms at the front of the room, with one representative from each team summarizing what their respective teams accomplished, learned, and started to work on during the day.
Witnessing Contributor’s day was an experience of open source organizing at its best. I would say that every open source community, at the scale of WordPress community, would benefit from the community organizing wisdom of the WordPress community.