Designing comparison and calculator interfaces around unknown values

D Ru — Thu, 08 Oct 2026 18:12:51 +0000

An empty input and a confirmed zero can look similar in a form, but they carry different meanings. A comparison interface needs to preserve that difference, especially when some of the information comes from documents a visitor has not finished checking.

VayThongMinh is my own in-house project: an independent informational website for a Vietnamese audience, not a lender. Its interface connects comparison content, explanatory articles and a cost calculator.

Make the comparison fields consistent

The homepage presents vehicle choices, amount and term selectors, and comparison cards. The cards organise information under recurring labels for vehicle type, documents and costs. Links lead from the overview to conditions and further detail.

Consistent labels give the reader a stable way to move across options. They also make a qualified value, such as a cost that depends on the individual documents, easier to recognise alongside a fixed piece of information.

The interface separates these comparison views from the calculator. Browsing an option and entering a calculation have different purposes, so their controls need different explanations.

Keep unknown distinct from zero

The cost calculator separates principal from the amount actually received. Its controls include interest-entry choices, rate units and periods, one-time fee handling, and recurring fee amounts and collection counts.

The form provides explicit choices for information that remains unknown. It distinguishes a fee confirmed as absent from a fee whose amount or collection method is unresolved. That is a useful interface decision: a missing answer remains visible instead of becoming an apparently complete result.

A small illustrative page model can express the distinction. This is an example for explaining the design, not production source:

{
  "oneTimeFee": {
    "status": "unknown",
    "amountVnd": null,
    "collectionMethod": null
  },
  "recurringFee": {
    "status": "confirmed_absent",
    "amountVnd": 0,
    "collectionCount": 0
  }
}

The separate fields show why knowing an amount does not automatically establish how it is collected. The calculator's interface treats fee amounts, collection timing and collection counts as separate pieces of information.

Put explanations beside the decision

The calculator groups related inputs under labelled sections. Nearby explanations describe the difference between principal and money received, the available interest-entry methods, and the handling of fees.

Its result area separates interest, fees and estimated total payment. Those labels continue the language used in the form, giving the reader a connection between input and output.

For developers designing similar interfaces, the useful pattern is to represent uncertainty explicitly and explain it where the decision happens. Clear labels, grouped controls and visible unknown states help the interface communicate what the visitor has supplied and what still needs clarification.

A page contract for service-and-location websites: an in-house Vietnam case

D Ru — Thu, 08 Oct 2026 17:56:56 +0000

A local service website needs to help visitors answer several connected questions: what work they need, where they need it and what to prepare before contacting the provider. Giving every page a clear responsibility makes those questions easier to follow.

For Khoan Giếng Nha Trang, an in-house website project in Khánh Hòa, Vietnam, my work covered research, content structure, design, development, SEO and launch. One part of that work was connecting service pages, area pages and supporting information into a useful route.

Define the page responsibility

The content map starts with three questions:

What kind of service does the visitor need?
What matters at the location?
What information will help them prepare an enquiry?

These questions provide a practical way to review the structure before focusing on individual layouts. A service page explains the work. An area page adds local context. Price information and an estimator help the reader prepare for the next conversation.

The following JSON illustrates that planning idea. It is an explanatory representation, rather than production source:

{
  "service": {
    "question": "What work do I need?",
    "nextSteps": ["area", "price", "enquiry"]
  },
  "area": {
    "question": "What matters at this location?",
    "nextSteps": ["service", "price", "enquiry"]
  },
  "estimator": {
    "question": "How do my assumptions affect the estimate?",
    "nextSteps": ["price", "enquiry"]
  }
}

The model connects each page to a reader question and a useful next step. It makes internal links part of the content design: their purpose is to continue the journey.

Give location pages useful local context

The site separates household and industrial drilling, repair, cleaning and survey services. It also has area routes for places including Nha Trang, Cam Ranh, Diên Khánh and Ninh Hòa.

The Nha Trang area page adds information about site access and what to prepare before a survey. It connects that context to price information and related material.

That responsibility helps distinguish an area page from the general service introduction. During a content review, a useful question is whether the local information would still be specific and helpful if the place name were removed.

Use the estimator to prepare an enquiry

The website combines a reference price table, an estimate calculator and a service request form.

The calculator exposes well type, depth, pipe diameter, area and optional additions. It presents a price range and explains that the final quote depends on a site survey. The interaction gives visitors a way to explore assumptions before discussing the actual work.

The form then asks for a name and phone number, plus service and area selections. A site photo or location screenshot is optional. Phone and Zalo provide additional contact routes.

The connection matters: content explains the service, the estimator helps with budget preparation, and the enquiry gathers context for the conversation.

Review the journey as a whole

A useful page has both a clear subject and a clear next step. Reviewing these together helps reveal missing connections between content, navigation and contact actions.

The full in-house project account describes the wider scope. The takeaway for developers is to define page responsibilities alongside navigation and form design, so content, interface and SEO work share a structure that can be reviewed and improved.

DEV Community: D Ru