...
We did come away with a couple of idea that we want to explore more.
First, the quantities was confusing to some users, even after our redesign. One thing that we should think about is having an explicit, table-like “Qty.” column instead of the “x”. In addition, instead of having a text box for the user to input a quantity, we should think about of just having a “” and “” "" and "" button. The “” button "" button appears on the “Menu” column on the page and the “” “” button appears on the “Your Order” column. If users want to order multiple items, they just tap the “” the "" the desired number of times. If they want to remove items from their order, they tap the “” button "" button which decrements the quantity. When the quantity gets get to 0, the item is removed. The nice thing about this, is that there are no more “x”s "x"s in the UI. The downside to this is that the UI U is that users users may “overshoot” "overshoot" their desired quantities. However, our guess is that people are not going to be ordering large quantities of good so error prevention is likely not that big of a deal in the common case. Additionally, having easy to click , “” and “” buttons is certainly more "" and "-" button is certainly more efficient for smaller quantities than clicking in a text box, moving your hand from your mouse to your keyboard, typing the number, hitting enter, and moving back to your mouse.
Second, After talking to a couple of users, we came away with an idea for a “Unified Shopping Cart”. Right now, our application flow is: (1) choose truck (2) select items (3) place order. To accomplish Task 3, this would require the user to place 2 order to get items from two different trucks. One idea is to have a “Shopping Cart” model, where users can choose their truck and add items to their cart. The items in the cart remain even after the user changes to another truck. Once they are done, they are able to place just a single order. This model will retain the same “ease-of-use” as our current implementation, but will scale better for scenarios like Task 3. This does come at the expense of a more complicated back end (and handling payments to multiple sources) but since this is a UID class, we should not sacrifice user experience because of implementation difficulties.
...