C62Y

C62Y began in 2012 as a personal catalogue for workshop and field equipment. I had a folder of product sheets, a half-finished fixed-width layout, and a familiar early-career instinct: if I could make one desktop screenshot look convincing, the rest of the site would somehow follow.

The project I could actually finish

It did not follow. The catalogue was cramped on a phone, wasteful on a large display, difficult to scan with a keyboard, and expensive over the mobile connections I could test. A product image that looked harmless on broadband dominated the transfer on a phone. A comparison table designed around a wide monitor lost the model names as soon as the viewport narrowed. Navigation depended on hover even though touch devices were becoming ordinary.

I kept C62Y intentionally small. It was not a client commission or a commercial inventory system. I assembled a representative data set from public product sheets, wrote the templates, and asked a few friends who worked with tools to try common identification and comparison tasks. The narrow scope gave me room to study the browser itself instead of hiding behind a large application.

The real project was learning to replace a picture of a page with a set of rules.

The question behind the redesign

The obvious question was, “How do I make this desktop page fit on a phone?” That framing produced bad answers: smaller type, hidden columns, squeezed controls, and a separate mobile version with less information.

I replaced it with a harder question: which relationships in this catalogue must survive every presentation?

The model name needed to stay attached to the identifying image. Decision-making specifications needed to remain comparable. Reference dimensions and manuals could move later in the reading order, but they could not disappear. Navigation needed to remain navigation even when enhanced into a compact control. A visitor using a keyboard, a touchscreen, or an older browser still needed a complete document.

That change in question affected the data before it affected the CSS. I reorganized each entry into three groups:

• Identity: manufacturer, model, category, image, and availability note.
• Decision: the small set of specifications that distinguished plausible alternatives.
• Reference: dimensions, compatible parts, manuals, and secondary details.

The source order followed that hierarchy. The narrow layout could then be a straightforward reading sequence rather than a desktop composition folded into a column.

A baseline before a breakpoint

I wrote the baseline document as one readable column with ordinary links and controls. Images could shrink within their containers. Tables remained real tables. Product headings created a useful document outline. Nothing important required JavaScript to become visible.

Only after that baseline worked did I add wider arrangements. The first meaningful breakpoint appeared when the identity block and the key specifications could sit beside one another without compressing either. Another appeared when the comparison view could use the additional width to keep row labels and several products visible at once.

The CSS was unremarkable, which was part of the lesson:

.catalogue {
  margin-inline: auto;
  width: 92%;
}
 
.product-image {
  height: auto;
  max-width: 100%;
}
 
@media (min-width: 48rem) {
  .product-summary {
    display: table;
    width: 100%;
  }
 
  .product-identity,
  .product-decisions {
    display: table-cell;
    vertical-align: top;
  }
}

I used layout techniques with the support profile available at the time and treated newer capabilities as enhancements. The important decision was not a particular property. It was that the document did not depend on the enhancement for meaning.

Breakpoints came from content stress rather than a list of popular device widths. I slowly narrowed and widened the page, looking for the moment a relationship became hard to read. This made the layout less sensitive to the rapidly changing catalogue of phones and tablets. It also exposed where a component had been given an arbitrary width instead of a genuine constraint.

The comparison table became the most difficult interface in C62Y. Each row represented a property, and each column represented a product. On a narrow screen, there was no honest way to display all columns at a comfortable size.

My first attempt transformed every cell into a stacked card with a repeated label. It looked pleasantly “mobile” in isolation and made comparison exhausting. A person could read one product, but could no longer scan the same specification across several products. I had preserved the data and destroyed the task.

The final approach kept the semantic table and allowed horizontal exploration inside a bounded region. The first column remained visually anchored where the browser support allowed it; otherwise a repeated product heading helped preserve context. A short instruction explained that the table could be scrolled. The surrounding page never overflowed.

This was an early lesson in localizing compromise. Horizontal scrolling was not a universal layout strategy, but it was a responsible answer for one inherently two-dimensional object. The alternative was not purity. The alternative was lost comparison ability.

I tested the table with keyboard navigation, zoom, long model names, missing values, and units that could not safely wrap. Those cases pushed the content model toward explicit absence and consistent units instead of placeholder dashes whose meaning changed by column.

The compact navigation caused the first failure that changed how I thought about enhancement. I built a disclosure that hid the link list and revealed it from a button. In one older browser, the initialization script failed after the “enhanced” class had already hidden the links. The menu control appeared, did nothing, and the site had no usable navigation.

I reversed the sequence. The links were visible in the document. A small script tested the capabilities it needed, inserted the control, connected its state, and only then applied the compact presentation. If the script failed at any earlier point, the result was less polished and still complete.

The control used a button rather than an anchor with a dummy destination. Its text described the action. Expanded state was represented in both the DOM and the visual treatment. Focus stayed on the button so the next keyboard action was predictable.

I did not yet have today’s mature vocabulary or testing ecosystem for accessible disclosure patterns. I did have enough evidence to establish a durable rule: an enhancement earns the right to remove the baseline only after it has proved it can replace it.

Images were a delivery problem

The starting catalogue served one large image for each product and relied on CSS to resize it. On a narrow viewport, the image looked smaller but cost exactly the same. That gap between visual dimensions and delivered bytes became the first performance issue I could not unsee.

The responsive image platform was still unsettled in 2012, so I avoided writing the project as if modern srcset and picture support were already ordinary. Instead, the build generated a few carefully compressed derivatives and recorded their intrinsic dimensions. The server-rendered template selected a conservative default. Larger linked views remained available when inspection mattered more than initial speed.

This was not a perfect adaptive image system. It was a practical reduction in the default transfer with a clear escape hatch. More importantly, it turned image weight into something the project measured rather than a vague future optimization.

I created a small asset report beside every build. It listed each image derivative, stylesheet, script, and font by transferred size. I set limits for the initial catalogue view and treated a limit breach as a design question:

• Did the first view need this image at this resolution?
• Was a decorative asset carrying information that belonged in text?
• Could a script wait until interaction?
• Had one shared stylesheet accumulated rules for pages that were not present?

The questions were more valuable than the exact numbers. A budget connected presentation choices to the conditions under which somebody received them.

A performance budget before the term stuck

At first, I measured the home page only after it felt slow. That made performance a cleanup phase and encouraged small compressions after the architecture was already fixed.

C62Y’s later builds produced a plain report with three categories: document and styles, images, and scripting. I tracked request count as well as total bytes because mobile latency made many tiny resources expensive. A feature that crossed the working budget needed either a reduction elsewhere or a written reason to change the budget.

The budget was deliberately tied to a scenario: first catalogue view over a throttled mobile connection, with an empty cache. A single universal score would have hidden the actual experience I cared about. Repeat views and detail pages had different profiles.

I also learned not to confuse transfer with responsiveness. One script was small and still delayed interaction because it performed unnecessary DOM work across every catalogue row. I replaced repeated queries with server-rendered hooks and updated only the relevant region. The byte report did not find that problem; using the page did.

Performance became a product constraint with more than one measure: what crossed the network, when it executed, and whether useful content survived while it loaded.

My earliest visual checks compared the page against a few screenshots. Once the layout became fluid, a small set of target images was no longer enough. The most revealing defects lived between the familiar widths.

I wrote a manual test matrix around capabilities and tasks:

• Read and navigate with styles but no script.
• Use the compact navigation with keyboard only.
• Zoom text until labels wrapped several lines.
• Compare products at narrow, intermediate, and wide widths.
• Load the first view on a throttled connection with no cache.
• Open a product with a missing image or unusually long specification.
• Follow the content order with the layout visually removed.

I still checked representative browsers, but browser names stopped being the organizing principle. A browser could support media queries and fail in a different interaction. A device could be narrow and fast or wide and slow. Capabilities and constraints described the product more usefully.

The test matrix also gave me a vocabulary for intentional limitations. A legacy browser received the full single-column document and not the enhanced arrangement. That was a supported experience, not a failed imitation of the most capable browser.

The catalogue model became part of the interface

The layout work exposed inconsistent source data that the old fixed canvas had managed to hide. One product recorded weight as a number and unit, another stored a formatted sentence, and a third embedded the value in a downloadable sheet. Missing fields sometimes meant “not applicable,” sometimes “unknown,” and sometimes “not yet entered.” The page rendered all three as an empty cell.

I introduced a deliberately small normalized model. Measurements carried a value, unit, and optional note. Enumerated properties used a controlled list while preserving the manufacturer’s wording as reference text. Absence had a reason: not applicable, not supplied, or not yet verified. This made the templates less clever and the comparison view more honest.

Normalization did not mean pretending different products were perfectly comparable. A specification could declare the conditions under which it was measured. The interface could then keep two values visible while warning that their test conditions differed. I learned that a tidy table can imply equivalence more strongly than its data supports.

The import process generated a review page for unknown units, duplicate models, implausible values, and missing identity fields. I resolved those cases in the source rather than adding template exceptions. That separation mattered: presentation code should decide how to communicate known data states, not quietly repair ambiguous data every time the page renders.

This work broadened the project again. Responsive design was not only about CSS. A flexible presentation depended on content with explicit structure and uncertainty. Once the data could say what it knew, the narrow layout no longer needed visual tricks to disguise holes.

