40 commits to make three identical screens: why invisible standardization changes everything

Three screens. Tasks. Memos. Events. All three essentially display the same thing: a title, content, people who have access to it, a parent folder, reminders, tags. And yet, in TAMSIV, these three screens each had their own layout, their own section order, their own way of displaying the same information. 40 commits later, they finally look alike. Here's why this invisible standardization changes everything.

Why standardize three screens that were already working

It's a legitimate question. If the three screens were already working, why spend 40 commits making them identical? The answer is one word: cognitive load.

When you use TAMSIV daily, you switch from a task to a memo then to an event, sometimes in less than a minute. If each screen displays the same information in a different order, your brain has to reorient itself with each transition. You look for the tag at the top of the task, you find it at the bottom of the memo, you can't find it at all on the event. Multiply that by 20 or 30 consultations a day, and the invisible friction eventually takes its toll.

Conversely, when the three screens look alike, your brain learns once where everything is. The title is at the top. The access tree is just below. The parent folder follows. The tags come next. The main content occupies the center. Reminders and history go to the bottom. Three screens, one mental map.

The access tree: two branches, zero ambiguity

The most critical information on a detail screen is "who sees what." Before the refactor, each screen answered this question in its own way. The task screen listed an assigned folder with a badge. The memo screen displayed a flat list of members. The event screen showed a "Participants" section detached from the rest.

The new TaskAccessTree component replaces these three logics with a two-branch structure clearly labeled:

• "Owner" branch: the person who created the task or memo. Minimal display, avatar plus name, nothing more.
• "Shared groups" branch: each group in which the content is visible, with the list of concerned members as stacked avatars. If the task is shared in three groups, three sub-branches are displayed.

The advantage of this two-branch structure is that it answers two different questions without mixing them up. Who is the owner: branch 1. Who sees the content in addition to the owner: branch 2. No possible confusion. A user can understand at a glance who has access, without reading a single line of text.

When the breadcrumb hierarchy disappears

Another refactor detail, invisible when everything is fine but horrible when it appears: the parent folder breadcrumb. If your task is stored in Family > Groceries > Supermarket, the screen displays this path at the top as a breadcrumb. Perfect.

Problem: some tasks are not stored in any folder. They are at the root. The breadcrumb then displayed an empty space, then an arrow, then nothing, then the title. A visual artifact that gave the impression that the screen was poorly loaded.

The fix is trivial when you think about it: if the list of parents is empty, we don't render the component. Two lines of code, one less visual bug, and the screen breathes. This is typically the kind of polish that no user will consciously notice, but everyone will subconsciously feel as "this app is well-cared for."

Hashtag-prefixed tags

Tags were displayed without prefix or header. A flat list of words placed below the content. Visually, they blended into the main text and were not immediately identified as tags.

The new rendering adds two simple things:

1. A "Tags" header above the list, so the eye immediately knows what it's about.
2. A # prefix before each tag, a convention borrowed from social networks that everyone knows.

The result is immediate: a task with five tags now displays a clear line like #urgent #groceries #weekend #family #meal, impossible to confuse with normal text.

The same section order on all three screens

On each screen, the sections now follow this order:

1. Title and status (or date for an event)
2. Access tree (TaskAccessTree)
3. Assigned parent folder (with the same visual card everywhere)
4. Tags (with header and # prefix)
5. Main content (description, memo text, event details)
6. Reminders and recurrence (if applicable)
7. Attachments (if present)
8. History and activity (comments, reactions)

Switching from a task to a memo then to an event now provides total visual continuity. You learn once where to click, then you learn nothing more. A gain of a few milliseconds per consultation, which becomes minutes per day and hours per month for a regular user.

Invisible features make apps you keep

No one will launch TAMSIV tomorrow thinking "oh great, the task detail screen is aligned with the memo one." Invisible features are not announced. They are not sold. They are felt.

This 3-day, 40-commit sprint produces no marketing screenshots. No new buttons to show. No cinematic animations. And yet, this is exactly the type of work that makes the difference between an app you install and forget, and an app you keep and recommend.

The previous 10 days were a complete transactional email system. The following 3 days were the standardization of the three detail screens. And tomorrow, it will be something else just as invisible. The app grows, but always silently.

What this refactor will enable later

The other benefit of this standardization is that it paves the way for future features much faster. When the three screens share the same structure, adding a new section (for example, an "automatically translated" box for a voice memo in a different language) is done once and applies everywhere.

Before the refactor, adding a cross-cutting section meant coding it three times, with three style variants and three locations to negotiate. Afterward, it's a shared component that injects into all detail screens. The marginal cost of adding a new feature is divided by three.

This is the real hidden beneficiary of this week: not today's user who will just see a more consistent app, but the solo developer who will build the next 40 features in three times less time.

And meanwhile, 22 old SEO redirects

In parallel with the screen standardization, I fixed a redirection problem on the site. The first blog translation passes had left 22 obsolete slugs in DE, ES, IT, and PT, which returned 404s on Google. Each obsolete slug is now permanently redirected (301) to its current version.

The x-default file of the sitemap is also corrected, so that search engines understand which is the canonical version of each article when the user's language cannot be determined.

These are 22 lines in a Next.js redirection file, 22 fewer indexing errors, and potentially 22 visitor paths found instead of lost.

Frequently Asked Questions

Does standardizing detail screens make the app faster?

Technically, marginally. Shared components are rendered more efficiently in cache, and the JavaScript bundle decreases by about 3% thanks to code deduplication. But the real gain is cognitive, not technical: the user feels faster because they navigate with less mental friction.

Why wasn't this standardization done sooner?

Because as long as the three screens were evolving separately and we didn't yet know which sections would emerge as cross-cutting, trying to standardize would have been premature. Each screen first had to discover its own needs, then extract common patterns once they were stable.

What impact does this have for someone using TAMSIV for the first time?

A newcomer learns the task screen first. Before the refactor, they then had to re-learn the memo screen and the event screen. Afterward, they instantly recognize the elements, and their learning curve goes from three stages to one. Onboarding is divided by three in perceived time.

Will a user notice the difference?

Probably not consciously. The refactor is designed to be invisible. But if you ask a user who used the app before and after to name what changed, they will often say "the app feels more consistent" or "I find my information more easily," without being able to explain exactly why.

Did the refactor break anything in the mobile version?

A complete audit was done after deployment. No functional regression detected. The transition animations between screens were even slightly smoothed because shared components allow for more predictable rendering by React Native.

Available on the Play Store, 6 months and 780+ commits

TAMSIV is available in production on Google Play since April 2nd. Free, 6 languages, solo dev. The app continues to evolve every day, mostly silently. It's the invisible 80% that keeps it installed.