By Aaron Gustafson

Each month, A List Apart’s editors select an article An Event Apart attendees shouldn’t miss, and we share it here. Enjoy this month’s essential reading, from ALA editor-in-chief Aaron Gustafson.—Ed.

It seems like ever since Frances Berriman  coined the term “Progressive Web App” in an effort to describe a new class of website, there’s been a great deal of confusion over exactly what a Progressive Web App (PWA) is. Sure, her husband, Alex Russell, put together a handy guide to the characteristics of a PWA, and they have been the subject of reams of documentation, dozens of blog posts, and equally as many conference talks.

Even with so much well-written, accessible content about PWAs freely available, misinformation abounds. Maybe you’ve run into one or more of these:

• If you’re building a PWA, you need to use a JavaScript framework.
• To build a PWA, start with a single page app.
• PWAs only make sense for “apps” your users want to install.
• PWAs only make sense in mobile.
• PWAs are an Android thing.

None of these are true, but like so much misinformation these days, each contains a shred of truth that has been contorted into a falsehood. If you’re considering building a PWA, you might use a JavaScript framework or build it as a single page app, but it’s by no means necessary. They’re an option for building a PWA just like they’re an option for any other web project. After all, every PWA is (or at least should be) a website. PWAs just have some features that empower them to do more than websites have traditionally been able to … like install. But, similarly, installation is not the raison d’être of every PWA. And, while many of the first PWAs were focused on mobile and only worked on Android, PWAs are not limited to small screen devices anymore. They’re also more than a Google thing too; Microsoft, Mozilla, Opera, and Samsung are all on board. Apple recently declared their intent to implement Service Workers (one of the technical underpinnings of PWAs), but time will tell if they’ll support aspects like installation. No matter, as Progressive Web Apps work really well in Safari anyway!

Sadly, misinformation like this has convinced many designers and developers (and their management teams) that PWAs aren’t appropriate for their projects. They are! Your site—every site—should be a PWA. This approach offers benefits for every project on the web, but I’ll get to that in a minute. Before I do, I want to level-set on what, exactly, makes a PWA a PWA. If you’ve been tracking PWAs closely or have already built one, you can skim or skip the next section. If you aren’t all that familiar or don’t feel like you have a good grasp on what they are, no worries, the next section is a very brief primer that will get you up to speed quickly.

So what is a PWA?

As I mentioned, a PWA is a website with special powers. The term “app” in the “Progressive Web App” is not indicative of the sort of content or experience users should expect with a PWA. You shouldn’t get hung up on it; “Progressive Web App” is a marketing term. PWAs have the ability to connect with the operating system (and, thereby, its users) on a deeper level through installation and APIs offering capabilities like notifications, access to the address book, and more. Not all of these APIs require installation for access, but some do. It may help to think about a PWA as being a website++.

What makes a PWA a PWA? Not much, actually; there are only three requirements:

1. You need to be running under HTTPS. PWAs can be granted a whole host of extra privileges in an operating system, so it’s critical that the connection to your web server be secure. If you need help with this, you should check out the free SSL service Let’s Encrypt.
2. You need a Web App Manifest. This is a lot less scary than it sounds. It’s a JSON file with information about your site. You may even have a bare-bones one already if you’ve used a favicon generator. Make sure you reference it using a link in the head of your web pages so browsers and search spiders can find it.
3. You need a Service Worker. This is probably the most complicated step, but there are a ton of recipe guides out there for creating Service Workers tailored to the kind of jobs you want them to do. This one, from Mozilla, is especially good.

That’s it. Once you have those in place, your website is a Progressive Web App. At least technically. Why the qualification? Well, this is where things get a little more nuanced.

Back in 2015, when he debuted the PWA concept, Alex Russell outlined ten characteristics PWAs shared (or at least were capable of). Most of those characteristics are, without a doubt, how we should be building for the web. Others are not as universal and would not make sense in every kind of project. I suspect that might be one of the sources of confusion for folks considering adopting the PWA approach and it’s the reason I decided to write this article.

Quality experiences and the universal benefits of PWAs

In the next few sections, I will discuss several web project archetypes and how adopting some of these PWA characteristics can benefit their users. After all, that’s who we’re doing this for. But before I get to that, I want to discuss the seven characteristics of PWAs that are useful in any web project.

As I mentioned, there are some characteristics of PWAs that will absolutely provide value to your users and are well worth your time and consideration. In fact, all of them are considered best practices in web design and development.

First off, PWAs must be safe. As I mentioned in my discussion of their technical requirements, PWAs must be running under HTTPS. Period. Thankfully, the cost of running your site under HTTPS has dropped to zero. Sure, there are legitimate challenges to converting large existing websites over, but it’s worth it for so many reasons. The primary one is that it protects your users from malicious man-in-the-middle attacks being made by ISPs, in hotels and airports, infected routers, or others with network access. HTTPS ensures that both the code and content you send to your users actually arrives intact. It’s not fool-proof, but it’s an important step in protecting your users and your data. Running HTTPS is also a prerequisite for access to many of the newer (and more sensitive) APIs including Geolocation and Service Workers and for performance-boosting technologies like HTTP/2 and Brotli compression. It’s also worth noting that many browsers are beginning to mark non-HTTPS sites “unsafe” and SSL also affects search ranking.

I mentioned earlier that PWAs were never intended to be a mobile-only approach. PWAs are for everyone. Making your project available to more people on more devices with wildly varying operating systems, browser capabilities, system APIs, and screen sizes is only going to increase your reach and create more opportunities to be successful. This is where progressive enhancement and responsive design come in. By building responsive layouts, your designs will adapt to provide the most appropriate layout given the screen real estate you have to work with, whether dependent on the dimensions of the device or on the window size set by your user. Progressive enhancement enables your projects to adapt to an even wider array of variance, in both the execution environment (device, OS, etc.) and, more importantly, your users.

Progressive enhancement also helps you avoid situations where users can’t access your project because they happen to use a device or browser you’re unfamiliar with or haven’t tested on. It ensures your site works on any device that can access the web, regardless of its capabilities, allowing you to use your valuable time optimizing that experience for more modern browsers and devices. It’s also a more economical approach in the long-run.

Another quality Alex identified was that many PWAs are “app-like”. Note the like. They are not apps, but rather, provide app-like experiences that users—dare I say it?—enjoy using. The more you can do to provide a consistent, seamless, effortless user experience (which is really what “app-like” is implying here), the more likely you are to see repeat visits, increased sales, etc. It’s worth noting that this doesn’t mean you have to use JavaScript; it simply means you should think about the flow your users take through your site and take every opportunity to remove the friction from the process of them accomplishing their goals.

If you’ve built something, you probably want folks to find it. PWAs, by definition, are easy to discover. Your site’s content should be written in such a way that it pops up organically when people search for related topics. Don’t get all spammy, but take care to author content in a thoughtful, appropriate, and straightforward way.

Related to discoverability is that PWAs are linkable. If your users can reach a certain point in your site via natural navigation, you should do your best to ensure they can save their place by bookmarking it or when they re-launch their web browser and your site’s tab is re-launched. This also plays into how shareable your project is. You may also want to do yourself a favor and spend some time putting together some Open Graph meta tags and some JSON-LD to make your content even more shareable.

Last, but certainly not least, there’s network independence. This is the big one that gets developers so excited. Offline capabilities and persistent storage has, to some extent, been possible for a while now; heck, Microsoft debuted client-side data storage back in 1999! Alas, while client side data stores—IndexedDB, localStorage, etc.—have definitely come of age in the last few years, true control over resource caching has been pretty abysmal. Then came Service Workers and the Cache API. These two technologies work in concert with the Fetch API to make, intercept, augment, and store resource requests made from within your site, meaning your users may still access your content, even if their network connection is interrupted.

There are a ton of fantastic resources covering the ins and outs of Service Workers, so I’m going to skip the technical stuff and just talk about some of the neat things you can do with them:

• Prefetch and cache resources you know your users are going to need. This can improve performance dramatically.
• Cache every page and asset requested by your site so they don’t need to be retrieved from the server each time a new page is loaded. This improves performance on navigation as well as on return visits.
• Define a custom “offline” page. This prevents users from seeing the browser’s generic “You’re not connected” message.
• Look for a network connection first and provide the “live” copy of a given resource if it’s available, falling back to a previously cached “stale” version if it’s not. This can also prevent users from seeing “You’re not connected” messages.
• Respond to requests for JPEG images with WebP (which tend to be considerably smaller) versions of those images if the browser supports them. This strategy allows you to provide alternate image sources that improve performance without having to modify your markup.

