Thoughts from Djangocon and request for your input

[Chris Moffitt]

I've been meaning to put my thoughts down from the experience at Djangocon but haven't gotten around to it until now. Overall, it was great to see all the folks and listen to the presentations. I enjoy seeing Django continuing to grow and mature and hope it will continue to maintain the open and participatory environment it has today.

The time at Djangocon was useful for me to reflect on Satchmo; where we've come from and where we're going. I continue to be impressed with how many people are using Satchmo and doing great things with it. On the other hand, I met a lot of people that said things like, "Satchmo looks great but the install is a pain" or "It's not flexible enough for me" or "the product model is confusing." After talking with Bruce, we agreed that now was a good time to stop and get some robust community involvement in defining Satchmo's future.

So, what do you think? We're going to close out the 0.9 release shortly (I'll probably start another thread for that) so we need to talk about things like:

- What do we need to do to bring Satchmo to the next level of visibility and usage?
- How can we get more developers/community involvement?
- What is stopping you from contributing?
- What is Satchmo missing?
- What warts need removing?
- What can we do so that at Djangocon 2010, we can feel that Satchmo is moving in a very positive direction?

I have a few ideas of my own:
1. Improve the install process.
2. Add some improvements to the admin to make routine tasks easier.
3. Improve documentation (need some specifics though)

Anyway, we really want to hear some feedback and ideas so we can solidify our roadmap.

Thanks!

-Chris

[Alessandro Ronchi]

2009/9/18 Chris Moffitt <ch...@moffitts.net>:

> 2. Add some improvements to the admin to make routine tasks easier.

This is a big point.
Something is very simple, for example:
- put search_fields for contacts and orders (and maybe for everything
in admin, it's free )
- add simple actions to orders (like "change status") to make it
possible from the admin list

--
Alessandro Ronchi

SOASI
Sviluppo Software e Sistemi Open Source
http://www.soasi.com

[Iain Mac Donald]

On Thu, 17 Sep 2009 20:26:03 -0500
Chris Moffitt <ch...@moffitts.net> wrote:

> 1. Improve the install process.

I don't think the install process is that difficult. The documentation
clearly explains each individual step. My perception of support
requests on the list, regarding installation problems, is that many
haven't followed those steps carefully enough.

Undoubtedly there are blog packages which can be installed from a
single command or double-click but that isn't a fair comparison for
Satchmo.

I quite like manual install processes as I get to see what is
happening. An automatic or scripted installation makes me nervous as I
don't know what it is doing to "my" system.

Perhaps there is an argument for an easy install local running demo
system just so people can take Satchmo for a spin but a real working
ecommerce site it will always take some work.

> - What is Satchmo missing?

There are two groups where Satchmo might get new users from. Those who
don't have a online shop and those who do. In many ways the wants of
those two groups will be the same. One difference will be the need (in
most cases) to import the existing store data. Making it easy to
import the existing data might tempt more to switch. Disclaimer: I am
currently working on moving two sites to Satchmo so this topic is head
of the queue for me.

Regards,
Iain.

[Jim Robert]

I can tentatively agree on the install process point, but not completely.

I would like the install to be simpler, but not at the expense of better docs.

given a choice between 2 hours of developer time spend improving the install docs and 2 hours on writing an install script, I'll take the docs any day.

Jim

[Ryan Headley]

I agree with the docs comment.  Even with the docs in their current state, I was able to getting a working installation.  Yea, there were some issues etc and there really needs to be a "First Steps" document that walks you through initial setup of your store.  (Store configs, payment settings, shipping, tax configuration, etc).

I was able to put together a bash script that grabbed everything you needed and throw it all in a virtuaenv.  My team ran that, and the macs had a few issues with PostGres -- but that wasn't Satchmo's nor my script's fault.

Docs are my #1 gripe, but digging in and bouncing around this user group has help enormously!

--
http://www.sudovi.com/
http://www.twitter.com/lifewithryan
http://www.thecommontongue.com
http://www.lifewithryan.com/

[Lee Packham]

I have to admit, I do wonder what this whole obsession with an install script is. The instructions are fine and, looking at the quality of people that come into #django these days (you know the ones that haven't even bothered to learn Python) the script just increases the number of people with zero knowledge trying to make stuff work.

Whereas, if they go through the process of installation, they sort of have to learn where everything is and start from a better base.

</rant>

[Ryan Headley]

Well hold on a sec though, I definitely see the value in the install script.

For instance, I'm the architect on my project.  I'm in charge of figuring out the hard stuff.  Then i have my team, some of which are template guys, not programmers really.  An install script that does it all allow me to have them run the script and be up and running from scratch in a short period of time so that they can get moving on what they need to do.

My install script even checks out the project for them...you don't want to have to go through the setup steps manually everytime you add someone to the team, so the value of an install script is high.

That being said, I do agree with doing it manually...at least once...to learn it.  But its not necessary for everyone on the team to do it from scratch...

[Chris Moffitt]

I can definitely appreciate the need to improve the docs. The question I have is, where should we spend the effort? Can someone give some ideas on which areas would be most useful for users that have Satchmo running but now need more docs.

-Chris

[Alessandro Ronchi]

On Fri, Sep 18, 2009 at 10:58 PM, Chris Moffitt <ch...@moffitts.net> wrote:
> I can definitely appreciate the need to improve the docs. The question I
> have is, where should we spend the effort? Can someone give some ideas on
> which areas would be most useful for users that have Satchmo running but now
> need more docs.

Maybe some more customization examples.

If you teach people how easy is to make new modules and how to
contribute them, more contributes will come I think :)

[Alessandro Ronchi]

On Sat, Sep 19, 2009 at 12:11 AM, Alessandro Ronchi
<alessand...@soasi.com> wrote:
> On Fri, Sep 18, 2009 at 10:58 PM, Chris Moffitt <ch...@moffitts.net> wrote:
>> I can definitely appreciate the need to improve the docs. The question I
>> have is, where should we spend the effort? Can someone give some ideas on
>> which areas would be most useful for users that have Satchmo running but now
>> need more docs.
>
> Maybe some more customization examples.

Another great way to make collective improvements could be a satchmo
snippet database: a collection of solutions for common problems,
searchable by words and tags.

[Harley Bussell]

The docs a pretty good and are easy to follow but it would be great if
there was some more guide style pages that explained full process with
code examples.
For example custom products comparing sub type and the inheritance
method. Or how to customize the livesettings of the site.

On the client side i'd love to see some kind of 1 page checkout
interface to make the process feel more modern.

Having a well designed default theme would be a huge help promoting
the system to new users and providing a base for customizations.
When using magento with the modern theme we could often just style the
general site theme and leave the cart styles in place.

In admin it would be nice to have some reports, products sold and
invoices details per day over a date range for example.

The admin in general could use some more visual components to help
sell the interface.
We have customized our admin dashboard with graphs of sales details
which makes the admin feel much more like a store.

Most of my requests are visual but its a weak area for Satchmo right
now and is an important part of getting new users.

[Bob Waycott]

- What do we need to do to bring Satchmo to the next level of visibility and usage?

Maybe it's just me, but I really feel like we could use some serious work on the default store look & feel, which means templates. I know both you and Bruce have expressed a hesitancy toward providing a default template that is rich in the way of client-side Javascript. From my perspective as professional who deals primarily in delivering and supporting e-commerce systems of varying degrees of complexity, the absence of Javascript is never on the menu.

I believe a robust and complete default template that looks contemporary to existing web trends would greatly enhance Satchmo's visibility as a professional solution. I also recognize that there are a number of arguments against this, to which I only have one response -- when in a situation where one is trying to pitch a Satchmo-based store to a client, they are more impressed often times by the "look" of the demo, rather than the promises of designs that have yet to be delivered.

 

- How can we get more developers/community involvement?

I think it could prove helpful, if there isn't one already of which I am unaware, to have some sort of a wish-list ticket, or similar place, where developers could view a list of desired features to work on. I have found that trying to tackle a bug can sometimes be daunting to me only because I battle a good bit of worry that I don't understand the existing codebase enough to really take on making changes.

Such a wish-list could provide a handy starting point for developers in the community to "adopt" a task, and hopefully remain on hand as the primary party who accepts responsibility for supporting bugs/issues/questions that rise. It might even be helpful for the community to have a better sense of who has adopted what features. Just a thought.

 

- What is stopping you from contributing?

Personally, I stay so covered in full-time work that I often wind up at home too exhausted to spend any serious time thinking about Satchmo. This annoys me, as I would very much like to invest more time in helping take it into the future. So, I guess I need to get off my lazy butt and start working. ;)

 

- What is Satchmo missing?

See opening comments on the front-end templates. I also second the recognition that a more customized admin is undoubtedly a necessity in enhancing the appearance of an actual store in the admin area. I have never liked that administering a Satchmo store is just working in the default Django admin.

I'd have to think a bit harder on what else Satchmo is missing.

 

- What warts need removing?

I think we could use quite a revamp of the Product catalog. Everyone I read on the mailing lists for both users & developers is developing their stores with custom product models. It seems to me that it would undoubtedly be wise to revisit the Product catalog's architecture from that vantage point. 

Guess I'd call the front-end templates somewhat of a wart, too. They just feel so 1998 to me.

 

- What can we do so that at Djangocon 2010, we can feel that Satchmo is moving in a very positive direction?

I have a few ideas of my own:
1. Improve the install process.

I'm in the camp of users who do not believe that one-click/single-command installs are the best option, in just about any scenario. I will admit that I am one of those annoying people who are given to "rtfm"s and suggesting that one learn a little something rather than expecting it to "just work."

To respond more directly to the comments here, particularly Ryan's, I come from a development house where we have lead developers, which seems to be a pretty standard paradigm. In any sort of development scenario, there should always be one person who goes through each and every step & knows the requirements and installation process inside & out. When you hit the point that the setup/installation needs to be duplicated, I think it is best to write one's own installation script, or whatever easier, more helpful message one wants to devise to duplicate the development environment. This ensures that Satchmo developers have things setup in whatever way is best for their needs. That's how I've always done development, and it's always easiest. Then I'm never supporting someone else's installation script. I'm supporting mine.

 

2. Add some improvements to the admin to make routine tasks easier.

Seconded. I think we should make a definitive list of what these routine tasks are, and then we know where we stand.

 

3. Improve documentation (need some specifics though)

Maybe I'll try to start spending some time here. I love documentation. I love writing up docs in all their painfully thorough glory.

 

Now, to speak from the standpoint of a developer who is evaluating using any sort of project out there. Docs are always a primary and critical evaluative factor. But aside from good docs, I expect a project to work as advertised, be amenable to as much customization as I want to throw at it, and have a clear sense of its own strengths and weaknesses. I like reading from a project what it does, what it does really well, and what it sees as its own areas that are in need of improvement. That's basically where I get my wish-list idea from. Even if it is only a bulleted list on the project's website that answered the question, "If we had all the developer time we needed, here are the things we see that we need to work on, add, extend, etc."

Hope that helps some.

[Joe Boutros]

For the record, I hadn't looked at the docs in about 14-16 months, and
I was very pleasantly surprised when I saw the Satchmo pdf
installation/usage guide.

> - What is Satchmo missing?

1: some administrative niceties, tracking of internal costs, a sales
dashboard, reporting, etc
2: integration with shipping APIs (fedex?) so that real shipping
labels can be generated, submitted, and printed from the admin
interface
3: notify feature for out of stock items
4: ability to override the "allow order with no inventory" flag on the
product level

