A few days ago I attend the An Event Apart conference in San Fransisco and it was such a wonderful experience!

It featured 15 amazing speakers covering topics on CSS, user experience, SEO, and so much more.

This post contains some of the takeaways that really stood out to me. Each section has links to the speaker and resources they mentioned.

I'd definitely encourage hearing any of their talks if the opportunity is available!

Talks in this post:

• 📢 Declarative Design
• 📢 Eyes on the Prize: Lessons in User-Centered Design
• 📢 When New CSS Features Collide: Possibility and Complexity at the Intersections
• 📢 Cascading Layers of !mportance
• 📢 SEO teams—The UX Ally You’ve Been Missing All Your Life!
• 📢 Supercharge Your Development with GitHub Codespaces
• 📢 Animation in Today's Responsive Design
• 📢 How to Win at ARIA and Influence Web Accessibility
• 📢 Better Onboarding Through Guided Interaction
• 📢 CSS :has() Unlimited Power

Also, I'm so grateful to Planning Center, for enabling myself and fellow teammates to attend conferences like this one. The way they care for our growth is just one of the many reasons why I love working here!

Shameless plug… We are hiring! For anyone looking to join a great company, check out our career page. :)

📢 Declarative Design

Speaker:
Jeremy Keith
Author & Co-Founder of Clearleft

Main Takeaway

Consider if a system should be given step-by-step instructions or instead guidance on the output, allowing it to decide the steps for us.

Imperative vs Declarative Programming

Imperative programming is where you describe how the program operates, giving it step-by-step instructions.

• Think of a tool like front-end JavaScript, where we can query a specific API for data and then specifically tell the browser how (or even if) to display that data in the DOM.

• Similarly ARIA labels lets us tell screen readers specifically what to say and what elements to look at first.

Declarative programming on the other hand takes in a description of the output and then figures out the rest on its own.

• For example, we tell HTML we want a <button> and then it figures how to communicate a lot of helpful information to screen readers, browsers, search engines, and even gives some base styling.

• Similarly CSS allows us to using rem units to specify how big a font size should be. Then if needed, a user can change that font size to be larger.

• We can take it a step further and specify padding-inline-start: 1rem; instead of padding-left: 1rem;. This does the same thing, but takes away the (imperative) assumption that the browser is showing a left-to-right language.

Different Mindsets

Imperative mindset gives more control with the code, which might be the right call if you are inventing something from scratch. Declarative mindset can feel like giving up control, however it also means your making less assumptions.

One of the ways Jeremy described declarative programming was to “Be the browser’s mentor, not its micro-manager”. It leads to a mindset of asking "should I be making assumptions for the browser and user?"

This mindset shift really stood out to me, because it takes things like ARIA labels that I usually think of as inherently a good thing and makes me consider the output more carefully.

As Jeremy mentioned, "The more ARIA you use, the more control you are trying to assert."

Principle of Least Power

This is where we choose the least powerful language suitable for a given purpose. The lower in the stack we go, the more simplicity in our solutions we might have. This simplicity might lead to less things breaking and a lower bar for learning.

If we don't legitimately need greater control that front-end JS and ARIA offers, then it might be a better choice to use HTML. In other words, don't use a <div role="button"> when <button> already exists.

Another thing to consider when moving lower in the stack, is that HTML is more "false tolerant" when compared to an imperative language like JavaScript. This means that it ignores what it doesn't understand (like a missing image) and keeps rendering the DOM. JavaScript however will throw up an error, that might break the page.

Taking A Layered Approach

Sometimes we can split the difference and use imperative and declarative programs and patterns together.

• For example, use HTML & CSS as the foundation for the project and default for solving front-end problems. Then "sprinkle" JavaScript and ARIA on top, using them for the things that only they can do.
• Using utilities like clamp() in CSS, lets us use imperative values, in a declarative way. Yes, we are setting a min and max value, but also allowing the value to shift between them as needed.

Other Takeaways

• Be aware that the tools that we use are influencing us to go in a certain way. Figma, is probably making us go towards imperative design/programming as we can make pixel perfect mockups. It might be worth designing in Figma, but making final decisions once in the browser.
• Look at approaches vs specific tools/solutions. Approaches lasts longer then the tools that enact them.
• Culture drives if a Declarative approach is the right one. Is the team focused on the outcomes (declarative) or the actual way things are done (imperative)?

Resources

• Be the browser’s mentor, not its micromanager
• Meet Utopia: Designing And Building With Fluid Type And Space Scales
• A Dao of Web Design
• Progressive Enhancement vs Graceful Degradation

📢 Eyes on the Prize: Lessons in User-Centered Design

Speaker:
Anita Cheng
Former Cancer Researcher & Content Designer for San Francisco Digital Services

Main Takeaway

High stress environments highlights the importance of understanding the problem and getting input from people so that we are ready when it times to create a solution.

A Testimony Of Working Under Pressure

Anita was the only content designer embedded in San Francisco’s COVID Command Center. She recounted her incredible experience of translating highly complicated health notices and reports into readable content on the government website.

To say she was under tremendous pressure, would be a gross understatement. Policy and information was continually changing, requiring that she be always proactive, engaged and flexible through an incredibly stressful time. Yet she more then rose to the task, making sure any communication to the population was clear and timely.

Some Of The Lessons She Shared

Surprisingly, despite high stress and long hours she did not burn out. She attributed her energy and ability to focus to getting incredible support from her counterparts and higher-ups. She also truly believed that the work they were doing was for the greater good and important. This belief gave her continual energy and motivation on her hardest days.

Here are just a few of the other traits that helped her to be successful during this time.

• Identifying her strengths and leaning into them. She created a personal mandate of what were the most important things in her role. As much as possible she delegated the rest away, which helped protect her time.
• She used research to understand any risks and considered existing similar guidelines when tackling something she didn't know how to do. That helped minimize guessing.
• She asked for help a lot. She might have been the only content designer, but she didn't go at it alone and collaborated frequently with different experts.
• She reached out to different government departments, asking to be in more meetings. This gave her context (and lead time) of what was coming down the line.

Resources

• hmntycntrd.com

📢 When New CSS Features Collide: Possibility and Complexity at the Intersections

Speaker:
Rachel Andrew
Technical Writer at Google & Member of the CSS Working Group

Main Takeaway

The future of CSS is bright, with many new features just landing or being added very soon that have been years in the making.

So Many New Features!

Rachel's talk was fascinating, covering the thought process and challenges the CSS Working Group consider when updating CSS.

She highlighted the history of developing Flexbox to solve the issues of float layouts. In someways, Flexbox is like the quote that is sometimes attributed to Henry Ford; "If I would have asked people what they wanted, they would have said faster horses."

It solves the specific problems of floated elements being hard to manipulate, since they are taken out of the document flow. However, it may not live up to the true potential of two dimensional layout, which came later on with CSS Grids.

She spoke about the power of CSS Grids and a new feature in the works called Subgrid. This lets child elements inherit their parent grid's size and track number.

