Adds screenshots to Honeycomb case study; updates that study's docs after review and revisions

assets/css/site.css

@@ -254,6 +254,10 @@ body {
             color: var(--light);
         }
 
+        code {
+            background: var(--hover);
+        }
+
         #end
         {
             .text p:first-child {
@@ -289,6 +293,10 @@ body {
                 order: 1;
                 padding-top: 2rem;
             }
+
+            a.return {
+                margin-left: 0.25rem;
+            }
         }
 
         menu {
@@ -443,6 +451,15 @@ main {
             font-size: 1.1rem;
         }
 
+        a.fn {
+            text-decoration: none;
+
+            &.sect {
+                font-size: 0.7rem;
+                vertical-align: super;
+            }
+        }
+
         section {
             width: 100%;
 
@@ -492,6 +509,17 @@ main {
                     margin: 0;
                 }
             }
+
+            &.rounded {
+                img {
+                    border-radius: 1rem;
+                }
+            }
+            &.rounded-tl {
+                img {
+                    border-radius: 1rem 0 0;
+                }
+            }
         }
     }
 }
@@ -662,7 +690,7 @@ nav {
     }
 }
 
-details {
+details:not(.hc-dropdown) {
     border-top: 1px solid var(--light);
 
     &:first-of-type {
@@ -1238,7 +1266,7 @@ body#values {
                         padding-bottom: 0.75rem;
                     }
 
-                    &:not(:has(em)) {
+                    &:not(:has(> em:first-child)) {
                         margin-top: -0.75rem;
                     }
                 }
@@ -1345,6 +1373,14 @@ body#values {
                 }
             }
         }
+
+        > article {
+            figure {
+                &.tablet-2\/3 img {
+                    max-width: 67%;
+                }
+            }
+        }
     }
 
     /* case studies list has more room */
@@ -1490,7 +1526,7 @@ body#values {
     /* article adjustments */
     main > article {
         p {
-            font-size: 1.1rem;
+            font-size: 1rem;
         }
     }
 
@@ -1504,7 +1540,7 @@ body#values {
             border-top: 3px solid var(--muted);
             flex-direction: column;
             margin-top: 0.75rem;
-            overflow-x: none;
+            overflow-x: hidden;
         }
 
         ul {
@@ -1529,6 +1565,7 @@ body#values {
 
         li {
             height: 2.5rem;
+            overflow: hidden;
             padding: 0.4rem 0 0;
             text-indent: 0.25rem;
 

content/studies/honeycomb/index.md

@@ -43,7 +43,7 @@ study:
     - id: "overview"
       label: "Project overview"
     - id: "constraints"
-      label: "Adoption constraints"
+      label: "Problems"
     - id: highlights
       label: "Highlights"
       num: "04."
@@ -61,10 +61,15 @@ study:
     - id: "reflection"
       label: "Reflection"
   footnotes:
-    - symbol: "†"
-      note: "The naming here is intentionally a little in flux. Honeycomb is the public design-system name; Schooltastic is the anonymized company/product framing used elsewhere in this portfolio. I may replace this with SchoolStatus where it makes sense, since that connection is easy to infer."
-    - symbol: "‡"
+    - id: "fn1"
+      symbol: "†"
       note: "The DOJ's Title II web and mobile accessibility rule set WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps. The original 2026 and 2027 compliance dates were later extended in 2026, but the rule's substance and procurement pressure remained important for education vendors."
+    - id: "fn2"
+      symbol: "‡"
+      note: "I know that Tailwind generates a lot of emotion. I've been writing CSS by hand for 25 years (and love it) and I'm not ashamed to say that I enjoy Tailwind, though I don't use it all the time. This site for instance is all hand-written, and I've created my own \"mini Tailwinds\" at times too. It made sense for Honeycomb as it significantly speeds up the time to write CSS/Sass, files are much shorter using `@apply` on single lines, other teams were using it or wanted to, and the config file defining our theme/primitives was really helpful for us."
+    - id: "fn3"
+      symbol: "§"
+      note: I fully appreciate how ridiculous it sounds to roll our own icon font! I have a lot of experience with them, though, and my manager was incredibly supportive in letting me really enjoy this project too. I think the reasoning stands on its own, but I also do just get a lot of enjoyment making them. 
 ---
 
 {{< intro id="intro" title="A design system is only valuable if teams can actually use it" >}}
@@ -84,6 +89,11 @@ That shaped both the earliest decisions and the later priorities: browser-native
 
 Honeycomb was built to support six education products with different histories, product roadmaps, engineering teams, and frontend maturity. We had products that ran the gamut from "we manually copy `jquery.min.js` and cannot install npm" to "everything is React." The system also existed in two connected places: a Figma component library for design work, and an implemented HTML/CSS package documented through a hand-built site.
 
+{{< figure 
+    src="img/overview@2x.png" 
+    alt="Button component sample in Figma and documentation"
+    caption="Button component variants in Figma (_left_) and a documented example (_right_)." >}}
+
 The package was intentionally native-first. Most components shipped as documented **HTML plus compiled CSS, with minimal JavaScript reserved for interactions that could not be handled reliably** with browser behavior alone. That meant product teams could drop in the CSS, copy the documented markup into whatever view file or component system they were using, and get a large amount of visual consistency and accessibility handling without committing to React, installing Tailwind, or rebuilding their app shell.
 
 This was also a design strategy. Our products needed to feel like one company without erasing their existing workflows overnight. The system provided shared foundations: header, left navigation, layout scaffolding, form controls, tables, buttons, alerts, theming, icons, and more complex components like datepickers and drawers. From there, each product could adopt progressively.
@@ -128,7 +138,7 @@ By documenting those patterns, the design team handled decisions that would othe
     title="<mark>Federal accessibility requirements</mark> created real urgency"
 >}}
 