> - What warts need removing?

1: Inventory editor needs pagination. My client has a shop with
nearly 20,000 product variations. The inventory editor tries to build
a 20,000 item long form when that page is rendered thereby swallowing
up a webserver process for a while. I've added pagination and
filtering to our relatively old version of Satchmo, but I need to
track down the patch so I can update and submit it.
2: Our shipping modules don't always work properly. For example,
Fedex is currently broken for international shipments (complains about
state code). Would be nice to upgrade to modern versions of these
APIs. (I have a new Fedex module on the way, loosely based on this
project: http://code.google.com/p/python-fedex/ and suds)

[Aviv Greenberg]

On Fri, Sep 18, 2009 at 04:26, Chris Moffitt <ch...@moffitts.net> wrote:
> 3. Improve documentation (need some specifics though)

This is my #1 item. The satcmo docs are very brief and they are
oriented more towards Django hackers and not end users. Every
description is short and it kinda assumes that the user has a (or will
have a) sense of the project workings. I had to read some code to find
out how some stuff works. I don't have an issue with this approach but
it is less end-user friendly. There are a lot of assumptions that may
be clear to a programmer but are not very clear for someone who is not
interested in the project internals. There are also some missing stuff
(e.g payment modules).

IMO, The whole doc should be reworked - be more verbose, perfectly
complete, and aimed towards non-Django end users.

My statement has a bigger implicit issue in mind: who is the target
audience? You stated a goal to increase the number of satchmo users.
But, who are these people? Are they existing Django users? Are they
semi-web developers installing a final product just adding css?
Existing customers of an alternative (PHP?)?

If we define the end user better we would better know how to target them.

--Aviv
--

Mike Ditka - "If God had wanted man to play soccer, he wouldn't have
given us arms." -
http://www.brainyquote.com/quotes/authors/m/mike_ditka.html

[Chris Moffitt]

Since Bob spent so much time on his response,  I'll address a couple of points below:

On Sat, Sep 19, 2009 at 11:41 PM, Bob Waycott <bobwa...@gmail.com> wrote:

- What do we need to do to bring Satchmo to the next level of visibility and usage?

Maybe it's just me, but I really feel like we could use some serious work on the default store look & feel, which means templates. I know both you and Bruce have expressed a hesitancy toward providing a default template that is rich in the way of client-side Javascript. From my perspective as professional who deals primarily in delivering and supporting e-commerce systems of varying degrees of complexity, the absence of Javascript is never on the menu.

I believe a robust and complete default template that looks contemporary to existing web trends would greatly enhance Satchmo's visibility as a professional solution. I also recognize that there are a number of arguments against this, to which I only have one response -- when in a situation where one is trying to pitch a Satchmo-based store to a client, they are more impressed often times by the "look" of the demo, rather than the promises of designs that have yet to be delivered.

For the record, I'm not totally against improving the default store. I do agree that the default is a bit outdated and can appreciate that. I'm not a designer and it shows :) I will support updates in one of two ways.

1. Create an alternative skin that it much sharper and sexier than the current approach.
2. Make some incremental improvements to the existing store templates so they look nicer but don't introduce too much extra complexity into the templates.

 

- How can we get more developers/community involvement?

I think it could prove helpful, if there isn't one already of which I am unaware, to have some sort of a wish-list ticket, or similar place, where developers could view a list of desired features to work on. I have found that trying to tackle a bug can sometimes be daunting to me only because I battle a good bit of worry that I don't understand the existing codebase enough to really take on making changes.

Such a wish-list could provide a handy starting point for developers in the community to "adopt" a task, and hopefully remain on hand as the primary party who accepts responsibility for supporting bugs/issues/questions that rise. It might even be helpful for the community to have a better sense of who has adopted what features. Just a thought.

We could use something like Google moderator - http://moderator.appspot.com/ to poll the community and get some feedback... Might help to get some general themes out there. What do people think about that?
 

 

- What is stopping you from contributing?

Personally, I stay so covered in full-time work that I often wind up at home too exhausted to spend any serious time thinking about Satchmo. This annoys me, as I would very much like to invest more time in helping take it into the future. So, I guess I need to get off my lazy butt and start working. ;)

 

- What is Satchmo missing?

See opening comments on the front-end templates. I also second the recognition that a more customized admin is undoubtedly a necessity in enhancing the appearance of an actual store in the admin area. I have never liked that administering a Satchmo store is just working in the default Django admin.

I'd have to think a bit harder on what else Satchmo is missing.

 

- What warts need removing?

I think we could use quite a revamp of the Product catalog. Everyone I read on the mailing lists for both users & developers is developing their stores with custom product models. It seems to me that it would undoubtedly be wise to revisit the Product catalog's architecture from that vantage point. 

Guess I'd call the front-end templates somewhat of a wart, too. They just feel so 1998 to me.

 

- What can we do so that at Djangocon 2010, we can feel that Satchmo is moving in a very positive direction?

I have a few ideas of my own:
1. Improve the install process.

I'm in the camp of users who do not believe that one-click/single-command installs are the best option, in just about any scenario. I will admit that I am one of those annoying people who are given to "rtfm"s and suggesting that one learn a little something rather than expecting it to "just work."

To respond more directly to the comments here, particularly Ryan's, I come from a development house where we have lead developers, which seems to be a pretty standard paradigm. In any sort of development scenario, there should always be one person who goes through each and every step & knows the requirements and installation process inside & out. When you hit the point that the setup/installation needs to be duplicated, I think it is best to write one's own installation script, or whatever easier, more helpful message one wants to devise to duplicate the development environment. This ensures that Satchmo developers have things setup in whatever way is best for their needs. That's how I've always done development, and it's always easiest. Then I'm never supporting someone else's installation script. I'm supporting mine.

 

