Small input hints that make web tools easier to use

I maintain the six projects linked in this note. They make useful examples of a recurring interface problem: a short label can hide an important assumption about units, coverage, eligibility, or the result.

The snippets below are proposed copy patterns for developers to adapt. They are separate from the live wording on each site, and they are not results from a user study or a complete product test.

1. Explain what can be represented

A Unicode text tool may use a conservative mapping instead of converting every character. A reader needs to know which input stays unchanged and whether the result suits the destination.

For an interface like my superscript generator, which lists the characters it leaves alone, a useful hint would be:

Some characters may remain unchanged in this mapping. Review the output and its character coverage before copying.

Keep the preview available beside the explanation. A coverage note helps the reader decide whether the result suits a particular name, formula, or caption; it does not establish compatibility with every destination app.

2. Put the interpretation beside the numbers

A ranking page may mix a qualitative recommendation with a numerical comparison. Readers need to understand which question each one answers.

At the tier list where the letter grades are labelled as opinion, the unofficial fan guide includes tier information and starter comparisons. A reusable explanation for that kind of interface is:

Read the tier notes for qualitative context. A raw-stat comparison answers a narrower question and does not capture every interaction in a run.

Put that distinction next to the relevant section. It prevents a score from acquiring a stronger meaning simply because it has a number attached to it.

3. Show the applicable limit at the point of selection

A bulk tool can have different limits for different account states. Show the limit that applies to the current reader.

For a workflow like the batch photo watermark tool where the limit depends on your account, a developer-facing message template could be:

Selected {count} of {limit} photos for this batch.
Your current account limit is {limit} photos per batch.

Here, the braces describe values your application should supply. Keep them tied to the same configuration that enforces the limit. If a new selection is rejected, explain the next useful action, such as reducing the selection, while preserving only state your implementation actually retains.

4. Separate eligibility, processing and retention

Media conversion involves several decisions: whether the source is appropriate to process, whether it fits the service's limits, and how long a completed result remains available.

For a service page such as my YouTube to MP3 converter and its stated limits, keep these messages close to their relevant actions:

• Before submission: the supported source and current duration limits, together with a clear rights confirmation.
• During processing: the status that the service actually reports.
• After completion: the download's actual expiry and the available deletion controls.

Avoid promising automatic retries or preservation of a job unless the implemented behavior supports that promise. A helpful failure message describes the known state and the available next step.

5. Name the unit, then explain the nearby distinction

An image's dimensions and its encoded file size measure different things. A reader trying to meet a byte limit may choose a width control and expect it to enforce that limit.

For a tool like the GIF resizer and its stated limits, clear field labels and a small hint can keep the distinction visible:

Width (pixels)
Height (pixels)
Pixel dimensions and file size are different measurements.
Check the exported file size against your destination's limit.

This explains what the controls address without predicting a compression percentage or a guaranteed export size.

6. Distinguish mixed units from decimal notation

Feet and inches are a familiar example of a formatting trap. Eight feet six inches is 8.5 feet, because six inches is half a foot.

For a feet-and-inches calculator that says what a bare number means, a reusable input hint is:

No unit? Bare numbers start as inches. Check the unit before calculating.

Keep the unit visible beside the input and beside the result. The linked page describes a separate length calculation; calculating room area is a different task.

A small review before shipping copy

For each hint, check that it:

1. Appears beside the control or result where the reader needs it.
2. Names the relevant unit, limit or assumption.
3. Uses the same current values as the enforcing implementation.
4. Describes supported behavior without adding guarantees.
5. Gives a practical next step when the current input cannot proceed.

Then test the implementation separately: unsupported characters, account-specific batch limits, rejected selections, failed jobs and mixed-unit inputs are behavior tests. Clear wording helps readers make decisions; it needs working behavior underneath it.