Books I read in 2016

• Batman: Birth of the Demon by Mike W. Barr and Dennis O'Neil
• Batman: Mad Love and Other Stories by Paul Dini and Bruce Timm
• The Fountains of Paradise by Arthur C. Clarke
• Wolverine by Chris Claremont and Frank Miller
• Daredevil: Born Again by Frank Miller and David Mazzucchelli
• Batman: Bruce Wayne, Murderer? by Ed Brubaker and Scott McDaniel
• The Epic Struggle of the Internet of Things by Bruce Sterling
• Writing in Markdown by Matt Gemmell

Books I read in 2017

• The Real World of Technology by Ursula Franklin
• Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement by Aaron Gustafson
• Steve Jobs by Walter Isaacson
• The Speech: The Story Behind Dr. Martin Luther King Jr.’s Dream by Gary Younge
• Jerusalem: Chronicles from the Holy City by Guy Delisle
• Daredevil: Yellow and Captain America: White by Jeph Loeb and Tim Sale
• The Demolished Man by Alfred Bester
• The Circle by Dave Eggers
• Tragic Design: The True Impact of Bad Design and How to Fix It by Jonathan Shariat
• Narrative of the Life of Frederick Douglass: An American Slave by Frederick Douglass
• Resilient Web Design by Jeremy Keith
• On Tyranny: Twenty Lessons from the Twentieth Century by Timothy Snyder
• Working the Command Line by Remy Sharp
• Get Ready for CSS Grid Layout by Rachel Andrew

These last two years pale in comparison to 2015’s book-reading bonanza. Nevertheless, I did read a lot of interesting non-fiction and consumed a healthy dose of graphic novels.

I’ve got a few goals for 2018:

1. Read more—both fiction and non-fiction—by women, people of color, and other under-represented voices. I’ll use my existing pile of unread books, NPR’s Best Books of 2017, and R. O. Kwon’s 46 Books By Women of Color to Read in 2018 as starting points.
2. Improve the balance between fiction and non-fiction and diversify within those two categories (e.g. historical fiction and sci-fi, politics and programming).
3. Spend more of the daily commute reading (instead of, say, scrolling through Twitter).
4. Choose to finish what I start or abandon what I don’t like. I’ve got a small habit of starting and not finishing books without deliberately setting aside ones that aren’t piquing my interest.

That about covers it for me. What have you read in the last year or so that you found meaningful and/or enjoyable?

I joined the United States Digital Service (USDS) back in April and currently work with my teammates at the Defense Digital Service (DDS). Alongside United States Transportation Command (TRANSCOM), we’re taking a fresh look at a sprawling mass of software and processes that over 400,000 military families use each year to coordinate movement of their household goods from one duty station to the next. We’ve heard the moving process described as the most stressful time in a service family’s life, second only to the stress of combat deployment.

For all my time spent at startups, agencies, and large corporations, I’ve rarely been involved in “design” activities such as user research, sketching sessions, and prototyping. Over the years, I’ve advocated for involving engineers throughout the design process. But while many managers pay lip service to the concept, when the rubber meets the road, organizations tend to prefer that their expensive engineers spend their time writing code. This attitude reinforces inefficient waterfall processes, prevents empathy building, precludes knowledge sharing between engineering and users, and results in lower-quality products.

As luck would have it, one of USDS’ core values is, “design with users, not for them.” In that spirit, I recently joined my DDS teammates in sunny O'Fallon, Illinois for a week-long design sprint.

Go where the work is.

We organized a Google Ventures-inspired design sprint by gathering a select group of service members, military spouses, civilian support staff, designers, and engineers with the goal of addressing some of the system’s most critical usability problems. We divided the group into six project teams, each tasked with developing a prototype that addressed a specific question around the theme of, “What would the moving experience look like if…?” Topics ranged from reimagining the inventory process to revamping the experience of visiting a transportation office.

The days were long and my brain nearly turned to mush, but I’m happy to report that by the week’s end, each team had successfully generated storyboards, produced prototypes, and tested their designs with military families. While working on a project team, I learned quite a bit about how an engineer can help organize, facilitate, and contribute to a successful design sprint.

Design with users, not for them.

I’ve wrestled with adequately capturing in words my enthusiasm coming out of the design sprint. I can’t understate the value I derived from being in the thick of the design process, sitting shoulder-to-shoulder with others deeply invested in improving such a critical system. I’ll do my best to highlight a handful of things I took away from the week’s activities.