Service Workers are capable of a whole lot more—some of which I will get into shortly—and are on track to be granted many more incredibly useful features in the not too distant future. They have already proven their worth and bring value to any project on the web. For a useful list of recipes, check out this cookbook from Mozilla or this one from the Chrome team.

Other PWA benefits by project type

Now that we’ve looked at the universally-beneficial qualities of PWAs, let’s shift gears. Every project is different, but there are a handful of archetypes that most web projects tend to fall into. And each of those archetypes can derive real benefits from running as a PWA.

Informational

When I think about informational sites, I’m talking about the kinds of sites many of us in the industry refer to as “brochureware.” Vanity sites are a good example of this. Small business sites whose interactivity tops out at a contact for or a phone number link are another. Portfolios would also fall into this category as would many restaurant sites.

In most cases, projects like these are there to serve folks wanting to know more about you, your business, a project, or something similar. In most cases, you’re not going to see a ton of repeat visits. Folks come to the site looking to find out a specific piece of information—which hopefully they can access quickly and easily—and they’re off again. They might return, but they might not, meaning the performance gains provided by a Service Worker’s offline caching could be useful, but likely won’t have quite the level of impact it would have on a site that gets frequent repeat visits. It’s also highly unlikely—though not impossible—that someone will actually install a project like this.

Depending on the type of site you’re building, you might consider integrating some device APIs. If the site is for a brick-and-mortar business, add Geolocation support. If you have sales or specials you’d like to inform your visitors about, you might consider integrating Notifications (either Web or Push).

Even though two of the oft-touted “major” benefits of being a PWA—install-ability and offline capability—are less applicable for informational sites, making projects like these a PWA is still beneficial. Those are just two aspects of being a PWA. Your users will thank you for building a site that works on every one of their devices, is easy to use, comes up in search, and is easily shared with their friends.

Periodical

Periodical sites encompass everything from a blog or newsletter or podcast to online comics, magazines, newspapers, and video programs. These sorts of projects are like informational projects, but are updated regularly (or semi-regularly). They also have an audience that is likely to return (ahem) periodically to read a new article, watch a new video, or listen to a new podcast episode. Since they share much of their DNA with informational sites—heck, a periodical may even be part of an informational site—all of the qualities that benefit informational sites benefit periodicals as well. There are, however, some capabilities that PWAs offer that periodicals are perfectly suited to take advantage of.

In discussing promotions or specials, I mentioned that Push Notifications could be an option for informational sites. They should be a given for a periodical site. Push Notifications provide a mechanism for your server to send an update to any instances of your Service Worker that are installed on your users’ machines. And, assuming they’ve granted you permission, those updates can be displayed to your users even if they don’t have your PWA installed or a browser tab open to your site.

Don’t take this as an opportunity to spam your users, as you’ll likely lose their eyeballs and business. Instead, choose appropriate times to ping them. If your site only gets updates once or twice a week, notifying them of individual posts is probably good and can provide a nice alternative for folks who don’t use a feed reader. If you have frequent updates, consider a daily or weekly roll-up. This might even be a good candidate for some A-B testing.

You could also up your game by offering an easy in-page tool for saving an article for offline reading. Why would you want to do that rather than caching everything the user ever sees using the Service Worker? Well, given the nature of a periodical, the reuse of individual content items is likely pretty low. If you cache everything the use ever sees—especially if your content contains a lot of high resolution images—you’re gonna be filling their cache up with stuff they may never want to see again. In order to be a good web citizen, you could either clean that up regularly by keeping track of the last time a resource was accessed (which, frankly, seems like a lot of work) or you could cache just the necessary long-lived resources like your CSS and JavaScript files. Then you can put your users in control by providing a button that enables them to save an entry for later.

Continuing our journey through Service Worker land, you could start exploring Background Sync to pull in new resources periodically. If you’re a newspaper, maybe you want to prime your users’ caches every morning with the front page and the top feature stories. If you’re a podcast, maybe you want to load in the newest episode on a regular cadence. Again, to play nicely in the sandbox, you’ll probably want to trash older articles, episodes, and so on, but this could be a great way to provide an incredibly fast experience for your users. Think about it … they launch your site and the browser already has everything it needs to render today’s issue. Magic!

