The goal of this tutorial is to show how to use Drupal 8.5's new off-canvas dialog in your own Drupal modules.

The term "off-canvas" refers to the ability for a dialog to slide in from the side of the page, in addition to resizing the page so that no part of it is obstructed by the dialog. You can see the off-canvas dialog in action in this animated GIF:

Animated GIF of Drupal off-canvas dialog tutorial

This new Drupal 8.5 feature allows us to improve the content authoring and site building experience by turning Drupal outside-in. We can use the off-canvas dialog to enable the content creator or site builder to seamlessly edit content or configuration in-place, and see any changes take effect immediately. There is no need to navigate to the administrative backend to make edits. As you'll see in this tutorial, it's easy to use the off-canvas dialog in your own Drupal modules.

I use a custom album module on for managing my photo albums and for embedding images in my posts. With Drupal 8.5, I can now take advantage of the new off-canvas dialog to edit the title, alt-attribute and captions of my photos. As you can see in the animated GIF above, every photo gets an "Edit"-link. Clicking the "Edit"-link opens up the off-canvas dialog. This allows me to edit a photo in context, without having to go to an another page to make changes.

So how did I do that?

Step 1: Create your form, the Drupal way

Every image on has its own unique path:<album-name>/<image-name>

I can edit my images at:<album-name>/<image-name>/edit