Release notes for a one-person project

Because C62Y was personal, I initially treated deployment as copying the latest folder to a small server. That habit created a peculiar kind of uncertainty: I could see a defect online and could not always say which local state had produced it. A stylesheet might be new while a template upload had failed. Browser caching made the mixture harder to recognize.

I added a simple build identity to the page footer in development and emitted every release into a separate directory. The deployment step uploaded the complete directory, checked a handful of important pages, and then changed which directory the web root referenced. It was an early, modest version of the immutable-release pattern that later became central to M31V.

The smoke checks did not try to prove the whole catalogue correct. They checked that the index rendered, a product detail contained its identity and image, the comparison route returned a table, the stylesheet URL matched the build manifest, and a deliberately missing route produced the right response. When a check failed, the current release remained untouched.

I kept short release notes even though I was the only maintainer. Each note named the user-visible change, the browsers or scenarios retested, a budget difference, and any limitation introduced. That record stopped me from rediscovering the reason for a strange fallback months later. It also made the project’s progression legible: early releases talked about viewport widths; later releases talked about information priority, missing-data semantics, and failure-safe enhancement.

The discipline was light enough to survive. A process that required a separate operations platform would have overwhelmed the project. One script, one manifest, a few checks, and a brief note were sufficient to replace memory with evidence.

I tested outdoors because the catalogue’s subject made field use plausible, even though C62Y was not deployed for a real service organization. Low contrast that looked refined at a desk became weak in glare. Small touch targets that passed a visual review became annoying while holding a phone in one hand. A horizontally scrollable region needed enough boundary contrast to remain discoverable without resembling a disabled panel.

I also tried the page with images disabled and with a high minimum font size. Product identity could not depend on the photograph, and a layout could not assume that text occupied the dimensions I had chosen. The tests turned several purely visual labels into visible text and removed fixed heights from summary blocks.

Print remained relevant because manuals and comparison sheets were often carried into workshops. A modest print stylesheet removed navigation, expanded truncated links, avoided splitting short product summaries, and let the comparison table use landscape paper where available. It did not recreate the screen design. It preserved the task in a different medium.

These tests made the project feel less like a collection of responsive tricks and more like a study of robustness. The same content had to negotiate width, light, input method, connectivity, user settings, and paper. No one presentation deserved to be the hidden source of truth.

Corrections that changed the project

The first redesign hid secondary specifications behind a “more” control on small screens. Testing showed that some of those supposedly secondary values were exactly what a field user needed. I had mistaken visual quiet for task priority. The content hierarchy changed so reference information moved later without becoming secret.

I also chose breakpoints too early. The initial values matched devices on my desk, and awkward gaps appeared as soon as the font size changed or a model name grew. Re-deriving them from content pressure made the rules more durable.

The navigation failure exposed an even deeper mistake: I thought progressive enhancement meant writing a fallback after the preferred version. In practice it meant constructing the preferred version from a dependable baseline, in an order where partial execution remained safe.

Finally, the asset budget became briefly theatrical. I spent time reducing a tiny icon while one product photograph dominated the page. The report needed to lead to decisions by impact, not reward activity because a file was easy to optimize.

C62Y did not need a novel framework or a dramatic launch to matter. It gave me a repeatable way to think about interface work:

1. Start with the information relationship.
2. Put the complete task in a durable document order.
3. Add layout when the content can use it.
4. Add behavior only after it can fail safely.
5. Treat delivery cost as part of the design.
6. Test the spaces between named devices and happy paths.

The visible outcome was a catalogue that adapted without maintaining a separate mobile edition. The more important outcome was a shift in what I considered the designed object. I was no longer designing a 960-pixel picture. I was designing rules that negotiated content, capability, and constraint.

That shift prepared the next project. T04P would keep the responsive shell, but add a harder dimension: time. A layout could be visually correct while the data inside it was old. C62Y taught me to expose spatial constraints. T04P forced me to expose uncertainty about the present.

Where the catalogue still gave way

The image pipeline was conservative and could not select perfectly for every device. Dense comparison still required horizontal movement on small screens. The personal data set did not reproduce every inconsistency of a real industrial catalogue. Older browsers received the complete baseline rather than every enhanced layout.

Those limits were acceptable because the project named them. C62Y’s purpose was not universal optimization. It was to build one coherent catalogue that remained understandable when width, input method, script execution, image delivery, and browser capability changed.

Technology: semantic HTML, CSS media queries, server-rendered templates, small progressive-enhancement scripts, generated image derivatives, keyboard and zoom test protocols, and a build-time asset budget.