
<YouTube youTubeId="V2izYekSSwY" />

From [Google I/O 2021](https://io.google/2021/): In this session, we (I) discuss marketing activities that help users discover and engage with what you’ve built on Google Assistant, as well as some updates to monetization features for Conversational Actions.


Driving a successful launch for Conversational Actions


<YouTube youTubeId="HX1bMuoZ6II" />

As a part of my work as a DevRel lead for Google Assistant, I did a guest segment on VOICE Talks in August of 2021, talking about why UX research for voice-first experiences is so crucial.


VOICE Talks August 2021: Trust the researchers for voice-first UX


<YouTube youTubeId="cw1wlHV4hGk" />

Tools like Eleventy, Hugo, Gatsby, Svelte, and others have given developers a superpower for quickly developing content-driven, easily manageable web properties. It's an exciting frontier for developers who are also content creators, but for non-technical creators, our favorite toolchains can feel like a labyrinth of indecipherable choices.

In this talk, we'll discuss our role in promoting the creator economy. We'll talk about the opportunity we have as developers in helping to democratize content creation for everyone, and the importance of creating a more robust, archival internet.

[Check out the slides](https://docs.google.com/presentation/d/1XFJ_nQfPnX0oPOUezOEwVKLZFtptTKemtGg41RJPisQ)


JAM Stack, SSGs, and their role in empowering the creator economy


<YouTube youTubeId="OaF_WhzNAKQ" />

From my work as a Developer Advocate on the Google Assistant team, this tutorial explains the difference between _shortcuts_ and _dynamic shortcuts_ for Android, and how to use Assistant to take advantage of this functionality.


Push dynamic shortcuts to Assistant


<YouTube youTubeId="lxviLXXvs3A" />

A brief, 2-minute Demo from [Google I/O 2021](https://io.google/2021/): learn how to create your first App Action for an Android app, which lets you connect your app's features to Google Assistant


How to create your first App Action


<YouTube youTubeId="z6l-V-EOGNY" />

A quick demo from [Google I/O 2021](https://io.google/2021/): we take a look at some user experience (UX) changes for card verification code (CVC) confirmation and new payment method entry for payments on smart screens.


New Transaction Features for Smart Displays


<Image
  publicId="external-references/fullstack-dev-article-aquent/cover"
  alt="Article screenshot: What the Heck is a Fullstack Developer? Aquent UK blog"
/>

An interview with my former employer (and parent company of [Gymnasium](https://www.thegymnasium.com/)), [Aquent](https://aquent.com) about my thoughts on what it means to be a Fullstack Developer.

Description from the article:

<Aside>
  To shed light onto what is for many a mysterious role—Full Stack Developer—we
  talked to our own Star of the Full Stack, Mike Bifulco. Currently the Director
  of Technology for Aquent Gymnasium, he was previously a User Experience Lead
  and Program Manager at Microsoft.
</Aside>

Full article is available to read on [Aquent UK's blog](https://aquent.co.uk/blog/what-the-heck-is-a-full-stack-developer).


What the Heck is a Fullstack Developer? Aquent UK


<Image
  publicId="external-references/proximity-acquires-smpl/cover"
  alt="A screenshot from a press release announcing proximity acquiring smpl"
/>

In early 2020, [smpl](https://smpl.io) was acquired by [Proximity](https://proximity.space). I was cofounder and CEO of smpl - we proudly helped independent coworking spaces manage their communities with automated billing, invoicing, and community management. It was a wild ride, and I couldn't have done it without my two amazing cofounders.

We were acquired by our biggest competitor, Proximity, who are continuing the dream by creating a network of amazing, independently owned coworking spaces around the world.

[Read the press release about the acquisition](https://www.proximity.space/news/proximity-acquires-smpl-software/) to find out more.

There is another (paywalled) article on [Business Insider](https://www.businessinsider.com/inside-a-coworking-software-deal-proximity-buys-smpl-2020-4) about the acquisition, too!

[More about smpl](https://www.crunchbase.com/organization/smpl-llc) on Crunchbase.

Tools we used to build smpl:

- [Firebase](https://firebase.google.com/)
- [Stripe](https://www.stripe.com)
- [React](https://reactjs.org)
- [Intercom](https://intercom.com)
- [LogRocket](https://logrocket.com)


Proximity Acquires SMPL Software


<Image
  publicId="external-references/matter-a-whole-thing/cover"
  alt="Cover slide: MATTER - a whole thing about design"
/>

From a talk I gave at my then-home-base [Hygge Coworking](https://wearehygge.com/) at a community event. The thesis: we're all designers, and you should give a damn about the things you put into the world.

Slides are [available on slideshare](https://www.slideshare.net/mbifulco1/matter-a-whole-thing-about-design).


Matter - a whole thing about design


<YouTube youTubeId="ukPI1zlxKqg" />

From my days working as Technical Director of [thegymnasium.com](https://thegymnasium.com): a 5-minute tutorial (lovingly referred to as a **Take 5**) showing how you can use GitHub pages to host your very own website.

The full tutorial (with additional reference material) is available **for free** on [The Gymnasium](https://thegymnasium.com/courses/take5/publishing-your-first-github-pages-website)

Gymnasium is a treasure - if you like this, get yourself a free account at [thegymnasium.com/register](https://thegymnasium.com/register), and start learning at your own pace today!


Publishing Your First GitHub Pages Website - Gymnasium Take 5


<Image
  publicId="external-references/the-perils-of-obedience/cover"
  alt="title slide: The Perils of Obedience, by Mike Bifulco"
/>

These are slides from a lightning talk I gave at a local conference in 2018.

I explain the Milgram Experiment, how absolutely terrifying it is, and how understanding Cognitive Psychology and Social Sciences can help us make the world a better place.

I also implore the audience to go register to vote. [turbovote.org](https://turbovote.org). Go do it!

Slides [available on Slideshare](https://www.slideshare.net/mbifulco1/the-perils-of-obedience) if you're interested in perusing.


Lightning Talk: The Perils of Obedience


<Image
  publicId="external-references/design-matters-zero-day/cover"
  alt="title slide: Design Matters, Hygge Zero day"
/>

These are slides from an empassioned talk I gave about design during a community event called Zero Day at [Hygge Coworking](https://wearehygge.com) in Charlotte, NC, USA.

The thesis: good design is important, and you should be paying attention to good-and-bad design in the world around you. Contributing to making the world better for everyone **is** everyone's job.

Slides [are available on SlideShare](https://www.slideshare.net/mbifulco1/design-matters-hygge-zero-day-93804671)


Design Matters, Hygge Zero day


<Image publicId="external-references/50-most-powerful-startups-in-charlotte/cover" />

I was cofounder and CEO of [smpl](https://smpl.io), a SaaS startup helping independent-scale coworking operators automate their business. We were featured in a 2017 Article by Axios Charlotte (then called **The Charlotte Agenda**) as one of the most powerful (lol) startups in town. Pretty cool!


50 Most Powerful startups in Charlotte


<Image
  publicId="external-references/edx-comprehensive-theming/cover"
  alt="Cover slide: Edx Comprehensive Theming tutorial, by Mike Bifulco"
/>

A talk I gave at Stanford University in 2016 on Comprehensive Theming for [Open EdX](https://open.edx.org).

Slides [are available on Slideshare](https://www.slideshare.net/mbifulco1/edx-comprehensive-tutorial)


Edx Comprehensive Theming Tutorial


<YouTube youTubeId="2VJmjmESvMo" />

(My talk starts at 5 minutes and 43 seconds into the video)

From [Open EdX Conf 2016](https://open.edx.org), this is a lightning talk I gave on our strategy for student support at [Gymnasium](https://thegymnasium.com), while I served as Technical Director there.


Open EdX, Slack, and Intercom


<Image
  publicId="external-references/30-under-30-2016/cover"
  alt="Photo of me being recognized as one of Charlotte's 30 under 30 in 2016"
/>

Not much on the web about this these days, but if you really want to go spelunking, here's a Wayback Machine link from late 2016 that's captured the gist of it. [Wayback Machine: Top 30 Under 30 Future Leaders of Charlotte, Elevate Lifestyle 2016](http://web.archive.org/web/20161115035530/http://elevatelifestyle.com/30-under-30-2016), and an [old facebook event](https://www.facebook.com/events/1088933411127102/).


Top 30 Under 30 Future Leaders of Charlotte - Elevate Lifestyle 2016


<Image publicId="external-references/your-app-is-ugly/cover" />

A rehash of a talk on the basics of design and aesthetics, covering color theory, swiss design, and some of the historical roots of modern design.

Authored with Andrew Miller, Jeremy Osborn, and Leah Cunningham

Slides [are available on SlideShare](https://www.slideshare.net/mbifulco1/your-app-is-ugly)


Your App is Ugly


<YouTube youTubeId="5DiJ_2Bz2hM" />

(My part starts at 13m47s, but you should watch the whole thing!)

This is a talk I gave during [Open Edx Conf 2016](https://open.edx.org) with my colleagues, comrades, and brothers in arms Andrew Miller and Jeremy Osborn, talking about how we built Gymnasium while actively experimenting with formulas for an effective MOOC.


Gymnasium - Building the plane while flying it


<Vimeo vimeoId="84388498" />

This is a talk I gave at [Blend Conf](http://2013.blendconf.com/speakers/mike-bifulco/) in Charlotte, NC USA in 2013, when I was working for [Microsoft](https://microsoft.com) as a UX Designer. If you're interested in learning how to design apps for a version of Windows that came out in 2012, this is your day!

Slides are [available on Slideshare](https://www.slideshare.net/mbifulco1/designing-windows-81-apps-from-the-ground-up)


Designing Windows 8.1 apps, from the ground up


This morning, I fully switched my personal site from Google Analytics to [Fathom](https://usefathom.com/) - something that I had been considering for a while, and finally decided to go all in on.  Thanks to my colleagues [@andrewpmiller](https://twitter.com/andrewpmiller) and [@jeremias](https://twitter.com/jeremias) for planting this seed months ago - I'm glad I finally made the switch.

## What is Fathom?

In their words, Fathom is "simple analytics for website owners & businesses".  Near as I can tell, that's a perfect distillation of what they've built.  Fathom provides an easily digestible single page analytics view of your site's traffic.

It's a service that rids you of some of the heft of having Google watch you and your users' every move.  They're open and transparent about being [Privacy First](https://usefathom.com/privacy) - something which has long since melted away from Google's ethos.

In addition to giving you information about the traffic coming and going from your web property, fathom also lets you set goals for your site traffic - so that you can keep an eye on performance of what matters to you.  Maybe you want to see how many people are visiting your "about me" page, or track newsletter subscriptions -- with Fathom, it's a straightforward javascript call to make that happen.

## Why Fathom?

For me, the functionality it provides is perfect - [my personal site](https://mikebifulco.com) is slowly growing in traffic, which is great! I had been using Google Analytics to keep an eye on my site's traffic, but honestly - I spent a disproportionate amount of time getting lost in all of the bells and whistles of GA.  That time wasn't giving me more usable insight... I was just getting lost in the tool.

I also love the idea of Privacy First tooling, which Fathom hits out of the park.  When you visit my site, I'm not keeping any of your PII, or doing anything creepy with your browsing behavior.  I just want to know how various articles perform, so that I can make better decisions about what to write in the future.

Another benefit was the install process - getting Fathom set up was a breeze. You may know that my site is built on [Gatsby](https://gatsbyjs.org/) - it turns out there's a reasonably well-featured [plugin for gatsby](https://github.com/lgraubner/gatsby-plugin-fathom) created by a member of the community. In addition to that, they're reportedly shipping their own plugin in the next few weeks. 


<Tweet tweetLink="usefathom/status/1256954976238055424" align="center" />

<Aside>
  Note: it looks like in the coming weeks, Fathom will be providing their own Gatsby plugin!
</Aside>

## Looking for a free option?

**Fathom also has a self-hosted product** called "[fathom lite](https://github.com/usefathom/fathom)" which you can run yourself if you want to use their service for free.  It isn't as full-featured as full blown fathom, but it will give you a good idea of what you're in for.  I set it up on Heroku (using [these instructions](https://gist.github.com/gmolveau/78f88af3f5951ba6e093f93a07caa302)) for a few weeks before deciding to take the plunge and pay for Fathom's SaaS service.

## Try it yourself!

Thinking about giving it a whirl? One of the perks of being a Fathom customer is their affiliate program - you can use my link to [sign up for Fathom](https://usefathom.com/ref/DPSSYB) for a $10 discount on your first invoice.  Sweet!






Why I switched to Fathom for analytics


**Note:** This post came from my work on [Surviving Other People's APIs](https://leanpub.com/surviving-other-peoples-web-apis).  I've been working on a chapter on **Async** - the content below came from that writing, but doesn't quite make sense in the context of the book.  I didn't want to scrap it entirely, so it's found its way into a blog post.  I'd love to know what you think!

## Plan for things to go wrong

Setting up an interface to pull data from an API asynchronously is a clear upgrade over the alternative; we're now able to update the content on a given page without reloading all of the markup and assets (images, css, etc) on the page. For better or worse, your asynchronous upgrades will also introduce some potential for things to go wrong for the people using your app.  Once again, this is an opportunity to anticipate the things which might go wrong, and build fallbacks for when they do.

### Dealing with dropped connectivity

Even if you've used a hyper-modern, robust websocket-enabled API-calling technology, at some point or another, the folks using your app will lose their internet connectivity.  This isn't just the canonical example of someone on a train going through a tunnel, either.  Often times connectivity will go down briefly for mobile users when they switch from a cellular connection to wifi, or when they go between wifi networks, or when they lose wifi and go back to cellular.  

You should test your software to make sure it will continue to work in these cases.  It turns out this can be pretty easy to simulate, too - if you're on a phone, turn airplane mode on, wait a moment, and then switch it off again. On a laptop or desktop developer environment, you can switch wifi off, or disable your LAN connection.  Even better, if you're using Chrome devtools, you can use their responsive tools to shut off connectivity on a single tab:

<Image
  publicId="posts/plan-for-things-to-go-wrong-in-your-web-app/chrome-devtools"
  alt="Screenshot of the throttling interface in Chrome Devtools' responsive mode"
  caption="Chrome DevTools has a simple switch to shut off connectivity"
/>

Once you're able to simulate this kind of trouble, you can build out fallbacks for when things go wrong.  A typical approach to this is to keep track of the result of your API call locally.  If a drop in connectivity is detected, you should let the user know that it looks like they're offline.  From there, you can give them the opportunity to retry the API call, and automatically retry your call when you can tell things are working correctly again.

<Image
  publicId="posts/plan-for-things-to-go-wrong-in-your-web-app/recover-from-offline"
  alt="Mockup of a mobile app showing a modal popup notification for when internet connectivity goes down, which takes over the entire screen."
  caption="Recovering from a dropped connection during an async save operation"
/>

Certain technologies will do the bulk of this work for you.  For example, if a connectivity drop is detected, Firebase will save any API operations to a queue in the client browser's local storage, and will execute offline changes as soon as connectivity comes back. Even still, as when creating interfaces which take advantage of features like this, you should let your users know when they're offline.  It's best to fully communicate what will happen when the connection comes back, too - in clear, human-friendly language.

<Image
  publicId="posts/plan-for-things-to-go-wrong-in-your-web-app/working-offline"
  alt="Mockup of a mobile app which informs the user they're working offline, and that changes will be sync'd when the connection comes back."
  caption="Explain clearly what will happen when the connection comes back"
/>

Note that in this case, we have the opportunity to create an interface which is a whole lot less shouty than in the last example. There's no need for the offline notice to be put in a modal window which takes up the whole screen.  Colors are dialed back a bit, too - yellow is used in the example, which is much less anxiety-inducing than the-sky-is-falling-red.

As a follow-up to this, when the connection comes back, it's good practice to fire off a notification when the offline requests are completed successfully.

### Dealing with changing APIs

At some point, the APIs you're calling will change. In an ideal world, these sorts of changes are well-documented, and deprecation notices are made available months in advance of permanent changes which will break your application. It is part of your team's job to keep an eye on any services you use for breaking changes coming your way.  This can be as simple as assigning a task every sprint to check for API and dependency updates. 

This is a perfectly functional approach to watching out for version changes -- until it isn't.  For larger applications, you may find that as you build more features which depend on a growing number of external services and dependencies, this task becomes an untenable time sink. Luckily, in many cases, there are ways to automate the process.  One such tool is called Dependabot, which is owned by the folks at GitHub.

<Image
  publicId="posts/plan-for-things-to-go-wrong-in-your-web-app/dependabot"
  alt="Screenshot from dependabot's marketing page"
  caption="Dependabot can be found at https://dependabot.com"
/>

Dependabot (and services like it) will keep an eye on dependency lists in your project (like `package.json` in Node projects, and `Gemfile` in Ruby projects).  Once initialized, it will regularly check your dependency lists against the published versions of each library.  When new versions are published, it'll open a simple pull request for each updated library, which you can review, test, and merge when ready.

<Image
  publicId="posts/plan-for-things-to-go-wrong-in-your-web-app/github-dependabot"
  alt="Screenshot from github.com showing a repo with automated Pull Requests, created by dependabot"
  caption="Lots of small pull requests - one for each library which has been updated!"
/>

Generally speaking, this makes the task of keeping dependencies up to date much simpler.  The majority of the work can now be done by your test suites via CI - and changes can be verified by reading changelogs for each updated package.

As this becomes more common, maintainers of various libraries are getting better at posting easy-to-understand changelogs, which reduces the chances that you'll merge a catastrophic change into your project. These kinds of proactive measures should help you sleep more soundly at night. 

Even still, sometimes things go wrong for one reason or another.

Maybe you merged and released a dependency update which has a breaking change to a mission critical API.  Maybe one of your web page uses an API with a version set to `@latest` (!), and you wake up one day to find hundreds of help tickets from people who used to love your application.  If you had been keeping an eye on server logs for your application, you may have noticed that overnight you received a spike in 4xx or 5xx errors from API calls.  Be honest with yourself - how often do you proactively check server logs for errors? Don't fault yourself if the answer is less than often - most of us never check.

Once again, this is a place where automation can save the day. There is no shortage of tooling available to help you detect problems reactively just as they start, and with a nimble enough release strategy, you can minimize application downtime.

### Use error reporting to turn reactive situations into proactive messaging

Imagine this: you're in charge of an application which uses an external service to check the weather for [whatever purpose].  You've got thousands of happy users who regularly use your app to check the weather before going about their day.  One day, without warning, the weather API begins sending back data in a completely different format than you'd expect - a change big enough to render your app useless.

In the old world, you wouldn't find out about this problem until help tickets and angry tweets started rolling in. At that point, it's past too-late - your beloved customers are upset, and you're the fireman who showed up after the roof collapses on your house.

We can do better than that.

There are a plethora of services available which will detect and report application crashes to you the instant they happen, so your support team can spring into action at a moment's notice.  Some of these services include [Raygun](https://raygun.com/platform/crash-reporting), [Sentry](https://sentry.io/), [LogRocket](https://logrocket.com/), [Rollbar](https://rollbar.com/), and [Data Dog](https://www.datadoghq.com/).  With a few lines of code, these will plug into your app, and keep an eye on network requests.  When a page crashes, they'll fire off all manner of notifications - SMS, email, webhooks, Slack messages, you name it.  

If you can't afford to use one of these services, or otherwise prefer not to, you can scrap together a simple one yourself.  This generally looks like a wrapper function which you can use to call APIs.  It should contain the logic to detect failures, and fire off whatever calls are necessary to alert your team to the problem.  For teams with a small budget, the easiest approach may be using Slack's incoming webhooks feature to send a message to a channel dedicated to an application crash:

```javascript
const callApi = async ({url, options}) => {
  try {
    // send off the API call
    const response = fetch(url, options);
    return response;
  } catch (e) {

    //something went wrong, let's notify the team!

    /* helper function to gather as much information as possible about this session, possibly including:
      - user name and contact information
      - URL or page they were visiting
      - which action caused this error
      - browser metadata ("IE7" or "Firefox 58", etc)
      - anything else that might help your support team send a thoughtful, personal response!
    */ 
    const metadata = getUserMetadata();

    // just what it sounds like - send a message to your team's slack channel via incoming webhook
    sendSlackWebhook({
      error: e,
      metadata: metadata
    });

    // send the response back to the interface so you can let the user know something went wrong
    return e;
  }
}
```

These can greatly decrease your effective response time.  If you're able to detect these problems and set your dev team off on a solution before users start complaining, the people using your app will feel loved. Think about how rare it is to use software and feel like the people who are making it care about you directly! If you're a small, scrappy start-up, this can really help you hang on to early customers.  If you're a larger company, it means lower attrition rates, and better support ratings.

Error reporting can also help you detect crashes with user-by-user granularity.  You may see crash reports coming in from a single user over and over.  Reaching out to that individual to see how you can help them before they message you can honestly feel like magic. I've even had users thank me for dropping them a line and telling them I see that they're having trouble, and that I'm on the case.  It's a great feeling - particularly when the alternative is a red-hot support email or a scathing tweet.

### Build a global status indicator... before you need it!

In all of the projects I work on, it's become common practice to include a global status indicator into the fundamental roots of the application.  In its simplest form, this amounts to a content container that lives somewhere near the very top of every page off the application.  The vast majority of the time, it sits invisible and dormant. On page load, and once every few minutes it checks our CMS for content - if something goes wrong, we use that field in our CMS to alert users to the issue, and update it regularly with easily understandable messages about resolution of the issue.

If you don't use a CMS, never fear - you can use something like GitHub Pages to host a json file which you can use for these kinds of warnings.  Have your interface check the public URL of your GitHub Pages site, and if there's anything more than a blank file or object, that content can be parsed and displayed in your status indicator.

### And then?

For now, that's it! Like I mentioned, this was just an excerpt from a chapter that didn't quite fit with what I'm writing.  What do you think? Is there anything you do to harden your site against failures that are out of your control?


#webdev