Finally, periodicals are one of those archetypes where the option to install your site begins to make sense. Some people like being able to hit an icon on their home screen or in the Start Menu to access their local newspaper. It’s not for everyone and may not be right for every periodical, but it’s an option. And offering your users the ability to install your PWA comes for free, so you may as well embrace it and make sure your Web App Manifest has been thoughtfully authored to provide a good user experience when your PWA is installed.

Transactional

Any site that facilitates the exchange of information could be considered transactional. The most common examples include online shops, banking and stock trading tools, travel booking systems, and payment portals. PWAs have, to a large extent, already proven their value in this area. A quick peek on PWA Stats revealed the following “wins”:

• The Raphael Hotels increased website conversions by 20%, pageviews by 66%, sessions by 59%, and reduced bounce rate 51%.
• MakeMyTrip saw a 3× increase in conversion and 160% increase in shopper sessions and first-time shoppers are 3× more likely to convert on the PWA than in native app.
• Lancôme saw a 17% increase in conversions, a 51% increase in mobile sessions overall and a 53% increase on iOS alone.

The kicker on that last one? iOS doesn’t even support Service Workers!

It’s well-known that improving page performance increases conversions, so the speed improvements granted by a smart caching and offline strategy with Service Workers are incredibly important here. But there are numerous other ways PWAs can benefit transactional sites as well.

Since I mentioned offline, I’ll add that your offline strategy should not begin and end with Service Workers. For a while now, we’ve used cookies to track transactional data shopping cart contents, but cookies have always been severely limited in terms of the amount of data they can store because they get sent along with every network request. With IndexedDB, localStorage, and sessionStorage, we have the ability to store more (and richer) data about the transaction taking place on the client side. Storing this information on the client makes it easier to recover from problems like a network loss. If a transaction fails, you will still have access to the data (which might have otherwise been lost in a failed POST) and you can either periodically try the transaction again or wait until you see the network is back before submitting it. Either way, adding real-time messaging about what’s going on and how you are working to resolve it will go a long way toward assuring your users that their data is not lost.

If your project is highly transactional, you will definitely want to look at Background Sync as a means of keeping your users’ local data in sync with server data. For example, if you are building a banking system, synchronizing information like recent transactions and current balances will be incredibly useful to your customers. Same goes with current stock prices and balances if you’re working on a trading platform.

In most transactional scenarios, notifications can be quite helpful. Borrowing on the scenario I mentioned earlier, notifications can be used to let someone know when their transaction has completed (after all, in a PWA you could complete the transaction during a Background Sync when your site isn’t running). Notifications come in a two flavors: Web Notifications are triggered via JavaScript in an active page, Push Notifications are sent from the server and can be delivered even when the site isn’t open. Depending on the scenario, one or the other will probably make more sense. Just be aware that Push Notifications are not as well supported as Web Notifications … yet.

For transactional sites that are frequently accessed (and I realize “frequently” is a very relative term) the install-ability of a PWA is a huge win. Isolating your site within its own app container allows users to focus on the task at hand, without the distraction of other tabs. It also insulates the processes running your code from the process running all of the sites they have open in their browser. Additionally, it has less overhead since there’s no browser chrome running alongside it. All of these benefits work together to create a streamlined, frictionless experience for your users.

Once installed, many operating systems will grant your project access to internal APIs. Perhaps you want to let them choose an address to ship a gift to, from their contacts. Or maybe you want to enable them to add the flights they just booked directly to their calendar. Or perhaps you want to voice-enable your app by integrating with their virtual assistant. All of those scenarios become possible in the context of a PWA, which is a huge boon for transactional websites.

Social

Social websites—think Twitter, Facebook, etc.—are excellent candidates for PWA-ification. In fact, Twitter has already gone that route. Social sites combine aspects of periodical and transactional websites, so they naturally inherit many of the benefits of those archetypes. Push Notifications, in particular, are incredibly important for sites like this, as re-engagement is crucial for the long-term success of your platform. Install-ability is also important in that regard.

Performance, especially initialization speed, is going to be an important benchmark for social projects, as users will not sit around waiting for all of their feed items (and their associated imagery, videos, etc.) to load. Caching your site’s assets will help a bit, but—depending on your project goals and situation—you might consider using Background Sync to update your users’ news feeds so they are ready to go (or close to it) the next time they open it up.

