Gutenberg 0.7.0 Adds Opt-In Usage Tracking

Gutenberg 0.7.0 was released just before the weekend with improvements to the writing flow and greater flexibility for theme authors to add their own customizations. Last week’s version 0.6.0 release made significant changes to the way paragraphs are created within text blocks, allowing for blocks to split when pressing enter. However, it inserted a “New Paragraph” placeholder that was distracting for users trying to stay in the flow of writing.

Version 0.7.0 hides placeholders on focus, providing a cleaner experience of starting a new paragraph. After a user has already intuitively initiated a new paragraph by pressing enter, the “New Paragraph” placeholder holds little value. Removing the placeholder is a minor improvement that brings Gutenberg closer to providing a better experience for long-form writing.

This release also introduces theme support for customized color palettes and a shared component, such as cover text and button blocks. The sample code below shows how easy it would be for theme authors to implement their own color palettes.

Gutenberg contributors have also added theme support for wide images. According to the inline docs, this allows for some blocks, such as the image block, to define a “wide” or “full” alignment by adding the corresponding classname to the block’s wrapper ( alignwide or alignfull ).

These additions offer theme developers a better picture of where Gutenberg is headed in regards to themes. The plugin’s contributors are slowly building in more points of customization so that theme authors can add or override Gutenberg’s styles and provide additional opt-in features to their users.

Theme support for wide images has already been committed to Tammie Lister’s experimental Gutenberg Theme. The project was created to showcase how Gutenberg will interact with WordPress themes and is still a work in progress.

Gutenberg Adds Opt-In Data Collection

After updating the Gutenberg plugin to 0.7.0 and navigating to the editor, users are presented with the option to opt into data collection about their usage of the editor. The usage data, which is anonymous and does not include post content, is sent to WordPress.com for future analysis. Gutenberg contributor James Nylen explained how the data tracking works in a post on Make.WordPress.org.

“The Gutenberg plugin contains a mechanism to count how often specific actions occur over time,” Nylen said. “If the user has previously clicked ‘Yes’ on this screen, and an event occurs that has an associated bumpStat call in the Gutenberg code, then this event is sent to WordPress.com servers by loading a special ‘pixel’ image.”

Gutenberg’s tracking code stores the “group” and “name” sent with the bumpStat call (short strings of text), along with the time the event was recorded. Nylen said the team will use the data to improve the editor based on usage patterns. This data collection information is currently only available to those with access to WordPress.com servers.

“As Gutenberg is an open-source community project, we view this data as belonging to the WordPress community, so we also plan to make this data available via a public dashboard,” Nylen said.

He shared an example of the data that has been collected from the plugin over the past few days since 0.7.0 was released. This chart is a preview of the number and types of blocks that users have added to posts while testing the editor.

“The approach taken here is very similar to Calypso’s event tracking code,” Nylen said in the pull request for adding the data collection. “We can use the data added in this PR to inform various decisions such as default order for blocks and whether some blocks are less suitable for core, and more generally this is a very useful technique to collect user experience data.”

The majority of Gutenberg’s chief contributors are Automattic employees, so it makes sense that they would use the options and infrastructure available to them to quickly get data collection going in Gutenberg. However, the data from these tests needs to be shared with the greater WordPress community as soon as possible, since it is being collected in the name of the WordPress project. Ideally, it would have been set up to be displayed publicly before asking users to opt into the collection.

Gutenberg contributors are also considering making the data collection more modular so that it could be used with other WordPress feature plugins or existing features in the future.

“Maybe the tracking could be its own module, it could be useful outside of the editor (and other WP feature plugins later),” Riad Benguella said. “Longer term (or not), WP.org needs its own tracking infrastructure and this could be very useful to enhance WordPress.”

10 Comments


  1. Stop for a second and imagine if a contributor from a company other than Automattic submitted a pull request that sent opt-in tracking data to their own company’s servers. Think about how crazy that sounds.

    This leaves a really sour taste in my mouth.

    Report


    1. “After updating the Gutenberg plugin to 0.7.0 and navigating to the editor, users are presented with the option to opt into data collection about their usage of the editor”

      They make you choose if you want or not, a lot of plugins do this and ask for the info to make the plugin better.

      Report


      1. The problem is not the opt-in tracking. The problem is the data is being transmitted and stored by Automattic, a for-profit company. To make matters worse, nowhere on the opt-in does it state this. It leaves you with the impression the data is being collected by WordPress.org.

        I clicked “Yes” on the tracking on Friday. It wasn’t until Sunday that it was disclosed via a blog post that the data was being sent to Automattic.

        I’m sure there was no malicious intent by adding the opt-in tracking. However, it is extremely tone-deaf given the current state of WP.

        Report


  2. As Gutenberg is an open-source community project, we view this data as belonging to the WordPress community, …

    I would like to ask what is the size of that community? Also, does “view” mean you know?

    Report


  3. An interesting comment on the metabox discussion WRT Gutenberg:

    Does WordPress intend to formally deprecate Metabox API?

    No.
    […]

    Yet, there are multiple ways in which meta-boxes and extensibility could be handled:

    * If we detect a meta-box is registered we can fallback to the old interface, nothing changes.
    * We could split editing the content and modifying meta information into two screens or stages.
    * We can try to see how feasible it is to render these as they are (PHP) below the content: #2251.
    * A theme/plugin/CPT could unregister the new interface as needed.
    * Various items that relied on meta-boxes could be converted to blocks for UI (still storing data separately).
    * We could implement API based meta-boxes extensibility like the Fields API.

    Or any combination of these.

    I know a lot of people have been worried about continuing use of meta boxes in the editor view. It looks like there is no need for concern, as the team are trying to find the right way to integrate the meta boxes with the new flow that Gutenberg provides.

    Report


  4. Great post, Sarah! This is a very interesting and hot topic.

    I think that tracking usage data is the best way to improve Gutenberg. Actually, I think it’s the best way to improve any plugin or even WordPress itself, as I discussed in my talk at WCEU17 (WordPress Plugin and Theme Directories Don’t Love Developers). So, yes, I completely agree with Riad Benguella when he says “WP.org needs its own tracking infrastructure and this could be very useful to enhance WordPress”.

    However, WordPress users might feel differently. During my talk, I could see the audience had mixed feelings. Some people (especially those that run a business) were really interested in tracking anonymous usage data. Others (concerned users) were completely against this “Big Brother” behaviors. Either way, it’s a discussion we should have.

    My opinion? I think that any developer who really wants this data will find a way to get it (implementing its own tracking solution or using alternatives such as Vova Feldman’s Freemius), regardless of what “the community” decides. So, why don’t we create this tracking module within WordPress? It’d be open source and the data we’d collect could be completely open, anonymous, and so on.

    Report


  5. The core telemetry ticket remains closed even though there is obviously a need for further discussion. Matt’s argument for closing it – that “it is not within the three focus areas” – is no longer valid as telemetry is being discussed in direct relation to the Editor focus (Gutenberg), yet it remains closed. In the ticket Matt says telemetry is a “terrible idea” without further details and ends with “I doubt that anything actionable or useful will come of it that couldn’t be obtained by non-data-collecting means.”

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

    Report


    1. I understand why it was removed. It was nice to see a glimpse into what’s possible if more time and energy was spent on the idea. Right now, the focus is to get the damn thing to a usable state, then energy can be spent on the surrounding issues. Makes sense to me.

      Report


    2. Matt says two words and all community effort is gone. Suddenly they changed their mind, obviously :) This “community” is amazing :)

      Report

Comments are closed.