FoxyCart Pre-Sales Questions, Part 1

We Love To Talk

We’re big fans of personal communication at FoxyCart, so we try to take the time to say hello to every store signup and every person that contacts us on our website mini-contact form. What follows is a real FoxyCart user email, with our responses inline. (The original email sections are in the blockquote boxes.)

Our hope in posting this is that it’d be at least slightly interesting to those looking for more information about why we built FoxyCart the way we did. We’re also posting because nobody over here is a very experienced blogger, and we’re so busy improving FoxyCart that the only way we can add content to our blog is to rip it off of our emails ;)

We’ve added headings in the copy of the email below just to clarify what’s going on. Let us know what you think in the comments below. Based on the length of our responses below, we clearly love talking.


Trash talk and back patting

Hi and thanks for your interest in FoxyCart!

As I’m sure you are aware, many all in one store packages are limited in how flexible the design can be and that can be frustrating.

Yes, painfully aware. We really tried to address all of my own personal frustrations in FoxyCart, and being an all-in-one solution was something we have set out to not be.

I’ve done a lot of work with (3rd party self-hosted ecommerce solution) which I like because I can customize any portion of the code (I’m very well versed in .NET programming). (...comments about other solution, removed to at least pretend like we don’t want to talk trash…) Further, the software lacks in many usability areas. As an example, in your cart when something is changed such as qty the “checkout” button hides until update is clicked. This is a nice feature that leads the customer in the right direction. Seems silly but these little things really matter.

Thanks for the comment. We actually bickered quite a bit about exactly how this should function, so it’s nice to hear it’s appreciated ;) We really tried to rethink the entire checkout process, and I think we did a lot of neat (and truly “new”) stuff as a result, including the one-page checkout that actually completely bypasses the usual confusion with figuring out a new versus a returning customer. That shouldn’t be the customer’s responsibility to figure it out. It confuses me most of the time.

Bored Yet?

Haha, never!

We hate duplication of data

I’ve also looked at Shopify which does a decent job as a store but lacks in general CMS areas, including blogging. They also charge a % per transaction which is not very attractive.

I actually really like Shopify, but at a conceptual level I really dislike ecommerce with an integrated CMS. Partly because I’m so in love with MODx, but also partly because an all-in-one solution just never ever does a good job at everything. And mainly because most every client I’ve ever had has a site with a store, rather than a site that is (only) a store.

Duplication of data == bad. Anyway, now I’m boring you!

We love MODx

MODx seems ok but I’m not a huge PHP guy so I’m not sure how much I want to dive into new things. I’ve also been looking at Ruby, but again, my time is well vested in .NET. However, I’m looking into this more :)

MODx is pretty brilliant, but the real power comes with some knowledge of PHP. Ruby (on Rails) always calls out to me, but I’ve just never found the time.

What about inventory management?

So my goal (I assume many of your potential clients too) is to be able to design a CSS, HTML, XHTML website and easily pull in e-commerce features. One area that may be a big void in your current system is that there is no product management in the back end except for downloads.

This is actually intentional on our part, and is done this way in an attempt to eliminate any and all duplication of data. The idea is to use a CMS to control the products. That said, you bring up a good point:

Why this is important is avoiding things like over selling qty. Since there is no way for the cart to check against avail qty the user would have to always be tweaking html to change this.

We really wanted to avoid inventory management because, in our experience, if you’re a store that’s actually tracking inventory, you probably have a real inventory system with a high probability of offline orders affecting inventory levels as well. Most ecommerce inventory systems are only appropriate for an exclusively online store, and are quite basic. Most stores requiring inventory don’t fit those criteria. (Not to say it might not be handy, but that it’s a one-size-fits-all approach that I’ve personally never actually seen used in the wild.)

Luckily, we built FoxyCart to integrate (in this case, using the XML datafeed), and we’ve already whipped up a quick and basic inventory management. It’s for MODx, but could easily be applied to any CMS that supports similar functionality. It basically uses the FoxyCart XML datafeed to decrease a database value (inventory) according to processed orders, and when the inventory value is 0, it change the generated “Add to cart” link to an “Out of stock” message.

I’d love to know what you think about this approach.

Why no product manager?

One method I thought would work is to have a product area in your admin. Once a product is created there is a button that will generate the html needed to place on the website. Instead of having product name and price it would just supply an id that maps to the product and would use this to pull in the information. Hope that made sense.

RomanCart actually does something quite similar to this, and it works ok, but it obviously gets into some duplication of data. If we did do something along these lines, I think we’d probably want to move the product “creation” to an XML file hosted on your own server, or something that could conceivably be controlled from the CMS... to avoid the need to login to a CMS to create a product page and description and link, then needing to log into FoxyCart’s admin to set up the product again.

We’re totally awesome, like Ashton Kutcher

Anyway, I’d be happy to expand on this and many other areas if you are interested and hopefully my years developing e-commerce sites, payment plug-ins and other custom modules will come in handy and help you shape a better product.

I’d absolutely love to get your continued input and expertise. Please send along anything you find good, bad, confusing, or etc.

Thanks again for the response email. I’m hoping we can make your ecommerce dreams come true ;)

Best,
Brett

   

Questions?

Love it? Hate it? Have questions or comments? Let us know!

 
Cart Json Bottom