Optimizes all images and some SVGs

content/studies/honeycomb/index.md

@@ -91,7 +91,7 @@ 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" 
+    src="img/overview.min@2x.png" 
     alt="Button component sample in Figma and documentation"
     caption="Button component variants in Figma (_left_) and a documented example (_right_)." >}}
 
@@ -171,7 +171,7 @@ So Honeycomb's first-class output was HTML and CSS. <mark color="yellow">Each pr
 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" 
+    src="img/browser-tw.min@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." >}}
@@ -185,7 +185,7 @@ We were also strict about using real browser controls wherever possible. A check
 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.
 
 {{< figure 
-    src="img/browser-native@2x.png" 
+    src="img/browser-native.min@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." >}}
 
@@ -198,7 +198,7 @@ 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.
 
 {{< figure 
-    src="img/unify-old@2x.png" 
+    src="img/unify-old.min@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." >}}
 
@@ -207,7 +207,7 @@ We needed the products to feel meaningfully refreshed and part of the same portf
 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.
 
 {{< figure 
-    src="img/unify-nav@2x.png" 
+    src="img/unify-nav.min@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." >}}
@@ -219,7 +219,7 @@ 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.
 
 {{< figure 
-    src="img/unify-theme@2x.png" 
+    src="img/unify-theme.min@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." >}}
 
@@ -234,7 +234,7 @@ The header was one of the most important examples of this balancing act. Each pr
 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. 
 
 {{< figure 
-    src="img/unify-headers@2x.png" 
+    src="img/unify-headers.min@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." >}}
 
@@ -271,7 +271,7 @@ 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.
 
 {{< figure 
-    src="img/stable-icons@2x.png" 
+    src="img/stable-icons.min@2x.png" 
     alt="Sampling of the outline and solid icons from the icon set"
     caption="Sampling of the outline and solid icons from our set, shown in the Figma component here." >}}
 
@@ -288,7 +288,7 @@ 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>
 
 {{< figure 
-    src="img/docs-datepicker@2x.png" 
+    src="img/docs-datepicker.min@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." >}}
 
@@ -303,7 +303,7 @@ 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.
 
 {{< figure 
-    src="img/accessibility-note@2x.png" 
+    src="img/accessibility-note.min@2x.png" 
     alt="Example accessibility note from the Tooltip component doc"
     caption="One of the accessibility notes from the Tooltip documentation page." >}}
 
@@ -320,7 +320,7 @@ 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.
 
 {{< figure 
-    src="img/docs-figma@2x.png" 
+    src="img/docs-figma.min@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." >}}
 

content/studies/legacy/index.md

@@ -82,7 +82,7 @@ The existing experience had become painful enough that major customers, includin
 At the same time, Wallabyte was also rebranding as **Schooltastic Forms**, now a year after it had been acquired by Schooltastic. This project was my first interaction with this app and team, and not only did I have to get up to speed quickly, its users could be seeing a lot of sudden change if this update wasn't handled carefully. 
 
 {{< figure 
-    src="img/overview.png" 
+    src="img/overview.min@2x.png" 
     alt="Original app screens for Wallabyte Central on desktop and mobile"
     caption="Original app screens for Wallabyte Central on desktop and mobile, for a user with multiple children and many form requests." >}}
 
@@ -105,7 +105,7 @@ This was perhaps the chief user complaint and the most immediately obvious usabi
 Users had to remember how a form had been started just to find it again, and unfinished work was treated differently in both sections. **These distinctions didn't matter to the user** who just wanted to get in and get out.
 
 {{< figure 
-    src="img/problem-find.png" 
+    src="img/problem-find.min@2x.png" 
     alt="Screenshots of the old UI showing the different locations for forms"
     caption="Users needed to remember if they responded to a form request (_left_) or if they started the form from their often massive library (_right_)" >}}
 
@@ -126,7 +126,7 @@ One of the revelations during the project's research phase was that **94% of end
 Pages were never optimized and often zoomed out, 2-axis scrolling was prevalent on data-dense screens or those with tables, and completing forms with data inputs that were not browser-native created more problems than they solved.
 
 {{< figure 
-    src="img/problem-critical.png" 
+    src="img/problem-critical.min@2x.png" 
     alt="Screenshots of the old UI showing that critical information was hard to find"
     caption="Certain critical action items&mdash;like pending form approvals or student safety alerts&mdash;were buried at the bottom on mobile with no indication up top." >}}
 
@@ -154,7 +154,7 @@ Parents and staff often needed to act on behalf of multiple children or schools,
 Simple things made it harder for users to quickly scan, like only showing the school or group avatar instead of the student that the form was requested for. Users could easily lose track of whose information they were viewing or updating, or bounce around the app to check first.
 
 {{< figure 
-    src="img/problem-multiple.png" 
+    src="img/problem-multiple.min@2x.png" 
     alt="Screenshots of the old UI showing how difficult the experience was for parents of multiple kids"
     caption="Parents of multiple children found it difficult to quickly identify which form was for whom. Even though the names are there, the redundant avatars and group information required extra thought." >}}
 
@@ -200,7 +200,7 @@ A bunch of compounding delivery constraints, however, stretched this closer to _
       At the same time of this project, <a href="/studies/honeycomb"><strong>Honeycomb, our design system</strong></a>, was under active development and beginning to show up in other platform products. This created a recurring strategic question: should this redesign fully adopt Honeycomb, or should it act as more of a stopgap refresh that preserved more of the existing product? Because leadership never fully committed to one path early enough, the design work sometimes had to serve both goals at once.
     </p>
 {{< figure 
-    src="img/context-ds@2x.png" 
+    src="img/context-ds.min@2x.png" 
     alt="Original form card, stopgap Wallabyte refresh card, and the final Honeycomb version"
     caption="Original form card (_left_), stopgap \"Wallabyte refresh\" version (_middle_), and the final Honeycomb card ultimately implemented (_right_)." >}}
     <p>
