DEV Community: Amberley Romo

What is Web Accessibility and How Do I Get Started?

Amberley Romo — Wed, 09 Sep 2020 16:58:22 +0000

Happy to say I finally shared this project! (Turns out I actually made the initial commit a year ago today.) I'm grateful for the warm reception it received on Twitter, and it now has over 10,000 page views! (Which is a big number for me). I'm really hopeful that it's a useful resource for folks.

The a11y.coffee project is my take on created a structured introduction to web accessibility. It's intended for web developers who want to learn about accessibility, but perhaps don't know where to start. There's a lot to tackle, and my goal was to create a gentle introduction that tackles the why, the most immediate opportunities for impact, a crash course in testing, and some direction to further resources.

Essentially, I wanted to gift wrap the answer I generally give when someone asks me, "What is web accessibility and how do I get started?"

I hope you'll check it out, and that you find it useful!

How to Conditionally Add to an Object or Array in JavaScript

Amberley Romo — Wed, 09 Sep 2020 16:51:06 +0000

In the course of my work, it's not uncommon that I need to conditionally add properties to objects, or (probably less commonly) values to arrays. Let's talk about how to do both. This is the piece of code I'll ultimately use as an example:

const trueCondition = true;
const falseCondition = false;

const obj = {
  ...(trueCondition && { dogs: "woof" }),
  ...(falseCondition && { cats: "meow" }),
};

// { dogs: 'woof' }

const arr = [
  ...(trueCondition ? ["dog"] : []),
  ...(falseCondition ? ["cat"] : [])
];

// ['dog']

First, defining a few things.

If you're familiar with the && operator, the ternary operator, and spread syntax, skip ahead.

The logical `&&` (AND) operator

&& is a logical operator. Logical operators are used to "reason" about Booleans. The && operator is one of three available in JavaScript (Not material here, but for completeness -- the two others are the || (OR) operator and ?? (nullish coalescing) operator.).

Usage

// expr1 && expr2

console.log(true && "hi");
// hi

console.log("abc" && "123");
// 123

console.log({} && "empty but valid");
// empty but valid

console.log(false && "bye");
// false

If the first expression (on the left side) is truthy ("considered true when encountered in a Boolean context"), return the second expression (on the right side).

If the first expression is falsy ("considered false when encountered in a Boolean context"), return the first expression.

Short-circuit evaluation

The && expression is evaluated left to right. If the first expression is falsy, the full expression is short-circuit evaluated to the falsy expression (meaning the second expression is never evaluated). This is what lets us do things like safely access nested properties on an object:

const obj = {};

console.log(obj.first && obj.first.second);
// undefined

console.log(obj.first.second);
// TypeError: Cannot read property 'second' of undefined

The conditional (ternary) operator

The ternary operator can be thought of as a shortcut for the if statement. It's made of of three parts:

A condition followed by a question mark (?)
An expression to execute if the condition is truthy, followed by a colon (:)
an expression to execute if the condition is falsy

// condition ? exprIfConditionTrue : exprIfConditionFalse

An example. The two functions below accomplish the exact same thing using different syntax. The first uses if logic, and the second uses a ternary

/*
 * Example 1
 */

function getWelcomeMessage(isLoggedIn) {
  if (isLoggedIn) {
    return "Welcome!";
  } else {
    return "Please log in.";
  }
}

console.log(getWelcomeMessage(true));
// Welcome!

console.log(getWelcomeMessage(false));
// Please log in.

/*
 * Example 2
 */

function getWelcomeMessageTernary(isLoggedIn) {
  return isLoggedIn ? "Welcome!" : "Please log in.";
}

console.log(getWelcomeMessageTernary(true));
// Welcome!

console.log(getWelcomeMessageTernary(false));
// Please log in.

The spread operator (`...`)

Spread syntax can be used to expand an iterable (like an array expression), or expand object properties.

Spreading an iterable:

let myDogs = [`Riggins`, `Lyla`];
let parentsDogs = [`Ellie`, `Remi`];

const holidayDoghouse = [...myDogs, ...parentsDogs];
// [ 'Riggins', 'Lyla', 'Ellie', 'Remi' ]

Spreading object properties:

let existingAnimals = {
  dogs: 2,
  cats: 4,
  donkeys: 2,
  horses: 2,
};

let newAnimals = {
  goats: 2,
};

const allAnimals = {
  ...existingAnimals,
  ...newAnimals,
};
// { dogs: 2, cats: 4, donkeys: 2, horses: 2, goats: 2 }

