Professor Sharon Lewin
Director Doherty Institute for Infection and Immunity
At a conference I attended several years ago, one of the speakers talked about needing to hire someone to step in and substitute for another designer who had fallen quite ill. The speaker found his new designer from reading their blog. Because that designer wrote and shared his thoughts on the web, he got a job.
I went home from that conference and started writing. I started a blog with a basic WordPress theme that I got for free. I shared my thoughts and ideas. I can say, without a doubt, writing has led to many wonderful things.
It was through writing that I connected virtually with many of the people in the industry that I’ve gone on to meet in-person at conferences. It all started by taking notes at a Mobile Portland meeting and publishing them on my site. I continued to think more about mobile and shared my thoughts on my blog. Those posts were the beginning for me, they were how I realized that I had a voice, that my thoughts mattered, and that sharing them was a way to start a conversation with others who were thinking about the same topics.
Through writing, I solidified my ideas on style guides. When I went to write up a rough post for the company blog about how I created the style guide we were using, it pushed me to think about how I define these tools. That rough post never ended up on the company blog, but it did get published as an A List Apart article. As I worked with an editor to shape that piece, my thoughts on style guides morphed and changed until I knew what I wanted to say about them.
The publication of that article led to speaking about style guides at conferences, giving me some amazing (and nerve wracking) opportunities to talk about them more.
As I’ve continued to write, on my own site and others, it’s led to more opportunities. I believe it was through my writing that I got to work with an amazing team, at an amazing startup that is no longer. As I wrote quick pieces on my site, some of them grew and went on to become more somewhere else, such as my article on CSS audits here on A List Apart.
It can be hard and intimidating to put yourself out there, but you should write. You should take the ideas that you get, and see what happens with them. Submit to publications you think may be interested in your topic (hint, hint) and see what they think. Writing can lead to more than you can imagine.
Often, the pieces I have the most doubts about turn out to be the words that people read and relate to most. So in those moments where you wonder if you should share something, I say do it, publish it. Treat your blog like your drafts folder. When I’ve done that, great things have happened.
Oh, government websites. Bless their confusing little hearts. Every time I log in to make a federal payment (favorite UI copy: “REMINDER! PAY ALL TAX BILLS WHEN DUE!”), or to file paperwork for the Social Security Administration (which gave me this oh-so-helpful warning), I’m greeted by inconsistent and incomprehensible design.Button designs across multiple government websites. Source: 18F
But teams at the U.S. Digital Service and civic consultancy 18F are changing that—and sharing their work as they go. Earlier this week, they released the U.S. Web Design Standards, containing patterns and principles to guide designers across agencies. It’s a great complement to resources like 18F’s growing set of Guides (I, of course, am partial to the content guide). Not only am I excited for better-functioning government websites, but I also love seeing organizations working out loud and sharing their tools—because we could all stand to steal these ideas. —Sara Wachter-Boettcher, editor-in-chiefYour weekend reading
- Visual clutter, ambiguous icons, and hijacked scrolling are some of the accessibility issues that are hurting our users, according to Marcy Sutton. Marcy is committed to making web accessibility better, and we should all join her. Check out her slides from Responsive Field Day, watch one of her recorded talks, or visit her Accessibility Wins blog. —Yesenia Perez-Cruz, acquisitions scout
- October 1 is an important day for US universities: the deadline for publication of Clery Act campus crime statistics—reports invariably published as PDFs. With the inevitable tightening of accessibility regulations, Clery reports are a good candidate for regulatory scrutiny under ADA. As always, semantic markup is the key to getting it right. Here’s an hour-long walkthrough of PDF accessibility basics that covers requirements and best practices. For more resources, there’s also the WCAG 2.0 PDF techniques document, as well as a new PDF accessibility checker being developed by the European Internet Inclusion Initiative (there’s an HTML checker, too)! —Rose Weisburd, columns editor
- Comments—they once held such promise, but too often they turn into a horrorscape of hatred, trolling, and -isms. Thankfully, the team at Civil has a novel plan for restoring civility to the web. Visit the site, watch the video, sign up, and help them test their new platform. —Caren Litherland, editor
- Last month I got to practice some great facilitation techniques at Kevin Hoffman’s Better Meetings by Design workshop as part of Confab Intensive. If you run meetings or want to get more out of them, check out his articles “Kick Ass Kickoff Meetings” and “Facilitating Great Design.” —Aaron Parkening, project manager
- I attended a workshop on responsive web typography with Clearleft’s Richard Rutter last week. Among other useful resources, he shared this nifty tool he’s built, which shows OpenType features for different typefaces and even lets you copy the CSS. His next workshop will be in November in Brighton, UK, at the 2015 Ampersand Conference; early bird tickets are still on sale. —Michelle Kondou, developer
So, what made you stop trying to learn how to code? I'm curious about the barriers that get erected.— Anil Dash (@anildash) September 29, 2015 Overheard in ALA Slack OMG I love trash pandas so much. Your Thursday gif
For web platform enthusiasts, the developing ServiceWorker is a wunderkind among APIs. It’s taking a lot on: offline-first control over assets, performance improvements via network interception and cache management, background process enhancements.
It’s cool and I want to use it right away. I want to ride the offline-first wave. But ServiceWorker is in that awkward phase of partial adoption and implementation that raises the question I’ve asked myself before: how do I use this beautiful future thing, now?ServiceWorker, valiant in shining armor
Briefly, ServiceWorker provides a proxy, letting you make decisions about how to handle and respond to network requests coming from your (client-side) app.
Want to respond to requests for gif files differently if the browser is offline? ServiceWorker can do that. Want to explicitly retrieve assets from the browser cache for certain requests? ServiceWorker in conjunction with its pal the cache API can do that, too. Neat-o.
ServiceWorker is, in part, a do-over for the API devs love to hate: Application Cache, a.k.a AppCache (though, I should point out, ServiceWorker is considerably more functional than AppCache).The waning antagonist: AppCache
It’s rare that I say “this is really just how it is” about anything to do with web technology but, okay, I’m going to be straight with you: AppCache is awful to work with.
With AppCache, you (ostensibly) create a manifest file of the stuff you want the browser to cache locally. In practice, there are so many ways to get this wrong.
It’s confusing to debug and difficult (sometimes nearly impossible) to rectify if you make a boo-boo—which you will, because it is a cruel master. And it just doesn’t give you fine-tuned control.Ideals vs. present reality
AppCache is a beast, but it’s been around for several years and is supported by the majority of modern browsers.
ServiceWorker is partially implemented in about 45 percent of the world’s browsers—newer Chrome, Android, Opera browsers. That seems substantial; however, there is no official word that Safari will ever implement it.
Another wrinkle is that ServiceWorker is partially re-implementing something that already exists. There is no straightforward progressive enhancement from AppCache to ServiceWorker. Supporting both probably means writing certain functionality twice.
That means for real-world project architecture, I have several options, each unsatisfying on some level:
- Treat offline-first as an enhancement that works in under half of the browsers out there
- Write an offline approach using AppCache and then also write it in ServiceWorker for browsers that support it
- Write an offline approach in AppCache and leave it at that
Option 1 won’t fly right now if you have a need to support a broad set of users. Option 2 is technically possible, but requires logic duplication and budget-straining extra time. Option 3 is functional but unappetizing.So now what?
We’re caught in the limbo between the web as it is and the web as we hope it will be soon. My heart is in the future; our reality is in the less full-featured now.
There is an ongoing conflict between what we want to believe is immediately doable and what is, in fact, feasible. I don’t want to suggest an academia-industry divide, because we’re all on the same side here. But we sometimes get wrapped up in the promise and energy of new standards and are blind to their growing pains.
Every new standard has to pass through the shadows of doubt as it makes its way to the light of day. We’ll always need to choose which questing API heroes to throw in with, knowing not every contender can be victorious.
The web demands risks and, dare I say it, courage. Its democracy leads to uncertainty—no one’s entirely in control of this crazy thing. Which is why forward-looking web thinking is considered future-friendly, not future-proof.
I’m not clamoring to put the brakes on the pace of change. We are getting what we asked for, for the most part: accelerating invention and improvement of the web.
But I’d like us to recognize that making decisions about fledgling platform APIs and the changing web is another expertise we have, though we may take it for granted.
And that building the web every day is a leap of faith.
Help your developers and writers manage dynamic content on the web (and in apps!) with our sponsor Contentful’s API-first CMS.
At Bluecadet, we didn’t set out to do headless CMS development for its own sake. We were curious about it and could see the potential benefits, but we only ended up doing it when it solved specific problems we faced on two very different projects.
The first was a website for Haruki Murakami. We wanted to create as seamless an experience as possible, which meant experimenting with different animated transitions between sections on the site. We eventually settled on AngularJS to support those transitions, so the challenge was how to merge AngularJS with WordPress, the CMS we were using. There are a few themes that do this, but after some testing and much research we decided to use the JSON API plugin. The client got a familiar CMS to work with, but also a very tightly-orchestrated front-end layer that captured their creative vision for the project.
Why do I tell these stories? The key lesson for us was that a headless CMS helped solve a problem. We didn’t dive into headless CMSes because it was trendy, we did it because we needed to solve specific problems (in the first case an aesthetic/creative one, and in the second a data-management one). The other important outcome was that we could let each piece of the project do what it does best—by letting the CMS simply manage content, we could use better tools for rendering the presentation layer. We were also able to let our team members focus on what they did best: with the James Ensor touchscreen, our CMS developers were able to take care of the data management problem while our Cinder developers could focus on the touchscreen application.Use your existing CMS
So let’s say that you’ve got some very good reasons to go headless. Maybe you want to have control over the front-end markup and animation in a way that stretches past what your CMS’s theming layer can support. Perhaps you want cleaner separation of front-end and content-management tasks—it can be easier to staff multiple projects when the responsibility for building a site doesn’t require everyone to know both the front-end rendering layer in addition to the backend of the CMS. Or perhaps you’re not building a website at all. Maybe you’re building a native iOS or Android application, but you need a familiar, yet robust, way to provide data for it.
The good news is that your preferred CMS likely already has what you need. WordPress and Drupal both have modules and plugins to enable a RESTful API, which I’ve found to be the most straightforward way to provide data in a headless architecture. For WordPress there’s the aforementioned JSON API plugin, as well as WP-API (which is being developed with the goal of eventual inclusion in WordPress core). Drupal has the Services module and Services Views, which allows developers to turn Drupal output created with Views into API endpoints.
So far, the examples I’ve described are headless with a one-to-one relationship between the CMS and the front-end rendering application. A useful thing resulted from our work on those applications, however: my teammates and I started to decouple our expectations on the CMS side as well. For all the talk of dividing content from presentation, it’s still absurdly easy to build assumptions into your CMS for a single form of delivery. You start out knowing that the CMS will be used for a website, so everything from the order of the fields to the name of your fields is influenced by the form that it will take on the site. But what if your CMS later needs to support different products besides that initial website? This is something that Jeff Eaton and others on the ALA on Air panel addressed quite well, by drawing a distinction between the intertwined content management and web publishing responsibilities of most CMSes.
I’ve found that having to build CMSes that serve many individual products has made me focus more on flexibility. So even if I’m building something that is only being used for a website right now, in the back of my mind I’m wondering what would be required if we had to support a native iOS or Android application using the same CMS. I’ve started thinking of these as nearly-headless (or headless-ready) CMSes.
That relates back to one of the key tenets of the web: separating content from presentation. It’s why we have CSS separate from our markup, and rely on class hooks so that we can style things in ways that do not affect the semantics of the content.
Right now I’m at the very beginning of a CMS project that has to serve multiple products: multiple different touchscreen applications, iOS/Android apps, and a responsive website. If we hadn’t had the initial experience creating headless CMSes for those individual product types, we’d be nervous. But right now we’ve got confidence that we’ve done all of the separate pieces before, even if we’ve never tried to do everything using one CMS.Downsides
This is less an issue for native mobile applications, because those are always going to be separate from the CMS anyway. Still, simply having multiple software systems can be tricky, because each piece comes with its own assumptions and opinions on how things can/should be done. It also means that your team’s expertise has to cover different codebases. (Although that’s potentially an upside, if your team already has that expertise in both camps.)
My litmus test is pretty simple: does going headless with the CMS solve a key problem, and is it enough to outweigh the complexity added to the project?Try it out