Thread

I haven’t had the chance to work with BR but have built 3 sites recently with CT. The last with CT2. It really is a very flexible system but don’t expect much in the way of ‘plug and play’ functionality. My first site with CT was a big learning curve as you literally build everything from scratch through each stage of the checkout process. This obviously has it’s pros and cons but by site three I now have blocks of reusable code that will get recycled in other projects.

What I love about CT is it’s complete integration with EE. My last site was for a musician.He can add a single entry that feeds both the shop and the ‘discography’ section which saves time and keeps things up to date.

The two areas where CT is still a bit lacking for me is ‘bundled items’ such as being able to offer full album downloads or select single songs form a list (I was able to create a work around for this) and reports - these, however are both being worked on.

Finally, the support from the CT guys is superb.

My experience of both CMS and eCommerce system at the high-end range ($5000+) usually results in 70% bloat, 10% redundant functionality and 20% of actual usage.

Nail on the head. It’s why I’m really excited about the prospects of both BR and CT. In conjunction with EE, all that waste is avoidable. Thanks for breathing life in this thread to stimulate the conversation!

The idea that you can simply ‘plug and play’ an eCommerce website is a very dangerous thing - there are extreme consequences in some cases and as with Stephen, most of our eCommerce projects are 4 to 5 figures - but clients are paying for our expertise in producing a quality product at the end of it which physically makes them money - however, one thing I don’t agree with Stephen on is the price point. Whether you pay $99 or $9000 for the software, it’s about the implementation of that software which will ultimately pay dividends. My experience of both CMS and eCommerce system at the high-end range ($5000+) usually results in 70% bloat, 10% redundant functionality and 20% of actual usage - versus a leaner solution which may lack functionality in some cases, but is built in such a way that it’s extensible to meet individual requirements.

Thank you for your very informative input.  I couldn’t agree more. 

FYI…I think you’ve lumped me (Stephen) in with Shine Marketing.  We’re separate:)

Thank you for your very informative input.  I couldn’t agree more.

You’re very welcome! I’ve already taken on board quite a few of the comments made here and added them to the BrilliantRetail Roadmap for the guys at Brilliant2 and I to discuss going forward - some of them you will probably see in future releases soon!

FYI…I think you’ve lumped me (Stephen) in with Shine Marketing.  We’re separate:)

Don’t think so - appreciate you’re different people, Shine Marketing poster is also Stephen 😊

Ah, okay.  I didn’t see his name in his profile so it confused me:)

Ah, okay.  I didn’t see his name in his profile so it even confused me:)

Ahh I see… no probs! 😊

Really finding this thread informative and will be coming back to it when I get my first eCommerce client.

Definately very informative, there’s a lot of good impartial info in this thread about both systems - and the conversation is so polite and mature about these 2 solid EE addons 😊

[still twiddling my thumbs waiting for an EE client who wants ecommerce…lol]

Hi all,

I think that this thread has covered just about everything, but having had experience with both BR and CT (1 and 2), I thought I would put my 2c in. 

First off, both BR and CT are excellent add-ons, and anyone who is considering doing an EE e-commerce site should purchase BOTH, and trial them.  I say this because whilst they are both ‘e-commerce’ add-ons, and certainly have a lot of features in common, I feel that they are each suited to slightly different types of projects.  Neither is high cost, and are both well worth the investment for R&D purposes.

BR is an excellent out of the box ‘traditional’ ecommerce add-on.  I was up and running with BR in a couple of hours (as Carl mentions above, it’s not plug and play, but it’s pretty close with BR!).  They provide literally templates for the whole site with the add-on, which makes setup so very very quick.  Everything is stable, and works just like it’s described.  For those wanting to sell all kinds of ‘widgets’ (software downloads, physical products, bundled products, etc), in a standard “find product (search, categories, related product, etc), choose option for product, add product to cart, go to checkout” way, then I highly recommend BR.

CT again is an excellent add-on, but takes a little more to get your head around.  They do provide excellent templates with the add-ons, but they seem more for example sake rather then an ‘out of the box’ solution.  That said… CT is HUGELY flexible.  With a little patience you can make it do almost anything.  As two examples of this, one site we required a cart to have ‘on the fly’ ski rentals added. We needed to be able to add multiple ‘skiiers’ to the cart, then each skiier had multiple items that they were renting, and finally each item could be rented for different amounts of days!! *Phew*. 

The second site required the sale of online tickets (for a dinner and show), for two different venues, each venue having different levels of seating.  On top of this, the site also sold traditional merchandise, AND ‘on the fly’ photos from the show the night before.  These photos could be downloaded or purchased as a printed item!  Complex!

The point in these two stories is not to tell you how great I am (which is true clearly! ha ha), but to highlight the level of complexity you can achieve with CT.  Of course it can also do the standard ‘product->cart->checkout’ style site as well… but it is a very very flexible system.

Both BR and CT come with a good set of extension hooks…which have come in super handy over time!

I will be honest that there are downsides to both products as well.  The reports are seriously lacking in both… but they are being worked on at the moment, plus it’s worth saying that you could use Leevi Graham’s NSM Reports add-on to create your own (http://ee-garage.com/nsm-reports).  BR’s documentation really isn’t great, and needs a bit of work (put examples in!!).

Data import is an important issue for both, and neither do this out of the box.  I’m not 100% sure how you would bulk import data into BR, but CT you can use the excellent DataGrab add-on (http://devot-ee.com/add-ons/datagrab/).

So back to the good things about them… both have loads of shipping and payment gateway plugins, and will happily help you create new ones, or you can pay and get them to create one for you.

The most important thing about any add-on is the support… and BOTH the BrilliantRetail and CartThrob teams are second to none with their product support.  They both provide helpful, USEFUL, advice in timely manner.

A lot of using these add-ons is about what is right for the job, and also which one you feel most comfortable in using.  For me, this is probably CT, but I think BR really is an excellent add-on, and will suit many many people… this is why you need to get both and test them.

I hope that this has helped someone!

Cheers.

Thanks Andrew, confirms a lot of what I’ve thought and I never knew about the reports add-on, I’ve been battling with restricted templates and the query tag all this time!

See next post, didn’t mean to post under this account.

Nice reply Andrew, and that pretty much sums up what CT does for me too. It’s a hugely flexible tool, that I can design the experience first, and know that it can work the way that I want it to work.

I think if I was to take on a simple product catalogue/cart project, BR would certainly be worth the time in researching, but it the requirements are a little more complex then I know CT can handle it. As examples of work I’ve done in CT:

STORM Watches
http://www.stormwatches.com.au/
This was a product catalogue, but needed the ability to have relationships between other types of content (using Playa). We actually built the catalogue component first, then retrofitted CT onto the site in about 2 days all up including testing (note that we had already designed the ordering process).

Australian Web Awards
http://www.webawards.com.au/
This had members joining the site, generating an Award nomination entry as a piece of content, then were paying for an entry based on the number of categories you chose to enter a website into. Again, it’s not out of the box ecommerce type stuff, but was relatively easy to implement using CT.

Conference Registrations
http://registrations.impcom.com.au/
This site required the ability for the client to create a ‘Conference’ as an entry, and setup all the difference options for the conference. Pricing for Early, Standard, Late across Day, Full and Student Registrations, Social Programs pricing (incl Guest Pricing), Workshop pricing for Conference Registrations and just Workshop. We’re using quite a large chunk of javascript to get all this working together and it a fairly complex form, but shows the complexity of what you’re able to do with CT. There’s a dashboard that has been created for the backend, that shows registrations for each of a conference’s components and how much $ is being generated as well. (Please don’t do any test registrations to see how it works)

Reports are lacking from the CT POV, as well as the Order Processing type templates (I’ve used Interspire before and their order processing screens are pretty comprehensive), but sometimes the client just doesn’t need a whole lot of functionality. And email is sometimes enough if there’s only 1 person in the office doing the processing. Just a matter of determining the requirements.

One thing that Carl Crawley mentioned was the differentiation between content and product. For me, and this is just my opinion as I hold Carl in high regard, is that all components of a website should be seen as content, and the integration with other types of content is what provides the richness to someones user experience. It could be just a matter of educating the client a little differently, but as I mention, that’s just my point of view.

Cheers
Brendan

I thought I’d pop in here to share my perspective, rather than to discuss features…. because I don’t really care about specific features much. Magento has features. OSCommerce has features. They have a giant laundry list that CartThrob will never match. But that’s not the point of CartThrob.

In developing CartThrob, our thought was thus: If you want standard ecommerce, use Magento. It’s a fantastic, full-fledged ecommerce powerhouse, trusted by large enterprise, developed and supported by a well-funded, well-staffed team. If you are not doing standard ecommerce, rather you’re chasing something unique, then CartThrob is for you. CartThrob was designed from the bottom up to support demanding designers (like ME!) edge cases, unique stores, wild customization, modular development, enhancements over time, and integration with existing data. In my past work as a developer/designer I’ve always been a perfectionist, and obsessed with challenging proposals. CartThrob grew out of my desire to have a tool that goes beyond the standard cart that could meet those challenges… something that doesn’t impose much on those that are creating the system, while reducing the need for a completely bespoke application for every project. No freaking limits… and no hacking the core!

What sold me on ExpressionEngine originally were the flexible channels (*cough*... weblogs) & the template language… the killer apps of ExpressionEngine. I’m personally very happy to have made them even more killer with the advent SafeCracker! I digress… When we started building CartThrob it was my mission to make sure that existing content could be monetized, to make sure that any data used in the cart could be shared and reused in other parts of the system without having to recreate EE’s successful template language, without having to recreate the data storage system, without having to recreate popular addons (Playa, LinkLocker [is this dead now?], and Ratings). We succeeded in building what I wanted to build… something that would give us the freedom to build what our clients wanted… without putting us in a position of saying “NO! THAT CAN’T BE DONE”.

Now that I’ve met MY goals we’re systematically meeting the goals of our customers… adding expected featuers that exist in a standard ecommerce app and simplifying what we already have. It disappoints me a bit to even have to worry about one feature or another sometimes, as in my experience we’ve built so many of them using nothing more than standard EE template code, BUT I get it… the out of the box features make our customer’s lives easier, speeds up their development, and simplifies our tags and methodologies… so we continue to refine. We acknowledge valid criticisms… especially in the case of the post purchase process. We advance, one day at a time.

All of that said, I’m a dreamer, people. I’ve loved building sites that amaze, that provoke a reaction, and that make a connection. Though I don’t actually build websites any more it pleases me to no end to see what our customers have done with CartThrob. They’ve built sites that make me proud and that go well beyond what I conceived of myself. Sites that make me smile. Nice.

Isn’t it fantastic that we’re at a point where we’re contrasting the pros and cons of ecommerce on ExpressionEngine? Where were we even a year and a half ago? Whether one app or the other fits your style… just the idea that ExpressionEngine can be even remotely considered a valid ecommerce platform… it’s awesome. Looking forward to the future!

I am very happy about this post and that it expresses some real world examples of experiences using BR and CT. I am obviously bias toward BR so I don’t think my thoughts on the pros/cons of these two add-ons would be objective or useful for people trying to compare them.

What I can be objective about is our intention for the direction of BR. We have built many sites in many different platforms but we want to work in EE. We also want to build great websites and perfect BR as we go forward. Our intention with BR was to build features that can be customized, not tools to build the e-commerce features you need. Our intention was to provide the developer/design/client with bricks rather than with the concrete, stone, clay or what have you. We can not compromise the quality of our e-commerce websites but we can improve the speed which we launch them using BR.

Most e-commerce websites are unique but that doesn’t mean you can’t include best practices. As we add new functionality and features with each release they do not come from just the needs of our clients - they come from the needs of your clients. This is the reason the EE community and support tickets are the biggest influence on our roadmap.

Lets work together to made EE + add-ons the choice for more clients. Use the right add-on for the project and let that define which one is the better fit for your client. If a prospect or developer doesn’t think BR is right for them, guess where we send them?

This is one of the best posts I have ever started. Thank you so much everyone. Both products have their own advantages and disadvantages. This is what makes EE such a great CMS.

This is one of the best posts I have ever started. Thank you so much everyone. Both products have their own advantages and disadvantages. This is what makes EE such a great CMS.