Product photos on the Weigh Kit list

Staff at a deli counter do not read a SKU when the line is moving. They look for the roast, the cheese, or the bag of nails. Weigh Kit now puts a photo on each row of the POS product list, and the photo is small enough that the list still opens with the catalog.

What the product row shows#

The product list groups variants under the product, in the order you set on the products screen in the admin. A product takes the position of its first variant. Each product row now carries a square thumbnail, 56 pixels on a side.

The image is the product's featured photo. If the product has no featured photo, the row uses the first variant that has one. That also covers a catalog saved on the till before the product image was stored on its own. An older snapshot still has a variant image, and the row can use it.

Variant rows keep their own photos. A variant with no photo borrows the product image. A variant that has its own photo does not replace the product row. The featured image can sit on a later variant. The product row still shows that featured image, not whatever photo happens to be first.

The box is the same size on every row. The picture is cropped to cover the square, so a wide pack shot fills the tile instead of sitting in a short strip with empty bands above and below.

Why the file is small before it reaches the till#

Weigh Kit does not send the original product photo to the register. When it builds the catalog for a location, it asks Shopify's CDN for a transformed image:

• at most 128 by 128 pixels
• cropped from the center
• delivered as WebP

One hundred twenty-eight pixels is enough for a 56-pixel box on a screen that draws two physical pixels for every CSS pixel. Asking for the original, often a large PNG or JPEG uploaded for the online store, would spend the till's time and memory on pixels the row cannot show. Center crop matches the square tile. WebP is smaller than the source file the merchant uploaded.

The same transform is applied twice, and the two results stay separate. One is the variant image. The other is the product's featured image. The product row reads the featured image. The variant row reads the variant image, then the product image if the variant has none. Mixing them into a single field would make the product row follow the first variant, which is the wrong photo whenever the featured shot lives somewhere else.

Why the list does not wait#

Those thumbnail addresses are fields on the catalog snapshot. That snapshot is the payload the POS extension already downloads for prices, barcodes, tare, and stock. The list does not call a second API to fetch pictures, and it does not download a gallery of full-size files. When the snapshot is on the device, the row already knows the image address and can request that small file from Shopify's CDN.

The thumbnail box is always 56 by 56 pixels, with or without a source. If there is no address, the image is rendered without one and Shopify POS shows its placeholder. Offline, the snapshot can still be there from an earlier download, but the CDN file may not load. The placeholder is the right result. The row does not collapse, and the title and price stay aligned with every other row.

A shop that adds a photo later sees it on the next snapshot. Until then, staff see the fixed placeholder, not a broken layout or a request that blocks the rest of the list.

The photo is there so the right product is obvious at a glance. The bytes behind it stay a thumbnail, already named in the catalog the till had to load anyway.