As transactional projects, social websites will also benefit from access to device and system APIs when installed. Most social networks, for example, request permission to peruse your Contacts to look for friends and colleagues that are also using the service. If you go that route, it’s imperative that you don’t abuse the privilege by trying to trick your users into spamming their friends with info about your service. If we don’t respect our users and their private information, we run the risk of losing access to it (and them) altogether.

Software

When we talk about “web apps,” often online software is what naturally comes to mind. Some examples include email clients, accounting tools, project management suites, version control systems, and photo editors. In many ways, these are software in the traditional sense, they just exist on the web instead of being installed locally … until now.

Through the magic of PWAs, these software-as-a-service projects can become full-fledged desktop (and mobile) applications. This enables teams that have gone all-in on web technologies to continue (or even increase) their investment in that area without sacrificing the convenience of install-ability on native platforms. Sure, there are absolutely some solid reasons why you might want to customize a native experience for your software, but for the vast majority of cases the web offers everything necessary to run your application … that’s why it’s on the web in the first place.

Offline data stores, background synchronization, and file system access help to elevate the experience for your users, making this archetype the most obvious beneficiary from Progressive Web Apps.

Institutional

Some projects are, frankly, too sprawling to fall neatly into one archetype or another. I’m thinking of schools, large corporations, mammoth financial institutions. These projects are often an amalgam of many or all of the archetypes I’ve covered here. As such, all of the benefits accrued to those archetypes apply, in context of course.

When looking at a large institutional project, it can be difficult to figure out how to assemble an overarching strategy for turning it into a PWA. The good news is that you don’t necessarily have to. You can carve up your project into many individual PWAs that can exist independently.

Take, for example, an online learning system. You could create a PWA for the learning system itself, but you could also carve off each individual course as its own, installable PWA, with its own cache, notifications, etc. The reason you can do this is that Service Workers and Web App Manifests can be scoped. You can scope them to a specific hostname or you could even scope them to a specific path within your URL structure. While obviously more complicated, if you think of each of those courses as having a course template and you think of a Web App Manifest and Service Worker being part of that template, it becomes easier to wrap your head around.

It’s your turn

Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. They’re just a shorthand for quality web experiences—experiences that can absolutely make a difference in our users’ lives. If you hadn’t considered building a PWA before, I hope this article has changed your mind. And if you’re already neck-deep in Service Workers, perhaps it’s given you some ideas for new ways to approach the projects you’re working on.

About the author

As would be expected from a former manager of The Web Standards Project, Aaron Gustafson is passionate about web standards and accessibility. He has been working on the web for two decades and currently reps the web at Microsoft, where he works closely with the Edge team. He is Editor-in-Chief at A List Apart and writes about whatever’s on his mind at aaron-gustafson.com. A list of Aaron’s articles may be found at at alistapart.com.

For more information every designer and developer needs, read A List Apart “for people who make websites.”

Illustration by Kevin Cornell.

The latest in our series “The Tools We Use” features Josh Clark, founder of Big Medium, a design studio specializing in what’s next: connected devices, mobile experiences, and responsive web design.

I’m both a creature of routine and a captive to my own muscle memory. This makes me incredibly (often ridiculously) loyal to my tools, and it takes a lot for me to pitch one overboard for a new one.

I mean, look, I’ve used the same brand of pen religiously for over a decade. I’ve inhabited the same software for 25 years (hi there, BBEdit). When I do adopt new software it’s often based on the same metaphors and keyboard shortcuts as familiar apps (Sketch works an awful lot like Keynote) so that I don’t have to do heavy context switching among apps.

In other words, my tools bend to the way I work and think, instead of the reverse. This makes me conservative about jumping onto the latest and greatest, but it also lets me focus on the task at hand instead of learning new settings, features and workflows.

Related: I tend to use Apple’s stock Mac software: Safari, Mail, iWork, Calendar… Individually, they’re not all best of class, but as a set they fit hand in glove and of course enjoy special integration with the operating system. It’s a suite of apps that talk easily to each other across devices, too, reducing friction and letting me get to work.

Here’s my kit.

Brainstorming + storytelling

From project pitch to product concept to UI design, everything about good design comes down to telling a good story. Here are the tools I use for gathering and presenting my thoughts.

Zebra Sarasa gel pen: This fast-flowing and quick-drying pen is my flat-out favorite; I haven’t used another brand in over ten years. I specifically prefer the 0.7mm tip for just the right mix of fluidity and friction on paper.