It can be used on iterables like an array or a string.
It expands an iterable to its individual elements

Conditionally add a property to an object

To conditionally add a property to an object, we can make use of the && operator.

const trueCondition = true;
const falseCondition = false;

const obj = {
  ...(trueCondition && { dogs: "woof" }),
  ...(falseCondition && { cats: "meow" }),
};

// { dogs: 'woof' }

In the example above, in the first property definition on obj, the first expression (trueCondition) is true/truthy, so the second expression is returned, and then spread into the object.

In the second property definition, the first expression (falseCondition) is false/falsy, and so the first expression is returned (and the second expression is never evaluated, because of short-circuiting). It may seem a little confusing to spread a falsy expression, but the result is that it is ignored:

const spreadFalsy = {
  ...false,
  ...null,
  ...undefined,
};

console.log(spreadFalsy);
// {}

You don't need parentheses in evaluating these expressions, but I prefer them, to make it clear that the spread operation applies to the result of the full expression.

const trueCondition = true;
const falseCondition = false;

const withParentheses = {
  ...(trueCondition && { dogs: "woof" }),
  ...(falseCondition && { cats: "meow" }),
};

// { dogs: 'woof' }

const withoutParentheses = {
  ...trueCondition && { birds: "tweet" },
  ...falseCondition && { foxes: "???" },
};

// { birds: 'tweet' }

Conditionally add a value to an array

Conditionally adding a value to an array looks a little different. Rather than using an && operator, we use a ternary operator.

Unlike the object spread example, if you attempt to spread on a falsy value in an array, you'll get a TypeError:

const falseCondition = false;

const arr = [...(falseCondition && ["cat"])];
// TypeError: boolean false is not iterable

Hence we need a ternary; Using a ternary, we can fall back to spreading an empty array. Then (assuming we've correctly provided two possible iterables) both possible returned expressions will be iterables:

const trueCondition = true;
const falseCondition = false;

const arr = [
  ...(trueCondition ? ["dog"] : []),
  ...(falseCondition ? ["cat"] : [])
];

// ['dog']

3 concrete ways to handle impostor syndrome every day

Amberley Romo — Thu, 13 Jun 2019 16:03:01 +0000

Yesterday I had the pleasure of chatting with Dustin Myers for a video he's doing on impostor syndrome. He asked me to share some ways I handle impostor syndrome, and I thought they'd be useful to write out, as well.

1. Surround yourself with awesome people

There's a saying that goes something like "Show me who your friends are and I'll show you who you are." The spirit of this is the number one way I manage impostor syndrome on the daily.

My favorite tweet about impostor syndrome is literally framed in my office. It reads:

Imposter syndrome: I am surrounded by beings of impossible, cosmic intelligence

Also imposter syndrome: I, an incompetent, have tricked them all

Between the community I've found on Twitter, my co-workers, and personal friends in tech, I have found some awesome company to keep. Some really brilliant, compassionate, accomplished people that I respect.

Whenever I get that impostor syndrome itch (which is less frequent now!), I think about the incredible people surrounding me, and the reciprocal respect they have for me, and that lifts me up so much.

If you're just starting -- build this community! The positive effect is exponential. You've got at least one to start with in me.

2. Don't make perfection the goal, make your mindset the goal

If you make perfection your bar for success, you will never succeed. Guaranteed.

Instead, think about the mindset you want to carry. Make your bar for success how you approach different situations. This will look different for everyone. For me, it looks like this:

Situation: There was something I didn't know. (Ha, daily).

Automatic thought (catastrophizing): "I feel embarrassed. I didn't know this one thing, therefore I don't know anything and I'm incompetent, therefore when everyone figures that out I'm going to lose my job and everyone's going to ridicule me and I'll never find another tech job and I'll have to find a new career."

Alternative thought (curiosity): "Huh! Well that's yet another interesting thing I know now. Add that to ye olde arsenal."

I try to make my bar for success the way I react to things -- For me that's working consciously to approach everyday situations with curiosity and compassion, first.

One amazing example of this type of mindset shift in practice is swyx's "Learn in Public".

3. Remain humble, not toxically self-deprecating.

I'm guilty of this by nature and work hard to recognize and retrain this thought pattern. It has wide-ranging consequences both for you, and for the people who surround you.

I naturally want to frame a question as: "I'm so dumb, this is such a stupid question, but..." For me, this inclination stems from a desire to self-protect -- if I pre-emptively say it, I've beaten everyone to the punch, no one can hurt me! This is not only needlessly self-harming and unproductive, it's also a models a destructive mindset for other people.

In contrast, by remaining humble and curious, you are open to new voices and information, and can soak it all up without expending the emotional bandwidth self-deprecation consumes. Save up that bandwidth! There's so many better things to do with it.

Reflecting on code bootcamp, three years later

Amberley Romo — Wed, 22 May 2019 15:37:05 +0000

There have been only two times in my life that I’ve kept a consistent blog. The first was my study abroad experience in China. The second was my time at Makersquare. (Makersquare was acquired by Hack Reactor, which is now a project of Galvanize. Lol, startups.)

At some point I decided to make all my bootcamp posts privately published (on my old WordPress blog). Yesterday, I decided to port them over and re-publish them. It’s now been three years, but if anyone is currently going through a bootcamp, or considering it, I hope that perhaps they find it helpful.

Weekly bootcamp posts

The Road So Far (2016-01-10)
Week 1: Lots (2016-01-10)
Week 2: Blur (2016-01-17)
Week 3: Enter APIs (2016-01-24)
Week 4: Mental Fog (2016-02-01)
Week 5: Onto Projects (2016-02-07)
Week 6: Halfway Through (2016-02-14)
Week 7: Projectland (2016-02-29)
Week 8: Back to Back-End (2016-03-07)
Week 9: Thesis, cont'd (2016-03-16)
Week 10: Is This Real Life? (2016-03-21)
Week 11: Thesis, Concluded (2016-03-28)
Week 12: The Transition (2016-04-02)

Was it worth it?

Short answer, yes.

I had been trying to break into full-time web development for years, and at the time, I still didn’t feel I’d done it.

I needed a complete change of pace, and a completely focused time period to focus on the pivot. I’m grateful that I had the opportunity to do so. I f’n love what Lambda School is doing to make this pivot more accessible to a wider range of people. (Enjoyed this Founder’s talk podcast episode feat. founder Austin Allred recently). Note: I have no experience with Lambda. My intention is to highlight the issue of access. See also: freeCodeCamp.

I took a chance on a bootcamp because:

I had been scratching at the door and doing the work for a long time, I already knew it was something I enjoyed.
Despite the fact that bootcamps were pretty much a new thing, and unregulated, I felt it conferred some greater level of validation, and gave me a better shot. (They’re not so new anymore, I feel like I was at the tail-end of that).
I needed to invest in a hard pivot. Working my way gradually wasn’t working.

I’m so grateful to be where I am now, and it’s absolutely mind-blowing that the bootcamp was three years ago. Also, none of this would be possible without these folks.

How to tweet with accessibility in mind

Amberley Romo — Tue, 21 May 2019 18:39:31 +0000

Curating some go-to tips for myself for tweeting with accessibility in mind. I hope others find this helpful.

Not already familiar with "alternative text" or "screen readers"? Check out the "Terms" explainer section at the end of this post.

Quick links / overview of the sections:

(Prerequisite) Enable alt text.
Provide meaningful alt text for images.
Provide direct "alt text" for animated gifs.
Use camel case or pascal case for multi-word hashtags.
Consider your use of punctuation and symbols.

(Prerequisite) Enable alt text.

Twitter supports providing alt text for images. At this point, you must still explicitly opt-in to expose this as a "feature". To opt-in, visit the accessibility tab in your Twitter settings, and enable "Compose image descriptions".

I still hope someday Twitter enables this option by default (or even requires it), rather than making it opt-in.

Provide meaningful alt text for images

When writing alt text, imagine that you're describing the image to a friend sitting across a table from you. Think of how you would describe it so that the full meaning of the tweet is communicated, without ever seeing the image.

Context is everything. The same image might have different appropriate alt text depending on the context. (Again, think about describing to a friend.)
Don't be unnecessarily verbose. Be as succinct as possible while getting the full point across.
Avoid "image of..." or "graphic of...". This context is provided implicitly by the <img/> tag. Including it in the alt text would be redundant.
Place a period (.) at the end of the alt text. This will make the screen reader "take a breath."

Alt text examples:

This great Twitter thread from @RobotHugsComic provides some great examples of effective alt text for images associated with tweets.
WebAIM also has great guides on the importance of context in alt text, and examples of alt text blunders.

Provide "alt text" directly in tweets containing animated gifs

I have "alt text" in quotes because currently you cannot provide alt text (as in a literal alt attribute) for animated gifs on Twitter. A lot of folks currently provide alternative text directly in the content of the tweet that contains the gif:

Use camel case or pascal case for multi-word hashtags.

In camel case, words are joined together with no spaces. The first letter is lower-cased, and each additional word begins with a capital letter. (Ex., iPhone, eBay). Pascal case is a subset of camel case, where the first word is also capitalized.

Camel or pascal cased hash tags are more readable to screen readers, and also more legible for sighted users.

#ThisIsPascalCase
#thisIsCamelCase
#thisislowercase

Consider your use of punctuation and symbols.

Awhile ago, the "sign bunny" meme was a thing. A tweet would include an ASCII bunny, holding a sign, conventionally with capitalized text. Reading this type of text content on a screen reader is... obnoxious.

(This tweet is an example, and not intended to call out the tweeter. I chose this one simply because it's one of my personal favorites.)

Below is a screen recording video demoing how this tweet is read aloud using the built-in screen reader for Mac, "VoiceOver":

In situtations like this, consider what the text of the tweet read aloud would actually sound like to someone. A better idea in this case might be to include the meme as an image, with appropriate alt text.

This includes emojis. Quoting Adrian Roselli:

In general, avoid too many emoji. Understand that different screen settings and sizes may make them hard to see, and that different cultural backgrounds (and context) can change their meaning. But beyond all that, they are just verbose in screen readers.

Consider this not only in tweet text, but also in your Twitter display name:

Make it a habit!

It took me a bit to get in the habit of considering all of these things, and I'm far from perfect. One thing I was going to link here was the Please Caption! Twitter bot account, that would politely remind me if I forgot to include alt text. Sadly, Twitter has changed the way bots work (apparently) and it's (hopefully temporarily??) dead.

Terms

Info on specific important terms in this post, if you're not familiar.

Alternative text

Alternative (alt) text provides a text alternative to non-text content. The text is read by screen readers in place of images. It communicates the content and function of the image to users who rely on means of navigating the web that aren't visual (blind users, low-vision users, users with cognitive disabilities, deafblind users, etc).

Alt text is:

Read aloud by screen readers,
Displayed in place of the image in browsers if the file is not loaded,
Crawlable by search engines and therefore indexable by search engines.

Learn more about alt text.

Screen reader

A screen reader is a software program that converts digital text into synthesized speech.

Learn more about screen readers.

Assorted relevant links

The cultural push to hire junior software developers

Amberley Romo — Sun, 17 Mar 2019 16:06:53 +0000

A friend chatted me recently, with an interesting question.

What is behind the rise of the “hire junior engineers” push that is going on industry wide?

We had a long conversation that I decided to translate into written thoughts.

Industry context

High demand for senior talent, low supply

There is a huge gap between the existing supply and the growing demand for software developers. There are more job openings for software developer roles than qualified people to fill them. The U.S. Bureau of Labor Statistics projects that by the year 2020, there will be one million unfilled software jobs.

The demand for software developers is growing faster than the average for all occupations. This is partially because in an increasingly digital world, demand is rising in finance, retail, manufacturing, and other traditional
industries, beyond traditional "tech" companies.

These stats back up what I would venture to say most working software developers personally observe and hear anecdotally, constantly. Especially via LinkedIn.

Saturation of junior talent

We have a dearth of qualified talent to meet existing demand.

Back in 2014-2015, the number of computer and information science bachelor degrees earned was 59,581. That doesn't even come close to starting to close the supply gap.

We have a situation now where everyone wants to hire senior, and there's already not enough senior or mid-level talent to meet demand. And at the same time supply is not on a growth trajectory to meet that demand, much less growing in proportion to the growing demand.

The explosion of code bootcamps is itself a sort of proof that there's a market to fill that gap. In contrast, because of bootcamps and things seeking to fill the demand, we have a saturation of eager, junior talent. At the same time, finding a quality, junior, entry-level job is a challenge. They're hard to come by, and the ones that are there seem to seek experience far above "entry".

My career context

A slight diversion into my career path, for context on my perspective.

Getting my foot in the door involved knocking on a lot of doors, and trying to figure out what I needed to do to finally have my Developer Card™️.

I don't even remember really when I started tinkering with static sites. When a web position opened up in the nonprofit I worked at (doing marketing, branding and graphic design at the time), I jumped at it. I got it -- at least in part, I believe -- because the person leaving (causing the open position) advocated for me, knowing what I could do. (This is not about me not deserving it -- I was qualified -- more about the fact that no one else at the non-profit really understood the job.)

That was great, but ultimately I was frustrated by not having anyone to learn from. It was whatever I could figure out on my own. I started applying for front-end developer positions.

At an agency I had a great feeling about, I interviewed for a front-end development role. Ultimately, because of my "well-rounded background", I was offered a position as a "technical strategist" instead, which was part business development, part client management, part project management. I figured that meant I wasn't ready to be a professional web developer (Despite the fact that that was currently my full-time job. Cognitive dissonance is amazing), and that this would be a good stepping stone. At the time I started, the agency had zero female developers.

The position did not fulfill what I wanted -- shocking, I know. While I was there, they did hire a female dev, and she was an amazing and supportive mentor and friend to me. She had been a social worker, and career changed by doing a bootcamp. She gave me the confidence to make a hard shift, and take the leap. I left DC, moved back to Texas, and went to a code bootcamp in Austin. (Makersquare, before it was aquired by Hack Reactor, before it was acquired by Galvanize 🙃).

Through this entire narrative, I suffered from ignorance of what I didn't know. I didn't know how to get where I wanted to go, or even what that position looked like. I could never have envisioned where I am now.

How about when I got my Developer Card™️? This imposter may never know, but still wonders:

// Detect dark theme var iframe = document.getElementById('tweet-1094655492545228800-858'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1094655492545228800&theme=dark" }

Why the push to hire junior?

With that context in mind, here are some of the main reasons I think there's been a strong, vocal push to hire junior devs.

Because we need new talent for our industry to thrive

Senior engineers do not spontaneously manifest from the ether like full-grown Athenas.

// Detect dark theme var iframe = document.getElementById('tweet-1040061861817868288-841'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1040061861817868288&theme=dark" }

We need to be nurturing junior talent, to fill existing and future demand. Every industry requires this for longevity. Given the demand for senior talent, and the short supply, where do we expect the gap to be filled?

In talking about hiring juniors, I have heard things like "If I hire a junior, they'll just move on later after they get some experience, and then what's the point?" In my opinion this an unproductive way to frame this question. Instead, perhaps, "How can we create a working environment that is so fulfilling and vibrant that a junior wants to continue to grow and become a leader from within?" Institutional knowledge is invaluable, and it makes sense to foster a culture that sustains that, rather than ensuring the realization of a self-fulfilling prophecy. If you foster a culture where your junior talent wants to stay and grow into senior roles, you're probably going to retain existing senior talent better, too.

This is also related to a larger industry issue:

// Detect dark theme var iframe = document.getElementById('tweet-1105812366841634816-903'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1105812366841634816&theme=dark" }

In a way, it feels we've made it inevitable for folks on every level to need to move on to move up. Once in the door, it can keep you stagnant. Anecdotally (see tweet and replies), it can be hard to feel a sense of career progress, if you have to leave for a title or pay bump. If you're not already in the door, it's just gatekeeping.

Because -- surprise -- we still suck at diversity...

Before working with Gatsby, I had worked with two other female engineers. Now, that total is four. (When I was hired on at Gatsby, I was the first. We now have three, including myself).

At the same time, the current talent pool in the industry is overwhelmingly white (74.2%) and male (92.9%). That was from the most recent general Stack Overflow survey. The "State of JavaScript" looks pretty similar:

// Detect dark theme var iframe = document.getElementById('tweet-1064710839066861568-272'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1064710839066861568&theme=dark" }

It's self-perpetuating. In order to diversify and enrich the talent pool, we have to make a concerted effort to not only nurture new talent, but to be willing and proactive about opening the door.

And -- surprise -- diversity has value

Higher bottom line

A report from Intel found that:

Improving ethnic and gender diversity in the U.S. technology workforce represents a massive economic opportunity, one that could create $470 - $570Bn in new value for the tech industry, and could add 1.2-1.6% to national GDP.

Better products

A viral video went around a couple years ago. A Nigerian man tweeted a short video of an automatic soap dispenser that responded to a white person's hand, but not a black person's.

// Detect dark theme var iframe = document.getElementById('tweet-897756900753891328-714'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=897756900753891328&theme=dark" }

Apparently a darker skin tone wasn't enough to register with the sensor on the dispenser. A problem that should have been avoided by testing on a spectrum of skin tones. A diversity of perspectives and backgrounds in teams mean better product design, testing and execution.

Modelling lays the groundwork for others to follow

The same reason that diverse representation in media is important. If every doctor you see on TV is male, it would be reasonable to conclude that "doctor" is a male-gendered profession. On the other hand, if you see a diverse set of people portraying doctors, including people you identify with, it's easier to envision yourself in that role.

// Detect dark theme var iframe = document.getElementById('tweet-1106594697126903808-884'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1106594697126903808&theme=dark" }

It never occurred to me to study computer science, or that working with the web was anything but a hobby. It took time, and meeting a single female software developer.
I may have never had the courage to quit my job and pivot if not for meeting her.

I saw a great Twitter exchange recently that touched close to this for me:

// Detect dark theme var iframe = document.getElementById('tweet-1103666283973758976-248'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1103666283973758976&theme=dark" }

So combine that with the squishiness around "what is a junior, mid-level, or senior developer". There are no universal qualifications, no agreed upon competency rubric.

Then combine that with this statistic: "Men apply for a job when they meet only 60% of the qualifications, but women apply only if they meet 100% of them."

You could say that it's on women to apply anyway, but I would argue that that ignores a lot of existing discriminatory socialization. For example, a study by researchers from Harvard, MIT and the Wharton School found that investors preferred pitches presented by male entrepreneurs over female entrepreneurs -- even when the content of the pitch was the same.

So often, men will apply up, and women won't. Or even if both apply, and are equally qualified, the male applicant may be perceieved to be more qualified or promising.

I think this results in an uneven acceleration of "seniority", but also entry into the industry, period.

It makes business sense

But "doing the right thing" doesn't always line up with what's "best for business", does it?

This is the part of the conversation that always reminds me about the hurdles in making the case for web accessibility. There's a whole area of the Web Accessibility Initative site dedicated to the business case for web accessibility, to help educate people to make the economic case for web accessibility.

Aside from that Intel study that indicates lost potential economic opportunity, hiring juniors has other benefits:

More understandable code gets shipped

// Detect dark theme var iframe = document.getElementById('tweet-1104469820081205248-168'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1104469820081205248&theme=dark" }

Just like writing a talk forces you to understand your subject matter on deeper level, explaining and talking through things with someone else, and particularly someone more junior than yourself, forces you to understand it better, and uncover holes in your implementation and thought process. Simpler code is more maintainable and less buggy. At the absolute least, it's a valuable live "rubber duck" situation.

Smarter distribution of tasks

// Detect dark theme var iframe = document.getElementById('tweet-1106281425563615233-908'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1106281425563615233&theme=dark" }

Certain things need to be architected and led by extremely senior, experienced engineers. But a lot of day-to-day work does not require that level of expertise. Distributing tasks keeps people engaged -- it keeps senior people from getting bored, and it keeps less experienced folks growing and levelling up in the trade. It's a smart allocation of resources.

Empathy

In talking about this with others, I find that empathy almost always enters the conversation.

// Detect dark theme var iframe = document.getElementById('tweet-1106210101575208960-949'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1106210101575208960&theme=dark" }

We remember what it was like, trying to break in, finding a path, knocking on a million doors. The very first JavaScript meetup I went to was me and forty dudes. I don't want that to be the reality anymore. It is a net gain for everyone to make our existing networks less homogeneous, and if we're not asking ourselves and each other how we can do that, I think that's a shame, and a failure.

tl;dr

I think the push to hire and grow junior talent cannot be disentangled from the push to diversify the tech space, which has social, cultural, and economic benefits. The health of our industry and the quality of what we create depends on increasing diversity in the field, and creating a larger talent pool.

Seriously, though. What is a progressive web app?

Amberley Romo — Mon, 06 Aug 2018 07:59:02 +0000

“unofficial” community logo for PWA

I’ve been familiar with the “progressive web app” (PWA) concept for a while now. But there’s always been an itch in the back of my mind about it.

I’ve been to talks at conferences and meetups about the subject. I’ve read the main docs and top-level “what is a PWA” articles. I’ve read Alex Russell’s post, “Progressive Web Apps: Escaping Tabs Without Losing Our Soul” [Posted 06/15/2015], about the discussion between himself and Frances Berriman that originated the term, and Frances’ post, “Naming Progressive Web Apps” [Posted 06/26/2017], about the semantic foofaraw around the term “progressive web app” itself.

And still, I have found it difficult to conclusively, accurately, and concisely define it (based on concrete citation, that is). I see similar confusion across the internet.

One such example — Ben Halpern of dev.to, in a post called “What the heck is a “Progressive Web App”? Seriously.” [Posted 11/06/2017, updated 04/21/2018]:

This morning I went to write an article outlining a few tips about implementing a progressive web app (PWA). But when I went to introduce the topic, I again encountered what was the hardest part about the whole topic in the first place: I have a really hard time describing what a progressive web app actually is .

He captured a lot of my “is this just me?” feels too:

Perhaps PWA is meant to be inclusive of a lot of technical approaches, so they need to be vague. This might be okay if it were just the source docs that were this way, but I feel like alternative introductions and how-tos scattered across the web have latched on to this vague language and the confusion has proliferated.

It’s socially hard to say “hold on, I don’t understand any of that”, because you don’t know if everybody else just gets it and you’re the stupid one. In the PWA space, I really do feel like there’s a lot of people nodding along assuming everyone else understands what a PWA is and they must be missing something. You know, imposter syndrome. [emphasis added]

Another such example is the uncertainty acknowledged in this blog post from Microsoft [Posted 02/06/2018] — a top-page hit when Googling “what is a progressive web”:

The excitement about PWAs in the developer community is almost palpable — but amongst all that excitement, it can be hard to pin down a single, concise, authoritative definition of a “Progressive Web App.” [emphasis added]

What had me particularly confused, personally, is that parts of the internet have seemingly coalesced around three baseline requirements for what comprises a progressive web app — and none of them cite where it came from. It’s impressive to me to achieve that level of unofficial, broad accord, given zero citation — it just echoes across the internet. (And the worst part? I’m guilty; I did the same thing in “A Browser-Based, Open Source Tool for Alternative Communication” [Posted 03/14/2018]. And I remember feeling conflicted about it at the time).

Because this time I couldn’t bring myself to divert from this mental rabbit hole, I started looking into:

The origin of the listing of attributes that constitute a PWA that are generally referenced in docs and posts,
The origin of the three baseline requirements for a PWA that are generally referenced in docs and posts, and,
The variation in definitions among the top-level search results for “progressive web app”

At the end, I’ll post my conclusion of a definition for PWA (for whatever that’s worth).

The general attributes that constitute a PWA

This part is conclusive. In 2015, Alex Russell introduced the term “progressive web app” online. He recounted a conversation between himself and Frances Berriman, in which they “enumerated the attributes of [a] new class of applications” based on the gradual and powerful evolution of modern browsers. Those attributes are, verbatim:

Responsive: to fit any form factor
Connectivity independent: Progressively-enhanced with Service Workers to let them work offline
App-like-interactions: Adopt a Shell + Content application model to create appy navigations & interactions
Fresh: Transparently always up-to-date thanks to the Service Worker update process
Safe: Served via TLS (a Service Worker requirement) to prevent snooping
Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them
Re-engageable: Can access the re-engagement UIs of the OS; e.g. Push Notifications
Installable: to the home screen through browser-provided prompts, allowing users to “keep” apps they find most useful without the hassle of an app store
Linkable: meaning they’re zero-friction, zero-install, and easy to share. The social power of URLs matters.

The three baseline criteria for a PWA

The three baseline criteria a site must fulfill in order to qualify as a PWA echo across the web. They are:

You need to be running under HTTPS.

You need a Web App Manifest.

You need a Service Worker.

This in particular is copied verbatim from Aaron Gustafson’s “Yes, That Web Project Should Be a PWA” [Posted 08/30/2017]. I asked Aaron where, specifically, that apparently canonical list of three originates (beyond the vague, general internet pseudo-consensus).

He pointed me to Jeremy Keith, where I re-read, among others, his post, “HTTPS + service worker + web app manifest = progressive web app”. In it, he cites an older post of his own, “Progressing the web”, where he said:

Literally any website can be a progressive web app:

switch over to HTTPS,

add a JSON manifest file with your metacrap, and

add a service worker.

Later on, in response to a tweet from Jason Grigsby asking the same question I’m asking now — “I agree with you on the three things that comprise a PWA, but as far as I can tell, you’re the first to declare it as such. Am I wrong about that?” He responded:

I was quite surprised by that. I always assumed that I was repeating the three ingredients of a progressive web app, not defining them. But looking through all the docs out there, Jason might be right. It’s surprising because I assumed it was obvious why those three things comprise a progressive web app — it’s because they’re testable.

So, nothing conclusive on the origin. (So far.)

Variation in definitions among the top-level search results for “progressive web app”

While on this bender, I thought I’d review the variations in definitions of the top five Google search results for “progressive web app”. And thank god I did because I found a gem (queue suspense).

1. Google Developers: Progressive Web Apps

Progressive Web Apps are user experiences that have the reach of the web, and are:

Reliable — Load instantly and never show the downasaur, even in uncertain network conditions.

Fast — Respond quickly to user interactions with silky smooth animations and no janky scrolling.

Engaging — Feel like a natural app on the device, with an immersive user experience.

2. Google Developers: Your First Progressive Web App

Progressive Web Apps are experiences that combine the best of the web and the best of apps. They are useful to users from the very first visit in a browser tab, no install required. As the user progressively builds a relationship with the app over time, it becomes more and more powerful. It loads quickly, even on flaky networks, sends relevant push notifications, has an icon on the home screen, and loads as a top-level, full screen experience.

This resource also lists the canonical list of attributes, but adds a tenth:

Progressive — Works for every user, regardless of browser choice because it’s built with progressive enhancement as a core tenet.

3. Wikipedia: Progressive Web Apps

Progressive Web Apps (PWAs) are web applications that are regular web pages or websites, but can appear to the user like traditional applications or native mobile applications. The application type attempts to combine features offered by most modern browsers with the benefits of a mobile experience.

The Wikipedia entry lists web manifest and service workers as “commonly used technologies” to support the defined characteristics of a PWA (which it does cite to Berriman and Russell).

Then, lo, buried in a footnote, the Wikipedia entry attributes the technical baseline criteria for a PWA to none other than (🥁) Alex Russell, from his post: “What, Exactly, Makes Something A Progressive Web App?” [Posted 09/12/2016]. (This is the gem, by the way 💎).

This is surprising to me for a couple reasons. One, how had I not seen this cited anywhere before? And two, how ironic that he works at Google, and as far as I can tell, the Google resources are one of the ones that don’t specifically cite these baseline requirements.

4. MDN: Progressive Web Apps

Progressive web apps use modern web APIs along with traditional progressive enhancement strategy to create cross-platform web applications. These apps work everywhere and provide several features that give them the same user experience advantages as native apps.

PWAs should be discoverable, installable, linkable, network independent, progressive, re-engageable, responsive, and safe.

Like the Google Developers: Your First Progressive Web App page, this list adds “progressive”, and contains all of the other attributes from the Russell/Berriman list, except for “Fresh” and “App-like”, for some reason?

5. Smashing Magazine: A Beginner’s Guide To Progressive Web Apps

A progressive web application takes advantage of the latest technologies to combine the best of web and mobile apps . Think of it as a website built using web technologies but that acts and feels like an app. Recent advancements in the browser and in the availability of service workers and in the Cache and Push APIs have enabled web developers to allow users to install web apps to their home screen, receive push notifications and even work offline.

It also recites the same characteristics, linking back to the Google Developers resource. It also cites PWAs as being “originally proposed by Google”.

The end of this unnecessary journey

Now, finally, what I will take forward as my personal definition of a PWA:

“Progressive web app” (PWA) is both a general term for a new philosophy toward building websites and a specific term with an established set of three explicit, testable, baseline requirements.

As a general term, the PWA approach is characterized by striving to satisfy the following set of attributes:

Responsive
Connectivity independent
App-like-interactions
Fresh
Safe
Discoverable
Re-engageable
Installable
Linkable

As a specific term, websites can be tested against the following three baseline criteria to qualify as a PWA:

It must run under HTTPS.
It must include a Web App Manifest.
It must implement a service worker.

The general set of attributes was first explicitly enumerated by Alex Russell and Frances Berriman, and the set of three requirements can also be attributed to Alex Russell.

PWAs are apps delivered through the web (as opposed to native apps, packaged and deployed through stores). As Alex Russell said:

…they’re just websites that took all the right vitamins.

Timeline of referenced posts:

“Progressive Web Apps: Escaping Tabs Without Losing Our Soul” [Posted 06/15/2015]
“What, Exactly, Makes Something A Progressive Web App?” [Posted 09/12/2016]
“Naming Progressive Web Apps” [Posted 06/26/2017]
“Progressing the web” [Posted 06/27/2017]
“Yes, That Web Project Should Be a PWA” [Posted 08/30/2017]
“What the heck is a “Progressive Web App”? Seriously.” [Posted 11/06/2017, updated 04/21/2018]
“Welcoming Progressive Web Apps to Microsoft Edge and Windows 10” [Posted 02/06/2018]
“HTTPS + service worker + web app manifest = progressive web app” [Posted 05/16/2018]

Sidenote: I mostly drafted this post on a plane, with no wifi. I realized I had forgotten to re-open one of Jeremy Keith’s posts I meant to reference. I clicked it, and there it was, cached and ready for my offline perusal 🙃