EPIC: Marketplace - Improve the checkout experience
#1672
Comments
KellyAH
added
🐞 bug
|
Catching up with this project plan today (it's been that kind of week...). Thanks for putting this together, @KellyAH, I found it very helpful to see it all written up and also the screenshots with examples of how other apps do it. 😻 I wanted to offer some thoughts on the MVP, in case these are helpful for the implementation:
In our current architecture, the delivery window depends on the delivery area chosen by the shopper. So we don't know the delivery window until the shopper chooses a delivery area -- that's why at the moment we don't show it until the "delivery details" are entered by the shopper. The way I see other delivery sites dealing with this is that either they just have one delivery area for the entire marketplace, or they ask you upfront before you start shopping to enter a zip code or address or otherwise choose a delivery area. We could do something similar in Convene:
These are just some rough thoughts based on my mental model of the marketplace, I'm sure other (better?) approaches are possible. |
|
Glad to see the project plan is helpful. I am very happy and willing to write up more project plans for convene whenever it is needed/wanted to help add clarity and scope, etc. As a technical writer, I enjoy writing them and I also gain a lot of clarity and big-picture scope from them. And right now I find writing up project plans more enjoyable than app coding. I would just need others to review the project plans for accuracy. |
|
I've really appreciated having the set of bugs that are most important laid out; as well as knowing that y'all are taking responsibility for polishing up the Delivery UX! |
- #1672 So, in reviewing a bunch of the delivery app workflows, most of them have: - Choose Pickup or Delivery - Enter Address - Browse Menu - Tap Item - Add Item to Order This lends me to believe we want to switch to gathering the `DeliveryArea` *then* `DeliveryAddress` *then* showing the `Products` that are available. This uses TurboFrames to replace pieces of the page, rather than relying on TurboStreams. On the one hand, it's lot easier (just respond with html with matching `turbo_frame_tag`s`). Blerg; anyway, I'm checking this in now; but not sure if I like it enough. Thoughts? In particular: - Copy-editing - Design tweaks? - Name Collisions: How Undo?
- #1672 So, in reviewing a bunch of the delivery app workflows, most of them have: - Choose Pickup or Delivery - Enter Address - Browse Menu - Tap Item - Add Item to Order This lends me to believe we want to switch to gathering the `DeliveryArea` *then* `DeliveryAddress` *then* showing the `Products` that are available. This uses TurboFrames to replace pieces of the page, rather than relying on TurboStreams. On the one hand, it's lot easier (just respond with html with matching `turbo_frame_tag`s`). Blerg; anyway, I'm checking this in now; but not sure if I like it enough. Thoughts? In particular: - Copy-editing - Design tweaks? - Name Collisions: How Undo?
- #1672 So, in reviewing a bunch of the delivery app workflows, most of them have: - Choose Pickup or Delivery - Enter Address - Browse Menu - Tap Item - Add Item to Order This lends me to believe we want to switch to gathering the `DeliveryArea` *then* `DeliveryAddress` *then* showing the `Products` that are available. This uses TurboFrames to replace pieces of the page, rather than relying on TurboStreams. On the one hand, it's lot easier (just respond with html with matching `turbo_frame_tag`s`). Blerg; anyway, I'm checking this in now; but not sure if I like it enough. Thoughts? In particular: - Copy-editing - Design tweaks? - Name Collisions: How Undo?
- #1672 So, in reviewing a bunch of the delivery app workflows, most of them have: - Choose Pickup or Delivery - Enter Address - Browse Menu - Tap Item - Add Item to Order This lends me to believe we want to switch to gathering the `DeliveryArea` *then* `DeliveryAddress` *then* showing the `Products` that are available. This uses TurboFrames to replace pieces of the page, rather than relying on TurboStreams. On the one hand, it's lot easier (just respond with html with matching `turbo_frame_tag`s`). Blerg; anyway, I'm checking this in now; but not sure if I like it enough. Thoughts? In particular: - Copy-editing - Design tweaks? - Name Collisions: How Undo? * Establish more appropriate DOM Hierarchy Card => TurboFrame => Content appears to be a little bit more reasonable for how we nest dom things. The Card is a layout and presentation element, so it sits as close to the top of the dom as possible. The Turbo Frame allows the pieces to be swapped; so it resides within the layout. The Content itself (be it a `DisplayArea::Form` or `DisplayArea`) is the most inwardly nested, so that it can be replaced with frames, or laid out differently depending on where it is being presented.
* `Marketplace`: `Shopper` chooses `DeliveryArea` independently - #1672 So, in reviewing a bunch of the delivery app workflows, most of them have: - Choose Pickup or Delivery - Enter Address - Browse Menu - Tap Item - Add Item to Order This lends me to believe we want to switch to gathering the `DeliveryArea` *then* `DeliveryAddress` *then* showing the `Products` that are available. This uses TurboFrames to replace pieces of the page, rather than relying on TurboStreams. On the one hand, it's lot easier (just respond with html with matching `turbo_frame_tag`s`). Blerg; anyway, I'm checking this in now; but not sure if I like it enough. Thoughts? In particular: - Copy-editing - Design tweaks? - Name Collisions: How Undo? * Establish more appropriate DOM Hierarchy Card => TurboFrame => Content appears to be a little bit more reasonable for how we nest dom things. The Card is a layout and presentation element, so it sits as close to the top of the dom as possible. The Turbo Frame allows the pieces to be swapped; so it resides within the layout. The Content itself (be it a `DisplayArea::Form` or `DisplayArea`) is the most inwardly nested, so that it can be replaced with frames, or laid out differently depending on where it is being presented. * Add tests!
- #1672 - #1325 - #1763 This splits out the Checkout flow to it's own page; so we can do things like: - Collect the Delivery Address and Phone Number - Let the Shopper pick a Delivery Time - Confirm prices - ??? * Communicate why we need Shoppers to choose a Delivery Area * Make pretty! MAKE PRETTY! * So much pretty * Remove unnecessary click
|
@KellyAH, if you get a chance can you run through the checkout experience and let me know if you think it meets the intent of the epic? |
|
✅ confirmed the checkout experience is better! Customers now can more easily tell when orders will arrive based on the delivery location and order time. |
Gizmo:Marketplace#831This is an attempt to focus our efforts on improving/fixing the currently most valuable area of the app, the
Marketplacewhich is used by Piikup and other clients.Tasks
🐛 Fix bugs
Anyone can pick up fixing a bug 😄
Marketplace:Buying Products:Guestis shown a 404 afterCheckout` #1657Marketplace:ShopperandVendorreceived duplicatedOrderNotification#1656Space: 404 pages should give people a way back to theSpacethey are in #1658Marketplace: order time is displayed in UTC #1660Feature
Marketplace buyers can see when their order will arrive
See - Project doc
Marketplace: GroupDeliveryWindowandAddress#1705Marketplace: StreamlineShopper=>Delivery=>Cart=>Checkoutflow #1509The text was updated successfully, but these errors were encountered: