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 _______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show-participation
