Henry's Room · Chapter Three: From Working to Feeling Right

Chapter One recorded the move from an idea to a real website.

Chapter Two opened the machinery: publishing, deployment-aware notifications, data preservation, failure, and recovery.

By then, the site was no longer a few empty pages.

I could write. Readers could read, comment, and subscribe. The admin could manage content and reconcile tasks. A feature list would have offered plenty of reasons to stop and use it for a while.

Yet I still opened the home page, watched it, and felt that something was missing.

Not a button. Not another service.

Why did it still feel like a picture placed on a screen? Why did animation sometimes feel like nothing? Why did a supposedly more considered redesign feel worse than the original?

This chapter records how, after making the site usable, I began deciding how it should feel and how it could remain itself.

Most of this happened on October 25, 2026. This is an experience retrospective, not a redesign tutorial or a final acceptance report.

1. Why Did a Feature-Rich Website Still Feel Unfinished?

Early on, the solution was obvious: add missing capabilities.

Comments, browsing, archives, tags, reading statistics, subscriptions. Each answered a real need.

But their arrival did not automatically produce coherence.

Some entrances looked isolated. Some pages seemed built at different times and placed under one navigation. Each could be defended individually; together they did not quite feel like one room.

It was difficult to turn that feeling into a precise request.

“More premium” was vague. “More animation” could mean everything jumping together. A single spacing problem was easy to discuss; the overall character was not.

That led me toward more systematic design guidance.

Two design skills entered the project: sets of instructions for AI-assisted work, covering how to understand a page, inspect typography and interaction, and avoid familiar template habits.

They were not one-click themes, and installing them could not manufacture taste.

Still, I hoped they would help identify the distance I could feel but not explain.

2. A More Designed Version That I Rejected

I initially allowed considerable freedom.

Use the two skills as the main guide. Some original decisions could go. Build locally first; I would look before anything went live.

My reaction to the result was direct:

It looks awful. I prefer the old one.

That did not mean nothing in it was good.

It had clearer composition, reorganized surfaces, and a more deliberate editorial order. But it moved away from what I wanted to keep.

The centered opening, familiar colors, article covers, and relaxed atmosphere were becoming a different kind of publication.

It might suit another site. It did not feel like Henry’s Room.

A design can follow a method and still be wrong for a project.

This was not a blank page awaiting a style. It already held content, habits, and an identity I valued.

An upgrade that first made the room feel less mine needed reconsideration.

We returned to the original visual foundation and used the skills to improve interaction, motion, readability, and calibration.

The rejected version never went live.

It was useful in one respect: it clarified the brief.

I did not want a different website that looked more professional. I wanted this website to become more fully itself.

3. “Be More Restrained” Was Not the Answer This Time

The first motion refinement was subtle enough that I could barely see a difference.

I asked for more. Then for greater confidence: not just segmented rises and staggered entrances, but a front end with life.

That can sound inconsistent with abandoning the always-moving background.

But I had not abandoned motion.

I disliked background activity that heated the device without helping anyone read.

This time I wanted:

A coherent entrance when the page opens.
Covers that respond to where the pointer approaches.
A category selection that travels rather than abruptly changing color.
A gentle indication that a subscription field is there.

Each relates to an action.

The home-page opening became slower and larger. Other titles acquired their own entrance. Featured writing, friends, tags, and the footer gained perceptible responses.

The page frame should not contract or shake with them. Reading should not wait for a performance to end.

Life meant feeling a relationship with the page, not seeing everything move forever.

4. Moving Is Easy. Moving Convincingly Is Hard.

Many refinements could not be described as simply having or lacking animation.

Direction, start, speed, and ending could turn the same idea into a different experience.

A Title Should Grow Upward, Not Flip Forward

Outside the home page, I wanted large headings, including article titles, to appear in reading order, rising from below.

The first version looked more like letters flipping toward me.

The descriptions sound similar. The results are not.

A flip draws attention to deformation. Rising should preserve the letter itself as it crosses an invisible lower edge.

The revised titles stayed upright and moved only upward in sequence. English words, punctuation, wrapping, copying, and accessible text also needed to survive.

I did not have to know the implementation first. I did have to say when the feeling was wrong.

Not Every Button Should Jump Up

Subscription controls, footer links, and tags initially shared a slight hover lift.

One instance was fine. Repeated everywhere, it became monotonous.

I wanted attraction: a small movement toward the pointer, followed by a natural return, without making the control difficult to click.

Friend cards needed depth like the featured cover. Their shadows had to support the impression of floating. Tilt without depth looked like twisting in place; heavy shadows fought the clean page.

