First - I totally agree, the experience could be improved in so many ways I can't even count them.
Before we proceed, let's establish _my_ goals for the 1PC for legacy vstore. The only goal with the 1PC was to 'acceptably replicate' the existing vstore legacy checkout paths and provide clients a pathway to an app that would let us eventually turn off the legacy checkout, well before we completely turned off the vstore platform (since checkout represents about 50% of the complexity and one of the largest maintenance costs).
It was intended as a way to help clients avoid disruptive change and to ultimately reduce our support costs (in hindsight it will almost certainly never achieve that goal). The 1PC was initially an experiment with the feasibility of an app based checkout (knowing that it was the most complicated portion of what had to be done -- and after it was finished an app based site would seem easy).
I make no claims that we intend to build the only perfect one page checkout --- in part because I believe we already have. Our 1PC is perfect, amazing, and with each iteration it only gets better. I'm not saying that in a "look at how beautiful my baby is" way -- rather, after 13 years in e-Commerce, I am positive there is no perfect flow and no matter how good something is, it can always be incrementally improved. I'm saying that *because* IT CAN BE CUSTOMIZED EASILY, and those incremental improvements will always vary by client. There is no other checkout platform that is easier to customize to specific requirements in part because it's so very simple out of the gate.
In ZoovyLIVE today, I outlined how I want to focus on things that fundamentally shift, and make those things very accessible and adaptable, and how the app framework is well suited for that.
But with specific regard to 1PC - I feel we've released a good solid product that is easily, affordably and infinitely customizable (easily testable as well, which is a HUGE part of checkout) that can be done as part of any app build. So it's a perfect "David" statue which can be dressed by the client in whatever attire they see fit (which may vary by season, holiday, special event, etc.). The 1PC works within my target compatibility parameters (it was never 100% compatibility due to jquery/prototype incompatibilities). Had I insisted on 100% compatibility, we never would have gotten it released.
Anyway, that alone warrants/justifies calling the 1PC an amazing step forward and makes it better than anything on the market. The goal in my business isn't to support 570 different versions of the 1PC, and then try to achieve compatibility with roughly 3,000 unique website designs built on a 13 year old rendering system. Instead, our mission is to have 3 or 4 that are minimal core releases which can be easily/quickly/affordably adapted to fit different business needs. So please don't wait for us to make a perfect version just for you and include it as a standard feature -- that isn't what we are trying to do.
On
a personal note -- I will ask the community to get together and outline
the perfect one page checkout flow right after everybody in our
community can agree on which religion is the one true/correct religion!
:-)
I don't expect everybody to agree. I am not trying to discover the one true religion or one true best checkout flow. You all run different businesses and you all have needs. But if there is overlap, that's GREAT!!!! I've suggested that some clients who need/want the same or similar things can and SHOULD pool their resources to create those things. We'll hire/train/manage/monitor developer(s) to create them and "split the check" across those clients. In some cases, to make it easy for the vendors who offer tools (ex remarketing to abandoned carts) build that feature and include it for free/low cost with minimal expertise and experience. In software, this is a new concept - in a pizza restaurant I think it's pretty common. Arrange an ad hoc decision management structure, appoint one client the lead, or do it as a community decision (podio is great for things like this. It's just another workspace for that portion of the project). Don't reinvent the wheel - unless you need a special wheel.
But our work here at Zoovy, and our responsibility, is shifting from trying to make one platform that does everything, to making a platform that is easy to make do *exactly* what you want and is infinitely adaptable, with the help of minimally trained developers. As far as I'm concerned, the template-based site model has too many limitations, as well as the generic checkout model. I feel this is not where we need to focus.
We
may improve the templates, but look for more revolutionary than
evolutionary changes. There is no shortage of great ideas/features I
want to get into the backend right now that will benefit everybody.
So, I'm not saying that we won't be releasing another 1PC. But I feel pretty comfortable saying it's unlikely we would consider offering one to those with compatibility to vstore, which is 1 year into it's 3 year end of life platform. The vstore 1PC is not customizable because the vstore product requires a developer spend 400-600 hours of one-on-one instruction learning the vstore TOXML format, and SPECL language to be able to connect it to the 1pc app framework. At this point the number of developers in the world who understand SPECL fluently is 2.5, and two of them are focused on building apps.
So we have crossed that threshold where it's cheaper to just start from an app. The next checkouts will likely tie to some interactive features of apps and won't be compatible with vstore (watch ZoovyLIVE for a preview of what we're working on).
From _my_ view the 1PC checkout process is:
1. Use HTML to ask customer for data. <-- whatever/anything you want
2. Upload data in order format to server. <-- upload as much or as little information as you gather in step #2
3. Server generates order # sends to app. --> yay!
4. App receives order # and thanks customer. <-- whatever/anything you want
Steps 2 and 3 are Zoovy responsibility - for #2 we need to make it as easy/reliable to send as possible, for #3 we need to make sure we always create an order or send back a meaningful error "ex: go away, we don't want orders from your country".
But for steps 1 and 4 -- let's get a podio group setup, and get a developer working on what you want!
Take care,
-Brian
No comments:
Post a Comment