She also covered new features like :has() (which I'll talk more about with a different speaker) and an CSS feature she is working on. Her proposal would allow developers to specify a custom focus order when laying out a complex grid of elements. This is a highly requested feature and is currently in review by the CSS Working Group.

Container Queries

The thing that grabbed my attention the most, was a new game changing feature called container queries. This allows the breakpoints to be based on a container size instead of the view-ports size.

This is a game changer because we can now design reusable components that can be used in a variety of layouts. Since it manages its own layout, such a component would be incredibly versatile.

If a "card" component was used in a single column it might show a wider layout and bigger font sizes. But if it had to appear in a row of cards at half the size, then we could stack the card content and reduce the font sizes.

This is already in Safari, Chrome, and just came to Firefox in version 109! 🎉 If the two top cards in the above example don't turn red, then try updating your browser.

Resources

• CSS Container Queries
• Container Units Should Be Pretty Handy
• A Primer On CSS Container Queries

📢 Cascading Layers of !mportance

Speaker:
Miriam Suzanne
Members of the CSS Working Group & SASS Core Team

Main Takeaway

CSS Cascading Layers lets us use more explicit selectors, by reducing specificity.

CSS Cascading Layers

Miriam lead us through a history of CSS and a fascinating demo of the new CSS Cascading Layer feature.

This feature allows for CSS selectors to be contained within @layer decorations. What is cool is that specificity of selectors is contained within that layer. We can then declare layers in the order of their priority.

Selectors outside of a layer by nature have the highest level of specificity, which gives us more flexibility.

@layer low, medium, high; // <–––– order here defines specificity 

@layer medium {
  button [type="submit"] {}
}

@layer high {
  button [type="submit"] {} // This wins
}

@layer low {
  button [type="submit"] {}
}

There are many use cases, but one would be to contain an external library in a layer. Then another layer with a higher priority can contain our overrides.

Resources

• A Complete Guide to CSS Cascade Layers

📢 SEO teams—The UX Ally You’ve Been Missing All Your Life!

Speaker:
Wil Reynolds
Owner of Seer Interactive

Main Takeaway

Google search is really good at knowing the questions customers are asking and the intent behind their requests. Search results could be one of the tools we can use to understand our customers.

Speak The language Of The Customer

Google Search is really good at understand customer intent and intonation. (The feeling behind a question.)

Example 1:
At the start of Covid-19 people searched for the term “FDIC” because they were worried about the safety of their funds. However, banks were advertising about opening new checking accounts, which most people were not interested in.

Had they looked at what people were searching for, they could have instead assured existing and new customers that their money was secure during a tumultuous time.

Example 2:
Google also knows when customers change their language, based on the search terms customers look for. For a while “Ian” was bringing up results about an actor, until “Hurricane Ian” hit.

In about 12 minutes, Google understood that the intent of people’s searched changed and they directed results about the hurricane.

Example 3:
Many colleges were promoting their librarian programs with the technical name of the degree. As it turns out, potential students rarely searched by that degree’s name. Instead they typed in the phrase: “Become a librarian”.

By including that terminology within landing pages and advertisements, schools where able to answer the very question people were asking.

Using Google Search to Understand Intent Tips

1. Type a word or two in Google Search and let it complete the sentence. This will preview what actual questions people are asking. Sometimes we assume what people are looking for incorrectly.

2. Check the "People also ask" and "Related searches" sections of the Google SERP. This shows what people searched after they looked at the current results. These are questions that your product might be able to answer for them.

3. Check what Google Images is serving to people for search terms, then use similar images to communicate products and ideas. For example, "Modern Pool Lighting" will bring back images of beautiful pools lit up at night. However many eCommerce sites will use images of the lights themselves. They are missing the point by showing the literal product, while Google Images show how the product is being used.

4. When testing search results, check the same result on mobile and desktop. Google looks for very different things on each platform and will often display different results for the same term.

📢 Supercharge Your Development with GitHub Codespaces

Speaker:
Morten Rand-Hendriksen
Senior Staff Instructor for LinkedIn Learning

Main Takeaway

GitHub Codespaces removes the barrier to entry for writing code by creating a per-configured development environment on the cloud, allowing you to write code in the browser.

What Is It?

Codespaces is a new service by GitHub that creates a virtual computer that can run your program within GitHub. It will install any libraries and packages, running them in a server. It lets you push, pull, and sync commits directly with your repo.

In the demo, Morten spun up Next site and made an update in a matter of minutes, all from an under powered 2017 Chromebook that didn't have VS Code installed.

Some Benefits Discussed

• Removes the blocker of needing a powerful machine to run process heavy tasks. Since everything is run off-site in the virtual computer.
• Makes coding more accessible, since it takes care of starting up complex environments like Gatsby.
• Makes teaching code easier. Since the teachers and students will be working off virtual computers, the settings can be unified.
• Enhances both security and messing around with code. Since the Codespace is a virtual computer it can be thrown away if a malicious script was added in a PR or testing a feature breaks "all the things".

Resources

• GitHub Codespaces

📢 Animation in Today's Responsive Design

Speaker:
Val Head
Author & Senior Staff Designer at Adobe

Main Takeaway

Recent improvements to CSS has given us greater control over animation properties, while still releasing control as needed to our users.

Individual Transform Properties

Declaring individual transform properties lets us get more flexibility when animating with keyframes.

• We can create “composable” keyframe animation
• It lets us add CSS variables for individual properties
• It currently works for translate, rotate, and scale and always gets applied in that order.

.animate {
  translate: 0 20%;
  rotate: -15deg;
  scale: 2;
}

@keyframes slideAndSpin {
  0% { translate: 20px; rotate: 0deg; },
  30% { rotate: 2deg; },
  100% { translate: var(--move); },
}

.composableAnimate {
  animation: grow 2s, spin 3s;
}

@keyframes grow {
  0% { scale: 0.5; },
  100% { scale: 1.5;  },
}

@keyframes spin {
  0% { rotate: 10deg; },
  100% { rotate: 20deg;  },
}

prefers-reduced-motion

This is used to detect if the user has requested the system minimize the amount of animation or motion it uses. It is set either in the browser or at the OS level.

Identify potentially triggering motion effects. These relate to things that actually move or give the illusion of movement. Not necessarily an opacity change.

People asking for this preference still want the context of the motion, but just reduced.

@media (prefers-reduced-motion) {
  /* styles to apply if the user's settings are set to reduced motion */
}

Resources

• MDN on prefers-reduced-motion

📢 How to Win at ARIA and Influence Web Accessibility

Speaker:
Tolu Adegbite
Product Designer at Meta

Main Takeaway

No ARIA is better then bad ARIA. Whenever possible, use native semantic HTML elements.

Tips & Rules of ARIA

• Do not change the native elements, unless absolutely needed.
• All interactive ARIA controls, must be usable with a keyboard.
• Interactive controls must have proper semantics and cannot be hidden.
• A role is a promise to the user that an element will behave a certain way. (role="button" means that this element is a button)
• aria-label will override the original text. For example: <a aria-label="This text will read">This won't</a>
• Toggle buttons like mute/unmute or pause/pause, need aria-pressed to read out their state at the right time
• Radio buttons need aria-checked
• Interactive elements usually use a tabindex=”0”

Resources

• aria-pressed
• tabindex
• Landmark Role
• aria-labelledby
• aria-describedby
• aria-live

📢 Better Onboarding Through Guided Interaction

Speaker:
Krystal Higgins
Author & UX Designer at Google

Main Takeaway

Onboarding a new customer doesn't happen in one interaction at the beginning, but over a period of time.

The Fear of Good Onboarding

It can be easy to worry that new users will leave the product without understanding "all the things". Because of this fear, products resort to "Front-loaded instructions". Using cards, guides, overlays, tutorials, we try to make the user into an expert before they start using the product.

The problem with "Front-loaded instructions"…

• Too much information upfront is hard to remember
• The information is often presented out of context (ie. "Welcome to store, did you know our checkout has this awesome feature?")
• By just having a tutorial upfront, the product might seem more complicated then it actually is.
• Extensive and in-depth front-load information might be costly to maintain, as features are improved or added.

Treat Onboarding As A Journey Over Time

It is easy to look at "how many people completed the welcome guide" as a metric for if onboarding was successful. However, for the reasons mentioned above this metric might not equal customers feeling comfortable in our products.

Myth: we only have a single moment to help people learn the product.

Instead we should look at where customers/users begin in the product. (This might be different based on their roles or platform used.) Then only consider the onboarding done, when the "core usage of features" ends.

Core usage is…

• Achievable for the user
• Aligned to long term goals

For example, for a community focused product the expectation is for an organization to create groups of people, with the goal of connecting them via in-person or online events.

Core usage might be when a group leader created 2 groups (achievable) and an event in each (aligned to long term goals). Throughout this time they would still be in the "Onboarding stage".

Onboarding Opportunities Along The Journey

Better onboarding is about guided interactions. Krystal outlined three key states/stages that a new user/customer can be guided and informed.

1. Prompt: Lead the person to choose or understand an action at the time they are ready to take it.
2. Work: Helping the person complete the action they just started.
3. Followup: Guide to next step(s) after the action was taken

Where Does Onbording Take Place?

Onboarding should not be one size fits all and happens over time. As such, better onboarding starts as part of the core product's design.

Krystal advises to anchor information in context to the action being taken and not resort to overlays or add-ons if possible.

For example:

• Some text near a "post" button that explains posting guidelines, instead of a big alert.
• When writing the post, show some placeholder text that suggests great titles.
• Instead of a big video upfront that covers all the features, use informative feature blank/empty states that provides or links educates about that specific feature.
• Provide inline hints on how a feature works that reduce in visual impact and frequency over time.

Caution About Using Overlays

• 90% of participates ignore dialog overlay messages that interrupt tasks. They just get rid of them to get them out of the way.
• Overlays are sometimes designed in isolation and can collide if forgotten about. (Login modal & "Welcome First Time User" modal)

Resources

• Better Onboarding Book

📢 CSS :has() Unlimited Power

Speaker:
Eric Meyer
Co-Founder of An Event Apart

Main Takeaway

A powerful way to select parent elements (and more) with CSS.

Other Takeaways

• a:has(.b) This is means a has a relationship with .b.
• Don’t nest a :has() inside a :has(). Example: ❌ :has(:has())
• Don’t nest a pseudo elements inside of :has()
• Don’t nest a :has() inside of pseudo elements
• Don’t add a :has() after a pseudo element
• You can’t match :has(a[href]:visited) for user privacy reasons
• :has() takes in a forgiving relative selector list, which means if it drops any item that isn’t valid. So if we do :has(h1, h-9a) the h1 will be looked at and h-9a will be ignored
• Specificity follows whatever the most specific selector it contains

Resources

• :has() MDN