2. Add some improvements to the admin to make routine tasks easier.

Seconded. I think we should make a definitive list of what these routine tasks are, and then we know where we stand.

 

3. Improve documentation (need some specifics though)

Maybe I'll try to start spending some time here. I love documentation. I love writing up docs in all their painfully thorough glory.

 

Now, to speak from the standpoint of a developer who is evaluating using any sort of project out there. Docs are always a primary and critical evaluative factor. But aside from good docs, I expect a project to work as advertised, be amenable to as much customization as I want to throw at it, and have a clear sense of its own strengths and weaknesses. I like reading from a project what it does, what it does really well, and what it sees as its own areas that are in need of improvement. That's basically where I get my wish-list idea from. Even if it is only a bulleted list on the project's website that answered the question, "If we had all the developer time we needed, here are the things we see that we need to work on, add, extend, etc."

Hope that helps some.

Thanks for the comments!

[Lee Packham]

On 20 Sep 2009, at 19:20, Aviv Greenberg wrote:

>
> On Fri, Sep 18, 2009 at 04:26, Chris Moffitt <ch...@moffitts.net>
> wrote:
>> 3. Improve documentation (need some specifics though)
>
> This is my #1 item. The satcmo docs are very brief and they are
> oriented more towards Django hackers and not end users. Every
> description is short and it kinda assumes that the user has a (or will
> have a) sense of the project workings. I had to read some code to find
> out how some stuff works. I don't have an issue with this approach but
> it is less end-user friendly. There are a lot of assumptions that may
> be clear to a programmer but are not very clear for someone who is not
> interested in the project internals. There are also some missing stuff
> (e.g payment modules).
>
> IMO, The whole doc should be reworked - be more verbose, perfectly
> complete, and aimed towards non-Django end users.
>
> My statement has a bigger implicit issue in mind: who is the target
> audience? You stated a goal to increase the number of satchmo users.
> But, who are these people? Are they existing Django users? Are they
> semi-web developers installing a final product just adding css?
> Existing customers of an alternative (PHP?)?
>
> If we define the end user better we would better know how to target
> them.
>
> --Aviv
> --

^ This man speaks sense.

On a side note - to those that keep saying how great the docs are,
they still don't list the new dependency of Signals Ahoy - I just
checked them out and re-made HTML so it's assuming I mysteriously know
the dependencies ;)

Regards,

Lee Packham

[Lee Packham]

Addendum - I'm blind - the dependency is there - sowwy! The man still
speaks sense though.

[Nicolas Miyasato]

> - What is Satchmo missing?

I would have to say more examples dealing with signals, cart + payment
customization, custom templates and products and use cases. I think
that there are lots of people that learn mostly from examples.

Thanks a lot for this great project.

--
Nicolás Miyasato (miya)
http://nmiyasato.blogspot.com

[Bob Waycott]

I'd be happy to contribute & write up some docs in this vein. It's the one thing I feel I have a pretty solid handle on in Satchmo.

[Rachel]

I'll add to Joe's comments because I'm the client he's talking about.
I doubt there is much feedback here from actual users who the
developers are building their sites for. I can tell you as it stands
now, I would not have chosen satchmo based on just looking at it.
Everything from the admin to the general look and feel of the basic
site is very off putting. So much so that I'm sure Joe is tired of me
complaining about it. The lack of these core features would turn other
users like myself away. I have a very highly ranked site with
significant traffic and a good sales volume.

In addition to my web presence, I also have two brick & mortar stores.
The POS systems that I use there have significantly more tools that
are instrumental in the success of the store. My major complaints as
it stands now have been listed here below.

> 1: some administrative niceties, tracking of internal costs, a sales
> dashboard, reporting, etc

The sales dashboard is a vital necessity to the success if satchmo as
I see it. In my other POS systems I can enter in what my costs are so
it's recorded with each product. I can then either base the sale price
on a percentage of markup or by entering in a specific price when it's
not as simple as doing 2x cost or something like that. Right now, I
have to keep paper invoices and track what my costs are in separate
spread sheets, which is time consuming. While I can see what items
have sold, I have no idea how to easily tell what items are actually
making money for me or that I need to stock more of to keep from
having to reorder.

The other thing that would help with adding products (as Joe said, I
have A LOT) would be the ability to enter in a price when adding the
variations. As it stands now, the steps to add new products are
incredibly time consuming. Most of my products do not allow me to just
use the variations I've added to set the price (ie certain sizes =
+x.xx dollars). Being able to do this in one step would make it easier
for me to add new products which often have 20+ variations every time
I need to add something new.

I am not looking forward to tax time when I have to figure out my
sales manually. It would be nice to see in a report what I spent on
products, my sales revenue (sale price minus cost), what I spent on
shipping, my highest selling items as well as what my highest margins
on products.

This is the number one negative on satchmo. The lack of reporting
functionality is enough to make me want to scrap the use of satchmo
even though we are very far into development as the store is
integrated into other projects.

> 2: integration with shipping APIs (fedex?) so that real shipping
> labels can be generated, submitted, and printed from the admin
> interface

I've been using stamps.com to handle my labels and I have to copy/
paste each shipping address and copy phone numbers and emails. Again,
incredibly time consuming. Then I have to go back and paste my
tracking numbers into the comment field when I move things to be
shipped. I get about 10-20 orders a day and this becomes one of the
worst chores associated with my shop. You can tell that I hate Mondays
or if I've taken a couple days off because making labels takes a very
long time.

> 3: notify feature for out of stock items

I have no idea when an item goes out of stock other than manually
watching the variations or when a customer emails me asking when I'll
have something in stock. Customers also can't be notified when an item
goes into stock. This also helps with figuring out demand for the
product.

> 4: ability to override the "allow order with no inventory" flag on the
> product level

The site wide "allow order with no inventory tag" on the site wide
level does not help me because while that would apply to about 90% of
the items I carry, the ones that are generally high ticket and one
offs don't fit into that situation. Having to enter 1000 of something
I can order then makes it difficult at tax time when I need to recount
all of my inventory for tax purposes. On a product level would be
incredibly useful because then I can manage the inventory properly.

A "back order" (ie items that are expected to come back into stock
soon) and a "pre-order" option would be very useful. Customers would
be able to order items and know there will be a slight delay in
shipping. The pre-order option would allow me to sell custom made
items for customers to purchase where they know that the item will be
custom made to order for them and then can expect a wait time for it.
In this case I just picked up a new supplier that I simply cannot
spend the hundreds of thousands of dollars it would cost to carry
their entire line. They're very willing to have me offer their catalog
as a pre-order, I just don't have a way to easily notify them of this
option. My POS at one of my stores has a section for custom orders
where I can notify the customer via email when I log in their order
that the item has been ordered along with the expected date I will get
it, plus when it's been shipped out to them.

> > - What warts need removing?
>
> 1: Inventory editor needs pagination.  My client has a shop with
> nearly 20,000 product variations.  The inventory editor tries to build
> a 20,000 item long form when that page is rendered thereby swallowing
> up a webserver process for a while.  I've added pagination and
> filtering to our relatively old version of Satchmo, but I need to
> track down the patch so I can update and submit it.

This caused the site to crash several times. It's also incredibly time
consuming so when I was adjusting inventory, if a customer purchased
something after I'd had the page loaded and finally made my changes
and the system finished processing them, it would then over write the
accurate inventory causing items to be in stock when they weren't.
Joe's pagination helped immensely with this but it's still very time
consuming to find products with the amount of pages that I have. The
load times with the pagination make this page so that I can actually
use it.

> 2: Our shipping modules don't always work properly.  For example,
> Fedex is currently broken for international shipments (complains about
> state code).  Would be nice to upgrade to modern versions of these
> APIs.  (I have a new Fedex module on the way, loosely based on this
> project:http://code.google.com/p/python-fedex/and suds)

This is definitely something that doesn't consistently work. The other
thing that I get complaints on are due to the fact that it just fails
out and doesn't show shipping options that aren't available. Customers
then email in asking why they can't have specific items mailed first
class etc so an option that showed those options but with an
explanation that it didn't qualify for that shipping method would be
helpful.

It also shows predicted shipping times (which I don't know if that's
just in the templates or if it's editable) which don't specify that
it's after processing. So I get angry emails often saying that the
site said 2-3 days delivery time when they've ordered on a Saturday at
midnight. They expect that their order will be delivered in that time
frame from when they order, not from when it ships.

The other shipping option I would like to see is the ability to ship
from multiple warehouses. I have two locations that I ship from so
when a customer places an order and they've ordered two items, one
from my LA store and one for the Canadian, I lose money because they
only pay one shipping fee. If I were able to mark items by warehouse,
the additional shipping fees could be included as shipping fees
instead of markups on the Canadian products. Canada Post has a good
API from what I've seen and I believe Satchmo has it already but I
can't remember for sure off the top of my head.

If you have any other questions that you'd like input from a real life
user, please let me know. While it's important to have developer
feedback, I think input from users will help when trying to figure out
how to make satchmo appeal to a broader base of users. Not everyone is
lucky enough to have a development team, which is what it sounds like
everyone here is part of.

Rachel

[Bob Waycott]

Rachel,

Thanks for this. So nice to hear from a user. This just put a number of concrete items in my head that I'd be happy to make a branch and hack away, contributing back.

I think I'll re-read through this later & perhaps ask some clarifying questions if any come up.

Chris, Bruce, perhaps we should stick a "client" or "user" wish-list up on the site? Something that shop owners can use to submit desired features? Clearly this was more concrete than us devs sitting around trying to think things up out of thin air ... or at least it was for me.

[Bruce Kroeze]

This is a fantastic set of wishes/warts. Thank you so much. More
comments inline.

On Tue, Sep 22, 2009 at 5:57 AM, Rachel <rachel...@gmail.com> wrote:
>
> I'll add to Joe's comments because I'm the client he's talking about.
> I doubt there is much feedback here from actual users who the
> developers are building their sites for. I can tell you as it stands
> now, I would not have chosen satchmo based on just looking at it.
> Everything from the admin to the general look and feel of the basic
> site is very off putting.

Could you give more specific examples? Would a "skins" site similar
to TemplateMonster, but focused on Satchmo help this? I've been
kicking that idea around for quite a while and if people think it is
useful, I think I should launch it.

> In addition to my web presence, I also have two brick & mortar stores.
> The POS systems that I use there have significantly more tools that
> are instrumental in the success of the store. My major complaints as
> it stands now have been listed here below.

Satchmo POS is out of my area of expertise, though I'm interested in
figuring out how to accomplish something like that. I think an API to
interact with the store from a desktop app (or another web app) would
probably be a huge step to that goal.

>> 1: some administrative niceties, tracking of internal costs, a sales
>> dashboard, reporting, etc

I am comfortable saying that these are on the "near-term" list for me too.

> The sales dashboard is a vital necessity to the success if satchmo as
> I see it. In my other POS systems I can enter in what my costs are so
> it's recorded with each product. I can then either base the sale price
> on a percentage of markup or by entering in a specific price when it's
> not as simple as doing 2x cost or something like that. Right now, I
> have to keep paper invoices and track what my costs are in separate
> spread sheets, which is time consuming. While I can see what items
> have sold, I have no idea how to easily tell what items are actually
> making money for me or that I need to stock more of to keep from
> having to reorder.

Finally, a concrete example of what we need from a report. I've been
asking for this forever, but people usually simply say "we need
reports", and clam up when I ask "what reports are the highest
priority?"

I've been thinking for some time that a simple Excel export of sales
would be a huge step in this direction. You could use your own
workbooks & macros to develop the reports you want. It isn't a
cure-all, but it would be a big step in the right direction.

> The other thing that would help with adding products (as Joe said, I
> have A LOT) would be the ability to enter in a price when adding the
> variations. As it stands now, the steps to add new products are
> incredibly time consuming. Most of my products do not allow me to just
> use the variations I've added to set the price (ie certain sizes =
> +x.xx dollars). Being able to do this in one step would make it easier
> for me to add new products which often have 20+ variations every time
> I need to add something new.

If you add a price to the variation product, it will override the
price of the base product + the variation delta. You *can* do this
already, and it works perfectly. It is non-obvious that it works that
way, but it does.

> I am not looking forward to tax time when I have to figure out my
> sales manually. It would be nice to see in a report what I spent on
> products, my sales revenue (sale price minus cost), what I spent on
> shipping, my highest selling items as well as what my highest margins
> on products.

Again, thank you for the report suggestions. This is what I/we need
before we go building reports, and is the major reason not many exist.

>> 2: integration with shipping APIs (fedex?) so that real shipping
>> labels can be generated, submitted, and printed from the admin
>> interface
>
> I've been using stamps.com to handle my labels and I have to copy/
> paste each shipping address and copy phone numbers and emails. Again,
> incredibly time consuming. Then I have to go back and paste my
> tracking numbers into the comment field when I move things to be
> shipped. I get about 10-20 orders a day and this becomes one of the
> worst chores associated with my shop. You can tell that I hate Mondays
> or if I've taken a couple days off because making labels takes a very
> long time.

What are you suggesting here? Plugin modules to places like
stamps.com? Possible, but I'd never considered it.

>> 3: notify feature for out of stock items
>
> I have no idea when an item goes out of stock other than manually
> watching the variations or when a customer emails me asking when I'll
> have something in stock. Customers also can't be notified when an item
> goes into stock. This also helps with figuring out demand for the
> product.

Great idea, easy too. Have you looked at the "Satchmo-toolbar" I
recently added to Satchmo? It is a start anyway.

>> 4: ability to override the "allow order with no inventory" flag on the
>> product level

Another idea which is easy and has a big payoff.

> A "back order" (ie items that are expected to come back into stock
> soon) and a "pre-order" option would be very useful. Customers would
> be able to order items and know there will be a slight delay in
> shipping. The pre-order option would allow me to sell custom made
> items for customers to purchase where they know that the item will be
> custom made to order for them and then can expect a wait time for it.

Excellent idea. I had not considered the "pre-order" option, it makes
sense. For example, I have a fashion clothes client who does "trunk
sales", which are basically pre-orders.

>> > - What warts need removing?
>>
>> 1: Inventory editor needs pagination.  My client has a shop with
>> nearly 20,000 product variations.  The inventory editor tries to build
>> a 20,000 item long form when that page is rendered thereby swallowing
>> up a webserver process for a while.  I've added pagination and
>> filtering to our relatively old version of Satchmo, but I need to
>> track down the patch so I can update and submit it.

It was a complete hack that I did for a client. I can and will add
pagination to it. I think while I am at it, I will also add the
ability to filter products before editing inventory for them. I.E.,
edit inventory for the "widgets" category.

>> 2: Our shipping modules don't always work properly.  For example,
>> Fedex is currently broken for international shipments (complains about
>> state code).  Would be nice to upgrade to modern versions of these
>> APIs.  (I have a new Fedex module on the way, loosely based on this
>> project:http://code.google.com/p/python-fedex/and suds)

I look forward to seeing that.

> This is definitely something that doesn't consistently work. The other
> thing that I get complaints on are due to the fact that it just fails
> out and doesn't show shipping options that aren't available.

Extending the shipping API to give feedback about why certain methods
are disallowed is a great idea. I've been trying to figure out a good
way to allow for different shipping options for different addresses
(i.e. out-of-country) as well, and I have a few ideas.

> It also shows predicted shipping times (which I don't know if that's
> just in the templates or if it's editable) which don't specify that
> it's after processing.

It is editable in your yoursite/settings.

> The other shipping option I would like to see is the ability to ship
> from multiple warehouses. I have two locations that I ship from so
> when a customer places an order and they've ordered two items, one
> from my LA store and one for the Canadian, I lose money because they
> only pay one shipping fee. If I were able to mark items by warehouse,
> the additional shipping fees could be included as shipping fees
> instead of markups on the Canadian products. Canada Post has a good
> API from what I've seen and I believe Satchmo has it already but I
> can't remember for sure off the top of my head.

I do this for another client. I am happy to give you pointers if you
write me off-list. Not that difficult, actually.

> While it's important to have developer
> feedback, I think input from users will help when trying to figure out
> how to make satchmo appeal to a broader base of users. Not everyone is
> lucky enough to have a development team, which is what it sounds like
> everyone here is part of.

Honestly, this is what is holding some "obvious" features back in
Satchmo. Real-world input. Many of the features in Satchmo were
developed based on requests of clients of mine. I/We do not want to
simply add stuff we think is a good idea. We want to only add stuff
that is actually useful for real end users, such as yourself.

Thank you sincerely.

--
Bruce Kroeze
http://www.ecomsmith.com
It's time to hammer your site into shape.

[Joe Boutros]

Bruce,

> What are you suggesting here? Plugin modules to places like
> stamps.com? Possible, but I'd never considered it.

I think what would be better here is direct integration with USPS,
Fedex and UPS shipping APIs. The integration is obviously less
trivial than the rate APIs, however it is possible to create and print
shipping labels, as well as track package status via the API. This
would make an invaluable addition to the Satchmo admin. This would be
preferable over a clearinghouse such as stamps.com

[Simon]

2009/9/21 Lee Packham <lpac...@gmail.com>

Addendum - I'm blind - the dependency is there - sowwy! The man still
speaks sense though.

 

The man does speak sense. But I would say Satchmo has three target audiences.
Below I will list them and what I think we need to provide them.

Store holders

• A sexy demo store to help sway their decision.
• Improved admin interface.
• Documentation.

Store developers
This kettle of fish may not know or want to touch Satchmo code base. To get a store up and running
they just want to change a few settings and templates. As Python gets more and more PHP converts
this audience will increase. The other way of looking at it is the more we target them the more PHP
converts Python will get.

• Easy way to try out Satchmo.
• A sexy demo store to help sway their decision.
• Documentation.
  

Seasoned developers
Well that's us. The one's that extend Satchno to do funky things. We don't want the install script
getting in our way.

• Documentation.
  

So what does this mean for the Documentation. Well basically it needs to target three audiences. Store
holders want to know how to use the admin interface etc... This needs to be the easiest to find. Then the
store developers want to know how to Install, customise (settings, templtes) and deploy. Then there
are the seasoned developers but I think that runs on nicely from the store developers docs.

Talking about the Docs in terms of verbosity is a bit abstract. I think the Docs need to be concise (brief in
form but comprehensive in scope.)

[Chris Moffitt]

The more I think about this, the more I think it would be good to have a section of the docs that is tailored towards the end user of the shop.

Thoughts, ideas, patches and contribs are helpful ;)

-Chris

[Christopher Hart]

We built http://clairdelune.ca with Satchmo and have been very happy.

One sore area has been the need to tinker tirelessly with Reportlab
syntax and it's seemingly non-existent documentation. E.g. I just
closed a support ticket where an Order's ship_addressee had the "&"
character in it, preventing PDF invoice generation. Responded by
hacking the product order admin module to show fields for addressees
so the client can retroactively remove non-unicode characters that
cause the error (which is thrown as a deprecated string error and not
logged; only shown in template debugger).

This thread began to discuss Pisa as a replacement for trml2pdf:
http://groups.google.com/group/satchmo-users/browse_thread/thread/1cf6ff33b4ad56a6.
This would go very far in business terms since it seems to be a common
client request to be able to generate fancy reports in PDF.

As for Chris's concern that Pisa is GPL and can't be included with
Satchmo, that's fine... assuming that the pip+virtualenv thing
materializes one day.

If this becomes a priority anyone can email me to help out on it.

Links of interest:
http://pypi.python.org/pypi/pisa/
http://www.xhtml2pdf.com/demo
http://www.djangosnippets.org/snippets/659/

[C]

The debian maintainers patched trml2pdf to force everything to
unicode.

And upstream actually fixed the unicode conversion problem as well.
The headache is that trml2pdf went from a standalone package to a part
of openobject-server from openerp.
(bzr lp:openobject-server/trunk if you're feeling masochistic).

But I think you're on the right track to go with something else for
pretty reports in PDF.

On Sep 24, 2:45 pm, Christopher Hart <ch...@metameat.ca> wrote:
> We builthttp://clairdelune.cawith Satchmo and have been very happy.

>
> One sore area has been the need to tinker tirelessly with Reportlab
> syntax and it's seemingly non-existent documentation. E.g. I just
> closed a support ticket where an Order's ship_addressee had the "&"
> character in it, preventing PDF invoice generation. Responded by
> hacking the product order admin module to show fields for addressees
> so the client can retroactively remove non-unicode characters that
> cause the error (which is thrown as a deprecated string error and not
> logged; only shown in template debugger).
>

> This thread began to discuss Pisa as a replacement for trml2pdf:http://groups.google.com/group/satchmo-users/browse_thread/thread/1cf....

> This would go very far in business terms since it seems to be a common
> client request to be able to generate fancy reports in PDF.
>
> As for Chris's concern that Pisa is GPL and can't be included with
> Satchmo, that's fine... assuming that the pip+virtualenv thing
> materializes one day.
>
> If this becomes a priority anyone can email me to help out on it.
>

> Links of interest:http://pypi.python.org/pypi/pisa/http://www.xhtml2pdf.com/demohttp://www.djangosnippets.org/snippets/659/

[Dave Lowe]

I agree with your ideas, Chris, particularly improving the admin and
documentation. The documentation serves well right now to get someone
up and running, but I've found there's not a lot for when you really
get into a project. And because Satchmo is complex, I spend a lot of
time digging through the code trying to figure out what's going on and
what I'm supposed to do about it.

Another thing I'd love to see is improvement to the markup in
Satchmo's templates. I have to override a lot of templates simply to
convert the markup to web standards, convert lists from lines
separated with <br> tags to proper lists, etc. This isn't because I'm
fanatical about web standards (though I'm definitely closer to that
than the alternative), but simply to get things working correctly with
the stylesheet. I imagine changing up the markup might cause problems
for existing stores, but it would make deployment a lot easier I
think.

I'd like to see downloadable products get full support. I feel like
they're the red-headed stepchild of Satchmo right now because products
are required to have inventory numbers and the downloadable product
model forces you to store your files on the same file system.

Finally, a huge +1 for reporting.

[Rachel]

Sorry for the delay in replying. I've been really busy!

> Could you give more specific examples?  Would a "skins" site similar
> to TemplateMonster, but focused on Satchmo help this? I've been
> kicking that idea around for quite a while and if people think it is
> useful, I think I should launch it.

There is something just unfriendly about the layout. The organization
of the sections is confusing. It just doesn't have the same look as
other commerce sites which make them more appealing. A set of skins or
even just a more developed back end would help a user like myself feel
like I'm not using something that was cobbled together.

> Satchmo POS is out of my area of expertise, though I'm interested in
> figuring out how to accomplish something like that.  I think an API to
> interact with the store from a desktop app (or another web app) would
> probably be a huge step to that goal.

It would be nice to have something like that so you wouldn't need two
POS (ie webstore versus brick and mortar) inventories. It would
definitely help more consumers migrate as more and more brick and
mortar stores are managing both an online store in addition to their
traditional store.

> I am comfortable saying that these are on the "near-term" list for me too.

Thank god!

> Finally, a concrete example of what we need from a report.  I've been
> asking for this forever, but people usually simply say "we need
> reports", and clam up when I ask "what reports are the highest
> priority?"
>
> I've been thinking for some time that a simple Excel export of sales
> would be a huge step in this direction.  You could use your own
> workbooks & macros to develop the reports you want.  It isn't a
> cure-all, but it would be a big step in the right direction.

Right now I NEED to know what I'm selling. I don't have this right now
other than going into each item and seeing what it says I've sold.
Obviously this shouldn't be that hard to export because you've got the
fields there so the site knows what you're selling. I wouldn't
necessarily want it to have to export though. It would be nice if
there was some kind of trending type graphs or something so you could
see how sales have grown over time.

> If you add a price to the variation product, it will override the
> price of the base product + the variation delta.  You *can* do this
> already, and it works perfectly.  It is non-obvious that it works that
> way, but it does.

Yes, I use that for items like tshirts which are static variation
costs but what I'm saying is I can't use that function for the
majority of my products because say I have two types of earrings. One
is wood and one is gold. The difference between 2ga and 0ga in wood is
not the same as 2ga and 0ga in gold. So instead of having one gauge
variation, I'd need to do one for each material. Most of the
variations of my products also don't increase in price in a uniform
manner. That's why I'm saying it would be nice to be able to add the
price when I was adding the individual variations.

> Again, thank you for the report suggestions.  This is what I/we need
> before we go building reports, and is the major reason not many exist.

Thanks, I'm just trying to help by giving a POV from a serious end
users perspective.

> What are you suggesting here?  Plugin modules to places like
> stamps.com?  Possible, but I'd never considered it.

If not stamps.com, then one that works directly with USPS or the
various shippers. It would be nice to be able to click on an order
number and have the shipping label function actually fill out all of
the forms appropriately.

> Great idea, easy too.  Have you looked at the "Satchmo-toolbar" I
> recently added to Satchmo?  It is a start anyway.

We're using an outdated satchmo right now since it was a stop gap
solution. I'm moving to the newest version in the next couple of days
so I haven't had a chance to see this yet. The other thing is (and I
don't know if this has been updated yet) along the lines of when an
item is out of stock is that a parent product has a quantity amount
but I don't know why. It's usually set to 0 because the children have
the quantities so if I were to search for things with 0 quantity those
would probably all come up since the parent product quantity doesn't
reflect a relevant number.

> Another idea which is easy and has a big payoff.

Yes, it's huge for me since some items I can reorder easily and
endlessly where as others I have only a specific quantity and that's

it.


> Excellent idea.  I had not considered the "pre-order" option, it makes
> sense.  For example, I have a fashion clothes client who does "trunk
> sales", which are basically pre-orders.

Yes, this would be a HUGE plus for me and would allow me to carry
significantly more items without screwing up my tax time because I
have to report items I have in stock as assets, right now on those
items I just put in a huge number like 1000 so it doesn't ever go out
of stock but then that hurts me when trying to figure out what I've
really got and what I don't. Some times I may have 3-4 of something
and I'd like to be able to mark what I actually have in stock versus
something that is not in stock but that I can order for a customer.

> It was a complete hack that I did for a client.  I can and will add
> pagination to it.  I think while I am at it, I will also add the
> ability to filter products before editing inventory for them.  I.E.,
> edit inventory for the "widgets" category.

A search function in there would be great. Right now I have like 100+
pages with the pagination and I can't easily find items.

>

>  Extending the shipping API to give feedback about why certain methods
> are disallowed is a great idea.  I've been trying to figure out a good
> way to allow for different shipping options for different addresses
> (i.e. out-of-country) as well, and I have a few ideas.

The biggest thing that I always remind myself is that I have to do
things to satisfy the lowest common denominator and that is always
people who aren't web savy. My customers are ALWAYS saying "I paid the
extra shipping for priority and my order still isn't here yet" even
though I ONLY ship priority so they didn't have a choice. Trying to
make things idiot proof lowers costs on the other end in customer
service since I don't waste time answering the same dumb questions.

> It is editable in your yoursite/settings.

Great thanks.

> I do this for another client.  I am happy to give you pointers if you
> write me off-list.  Not that difficult, actually.

Awesome, I'm sure Joe saw this and has contacted you. Some have
suggested adding in the extra shipping costs into those product prices
but that still results in losing money depending on the combination of
items ordered plus it deters purchases who don't understand that the
shipping is included so they'll buy the product elsewhere because it
may seem like its 5-10 dollars cheaper from another store.

> Honestly, this is what is holding some "obvious" features back in
> Satchmo.  Real-world input.  Many of the features in Satchmo were
> developed based on requests of clients of mine.  I/We do not want to
> simply add stuff we think is a good idea.  We want to only add stuff
> that is actually useful for real end users, such as yourself.

If you have any questions or want to bounce any ideas off of me, feel
free. I'm more than happy to help.

[Ricardo Silva]

I migrated two stores from ZenCart to Satchmo by following the docs. It's a good documentation, but I think it would be better if it was a Wiki. I found a lot of outdated statements that I could have fixed if it was a Wiki (Or at least something like the Django Book, where we can comment and point it out on a per paragraph basis).

Regards,
Ricardo Silva.

[Marconius Cuthemustard]

Sorry for dusting off this old message, but has anything ever been done about this 'end-user' documentation?