# Where it all started

I had the original idea for “projections” way back in 2019. Inspired by OS X’s Dashboard Widgets and Adobe AIR, I’d begun to wonder if it might be possible to project a component from a website into those kinds of surfaces. Rather than building a bespoke widget that connected to an API, I thought it made sense to leverage an installed PWA to manage those “projections.” I shared the idea at TPAC that year and got some interest from a broad range of folks, but didn’t have much time to work on the details until a few years later.

In the intervening time, I kept working through the concept in my head. I mean in an ideal world, the widget would just be a responsive web page, right? But if that were the case, what happens when every widget loads the entirety of React to render their stock ticker? That seemed like a performance nightmare.

In my gut, I felt like the right way to build things would be to have a standard library of widget templates and to enable devs to flow data into them via a Service Worker. Alex Russell suggested I model the APIs on how Notifications are handled (since they serve a similar function) and I was off to the races.

I drafted a substantial proposal for my vision of how PWA widgets should work. Key aspects included:

• A declarative way to define and configure a widget from within the Web App Manifest;
• A progressively enhanced pathway for devs to design a widget that adapts to its host environment, from using predefined templates to using custom templates to full-blown web-based widgets (with rendering akin to an iframe);
• A collection of recommended stock templates that implementors should offer to support most widget types;
• Extensibility to support custom templates using any of a variety of templating languages; and
• A complete suite of tools for managing widgets and any associated business logic within a Service Worker.

# Widgets became a reality

After continuing to gently push on this idea with colleagues across Microsoft (and beyond), I discovered that the Windows 11 team was looking to open up the new Widget Dashboard to third-party applications. I saw this as an opportunity to turn my idea into a reality. After working my way into the conversation, I made a solid case for why PWAs needed to be a part of that story and… it worked! (It no doubt helped that companies including Meta, Twitter, and Hulu were all invested in PWA as a means of delivering apps for Windows.)

While the timeline for implementation didn’t allow us to tackle the entirety of my proposal, we did carve out the pieces that made for a compelling MVP. This allowed us to show what’s possible, see how folks use it, and plan for future investment in the space.

Sadly, it meant tabling two features I really loved:

• Stock/predefined templates. A library of lightly theme-able, consistent, cross-platform templates based on common data structures (e.g., RSS/Atom, iCal) would make it incredibly simple for devs to build a widget. If implemented well, devs might not even need to write a single line of business logic in their Service Worker as the browser could pick up all of the configuration details from the Manifest.
• Configurable widget instances. Instead of singleton widgets, these would allow you to define a single widget type and replicate it for different use cases. For example, a widget to follow a social media user’s profile could be defined once and the individual instances could be configured with the specific account to be followed.

I’m sincerely hopeful these two features eventually make their way to us as I think they truly unlock the power of the widget platform. Perhaps, with enough uptake on the current implementation, we can revisit these in the not-too-distant future.

To test things out, I decided to build two widgets for this site:

1. Latest posts
2. Latest links

Both are largely the same in terms of their setup: They display a list of linked titles from this site.

# Designing my widget templates

Given that they were going to be largely identical, I made a single “feed” template for use in both widgets. The templating tech I used is called Adaptive Cards, which is what Windows 11 uses for rendering.

Adaptive Card templates are relatively straightforward JSON:

{“type”:“AdaptiveCard”,“$schema”:“http://adaptivecards.io/schemas/adaptive-card.json”,“version”:“1.6”,“body”: [{“$data”:“${take(items,5)}”,“type”:“Container”,“items”: [{“type”:“TextBlock”,“text”:“[${title}](${url})”,“wrap”:true,“weight”:“Bolder”,“spacing”:“Padding”,“height”:“stretch”}],“height”:“stretch”}],“backgroundImage”: {“url”:“https://www.aaron-gustafson.com/i/background-logo.png”,“verticalAlignment”:“Bottom”,“horizontalAlignment”:“Center”}}

What this structure does is:

1. Create a container into which I will place the content;
2. Extract the first five items from the data being fed into the template (more on that in a moment);
3. Loop through each item and
   • create a text block,
   • populate its content with Markdown to generate a linked title (using the title and url keys from the item object)
   • Set some basic styles to make the text bold, separate the titles a little and make them grow to fill the container; then, finally
4. Set a background on the widget.

The way Adaptive Cards work is that they flow JSON data into a template and render that. The variable names in the template map directly to the incoming data structure, so are totally up to you to define. As these particular widgets are feed-driven and this site already supports JSONFeed, I set up the widgets to flow the appropriate feed into each and used the keys that were already there. For reference, here’s a sample JSONFeed item:

{“id”:“…”,“title”:“…”,“summary”:“…”,“content_html”:“…”,“url”:“…”,“tags”:[],“date_published”:“…”}

If you want to tinker with Adaptive Cards and make your own, you can do so with their Designer tool.

# Defining the widgets in the Manifest

With a basic template created, the next step was to set up the two widgets in my Manifest. As they both function largely the same, I’ll just focus on the definition for one of them.

First off, defining widgets in the Manifest is done via the widgets member, which is an array (much like icons and shortcuts). Each widget is represented as an object in that array. Here is the definition for the “latest posts” widget:

{“name”:“Latest Posts”,“short_name”:“Posts”,“tag”:“feed-posts”,“description”:“The latest posts from Aaron Gustafson’s blog”,“template”:“feed”,“ms_ac_template”:“/w/feed.ac.json”,“data”:“/feeds/latest-posts.json”,“type”:“application/json”,“auth”:false,“update”:21600,“icons”:[{“src”:“/i/icons/webicon-rss.png”,“type”:“image/png”,“sizes”:“120x120”}],“screenshots”:[{“src”:“/i/screenshots/widget-posts.png”,“sizes”:“387x387”,“label”:“The latest posts widget”}]}

Breaking this down:

1. name and short_name act much like these keys in the root of the Manifest as well as in shortcuts: The name value is used as the name for the widget unless there’s not enough room, in which case short_name is used.
2. You can think of tag as analogous to class in HTML sense. It’s a way of labeling a widget so you can easily reference it later. Each widget instance will have a unique id created by the widget service, but that instance (or all instances, if the widget supports multiple instances) can be accessed via the tag. But more on that later.
3. The description key is used for marketing the widget within a host OS or digital storefront. It should accurately (and briefly) describe what the widget does.
4. The template key is not currently used in the Windows 11 implementation but refers to the expected standard library widget template provided by the system. As a template library is not currently available, the ms_ac_template value is used to provide a URL to get the custom Adaptive Card (hence “ac”) template. The “ms_” prefix is there because it’s expected that this would be a Microsoft-proprietary property. It follows the guidance for extending the Manifest.
5. The data and type keys define the path to the data that should be fed into the template for rendering by the widget host and the MIME of the data format it’s in. The Windows 11 implementation currently only accepts JSON data, but the design of widgets is set up to allow for this to eventually extend to other standardized formats like RSS, iCal, vCard, and such.
6. update is an optional configuration member allowing you to set how often you’d like the widget to update, in seconds. Developers currently need to add the logic for implementing this into their Service Worker, but this setup allows the configuration to remain independent of the JavaScript code, making it easier to maintain.
7. Finally, icons and screenshots allow us to define how the widget shows up in the widget host and how it is promoted for install.

When someone installs my site as a PWA, the information about the available widgets gets ingested by the browser. The browser then determines, based on the provided values and its knowledge of the available widget service(s) on the device, which widgets should be offered. On Windows 11, this information is routed into the AppXManifest that governs how apps are represented in Windows. The Windows 11 widget service can then read in the details about the available widgets and offer them for users to install.

# Adding widget support to my Service Worker

As I mentioned earlier, all of the plumbing for widgets is done within a Service Worker and is modeled on the Notifications API. I’m not going to exhaustively detail how it all works, but I’ll give you enough detail to get you started.

First off, widgets are exposed via the self.widgets interface. Most importantly, this interface lets you access and update any instances of a widget connected to your PWA.

# Installing a widget

When a user chooses to install a widget, that emits a “widgetinstall” event in your Service Worker. You use that to kickoff the widget lifecycle by gathering the template and data needed to instantiate the widget:

self.addEventListener(“widgetinstall”,(event)=>{console.log(</span><span class="token string">Installing </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>event<span class="token punctuation">.</span>widget<span class="token punctuation">.</span>tag<span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">);event.waitUntil(initializeWidget(event.widget));});

The event argument comes in with details of the specific widget being instantiated (as event.widget). In the code above, you can see I’ve logged the widget’s tag value to the console. I pass the widget information over to my initializeWidget() function and it updates the widget with the latest data and, if necessary, sets up a Periodic Background Sync:

asyncfunctioninitializeWidget(widget){awaitupdateWidget(widget);awaitregisterPeriodicSync(widget);return;}

The code for my updateWidget() function is as follows:

asyncfunctionupdateWidget(widget){const template =await(awaitfetch(widget.definition.msAcTemplate)).text();const data =await(awaitfetch(widget.definition.data)).text();try{await self.widgets.updateByTag(widget.definition.tag,{ template, data });}catch(e){console.log(</span><span class="token string">Couldn’t update the widget </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>tag<span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">, e);}return;}

This function does the following:

1. Get the template for this widget
2. Get the data to flow into the template
3. Use the self.widgets.updateByTag() method to push the template and data to the widget service to update any widget instances connected to the widget’s tag.

As I mentioned, I also have code in place to take advantage of Periodic Background Sync if/when it’s available and the browser allows my site to do it:

asyncfunctionregisterPeriodicSync(widget){let tag = widget.definition.tag;if(“update”in widget.definition){registration.periodicSync.getTags().then((tags)=>{// only one registration per tagif(!tags.includes(tag)){periodicSync.register(tag,{minInterval: widget.definition.update,});}});}return;}

This function also receives the widget details and:

1. Looks to see if the widget definition (from the Manifest) includes an update member. If it has one, it…
2. Checks to see if there’s already a Periodic Background Sync that is registered for this tag. If none exists, it…
3. Registers a new Periodic Background Sync using the tag value and a minimum interval equal to the update requested.

The update member, as you may recall, is the frequency (in seconds) you’d ideally like the widget to be updated. In reality, you’re at the mercy of the browser as to when (or even if) your sync will run, but that’s totally cool as there are other ways to update widgets as well.¹

# Uninstalling a widget

When a user uninstalls a widget, your Service Worker will receive a “widgetuninstall” event. Much like the “widgetinstall” event, the argument contains details about that widget which you can use to clean up after yourself:

self.addEventListener(“widgetuninstall”,(event)=>{console.log(</span><span class="token string">Uninstalling </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>event<span class="token punctuation">.</span>widget<span class="token punctuation">.</span>tag<span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">);event.waitUntil(uninstallWidget(event.widget));});

Your application may have different cleanup needs, but this is a great time to clean up any unneeded Periodic Sync registrations. Just be sure to check the length of the widget’s instances array (widget.instances) to make sure you’re dealing with the last instance of a given widget before you unregister the sync:

asyncfunctionuninstallWidget(widget){if(widget.instances.length ===1&&“update”in widget.definition){await self.registration.periodicSync.unregister(widget.definition.tag);}return;}

# Refreshing your widgets

Widget platforms may periodically freeze your widget(s) to save resources. For example, they may do this when widgets are not visible. To keep your widgets up to date, they will periodically issue a “widgetresume” event. If you’ve modeled your approach on the one I’ve outlined above, you can route this event right through to your updateWidget() function:

self.addEventListener(“widgetresume”,(event)=>{console.log(</span><span class="token string">Resuming </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>event<span class="token punctuation">.</span>widget<span class="token punctuation">.</span>tag<span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">);event.waitUntil(updateWidget(event.widget));});

# Actions

While I don’t want to get too into the weeds here, I do want to mention that widgets can have predefined user actions as well. These actions result in “widget click” events being sent back to the Service Worker so you can respond to them:

self.addEventListener(“widgetclick”,(event)=>{const widget = event.widget;const action = event.action;switch(action){// Custom Actionscase“refresh”:event.waitUntil(updateWidget(widget));break;}});

For a great example of how a widget can integrate actions, you should check out the demo PWAmp project. Their Service Worker widget code is worth a read.

# Result!

With all of these pieces in place, I was excited to see my site showing up in the Widget Dashboard in Windows 11.

You can view the full source code on GitHub:

• “Feed” Adaptive Card Template
• Widget definitions in the Manifest
• Widgets code in my Service Worker

I’m quite hopeful this will be the first of many places PWA-driven widgets will appear. If you’s like to see them supported elsewhere, be sure to tell your browser and OS vendor(s) of choice. The more they hear from their user base that this feature is needed, the more likely we are to see it get implemented in more places.

# Addendum: Gotchas

In wiring this all up, I ran into a few current bugs I wanted to flag so you can avoid them:

• The icons member won’t accept SVG images. This should eventually be fixed, but it was keeping my widgets from appearing as installable.
• The screenshots members can’t be incredibly large. I’m told you should provide square screenshots no larger than 500px ×500px.

# Step 1: Log the 404s to a file

I make ample use of Eleventy’s global data files, but 404s didn’t feel like something I needed to have as part of the data cascade. Instead, I’m logging them to a YAML file in my ./_cache folder. For simplicity, they get logged like this:

https://path.to/original/page/that-is-404ing/:true

I chose YAML as it’s about as bare-bones as you can get when it comes to file formats and is pretty easy to work with in the context of Eleventy.

# Step 2: Add an Eleventy data file to my links folder

If you’re not familiar, Eleventy allows you to create directory-level data files that can be used to augment file-level data. I was originally using it to define the layout and permalink front matter variables for all the links using the JSON option, but as a JavaScript file, directory-level data becomes even more powerful.

Setting up your data file is relatively straightforward using module.exports:

module.exports ={layout:“layouts/link.njk”,permalink:“/notebook/{{ page.filePathStem }}/”,eleventyComputed:{custom_property:(data)=>{return some_value_based_on_data;},},};

Here I’m defining two static values (layout and permalink) and a computed value (the hypothetical custom_property).

# Step 3: Consult the 404 log

As I mentioned, the 404 logging happens separately and results in updates to _cache/404.yml. To make use of all this in the Eleventy data file, I need to set up a few things at the top of the file:

const fs =require(“fs”);const yaml =require(“js-yaml”);const cached404s = yaml.load(fs.readFileSync(“_cache/404s.yml”));

Here I’m bringing in Node’s File System and JS-YAML. Then I am loading the YAML file into memory as cached404s, leveraging those utilities.

Next up is defining a helper function to search cached404s for a match:

functionis404ing(url){return url in cached404s;}

This function takes the URL as an argument and returns true or false. Making use of this in the eleventyComputed section is straightforward:

module.exports ={layout:“layouts/link.njk”,permalink:“/notebook/{{ page.filePathStem }}/”,eleventyComputed:{is_404:(data)=>{returnis404ing(data.ref_url);},},};

In my case, ref_url is the front matter field storing the URL I’m linking to from my link blog, so I return the value of passing that to is404ing() as is_404.

# Step 4: Lean on the Wayback Machine

The next thing I want to do is generate a link that has a good chance of working for my readers. Thankfully the Wayback Machine has a predictable URL structure for entries and it’s pretty good about handgun redirects to the most temporally-proximate snapshot when you give it a date to work from. Knowing that, I set up another helper function:

functionarchived(data){let archive_url =“https://web.archive.org/web/{{ DATE }}/{{ URL }}”;let month = data.date.getUTCMonth()+1;month = month <10?“0”+ month : month;let day = data.date.getDay();day = day <10?“0”+ day : day;archive_url = archive_url.replace(“{{ DATE }}”,</span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>data<span class="token punctuation">.</span>date<span class="token punctuation">.</span><span class="token function">getUTCFullYear</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token interpolation-punctuation punctuation">}</span></span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>month<span class="token interpolation-punctuation punctuation">}</span></span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>day<span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">).replace(“{{ URL }}”, data.ref_url);return archive_url;}

Note: I know this isn’t the most elegant/efficient code, I wanted to show step-by-step what’s happening here.

This function takes the data object as an argument and composes a URL that points to a snapshot of the given page (data.ref_url) at the time I saved the link (data.date). The data.date value is already a JavaScript date, so it’s pretty easy to turn it into the format the Wayback Machine expects (YYYYMMDD). In the end, this method returns a URL that looks something like this:

https://web.archive.org/web/20150102/http://andregarzia.com/posts/en/whatsappdoesntunderstandtheweb/

With that helper in place, I can make use of it within eleventyComputed:

module.exports ={layout:“layouts/link.njk”,permalink:“/notebook/{{ page.filePathStem }}/”,eleventyComputed:{is_404:(data)=>{returnis404ing(data.ref_url);},archived:(data)=>{returnis404ing(data.ref_url)?archived(data):false;},},};

Now every link in my link blog will have an is_404 value that is true or false and an archived value that is either a valid Wayback Machine URL (if the page is 404-ing) or false.

# Step 5: Using these in the my template

I use Nunjucks for most of my site’s templating, but you can make use of these computed properties in any supporting templating language. Knowing if a linked URL is 404-ing allows me to

• display the title without a link,
• display the source without a link, and
• provide additional copy about the link’s 404 status and provide the Wayback Machine link instead.

I am only going to share code with you for that final bit as it should give you enough of a sense of how you can use these properties in the other contexts too.

{%if is_404 %}<p>This link is 404-ing{%if archived %}, but<arel=“bookmark”href=“{{ archived }}”>you can view anarchived version on the Wayback Machine</a>{%endif%}.</p>{%endif%}

Here you can see I am injecting a footer into the markup when the entry is 404-ing. Within that footer, I note the link’s status. Then I inject some additional text to point to the Wayback Machine’s archive of the page. It’s worth noting that I am being overly cautious here and only injecting the link if post.data.archived is truthy. This will ensure that the link won’t be shown if something fails in my code or I change how I am implementing the archived property.

# Crossing my fingers

Relying on an unverified URL, even one at the Wayback Machine, is risky, but so far this approach seems to be working. If you’ve got a link blog suffering from link rot, you might consider setting up something similar. Hopefully this will help jumpstart that project for you.

Early last year, Tim Kadlec shared his bookmarklet for saving links to his site. I thought it was a brilliant setup, especially for a static site:

1. The bookmarklet captures the URL, page title, and any selection you’ve made and pipes it over to a form on your site;
2. The form contains the code that will generate a new static file in you site’s GitHub repo.

Smartly, the form requires you to log in with your GitHub credentials. That keeps it from being abused by others. Sadly, I always struggled to get this setup working fluidly on mobile. With the introduction of the Share Target, it’s become a lot easier.

You define a Share Target in your Web App Manifest. The original design only allowed for links and text to be shared, but version 2 is coming soon with support for any file type.¹ Pretty cool stuff! As you’d expect, the key is share_target and it takes a JSON object that looks a lot like a form configuration:

“share_target”:{“action”:“linky/poo/”,“method”:“GET”,“enctype”:“application/x-www-form-urlencoded”,“params”:{“title”:“title”,“text”:“body”,“url”:“url”}}

The first key is the action page. In this case, it points at my link posting form. I want the shared data passed via the query string, so I’m using GET as the method (but you could use other HTTP request methods as well). I set the encoding (enctype) and then identify the parameters I want to send and what they should be called in the payload.

With this in place, I installed my site on my phone and could immediately share links directly to it:

On the receiving end, everything works pretty well. Android doesn’t support sharing selected text along with the title of the page and the URL (like Tim’s bookmarklet does), but I can always copy the text I want to quote before I share the page. Another oddity in Android is that it currently sends the URL over as the body for some strange reason, but I set the JavaScript up on the resulting page to enable me to look for a URL in that field and pop it into the right spot. That way, when Android fixes the issue, it won’t cause any issues with a true text body (like your text selection—hint, hint).

Another nice enhancement I added to the form was autocomplete for the tag field. Using a datalist element, I have all of my site’s tags ready to autocomplete that field. Unfortunately, autocomplete doesn’t work great for multiple items out of the box, so I got some inspiration from this StackOverflow solution and implemented a vanilla JavaScript multiple choice datalist-driven input. Sweet!

While we often think of PWAs as being something we build for others, I’m totally stoked that I can also add PWA functionality that’s just for me (or, more broadly, internally-focused). That’s pretty exciting and demonstrates just how powerful and adaptable PWAs are.

Octopress was built on top of Jekyll, so I figured the move would be fairly easy. On the whole, it was. I was able to move the content over without too much difficulty. I ended up having to back out some of the Octopress plugins and either write the functionality myself or look for alternatives. Thankfully none were a terribly big deal.

The only major change was to the overall structure of the site. I opted to move my blog and linkblog into Jekyll collections, which worked out pretty well. I opted to go with the newer jekyll-paginate-v2 gem to build out the archive pages for each and used jekyll-tagging to generate the tag archive pages. In the process, I also moved all of my post “categories” over to being “tags”, since that was more appropriate to how I was using them anyway.

It took a few days to get it to the point where I feel I can merge the Jekyll-only branch back and publish for the first time, but I think it is pretty stable. That said, there are likely some bugs yet to be discovered. Please let me know if you find one; more sets of eyes are always better.

In case you’re curious why I’m making the shift, it’s pretty simple:

• Octopress development seems relatively stalled;
• Octopress includes dependencies I don’t really need;
• I’ve been writing a lot of Jekyll plugins and maintaining them without using them on the latest Jekyll is challenging;
• I’m comfortable writing my own Rake commands; and
• This is the big one: Incremental builds.

I’m hopeful this shift will make it easier for me to get content published more quickly and more reliably. I may even move my build processes into Travis CI to further offload the work. But I’m getting ahead of myself… let’s see how Tuesday goes first.

I was using Github to host my site as a Github page. It worked really well given this is a static site, but you can’t run Github-hosted sites under HTTPS unless you go with their *.github.io domain name (they have a wildcard certificate for that domain). There’s been a ton of interest in Github allowing custom cert installation, but no movement yet, so… onward!¹

I opted to move to DigitalOcean since my consultancy recently relocated all of its sites there in a mass exodus from MediaTemple. Migrating the site was as simple as setting up the DigitalOcean server as a new “live” remote on my local git install and pushing it up there. Since it’s a static site, I didn’t have to worry too much about the server config. Apache is really great at hosting static files.

With the contents in place, I went through the rather convoluted process of getting SSL set up following the instructions from DigitalOcean. I opted for the free StartSSL certificate to begin with (a rather convoluted process, but we got there in the end) and then flipped the DNS records to point to the new box. Given that the StartSSL certificate needs to be renewed every 30 days, I may opt for a paid certificate in the not too distant future.

Once the DNS propagated, I had to go back and button up a few scripts that were requesting non-HTTPS content. I also had to tweak my Jekyll plugins and Rake tasks to include the legacy “http://" URLs when querying for webmentions and the like (since I didn’t want to lose those references). I also updated the Apache’s VirtualHost configuration for the non-secure site to make all traffic redirect:

Redirect permanent / https://www.aaron-gustafson.com/

All in all, it was a relatively painless migration. Admittedly, the initial re-build of the site (after updating the Rake tasks) did re-submit all of the webmentions I’d previously sent in order to provide the new address. If I referenced you a bunch in the past, I apologize for the flood of traffic, but it had to be done.

Anyway, so now this site is running under HTTPS. If you encounter any issues, please let me know. And if you want to read a really good account of migrating a site to HTTPS, you should definitely read Jeremy Keith’s step-by-step guide.

I recently began posting links (with commentary) in a bit of a link blog, but I wasn’t really happy with having it mixed in with the rest of my Notebook posts. I finally took a few minutes to formally bust out the links into their own paginated section, so you can keep up with them independently. I also set up a three distinct Atom feeds to let you consume this site’s content how you want to: Latest 20 posts and links, latest 20 posts, and Latest 20 links.

I’m hopeful this organization will prove as helpful to you as it is for my compartmentalization anxiety.

What I’m trying to say (or rather excuse) is that I have been struggling with some of my initial decisions with respect to URLs on this site and finally decided to make some changes before too many links to its content get out there. I was a bit reluctant to do so as we all know what Sir Tim Berners-Lee says

Cool URIs don’t change.

Well, consider me uncool as I decided to change some things around here:

1. I dropped the year indicator from blog post URLs. I realized that the likelihood of me having two posts with the same name was pretty much nil, so it was unnecessary to disambiguate like that. Plus it would save me from having to create the annual archives I would feel compelled to make in order to justify the “2014” directory in the URL.
2. I consolidated my book and article pages to a single page or publications. I thought it might be nice to maintain them separately, but in retrospect that seems unnecessarily complicated.
3. I changed the URL to my speaking engagements from “events” to “speaking-engagements” as it just made more sense.

On the off chance you ever consider changing URLs on a Jekyll or Octopress site, I thought I’d share my process.

# Redirecting Old Links

I was quite concerned concerned about old links being broken in this site. It’s just not a good thing to do.

In a traditional hosting scenario, I could use .htaccess to set up 302 redirects, but I am hosting on Github so that isn’t an option. On top of that, this site is built using Octopress (and Jekyll), so there is no dynamic system in place to programmatically manage those redirects.

Thankfully, there is a plugin for Jekyll to manage redirects. With it, you can redirect from an an existing page in the YAML front matter using the redirect_to key or you can use the redirect_from key in the YAML front matter on the destination page. I ended up using the former for old pages (articles, books, and events), and the latter for blog posts.

The plugin covers all the bases. It generates pages at the old URLs that redirect using the good old meta refresh, a JavaScript redirect, and a fallback link just in case neither of those work. Oh, and it sets the new URL as the canonical reference to boot.

Done and done.

# Keeping Webmentions

As I mentioned a few weeks back, I wrote a Jekyll plugin to enable webmentions. As web mentions are tied to the “mentioned” URL, changing a post’s URL was going to cause me to lose any previous webmentions. I didn’t like that idea, so I talked to Aaron about adding multiple URL support to the webmention.io API and he agreed it was a good idea.

The feature landed late last week and I adjusted my Jekyll Webmention.io plugin to allow you to supply multiple URLs. While I was at it, I did some other upgrades: I added caching, downloading of webmention titles if the API didn’t supply one, and a test for the existence of avatars before inserting them (so you don’t end up with missing images).

If you were using the plugin, I definitely recommend upgrading as it performs a lot better now. I also added a Rake task for sending webmentions which is super handy.

# Pardon My Dust

I apologize for changing URLs on you, but I am hopeful this will be the last major change on the site. As it (currently) says at the top, this is an open redesign, so there are bound to be a few bumps here and there. That said, I will try to keep them to a minimum in the future.

In my quest to learn something new (more on that in a forthcoming post), I decided to give Octopress a whirl. We’ll see how it goes, but the content entry has gone well so far and the Octopress community has been pretty responsive to my requests. I just need to get used to the workflow.

In the spirit of openness, I’ve decided to host the new site on Github as a Github Page. This frees me up from worrying about hosting fees of course, but it also means this site can serve as an educational tool for those inclined to dig in to the work I do and want some introspection into the way I do it. You can view (and fork) the whole darn thing at your leisure.

Finally, I’m designing and building this site in the open and, for posterity, taking screen shot of the progress. The screenshots will go up in time as an animated GIF, but those of you who wish will be able to follow along at home or work, seeing how I typically piece together a site, layer by layer, using progressive enhancement. So far it’s just the content, but that’s what I preach: content first.

Now it’s time to get back to it. Feel free to reach out if you have any questions.

So what’s going on? Well, a lot.

For one, we’ve relocated from New Haven, CT to Chattanooga, TN after being urged to visit by Mr. Shaun Inman and his lovely bride Leslie and falling in love with this awesome city. We made the move in August of last year and, after spending a few months in an apartment, have bought a house and will be moving in this weekend. Chattanooga is an amazing place. There’s always something going on, it has a wonderful art scene and tech community, and is nestled in the mountains, right along the Tennessee River. It has many of the perks of Portland, OR and San Francisco, CA (other cities we considered moving to), but at 1/4-1/3 the cost. I couldn’t ask for a better place to live.

Since relocating, Easy! Designs has also been growing. We’ve taken on two interns – Matt Turnure and Sean McCarthy – and have been joined full-time by both Dave Stewart (who I had previously worked with in CT) and Matt Harris (an excellent developer from the UK), so expect to be hearing from them on this site soon as well. In addition to our client work, we’ve been busily coding away on a few products of our own that should hopefully see the light of day in the coming year. We’re also working on a relaunch of our own website and this blog.

Finally, there’s eCSStender. I’ve been working on this project for ages and it’s currently in a closed beta. Things are progressing smoothly on its development though and I expect it will be ready for its initial public release in the coming weeks.

Anyway, that’s the nickel tour of the changes. I apologize profusely for rendering this blog pretty useless with my error, but hopefully we’ll have it all back up and running shortly.

PS - If you happen to have an archive of my blog post on IE8 Standards Mode, please forward a copy of it to me. I can’t seem to find it even though it appears to be somewhere in the Google Cache.