A 165 Added, 145 Removed Diff That Barely Changed the Line Count

Four commits landed between 21:55 and 23:42 one Thursday evening on a side project, and the last one only changed how a divider looks. By the end the detail page showed four things at the top and buried the rest under a collapsible labeled “Details.”

It started because we opened the detail view for a single item to check one thing: whether it was waiting on us. Above the fold sat a status card, a row of tuning sliders, a block of key dates, a related-items list, attached artifacts, a history log, and a metadata footer. All of it stacked, all of it accurate, none of it answering the question we came with. We had to read the entire screen to find one word.

Progressive disclosure gets talked about like a decision you make once. In the log it looks like a convergence.

Commit 1: the list row

The night started one level up, in the list view. Each row rendered a cluster of muted metadata: the item’s types joined with commas, an optional domain, an optional “value” badge, and a relative timestamp from formatDistanceToNow. Four competing bits of grey text per row, flex-wrapped so they reflowed on narrow screens into something that looked like a search-result footer.

We replaced all of it with one function, getSubtitle(item), that returns a single string. If the item is waiting on us, it says “Waiting on you.” Waiting on someone else, “Waiting on them.” Otherwise it falls back to the relative time, “3 days ago.” That one sentence answers the only question you ask while scanning a list: is this on us, and how stale is it?

The types, the domain and the value badge didn’t get deleted. They got relocated to the detail view, which is where the rest of the night went. Simplifying a UI moves information to the place where the question that needs it actually gets asked.

Commit 2: the status card down to four things

The detail view’s status card was the worst offender. It held the state icon and label, the waiting info, a state-select dropdown, the tuning sliders, the key dates, related items, artifacts, the history log, and the metadata.

This commit cut the card to the state icon and label, the waiting info, and the state-select. The sliders, the dates, the related list, the artifacts, the history and the metadata went into a Details collapsible that defaults to closed. The diff was 165 lines added and 145 removed on a roughly 310-line file. More than half the file moved while the net line count barely changed, because the work was relocating rather than adding or deleting.

The three that stayed answer “what state is this in, and what’s the one thing to do about it right now.” Everything we buried answers a question you have occasionally, on purpose, once you’ve decided to dig in. The sliders are important. You just don’t consult them on every glance.

Commit 3: the header had the same problem

At this point the toggle was still a small button that expanded the Details section. But the header above the status card still carried the item’s types, its domain, and its intent, right next to the title. We had buried metadata in the card and left a different pile of it in the header.

This commit pulled the header back to a title, a back button and a delete button. The types, domain and intent followed the rest of the metadata down into Details. The toggle got promoted from a small button to a full-width row, because it now sat on the seam between the four things you came for and everything else about the item. A small button undersells a seam like that.

This was the pass where the line got tested. The first time we moved intent into Details it felt wrong, because for some item types intent is closer to primary than buried. We left it buried anyway. Keeping it up top meant a special case in the header, and a special case is how you end up back at the wall of stuff. The line has to hold for every field or it doesn’t hold.

Commit 4: restyling the toggle

The last commit changed almost nothing about what was hidden. It restyled the toggle.

It had been a button sitting next to a Separator component. This commit turned it into a real divider: a horizontal line on each side flanking a chevron and the word “Details,” full width, no button chrome. We also deleted the now-unused Separator import, because the divider had absorbed its job.

This is the commit we’d defend hardest, and it looks the most like fiddling. A button says “this is a control, press it to do something.” A section divider with a chevron says “this is a seam in the page, and there’s more below it.” Those are different promises. Behind a button, the hidden content reads as controls we tucked away. Behind a divider, the same content reads as the next level down, available if you want it. The content and the toggle behavior are identical, and the story the page tells about itself is different.

We spent a whole commit on horizontal lines and a chevron because the page needed to admit it had hidden something. Deciding what to hide had taken the first three commits.

dxdev LESSON · paste into your AI coding agent
LESSON: Progressive Disclosure Is a Convergence, Not a Decision
SOURCE: dxdev.com/blog/progressive-disclosure-is-a-convergence-not-a-decision
WHAT HAPPENED: A detail view started as a wall of fields, all above the fold. One attempt to tidy it was not enough. It took four commits over two hours to find the real line between primary and buried. The first two commits relocated data. The third tested the line by pushing something across it that felt wrong, then leaving it there to see if a special case was really needed. The fourth committed an entire pass to making the toggle look like a seam rather than a button, because the affordance was telling a different story than the content structure.
THE RULE: Progressive disclosure is a convergence across multiple passes, not a one-time information-architecture decision; you find the line by pushing across it and feeling the pull to move it back.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Any detail or secondary view that renders more than 4-5 fields above the fold without a progressive disclosure boundary (collapsible, tab, drawer, or modal).
  2. Any toggle or expand control that uses button chrome (button element or styled-as-button) to hide a section that contains more than one or two minor fields (a section-divider affordance is more honest at that scale).
  3. Any list row that renders more than one piece of metadata alongside the primary label (multiple metadata fragments compete; a single context-aware subtitle scales better).
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.