Update on "Ideas"
A while back, I did a post asking for ideas for an open-source project. Having thought long and hard about the many (truly excellent) ideas, I think I'm ready to begin the next phase.
I've decided to go with an Ajax-based ecommerce system. While there was a good deal of enthusiasm for a CMS, there are some very good ones out there now and I think we'd all benefit from having a really nice, flexible ecommerce system.
I'm planning on taking this slowly, and at this point, I'd really like to get your ideas about the following categories:
MUST: What features must the system have to be usable? In other words, what features, were they to be lacking, would make any ecommerce system unusable?
NICE: Having passed the bar of MUST, what features would you really like to see in the ecommerce system?
NOT: What would you like to see omitted from such a system? This category could also be used to indicate particular "gotchas" from features in the MUST or NICE category.
Also, if you would be willing to work on this system, please send me an email to h a l @ h a l h e l m s . c o m telling me what areas (graphics, architecture, coding, internationalization, etc) would you like to work on?
Thanks!
e-Commerce is a great idea and I would suggest check some best accepted solutions such as oscommerce.com etc.
I am ready to provide my help especially for i18N part.
I also would like to suggest Git as version control for a better team collaboration.
Thanks again for an idea like that.
Have a big emphasis on a clean separation between the model/backend and the user interface. Yes, an Ajax interface would be pretty an all, but I think much more beneficial for everyone would be if anyone can just pickup the "engine" of the ecommerce system and plug it into any type of interface they need. That way you can go from a simple html+cf interface, to Air, to Flex, to Framework XYZ, to anything you want.
NICE: Item attributes should be standardized. Maybe match them to the attributes in Google base?
@Oğuz: I know very little about Git. Perhaps you'd be able to set us up and give us a little knowledge about using it?
@Oscar: Agreed. Even if we provide a front end for it, it should simply be one client implementation. That's one of the biggest shortcomings I see in ecommerce systems. Sounds like we need a good API.
@Will B: Agree. I'm working on an ecommerce system for a client in which customers can select an entire tableware set and buy them over time. The advantage to the customer is that they receive a discount on each individual selection. We're planning on using their chosen set to (a) remind them when they come on the site and (b) periodically contact them to remind them about continuing the completion of their set.
I've thought of doing something similar. I even entered into discussions with AbleCommerce, which seemed to be the most mature CF-based e-Commerce system. AbleCommerce has stopped development of the CF version, and they were in fact open to selling it. The price was too high, and I was suggesting them to open-source it. I do know the code is somewhat spaghetti, but it did have tons of features.
Having had time to think this over, I think Oscar's comment is right on. You should be able to plug something robust into Mach II, ColdBox, MG, etc, or work with AIR, Flex, HTML.
For a list of features, its easy to skim other systems. An e-Commerce system never seems to have enough features.
Unusable: Lack of https support.
Nice: The merchant wants some sort of dashboard to see who's "shopping" in your store, and a "Can I help you?" feature.
Must: Keep track of profits for taxes.
Nice: Integration with Quickbooks.
Nice: Drop shipping, so when someone signs up to this new eCommerce system, the only thing they have to handle is the money coming into their bank account.
With all due respect that really shows your lack of understand on PCI DSS.
if you're using a payment server provider its a requirement at the very least to complete the PCI DSS questionnaire. No matter even if you are using a PSP the end store has to satisfy at what level they need to meet (if any). Even PayPal Payments Pro! Anyone who runs a ecommerce store must understand this!
Paypal "If you're using Website Payments Pro or Virtual Terminal or your method of integration means you store card data, you are therefore responsible for your own PCI DSS compliance."
You have to prove you don’t need to meet the requirements now. Most sites using Paypal pro, WorldPay, Sagepay come will come under level 4 which is just a scan once a year.
however our customers using Paypal standard and SagePay VSP Form where the end user never enters their actual card details are still required to complete the questionnaire even if the outcome is you dont need to to meet any level. certainly over the last few months some of our clients have had to prove to the bank there are not storing card data or transmitting data (even in RAM for a second is storage)