@@ -218,7 +218,7 @@ A bunch of compounding delivery constraints, however, stretched this closer to _
       <strong>The app header was a perfect example of overthinking and tinkering to a fault.</strong> We had a version of the common header design ready in our design system and it made sense to introduce that part of the design system now&mdash;it wasn't that much different than the current header. 
     </p>
 {{< figure 
-    src="img/context-header.png" 
+    src="img/context-header.min@2x.png" 
     alt="Some of the header variations that delayed progress"
     caption="Some of the header variations. The beginning and end were not far off! Many hours were spent going over color and multiple account switching that ended up outside the scope." >}}
     <p>
@@ -271,7 +271,7 @@ Users no longer had to remember how a form started just to find it again, **form
 This change addressed the <mark color="yellow">fragmented findability problem</mark> at the center of the legacy experience and gave both parents and staff a more predictable place to return to unfinished or completed work.
 
 {{< figure 
-    src="img/response-forms@2x.png" 
+    src="img/response-forms.min@2x.png" 
     alt="Revised navigation showing the new forms organization by status"
     caption="Forms are now organized by their status as opposed to separating them based on type." >}}
 
@@ -293,7 +293,7 @@ We played around with a more traditional tab bar at the bottom or a simpler aler
 This is one of the clearest examples in the project of <strong>designing for the user rather than for my own aesthetic preference</strong>. I hated the way this looked on the screen and how much space it took up! **It felt clunky and non-standard, but it tested very well with customers**, helped users notice important items faster, and ended up creating real goodwill because the product finally felt more helpful.
 
 {{< figure 
-    src="img/response-widget-desktop@2x.png" 
+    src="img/widget-desktop.min@2x.png" 
     alt="Desktop version of the mobile navigation + alert setup"
     caption="Card-style buttons mirrored the mobile navigation + alert display for parents on desktop." >}}
 
@@ -302,7 +302,7 @@ This is one of the clearest examples in the project of <strong>designing for the
 It addressed the mobile-heavy reality of the product and <mark color="red">eliminated all possibility that users would miss approvals, alerts, or other high-priority tasks</mark> simply because they were visually buried.
 
 {{< figure 
-    src="img/response-widget-mobile@2x.png" 
+    src="img/widget-mobile.min@2x.png" 
     alt="Mobile screens detailing the new alert + navigation widget"
     caption="New alert + navigation widget for mobile solved 2 issues: alerts are always at the top now, and users can easily jump by form status." >}}
 
@@ -347,7 +347,7 @@ Users dealing with multiple children, groups, or school contexts needed clarity
 This was a more practical and effective answer to the multi-student problem than the broader universal switcher concept we explored earlier in the project. It improved scanability without adding a heavier interaction model the product did not really support.
 
 {{< figure 
-    src="img/response-users@2x.png" 
+    src="img/response-users.min@2x.png" 
     alt="Various UI components showing the different user avatar treatments"
     caption="Whenever students or teachers were presented, we included their name, group, and avatar in a consistent way. We also introduced standard sets of avatars with a high-contrast initial fallback." >}}
 

static/img/nyc.svg

@@ -1 +1 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><svg width="100%" height="100%" viewBox="0 0 192 240" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;"><rect x="8.693" y="167.817" width="86.4" height="72" style="fill:#fcb70d;"/><rect x="100.268" y="129.523" width="86.4" height="110.477" style="fill:#de342a;"/><rect x="100.268" y="96.682" width="86.4" height="32.84" style="fill:#0064c0;"/><rect x="100.268" y="53.482" width="43.2" height="43.2" style="fill:#272727;"/><rect x="144.859" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="147.739" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="150.619" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="153.499" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="156.379" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="159.259" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="162.139" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="165.019" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="167.907" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="170.787" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="173.667" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="176.547" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="179.439" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="182.319" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="185.199" y="53.482" width="1.448" height="43.2" style="fill:#272727;"/><rect x="21.173" y="152.457" width="61.44" height="15.36" style="fill:#0064c0;"/><rect x="49.985" y="138.83" width="3.816" height="13.627" style="fill:#272727;"/></svg>
+<svg xmlns="http://www.w3.org/2000/svg" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2" viewBox="0 0 192 240"><path d="M8.693 167.817h86.4v72h-86.4z" style="fill:#fcb70d"/><path d="M100.268 129.523h86.4V240h-86.4z" style="fill:#de342a"/><path d="M100.268 96.682h86.4v32.84h-86.4z" style="fill:#0064c0"/><path d="M100.268 53.482h43.2v43.2h-43.2zM144.859 53.482h1.448v43.2h-1.448zM147.739 53.482h1.448v43.2h-1.448zM150.619 53.482h1.448v43.2h-1.448zM153.499 53.482h1.448v43.2h-1.448zM156.379 53.482h1.448v43.2h-1.448zM159.259 53.482h1.448v43.2h-1.448zM162.139 53.482h1.448v43.2h-1.448zM165.019 53.482h1.448v43.2h-1.448zM167.907 53.482h1.448v43.2h-1.448zM170.787 53.482h1.448v43.2h-1.448zM173.667 53.482h1.448v43.2h-1.448zM176.547 53.482h1.448v43.2h-1.448zM179.439 53.482h1.448v43.2h-1.448zM182.319 53.482h1.448v43.2h-1.448zM185.199 53.482h1.448v43.2h-1.448z" style="fill:#272727"/><path d="M21.173 152.457h61.44v15.36h-61.44z" style="fill:#0064c0"/><path d="M49.985 138.83h3.816v13.627h-3.816z" style="fill:#272727"/></svg>