One Conversation at a Time

This one is critical. Design sprint activities are purposefully time-boxed to drive project teams toward quick-and-dirty prototypes. In this hectic environment, side conversations could subdivide the group and divert attention from the task at hand. As one of two facilitators on my team, I had to gently—but firmly—keep sidebar conversations to a minimum. This wasn’t much of an issue in my project team, but it’s important to keep in mind.

Manage a Parking Lot

Before this design sprint, I wasn’t familiar with the meeting management concept of a “parking lot.” Basically: capture ideas or lines of conversation tangential to the meeting’s purpose in a “parking lot” for future recall and discussion. In the context of a design sprint, and given the haphazard nonlinear idea generation process, maintaining a parking lot will help the group focus without scrapping useful tangential ideas.

Ask Questions

As ideas flowed fast and furious, I found that asking plenty of questions helped the project team determine which ideas we should pursue, which we should discard, and which we should add to the “parking lot.” By asking plenty of questions, I was able to make sure I had the time to fully understand my teammate’s idea or position. Being asked questions by my teammates kept me on my toes and gave me the chance to refine and solidify an idea or position.

Listen Intently

With the clock running, adrenaline pumping, and ideas flowing, I found it difficult to quiet my mind and really listen to my teammates. My brain was in overdrive coming up with possible solutions when it should have been listening to what my teammates were sharing. Remaining mindful of my own inner voice and actively listening to others was a struggle, but a worthy one.

Create momentum.

We heard repeatedly from participants how much they enjoyed contributing and how excited they are to see their solutions considered for implementation. Some of these folks have served their country or worked in government for literal decades. They related how, in the past, they’d offered solutions to the problems we’re addressing only to watch their ideas fail to gain traction. I’m humbled by the tenacity of those who, despite the relative ease of cynicism, so freely participated and shared their experience.

I’m also grateful for the chance to take part in this design sprint. I was able to exercise a set of skills I don’t normally flex in my regular project work. The week’s activities also built empathy with the military families affected by the current systems and processes. For a brief moment, they opened to us a window into their lives. We demonstrated that cross-functional teams—designers, engineers, and users—could rapidly design, prototype, and test solutions to some of the system’s most critical usability problems.

I fully intend to participate in future design sprints and will continue advocating for an engineer’s role in the design process. If you’re an engineer, I’d encourage you to speak up when you next hear about an upcoming design sprint. If you’re a designer or project manager, include the engineers on your team as you plan out your next design sprint. Together, we—designers, developers, users—can create compelling solutions to critical challenges.

For more examples of governments using the design sprint model, check out the following Sprint Stories case studies:

• US Marine Corps: A design sprint with machinists
• GOV.UK: How We Ran a Design Sprint in Government

Many thanks to James Athey, Justin Ellsworth, Jordan Kasper, Reina Staley, and Elliott Wilkes for reviewing an early draft of this post.

I joined the team back in September, 2015 with the goal of corraling front-end development efforts across the company’s sprawling engineering organization. Life often throws you curveballs and my time at LivingSocial-slash-Groupon provided ample opportunity for some serious batting practice (to stretch a thin sportsball metaphor). Perhaps I’ll write more soon reflecting on the lessons I’ve learned and the people I’ve come to know over the past year and a half and the lasting impression the experience left on me.

But! Today, I’m looking forward. I’m leaving the private sector to join The United States Digital Service (USDS).

Record scratch. Freeze frame.

Jason… you’re joining the Federal Government? Now?

Right? I agree. On the surface, this is a little crazy, but hear me out.

Irrespective of any opinions regarding November’s election (and believe me, I have opinions) and the events transpiring literally every day since (again, opinions), the fact remains that the American people deserve an effective and efficient government that meets their needs. Specific to my particular skill set, the American people deserve effective and efficient digital interactions with their government. Given the current state of government information technology, the work in this realm is plentiful.

With our country’s politics in what may be described charitably as a death spiral, I don’t begrudge anyone for leaving government or for not getting involved in the first place. I understand. Bigly.

For me, though, the choice is binary: I could stay in the private sector, lament the increasingly distressing state of affairs, and hope others would fix the problem or I could roll up my sleeves, run into a metaphorically burning building, and do my damnedest to make things better.

I’m choosing the latter.

