diff --git a/assets/css/site.css b/assets/css/site.css
index 50ee057..0515620 100644
--- a/assets/css/site.css
+++ b/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
{
diff --git a/content/studies/legacy/index.md b/content/studies/legacy/index.md
index f8eb5bc..a9bbe1e 100644
--- a/content/studies/legacy/index.md
+++ b/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.
-
-
-
- Original app screens for Wallabyte Central on desktop and mobile, for a user with multiple children and many form requests.
-
-
+{{< figure
+ src="img/overview.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." >}}
{{< /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.
-
-
-
-
Users needed to remember if they responded to a form request (left) or if they started the form from their often massive library (right).
-
-
+{{< figure
+ src="img/problem-find.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_)" >}}
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.
-
-
-
-
Certain critical action items—like pending form approvals or student safety alerts—were buried at the bottom on mobile with no indication up top.
-
-
+{{< figure
+ src="img/problem-critical.png"
+ alt="Screenshots of the old UI showing that critical information was hard to find"
+ caption="Certain critical action items—like pending form approvals or student safety alerts—were buried at the bottom on mobile with no indication up top." >}}
{{< /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.
-
-
-
-
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.
-
-
+{{< figure
+ src="img/problem-multiple.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." >}}
{{< /problem >}}
@@ -207,12 +199,10 @@ A bunch of compounding delivery constraints, however, stretched this closer to _
At the same time of this project, Honeycomb, our design system, 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.
-
-
-
-
Original form card (left), stopgap "Wallabyte refresh" version (middle), and the final Honeycomb card ultimately implemented.
-
-
+{{< figure
+ src="img/context-ds@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_)." >}}
That ambiguity led me to create a temporary bridge 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.
@@ -227,12 +217,10 @@ A bunch of compounding delivery constraints, however, stretched this closer to _
The app header was a perfect example of overthinking and tinkering to a fault. 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—it wasn't that much different than the current header.
-
-
-
-
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.
-
-
+{{< figure
+ src="img/context-header.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." >}}
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.).
@@ -282,12 +270,10 @@ Users no longer had to remember how a form started just to find it again, **form
This change addressed the fragmented findability problem at the center of the legacy experience and gave both parents and staff a more predictable place to return to unfinished or completed work.
-
-
-
-
Forms are now organized by their status as opposed to separating them based on type.
-
-
+{{< figure
+ src="img/response-forms@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." >}}
{{< /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 designing for the user rather than for my own aesthetic preference. 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.
-
-
-
-
Card-style buttons mirrored the mobile navigation + alert display for parents on desktop.
-
-
+{{< figure
+ src="img/response-widget-desktop@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." >}}
#### What this solved specifically:
It addressed the mobile-heavy reality of the product and eliminated all possibility that users would miss approvals, alerts, or other high-priority tasks simply because they were visually buried.
-
-
-
-
New alert + navigation widget for mobile solved 2 issues: alerts are always at the top now, and users can easily jump by form status.
-
-
+{{< figure
+ src="img/response-widget-mobile@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." >}}
{{< /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.
-
-
-
-
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.
-
-
-
+{{< figure
+ src="img/response-users@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." >}}
{{< /response >}}
- 
- 
- 
- 
- 
- 
- 
- 
- 
-