-Accessibility was not just a quality goal or a design value&mdash;it had become a business requirement. Most Schooltastic customers are public school districts, and the [DOJ's Title II web and mobile accessibility rule](https://www.ada.gov/resources/2024-03-08-web-rule/) created a concrete expectation that public entities would bring web content and mobile apps into [WCAG 2.1 Level AA](https://www.w3.org/TR/WCAG21/) conformance&ddagger;. 
+Accessibility was not just a quality goal or a design value&mdash;it had become a business requirement. Most SchoolStatus customers are public school districts, and the [DOJ's Title II web and mobile accessibility rule](https://www.ada.gov/resources/2024-03-08-web-rule/) created a concrete expectation that public entities would bring web content and mobile apps into [WCAG 2.1 Level AA](https://www.w3.org/TR/WCAG21/) conformance.<a href="#footnotes" id="fn1" class="fn">&dagger;</a> 
 
 For an edtech platform this meant we could lose some of our largest districts (and theoretically almost all of our customers) if we didn't meet these requirements. It also meant that the the product teams could not just treat accessibility as something to "handle whenever we feel like it," and we could not rely on every team independently interpreting the WCAG, writing accessible markup, handling keyboard behavior, and testing every interaction with a screen reader. **The company needed accessibility that product teams could pick up off the shelf** as part of normal feature work.
 
@@ -147,7 +157,9 @@ Honeycomb had to absorb as much of that responsibility as possible and we took i
 
 {{< section id="native" title="Browser-native by default" >}}
 
-The most important implementation decision was that Honeycomb would not belong to any single product stack or require any kind of upgrade. We decided to be as out-of-the-way as possible and belong primarily to the browser.
+There are a bunch of projects wins and lessons that I'd love to highlight here, but I'm going to focus on four key ones that cover all the bases.
+
+The first and most important implementation decision we got right was that **Honeycomb would not belong to any single product stack** or require any kind of upgrade. We decided to be as out-of-the-way as possible and belong primarily to the browser.
 
 Despite the extended discussion, this pretty quickly ruled out a React-first design system early on. Some products would eventually wrap Honeycomb in React components (which was great!) but React could not be the system's lowest common denominator. **If the baseline required a modern JavaScript framework, two products would be locked out for too long** and the design system would fail at the thing it most needed to do: create consistency across the company before every app was modernized.
 
@@ -155,19 +167,26 @@ So Honeycomb's first-class output was HTML and CSS. <mark color="yellow">Each pr
 
 ### Sass on top of Tailwind
 
-Under the hood, **we authored Honeycomb as Sass-based components on top of Tailwind**. Tailwind helped us write and maintain the system faster, and the decision was also practical: two products already used Tailwind, so they could compile Honeycomb alongside their own Tailwind configuration and benefit from the same tree-shaking and build process. Other products were encouraged to move in that direction (and one did), but they were not blocked if they could not get there immediately.
+Under the hood, **we authored Honeycomb as Sass-based components on top of Tailwind**. Tailwind<a href="#footnotes" class="fn" id="fn2">&ddagger;</a> helped us write and maintain the system faster, and the decision was also practical: two products already used Tailwind, so they could compile Honeycomb alongside their own Tailwind configuration and benefit from the same tree-shaking and build process. Other products were encouraged to move in that direction (and one did), but they were not blocked if they could not get there immediately.
+
+{{< figure 
+    src="img/browser-tw@2x.png" 
+    alt="Sass code sample of the alert Honeycomb component"
+    class="rounded"
+    caption="We took advantage of Tailwind to better leverage our primitives and help write more readable Sass." >}}
 
 JavaScript followed the same model. We exported small vanilla JS modules, and later added a few framework-agnostic web components for interactions that needed more behavior. Teams could include those individually or as a bundle, but static components did not require JavaScript just to look and behave correctly. This included interactive components like dropdowns too!
 
-[ interactive dropdown example ]
-
 ### Native elements whenever possible
 
 We were also strict about using real browser controls wherever possible. A checkbox was an `<input type="checkbox">`, not a div managed by a JavaScript checkbox library. A button was a `<button>`. When the browser already provided semantics, keyboard behavior, form behavior, and accessibility expectations, Honeycomb leaned into that instead of replacing it. 
 
 In some products, this did mean that **we asked teams to remove older UI libraries that had recreated native controls in JavaScript**. That was one of the places where adoption did require change, but it was an intentional one: Honeycomb could only provide a reliable accessibility and interaction baseline if the underlying elements were honest.
 
-[ screenshot of form controls ]
+{{< figure 
+    src="img/browser-native@2x.png" 
+    alt="Various form controls all using native elements"
+    caption="All form controls looked clean and had subtle animations, still using native HTML elements entirely." >}}
 
 The result was a "tiered" model of sorts: every product could start with compiled CSS and documented HTML, and products with stronger tooling could compile the package themselves. Teams could opt into Tailwind, JavaScript modules, or web components as needed. **The system got more powerful at each layer, but the first layer still worked (really well).**
 
@@ -177,13 +196,20 @@ The result was a "tiered" model of sorts: every product could start with compile
 
 The biggest initial design challenge was trying to come up with an **app layout that could plausibly belong to six products that had a lot of unique history**. There was little visual overlap and we had at least three different navigation models to work with. Coming up with a modern layout and UI in isolation would've been a dream, but we had to consider legacy interfaces with longtime customers.
 
-[ screenshot of the old layouts stacked? ]
+{{< figure 
+    src="img/unify-old@2x.png" 
+    alt="Early screenshots of the acquired apps prior to redesigns"
+    caption="Early screenshots of the acquired apps prior to any redesign or design system integration." >}}
 
 We needed the products to feel meaningfully refreshed and part of the same portfolio, but not so different that each product team would have to significantly retrain users or redesign large workflows before adopting Honeycomb. That pushed us toward a familiar structure: a top app header, a collapsible left nav, a secondary left nav that could sit alongside this when needed, and a main content area that could support everything from dense admin tables to simpler card-based designs.
 
 This seems super obvious in retrospect, but the bigger point is the restraint. The design team (and org as a whole) was excited about the possibility of a more novel layout as we now had the opportunity to introduce something fresh. And we did, in fact, try out a ton of different directions&mdash;they just all would have made adoption feel riskier and forced too many product-specific exceptions. **The shared layout gave us a stable frame where every product was recognizable, while still creating a clearer, more modern, and professional baseline** across the portfolio.
 
-[ screenshot of left nav and header ]
+{{< figure 
+    src="img/unify-nav@2x.png" 
+    alt="Screenshot showing the new app header and left nav"
+    class="rounded-tl"
+    caption="The finalized app header and left navigation, integrated into the teacher training and evaluation product." >}}
 
 ### Neutral by default, themed by product
 
@@ -191,7 +217,10 @@ The visual direction followed the same logic. Honeycomb components were intentio
 
 **Product personality came through the specific color palettes instead.** Each app had its own palette exposed through CSS variables, so a product could feel distinct without owning a separate component library. These themes could even be applied with simple `data` attributes to allow for various fledgling integrations where one app feature was embedded in another. This all let us bring six products closer together without flattening them into a single generic interface.
 
-[ Theme screenshot ]
+{{< figure 
+    src="img/unify-theme@2x.png" 
+    alt="Various themed components from the design system"
+    caption="Themed variants of some of the Honeycomb components. Themed buttons used primarily for CTAs and larger actions." >}}
 
 This also helped Honeycomb provide patterns, not just components. A themed button or alert was (very) useful, but another win was that <mark color="green">we solved recurring questions each team had about layout patterns, what utilities to include in the header, how navigation should work, etc</mark>. Not only did they no longer have to reinvent these things every time in inconsistent ways, we took the decisionmaking chore away as well. 
 
@@ -199,11 +228,14 @@ The neutral components also gave those patterns enough consistency to feel share
 
 ### App header as an example
 
-The header was one of the most important examples of this balancing act. Each product had account controls and would need to update their product name and logo to the new Schooltastic-branded one. Beyond that, though, each one used this space for a lot of different things. Two had complex group switching, one had super buttons for users to create different types of content, one used it for their app's entire navigation, and one didn't use it at all.
+The header was one of the most important examples of this balancing act. Each product had account controls and would need to update their product name and logo to the new SchoolStatus-branded one. Beyond that, though, each one used this space for a lot of different things. Two had complex group switching, one had super buttons for users to create different types of content, one used it for their app's entire navigation, and one didn't use it at all.
 
 We used the header to standardize these things cross-product, while also solving some usability issues on both ends of the spectrum. The company plus product logo and the user account controls were the same and now in consistent places. A help button was introduced in those that didn't have it, and put in a predictable place as well. Finally, space was reserved for the two functions the header would be limited to: context switching and high-level app functions. 
 
-[ all 6 headers on top of each other ]
+{{< figure 
+    src="img/unify-headers@2x.png" 
+    alt="Final versions of the app headers for all 6 portfolio products"
+    caption="Final versions of the app headers for all 6 portfolio products. Certain elements became consistent across products for the first time." >}}
 
 The design stayed intentionally simple so it could work across products without becoming a custom negotiation every time, and we took away the ability to jam other random things into this space. This decision made the header less expressive than some early explorations, but more useful as infrastructure. <mark color="red">The header became one of the easiest ways for a product to start feeling like part of the portfolio too</mark>, and because it sat above the rest of the app, it could introduce Honeycomb without forcing every screen underneath it to change at once.
 
@@ -225,11 +257,9 @@ Once the HTML for any given component was set, in most cases **we could improve
 
 **CSS variables were a major part of that model.** Anything theme-related, all primitives, things like our custom shadows and opacities&mdash;really anything visual&mdash;was accessible and could be adjusted at the system layer easily. One of the biggest wins this introduced was the ability for product teams to access the same style attributes Honeycomb used when they weren't able to use a Honeycomb component. 
 
-[ screenshot of variables or theme controls ]
-
 ### Icons as an example
 
-We decided to roll our own icon set&mdash;not just because [I love making icon fonts](https://keyrune.andrewgioia.com) but because it gave us control over a pretty important component to Honeycomb's personality. We looked at open source libraries like [Iconoir](https://iconoir.com) and [Lucide](https://lucide.dev) but 3 problems led to us making our own:
+We decided to roll our own icon set&mdash;not just because [I love making icon fonts](https://keyrune.andrewgioia.com) but because it gave us control over a pretty important component to Honeycomb's personality.<a href="#footnotes" class="fn sect" id="fn3">&sect;</a> We looked at open source libraries like [Iconoir](https://iconoir.com) and [Lucide](https://lucide.dev) but 3 problems led to us making our own:
 
 * No single library was complete enough for us 
 * I hated the idea of loading massive font files when we only needed a fraction of the icons
@@ -239,9 +269,12 @@ We also needed icons to remain centrally maintainable; if every product inlined
 
 We combined open source icons and drew others to fill the gaps, and **shipped outline and solid sets as font files within the Honeycomb package**. One of the cool aspects is that we made the icon font work as one family with two weights: regular for outline icons and bold for filled icons. You could switch between variants using the same name just by changing the elements font weight.
 
-We also added ligatures for every icon as well, so that teams could write readable names like `arrow-left` as text instead of the normal `<i class="hc-icon hc-icon--arow-left></i>`. This was partly an implementation convenience but mostly a response to a real product request: one team specifically wanted to place icons using words, as they were doing it that way in their app currently. <mark color="red">Supporting this request was just one more way we drove adoption.</mark>
+{{< figure 
+    src="img/stable-icons@2x.png" 
+    alt="Final versions of the app headers for all 6 portfolio products"
+    caption="Final versions of the app headers for all 6 portfolio products. Certain elements became consistent across products for the first time." >}}
 
-[ screenshot of icon font variants ]
+We also added ligatures for every icon as well, so that teams could write readable names like `arrow-left` as text instead of the normal `<i class="hc-icon hc-icon--arow-left></i>`. This was partly an implementation convenience but mostly a response to a real product request: one team specifically wanted to place icons using words, as they were doing it that way in their app currently. <mark color="red">Supporting this request was just one more way we drove adoption.</mark>
 
 Icons are a great example of how Honeycomb needed to be easy for product teams to use, but still governable by the design system. Stable implementation gave product teams confidence, while centrally owned assets let the system keep getting better after adoption.
 
@@ -253,7 +286,10 @@ The documentation site became one of the most important parts of Honeycomb becau
 
 Each component page included examples, available attributes, expected markup, accessibility notes, and implementation guidance. We documented not only what a component looked like, but when to use it, what options it supported, and what developers still needed to handle correctly in their own product context. <mark color="red">That level of detail made the docs a huge time investment, but it also made them one of the strongest adoption tools we had.</mark>
 
-[ screenshot of component docs ]
+{{< figure 
+    src="img/docs-datepicker@2x.png" 
+    alt="Screenshot of the Honeycomb documentation page for the Datepicker component."
+    caption="Each component was fully documented showcasing attributes, variants, and implementation code for HTML and, as with the Datepicker, web component code." >}}
 
 **Writing the docs also improved the system itself.** If I had trouble explaining a component clearly, or if an example required too many caveats, or if the classnames were inconsistent with other components, that was usually a sign that the component/markup needed more work. It also let me test the designs in real time, which often improved our components on the Figma/design side. 
 
@@ -265,7 +301,10 @@ The docs were especially important for accessibility. The DOJ requirement create
 
 That helped teams get accessibility benefits from Honeycomb without needing every developer to become an accessibility specialist overnight. Components started from a stronger baseline, and the docs explained the remaining responsibilities clearly enough that teams could act on them.
 
-[ screenshot of accessibility notes ]
+{{< figure 
+    src="img/accessibility-note@2x.png" 
+    alt="Example accessibility note from the Tooltip component doc"
+    caption="One of the accessibility notes from the Tooltip documentation page." >}}
 
 ### A playground for real markup
 
@@ -279,7 +318,11 @@ The playground also made support conversations easier. If someone had an issue o
 
 That was OK because we kept both sources connected through the Honeycomb repo. **The same implementation examples that powered the docs also informed the Figma code connections**, so the code that developers saw in Dev Mode matched what they would find on the docs site. Figma became the quick path from design to code, while the docs remained the deeper source for examples, attributes, accessibility details, and usage guidance.
 
-[ screenshot of Figma Dev Mode / Code Connect ]
+{{< figure 
+    src="img/docs-figma@2x.png" 
+    alt="Screenshots of Figma code connections for HTML and web component code for the Alert component."
+    caption="Each component was connected to Figma Dev Mode via Code Connect, including HTML and Web Component options." >}}
+
 
 ### Design became a frontend resource
 
@@ -291,7 +334,7 @@ This really changed the design team's role quite a bit, particularly at a time w
 
 {{< section id="impact" title="Impact" >}}
 
-Honeycomb has had a profound impact on Schooltastic as a whole. At the most basic level, it's a shared library of frontend components and patterns that have moved all six products so much closer to a truly unified experience. From accessibility to standardized patterns, it's taken so much off the plates of frontend developers that they're shipping noticeably faster. The design team too is able to create high fidelity designs much quicker and easier.
+Honeycomb has had a profound impact on SchoolStatus as a whole. At the most basic level, it's a shared library of frontend components and patterns that have moved all six products so much closer to a truly unified experience. From accessibility to standardized patterns, it's taken so much off the plates of frontend developers that they're shipping noticeably faster. The design team too is able to create high fidelity designs much quicker and easier.
 
 These are really table stakes for any design system, though, and I want to highlight two major and somewhat unexpected impacts that our specific design system created.
 
@@ -301,7 +344,7 @@ Accessibility is often an afterthought at most orgs, and even here where it was
 
 <mark color="blue">Honeycomb gave us a way to turn accessibility from a "compliance scramble" into a shared competency.</mark> The design team led the way in translating requirements into functional code. Components started from accessible markup and interaction patterns, the documentation explained requirements in practical language, and our team became a place product teams could go with real questions: focus behavior, labels, keyboard interactions, screen-reader expectations, color contrast, and when ARIA was actually needed.
 
-The business value was significant too. For a company obviously selling into education, accessibility is not a nice-to-have feature. Accessibility affects trust, procurement, renewals, and risk, and Honeycomb gave Schooltastic a much stronger answer to that pressure because it was built into the system teams were already adopting.
+The business value was significant too. For a company obviously selling into education, accessibility is not a nice-to-have feature. Accessibility affects trust, procurement, renewals, and risk, and Honeycomb gave SchoolStatus a much stronger answer to that pressure because it was built into the system teams were already adopting.
 
 ### The design team elevated to a true cross-functional team
 

content/values.md

@@ -2,7 +2,7 @@
 title: "Design philosophy"
 layout: "document"
 slug: "values"
-summary: "<span color=\"blue\"><strong>How I think about design</strong></span>, particularly for the browser, and the values I hold close. Good design can't happen without <span color=\"red\"><strong>respect for the user</strong></span> and their device. <span color=\"yellow\"><strong>Taste and personality matter.</strong></span>"
+summary: "<span color=\"blue\"><strong>How I think about design</strong></span>, particularly for the browser, and the values I hold close. Good design can't happen without <span color=\"red\"><strong>respect for the user</strong></span> and their device. <span color=\"yellow\"><strong>Taste and personality matter</strong></span> quite a bit."
 header:
   page:
     title: "Design"
@@ -16,13 +16,13 @@ footnotes:
 
 <em>I design for the browser first.</em> This is true even in an age of mobile-first and push-them-to-the-app-at-all-costs. I think the web browser is a great equalizer and perhaps the greatest preserver of the open internet. 
 
-<em>I care deeply about how something looks, but aesthetics are never the point on their own.</em> Good design should feel thoughtfuland calm; it should build trust and reduce cognitive load, never add to it. The goal is to make software more useful and easier to use. If a visual choice, interaction, or animation doesn't improve the experience, it probably doesn't belong there. **Dark patterns are an abomination.** Delight matters and it should come primarily from responsiveness, care, playfulness, and personality.
+<em>I care deeply about how something looks, but aesthetics are never the point on their own.</em> Good design should feel thoughtful and calm; it should build trust and reduce cognitive load, never adding to it. The goal is to make software more useful and easier to use. If a visual choice, interaction, or animation doesn't improve the experience, it probably doesn't belong there. **Dark patterns are an abomination** and I will never contribute to them. Delight matters and it should come primarily from responsiveness, care, playfulness, and personality.
 
 <em>Good interfaces should respect the user and their device.</em> The browser, HTML, and CSS are already an extraordinarily capable platform, and I try to stay as close to browser-native as possible. If something can be done well with HTML and CSS, I will always do that rather than rely on JavaScript as a crutch. 
 
 I am not opposed to frameworks or complex client-side applications when they're justified, I just think they rarely are and too often introduce more usability, accessibility, and performance problems than the ones they solve. **JavaScript should enhance an experience, not become a requirement** by default.&dagger;
 
-<em>That same respect extends to semantics, controls, and data structures.</em> A button should be a button. A checkbox should be a checkbox. Tabular data should (almost always) be shown in a table. I don't believe in reinventing familiar controls when the native version already communicates the right thing and behaves the way users expect. **Page load times, payload size, and memory use all matter too.** These are not just engineering's job or an anachronism&mdash;**they are a foundational part of the user experience**.
+<em>That same respect extends to semantics, controls, and data structures.</em> A button should be a button. A checkbox should be a checkbox. Tabular data should (almost always) be shown in a `<table>`. I don't believe in reinventing familiar controls when the native version already communicates the right thing and behaves the way users expect. **Page load times, payload size, and memory use all matter too.** These are not just engineering's job or anachronisms&mdash;**they are a foundational part of the user experience**.
 
 <em>I don't believe products need to wait for perfect alignment before they improve.</em> Some of the most harmful thinking on product teams comes from the idea that everything has to be redesigned at once in order to be worth doing. Consistency matters, but so does momentum. If something is broken, **it's often better to fit it now than to wait for the ideal future state that may never arrive**. Many interfaces stay bad for years because teams are too concerned with doing every related piece at the same time.
 
@@ -32,4 +32,6 @@ I am not opposed to frameworks or complex client-side applications when they're
 
 <em>Type is just as much a part of the design as everything else.</em> I often design around or with the words on the screen, and it's OK to add another line of text or force everything to be a single line when it makes the design and usability better.
 
-<em>Finally, design benefits from collaboration, but not from design by committee.</em> Everyone has opinions about interfaces because everyone uses them. That's normal and useful! **But not every opinion should carry the same weight**, and not every preference should become a product decision. Good design requires judgment: knowing when to listen, when to test, when to defend a choice, and when to change course. My job is not to just impose my taste by fiat&mdash;**my job is to make informed decisions in service of the user and the product&mdash;but my taste as the designer <em>does</em> matter**&ddagger; and I will rely on it.
+<em>Finally: design benefits from collaboration, but not from design by committee.</em> Everyone has opinions about interfaces because everyone uses them. That's normal and useful! **But not every opinion should carry the same weight**, and not every preference should become a product decision. 
+
+Good design requires judgment: knowing when to listen, when to test, when to defend a choice, and when to change course. My job is not to just impose my taste by fiat&mdash;**my job is to make informed decisions in service of the user and the product&mdash;but my taste as the designer <em>does</em> matter**&ddagger; and I will rely on it.

hugo.yaml

@@ -1,5 +1,5 @@
 baseURL: "https://portfolio.lan"
-languageCode: "en-us"
+locale: "en-us"
 title: "Andrew Gioia | Case Studies"
 enableRobotsTXT: true
 disableKinds:

layouts/partials/footer.html

@@ -12,12 +12,18 @@
     <big>Ag</big>
     <ul aria-label="Footnotes">
         {{- range $footnotes -}}
+        {{- $footnote := . -}}
         <li class="footnote">
             {{- with .symbol -}}
             <span class="symbol">{{ . | safeHTML }}</span>
             {{- end -}}
             {{- with .note -}}
-            <span class="note">{{ . }}</span>
+            <span class="note">
+                {{ . | markdownify }}
+                {{- with $footnote.id -}}
+                <a href="#{{ . }}" class="return">⤴</a>
+                {{- end -}}
+            </span>
             {{- end -}}
         </li>
         {{- end -}}

layouts/shortcodes/figure.html

@@ -0,0 +1,17 @@
+{{- $src := .Get "src" -}}
+{{- $alt := .Get "alt" | default "" -}}
+{{- $class := .Get "class" -}}
+{{- $caption := .Get "caption" | default "" -}}
+{{- $resource := .Page.Resources.GetMatch $src -}}
+{{- $url := $src -}}
+{{- with $resource -}}
+  {{- $url = .RelPermalink -}}
+{{- end -}}
+<figure {{ with $class }}class="{{ . }}"{{ end }}>
+  <img src="{{ $url }}" alt="{{ $alt }}" />
+  {{- with $caption }}
+  <figcaption>
+    {{ $caption | markdownify }}
+  </figcaption>
+  {{- end }}
+</figure>