Sharpie stainless steel pen: When you need a marker, naturally Sharpie is a no-brainer. But did you know your Sharpie can also be chrome?

Baron Fig Confidant notebook: I treat my ideas more seriously when I keep them in a serious place, so I’m a fan of these clothbound, hardcover, open-flat notebooks. I prefer the dot grid paper, and the Confidant’s ribbon bookmark keeps me on the right page.

Post-its: Nothing beats a wall full of PostIts for flushing out ideas and getting them into rough categories. For facilitation of big groups, I’m also a fan of using them as jumbo-size “dots,” for dot voting. (Tip: Post-it Plus is a nifty iOS app that lets you photograph a wall of Post-its to capture them digitally for further rearranging, editing, and sharing.)

Spreadsheets: Every single one of my projects takes shape inside a flurry of spreadsheets. (Exciting, I know!) As you’d expect, spreadsheets are great for project plans and product roadmaps, but they’re also where initial screen designs happen, too. In web projects, I give every page a worksheet, with rows detailing the components on the page, in order. The first column of each row lists the name of each component; when you squint at that first column, it amounts to a first-draft wireframe of the mobile view: a single-column layout of components. Because these are typically collaborative documents, I tend to use Google Sheets for this (but reluctantly, as I describe below).

Ulysses: This wonderful writing app is where I wrangle all my words, from rough meeting notes to polished blog posts. It’s a Markdown word processor, which naturally puts the focus on ideas instead of fancy formatting. The plain-text documents are resilient, future-friendly ASCII files, but Ulysses can export to PDF, HTML, Word, ePub, and Word—or even blast your prose directly into Medium or Wordpress. The Mac, iPhone, and iPad versions are all lovingly designed to create a calm and focused place to marshal ideas.

Keynote: I’m inside this app every single day; it’s an extension of my brain. (Many years ago, I even wrote a whole book about using Keynote and the iWork suite; there’s deep muscle memory here for me.) Sure, I use it for presentations—for talks, or anytime I need to telegraph ideas to a group—but I also use it for tinkering with animations and quick design ideas. Keynote is effective as both a visual canvas and a laboratory for simple motion concepts.

Big Medium CMS. The Big Medium website runs on an eponymous CMS I wrote starting way back in 1999. It’s changed a lot in two decades, but from the start it anticipated today’s fascination with static-site generators (it builds static HTML pages). It’s hugely satisfying to keep folding new web technologies into the CMS as they emerge, and I enjoy maintaining independent control over my own content in a system I intimately understand.

Design + Production

I’m a product director and interaction designer, so my design production work is typically limited to wireframey UI sketches. I focus on a small suite of tools for this.

Sketch: This is where I do more UI work and tinker with vector graphics. Because Sketch is built on top of Mac OS’s native graphics tools, it also feels like an extension of the familiar iWork suite. (Sketch is basically a Keynote canvas on steroids.)

The Noun Project: A vast collection of high-quality, uniform vector icons. The website is great, and the Mac app is essential.

SVGOMG!: This is a GUI for SVGO (SVG Optimizer), a terrific tool for reducing and cleaning up the cruft in SVG files. (And Sketch’s SVG files are crufty.)

Code

Our design projects get into the browser as quickly as possible, so the bulk of the work happens in markup. Here are the tools I use.

BBEdit: My code editor since 1992, no kidding. (Until Ulysses stole my heart, it was also where I did all my writing.) Every year sees the arrival of a hot new code editor, but I’ve never wavered. The keyboard shortcuts, personal preferences, and overall experience are just too deeply engrained. It’s easy for me to think here.

CodeKit: I always have this Mac app running in the background while I’m slinging CSS and JavaScript. The app compiles my Sass, compresses my JavaScript, lints my syntax, and keeps all of the necessary libraries up to date.

Pattern Lab: Brad Frost first developed his original atomic-design pattern library when we designed the TechCrunch and Entertainment Weekly websites together. Since then, it’s grown into a sophisticated open-source tool for crafting a pattern library. More than that, it’s the environment where we do nearly all of our work now. For web projects, Pattern Lab has become our development environment, collaboration platform, and deliverable—all in one.

Github: Like pretty much everyone else, I use Github for version control. Some troubling stories about Github’s company culture have me looking around, though, and I’m eyeing Gitlab and Bitbucket as alternatives.

APIs

Recent projects and experiments with machine-learning and IoT have had me designing (and playing) with the APIs of a number of services.

IFTTT and Zapier. I use these services for quick prototypes when I need to play with chaining together digital services or tying them to physical triggers. I can’t even guess how many virtual actions I’ve hooked up to a simple USB button with these services.

Microsoft Cognitive Services: So many great services to work with here, from speech and image recognition to understanding language to Amazon-style product recognition. This is an ample playground for working with machine learning as design material. (See also the machine-learning APIs from Amazon AI, Google Cloud, and IBM Watson.)

Collaboration

I always work with remote teams and remote clients, so constant but meaningful communication is a must. Here are the tools that make that possible.

Google Docs: For collaborative documents, there’s just no escaping these apps, and believe me, I’ve tried. I’d prefer not to use Google’s apps at all. I have a deep uncertainty (and mild distrust) about how content stored with Google might be used now and in the future. The Google robots are certainly reading all of our content looking for patterns to display better ads, to develop new services, to tailor our search results. I like some of the fruits of that, but others leave a bad taste. The trouble is that none of this is particularly transparent. I’d rather use a paid, leave-my-stuff-alone service (Quip tempted me for a while), but most of the world prefers Google Docs, and so I reluctantly acquiesce.

Dropbox Paper: For prose documents and checklists, I much prefer Dropbox Paper to Google Docs. It has great collaboration features, and their business model doesn’t involve mining my content.

Dropbox: Each of my projects gets a Dropbox directory to share and archive assets and documents. For my personal files, of course, the service is my multi-device file system, keeping my world in sync.

Trello: I love me a Kanban)-style Trello board for managing all tasks in a project. It efficiently visualizes overall project workflow while letting me drill into the status of specific tasks.

Slack: Slack channels are like the live transcript of every project, which is at once great and horrible. The sheer flow of live chat often buries important content, which has me considering Slack alternative Twist. Twist emphasizes threaded conversations for a kind of hybrid between chat and email.

CloudApp: This is my go-to utility for sharing screenshots and screencasts. A quick keystroke grabs the screnshot/movie/gif, I paste the URL, and I’m done. The app’s annotation tools are handy, too.

Doodle: How many hours (days? weeks?) have all of us lost trying to find a time when everyone is available to meet? Doodle takes away much of the pain with its poll-style process for identifying available meeting times.

Productivity

These tools keep my head straight and my feet moving in the right direction.

Things: This Mac and iOS app maintains all of my to-do lists across every area of my life. Its interface and philosophy are both fairly straightforward—you just organize lists of lists—but it has many thoughtful grace notes that let me adapt the system to my specific organizational style. (I’m a Getting Things Done guy from way back, and Things is well tuned for that system.)

Alfred: This is my all-purpose app launcher, clipboard, search tool, calculator, music player, language translator, dictionary, and workflow manager. Command-space is all I need to make it all happen.

Pinboard: This is where I bookmark and stash notes on everything I read online. For $25/year, the app also archives the full text of every page I bookmark, a future-friendly bulwark against link rot. On iOS, the Pinner app makes it extra-easy to save and fetch my bookmarks.

Shoeboxed: I use this online service to scan receipts for taxes and expense reports. The iPhone app in particular makes this a breeze: take a photo and the app’s elves log the receipt into the proper category and even do currency conversion when necessary.

Media

These are the tools I use to stay current with a steady but manageable flow of info.

Reeder + Feedbin. Old school: I still use RSS feeds to stay current with my favorite writers and publications. I use Reeder on iPhone and iPad, combined with the Feedbin RSS service for syncing my feeds.

Instapaper: My longtime favorite service for gathering long-form reading for later. (I especially like that I can sync highlighted text as Pinboard links, a nice integration.)

Huffduffer: This marvelous little service from Jeremy Keith is Instapaper for podcasts. Grab audio snippets from anywhere on the web and add them to your own custom podcast feed.

Overcast: My preferred podcast app for iOS.

Housekeeping

A safe and secure digital life requires good digital hygiene. Here’s what I use to floss regularly.

1Password: This password manager makes it possible for me to have a unique strong password for every single login I’ve got. The app’s “Watchtower” feature even alerts me when one of the services I use may have been compromised so that I can update my password info.

Backblaze: Thsi service makes a cloud-based backup of all my files. I used to keep a local hard-drive backup, but that doesn’t do much for me when I’m traveling or (heaven forbid) if my home is hit by a meteor.

TripIt: I travel. A lot. TripIt keeps my itineraries straight—and keeps me on time.

Streisand: This remarkable open-source project made it easy for me to set up and deploy my own VPN server with the minimum possible fuss. It took about 15 minutes to stand it up, and my family now enjoys much-improved security when using public wifi (or on our own home network for that matter).

Piwik: I use this excellent open-source analytics package to track web traffic, as an alternative to Google Analytics. It’s a secure and privacy-conscious option (it honors the “do not track” http header, for example). And the data stays with me, instead of going out to a corporate giant.

In this free 60-minute video, captured live at An Event Apart Orlando: Special Edition, developer, entrepreneur, and world-renowned CSS expert Rachel Andrew introduces us to the web’s first native CSS grid layout system.

Since the early days of the web, designers have been trying to lay out web pages using grid systems. Likewise, almost every CSS framework attempts to implement some kind of grid system, using floats and often leaning on preprocessors. The CSS Grid Layout module brings us a native CSS Grid system for the first time—a grid system that does not rely on document source order, and can create complex layouts which are easily redefined with media queries.

Following along with practical examples, you’ll learn how Grid works, and how it can be used to implement modern layouts and responsive designs.

Enjoy all the free videos in An Event Apart’s library. And for your free monthly guide to all things web, design, and developer-y,  subscribe to The AEA Digest.  Subscribers get exclusive access to our latest videos weeks before anyone else!

The latest in our series “The Tools We Use” features Krystal Higgins, Staff Interaction Designer at Google Australia.

Whiteboarding, diagram sketching, and sketchnoting are key parts of my personal and professional workflows. Since I have a lot more virtual conversations these days, I’ve moved to digital sketching tools. The Bamboo Paper iPad app from Wacom is what I use for quick sketching on the go. In the office, I use a Microsoft Surface Studio to sketch larger diagrams for discussions with the local and remote team. Most sketches also get dropped into Google Docs or Slides for commenting.

I use Procreate’s iPad app to draw illustrations for my personal posts and presentations. It’s also great for exploring colors and layouts for watercolor paintings.

With an active community of contributors and powerful plugins, Sketch is my go-to app for quickly exploring UI variations and keyframes in an experience.

I’ve enjoyed rediscovering keyframe-based prototyping tools like Principle. What makes Principle helpful is that it imports Sketch files and retains the layer stack for easy object manipulation.

Keynote is still my default presentation app because of its built in recording and rehearse modes.

The Samson Go Mic vastly improved my ability to record high-quality podcasts and webinars, and has become my default laptop mic.

F.lux saves my eyes (and sleep patterns!) from the harsh blue glow of my laptop by adapting its color based on time of day.

And Skype has been a lifesaver, helping me keep in touch with everyone back home.

The latest in our series “The Tools We
Use” features Cloud Four’s very own Jason Grigsby.

I use far too many tools. Trying to figure out what would be interesting to others was challenging. Here’s my oddball list spanning design to code to utilities:

Atom: My current text editor of choice. I still open BBEdit every so often as a scratchpad and because I know its grep features best.

Drizzle: This is our own open source pattern library tool. We use it on nearly every project.

LICEcap: The worst named, best app that we use. LICEcap creates animated gifs from screen captures. We then share those animated gifs in Slack.

Netlify: We use Netlify to host the pattern libraries that we develop. It auto-updates from the project Github repo.

Lucid Meetings: We use Lucid for project meetings. We rely on its ability to set an agenda and help us keep our meetings on track. After meetings end, it publishes notes to Basecamp.

Web Page Test: My tool of choice to get a standardized look at the performance of a web page.

Lighthouse: For testing Progressive Web Apps.

Moom: I use this to resize windows multiple times every day.

Hazel: Hazel automates tasks on my Mac like emptying the trash or cleaning folders.

1Password: I currently have four secure vaults between work and home. I need to add a couple more. I love 1Password.

PhotoShop: For the usual image manipulation stuff.

Google Docs: For any documents or spreadsheets, Google Docs is now my default choice after years of being attached to iWork.

Keynote: Keynote is the exception to the above Google Docs rule. Nothing beats Magic Move.

Keynote Tweet: For tweeting while keynoting.