UX for a system that converts between units of weight and volume

Question

I'm trying to design a system that aggregates transaction amounts recorded in units of both weight and volume.

Obviously, showing the total weight in kilograms of things you have individually weighed in pounds is simple (just multiply by a conversion rate), but it's not easy to show the weight in kilograms of something you've measured in gallons... (unless it's water or another common substance).

How can I allow users to track amounts in both weight and volume, and show accurate totals? Are there any applications that have solved this elegantly?

Any suggestions are welcome! :)

---

Some specifics...

Our agriculture application lets users track inventory of an arbitrary number of "resources"--chemicals, fertilizers, grain, etc. We're trying to make record keeping lightweight and simple, but our customers run businesses that require powerful, flexible record keeping.

1. Users can add resources to our system, giving them a name (ie, "Fertilizer-X", "RoundUp", "blue corn") and attributes (ie "organic: yes", or "EPA number: 1234")
2. When users record a transaction, they specify which resource was moved, the amount, and the unit (ie, "purchased 1000 lbs of Fertilizer-X", or "used 300 gallons of SuperFertilizer")
3. In reports, a user can see usage statistics for these "resources" in aggregate (ie, not just "purchased 1000 lbs of Fertilizer-X yesterday", but also "total amount of Fertilizer-X used this year")

Ideas so far

• When adding a resource, require users to choose weight or volume as the method of measurement. This would be permanent and uneditable, as changing it would break our ability to calculate totals.
• When adding a resource, require users to specify a permanent volume-to-weight conversion rate. Again, this would be permanent, as changing the method would prevent us from calculating inventory amounts.
• When adding a resource, require users to choose weight or volume as the method of measurement but allow users to change from weight to volume (or vice versa) at some later date as long as they provide a conversion rate when they do so (and have the system convert all their old data).
• When adding a resource, require users to choose weight or volume as the method of measurement or a conversion rate. If they want to change the rate later, let them. If they want to change the method of measurement, require a conversion rate.

Even worse ideas :-)

• Research and hard-code weight/volume conversion relationships for hundreds (thousands?) of substances and only allow users to choose from our list. They could then record amounts in any unit. (Not feasible.)
• Research and hard-code which unit type (weight or volume) each substance should use--again, for hundreds (thousands?) of possible substances--and only allow users to choose from our list. They could only record amounts in weight or volume, whichever we mandate for each substance. (Not feasible.)
• System-wide, only allow users to record amounts in weight, or in volume (not good enough for our industry, not helpful to our users).
• For each type of resource (ie fertilizer, pesticide), only allow users to record amounts in weight, or in volume (still not good enough for our users).
• Don't show aggregate values for things that have mixed unit types (a technical challange, and rather useless to users--not to mention confusing).

Answer 1

First of all, I would say that it is not helping anyone to propose different types of measurement. Conversion from kilos to pounds is useful because there is a cultural difference. But weight and volume ? It is commonly accepted that liquids are in volumes and solids in weights. But lets imagine that one measurement is for use and the other for transportation so it does make sense.

---

To start why do not use a pre-selected choice by the user so she can have a monotonous content threw the application ?

When creating an account she chooses a "culture", for instance: kilos, meters and liters or pounds, inches and gallons or what you think make sense. Then she can deal with amounts according to her own cultural background.

---

Then when adding a resource : give her 3 alternative, weight, volume or both. Let here choose whatever is relevant to her.

First two alternative are not really an issue. If she chooses volume AND weight :

If you have data about weight and volume, make a default guess and let her change it if she wants. If you do not have this kind of information, let her give you the information in a non so complicated way :

Probably the resources are packed into units, ask for this minimal unit (like a can or a bundle) and for its content's weight and volume : there you have your conversion rate.

Then she can change the unit whenever she wants since conversion rate is going to stay the same.

Answer 2

I see a larger UX question here - why ask your users to do data entry?

You don't want to do that product data entry manually. It'd be terribly boring.

However, neither do your users.

The companies who manufacture these products surely have spreadsheets or databases where they've already captured all the information you need. There must be some source where you could request that... or at least scrape the data off some other website.

If it's easy for people to make mistakes when entering data and impossible for them to correct their mistakes, you're creating an unpleasant situation for both the people who'll be using the site and the person who'll be getting their frustrated emails.

Instead, I'd recommend a system where it automatically pulls in data that came directly from the manufacturer and then gives the user the ability to duplicate it into a new item entry and then edit that entry if necessary.

Answer 3

Once you have the conversion ratio, can you not freely convert between weight and volume?

When adding a resource, require users to specify a permanent volume-to-weight conversion rate. Again, this would be permanent, as changing the method would prevent us from calculating inventory amounts.

This seems to be your best option. Each resource type has a variable(s) that allows you to convert weight to volume and vice versa. Your input interface can then be flexible - allow the users to enter weight or volume and then allow them to display inventory calculations in weight or volume.

Note that unit conversions are a separate (and solvable) problem.

Answer 4

I had a similar issue, albeit the project wasn't finished by me.

Question in your case is, wether measurement always stay the same per resource - eg: is the measurement always gallon for Fertilizer X, or shall the same resource be measured sometimes in weight, sometimes in volume?

In our case, it was a small one-man shop of home made cosmetics. Think of biosoaps, bath gels, creams, whatever - ask your wife/gf/sister...

The problem there was that recipes said "drops" but units were sold in mililiters. The size of a drop is dependent of the material itself (and even a bit of temperature).

I could imagine that some things are bought in volume (liters), but mixed to create some compound material with a recipe in grams.

Also, it's a big question wether some materials have slightly different densities (volume-to-mass conversion rate) based on manufacturer.

Like, some chemicals could be in crystalized form or in powder (that's surely true for artifical fertilizers). As they're dissolved in water, it doesn't really matter, but there's no constant conversion rate.

I guess you have to do ethnographic research with your customers on how do they use it themselves.

I'd also

• add the ability to freeform setting of measuring unit when taking in materials (eg, you buy it from a country which counts in gallons, and then one which is in liters... for these you can autoconvert),
• allow to enter multiple measurements per resource (both weight, volume, units) and
• beep if there's an inconsistency with existing resources of the same material.