Mycelium

The Rest

The Login Is a Gate

[SEEDED — compose the two fragments below into one piece]

Fragment 1 — the gate (dialogue, 2026-04-30)

We have a little problem of hierarchy. Lots of semi-field looking elements.

YOUR NAME you@somewhere.com

For example. And a "PENDING" tag that might look like a button. And the actual form of the login.

I mean — really think of this component. And the states of it. What the user expects in each signup mode. Who is it? What he wants to do? Why he sees this page right now? Where did he attempt to go?

This is a gate, isn't it? Blocking my way to go where I want. Like "hey stop, who are you?"

Or if it's open for everyone it's like "yo yo yo, do you have an account already?"

Really think of all of this and do improvements.

Two specific hierarchy failures stacked on top of each other:

1. The decorative elements looked like operational fields but weren't. A fake promise. Type-in-shaped things you can't type into. Button-shaped things you can't press.

2. The decorative elements were sitting at the same hierarchical weight as the actual form. No visual demotion. No "I'm context, not action." Primary and secondary competing for the same eye, in the same column, at the same scale.

Either failure alone is a problem. Stacked, they're a trust collapse — the user's pattern-matching fires on the wrong elements, fails, and now the rest of the screen feels unreliable too.

Context: the component has three modes — OPEN, REQUEST, INVITE.

Same component. Three different gates. Three different characters.

The hierarchy breaks because the design is trying to be neutral across all three. But neutrality is the enemy here. Each mode has its own posture, its own tone, its own set of things that matter and don't matter.

You can't design the component once. You design it three times — and then find what they share.

Fragment 2 — density matches commitment (principle, same conversation)

Okay, we can do better.

First, dynamically condition the heck of the actual form and action part.

Single button "login with Google" (works both for signup and login when free-for-all).

Try being one option at a time, with always an option to CHOOSE to do something different.

Like — show only the email field. When done, next step is password.

When invite-only, put the 2 options on the same screen so a single click does any path or journey.

Really plan this through. All paths and scenarios. The matrix:

signup × login (action) email-pass × Google (method) open × request × invite (mode)

= 3 × 2 × 2 = 12 paths.

Three principles fall out of this:

1. One decision at a time, with a visible escape hatch. Not a wall of options. Not a single forced path. A focused path with a clearly-reachable exit. The user is doing one thing at a time but can always switch lanes.

2. Density matches commitment. When the user is known and expected (invite-only — they have a code, they came here on purpose), collapse the choices onto one screen — single-click any path. When the user is unknown and could leave at any step (open signup), unfold the form one decision at a time so each step is small and abandonable.

3. The system absorbs complexity the user shouldn't feel. "Continue with Google" handles signup and login because the system doesn't care which one it is. The user doesn't pick a verb — they pick a method, and the system figures out the rest.

The matrix is the artifact. Don't design the screen — design all 12 cells, and let each one earn its own posture.