NovAsia

A floor plan should remain legible after mobile image optimisation

Why a floor plan is a document to be read, not just another gallery image, and how mobile optimisation can fail even when the file loads quickly.

This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.

A pool photograph can survive substantial resizing and still communicate its main idea. A floor plan has a different job. The information often lives in thin wall lines, small labels, dimensions, door swings and the relationship between rooms. If optimisation preserves the image file but destroys those details, the page is technically faster and practically poorer.

I prefer to treat a plan as a reading surface. The buyer opens it to answer questions that ordinary photography cannot settle, so the mobile version needs to preserve the ability to inspect rather than merely the ability to display.

Start with the decision the plan supports

The question is not whether a plan looks sharp at thumbnail size. It is whether the buyer can use it.

Someone may be checking whether the bedroom is reached through the living area, whether a bathroom opens from a private or shared zone, where storage could fit, or how the entrance relates to the kitchen. Another buyer may need a dimension printed in small type. These are structural questions.

A photograph can suggest spaciousness, but it rarely establishes circulation. That is why a low-quality plan is not simply a lower-quality version of an interior photo. It removes a different category of evidence from the page.

This gives optimisation a functional threshold. Once the buyer can no longer answer the relevant plan question without guessing, the file may still be visible, but the feature has failed.

A small viewport does not justify a permanently small asset

Phones display content in a narrow column, yet users can zoom, rotate the device, open an image separately or inspect only one region. A sensible mobile experience can use a compact initial representation without making that representation the final ceiling on detail.

This distinction matters for performance. There is no need to force the largest source file into the first page load if the buyer has not opened the plan. But once they choose to inspect it, the interface should offer enough information for that inspection to succeed.

The mistake is to equate display width with required source detail. A 360-pixel viewport does not mean that every useful document should be reduced to 360 pixels of permanent information. The viewport is just the window through which the document is viewed.

File weight is measurable; lost meaning needs a separate test

Performance work naturally gravitates towards numbers: bytes transferred, dimensions, load time. Those are useful because they are objective. Legibility needs an additional human check.

Imagine two optimised copies of the same plan. At first glance they look nearly identical. When enlarged, one still shows room labels and dimensions cleanly. In the other, digits merge, thin lines fade and small text becomes a blocky texture. The second may win every file-size comparison while losing the reason the plan exists.

The test should cover more than one type of plan. Simple black-and-white drawings, light grey plans, dense layouts and plans with very small labels react differently to resizing and compression. A setting that works beautifully for a facade photograph may be inappropriate for a technical-looking drawing.

The product does not need one perfect number for every asset. It needs rules that respect the different jobs assets perform.

“Pinch to zoom” can sound like a complete solution. It is not. Zoom magnifies what is there. It cannot recover dimensions or labels that were removed during processing.

The same is true of a full-screen viewer. A large modal containing a degraded source is simply a larger degraded source. The escape route has to lead to an asset that still contains the relevant information.

A downloadable original can be useful for buyers who want to save the plan, compare it offline or share it. That option should not become an excuse for a poor inline experience, though. The basic research task should work on the device where the buyer started it.

At the other extreme, sending the maximum-resolution file immediately to every visitor can be wasteful. The practical compromise is progressive access to detail: fast enough to browse, detailed enough to inspect when requested.

Viewer behaviour is part of legibility

Image quality is only one layer. A sharp plan can still be painful to use if controls cover the drawing, the viewer closes after a small gesture, the zoom level resets whenever the user moves slightly, or the image is constrained to a tiny box.

That means mobile QA needs to include interaction. Can the buyer enlarge a room and hold that view? Can they move across the drawing without accidentally exiting? Can they rotate the device and continue? Can they return to the property page without losing where they were?

These are not reasons to turn a product article into a coding tutorial. They are simply the difference between “the plan exists” and “the plan can be read”.

Optimisation succeeds when the document keeps its purpose

I do not see performance and information quality as opposing goals. The conflict appears when only one side is measured. If file size is the only visible success metric, the system will naturally move towards lighter and lighter assets until somebody notices that a buyer can no longer read them.

A better test is phrased in user terms. On an ordinary phone, can a person open this plan and understand the circulation? If dimensions are part of the source, can they inspect the ones that matter? Does enlargement reveal information rather than blur? Is the plan clearly identified as belonging to the correct unit or type?

If the answer is yes, optimisation is doing its job. If not, the platform has retained an image while losing a document. A slightly heavier asset, or an additional high-detail load after the user asks for it, is preferable to a fast plan that cannot support a housing decision.