Use case

A web app forthe phone first.

When users are on phones, the narrow width is the real one. Adams checks it on every change.

Lite and Pro
// the problem

What goes wrong

Desktop hides the problemsTouch targets, safe areas and long labels only fail on a small screen. You will not see them on a big monitor.
Every change can break the layoutA new field in a form can push a button off screen. Without a check, you find it when someone complains.
// what adams does

What Adams does

Checks at 375 firstPro: phone width is the first thing reported, then tablet and desktop.
Holds a standing rulePro: coach keeps "check phone width" as a rule every session receives.
Protects the keysLite: secrets in client code are caught before commit.
// worked example

An example

A form after a change

Illustrative output.

~/project~/your-project · example
$ adams check http://localhost:3000/signup
375px: submit button is below the fold on load
375px: label "Confirm your email address" wraps
Shortening the label, tightening the form
✓ 3 widths checked, no problems
// faq

Questions

Does it test on a real phone?

No. It renders at phone width in a headless browser. Check on a real device before launch too.

Is this a native app tool?

No. It is for web apps and pages.

What is Pro here?

The width checks and the coach. Secret guards are Lite.

// related

Keep reading