For example, gives you the image of the Niagara Falls. If you have the right permissions you could edit the image at (you don't πŸ˜‰). Because you don't have the right permissions, I'll show you a screenshot of the edit form instead:

Drupal off-canvas dialog tutorial: regular Drupal form

I created those paths (or routes), using Drupal's routing system, and I created the form using Drupal's regular Drupal form API. I'm not going to explain how to create a Drupal form in this post, but you can read more about this at the routing system documentation and the form API. Here is the code for creating the form:


namespace Drupal\album;

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;
use Drupal\album\Image;
use Drupal\Core\Url;

class ImageEditForm extends FormBase {

  public function getFormId() {
    return 'album_edit_image';

  public function buildForm(array $form, FormStateInterface $form_state, $dir = NULL, $img = NULL) {
    $image = Image::loadImage("$dir/$img");

    $form['path'] = [
      '#type' => 'hidden',
      '#value' => $image->getUrlPath(),  // Unique ID of the image
    $form['title'] = [
      '#type' => 'textfield',
      '#title' => t('Title'),
      '#default_value' => $image->getTitle(),
    $form['alt'] = [
      '#type' => 'textfield',
      '#title' => t('Alt'),
      '#default_value' => $image->getAlt(),
    $form['caption'] = [
      '#type' => 'textarea',
      '#title' => t('Caption'),
      '#default_value' => $image->getCaption(),
    $form['submit'] = [
      '#type' => 'submit',
      '#value' => t('Save image'),

    return $form;

  public function submitForm(array &$form, FormStateInterface $form_state) {
    $values = $form_state->getValues();

    $image = Image::loadImage($values['path']);
    if ($image) {

    $form_state->setRedirectUrl(Url::fromUserInput('/album/'. $image->getUrlPath()));


Step 2: Add an edit link to my images

First, I want to overlay an "Edit"-button over my image:

Drupal off-canvas dialog tutorial: "Edit"-link

If you were to look at the HTML code, the image link uses the following <a href> tag:

<a href="" 

Clicking the link doesn't open the off-canvas dialog yet. The class="edit-button" is used to style the button with CSS and to overlay it on top of the image.

Step 3: Opening the off-canvas dialog

Next, we have to tell Drupal to open the form in the off-canvas dialog when the "Edit"-link is clicked. To open the form in the off-canvas dialog, extend that <a href> tag to:

<a href=""
   class="edit-button use-ajax" data-dialog-type="dialog" data-dialog-renderer="off_canvas" 

Some extra HTML in the <a href> tag is all it took; it took my regular Drupal form, showed it in an off-canvas dialog, and even styled it! As I wrote above, it is easy to use the off-canvas dialog in your own modules. Hopefully you'll be inspired to take advantage of this new functionality.

Drupal off-canvas dialog tutorial: open dialog

There are several things being added though, so let's break it down. First we add the a class called use-ajax:

  • use-ajax is the class that is necessary for any link including dialogs that use Drupal's Ajax API.

We also added some data-dialog-* attributes:

  • data-dialog-type="dialog" specifies that you want to open the link in a dialog. The other option you can specify is modal. Unlike a dialog, a modal dialog restricts interaction with the current page until the modal dialog is closed.
  • data-dialog-renderer="off_canvas" specifies how Drupal will actually render the dialog. If data-dialog-renderer is not specified then the dialog will rendered with Drupal's default dialog renderer, which is a pop-up dialog (similar to the modal dialog which is used by the Views module).
  • data-dialog-options="{&quot;width&quot;:400}" is optional and can be used to overwrite the default off-canvas dialog properties. In this case, I'm specifying that I want the width of the off-canvas dialog to be 400 pixels instead of the default 300 pixels. Any valid jQuery UI dialog options can be sent here.
  • ?destination=current-path specifies the page we have to navigate back to after we close the dialog. To have the form redirect to the current page a destination value must be added to the query string of the link. Redirecting the form to the current page works the same for dialog links as it does for other links to forms in Drupal. Luckily Drupal 8 provides a RedirectDestination helper service to handle this. In the example above, submitting the form would redirect you to

You can create a link like the example above using a Drupal render array; it will open a form page in the off-canvas dialog and redirect the submitted form back to the current page:

$elements['link'] = [
  '#title' => 'Edit image',
  '#type' => 'link',
  '#url' => Url::fromRoute('album_image', ['album' => $album, 'image' => $image], 
    ['query' => \Drupal::service('redirect.destination')->getAsArray()])->toString();,
  '#attributes' => [
    'class' => ['use-ajax'],
    'data-dialog-type' => 'dialog',
    'data-dialog-renderer' => 'off_canvas',
    'data-dialog-options' => Json::encode(['width' => 400]),
  '#attached' => [
    'library' => [

Because the dialog functionality might not be needed on every page, Drupal won't load it unless needed. We use the #attached element to tell Drupal that we want the JavaScript dialog system to be loaded for this page. It's a bit more work, but it keeps Drupal efficient.

Improving the developer experience

Applying the off-canvas dialog to my blog and writing this tutorial uncovered several opportunities to improve the developer experience. It seems unnecessary to set class' => ['use-ajax'] when data-dialog-type is set. Why do I need to specify both a data-dialog-type and a data-dialog-renderer? And why can't Drupal automatically attach core/drupal.dialog.ajax when data-dialog-type is set?

In discussing these challenges with Ted Bowman, one of the developers of the off-canvas dialog, he created an issue on to work on off-canvas developer experience improvements. Hopefully in a future version of Drupal, you will be able to create an off-canvas dialog link as simply as:

$link = Link::createFromRoute('Edit image', 'album_image', 
   ['album' => $album, 'image' => $image])->openInOffCanvasDialog();
$elements['link'] = $link->toRenderable();

Special thanks to Ted Bowman and Samuel Mortenson for their feedback to this blog post.

I recently had the opportunity to read Tiffany Farriss' Drupal Association Retrospective. In addition to being the CEO of, Tiffany also served on the Drupal Association Board of Directors for nine years. In her retrospective post, Tiffany shares what the Drupal Association looked like when she joined the board in 2009, and how the Drupal Association continues to grow today.

What I really appreciate about Tiffany's retrospective is that it captures the evolution of the Drupal Association. It's easy to forget how far we've come. What started as a scrappy advisory board, with little to no funding, has matured into a nonprofit that can support and promote the mission of the Drupal project. While there is always work to be done, Tiffany's retrospective is a great testament of our community's progress.

I feel very lucky that the Drupal Association was able to benefit from Tiffany's leadership for nine years; she truly helped shape every aspect of the Drupal Association. I'm proud to have worked with Tiffany; she has been one of the most influential, talented members of our Board, and has been very generous by contributing both time and resources to the project.

Earlier today, we released Drupal 8.5.0, which ships with improved features for content authors, site builders and developers.

Content authors can benefit from enhanced media support and content moderation workflows. It is now easier to upload, manage and reuse media assets, in addition to moving content between different workflow states (e.g. draft, archived, published, etc).

Drupal 8.5.0 also ships with a Settings Tray module, which improves the experience for site builders. Under the hood, the Settings Tray module uses Drupal 8.5's new off-canvas dialog library; Drupal module developers are encouraged to start using these new features to improve the end-user experience of their modules.

It's also exciting to see additional improvements to Drupal's REST API. With every new release, Drupal continues to extend investments in being an API-first platform, which makes it easier to integrate with JavaScript frameworks, mobile applications, marketing solutions and more.

Finally, Drupal 8.5 also ships with significant improvements for Drupal 7 to Drupal 8 migration. After four years of work, 1,300+ closed issues and contributions from over 570 Drualists, the migrate system's underlying architecture in Drupal 8.5 is fully stable. With the exception of sites with multilingual content, the migration path is now considered stable. Needless to say, this is a significant milestone.

These are just a few of the major highlights. For more details about what is new in Drupal 8.5, please check out the official release announcement and the detailed release notes.

What I'm probably most excited about is the fact that the new Drupal 8 release system is starting to hit its stride. The number of people contributing to Drupal continues to grow and the number of new features scheduled for Drupal 8.6 and beyond is exciting.

In future releases, we plan to add a media library, support for remote media types like YouTube videos, support for content staging, a layout builder, JSON API support, GraphQL support, a React-based administration application and a better out-of-the-box experience for evaluators. While we have made important progress on these features, they are not yet ready for core inclusion and/or production use. The layout builder is available in Drupal 8.5 as an experimental module; you can beta test the layout builder if you are interested in trying it out.

I want to extend a special thank you to the many contributors that helped make Drupal 8.5 possible. Hundreds of people and organizations have contributed to Drupal 8.5. It can be hard to appreciate what you can't see, but behind every bugfix and new feature there are a number of people and organizations that have given their time and resources to contribute back. Thank you!

Join more than 5,000 others and subscribe to my blog by e-mail:

When I'm home, one of the devices I use most frequently is the Amazon Echo. I use it to play music, check the weather, set timers, check traffic, and more. It's a gadget that is beginning to inform many of my daily habits.

Discovering how organizations can use a device like the Amazon Echo is big part of my professional life too. For the past two years, Acquia Labs has been helping customers take advantage of conversational interfaces, beacons and augmented reality to remove friction from user experiences. One of the most exciting examples of this was the development of Ask GeorgiaGov, an Alexa skill that enables Georgia state residents to use an Amazon Echo to easily interact with government agencies.

The demo video below shows another example. It features a shopper named Alex, who has just returned from Freshland Market (a fictional grocery store). After selecting a salmon recipe from Freshland Market's website, Alex has all the ingredients she needs to get started. Alex begins by asking Alexa how to make her preferred salmon recipe for eight people. The recipe on Freshland Market's Drupal website is for four people, so the Freshland Market Alexa skill automatically adjusts the number of ingredients needed to accommodate eight people. By simply asking Alexa a series of questions, Alex is able to preheat the oven, make ingredient substitutions and complete the recipe without ever looking at her phone or laptop. With Alexa, Alex is able to stay focused on the joy of cooking, instead of following a complex recipe.

This project was easy to implement because the team took advantage of the Alexa integration module, which allows Drupal to respond to Alexa skill requests. Originally created by Jakub Suchy (Acquia) and maintained by Chris Hamper (Acquia), the Alexa integration module enables Drupal to respond to custom voice commands, otherwise known as "skills".

Cooking with Amazon Echo and Drupal

Once an Amazon Echo user provides a verbal query, known as an "utterance", this vocal input is converted into a text-based request (the "intent") that is sent to the Freshland Market website (the "endpoint"). From there, a combination of custom code and the Alexa module for Drupal 8 responds to the Amazon Echo with the requested information.

Over the past year, it's been very exciting to see the Acquia Labs team build a connected customer journey using chatbots, augmented reality and now, voice assistance. It's a great example of how organizations can build cross-channel customer experiences that take place both online and offline, in store and at home, and across multiple touch points. While Freshland Market is a fictional store, any organization could begin creating these user experiences today.

Special thanks to Chris Hamper and Preston So for building the Freshland Market Alexa skill, and thank you to Ash Heath and Drew Robertson for producing the demo videos.

Last week, Matthew Grasmick stepped into the shoes of a developer who has no Drupal experience, and attempted to get a new "Hello world!" site up and running using four different PHP frameworks: WordPress, Laravel, Symfony and Drupal. He shared his experience in a transparent blog post. In addition to detailing the inefficiencies in Drupal's download process and end-user documentation, Matt also shows that out of the four frameworks, Drupal required the most steps to get installed.

While it is sobering to read, I'm glad Matthew brought this problem to the forefront. Having a good evaluator experience is critical as it has a direct impact on adoption rates. A lot goes into a successful evaluator experience: from learning what Drupal is, to understanding how it works, getting it installed and getting your first piece of content published.

So how can we make some very necessary improvements to Drupal's evaluator experience?

I like to think of the evaluator experience as a conversion funnel, similar to the purchase funnel developed in 1898 by E. St. Elmo Lewis. It maps an end-user journey from the moment a product attracts the user's attention to the point of use. It's useful to visualize the process as a funnel, because it helps us better understand where the roadblocks are and where to focus our efforts. For example, we know that more than 13 million people visited in 2017 (top of the funnel) and that approximately 75,000 new Drupal 8 websites launched in production (bottom of the funnel). A very large number of evaluators were lost as they moved down the conversion funnel. It would be good to better understand what goes on in between.

An example Drupal conversion funnel and the primary stakeholders for each level.

As you can see from the image above, the Drupal Association plays an important role at the top of the funnel; from educating people about Drupal, to providing a streamlined download experience on, to helping users find themes and modules, and much more.

The Drupal Association could do more to simplify the evaluator experience. For example, I like the idea of the Drupal Association offering and promoting a hosted, one-click trial service. This could be built by extending a service like into a hosted evaluation service, especially when combined with the upcoming Umami installation profile. (The existing "Try Drupal" program could evolve into a "Try hosting platforms" program. This could help resolve the expectation mismatch with the current "Try Drupal" program, which is currently more focused on showcasing hosting offerings than providing a seamless Drupal evaluation experience.)

The good news is that the Drupal Association recognizes the same needs, and in the past months, we have been working together on plans to improve Drupal's conversional funnel. The Drupal Association will share its 2018 execution plans in the upcoming weeks. As you'll see, the plans address some of the pain points for evaluators (though not necessarily through a hosted trial service, as that could take significant engineering and infrastructure resources).

The Documentation Working Group also plays a very important role in this process. After reading Matthew's post, I reached out to Joe Shindelar, who is a member of the Drupal Documentation Working Group. He explained that the Documentation Working Group has not been meeting regularly nor coordinating initiatives for some time.

It is time to rethink our approach around Drupal's documentation. Adam Hoenich, a long-time Drupal contributor, recommends that documentation becomes a full-fledged core initiative, including the addition of a Documentation Maintainer to the Core Committer team. His proposal includes blocking commits to Drupal on documentation.

I've no doubt that we have to evolve our governance model surrounding documentation. It's hard to write world-class documentation by committee without good governance and Adam's recommendations are compelling. Drupal's API documentation, for example, is governed by the Core Committers; while there is always room for improvement, it's really well-maintained. Some of you might remember that we had an official Documentation Maintainer role in the past, filled by Jennifer Hodgdon. Reinstating this position could bring documentation back into clearer focus and provide the necessary governance. I also suspect that a stronger emphasis on coordination, governance and recognition for documentation work, would inspire more contributors to help.

Last but not least, this also affects the Drupal (Core) Contributors. Evaluators often spend hours trying to get their web server configured, PHP installed or their database setup. As a community, we could help alleviate this pain by deciding to have a single, recommended default installation environment. For example, we could maintain and promote a Docker container (including an official docker-compose.yml) that ships with the latest version of Drupal. It would simplify many of our documentation efforts, and eliminate many roadblocks from the evaluation process.

To narrow down my recommendations, I would propose the following three steps:

  1. A single, recommended default installation environment (e.g. Docker container) for evaluators or developers taking their first steps in Drupal development.
  2. Infrastructure budget and engineering resources for the Drupal Association so they can offer a true hosted "Try Drupal" service.
  3. A Documentation Maintainer who can focus on end-user documentation, is a member of the Core Committer team and is responsible for defining the scope of what should be documented. Given the amount of work this position would entail, it would be ideal if this person could be at least partially funded.
Of course, there are many other solutions, but these are the areas I'd focus on. As always, success depends on our ability to align on solutions, coordinate all the work, and allocate the time and money to implement the necessary improvements. If you think you can help with any of the proposed steps, please let us know in the comments, and we'll help you get involved.

Earlier this month, I uninstalled Facebook from my phone. I also made a commitment to own my own content and to share shorter notes on my site. Since then, I shared my POSSE plan and I already posted several shorter notes.

One thing that I like about Facebook and Twitter is how easy it is to share quick updates, especially from my phone. If I'm going to be serious about POSSE, having a good iOS application that removes friction from the publishing process is important.

I always wanted to learn some iOS development, so I decided to jump in and start building a basic iOS application to post notes and photos directly to my site. I've already made some progress; so far my iOS application shares the state of my phone battery at This is what it looks like:

My phone's battery level is 78% and it is unplugged

This was inspired by Aaron Parecki, who not only tracks his phone battery but also tracks his sleep, his health patterns and his diet. Talk about owning your own data and liking tacos!

Sharing the state of my phone's battery might sound silly but it's a first step towards being able to publish notes and photos from my phone. To post the state of my phone's battery on my Drupal site, my iOS application reads my battery status, wraps it in a JSON object and sends it to a new REST endpoint on my Drupal site. It took less than 100 lines of code to accomplish this. More importantly, it uses the same web services approach as posting notes and photos will.

In an unexpected turn of events (yes, unnecessary scope creep), I decided it would be neat to keep my status page up-to-date with real-time battery information. In good tradition, the scope creep ended up consuming most of my time. Sending periodic battery updates turned out to be difficult because when a user is not actively using an iOS application, iOS suspends the application. This means that the applications can't listen to battery events nor send data using web services. This makes sense: suspending the application helps improve battery life, and allows iOS to devote more system resources to the active application in the foreground.

The old Linux hacker in me wasn't going to be stopped though; I wanted my application to keep sending regular updates, even when it's not the active application. It turns out iOS makes a few exceptions and allows certain categories of applications – navigation, music and VOIP applications – to keep running in the background. For example, Waze continues to provide navigation instructions and Spotify will play music even when they are not the active application running in the foreground.

You guessed it; the solution was to turn my note-posting-turned-battery application into a navigation application. This requires the application to listen to location update events from my phone's GPS. Doing so prevents the application from being suspended. As a bonus, I can use my location information for future use cases such as geotagging posts.

This navigation hack works really well, but the bad news is that my application drains my phone battery rather quickly. The good news is that I can easily instruct Drupal to send me email notifications to remind me to charge my phone.

Scope creep aside, it's been fun to work with Drupal 8's built-in REST API and to learn some iOS application development. Now I can post my phone's battery on my site, posting notes or photos shouldn't be much more difficult. I'm guessing that a "minimum viable implementation" will require no more than another 100 lines of code and four hours of my time. My current thinking is to go ahead with that so I can start posting from my phone. That gives me more time to evaluate if I want to use the Micropub standard (probably) and the Indigenous iOS application (depends) instead of building and maintaining my own.

My website plan

In an effort to reclaim my blog as my thought space and take back control over my data, I want to share how I plan to evolve my website. Given the incredible feedback on my previous blog posts, I want to continue the conversation and ask for feedback.

First, I need to find a way to combine longer blog posts and status updates on one site:

  1. Update my site navigation menu to include sections for "Blog" and "Notes". The "Notes" section would resemble a Twitter or Facebook livestream that catalogs short status updates, replies, interesting links, photos and more. Instead of posting these on third-party social media sites, I want to post them on my site first (POSSE). The "Blog" section would continue to feature longer, more in-depth blog posts. The front page of my website will combine both blog posts and notes in one stream.
  2. Add support for Webmention, a web standard for tracking comments, likes, reposts and other rich interactions across the web. This way, when users retweet a post on Twitter or cite a blog post, mentions are tracked on my own website.
  3. Automatically syndicate to 3rd party services, such as syndicating photo posts to Facebook and Instagram or syndicating quick Drupal updates to Twitter. To start, I can do this manually, but it would be nice to automate this process over time.
  4. Streamline the ability to post updates from my phone. Sharing photos or updates in real-time only becomes a habit if you can publish something in 30 seconds or less. It's why I use Facebook and Twitter often. I'd like to explore building a simple iOS application to remove any friction from posting updates on the go.
  5. Streamline the ability to share other people's content. I'd like to create a browser extension to share interesting links along with some commentary. I'm a small investor in Buffer, a social media management platform, and I use their tool often. Buffer makes it incredibly easy to share interesting articles on social media, without having to actually open any social media sites. I'd like to be able to share articles on my blog that way.

Second, as I begin to introduce a larger variety of content to my site, I'd like to find a way for readers to filter content:

  1. Expand the site navigation so readers can filter by topic. If you want to read about Drupal, click "Drupal". If you just want to see some of my photos, click "Photos".
  2. Allow people to subscribe by interests. Drupal 8 make it easy to offer an RSS feed by topic. However, it doesn't look nearly as easy to allow email subscribers to receive updates by interest. Mailchimp's RSS-to-email feature, my current mailing list solution, doesn't seem to support this and neither do the obvious alternatives.

Implementing this plan is going to take me some time, especially because it's hard to prioritize this over other things. Some of the steps I've outlined are easy to implement thanks to the fact that I use Drupal. For example, creating new content types for the "Notes" section, adding new RSS feeds and integrating "Blogs" and "Notes" into one stream on my homepage are all easy – I should be able to get those done my next free evening. Other steps, like building an iPhone application, building a browser extension, or figuring out how to filter email subscriptions by topics are going to take more time. Setting up my POSSE system is a nice personal challenge for 2018. I'll keep you posted on my progress – much of that might happen via short status updates, rather than on the main blog. ;)

My blog as my thought space

Last week, I shared my frustration with using social media websites like Facebook or Twitter as my primary platform for sharing photos and status updates. As an advocate of the open web, this has bothered me for some time so I made a commitment to prioritize publishing photos, updates and more to my own site.

I'm excited to share my plan for how I'd like to accomplish this, but before I do, I'd like to share two additional challenges I face on my blog. These struggles factor into some of the changes I'm considering implementing, so I feel compelled to share them with you.

First, I've struggled to cover a wide variety of topics lately. I've been primarily writing about Drupal, Acquia and the Open Web. However, I'm also interested in sharing insights on startups, investing, travel, photography and life outside of work. I often feel inspired to write about these topics, but over the years I've grown reluctant to expand outside of professional interests. My blog is primarily read by technology professionals β€” from Drupal users and developers, to industry analysts and technology leaders β€” and in my mind, they do not read my blog to learn about a wider range of topics. I'm conflicted because I would like my l blog to reflect both my personal and professional interests.

Secondly, I've been hesitant to share short updates, such as a two sentence announcement about a new Drupal feature or an Acquia milestone. I used to publish these kinds of short updates quite frequently. It's not that I don't want to share them anymore, it's that I struggle to post them. Every time I publish a new post, it goes out to more than 5,000 people that subscribe to my blog by email. I've been reluctant to share short status updates because I don't want to flood people's inbox.

Throughout the years, I worked around these two struggles by relying on social media; while I used my blog for in-depth blog posts specific to my professional life, I used social media for short updates, sharing photos and starting conversation about wider variety of topics.

But I never loved this division.

I've always written for myself, first. Writing pushes me to think, and it is the process I rely on to flesh out ideas. This blog is my space to think out loud, and to start conversations with people considering the same problems, opportunities or ideas. In the early days of my blog, I never considered restricting my blog to certain topics or making it fit specific editorial standards.

Om Malik published a blog last week that echoes my frustration. For Malik, blogs are thought spaces: a place for writers to share original opinions that reflect "how they view the world and how they are thinking". As my blog has grown, it has evolved, and along the way it has become less of a public thought space.

My commitment to implementing a POSSE approach on my site has brought these struggles to the forefront. I'm glad it did because it requires me to rethink my approach and to return to my blogging roots. After some consideration, here is what I want to do:

  1. Take back control of more of my data; I want to share more of my photos and social media data on my own site.
  2. Find a way to combine longer in-depth blog posts and shorter status updates.
  3. Enable readers and subscribers to filter content based on their own interests so that I can cover a larger variety of topics.

In my next blog post, I plan to outline more details of how I'd like to approach this. Stay tuned!

Yesterday I shared that I uninstalled the Facebook application from my phone. My friend Simon Surtees was quick to text me: "I for one am pleased you have left Facebook. Less Cayman Island pictures!". Not too fast Simon. I never said that I left Facebook or that I'd stop posting on Facebook. Plus, I'll have more Cayman Islands pictures to share soon. :)

As a majority of my friends and family communicate on Facebook and Twitter, I still want to share updates on social media. However, I believe I can do it in a more thoughtful manner that allows me to take back control over my own data. There are a couple of ways I could go about that:

  • I could share my status updates and photos on a service like Facebook or Twitter and then automatically download and publish them to my website.
  • I could publish my status updates and photos on my website first, and then programmatically share them on Facebook, Twitter, etc.

The IndieWeb movement has provided two clever names for these models:

  1. PESOS or Publish Elsewhere, Syndicate (to your) Own Site is a model where publishing begins on third party services, such as Facebook, and then copies can be syndicated to your own site.
  2. POSSE or Publish (on your) Own Site, Syndicate Elsewhere is a publishing model that begins with posting content on your own site first, then syndicating out copies to third party services.

Pesos vs posse

Here is the potential impact of each approach:

Dependence A 3rd party is a required intermediary within the PESOS approach. When the 3rd party platform is down or disappears completely, publishers lose their ability to post new content or retrieve old content. No dependence, as the 3rd party service is an optional endpoint, not a required intermediary.
Canonical Non-canonical: the data on the 3rd party is the original and copies on your domain may have to cite 3rd party URLs. Canonical: you have full control over URLs and host the original data. The 3rd party could cite the original URL.
Quality Pulling data from 3rd parties services could reduce its quality. For example, images could be degraded or downsized. Full control over the quality of assets on your own site.
Ease of use, implementation and maintenance 3rd party platforms make it really easy for users to publish content and you can still benefit from that. For example, you can easily upload images from your phone. The complexity inherent to the PESOS approach includes developing an infrastructure to curate archival copies to your own domain. The POSSE strategy can be significantly more work for the site owner, especially if you want comparable ease of use to 3rd party platforms. A higher level of technical expertise and time investment is likely required.

The goal of this analysis was to understand the pros and cons of how I can own my own content on While PESOS would be much easier to implement, I decided to go with POSSE. My next step is to figure out my "POSSE plan"; how to quickly and easily share status updates on my Drupal site, how to syndicate them to 3rd party services, how to re-organize my mailing list and my RSS feed, and more. If you have any experience with implementing POSSE, feel free to share your takeaways in the comments.

Facebook social decay
© Andrei Lacatusu

Earlier this month, I set a resolution to blog more and use social media less. While I still need to work on blogging more, I'm certainly spending less time on Facebook. I'm halfway there. So far, only my mom has complained about me spending less time on Facebook.

This morning when my alarm woke me up at 4:45am, I took it a step further. Most mornings, I spend ten minutes checking Facebook on my phone. Today, however, I deleted the Facebook application from my phone, rolled out of bed and started my workday. Great!

As an advocate for the open web, I've written a lot about the problems that Facebook and other walled gardens pose. While I have helped raise awareness and have contributed time and money to winning back the open web, I haven't fully embraced the philosophy on my own site. For over 12 years, I've blogged on my own domain and have used Open Source software instead of using a third party service like Blogger or Medium, but I can't say the same about sharing my photos or social media updates. This has bothered me for some time.

I felt even more motivated to make a change after watching David Letterman's new Netflix series. During a conversation with his first guest, President Obama, Letterman shared the fear that his son will one day ask, "Wait a minute. You knew this was a problem, and you didn't do anything about it?". Letterman's sentiment mirrors Jeff Bezos' regret minimization framework; when you look back on your life, you want to minimize the number of regrets you have. It's a principle I like to live by.

We can't have a handful of large platform companies like Facebook control what people read on the web; their impact on democracy and society is concerning. Even Facebook doesn't like what it sees when it looks in the mirror.

Today is not only the day I uninstalled Facebook from my phone, but it's the day I fully embrace and extend my new year's resolution. Not only would I like to use social media less, I want to take back control over my social media, photos and more. I also want to contribute more to the open web in the process β€” it will be a worthwhile personal challenge for 2018.