Final cleanups for mobile handling; reduces site header to 4rem on short screens; converts legacy case study to use figure shortcode

assets/css/site.css

@@ -22,10 +22,11 @@
     --surface: rgba(255, 255, 255, 0.28);
 
     --font-sans: Inter, -apple-system, BlinkMacSystemFont, "SF Pro Text", "SF Pro Display", "Helvetica Neue", Helvetica, Arial, sans-serif;
-    --font-serif: "Source Serif", "Iowan Old Style", "Palatino Linotype", "Book Antiqua", Georgia, serif;
 
     --column-width: min(72rem, calc(100% - 3rem));
     --content-width: min(44rem, calc(100% - 3rem));
+    --header-height: 4rem;
+    --hero-min: 800px;
     --article-grid: 1fr;
     --article-gap: 2rem;
     --article-top: 0;
@@ -86,7 +87,7 @@ h3 {
     text-shadow: 0 1px 0 #fff;
 
     #impact & {
-        font-size: 1.1rem;
+        font-size: 1.2rem;
     }
 }
 
@@ -112,7 +113,7 @@ body {
     color: var(--text);
     display: grid;
     font-family: var(--font-sans);
-    grid-template-rows: 5rem 1fr auto;
+    grid-template-rows: var(--header-height) 1fr auto;
     line-height: 1.5;
     -webkit-font-smoothing: antialiased;
     text-rendering: optimizeLegibility;
@@ -146,7 +147,7 @@ body {
             align-items: center;
             display: flex;
             font-size: 1.5rem;
-            gap: 0.5rem;;
+            gap: 0.5rem;
             text-decoration: none;
 
             &:hover {
@@ -1303,7 +1304,7 @@ body#values {
 
 /* small height screens override */
 /* FIX */
-@media (max-height: 720px)
+/*@media (max-height: 720px)
 {
     main > header {
         grid-auto-rows: auto auto;
@@ -1312,6 +1313,15 @@ body#values {
         padding-bottom: 3rem;
     }
 }
+*/
+
+/* make the header taller on screens > 720px high */
+@media (min-height: 900px)
+{
+    body {
+        --header-height:  5rem;
+    }
+}
 
 /* bigger than phones */
 @media (min-width: 420px)
@@ -1349,10 +1359,10 @@ body#values {
 
     /* main header is now full pane */
     main {
-        grid-template-rows: max(800px, calc(100lvh - 5rem)) auto;
+        grid-template-rows: max(var(--hero-min), calc(100lvh - var(--header-height))) auto;
 
         > header {
-            min-height: calc(800px - 5rem);
+            min-height: calc(var(--hero-min) - var(--header-height));
 
             > hgroup {
                 margin-top: 4rem;
@@ -1520,6 +1530,12 @@ body#values {
         max-width: 75%;
     }
 
+    h3 {
+        #impact & {
+            font-size: 1.1rem;
+        }
+    }
+
     /* site footer follows content columns now */
     body > footer
     {

content/studies/legacy/index.md

@@ -81,12 +81,10 @@ 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>
+{{< figure 
-  <img src="img/overview.png" />
+    src="img/overview.png" 
-  <figcaption>
+    alt="Original app screens for Wallabyte Central on desktop and mobile"
-    Original app screens for Wallabyte Central on desktop and mobile, for a user with multiple children and many form requests.
+    caption="Original app screens for Wallabyte Central on desktop and mobile, for a user with multiple children and many form requests." >}}
-  </figcaption>
-</figure>
 
 {{< /overview >}}
 
@@ -106,12 +104,10 @@ 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>
+{{< figure 
-  <img src="img/problem-find.png" />
+    src="img/problem-find.png" 
-  <figcaption>
+    alt="Screenshots of the old UI showing the different locations for forms"
-    <p>Users needed to remember if they responded to a form request (<i>left</i>) or if they started the form from their often massive library (<i>right</i>).</p>
+    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_)" >}}
-  </figcaption>
-</figure>
 
 Highlighting this issue were the three distinct paths for a user to find the forms they submitted:
 
@@ -129,12 +125,10 @@ 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>
+{{< figure 
-  <img src="img/problem-critical.png" />
+    src="img/problem-critical.png" 
-  <figcaption>
+    alt="Screenshots of the old UI showing that critical information was hard to find"
-    <p>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.</p>
+    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." >}}
-  </figcaption>
-</figure>
 
 {{< /problem >}}
 
@@ -159,12 +153,10 @@ 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>
+{{< figure 
-  <img src="img/problem-multiple.png" />
+    src="img/problem-multiple.png" 
-  <figcaption>
+    alt="Screenshots of the old UI showing how difficult the experience was for parents of multiple kids"
-    <p>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.</p>
+    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." >}}
-  </figcaption>
-</figure>
 
 {{< /problem >}}
 
@@ -207,12 +199,10 @@ A bunch of compounding delivery constraints, however, stretched this closer to _
     <p>
       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>
+{{< figure 
-      <img src="img/context-ds@2x.png" alt="Original form card, stopgap Wallabyte refresh card, and the final Honeycomb version" />
+    src="img/context-ds@2x.png" 
-      <figcaption>
+    alt="Original form card, stopgap Wallabyte refresh card, and the final Honeycomb version"
-        <p>Original form card (<em>left</em>), stopgap "Wallabyte refresh" version (<em>middle</em>), and the final Honeycomb card ultimately implemented.</p>
+    caption="Original form card (_left_), stopgap \"Wallabyte refresh\" version (_middle_), and the final Honeycomb card ultimately implemented (_right_)." >}}
-      </figcaption>
-    </figure>
     <p>
       That <strong>ambiguity led me to create a temporary bridge</strong> between the legacy Wallabyte interface and Honeycomb so the team could keep moving. It helped in the short term, but it also created rework later when parts of that hybrid approach needed to be unwound.
     </p>
@@ -227,12 +217,10 @@ A bunch of compounding delivery constraints, however, stretched this closer to _
     <p>
       <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>
+{{< figure 
-      <img src="img/context-header.png" alt="Some of the header variations that delayed progress." />
+    src="img/context-header.png" 
-      <figcaption>
+    alt="Some of the header variations that delayed progress"
-        <p>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>
+    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." >}}
-      </figcaption>
-    </figure>
     <p>
       Personal preference wedged its way in and a senior design leader felt strongly that the header's background color needed to signal the user's account type (parent, staff, approver, etc.).
     </p>
@@ -282,12 +270,10 @@ 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>
+{{< figure 
-  <img src="img/response-forms@2x.png" alt="Revised navigation showing the new forms organization by status" />
+    src="img/response-forms@2x.png" 
-  <figcaption>
+    alt="Revised navigation showing the new forms organization by status"
-    <p>Forms are now organized by their status as opposed to separating them based on type.</p>
+    caption="Forms are now organized by their status as opposed to separating them based on type." >}}
-  </figcaption>
-</figure>
 
 {{< /response >}}
 
@@ -306,23 +292,19 @@ 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>
+{{< figure 
-  <img src="img/response-widget-desktop@2x.png" alt="Mobile screens detailing the new alert + navigation widget." />
+    src="img/response-widget-desktop@2x.png" 
-  <figcaption>
+    alt="Desktop version of the mobile navigation + alert setup"
-    <p>Card-style buttons mirrored the mobile navigation + alert display for parents on desktop.</p>
+    caption="Card-style buttons mirrored the mobile navigation + alert display for parents on desktop." >}}
-  </figcaption>
-</figure>
 
 #### What this solved specifically:
 
 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>
+{{< figure 
-  <img src="img/response-widget-mobile@2x.png" alt="Mobile screens detailing the new alert + navigation widget." />
+    src="img/response-widget-mobile@2x.png" 
-  <figcaption>
+    alt="Mobile screens detailing the new alert + navigation widget"
-    <p>New alert + navigation widget for mobile solved 2 issues: alerts are always at the top now, and users can easily jump by form status.</p>
+    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." >}}
-  </figcaption>
-</figure>
 
 {{< /response >}}
 
@@ -364,13 +346,10 @@ 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>
+{{< figure 
-  <img src="img/response-users@2x.png" alt="Various UI components showing the different user avatar treatments" />
+    src="img/response-users@2x.png" 
-  <figcaption>
+    alt="Various UI components showing the different user avatar treatments"
-    <p>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.</p>
+    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." >}}
-  </figcaption>
-</figure>
-
 
 {{< /response >}}