Site Sections: Satchmo Main | Wiki | Demo Store |

Conceptual integrity

Adam Gomaa has a well thought out piece on the differences between Django and Pylons. If you haven't read it, you should check it out. The gist of the article is that the concept of conceptual integrity really can be the differentiating factor in making a framework really work for the programmer.

Since Satchmo is supposed to be a framework for creating online stores, I think there are things to take away as Satchmo grows. For instance, we all know that documentation is important but this article helps to reinforce it from another angle. This quote -

Brooks says that moving something from being a program to a programming product takes three times as much effort as writing the program itself. This effort is put into documentation, maintenance, refactoring, and stability. This effort has not been put into Pylons.

really hit home for me. I don't like to throw stones but this quote could probably apply to OsCommerce. We need to keep in mind that Satchmo isn't all about cool new features. We need to make sure it is well documented, thoroughly tested and really stable.

One of the most difficult things for me is figuring out when to add features to Satchmo. When we first started, I was willing to add just about anything anyone wanted if I thought that it would make the application more appealing. Now, as more people use it and have suggestions, I find myself trying to figure out what we should add versus letting the end user add. This passage might be a useful guide:

When someone uses a framework - or, for that matter, a programming language - what they are really doing is delegating decision-making to someone who they think will have better judgment.

We need to make sure we are balancing the new features with backwards compatibility and stability. Overall, I don't think we're making any major mistakes but I do think it's important for me to pause sometimes and make sure the project is moving in the right direction.

So, how are we doing? What could we do better?

Posted on December 17, 2007 by chris satchmo

8 Comments

#1 jeff commented, on January 8, 2008 at 3 a.m.:

You aren't marketing yourselves well enough. When people hear of the great work you're doing, more developers will join.

#2 Chris commented, on January 8, 2008 at 8:16 a.m.:

Yes, marketing is key. I'm not sure what is the best way to do it without being obnoxious in the process. Also, sometimes I think I'm waiting for it to be perfect before we really make a huge splash. Perfection is probably not the right goal.

Any ideas folks have for more marketing would be appreciated.

#3 Leo commented, on March 18, 2008 at 6:08 p.m.:

Couple ideas on marketing:

- Try to encourage (not force!) developers to add satchmo badges to their sites (I plan to).

- Fix up the demo store. Being superficial, its the first thing I look for, that and screenshots.

- Ride on Django's coat tail whenever possible. Its immensely popular and people are still very curious about it, and what they can do with it.

- Build on the community!

- Make satchmo easier to install and try, especially within a hosted webserver environment (Try to encourage webhosts like webfaction to provide a panel installer for satchmo).

I found satchmo because I did not want to use any store that was not python based, to the point I was willing to build one myself. If I had been flexible in programming languages, I might have gone somewhere else (to my eventual agony I am sure). Essentially people should find satchmo by default and not out of chance (Don't know how to change that).

#4 Stefan commented, on April 27, 2008 at 7:48 a.m.:

What you could do better? Make a .deb package for Debian and Ubuntu.
This would help a lot. It makes it much easier to try out Satchmo.
When I look for an OpenSource solution to any problem, the first thing I do is "apt-cache search ...". I found Satchmo by looking for Webframeworks, then Python Webframeworks, then django. Then I had to read a lot, follow lots of links to lots of sites, until I found Satchmo.
This is clearly too hidden :-)

#5 Waldemar commented, on May 13, 2008 at 3:56 p.m.:

What about a greater focus on ease of use and making the framework more usable as an end-product (which would fit nicely with an ease of use focus) instead of moving all the work to the developer who uses the framework? Make it easier to get started.

Just a very simple example that immediately came to my mind when playing with the demo shop: it forces you to click the checkbox "Shipping same as billing?". Why not make that the default and make the respective form fields invisible?

Why not put the checkout form (maybe including payment details) directly below the cart instead of putting it on a separate page? That way, you can directly see what you buy and actually buy it; no context switching.

Why not move the "Login" box in the checkout procedure into the sidebar, so it doesn't take up space that could better be used for the actual form?

Why not get rid of the "update amount" buttons and simply auto-update the price when the user changes the quantity?

What about a nicer default template? I know, you only build a framework, but your demo shop really makes a poor demonstration of the product.

Regarding feature bloat, I think it's best to have an architecture that is modular enough to allow great flexibility for those who need it, but by default ship with a minimal system for a basic shop, so beginners don't get overwhelmed and can get started immediately. Most great open-source (and commercial) projects use that recipe to get around the hard decision of whether or not to incorporate a feature. By default, the answer is "no, but you can write a plugin".

I've written a blog post, based on my experience of working with open-source projects and I hope you'll find it useful (at least it fits the topic):
http://allbuttonspressed.blogspot.com...

Hopefully the comment is not too late. :)

#6 Chris commented, on May 25, 2008 at 9:07 p.m.:

Thanks for all the comments. They are helpful.

#7 Anonymous commented, on June 6, 2008 at 5:29 p.m.:

Until I see instructions/documentation on how to actually create a custom product module beyond just "add your module name to CUSTOM_PRODUCT_MODULES", I'm going to say that this whole article is a lie.

#8 Chris commented, on June 9, 2008 at 4:42 p.m.:

Anonymous -

I can appreciate your concern but don't see how this is a "lie." My point of the whole post is that we need to get better and keep this in mind. I see that developing new products is an area you think needs more docs. Fair feedback. If you are interested in helping, feel free to jump in.

Post a comment

Your name:

Comment: