Benoit Tremblay - the web, what matters. Simple.

quote bar

Decision making

December 21st, 2009

The role of the number of persons involved in decision making. Too many persons involved = screwed.

Getting everybody involved in decision making is a good idea to please everybody, but it’s impossible to take the best decision.

It makes everybody feel part of it, but makes making the decision actually impossible: too many compromises are involved.

Analytics: Why Are They Leaving?

December 18th, 2009

Analytics: it's not only about how many visitors you have and where they're coming from, it's also a lot about why and how they're leaving

Doing Crap Vs Changing Things

December 17th, 2009

Doing crap is the easy way out while changing things is a totally different game. What are you doing right now?

Self-proclaimed Expert Vs Real Expert

December 14th, 2009

Self-proclaimed expert Vs Real expert. The self-proclaimed expert claims he's good while the real expert doesn't have to prove he's one.

Complex problems

December 12th, 2009

Complex problems can't be solved by making random moves

Pleasing everybody

December 10th, 2009

Pleasing everybody usually leads to average results

Where’s the magic now?

December 7th, 2009
Blog, twitter, Facebook, now what?

Blog, Twitter, Facebook: Now, where's the magic?

Building Websites: Theory Vs What Matters

December 6th, 2009
Is your website worth visiting?

Is your website worth visiting?

3 Open Source Alternatives to Traditional PHP e-commerce Solutions

November 5th, 2009

purchase

I’ve been evaluating a lot of e-commerce solutions lately for a particular project I’m working on and I’m really disappointed by the open source offering in general: most e-commerce solutions out there are just heavy and/or a total mess to customize.

Because we’re talking open source here, most platforms are built using php. I wouldn’t say that the reason they ended up this way (messy) is because they were built using php, but for me it was a great opportunity to look for other e-commerce solutions built using newer programming languages like Ruby and Python.

This quest for e-commerce solutions built with new technologies and best practices in mind led me to a couple of very promising platforms built with Ruby on Rails or Python Django.

I’m not going to review the solutions in this post as my goal is only to raise the awareness about the simple fact that if you’re not satisfied with the current classic php platforms like OSCommerce, X-Cart or Magento, there are some decent alternatives.

Let’s have a look.

Spree shopping cart

spree

I have to admit that so far, Spree is my favorite solution. It’s built using the popular Web framework Ruby on Rails and it’s very lightweight and clean. One could argue that it’s lightweight because it’s still missing a lot of features most php carts have, but it’s actually pretty complete for such a young product. You can have a quick look at the features list here.

Among the features, you will find localization, extensible design, use of css frameworks, custom tax and shipping rules, advanced product categories, SEO friendly, one page checkout and many others.

Another great thing with this solution is the community. Like any open source project, one of the most important aspect is the community support and also plugins built by this community. No problems for Spree, it delivers. There’s an active discussion board and also an extension repository with around 40 extensions ready for download and installation.

Visit the project’s website or have a look at the demo, it’s worth a look.

I haven’t tested spree yet in a production environment, but so far I’m impressed by what I see in my development environment.

Substruct

Substruct is another interesting alternative based on Ruby on Rails, but it is not as complete as Spree shopping cart. The project is hosted on Google Code and while that’s absolutely fine with me, the problem is that the project doesn’t have its own central website (with extensions, basic information, support, etc.) like Spree. It’s not as mature as Spree is.

If you have a quick look at the demo admin section, you’ll also find out that there are a lot of features missing and that it might be a problem to build a decent e-commerce website with all the functionalities you would expect.

substruct_admin

For very simple needs though, it could end up being a very lightweight and easy to maintain solution.

For more information (download, demo, support), visit the project’s Google Code page here.

Satchmo

satchmo

Satchmo is the third non-php e-commerce platform I’d like to cover. Unlike the other two solutions, Satchmo is built using the popular Python Web framework, Django.

I’ve heard a lot of good things about satchmo, but it’s a little bit painful to set up for the first time as you need quite a lot of dependencies. Usually I wouldn’t bother too much about that aspect as once your initial setup is all set, you’re good to go, but it could end up being a problem.

The problem here is that because of all the required dependencies, I would be worried about deploying this in a production environement on a traditional shared hosting. Feel free to have a look at the impressive requirements list.

The requirements might be impressive and the whole thing not that polished, but the feature list is pretty interesting. Among the features, there are some you won’t find in a lot of e-commerce platforms like support for downloadable and subscription products, support for rating and comments, related products suggestions and many more. Feel free to have a look at the features list for more information.

Conclusion

As mentionned earlier, this post was definitely not a review of every e-commerce solution out there: it’s more of a reminder that there might be some pretty good solutions that aren’t built using php.

I love php, but the code base of e-commerce platforms using php usually end up being really messy. In fact, it’s not just the case for e-commerce platforms.

Newer programming languages like Ruby and Python offer a lot of advantages over php and it’s definitely worth considering these newer languages for your next projects, being e-commerce or not.

If I’d asked my customers what they wanted, they’d have said a faster horse

October 20th, 2009

There is a great quote from Henry Ford on the first car he built:

If I’d asked my customers what they wanted, they’d have said a faster horse

It is by far one of my favorite quote as it relates very well to the Internet industry and the whole customer-business relationship. It’s easy to take it very seriously and to think that what Ford meant with this quote is to ignore your customers and just do what you think is right, but it actually goes deeper.

I’m pretty sure that if Ford had asked his customers what they wanted, they’d have said something like faster horses and the reason is fairly simple: they couldn’t imagine anything else.

In fact, they didn’t want faster horses, they wanted a faster personal transportation method. It’s as simple as that. For Henry Ford, achieving this goal was absolutely impossible with a horse, so he came up with the idea of building a car that everybody could afford. Nobody knew they needed a car before they saw the Model-T (and knew they could afford it).

Twitter anybody? Twitter is the tool you never knew you needed before you had it: nobody wakes up in the morning with the needs for a tool like twitter, but the aggregation of different persons communication needs eventually led to the creation of twitter.

Twitter is the first obvious one that came to my mind, we can find plenty of other examples.

Customer needs on the web

How is this all related to customers needs on the Internet and to the whole customer-business relationship (note that the term customer is used in a very large context and can be your website’s visitors, readers, the people you build websites for, etc.)?

In fact it’s very simple:

Users will ask for tons of very precise features and it’s important to understand that they ask these features because it’s hard for them to think outside the constraints your product, website or service impose them.

What’s really important is to understand what lies behind these requests.

Do your website’s visitors ask for a certain feature because they simply want more exposure (egosystem)? In this case, you might think of a better or different idea than the feature they’re asking for. A feature that really answer their need and that is not limited by the external view users have on your product.

Do the customer you’re consulting for wants a certain feature on his website just to better communicate with his potential clients? If so, what the customer want is to better communicate: the feature he’s asking for might not be the best solution.

Innovation and feedback

The problem when you innovate and do things according to core customers needs and not feature requests is that you have no clue how it’s going to be received. That’s why you need feedback.

I posted a talk by Kevin Rose last week, and he said the worst thing you can do as a website owner is to pretend you really understand what your visitors want. To avoid this problem, he recommends to build features very quickly, release them and then test (feedback).

All in all, I guess the key is to act according to core customer needs (not feature requests) and put in place a good feedback loop so you can react quickly and make good decisions. Agree?

Subscribe

rss feed Subscribe : A new sketch every morning

Receive this blog in your inbox by entering your email address: