#Mor10isAnOld – the 40th Birthday Fundraiser

To celebrate my 40th year on this planet, I’m doing a fundraiser for the Norwegian Refugee Council and a month-long AMA in video format, and I invite you to take part! Each day from today until my birthday on October 17th, I’ll make a video where I answer one question from you. It can be about anything, but I suspect it’ll mostly be centered around web design and development and the internet and how it shapes us. So, if you have a burning question you’d like me to answer, send it my way and it may end up in a video!

Somehow I made it to 40. On October 17, I break that imaginary temporal threshold that puts me squarely in what Norwegians refer to as the “middle age”. In the eyes of my younger self I guess that makes me, officially, “an old”. The path leading here has been long and complex, with twists and turns and loops and seemingly unmountable obstacles. Yet I am here, in my office, writing this. And for that I am grateful.

Some 20 years ago, while riding the subway from downtown Oslo to Blindern station on my way to a philosophy lecture at the University of Oslo, I ripped a page out of my notebook and scribbled down a question:

“If you knew this was your last day on earth, what would you do to leave the world better than you found it?”

Such are the dark ruminations of an immature mind deeply immersed in the impossible task of understanding life, the universe, and everything.

I folded the slip of paper, wrote “read me” on the front, and placed it on an empty seat across the aisle. At the next station a group of students entered and one of them picked up the paper and read it. Then he read it out loud and they all started laughing. What a ridiculous question. Yet minutes later they were deep in conversation about what they had accomplished in life, and more importantly what they wanted to accomplish.

I repeated this experiment for weeks, spending an unreasonable volume of time leaving notes and listening to the conversations that followed on the subway. Looking back on it now, it is clear what I was really doing was attempting to crowdsource an answer to the hardest problem: the meaning of life.

As I round this arbitrary milestone of my life, I am no closer to answering that question I left on a subway seat on the other side of the world all those years ago. Maybe the meaning of life will only reveal itself two years from now? As my search continues, I am putting forward an interim answer, and for that I need your help.

Looking at the world today, and back at the world I grew up in, I see an endless succession of refugee crisis, observed from afar and from which my life and the lives of those around me have rarely been impacted. And I’ve come to realize that there, but for the grace of privilege and luck and geography and geopolitical machinations over which I had no impact or involvement, go I. My life so far has been one of opportunity and open doors, one in which the fear of bombs and bullets and terror has been in the abstract. And that is not because I made the right choices or because I did the right things or because I worked hard or believed in the right powers. It is because I happened to be born to a middle class family in Norway. During peacetime. That’s all.

Somehow I made it to 40, and I think it’s high time I gave that snarky kid on the subway in Oslo got a concrete answer:

For the next 30 days, I am running a fundraiser for the Norwegian Refugee Council (NRC), a non-profit organization helping refugees all over the world, and I invite you to join me. Our family (my wife Angela, our son Leo, and I) are donating $1000 CAD and will match donations up to another $1000 CAD. My employer LinkedIn will match my $1000 donation through the LinkedIn Gives program. And I’m asking my family, relatives, and friends, to make a donation to the NRC in lieu of presents for my birthday.

That’s where you come in. I also hope to convince you to donate if you have the means. If you have a dollar or two, follow the link and add your contribution. If you don’t, just help spread the word using the #Mor10isanOld hashtag and maybe someone else in your circle will. And if you don’t want to donate to this organization, or even this cause, find something else you care about to contribute to. Or take the time today to tell someone in your life how important they are to you. Do your small part to leave the world a better place than you found it, in whatever way you see fit.

Somehow I made it to 40, and I plan on sticking around for many years to come. For as long as I’m here, I’ll do my part, and use my privilege, to leave the world a better place than I found it. Starting right here, right now, with this article. I invite you to join me.

Speaking Engagements

How Not to Destroy the World: Ethics in Design and Technology – Smashing Conference Freiburg, 2018

All the links from the talk

Unsplash photos from the presentation


Gutenberg, Forks, and the need for an LTS version of WordPress

Over the past week, developments which I predicted back in December last year have come to fore, and I am deeply concerned about the effects they will have on WordPress (the application) and the community unless we take decisive action.

Short version: For various reasons, many WordPress users will be faced with a complex dilemma when 5.0 and Gutenberg comes out:

a) Get the latest version of WordPress and risk compatibility issues / costly retraining, redesign, or entire rebuilds, and/or other problems, or b) choose not to upgrade and end up running an old and eventually insecure version of the content management system.

So far, the response from WordPress leadership has been to install the “Classic Editor” plugin which as the name suggests reintroduces the classic WYSIWYG editor once the Gutenberg Block Editor becomes the default. This is, in my opinion, a dangerous road to go down both for the end-user and WordPress itself. 

Classic Editor as a permanent solution won’t work

Classic Editor is a bit like using a band-aid to plug a hole in a ballon as you are inflating it. It may work right now, but as the balloon continues to grow, the band-aid not only won’t do its job, it will actively harm the balloon itself. Here’s why:

Gutenberg as an editor replacement is just the first step for the WordPress Next project. The next step for Gutenberg is to migrate to the Customizer, at which point blocks move out of the editor and into other interfaces and displayed spaces in WordPress. Which means the Classic Editor can’t do its job and another patch plugin needs to be introduced.

It does not require a lot of imagination to see how this solution is not scaleable.

On top of this comes the issue of plugin and theme developers having to serve up solutions that work both for Gutenberg and non-Gutenberg installs which dramatically increases complication, cost, and management. And the “this plugin only works with Gutenberg” path flies in the face of the deeply held WordPress ideology of everything working for everyone and breaks the reasonable expectations of end-users. 

From my perspective (you are free to disagree – please leave your own opinion in the comments below) the Classic Editor plugin was a misstep and should be abandoned for a more robust solution, A Long-Term Support version of WordPress 4.9.x (link to Trac ticket):

WordPress LTS

On the release of 5.0, give site owners the option of “freezing” their install at 4.9.x by choosing to stay with a terminated LTS (Long-Term Support) branch which only receives security and maintenance updates, and only for a specified number of years.

Practical implementation

When 5.0 ships, site owners are presented with a panel similar to the mockup added below where they can choose to upgrade to 5.0 or stay with the LTS version. Information about each choice and what that entails is provided in links in the panel.

Proposed modal window offering upgrade to WordPress 5.0 or off-ramp to LTS version.

Users who choose the LTS version are given two options in the Updates panel: “Update WordPress LTS” (security updates only) or “Upgrade to 5.0“.

Why this is necessary

While the majority of WordPress users will weather the 5.0 upgrade without issues, a not insignificant group will run into issues which may end up requiring a significant investment in time or money or both which they are not able to take on at this time. Providing a clean off-ramp allowing them the time and space to prepare for the upgrade or otherwise resolve their unique challenges is essential to avoid harm to the end-user.

Additionally, offering a LTS version provides a relatively uncomplicated solution to the problem of backwards compatibility faced by many plugin developers.  As I mentioned earlier, the popularity of the Classic Editor plugin means plugin developers have to either ship two versions of their plugins (Gutenberg and Classic) or ship a larger plugin with both options built in. An LTS version of WordPress would mean these developers could offer a similar LTS version of their plugin as it was when 4.9.x was released, and continue development on their 5.x support plugin as normal.

This will split the community

A public LTS version of WordPress will split the community between those who upgrade to 5.0 and those who stay on LTS. This is neither new nor is it unusual. There are countless WordPress sites out there intentionally or unintentionally running older versions already, and within the community there is talk of launching an official fork of WordPress which would see a true split.

An LTS version is the lesser of all evils in this situation in my opinion. It is an unavoidable fact that some users will choose to not upgrade to 5.0. How this issue is addressed will impact the development of the application, its community, and its users long term. Offering a Long-Term Support version, and making each user who considers it aware of what this means, falls squarely under the open source philosophy and the WordPress philosophy of democratizing publishing. Granting users agency and the capability to choose solutions that work for them is a key ingredient to keeping the open web alive. That’s what we all strive for. 

LTS is what WordPress already does

WordPress has a long shipped security updates for older versions for an extended period of time, so technically this is no different from what is already happening. My proposal is to make this an explicit feature of the WordPress 5.0 release by giving each site owner the ability to opt out of the 5.0 upgrade until they are ready by activating a “WordPress LTS” release.

On a personal note…

This proposal might seem controversial, or inflammatory, or playing into the #WPDrama or #GutenDrama or #GutenSpiracy or whatever. It really is not. All I’m proposing here is to take something we already do – offering LTS versions of every version of WordPress – and make it a feature rather than something which happens behind the scenes. It changes nothing about how Gutenberg works or how it is implemented, and changes nothing about how we work. Only two minor things are different:

  1. Every WordPress site owner is offered an explicit choice to upgrade to 5.0 or stay with LTS for however long they want (within the clearly defined support timeline)
  2. The Classic Editor plugin is deprecated as a solution to Gutenberg upgrade woes.

That’s my take. Now I want to know what you think. Leave a comment here, or share your thoughts with me on LinkedIn or Twitter

Oh, and this proposal is also a Trac ticket: #44851


WordPress: The 15 Year Revolution

Tuesday May 27th, 2003 is a significant marker in the history of the web. On that day 15 years ago, in a tiny corner of the internet, a new software package titled “WordPress” made its debut. It’s goal: Make this thing called “blogging” possible for anyone and everyone.

Just three years earlier I sat in a lecture hall at the University of Oslo where a professor explained how open source software was a dead-end; the fever dream of anarchist software developers with no footing in the real world. “Free software,” he proclaimed (I’m paraphrasing here), “is a waste of time. Ten years from now we will look back on this whole movement in shame.” The same professor also wrote off JavaScript as an irrelevant experiment in useless application design soon to be extinguished.

Looking back at these statements from today where open source software powers much of the internet and JavaScript is eating the web it is hard not to scoff at his seeming ignorance. But back then Open Source really was a fringe movement in an industry still in its infancy, and it was hard to imagine how giving software away for free and allowing anyone to copy it and turn it into whatever they wanted would be a good idea.

All things to all people

Today WordPress powers more than 30% of the top 10,000,000 sites on the web. It is the engine driving your friend’s dog blog, the website of the flower shop down the street, the membership site for your gym, the fundraising site for your favorite charity, the newspaper you read every morning, and the sites of your local, federal, and international governments. If you spend any time on the web today, you are almost guaranteed to encounter a WordPress site. Though you probably would never know unless you inspected its code base. From its roots as a “blogging platform”, WordPress has evolved into a full-featured Content Management System and web publishing platform.

GPL or bust

The key to WordPress’ success, what turned a tiny blogging application into the go-to publishing application for the web, was captured in the last sentence of the announcement post published all those years ago:

“WordPress is available completely free of charge under the GPL license. Enjoy!”

The GPL, or GNU General Public License, is one of the most radical “copyleft” licenses software can be published under. It embeds in the software itself the “four freedoms that every user should have:

  • the freedom to use the software for any purpose,
  • the freedom to change the software to suit your needs,
  • the freedom to share the software with your friends and neighbors, and
  • the freedom to share the changes you make.

The GPL is also passed on to any derivative work meaning anything built on or with WordPress (which is GPL) automatically inherits the same GPL license.

The use of GPL in WordPress is not unique. What makes WordPress special is how fiercely and literally the GPL is enforced by project leader Matt Mullenweg. Over the 15 years of WordPress’ life, Mullenweg has entered the fray numerous times to protect and uphold what he sees as the absolute freedoms of every user of WordPress. And though this has caused no small amount of controversy, it is in my opinion one of the main reasons for WordPress’ success and its transformative impact on the web and the web and internet industries.

Democratize publishing

With Mullenweg’s vision as its foundation, a thriving world-wide community of content creators, software developers, and community organizers have made reality of the project mission, to mission of the WordPress project is to “democratize publishing through Open Source, GPL software.” Thanks to WordPress, anyone with an internet connection and access to basic web hosting can create their own website to publish their ideas, creations, products, and communities. And thanks to the GPL embedded in WordPress, anyone can contribute back to the project in any way they desire. Around the world, more than 1300 Meetups and hundreds of WordCamps bring users, administrators, designers, and developers together to learn about and share their knowledge of and build the application and its community. Around the world thousands if not millions of people make a living thanks to WordPress. And around the world, millions of people leave their mark on the web through their WordPress sites every single day. No small feat for a bunch of files you can download for free.

WordPress Next

As we enter the 16th year of WordPress, much of what made the application unique has been adopted by its competitors and companies including Mullenweg’s own SAAS platform are offering WordPress-like features with extended management options for a premium. Where WordPress goes next will determine not only its future success or whether it reaches the lofty (and in my opinion irresponsible) goal of powering 50% of the web, but whether it will continue to push the web forward and keep web publishing democratic and accessible to all.

With a 30% market share WordPress has the potential to drive the web forward through participation in web standards bodies and by simply implementing its own opinions of how the web and the internet should work. So far, the application and its community has been agnostic to the point of riding the back seat in these conversations; a consequence of its roots as a tool built by the people who show up with no clear management structure or long-term strategy. This inaction has not gone unnoticed, and large influencers like Google have realized WordPress can be used as a vehicle to bring us to the future of the web faster. One of our major challenges as a community will be to navigate this new reality and find ways to make decisions about how WordPress should wield its power to democratize publishing beyond its own borders.

The challenges facing the application are also internal. As I write this, the WordPress project is in the midst of its largest and most revolutionary evolution to date. Project Gutenberg, announced some 18 months ago, reimagines the very nature of content creation treating each piece of content placed in a post, or page, or view as an individual block with its own unique properties. The WordPress block concept is a fundamental transformative departure from the core feature of the application itself – the content blob – that may carve a new path into the future for web publishing as a whole. The question yet to be answered is whether this new vision for the web will bring another generation of users to the WordPress table. Only time will tell.

WordPress and me

I published the first post on my own blog a late summer evening 11 years ago. At the time I’d transitioned from table-based layouts through Flash and DWTs and ASP.NET to Mambo and Joomla! and Drupal and eventually WordPress. What I found in the little blogging engine that could was an end-user experience for my clients that allowed me to build what they needed and them to manage it without running the risk of destroying everything in the process. Over the years I’ve transitioned from WordPress user and implementer to theme developer, educator, and project contributor. I’ve met some of my closest friends and collaborators through WordPress. I attribute much of my career to the success of WordPress. And I have every hope that 15 years from now my son will be building his own web experiences using software that traces its roots back to the application I write this article in today.

We have proven the democratization of publishing is possible. Our next challenge will be using that power to bring democracy to every corner of our shared world. I invite you to join us.

gutenberg WordPress

Gutenberg and the Future of WordPress: Conditions for Success

NB: This article is part of a series on the new WordPress editing experience called "Gutenberg". If you are not familiar with Gutenberg, check out the first article in the series.

As the Gutenberg project moves ever closer to merging with WordPress, users, administrators, designers, developers, and core contributors are raising concerns about timelines and what will happen to the community once the merge is complete. I've been thinking about this for the past year and over the last few weeks I've had several conversations that have helped bring into focus the key conditions I think need to be in place for Gutenberg to be a success. I present them to the community to start the conversation. Please add your own voice in the comments below, on social media using the #Gutenberg hashtag, on your own blog or website, and in the GitHub repository. Every viewpoint is relevant, every voice matters.

Before we continue, be advised these are my personal opinions. As of this writing I am not a functioning member of the Gutenberg team nor am I speaking on behalf of anyone other than myself. What you'll read below does not indicate nor dictate the future course of this project, they are the conditions I personally think need to be met for the success of the project. In my opinion. Clear? Ok, you can continue:

Condition 1: Accessibility

The web was built to make content and information accessible to anyone and everyone. WordPress' core principle is to "Democratize Publishing" and a key part in achieving this is to make sure WordPress itself and the code generated by WordPress is accessible.

The first condition for the success of Gutenberg is accessibility, both on the back end and on the front end. WordPress core is ostensibly accessible, and over the past several years significant efforts have been made put accessibility at the center of every conversation about WordPress. As Gutenberg merges with core, it is imperative that accessibility is not just maintained but improved.

Web accessibility is not just good practice (an inaccessible site is a broken site) and a moral duty, it is also becoming a legal requirement in many regions. Meeting this condition is a necessity for the future success of WordPress and the millions of sites it runs.

For this condition to be met, Gutenberg and the merged version need to be able to pass independent comprehensive accessibility review.

Condition 2: Change moratorium and ample ramp-up time

During his State of the Word address at WordCamp US 2017, project lead Matt Mullenweg suggested Gutenberg would be "ready for the widest audience" in April 2018. The comment is ambiguous (view it for yourself here) and it is not clear whether he means the beta plugin is ready to be pushed to all WordPress users for testing or Gutenberg is ready for core merge or if he thinks Gutenberg will be merged in core and WordPress 5.0 will release in April. I think (hope) he means Gutenberg will be ready for full-scale testing in April and will be pushed out so people can test it before it is merged to core at that time. If I'm informed otherwise I'll update this section.

Be that as it may, the second condition for the success of Gutenberg is that the community is given enough time to prepare before WordPress is updated. To achieve this, once Gutenberg is considered ready for core merge, the Gutenberg plugin should be advertised to all WordPress users along with a training regimen, and I propose a 4-6 month moratorium on Gutenberg and core updates from the time Gutenberg is considered ready and WordPress 5.0 ships. This sounds extreme, but it is necessary for several reasons, most notably:

Gutenberg changes how WordPress works

WordPress users need time to prepare for Gutenberg. They need comprehensive documentation and training, and need time to figure out how to run their blog/website/e-commerce store/community using this new version of WordPress. This is especially important for large-scale operations like educational institutions and publishers as they typically have complex publishing processes in place that need to be updated.

Without a significant marketing push and proper documentation and training, WordPress users will feel as if their platform has been changed without their knowledge and it will cause them unnecessary hardship. Bridget Willard has written about this in more detail. A moratorium would provide ample lead-up time to ensure WordPress users and the businesses that rely on the platform have time to prepare.

Plugins and themes need to be updated in advance

Because Gutenberg changes the way WordPress works, many themes and plugins will either work differently or not work properly with the rollout. Unless they are updated in advance. A change moratorium provides enough time to allow plugin and theme authors to a) learn how to build solutions for Gutenberg, and b) roll out necessary updates in advance of the final release. The goal here is to ensure when the switch happens, WordPress seamlessly transitions from old to new and everything continues to work.

For that to happen, plugins and themes must already be updated to account for Gutenberg before WordPress updates. The alternative, to update WordPress and then be told to update a long list of plugins, or worse be told some plugins or themes will no longer work, is not tenable as it will appear to the people who use WordPress as WordPress being broken.

If/when plugins and themes are updated, they will have to invest time and money in providing documentation and training for their users to help them prepare. Which leads us back to the first point: Gutenberg changes how WordPress works.

Condition 3: A line in the sand

This is easily the most controversial point, so I'll reiterate this is my personal opinion.

The third condition for the success of Gutenberg and the WordPress of the future is for WordPress to cleanly fork itself at version 5.0. Let me explain:

Even if the two other conditions are met: Gutenberg sets a new gold standard for accessibility on the back- and front-end, and the community is granted ample time to prepare, train, reengineer, and build their businesses around Gutenberg, there will still be a large number of WordPress sites and solutions that will be negatively affected by this update. There are many reasons for this:

  • Plugins and themes that won't update for various reasons.
  • Custom setups that would need to be completely reengineered to work under Gutenberg.
  • Custom setups that are too expensive to update.
  • Processes and procedures that require expensive retraining of tens or hundreds or thousands of users.
  • Legacy systems that can't be updated to Gutenberg for various reasons.
  • your reason goes here.

Bottom line, there are valid reasons why many WordPress users and WordPress sites can't or will be unduly negatively affected by the upgrade to Gutenberg. The only responsible course of action from WordPress is to provide a clean solution for these users to opt out of the upgrade and stay on the last stable release, which will be 4.9.x. In other words, WordPress forks itself at 5.0 creating "WordPress Classic" for users and sites that can't or won't upgrade.

For this to work, WordPress Classic would need to accept a feature freeze receiving only security updates. If it evolves independently, we'll invariably end up with two incompatible solutions.

Here's the thing: If this is not done, the community will fracture and those who rely on pre-Gutenberg WordPress will either refuse to upgrade causing major security and maintenance issues, force a fork which will split the community, or abandon WordPress for other options. Neither of these outcomes are beneficial to anyone.

Benefits of a clean fork

Cleanly forking WordPress at 5.0 brings benefits for the Gutenberg project and for WordPress as a whole:

  • The requirement of backwards compatibility can be removed, or reset to 5.0 meaning WordPress' code base can finally be updated and modernized.
  • Data structures inside WordPress can be properly modularized and Gutenberg can move beyond the content blob.
  • Plugin and theme authors can ship solutions that only work for WordPress Classic or WordPress New removing the need to support both the new and the old editor.
  • PHP and other infrastructure version requirements can be updated without leaving people behind.
  • People who can't or don't want to upgrade can cleanly choose WordPress Classic as their solution.
  • If people try to install WordPress in an environment that does not support the new version, they can automatically be sent to WordPress Classic for the top-of-the-line experience we have today.

Drawbacks of a clean fork

There are significant drawbacks to forking WordPress as well:

  • WordPress would be forked, which splits the community.
  • Maintaining two versions requires twice as much work as maintaining one.
  • Eventually a fork will evolve on its own, feature freeze or not.
  • A fork provides "bad optics" as they say.

Dangers of not forking WordPress

There are significant risks to not forking WordPress, and at present we are headed straight toward all of them. Here's a small sample:

  • Not forking WordPress means the project needs to retain backwards compatibility. That means continued support for both the current (classic) editor and the ever evolving Gutenberg experience. This will hold back and eventually block future innovation and WordPress will become a monster even Dr. Frankenstein would shun.
  • The current approach to handling plugins and themes lacking Gutenberg support is to allow them to declare lack of support and force a fallback to the old editor. This will be used by plugin and theme developers who do not like Gutenberg to force WordPress to revert. Which in turn holds back future development. It also means plugin and theme developers have to ship code that supports both the classic editor and Gutenberg because any other theme or plugin may force WordPress to roll back. This issue was brought up by Kevin Hoffman brought this up during State of the Word, and the answer he got was, in my opinion, less than satisfactory (judge for yourself).
  • One of the major issues with WordPress is how it handles content. Presently all post content sits in the post table as a single blob which makes it impossible to effectively query data without querying the whole post content. To get around this problem theme and plugin developers use custom fields, but these just stash all the info in another table so we end up with two blobs. To truly meet the goals of Gutenberg, the blob needs to be broken up and the data structures of WordPress need to be rearchitected. If WordPress is not forked, this will not be possible and the current structures will eventually render the application obsolete.
  • Finally, if a clean fork is not created, parts of the community will shard off and force a fork. This will be damaging to the community as a whole because it will create an antagonistic relationship between those who support the "classic" fork and those who stay with the Gutenberg branch. With a clean fork, much of this animosity can be avoided or remedied, and we won't end up with a fractured community.

Your voice matters, and I want to hear it

Now that you know what I think needs to happen for this project to succeed, I want to know what you think. Like I said before, add your thoughts in the comments on this article, share them on social media using the #Gutenberg hashtag, publish your own articles, file issues and contribute to the project on GitHub, and keep the conversation going. I'm looking forward to having this conversation with you.

This article was cross-posted on LinkedIn Pulse.

gutenberg WordPress

WordPress is Changing. Here are 3 Things You Need to Know About Gutenberg

Everything you know about WordPress is about to change. The project codenamed "Gutenberg" is reimagining what content creation and editing on the web should look like and how it should work. Some time in 2018 the way WordPress works and the way you work with WordPress will change in a fundamental way, whether you are a visitor, a content creator, an administrator, a designer, or a developer.

Last weekend I had the privilege of presenting a talk titled "Gutenberg and the WordPress of Tomorrow" at WordCamp US in Nashville. You can view the video below and slides below. Once you're done, keep scrolling to see the three things you need to know as WordPress moves into the future.

1. Gutenberg is coming, fast. Be prepared.

If this is the first time you've heard about Gutenberg, this is the time to familiarize yourself with the project. The second half of Matt Mullenweg's State of the Word talk from WordCamp 2017 is a good place to start:

The project will probably reach maturity around April 2018 and I expect WordPress 5.0 will ship with this new interface to every WordPress site around June/July 2018. That means right now you have roughly 6 months to prepare.

Here are my recommendations:

  • Familiarize yourself with Gutenberg by installing the plugin on an experimental site.
  • Train your contributors / staff on content creation and management using Gutenberg.
  • Check with the developers of your themes and plugins that they are preparing for Gutenberg.
  • As the release gets closer, start testing your sites with Gutenberg to ensure everything works properly.

2. Gutenberg is not just an editor replacement, it changes everything!

The core concept of Gutenberg is every item you add to WordPress is a "block". Every heading, paragraph, image, blockquote, list, and other content you add is a block, and every block has unique properties and settings. That means when you create content, you can work with and customize each individual block, move those blocks around, and even make individual blocks reusable so you can build them once and use them in different locations and different views.

Notice how I said "views", not "posts and pages"? This is key: The current version of Gutenberg replaces the content editor. That's step one. Once it merges into WordPress proper, the project will expand its scope to encompass the Customizer, and eventually the way we create and mange content in WordPress will undergo a complete overhaul. Today we think of creating posts and pages. In the WordPress of Tomorrow, we will be making blocksand placing them in views. As weird as it sounds, the concept of post and pages is going away, and along with it the WordPress theme as we know it will likely fall to the wayside replaced by something all together different.

To wrap your head around this, imagine every piece of content you create as a literal building block and the environment (or view) the visitor accesses a space where you can place and organize those blocks in any combination and configuration you want. Then realize the current limitation of the browser viewport (the rectangular area within the screen you probably use to access the web) is going away thanks to everything from text-to-speech browsers to VR/AR/MR/XR.

Bottom line: The way we interact with content on the web is changing in a fundamental way and Gutenberg is what can bring WordPress into that future.

3. Gutenberg needs you!

Which brings me to the final point: Gutenberg is not ready, and the Gutenberg team needs your input and help to get the project and WordPress where it needs to go. Whether you are an absolute beginner and just started using WordPress yesterday or you have been contributing to WordPress core since the first line of code was written, your input is vital for the success of the project.

Here are some ways you can help:

These are exciting times and we are privileged to be part of a community that values every member and hears every voice. Your contributions matter. Make your voice heard!

This article was cross-posted on LinkedIn Pulse.


The Case for Telemetry in WordPress

Update August 10, 2017: After publishing this article I reopened the Trac ticket arguing the reason for closing it was no longer valid in lieu of Gutenberg’s collection of telemetry. A few hours later it was announced that usage tracking will be removed from Gutenberg and the ticket was closed as the original argument for closing it is once again accurate.

This is an expanded version of a Twitter thread from earlier today.

#WordPress needs a core method for collecting quantitative user data through telemetry (aka “metrics”). I wrote a post about this on my blog back in December 2016 and filed a ticket on the WordPress development system Trac at the same time. That ticket was promptly closed by project lead Matt Mullenweg arguing “it is off the table for 2017 as it is not within the three focus areas.”

Since then, Gutenberg – the proposed new editor feature for WordPress – has introduced an “opt-in usage tracking system” (telemetry) meaning the argument that telemetry is not within the three focus areas (of which Gutenberg is one) is no longer valid.

One of the biggest challenges WordPress faces is the lack of reliable data about global day-to-day use. Like most Open Source projects, WordPress has relied on community feedback as it’s primary data source. Which is fine for a small project. Problem is WordPress is a Very Big Project with global reach and the majority of it’s users never interface with the community.

I like to say we, the people who talk about, provide feedback for, and design/develop WordPress are the 1%. I wrote about this on my blog in December 2015.

I now think the number is more like 0.1%.

Making decisions based on the traditional community feedback model is making decisions without knowing anything about the majority of users. Some will argue this is fine, that WordPress is developed by those who show up. That’s not a workable or responsible model for a project. It also goes against one of the core principles of WordPress itself, that “the core should provide features that 80% or more of end users will actually appreciate and use,” although the validity of the 80/20 rule was put into question by project lead Matt Mullenweg earlier this year (I wrote about this on my blog as well).

We, the people who build WordPress, have a duty of care to the people we build it for. And those people are not us.

“We can just do user testing,” you say? Sure. Let’s do proper qualitative user testing. That requires staffing, funding, and infrastructure. User testing for a project like WordPress is non-trivial. It requires professional analysis.

Testing one UX feature (like a view) would take 3 dedicated testers, at least 10 subjects, 3 weeks, and result in a >10 page report. User testing like this would be great, but it’s not something we are doing right now, and it’s not on the horizon either. Which brings me to telemetry and quantitative user metrics in WordPress.

Done responsibly and with care, telemetry can be a treasure trove of information for the evolution of WordPress. The key is collecting the RIGHT metrics using the right methodology. Telemetry data often ends up being a numbers soup because too much irrelevant data is collected. What I’m proposing is a lean and targeted approach to telemetry in WordPress:

  1. Telemetry should be an opt-in option that when activated installs a plugin. Admins should be informed about this option by the WordPress dashboard when WordPress is installed and reminded at regular intervals that the plugin is available and whether it’s activated.
  2. Anonymize all collected data at client level before submission.
  3. Collect only basic data at the core level of the plugin (WP/PHP/MySQL version, locale, language, etc.)
  4. Provide up-front info to end-users about what data is currently collected and what it’s being used for, with opt-out options for the plugin as a whole and for granular data collection.
  5. Allow for targeted data collection based on research needs.
  6. Store data on servers owned by the community (not corporate interests). Share data openly to ensure transparency.

Telemetry implemented in this way would give WordPress the ability to inform decisions about current and future features. Some, notably project lead Matt Mullenweg, have said this is not necessary, that it won’t be useful. I disagree.

In my view, making decisions that impact millions of users without metrics to back them up is irresponsible and quite frankly foolish. We run the risk of doing a bear’s favor: something we think will help that actually hurts, all because we don’t have enough information.

There are plenty of arguments against telemetry: anonymity, security, oversight, Big Brother, competitive advantage, etc. If we do this right I am certain we can build a system that alleviates the concerns over anonymity, surveillance, etc. Couple that with up-front disclosure, transparency, and explanation of what data is collected and why and people will sign on.

As for the competitive advantage aspect; we don’t want to share data with our competition; that runs counter to the Open Source idea in my opinion. We can and should share this data with everyone, because it’ll make the web a better place for everyone. It has purpose beyond WordPress. Not collecting this data because we don’t want competitors to have it is like leaving a broken window unmended lest it be broken again.

In short, WordPress needs telemetry. There’s a ticket on Trac proposing this, and Gutenberg has a PR for telemetry.

Inexplicably the Trac ticket is closed because “it is not within the three focus areas” which thanks to Gutenberg is not the case.

What WordPress needs is an open debate on this topic. What are the arguments for and against? What can be gained and what is lost? Should we do this? And if so, how do we do it in an open, transparent, and responsible way that helps inform and elevate the conversation while looking after the interests of all WordPress users?

This discussion belongs in Trac in an open ticket. Closing it down before a proper discussion has been allowed is not the Open Source way.

As of this writing the WordPress telemetry ticket remains closed:

Cross-posted from the original at LinkedIn.

Speaking Engagements

WCEU2017: CSS Grid Changes Everything (About Web Layouts)

Below are the advanced slides for my WordCamp Europe 2017 talk CSS Grid Changes Everything (About Web Layouts) presented June 17th, 2017 in Paris, France:

From the website:

“CSS Grid is now live in all major browsers, and with it everything we know about web layouts changes! Imagine drawing a grid in the browser and placing content in one or any number of cells without having to change the HTML or source order. And imagine changing that grid on the fly using media queries or JavaScript while keeping the HTML markup clean and accessible. That’s what CSS Grid does, and that’s why you should be using it today.

The CSS Grid Layout Module introduces a native CSS grid system, provided at the viewport level, that achieves what CSS frameworks and popular grid systems could only dream about: Responsive, flexible, pure CSS grid layouts, independent of document source order, that allow us to treat the browser as a true design and layout surface.

In this talk you’ll get an intro to CSS Grid and learn how it changes pretty much everything when it comes to layouts on the web. Through examples, code snippets, and practical demos you’ll learn how to use CSS Grid in a theme for modern responsive layouts, and you’ll also learn how to handle older browsers without Grid support in a clean and straight-forward way.

CSS Grid is here, and you can start using it today. This talk shows you how to do it right.”

Links from the talk

Video of the talk will be posted here as soon as it’s available. Until then, read through the slides above and follow the links for more information on this transformational CSS module.

Header photo by Mark Sallman.

My Opinion WordPress

The End of 80/20 and the Future of WordPress

History is filled with events that at the time seemed like footnotes but in hindsight revealed themselves as pivotal turning points. Such an event may have occurred Friday March 3rd, 2017. Buried in the comments section of a post on WPTavern a comment from WordPress co-creator and project lead Matt Mullenweg reads:

It might be time to retire 80/20 from the philosophy page, as it is seldom used as intended.

Below the surface of this short sentence lies a highly stressed fault line, and what Mullenweg seems to suggests is to deliberately trigger its release, causing a tectonic shift that will permanently change how WordPress is developed and as a consequence how content is published online.

For the record I do not know what Mullenweg thinks about the 80/20 rule beyond this single sentence. The following is my personal thoughts and reflections around the 80/20 rule. I am merely using his comment as a starting point for a discussion.

tl;dr: The 80/20 principle as applied in the context of current WordPress development is an ideal without a tether to reality. However much we say we develop the application for 80% of users, the reality is we know almost nothing about 99% of WordPress users. That means at best the rule is without consequence, at worst it is doing harm. The big question is how do we change our philosophy to solve this issue?

I have some thoughts, and I’d also like to hear yours. But first, a short primer:

What is the 80/20 rule, and why does it matter?

The 80/20 rule is a term you’ll hear a lot in business circles. It is called the Pareto Principle and goes as follows: “for many events, roughly 80% of the effects come from 20% of the causes” so for example “80% of your sales come from 20% of your clients.” This principle shows up everywhere. As an example Microsoft found that “fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in a given system would be eliminated.

The Pareto Principle is also sometimes used in reverse, as is the case in the WordPress Philosophy (my highlighting):

“The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.”

This version of the 80/20 principle is a good one, both from a development and a business standpoint: Build solutions that work for 80% of the user base, and let the remaining 20% find or build extensions to meet their needs.

The Challenge

As WordPress continues to grow in popularity and user base, changes made to the application and related services like the website are met with tighter scrutiny and critique. Many WordPress users are expressing a feeling of disconnect between themselves and the people who build the application, and changes are often criticized for being imposed in a “top-down” fashion without taking end-users into consideration. This is what the post on which Mullenweg left his comment was about. There are many reasons for this (most of which I will not get into here), including how the 80/20 principle is used when decisions are made.  

For the 80/20 principle as described in the WordPress Philosophy to work, the design and development team must have a firm fact-based understanding of the entire user base so they can identify the needs and abilities of the 80% and build solutions for them. That in turn requires data. The problem for WordPress is that data does not exist. As a result, any decision made under the banner of the 80/20 principle is actually a decision made based on the educated guesses of the development team and their immediate circle of contributors. This is even stipulated in the WordPress Philosophy (my highlighting):

“while we consider it really important to listen and respond to those who post feedback and voice their opinions on forums, they only represent a tiny fraction of our end users. When making decisions on how to move forward with future versions of WordPress, we look to engage more of those users who are not so vocal online.”

When Mullenweg says the 80/20 principle “is seldom used as intended” I am fairly certain this is what he’s referring to. Put bluntly, we can’t say we’re building solutions for the 80% because we don’t have the data to back that claim.

The Fork in the Road

When Mullenweg suggests removing the 80/20 principle from the WordPress Philosophy page, I think he is really suggesting replacing the 80/20 principle with something more practically feasible that moves the project forward. Lacking any further details, I’ll extrapolate the two possible paths I think this move could lead us down:  a Contributor-centric approach and a User-centric approach.


If we simply remove the 80/20 principle from the philosophy page, we will effectively end up where we are right now, with a Contributor-centric approach: WordPress is designed and developed by the people who contribute to the project, and user testing is done primarily on contributors and active community participants. This is already stipulated in the WordPress Philosophy:

“We do this (engage more of those users who are not so vocal online) by meeting and talking to users at WordCamps across the globe, this gives us a better balance of understanding and ultimately allows us to make better decisions for everyone moving forward.”

This Contributor-centric approach is common in open source communities, and has its origins in how open source projects come about: A small group of contributors build a solution for the contributors and anyone else interested. Even when the actual users outnumber the contributors, this dynamic remains because it’s what made the project successful.

It is important to understand the Contributor-centric approach is not based on a “we know what’s best for the user” attitude, rather “we know the application better than anyone, and we do what’s best for the application because we want it to grow and succeed.”

The overarching principle here is one of meritocracy: decisions are made by those who show up, and those who contribute the most have the most sway when decisions are made. This stems from the reality that open source contributors typically volunteer their time and are more likely to work on things they care deeply about. Allowing them to choose their own focus, and keeping a flat/no management structure is thought to ensure they have a continued vested interest in the project. In the background of all this there is also a real concern that limiting the autonomy of contributors may lead them to move on to other less restricted projects.

The Contributor-centric approach leaves itself open to critique that it is rooted in privilege: to have influence and “show up” requires availability of free time and a fairly high level of technical expertise, neither of which we can reasonably expect or demand from the average user. When the barrier to entry, or even constructive feedback, is high (as is the case with WordPress), the only voices heard are from the experts. The Contributor-centric approach solidifies this development model, and if that’s the path we choose to take, it needs to be explicitly stated.


If we either commit to the spirit of the 80/20 principle or replace it with a similar principle, we are adopting a User-centric approach. User-centered design is a well-established method of iterative design based on extensive user testing and data gathering. From Wikipedia:

“user-centered design tries to optimize the product around how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product”

The User-centric approach is what most major software and service vendors use to develop their products. It typically involves large-scale quantitative data gathering through telemetry, surveys, and other statistical methods as well as qualitative user testing on individuals and groups. A common argument against the user-centric approach is that it’s costly and slow, but in my experience the major challenge with it is that it tends to cause cognitive dissonance in stakeholders: User research often concludes that what designers and developers think is the best solution is not what the end-user prefers. This sometimes leads back to the “we know what’s best for the user” argument which is why some development teams cycle back and forth between the two approaches.

Another common critique of the User-centric approach is that the user does not always know what they want or need, and maybe more importantly, they don’t know what’s possible. The extreme version of this argument is Steve Jobs’ famous quote “A lot of times, people don’t know what they want until you show it to them.”

The User-centric approach requires rigorous discipline and careful management to work: Research and data gathering has to be unbiased and statistically sound and significant. At the same time, too much research and data, or research and data that has little value, can cause stagnation and confusion. And to top it all off, the User-centric approach will result in contributors having to work on projects they are not passionate about or even disagree with simply because they are not building solutions for themselves but the end-users.

In many ways the User-centric approach is a walk across a tightrope: Success is only achieved with training, planning, focus, and constant corrections. For the WordPress community, this would be a whole new way of doing things requiring a radical shift in attitudes.

The Duty of Care

Before we can make a decision about where to go next, we need to consider our Duty of Care: When we add, augment, or remove a feature in a tool used by someone else, we have a duty of care to that person to ensure your actions do not negatively impact them. The Decisions, Not Options principle comes into play here. From the WordPress Philosophy:

“Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration.”

On the surface, the duty of care outlined here is to protect the user from confusion and frustration. Deeper down, we find the duty of care when making a decision on behalf of the user. The reasonable expectation from a user is that the application (and by extension its designers and developers), makes decisions that are in the best interest of the user.  

Which begs maybe the most important question:

How do we, the people who build WordPress, best meet our duty of care to the people who rely on WordPress in their personal lives, their communities, and their businesses?

Where do we go from here?

Whatever decision is made, it will cause a tectonic shift in how WordPress moves forward. That’s why every voice needs to be heard.

It is no secret that I land firmly on the side of the User-centric approach. From my experience user research is an integral part of any successful project, and the larger the user-base, the more important this research gets. I agree with Mullenweg that the 80/20 principle is not working, and I believe the solution is to realign the WordPress project to a more user-centric approach. This is not a quick and easy pivot, and it will require fundamental changes to how WordPress development is done on all levels. For one, we will need to gather large volumes of data on the existing user base and implement statistically sound methods for large-scale user testing of redesigns and new features. The first step in that process is to implement telemetry for the core application, a proposal that has already been shelved by Mullenweg.

Now you know what my answer is, but I’m just one of thousands of contributors, one of tens of thousands of active community participants, one of millions of WordPress users. I want to know what you think. Everyone who uses, interacts with, or contributes to WordPress has a stake in the project, and this is a decision that needs your voice. So, speak up and share your thoughts. I am listening, and I guarantee I’m not the only one.

Cross-posted on LinkedIn Pulse.


The Case for WordPress Telemetry

WordPress prides itself on being an application built by the user for the user. The problem is with the popularity and reach of WordPress today, the distance between the WordPress 1% (or even .1%) and the average user is becoming so vast we (the people who contribute to WordPress core) know almost nothing about the actual people who use WordPress or how they use the application. This will become more of an issue as the application evolves, and it is high time we do something about it.

Lack of data means we’re flying blind

During the development of WordPress 4.7, I was involved in several conversations centered around assumed use of features. The general argument was that based on the 80/20 rule, certain features should be added while others should be removed. I kept brining up the well known fact we don’t have a clue what features 80%, or even 20%, of WordPress users actually use so any claim of validity in the 80/20 rule is guesswork at best, and in response one developer told me, point blank, “we know what the user wants.” I don’t know about you, but in my book that is not the way to build an application for real people.

What we need is raw data based on actual use, and lots of it. What we need, is telemetry. And there is ample industry precedence for collecting such telemetry, in online and offline applications and even in the WordPress ecosystem.

Here’s what I propose:

WordPress core should ship with an opt-in Telemetry feature that collects anonymized data on feature and functionality use.

This is in line with what major software providers do, and it is a feature most users will be familiar with.

The purpose of the Telemetry feature is to collect relevant data about how WordPress is used in the wild. This begs the questions “what is relevant data?”, “who decides what data is collected?”, and “who has access to the collected data?”

Here’s how I imagine it would work:

Implementation and activation

WordPress Telemetry is shipped as a core feature in new installs and an update to existing installs. When Telemetry is first added to the site, the admin gets a prompt asking if they want to contribute anonymized use data to the WordPress project. The default setting is “No” and the admin can change this to “Yes”. Once activated, the Telemetry setting can be changed at any time by the admin.

In more detail:

  • The opt-in selector for the feature should be surfaced on first install or when the site is updated to the first version of WordPress containing the feature is installed.
  • For new installs the opt-in question should appear on the 5-minute install page along with “Allow search engines to index the site” or similar.
  • For upgrades, the opt-in question should be revealed in a dedicated modal.
  • The feature should be disabled by default and the admin can make an active choice to participate.
  • The feature should be controllable at any time through a dedicated section under Settings->General
  • It is possible the best way to make users feel this feature is not a Trojan horse is to ship it as a plugin that auto-installs on opt-in and auto-uninstalls on opt-out.

Data collection

As a benchmark, some core data should always be collected, including but not limited to:

  • Number of themes and plugins installed
  • Frequency of use of specific views (Settings, Customizer, etc)
  • Current version
  • Update status
  • Locale (generalized to country)
  • Language
  • etc

In addition it should be possible to push custom queries to activated users to test for specific interactions, as an example how many users click the Underline button in TinyMCE. I’m not sure exactly what the best approach here is, but this is one idea: The feature queries a centralized service on a weekly / monthly basis to get instructions on what type of data is currently being collected.

The decision on what data to be collected should be done by committee based on current active tickets and features in development that require user data as well as longitudinal studies of user behavior.

Anonymity and transparency

A core requirement for the success of this feature is that data collection must be 100% anonymized. No data collected can be traced back to an individual user. Ideally the feature itself will be built in such a way that even accidental collection of personal data is impossible.

At any time, information about what data is being collected should be available to end-users both on a dedicated page on and through the setting in admin.

All data collected should be made public for scrutiny and use to ensure transparency and enable actual use.

Practical way forward

To prove the viability of this feature I propose a slow incremental deployment: Start with collection of certain uncontroversial datapoints like current language setting, number of themes and plugins, and one UI interaction that needs testing. Once this MVP has proven itself effective, a larger scale testing program can be shipped.

I’ve already created a ticket for this proposal on Trac and I’d love to hear your thoughts and ideas on the topic. To keep the conversation in one place I request that all comments are left on the Trac ticket. For this reason I’ve disabled comments here.

Update February 3, 2017

Matt closed the ticket shortly after an article published in WP Tavern brought it to the surface. I personally think that closure was premature and will continue pushing for the feature. In the meantime I’ve reopened comments here so you can voice your opinion on the matter.


My Opinion

Rearview Mirror: A look back at 2016

Earlier today I was asked to share with my team what accomplishments I was most proud of in 2016. Rolling back the tape and looking at everything that’s happened in this year, I realized I should do some sort of year in review / inventory to document what I’ve done and challenge myself to do better in the coming year. So, borrowing a page from fellow Learning author and person I aspire to be more like Carrie Dils’ blog, here is my 2016 Year In Review / Inventory / Reflection: / LinkedIn Learning

In addition to regular updates of WordPress Essential Training and other related courses, I developed several new courses including Foundations of UX: Content Strategy, Responsive Web Design In the Browser, CSS Grid: First Look, Web Icons with SVG, and Advanced Layouts and Filtering with Isotope.js.

For 2017 I plan on continuing this trend, releasing advanced courses on WordPress development centered around the WP REST API, and broadening my base of courses on web standards and advanced development tools and techniques.

2016 was also a year for dabbling in new publishing formats. There’s a good chance you are reading this article on LinkedIn Pulse where I’ve published a steady stream of content touching on web development and related areas, and I’ve also contributed to the LinkedIn Learning Blog at various times. You can expect to see more material from me on these platforms and on my personal blog at in 2017.

WordPress Contribution

One of my major goals for 2016 was to become an active contributor to WordPress, and in particular WordPress core. I’ve been a “soft” contributor for some time, but rarely got any deeper than speaking at conferences, producing learning materials, and providing input to tickets and new features.

In the summer, I got a chance to speak at WordCamp Europe, a personal goal of mine since the conference was first announced, and I took the opportunity to bring the conversation about empathy and acceptance in design and communities to my own community. The talk was well received and I’d be honored if you watched it and read the accompanying article.

As for contribution, I invested my hours in contributing code and opinions to the new default theme to ship with WordPress 4.7 called “Twenty Seventeen” and some of the new features in WordPress core including Post Type Templates, reorganization of the tools in the WYSIWYG TinyMCE editor, and better discoverability of keyboard shortcuts.

In 2017 I hope to continue, and ideally increase, my level of contribution to WordPress because I believe the application and the community are important contributors to the future development of a free and open web.

Personal Things

2016 started with the best of news: In January we confirmed my wife was expecting a baby boy. This meant a drastic restructuring of our lives, and we prepared for his arrival in late September. Little did we know nature had little regard for our plans. Right at the start of August, only two weeks after our return from WordCamp Europe in Vienna, our son Leo Roar decided to make his appearance 6 weeks early. And with that, whatever structure existed went out the window. We spent a total of 4 weeks in the hospital before brining home our amazing little baby, and it was only thanks to the support of my amazing team at Learning and the equally amazing team at the hospital NICU that the Mortangela train didn’t totally derail.

Four months later and all I can say is we owe a life’s debt to modern medicine and socialized health care. Without them we would not have the pleasure of spending every day with what in my totally objective opinion is the cutest and most amazing little child ever to be born.

On a broader note, 2016 was the year that reawakened my long slumbering political self. Watching political schisms turn to impassable chasms and the civil discourse of our modern society give way to extreme partisanship and hate fueled anger left me despondent and fearing for the future. Once upon a time, I was an aspiring politician, but in a moment of deep self reflection I realized my energy was better spent outside parliamentary board rooms. For the next several years I willingly excluded myself from the political process, but now I realize that was suppressing a vital part of my being. So, in 2017 I will get involved once more, though in a much different manner than before.

Does this mean I’ll join a political party or become a partisan? No. That will not help anyone. Moving forward I’ll use my experience in politics and web technologies in whatever way I can to help heal the divide and encourage more healthy discussions about politics and our society. What exactly that looks like I am not entirely clear on yet, but as one who evangelizes the powers and potential of the web, I must also be one who helps make it better and moves our society forward using this amazing technology. More to come on that front as our journey around the sun commences once more.

Final thoughts at the end of the year

We are at an amazing time in history. Information is available at our fingertips in a way and with an ease unlike anything we ever dared dream. With that comes great responsibility. I truly believe we are straddling a 10 year demarcation line in history – separating the time before the connected self to the time after. What we see on the web, the internet, and in the world today are the beginnings of a new society shaped first and foremost by our ability to connect to anyone, anywhere, at any time. This is an ability our species and our society was never built to handle, and much of the turmoil we see both online and off is a direct result of our infantile first steps in this new world mostly unexplored. As we cross fully into this new reality, we must take stock of ourselves and ask some important questions, questions well deserving of a late night conversation at the end of the year:

  • What impact does language, location, and culture have on individuals and our global connected culture?
  • Who are we building technologies for, and how do we know what they need?
  • How do we measure value in a world where content distribution is free and every person with a digital soap box can reach anyone on the globe in a matter of seconds?
  • How do we use our newfound connectedness to move the whole world forward?

Thank you for reading, for watching, for engaging, and for being you. Happy end of 2016, and I look forward to working with you to build amazing things that make the world a better place for all in 2017.


This post is also available on LinkedIn Pulse.

News Web Standards

Semaphore: A 10k Apart entry powered by SVG, CSS, and JavaScript

A couple of months ago A List Apart announced the 10k Apart contest. The premise is simple:

Build a compelling web experience that can be delivered in 10kB and works without JavaScript.

Over the past year I’ve been exploring the edges of what is possible with SVG and this seemed a perfect challenge to really see how far this new graphics format is able to take us.

The result is Semaphore, a flag semaphore simulator you can control with your mouse, touch, or keyboard.

Side note: Go vote for Semaphore, and don’t forget to check out the many other excellent entries.

Now that it’s up, I urge you to check out the final product and the Github repo to see how it all fits together. Here’s the full breakdown:

What is this?

Semaphore is a simple web app providing a straight-forward method for generating flag semaphore symbols. A visitor triggers the semaphore figure using the on-screen keyboard with either touch, a mouse or other pointing device, by tabbing through the options, or via the letters and numbers on their keyboard. Using a screen reader the visitor will hear the arm positions read out based on a clock face.

The 10K Apart challenge stipulates you must build a functional and “compelling” web experience that transfers no more than 10kB to the browser during first load. I chose to take this challenge as literally as possible, creating a web app that only consists of the bare-bones necessary to make it work: a HTML file, a CSS file, and a JavaScript file, providing a complete experience at just shy of 10kB. There is no lazy loading or external elements, and the app is entirely self-contained meaning once it’s in the browser, the visitor can unplug the internet and still have the same experience as someone on a broadband connection.

How does it work?

Semaphore utilizes modern web technologies to provide a responsive, accessible, high-resolution experience in a tiny package. The flat semaphore figure is an SVG split into three components:

  • the body (loaded as the SVG loads)
  • the two arms (loaded as separate symbols)

When a letter is selected, the JavaScript applies a class to the left and right arms that in turn brings in CSS rules that position the arms using CSS transform: rotate();. In some cases the arms are simply rotated along the plane of the page (much like a clock face), in others they are also rotated in 3D space to allow the flag to “react” to gravity. To make the figure more lifelike, the transition property is used to create an animation. The end result is a graphic figure that appears to be alive. The effect is especially striking when typing on your keyboard.

NoJS Fallback

In the original submission, I had left out the JavaScript fallback. This has now been remedied. If the browser does not support JavaScript, an SVG mapping all the semaphore positions is presented in its place. The graphic also has a long description appended describing the flag positions in plain text for screen readers.


When I originally put this project together, I used a much simpler SVG without symbols and applied the transforms to IDs within the SVG. However, early testing showed CSS transforms are not honored when applied to elements or presentational attributes within an SVG in Internet Explorer 11 and Edge. To get around this problem, I split each of the arms into a symbol within the SVG and called them in separately. As individual elements in the DOM, they accept CSS transforms with no issues.

That settled, I ran into another browser hurdle: While the arms behaved as expected in Chrome, Edge, Safari, and Opera, they were literally all over the place in Firefox. This is because Firefox does not respect percentage values fortransform-origin. There was also the nontrivial issue of positioning the arms in the correct location relative to the body. There are several complex ways around this problem, but because I had already broken the arms out into separate symbols, the easiest workaround was to make each symbol containing an arm the size of the entire SVG. That way they could be absolutely positioned on top of one another, and the shoulder joints (transform-origin points) could be targeted with simplified CSS. Sometimes practical solutions are just way easier.

Flag semaphore? Really? Where did that idea come from?

I’m fascinated by how technology has changed the way we think about information. Only a couple of decades ago, information (and in particular the communication of information) was a highly valued commodity that required means, expertise, and access. Flag semaphore, and its siblings the semaphore line and Morse code, are maybe the most archetypal representations of this reality: time consuming, cumbersome, and requiring rote recall of complex symbols, they allowed letter-by-letter communication across sight-lines and beyond, forcing the communicators to be vigilant, accurate, and most importantly frugal in their communications. In sharp contrast to today’s plethora of always-on internet-enabled communication methods, with flag semaphore every message needed to be concise, accurate, and without ambiguity – properties our modern world is often in dire need of.