Suggested sanity check for out-of-order fill up entries
 

Recently, I just added almost 20 fill ups over my cell phone, and data entry seems to be a nightmare, as I messed up an awful lot. Entirely my fault, and not the sites fault, but, maybe a new data check should be implemented to assist in ensuring that the dates entered make sense?

Also;
- On a side note, I don't remember if I was prompted on the mobile fill up form, but it MIGHT be prudent to have the fuelup_date as a full date & time field, or allow it to be included in the CSV as such, as with multiple fillups on that day (If I had the GA instead of a rental I would have filled up twice in a day) it'd allow for this sanity check above to be a bit more precise and cause one less false-alarm.

- I also `JUST` noticed that even though the CSV has the Metric heading values, the values themselves are still set for US. (KM and Liters are headings, 12.19 liters for a price of 3.79 doesn't make sense)

How I found the problem;

On Feb 7, 2009, I entered 18 fill ups, on my cell phone. I entered the fill ups out of order, meaning that I could have entered a fill up for January 2009 before I entered a fill up for Oct 2008, as I was sitting in the car waiting for the wife (And wanting to test out the new data plan on the cell. ;))

I downloaded the CSV for all my fill ups tonight on the PC, and I noticed that when I sorted the data based on odometer, some of the dates I entered were out of order, and obviously didn't make any sense.

So my thought, as a very BASIC check in this sites submission code:

When submitting a new fill up from the past, take the odometer reading, compare it to what the previous date fill up was based on odometer reading only, and check to see if it makes sense against the user submitted fill up date.

As an example, if I were to have filled up at 118,495 on 11/13/08, and my next fill up was at 118,671, and I accidentally entered 08/08/08, it'd fail the data entry because I already have a fill up on 11/13/08 with a lower odometer reading.

My DB theory:

select odometer, fuelup_date from whatever_table_you_called_it where (odometer $_GET["fuelup_date"]) {
// Fail
echo "Houston, we have a problem."
exit
} else {
// Pass
echo "Houston, the Eagle has landed."
}

The problem that is going to come up is that if I erred previously with a date entry, I'm going to get stuck and will have to review the changes. What COULD be done is in the "Houston, we have a problem" section is give a simple, sorted (based on Odometer) table showing the odometer readings previous to, and after the user entered odometer reading, with the fill up dates, and then either allow to force the submission of the data so the user can go back and edit later on a PC, or, allow the user to make changes on the spot, if their cell browser allows it.

Of course, if I erred back on Feb 7, and entered a fill up on a date that hasn't happened yet (Which I did), the next time I fill up, and enter the new data for the fill up, I'd be confronted with the "Houston, we have a problem." error, but at least I'd know I'd have to fix something.

Now, to check my theory; If I didn't enter any data for a few months, then decide that I want to make an entry, I can still submit the new fill up (213,435 on the odometer, this fill up will happen Feb 28, 2010), with all said above, since my `last` fill up as far as your DB is concerned was at 118,495 on 11/13/08, the sanity check would pass, because my current odometer reading is bigger than the last fill up, AND the DB date is in the past.

Getting good data into the system is one of our biggest challenges, and we really have no control over how people use the system. We have a very open system that is pretty flexible in how you can enter your information. You're right, you can just take a list of fuel-ups that is completely out of order, enter them in, and Fuelly will do its best to calculate everything correctly.

I'm sure we could add a gentle warning message here or there, but I'd rather err on the side of letting bad data in and then letting people clean up later. I'm afraid if we stop the data from going in, even if it's close, and show a list of fuel-ups explaining why the data someone is trying enter is bad, we'll just frustrate the heck out of people.

Double-checking your fuel-ups is a great idea. And any bad dates or odometer readings can be fixed by editing any bad fuel-up.

And to touch on some other points you mentioned:

1.) yep, adding time to fuel-up dates is a great idea and something we'll do at some point. We opted for simplicity by not offering time, but it is confusing when you have multiple fuel-ups on the same day.

2.) The CSV import is a bit more loose than entering data via the fuel-up form. The import will go with a car's unit settings, and simply use whichever fuel-volume or distance unit you have in the header. So if your CSV has "gallons" as the header, but your car is set for "km", the system will convert everything to "km". There's a note on the page that's front and center letting you know what units the import is expecting. Again, we're assuming that folks know what they're doing, and we don't want to frustrate them by being too rigid.

I think it boils down to: we can't know how people will use the system so we have to try to be very flexible. If someone wants to enter a fuel-up from today, and then one from two years ago an hour later, we should assume that's what they wanted to do.