Problem
Wardrowbe currently stores body measurements mainly as the latest profile snapshot. That works for a current value, but it loses useful information about when a measurement was taken and makes it impossible to distinguish:
- a profile edit from a new measurement,
- a repeated measurement with the same value,
- older measurements from the latest known value.
The goal is to build a foundation for recording whether clothes fit well, are too small, or are too large, and relate that fit feedback to the body measurements that were current at the time.
Proposed direction
Add a small, provider-neutral measurement history model while keeping the existing profile snapshot for compatibility.
The intended behavior would be:
- keep the latest values in the existing profile snapshot,
- store timestamped observations separately,
- allow an explicit remeasurement to create a new observation even when the numeric value did not change,
- support partial measurement updates without overwriting unrelated measurements.
UX questions to resolve before implementation is finalized
The backend/history model is relatively straightforward, but the user-facing behavior needs a little more thought:
- whether measurement history should be shown in Settings at all,
- whether users should be able to correct/delete observations,
- how much history should be visible by default.
Compatibility
This should remain backward-compatible with the existing body_measurements profile field. Historical observations would be additive rather than replacing the current snapshot.
Problem
Wardrowbe currently stores body measurements mainly as the latest profile snapshot. That works for a current value, but it loses useful information about when a measurement was taken and makes it impossible to distinguish:
The goal is to build a foundation for recording whether clothes fit well, are too small, or are too large, and relate that fit feedback to the body measurements that were current at the time.
Proposed direction
Add a small, provider-neutral measurement history model while keeping the existing profile snapshot for compatibility.
The intended behavior would be:
UX questions to resolve before implementation is finalized
The backend/history model is relatively straightforward, but the user-facing behavior needs a little more thought:
Compatibility
This should remain backward-compatible with the existing body_measurements profile field. Historical observations would be additive rather than replacing the current snapshot.