Designing a No-Tracking Mixing Calculator for Product-Specific Ratios

Disclosure: I work with Hangzhou Karn New Building Materials Co., Ltd. (KARN), a manufacturer and exporter of powdered wallpaper adhesive. This post explains the engineering choices behind a free tool we published; it is not an independent product review.

Small calculators are easy to build and surprisingly easy to make unsafe. A form with two inputs and a multiplication operator can still mislead users if it invents a default ratio, hides the unit basis, accepts invalid values, or turns a product-specific instruction into a universal recommendation.

We recently built a static Wallpaper Adhesive Mixing Ratio Calculator and Sample Test Record for decorators and technical buyers. The code is available in the public GitHub repository.

This article focuses on the design constraints that mattered more than the arithmetic.

Requirement 1: never recommend a universal ratio

The first requirement was a negative one: the application must not tell users which ratio to use.

Wallpaper adhesive powders are supplied with product-specific instructions. A number remembered from another pack, supplier or formulation is not a safe default. The interface therefore requires users to enter the ratio printed on the exact product label or technical data sheet.

The calculator works with a declared 1:X mass basis:

water mass = powder mass × X

If a label states 1:25 and the test portion is 200 g, the calculation is:

200 g × 25 = 5,000 g water

That is an arithmetic example, not a recommendation for a different product. The distinction is repeated in the UI because a correct formula can still communicate the wrong instruction.

Requirement 2: make the unit basis explicit

Many calculation errors come from mixing mass and volume without saying so. Our tool labels both powder and water as grams and explains that the result is a mass calculation.

For water under ordinary test conditions, users may treat grams and millilitres as approximately equal for practical measuring, but the calculation itself remains mass-based. The interface does not silently convert other liquids or promise laboratory precision.

The implementation keeps the computation small and inspectable:

function calculateWaterMass(powderGrams, ratioParts) {
  if (!Number.isFinite(powderGrams) || powderGrams <= 0) {
    throw new Error('Powder mass must be greater than zero.');
  }

  if (!Number.isFinite(ratioParts) || ratioParts <= 0) {
    throw new Error('Ratio parts must be greater than zero.');
  }

  return powderGrams * ratioParts;
}

There is no hidden lookup table and no server response that can change the ratio.

Requirement 3: validate before calculating

HTML input constraints are useful, but they are not the whole validation layer. The application checks parsed numeric values again before producing a result.

We reject:

• empty inputs;
• zero or negative values;
• NaN and infinite values;
• values outside the form's documented operating range.

Error messages explain which input needs attention. The result area does not display stale output after an invalid submission.

For formatting, we avoid false precision. A field calculation for a powder sample does not become more scientific because the UI prints twelve decimal places.

Requirement 4: preserve the test context

The useful output is not only the water number. A buyer comparing samples also needs to know whether the preparation can be repeated.

The printable record captures:

• sample and batch reference;
• powder and water quantities;
• water temperature;
• mixing duration and method;
• rest or hydration time;
• room and wall conditions;
• wallcovering or test-panel reference;
• observations and comparison controls.

This turns the calculator into a small QA aid rather than a one-time number generator.

The domain workflow behind those fields is described in our repeatable sample-test protocol and wallpaper adhesive technical-document workflow. The latter separates the roles of TDS, SDS/MSDS and COA instead of treating the acronyms as interchangeable attachments.

Requirement 5: run without tracking or accounts

The tool is a static web application. It does not require:

• registration;
• cookies for the calculation;
• analytics scripts;
• third-party fonts;
• a database;
• an API request.

All entered values remain in the current browser page unless the user chooses to print the record. This is useful for sample and batch references that a buyer may not want to send to an unrelated analytics provider.

Static hosting also makes the operational model easy to audit. The public repository, deployed page, robots.txt, sitemap and verification key can all be inspected directly.

Requirement 6: keep the page accessible and printable

The form uses real labels, logical heading order and keyboard-reachable controls. Results are announced in a dedicated status region. Explicit dimensions and a restrained layout help the page remain stable on mobile screens.

Color choices were checked for WCAG AA contrast, including the small gold-accent labels. At a 390 px viewport the page should not require horizontal scrolling.

Print CSS removes interactive controls that do not belong in the test record and preserves the values and notes that do.

Requirement 7: link calculations back to source instructions

The page repeatedly tells users to verify the ratio against the exact label or technical data sheet. It also links to the relevant product and document context instead of dropping every visitor onto a generic homepage.

Examples include the wallpaper adhesive product overview and the 20 kg bulk handling workflow. Those links are contextual references, not a substitute for the exact documentation supplied with a specific product.

What we tested before publishing

The release checks included:

• valid and invalid numeric inputs;
• correct multiplication for representative values;
• result reset after validation errors;
• print-record field preservation;
• canonical and robots metadata;
• a single semantic H1;
• responsive layout at 390 × 844;
• no horizontal overflow;
• console errors and failed network requests;
• public access to the page, source, sitemap and robots file.

The design lesson is simple: for domain calculators, communication constraints are part of the software requirements. “The multiplication is correct” is not enough if the interface encourages users to apply the wrong input assumptions.

If you build similar tools for coatings, adhesives, mixing, dilution or batch records, start by writing down what the application must refuse to infer. That list may be more important than the equation.