None of this belonged on paragraphs of reading text. Those should stay still.

Why Did an Up-Right Arrow Move Down?

“Browse all writing” pointed up and right, but moved downward on hover.

It was a small mismatch with a clear lesson: feedback has meaning.

An onward link should not inherit the gesture of an entrance that leads down the same page.

Later, a back arrow on the 404 page looked too high. The graphic was symmetrical; its placement alongside the text was not.

Both problems showed that detail is not endless complexity. It is keeping simple things from contradicting each other.

5. The Subscription Area Needed One Breathing Edge

Subscription was a useful example of “present” not meaning “right.”

I wanted the form to attract a little attention without remaining an inert box at the bottom.

The first cue was too subtle. A stronger envelope treatment became a circular decoration I disliked.

The request finally became specific: put a breathing light around the input.

Not scaling the whole card. Not flashing the heading. Not another floating circle.

The field should retain its size and position while its edge gently brightens and fades.

I then asked for a faster rhythm.

At the stage described in this chapter, the cue was finite: a few cycles after entering view, stopping when the reader focused, pressed, or typed into the field.

The purpose of attention became clearer.

It was not to justify a larger ornament. It was to reveal a useful action at the right moment.

A form should invite someone to begin. It does not need to keep announcing that it can animate.

6. Confidence Must Not Bring the Fan Problem Back

Stronger motion did not invalidate the earlier performance lesson.

I had already lived with a blog that made the computer warm. I did not want its new life to restore that problem.

Effects needed boundaries.

Entrances end. At this stage, the breathing cue ended. Buttons and cards respond to interaction and return afterward. Hidden pages and discarded features stop work.

A phone has no hovering mouse. Reduced-motion preferences should yield complete, stable content.

These requirements sound less exciting than “be bolder,” but they decide whether boldness can stay.

There were also differences between implementation and reality.

A scroll-linked animation in source was not proof that the built CSS actually ran in the browser. An animation name was not evidence of the expected computed result.

We encountered that gap and had to inspect the finished page.

Checks do not mean I can skip looking. My liking the result does not mean every device is verified.

Responsive emulation, themes, and reduced-motion checks matter. They do not stand in for long-term use on all phones and tablets.

I can say the result moved closer to what I wanted. I cannot responsibly call motion and performance permanently perfect.

7. Why Thirty Thousand Lines Did Not Belong in an Arbitrary Corner

I wanted the development journal to show the project’s source line count.

It was partly commemorative: a few pages had grown into writing, comments, subscriptions, mail, administration, and tests.

The count at that stage was 33,859 non-empty source lines across 245 files.

It covered maintained code and tests, including comments, but excluded articles, dependencies, build output, and duplicate generated entries. It was neither a handwritten-line count nor a quality score.

The number was correct. Its first placement was not.

Stats stacked on the right stretched the page and upset the balance. It felt bolted on.

The revised layout separated title, introduction, and a full-width row of commits, milestones, development days, and source lines. Methodology moved into an expandable explanation.

Readers saw a journal, not a code dashboard inserted into it.

AI can quickly turn “add a source count” into a number inside a card.

But the real requirement was for that information to belong without interrupting the reading order.

Implementing a requirement and integrating it into a product are different jobs.

8. A Successful Build That Still Looked Failed

Near the end, an old kind of problem returned.

Chapter One failed its first build and succeeded on retry. Publication history showed success, yet the article list still said failed.

The article existed publicly. The task history had the result. The screen I looked at most often disagreed.

Chapter Two already covered the mechanics. Here the point is the user’s uncertainty.

Which source should I trust? Should I publish again? A polished progress bar cannot repair contradictory facts.

Investigation found an unreconciled failure state. Dismissing success could also let an older stored record restore that stale failure.

The fix was not deleting history or hardcoding this article as successful. Current state needed to follow the article’s actual version and build attempt, rejecting obsolete results.

That fix shipped with the phase. Still, isolated checks and the author’s individual production acceptance remain different evidence.

This belongs in a chapter about experience.

Experience includes whether the page’s statements can be trusted.

A correct failure message may matter more than an attractive success effect. Once work succeeds, the UI should also let it finish.

9. Learning to Describe Feelings, Not Just Add Features

Much of my feedback was untechnical.

“Too ugly.”

“I cannot see a difference.”

“It flips. It does not grow.”

“It feels forced in and unbalanced.”

Taken out of context, it might sound like constant rejection.

In practice, it was a process of naming a feeling and locating its cause.

I did not have to learn the entire vocabulary of design before asking for something uncomfortable to improve.

Feelings still do not replace judgment.

Bolder cannot obscure content. Attraction cannot make buttons evasive. Subscription cues should become quiet once a reader starts.

That also changed my expectations of AI collaboration.

AI accelerates experiments and helps inspect details. It does not automatically know which version belongs to my room.

Skills provide methods, not personal decisions. I still have to open the page, use it, reject a direction, and look again.

A longer prompt cannot entirely remove that work.

10. At the End, It Felt More Like Somewhere People Use

Henry’s Room kept its identity. A redesign did not replace the articles, comments, or subscription relationships.

The familiar covers, themes, name, and “Stay curious. Keep making progress.” remained.

What changed was the care of its responses.

An opening when entering. Feedback when approaching. Continuity between choices. Quiet while reading. An ending when work finishes.

I would not call these changes a sudden transformation.

Most are small. Some are noticed only when wrong. Together they make separately built pages feel more like a place.

If Chapter One made the website exist and Chapter Two made it worth maintaining, Chapter Three asks:

Once the system works, do I still want to enter and pay attention to how it treats every reading session and every action?

Now I do, more than before.

I do not have another enormous checklist ready. Some details need real use. Some effects may later be removed.

The important thing is leaving room to adjust, while remembering the directions already tried and why they were abandoned.

Making a room alive does not mean making every part move. It means giving every response a reason.

Stay curious. Keep making progress.

Open-Source Projects and Third-Party Components

This chapter records the site’s development and choices. The following distinguishes design tools, foundational projects, and services from original work.

Taste Skill

Project: Taste Skill, using design-taste-frontend.
Author: Leonxlnx and contributors.
Upstream: Leonxlnx/taste-skill.
License: MIT.
Use: development guidance for visual consistency, interaction, and motion review, not an additional front-end runtime.
Note: the redesign decisions here do not imply upstream endorsement or guarantees.

Impeccable

Author: Paul Bakaus and contributors.
Upstream: pbakaus/impeccable.
License: Apache License 2.0.
Use: product constraints, interaction, motion, accessibility, and detail review.
Note: tool feedback is not author acceptance or proof of every-device, long-term performance, or complete accessibility verification.

Astro and Official Integrations

Projects: Astro, @astrojs/rss, @astrojs/sitemap.
Authors: Fred K. Schott, the Astro team, and contributors.
Upstream: withastro/astro.
License: MIT.
Use: pages, content, RSS, and sitemaps. This phase refined the existing site without changing frameworks.

Existing Components and Development Tools

Marked: Christopher Jeffrey, the MarkedJS team, and contributors; markedjs/marked; MIT and notices. Markdown parsing and previews.
Turndown: Dom Christie and contributors; mixmark-io/turndown; MIT. Visual editing and Markdown conversion.
js-yaml: Vitaly Puzrin, Nodeca, and contributors; nodeca/js-yaml; MIT. Build-time metadata.
resvg-js: its maintainers and contributors; thx/resvg-js; MPL-2.0. SVG-to-bitmap tooling.
Node.js: its maintainers and contributors; nodejs/node; core MIT with separate notices in the official license. Builds and tests.
Python: Python Software Foundation and contributors; python.org; primarily PSF License Version 2. Deployment guards, backups, and recovery.
Git: its maintainers and contributors; git/git; GPL-2.0. Version history.

This is not a complete software bill of materials. Actual versions, the lockfile, and each component’s accompanying license determine obligations.

Cloudflare, GitHub, and Resend

Providers: Cloudflare; GitHub and GitHub Actions; Resend.
Sources: Cloudflare, GitHub Actions documentation, Resend documentation.
Use: hosting and dynamic services, source history and deployment, email verification and notifications.
Note: third-party platforms are not original open-source components. Quotas, pricing, terms, and individual Action licenses remain distinct.

Browser Capabilities and Design References

Motion uses native HTML, CSS, and JavaScript. Platform capabilities are not inventions of this site, nor guarantees of identical behavior across browsers.

Apple products remain a reference for space, hierarchy, and interaction. This is not an Apple product and has no official affiliation or endorsement.

This Project and AI Assistance

Henry initiated and maintains the project. OpenAI Codex assisted development and preparation. Actual feedback and final direction came from using the project. AI and design tools do not replace factual checks or upstream rights.

At writing, the repository was private and had no project-wide open-source license. Open-source dependencies do not make all site code, articles, and media freely redistributable.

No passwords, access tokens, backup keys, or visitor data appear here.

Project and article by Henry. Recorded through October 25, 2026.

Earlier chapters: Chapter One · Chapter Two.