NYCPHP Meetup

NYPHP.org

[nycphp-talk] Proper Form Processing Techniques

David Krings ramons at gmx.net
Fri May 23 07:27:36 EDT 2014


On 5/22/2014 11:58 PM, Michael B Allen wrote:
>
> I'm still not convinced. Imagine you're making a calendaring
> application and use local storage like you describe to draft events.
> Then imagine a scenario where a user tries to schedule an appointment
> while they're on the train and the internet cuts out. The appointment
> is not actually scheduled until they visit the site again which by
> then the event time may have already passed. Or maybe they used
> another device. A lot of people have multiple devices now.
>
> I think there certainly are cases where it is ok to store data on the
> client. But it should not be anything someone would get remotely upset
> about losing. And if it has to do with money, it's probably something
> someone would care about.

It all comes down to clearly indicating "Hey, your stuff is not submitted to 
the server yet and it is as if you didn't do it." Disclosure and proper 
documentation is of importance here. One of the biggest misconceptions in 
software development is that there is no network latency and even more so that 
there is always a network. That is why the whole cloud stuff is only nice as 
long as Big Bubba with his steam shovel doesn't rip the cables out of the 
street somewhere. So the choice is to lose everything or store a local draft 
that depending on the nature of the item gets uploaded automatically to the 
server once connectivity is available again.

I see your point with multiple devices, but that requires the user to 
understand that one device is not the same as the other. That concept is not 
new and only a problem if one doesn't know about it and if connectivity was 
not present during the entire process.
To mitigate that allow the start of a task with results that need to be shared 
to happen only when connectivity is present and make a note of the task start 
on the server. If the connection craps out after that the server at least 
knows that it is waiting for something final and can display that fact on any 
other device...assuming that device has connectivity.
Beyond that we get into having cake and eating it too territory as well as 
that no software in the world can fix management flaws.

>
> Putting something in a shopping cart is a sort of transaction. You're
> saying I am willing to purchase this particular item at this price. At
> any point after that moment the item and/or price could change. The
> item could sell out. A sale could expire.

That depends on how you design the cart. To be fair to customers do not allow 
them to add anything to the cart that is no longer available. And once placed 
in the cart mark that item as 'on hold' so that inventory is properly 
reflecting the potential buy. Sure, once the cart expires or the customer 
removes the item the product was held for nothing. I'd rather take that risk 
than having to make good on my promise...or always claim no rainchecks.
Price change is a bit different, when the customer put the item in the cart 
they accepted that current price. You can be nice and honor a lower price on 
checkout (and eat the loss if the price went up), but important price 
fluctuations may exist for day traders on stock markets. Prices are quite 
stable for cucumbers and keyboards.

In the end strive for the best user experience and assume that there is at 
least one user who does everything wrong...such as typing "abc" into a 
quantity field or typing 'May' or '234' into a numerical date field. Sure, 
that adds to complexity, but users generally don't care if you are miserable.

>
> Have you ever tried to buy plane tickets and a price changed on you
> while you're sitting at the computer fiddling with times trying to
> satisfy everybody's schedule? I think the airlines actually change
> prices depending on website activity for particular flights. Bastards!

Yep, they do...and that is another example. Competition and scarceness (there 
is only one plane that leaves at that time from that airport to that 
destination) do weird things. In the end it doesn't matter when they slam you 
with cabin door closing fees and moronic stuff like that.

- David


More information about the talk mailing list