Re: [Grecipe-manager-devel] Ranges for Ingredient Amounts

[Daniel F <nan...@gm...>]

> Also please feel free to bring up any alternative problems.
>=20
alternative problems discussed below the original 5.

> The list of problems and possible solutions as I see them is below.
>=20

> Problem 1: Entering Ranges
>=20
> Possible Solutions:
>=20
> 1. Just allow user to type a "dash" (1-2) in the amount field. We
> should probably also understand "to" and it's internationalized
> equivalents.

i think this is the more elegant solution. but i see no need to allow
"to" or anything else. first, it would complicate the handling of the
ranges, and second, it would add no real functionality to it.
separating ranges with a dash is standard procedure, i do not think
anyone would get confused if only numbers and a dash were to be
allowed in the ingredient amount field. (just like now a box comes up
that you can only enter numbers in the amount field, it would come up
and say you can only enter numbers, or a dash in case of ranges, if
someone tries to put in letters..)

> 2. Present a separate "range" interface with two entry widgets (okay,
> I wouldn't really consider this, but it is a possibility)...
>=20
> Problem 2: Calculating nutritional values
> Possible Solutions:
> 1. Simply assume the larger or smaller amount (with a preference
> setting somewhere to allow the user to specify)
> 2. Simply assume the average amount

i would say put the two together, and do "Simply assume the larger or
smaller or average amount (with a preference setting somewhere to
allow the user to specify)", probably with "average" being the default
setting.

> Problem 3: Generating shopping lists
> Possible Solutions:
> 1. Ask user how much of ingredients to use each time a range is
> presented, just as we do with optional ingredients. Possibly create
> some preferences to override this behavior and simply assume a value
> (low end, high end, or average).
> 2. Always assume the high value should be used (after all, you'd never
> want to end up with two little food).

i would think option #1 is better. just add a "save this decision and
do not ask me again" checkbox in the dialog when it is presented, so
the user has the option to save a persistent setting.

> Problem 4: Exporting ingredients
> Possible solutions:
> 1. Create an XML syntax for ranges of numbers (gourmet format)
> 2. Normalize to use "-"s
> 3. Simply export amounts as strings (so if the user enters "to" or its
> equivalent, their language is maintained).

well, if we go along with just allowing the use of dashes in entering
ranges, as per problem #1, this problem resolves simply into solution
#2.

> Problem 5: Storing ranges. If I remember correctly, amounst are
> currently stored as a float in our database.
> Possible Solutions:
> 1. Store amounts as a string
> 2. Create a new database column "rangeAmount" where we store the second n=
umber.
> 2.a always format ranges the same way (standardize to a "-" or "to" as
> a separator)
> 2.b. Create another database column to store the separator character
> ("to" "-" etc.) (this seems ugly to me)

deciding problem #1 in favor of only allowing dashes resolves this
problem too, in favor of 2a. so really, restricting the range
separator to just a dash solves a lot of these problems.

also, another consideration here is if you store the amount as a
string, then when you have to calculate the average for say,
nutritional purposes, you will have to parse the string for the two
numeric values before you can start doing simple arithmetic on them,
and it will be just a pain.

now, a Problem 6
parsing erroneous user input. say, we allow just the dash as a
separator character, for simplicity's sake. then, a user enters
something like "10-" or "-3" into the amount field. do we just parse
that silently into one amount, or notify the user something is wrong?
how about if a user enters input like "10-5"? do we just take it as it
is and parse it, letting the high amount be lower than the low amount?
or do we automatically reverse the numbers, or do we notify the user
again?

solution: it would seem to me that it would be better to notify the
user... but then it might be an awful lot of dialog boxes to throw
around...

and i will throw in a bug report here too, since it is related. just
tested negative number input for amounts, and it silently parses neg
numbers into "0". then, when you start editing that amount, but leave
it as is, spits out a box saying "cant understand amount '0', must be
numbers or decimals or blank". definitely looks like a bug to me. if 0
is not allowed, should not parse negative input into 0 silently.

-d