Steve Jobs famously asked then-Pepsi-Cola president John Sculley:

Do you want to sell sugar water for the rest of your life, or do you want to come with me and change the world?

Selling coupons for bikini waxes won’t change the world. Building the next disposable media creation app won’t change the world. “Disrupting” grocery shopping for wealthy urbanites won’t change the world.

Fixing a broken health care registration process for veterans will change the world. Streamlining student loan repayment will change the world. Bringing immigration application and refugee admissions systems online will change the world.

These are three examples of the kind of work done by the teams at USDS. In their short two-and-a-half year existence, they’ve begun to reshape how government approaches technology and design projects. USDS recruits technical talent from the private sector for term-limited tours of duty and seeks to foster a spirit of public service among technology professionals. You should give USDS’ mission statement a read. It’s solid stuff.

The Best and The Worst

At the beginning of our conversation, the first thing Chris Lynch said to me was, “This will be the best and worst job you’ll ever have.” He used more, um, colorful language than that, but you get the idea.

The work won’t be easy, I’ve been assured of that during every step of the interview process. Nor will the work be cutting edge, I’ve been told. The work will be meaningful. The work will fix things that are broken. The work might even change people’s opinions about their government.

It’s going to be an interesting—and rewarding—couple of years.

On to the original post…

At work, we’re in the thick of rebuilding several of the key pages in our Restaurants Plus product. The team’s making great progress building out a mobile-first, responsive, progressively-enhanced website while concurrently developing a reusable pattern library for future development (and future teams). I’ve particularly enjoyed the challenges of building out the updated “explore” page: a JavaScript-heavy page listing the participating restaurants in a metro area that’s filterable, sortable, and very dynamic.

There are a handful of lessons I’ve learned around writing high-performance, low-overhead JavaScript that I hope to cover in future posts, but for today, I’d like to share a few quick things that Jared and I did last week that improved accessibility in meaningful ways.

A Few Caveats…

First, I don’t self-identify as an accessibility expert (few do, in fact). I’m merely a for-now able-bodied front-end developer with an interest in building products accessible to all. I’ve also had the good fortune of learning from local accessibility guru John Croston and other accessibility advocates like Derek Featherstone, Aaron Gustafson, and Marcy Sutton. We all benefit from the open sharing of knowledge on the part of the Web accessibility community.

Second, the changes outlined here are what I’d consider low-hanging fruit. Simple webpages often require only simple updates to improve their accessibility. More complex pages (like the “explore” page referenced above) naturally require more complex code to provide an accessible experience. My goal with this post is to demonstrate how even small changes to a page’s design and code can yield quick accessibility wins.

Third, accessibility is a practice and requires consistent attention over a project’s lifetime. You never really cross accessibility off of your project’s to-do list, just as you wouldn’t treat performance as “done.” That may seem daunting, but it’s a good thing for your customers, your team, and your business.

Tools and Guidelines

There are a number of tools for testing a website’s conformance with Section 508 (a U.S.-centric accessibility standard) or the W3C’s Web Content Accessibility Guidelines (WCAG) 2.0. The browser bookmarklet HTML_CodeSniffer is a personal favorite, but there are other useful tools available:

• pa11y: an automated accessibility testing tool available in several flavors.
• Tenon.io: a hosted automated accessibility testing tool.
• tota11y: an accessibility visualization toolkit from Khan Academy.

These tools make objective evaluations of your website’s accessibility against known standards and should be supplemented by real user testing to determine the practical accessibility of your website. You could conceivably design and build a website that passes WCAG 2.0’s AA compliance level but that has inaccessible complex interactions. So: keep in mind that automated accessibility testing is a starting point.

Small Changes, Big Improvements

For the purposes of this post—and to demonstrate the utility of automated testing tools as a starting point—I used the HTML_CodeSniffer bookmarklet to check against WCAG 2.0’s AA compliance level. Running HTML_CodeSniffer on the aforementioned work-in-progress “explore” page yielded a high number of conformance errors and warnings. Paging through the results, I found the most common error had to do with insufficient color contrast:

This element has insufficient contrast at this conformance level. Expected a contrast ratio of at least 4.5:1, but text in this element has a contrast ratio of 1.53:1.

The element in question appears throughout the UI and contained white text (hex triplet #fff) on a light grey background (#d1d1d1), which is quite difficult to read and clearly lacking contrast. Working with the design team, we iterated on the design and decided on dark grey text (hex triplet #666) against a light grey background (#e6e6e6), giving the element a color contrast ratio of 4.6:1. Success!

The next error was similarly easy to identify and resolve:

Anchor element found with a valid href attribute, but no link content has been supplied.

In this case, the element in question is the site’s navigation control, commonly known as the hamburger icon. The markup looks something like this:

<a href="#site-nav">
    <svg><use xlink:href="#sprite-hamburger"></svg>
</a>

We’re using an SVG icon sprite (which I’ve written about previously) to manage our website’s icons and the pattern above references an icon with the <use> element.

<svg style="display: none;" version="1.1">
    <symbol id="sprite-hamburger" viewBox="0 0 22 16">
        <title>menu icon</title>
        <path d="…">
    </symbol>
    <!-- additional <symbol> elements here… -->
</svg>

As is good practice, the SVG <symbol> representing the icon has a child <title> element with descriptive content of “menu icon.” Since the SVG contained a meaningful <title> element, I was initially confused by the reported error. I checked the page with VoiceOver and confirmed that “menu icon” was spoken aloud indicating that, in an indirect way, the anchor element had content that would be read by the screen reader. (I’m unsure if this is a shortcoming of the conformance parser or a genuine error. Any thoughts, accessibility friends?)

Regardless, it’s easy enough to add meaningful content to the anchor:

<a href="#site-nav">
    <svg><use xlink:href="#sprite-hamburger"></svg>
    <span>Site Navigation Menu</span>
</a>

We can then use CSS to move the <span> out of the viewport while leaving the element perceivable to assistive technologies. In my testing, VoiceOver read “Site Navigation Menu,” preferring textual content in the HTML over the SVG’s <title> element.

Accessibility is never “done”

The changes outlined above—which took very little time and effort—greatly reduced the number of WCAG 2.0 AA errors and warnings reported by HTML_CodeSniffer and meaningfully improved our pages’ accessibility. Our work is far from finished, though.

As mentioned earlier in this post, accessibility is never “done” and must become an integral part of an organization’s design process. Likewise, automated evaluation and testing tools like HTML_CodeSniffer serve as a great starting point, but should be augmented with real user testing to ensure that a website’s design and buildout are accessible to all.

I voted because it’s my responsibility as a citizen in our ever-improving democracy.

I voted against hatred, fear, xenophobia, racism, and misogyny.

But more importantly…

I voted for an imperfect but overly-qualified candidate who represents more of my values than not.

I voted for a vision of a more equal and more just America for my beautiful nieces and nephew. They deserve nothing less.

I voted for a woman because it’s beyond time we broke through that glass ceiling.

I voted for reforming a criminal justice system that discriminates against African Americans.

I voted for a leveling of the playing field for all Americans.

I voted for a candidate who acknowledges that the Earth’s climate is changing, that we’re responsible for that change, and that we have the means of confronting and solving the problem.

I voted for pragmatism.

I voted for inclusivity.

I voted for womens’ rights.

I voted for civil rights.

I voted for human rights.

I voted for equality.

I voted for love.

I voted and I encourage you to do the same. Visit iwillvote.com for more information on where you can vote today.

Many of you know I play guitar in an instrumental post-rock band—The Orchid—here in DC. If you follow me on Twitter or Facebook, you’ve no doubt seen me sharing our music, events, and photos. The band’s been a big part of my life for the past eight years and is one of many ways I stay creative outside of work. In our time together as a band, we’ve recorded and released two EPs and two full-length albums available for streaming and purchasing on Bandcamp.

Our most recent album, Apogee, Perigee, features six songs exploring the theme of isolation:

From the massive, three-guitar assault of album opener, The Astronaut (Escape Velocity), to the haunting, suffocating sparseness of the closing Life in Retrograde, the album weaves together influences ranging from Morricone’s Spaghetti Western soundscapes to DC-infused punk and math rock. The album moves effortlessly from crushing rhythms to delicate, intertwined arpeggiated guitars—often within a single song.

This is a very personal record for me and one that I’m excited to have completed and available for the world to enjoy. We’ve so far received positive reviews from friends and fans here in our native land, but the album’s first review comes to us all the way from Germany!

German-language music website Gezeitenstrom recently published a review of Apogee, Perigee. Being in no way fluent in German, I turned to my friends Jeremy and Jessica and asked for help translating the review. Jessica works as a freelance German translator and very kindly agreed to help translate the review’s text. Seriously, Jessica is a fantastic translator and an all-around wonderful person, so if you find yourself needing translation services, check out her website, lostintranslation.com.

I’m grateful to Jessica for her time and expertise and to Gezeitenstrom’s publisher André for enjoying our music enough to write up the following review, republished here in English:

An acoustic essay about isolation.

What makes The Orchid particularly intriguing is that every few years they reemerge with an album which sets high standards in terms of creativity and inspiration. Four years back, the band made a big impression here on Gezeitenstrom with its post-rock work “Beyond the Vast, Endless Sea.” The Americans went quiet again after that—until now. They’ve used this time to evolve, as can be heard clearly on their new album “Apogee, Perigee”.

While they were still creating shoegaze-heavy post-rock on their previous album, The Orchid is now sailing more frequently into acoustically experimental waters. The album “Apogee, Perigee” also follows a concept: it explores the subject of isolation. This emotional theme is conceptualized very differently in all six songs and The Orchid interpret it in a very comprehensive way.

In this album’s sound structures, modern post-rock increasingly gives way to influences from math and art rock, but it never disappears entirely. This combination of energetic walls of guitar and dynamic shifts in tempo and intensity very vividly conveys the band’s creative process. Even classical instruments such as cello and violin have been included, giving individual songs an expressionistic touch.

One very good example of this is the song “A City of Plaster.” Classical instruments are used here to very quietly and sedately capture an atmosphere of loneliness. Isolation has many different facets for The Orchid, an aspect explored in songs such as “The Astronaut” and “Decompressor/The Last Dive.” Guitars are used very intelligently as emotional connectors in these spheres of sound, and their message is revealed through magnificent arpeggios.

For fans of traditional post-rock, The Orchid have “My Affinity is Fire” up their sleeve, a piece that stands somewhat apart from the rest of the album with its catchy soundscapes and dynamic changes. Another very appealing song is the quiet “Life in Retrograde,” which very successfully interlaces elements of alternative rock with aspects of the post-genre and even ambient music.

On the whole, “Apogee, Perigee” is a very big step forward for the career of the five Americans. The album thoroughly succeeds in breaking out of familiar schemas and forging new paths. The Orchid deserves a good deal of respect for the courage to do this. They’ve gone in a new direction which has been implemented nearly perfectly, both acoustically and technically. Fans of experimental rock will certainly enjoy the new album.

Streaming and purchasing options are available on Bandcamp.

Twice in the last three months I’ve spent an afternoon digging into our traffic data collected with Google Analytics (GA), specifically looking at devices, operating systems, and browsers. I set out to gain a better understanding of the technology our customers use and, in turn, use the data to make some decisions about how we design and build our products.

Let’s first take a look at some stats from the end of last year.

November-ish, 2015

We long ago had our mobile moment, so it was no surprise that 59% of our traffic came from what GA classifies as “mobile” devices. I’m generally not a fan of this distinction since the term “mobile” generally carries a lot of assumptions around device size, interaction modes, user intention, and browsing environment. But… for our purposes here, “mobile” amounts to devices that aren’t laptops or traditional desktop computers.

By platform, we saw 42% of traffic from iOS devices and 33% from versions of Windows. Android usage trailed behind at roughly 16% and OS X hovered around 8% of overall website traffic.

Of the 59% of our traffic classified as mobile, Apple’s iPhone (57%) and iPad (13%) carried the day. Samsung device identification makes collecting device-specific stats difficult, but with a little work I was able to determine that the Galaxy S5, Galaxy S6, and Galaxy Note 4 accounted for 5%, 4%, and just over 1% of mobile traffic, respectively. Beyond that, we quickly get into the very long tail of devices accessing our site. (If you’re curious about the abundance of viewport sizes out there, check out viewportsizes.com).

On the Windows side of things, we had quite the browser party going. The following table lists browsers with greater than 1% of total visits. Values in the percentage column are relative to overall website traffic.

Seeing the then-current version of Google Chrome at the top of the list wasn’t much of a surprise. Internet Explorer (IE) 11’s second-place finish was slightly surprising, though, and the continued presence of IE 9 and 10 made this front-end developer’s soul hurt just a little bit.

At the end of last year, Internet Explorer accounted for 11% of our traffic and the overwhelming majority of that traffic was IE 11 coming from three different versions of Windows: 7, 8.1, and 10. Yeesh.

But Internet Explorer’s a dead browser, right?

While it’s true that Microsoft discontinued Internet Explorer in favor of its successor Edge, it’s equally true that discontinuing development of a browser has little impact on usage of that browser. Amongst LivingSocial customers, at least, we’ve recorded very low adoption (~1.25% of overall website traffic) of the newer—and perfectly capable—Edge browser.

February-ish, 2016

Jumping ahead to the here-and-now…

Looking at data across the last thirty days revealed that mobile devices now account for 61% of overall website traffic, up from 59% three months ago. iOS and versions of Windows continue to account for 42% and 32% of traffic by platform, respectively.

Three months ago, the latest version of Chrome (46) accounted for 13% of overall website traffic. Today, Chrome 48 (the current version) accounts for 13% of overall website traffic. While there’s no percentage change in Chrome usage, that our customers using Chrome tend to run the most up-to-date version is good news.

Internet Explorer 11’s aging talons maintained their firm grasp on 8% of overall traffic while all versions of Edge (12 up through the just-released 14) gained some minor ground in the last ninety days.

That Windows browser rager we were throwing for New Year’s? Things have changed.

Keep in mind the browsers listed above are only those browsers that charted greater than 1% of overall website traffic in the dataset. While current versions of Chrome and Firefox top the charts alongside IE 11 just as they did three months ago, long gone are IEs 9 and 10. Throw in the current-minus-one version of Edge and a random version of Chrome (43) and you’ve got a reasonably calm dinner party on Windows.

The Path Forward

What useful information can we glean given the above data?

Our Mobile Future

As mobile traffic continues consuming a larger share of our overall traffic, our design process should similarly shift from developing and maintaining unique “mobile” and “desktop” designs to a singular, mobile-first responsive design philosophy. A unified front-end, built with a focus on accessibility and performance, would result in a better experience for our customers and a more maintainable code base for our engineering team.

Support vs. Optimization

Using techniques like progressive enhancement (e.g. cutting the mustard), we can build future-friendly products optimized for modern Web browsers and devices while also delivering a usable baseline experience to customers on older browsers. Brad Frost draws the distinction between support and optimization, calling for more consideration on the part of front-end developers:

Start with a strong, semantic foundation, layer on styles smartly, and add in unobtrusive Javascript to build up the experience.

On that point, the above data indicates that we should optimize for current versions of Safari on iOS, Internet Explorer 11 (and current versions of Edge) on Windows, and current versions of Chrome and Firefox across all platforms. That’s a pretty awesome browser matrix. For largely historical reasons, our current front-end code tends to optimize for IE 8 in many places, but a quick scroll through this caniuse.com comparison of IE8–11 shows just how much has IE has improved since version 8’s 2009 release.

A Modern Baseline

With IE11 as our optimization baseline in 2016, we’ve opened the doors to many modern Web technologies: flexbox and all ES5 language features, for instance. Pushing even further, we could take advantage of cutting edge features like responsive images (the <picture> element and srcset attribute), Promises, and Service Workers to deliver an improved user experience.

As we continue building and iterating on new products like Restaurants Plus, I’m excited to help our teams push our design process and development approach forward and deliver accessible, high-performance, and beautiful products for our customers.

IndieWebCamp

Flashback to September 2013: I’m in Brighton, UK, attending dConstruct and my first IndieWebCamp. There I found a group of people—tinkerers, really—interested in taking back ownership of their content from third party services more interested in pleasing investors than in pleasing their users. But something separates IndieWebCamp from the rest of the crowd shouting about Web hegemony: this community recognizes the value that silo'ed networks provide (e.g. Facebook’s where your parents hang out online.) while emphasizing the importance of maintaining ownership of the content—words, photos, videos—you produce.

For me, that’s the key differentiator and why I like this community-slash-movement: it doesn’t advocate wholesale rejection of massive, corporate social networks. IndieWeb is largely about creating for oneself first while developing mechanisms that enable communication between your personal space on the Web and those massive, corporate social networks.

There’s plenty more IndieWebCamp-related things to write about, but in the mean time, you can learn more at indiewebcamp.com.

Bringing it back home

For years, I used the static site generator Jekyll to create new blog posts, written in Markdown, and pushed out updates by deploying code with GitHub and Capistrano to my barebones DigitalOcean-hosted server. The whole process was relatively straightforward and I was serving static HTML (…and CSS and JavaScript and images). Nice and easy.

But there are boundaries to what one can reasonably achieve with a static site. I wanted to post photos to my site. I wanted to support receiving and sending webmentions. I wanted to more easily cross-post to Twitter, Facebook, and Flickr much more easily.

I started by building a separate webmention-receiving app in Ruby using the Sinatra framework. It ran for quite a while, collecting incoming webmentions, verifying them (manually, unfortunately), and returning all verified webmentions on my blog posts when requested. It worked, but I didn’t like that it was an app separate from my main website and that there wasn’t a “real” user interface for verifying webmentions.

So.

In October 2014, I set out to create an IndieWeb-friendly CMS of my own. Built in Ruby using Sinatra, FranklinCMS FrancisCMS, named for the Chairman of the Board, would over time morph from a Sinatra app to a Rails app before settling out as a Rails Engine. You can read all about the particulars of implementation over on GitHub.

I spent over a year learning, writing, and rewriting FrancisCMS. I should’ve launched months ago, but… you know: hand-wringing. The important part now is that I did launch my site and that I continue working on it regularly at events like Homebrew Website Club (which is where I’m at as I write these words).

For me… and maybe you

In true IndieWeb spirit, FrancisCMS is built for me first. But… you may also find it useful. It’s not the easiest thing in the world to get up and running, but I’ve done my best to document FrancisCMS’ features along with detailed usage instructions. Naturally, there’s still plenty more I’d like to do with it.

This is my space for tinkering, after all.

I was able to keep up the pace in the second half of the year mixing in a heavy helping of graphic novels (working through that comiXology collection), a handful of fiction, some design books, and a pair of motivational books by social worker and public speaker Brené Brown.

Here’s the complete rundown of what I read in the second half of this year:

• Crooked Little Vein by Warren Ellis
• City of Thieves by David Benioff
• Something Wicked This Way Comes by Ray Bradbury
• Designing for Performance: Weighing Aesthetics and Speed by Lara Callender Hogan
• RASL by Jeff Smith
• Boom! Voices of the Sixties Personal Reflections on the ‘60s and Today by Tom Brokaw
• Young, Gifted, and Black: The Story of Trojan Records by Michael de Koningh and Laurence Cane-Honeysett
• Cunning Plans: Talks By Warren Ellis by Warren Ellis
• Daring Greatly and Rising Strong by Brené Brown
• Spider-Man: Blue, Hulk: Gray, and Catwoman: When in Rome by Jeph Loeb and Tim Sale
• Batman: Year Two (Fear the Reaper) by Mike W. Barr and Alan Davis
• Batman: Year Three by Marv Wolfman and Pat Broderick
• Catwoman: Her Sister’s Keeper by Mindy Newell
• Using Webpagetest: Web Performance Testing for Novices and Power Users by Rick Viscomi, Andy Davies, and Marcel Duran
• Superman/Batman: World’s Finest by Dave Gibbons and Steve Rude
• Batman: Noël by Lee Bermejo
• The Missing Piece Meets the Big O by Shel Silverstein
• Batman/Huntress: Cry for Blood by Greg Rucka and Rick Burchett
• Catwoman, Vol. 1: The Game by Judd Winick and Guillem March
• Batgirl, Vol. 1: The Darkest Reflection by Gail Simone and Ardian Syaf
• Superman: Red Son by Mark Millar and Dave Johnson

Did I mention Batman is my favorite superhero…?

I feel really good about the amount I read this past year and fully intend to keep up the pace in the new year. If you’d like to follow along or share what you’re reading, you can find me over on Goodreads.

Quite a lot’s changed since then. This site is now hosted with Digital Ocean and I long ago abandoned WordPress in favor of Jekyll. I’ve been hard at work for far too long on an IndieWeb-friendly CMS, dubbed FrancisCMS, that I hope to launch over the upcoming holidays.

Some things haven’t changed, though. I’m still very much a Web developer. I live and work in Washington, DC, and I play in a post-rock band with some friends of mine. I also still enjoy taking photos.

Those remain the basics for the time being. As I’ve tried to do over the last ten years, I’ll continue to use this space to post things I find interesting and explain to you why I find them interesting. I’ve no idea what the Web (or this small site) will look like in ten years, but I’m excited to help shape it.