Lots of good discussion here. I'll chime in with some of my thoughts: - Satchmo needs to have a custom set of management screen that makes it easier to do things like add products, ship orders, manage contacts, etc. The admin won't be going away but it will be an admin and not the primary way of managing the store. I envision this as a separate Satchmo app that can be easily configured or extended. If someone doesn't need or want to use it, they won't have to.
- I view reporting the same way. We should have some simple reports that can be easily extended by the developer if they need to. The lack of any reporting is a pain right now. My reference to the satchmo reporting snippets on github was just to try to get the discussion started. There's lots of interest but no activity. I was hoping to jumpstart some activity not endorsing a specific approach. IIRC, the original poster was just try to help out and wasn't claiming their solution was the right one. Just that it was a start. - Regarding the general coupling of Satchmo's parts - we've made much progress in this area but there's still room for improvement. Any specific suggestions or ideas are appreciated. - Back when LFS was started we had some dialogue about working together. At the time, it just didn't pan out. I'm not opposed to it & would like to do it but I think the LFS folks had some pretty strong design differences and wouldn't be interested. It would be a non-trivial task to merge things together. There may be other ways to unit efforts but I'm not sure what that would look like. In summary, I'm hoping to make some progress on the first two items but I need some design help. The actual development isn't really the hard part - it's getting a decent UI in place that works. I tried my hand at design with the default Satchmo theme and you see how that turned out :) I need someone that's better at it than I to help put the building blocks in place. Once that's done, fleshing it out shouldn't be impossible. My experience has been that a blank slate is intimidating. If we get something that's decent in place, people will chime in with improvements. -Chris On Wed, Aug 4, 2010 at 4:18 AM, Albert Pi <[email protected]> wrote: > >As a long time lurker on django-dev, I would certainly differ from the > assessment that this is a 'top feature request' there. > However, I am not discrediting your attempt to stir up discussion on > this topic. If there are good ideas out there, lets have them! > > I meant satchmo-devs, of course, although django-devs are taking admin- > related things into account, design-wise, lately: > http://code.djangoproject.com/wiki/DjangoDesign I think the same can > be done in satchmo, think about what's the best way to manage a web > store admin, not just CRUD. Plain CRUD is great for developers, not so > much for users. > > >That said, many of my frustrations with Satchmo is that it attempts to be > everything so it takes some effort to ignore/disable its dependencies on 3rd > party apps (django-registration et al). > > I feel it's not just 3rd party apps, it's satchmo itself. I feel it's > too tightly coupled somehow. But again, satchmo-devs are trying to > improve this, I'm sure, to make it more flexible, modular. > > >The trick is making concrete proposals and effectively channeling the few > developers out there that have spare cycles to spend on this task. > > Maybe we could learn from other e-commerce solutions in this matter. > For example, I've been playing with enstore ( http://www.enstore.com/ > ) and its admin is refreshing: http://bit.ly/9i7v2H (Picture of the > Admin). And I'm not talking about aesthetics, CSS, nice icons (which > don't hurt at all, on the contrary), but about simplicity, about > exposing data in a smart way, about design. As a matter of fact, > Enstore uses Django, or at least, parts of Django: > http://www.enstore.com/support/documentation/templates/language > > I was also wondering if satchmo-devs have contact with other django > open source e-commerce packages, like django-lfs ( www.getlfs.com ). > And if they are sharing and joining efforts and code. Or if they're > following completely different paths. > > Good and fair points, John, and very well put together. Thanks for > responding. > > > To conclude, I think Satchmo is amazing, right now; and I'm sure it > has required a lot of effort, and they (Chris, Bruce & co.) keep > improving it, listenting to, sometimes, pointless feature requests and > opinions from us, users. Thanks for that. > > On Aug 4, 8:58 am, John-Scott Atlakson <[email protected]> > wrote: > > On Aug 4, 2010, at 1:14 AM, Albert Pi wrote: > > > > >> I'm pretty sure the topic of reports has been addressed before on this > list > > > > > Indeed, it has been addressed before, cause it's one of the satchmo > > > weak points right now. I'm sure it's in django-devs agenda, among top > > > feature requests. And I'm just asking about it again, to know the > > > current state of the question. > > > > As a long time lurker on django-dev, I would certainly differ from the > assessment that this is a 'top feature request' there. > > However, I am not discrediting your attempt to stir up discussion on this > topic. If there are good ideas out there, lets have them! > > > > >> Pardon my skepticism that code can reach perfection in merely 19 > commits. I tend to abstain from undocumented projects > > > > > Regarding satchmo reporting tools, I recall Chris Moffitt saying it > > > could be a starting point: > http://bitbucket.org/chris1610/satchmo/issue/1166/canned-reports-in-s... > > > > I am merely an end user and developer of custom Satchmo installs. I have > no place to contradict what a core developer may deem desirable in the > official distribution. > > That said, many of my frustrations with Satchmo is that it attempts to be > everything so it takes some effort to ignore/disable its dependencies on 3rd > party apps (django-registration et al). > > The reporting tools may very well turn out to be some sort of 'start'. > Again, I have not dug through the undocumented code. I was just voicing > skepticism on this point. > > > > > > > > >> I do not say this flippantly but, having worked for many real-world > clients, I lack the imagination to envision a single tool for clients to > generate the ad hoc queries they inevitably require. > > > > > I'm sure you can think of some basic -non ad hoc- basic queries, every > > > single satchmo store would benefit of, specially if it's simple, maybe > > > graphical, and you can get an idea of how is your business/products/ > > > categories going (this year, month, week...) at first glance. Read > > > "Rachel" comments: > http://groups.google.com/group/satchmo-users/browse_thread/thread/96a... > > > > Sure, I can imagine simple reports. I'm just saying that none of my real > world clients request these sorts of reports. They always want very specific > and aggregated reports that require bundling certain categories of products > (but not other categories), etc. which requires a bit of automation and a > bit of hard coding. I haven't yet seen the light on how I can abstract this > into a one-size-fits-all. > > > > >> Concrete ideas/proposals? > > > To modify and adapt the admin according to satchmo needs, to begin > > > with. > > > > I'm completely in conceptual agreement with the recent proposal to spin > off the Satchmo 'admin' interface from the Django admin interface. Again, I > feel too often that apps like Satchmo and django-cms try to monkey patch > their way into the admin or otherwise proceed as if they are the only app in > town. Of course it's tempting to leverage the conveniences of the admin, I > get that. But the reality is that these monkey patches do not always play > well with others or even make for a compelling user experience. A few of my > client's refuse to use the Satchmo bits of the admin, requiring us to > manually manage products for them...extremely low margin, uninteresting work > but the clients can't be bothered to sort out the undocumented and > perplexing bits of the admin. So yes. Django's admin is a pretty decent CRUD > interface. Satchmo could do with a tailored interface. Agreed. > > > > The trick is making concrete proposals and effectively channeling the few > developers out there that have spare cycles to spend on this task. I wish I > had that sort of time, but sadly I barely have time to submit patches for > documentation typos/gaps at the moment. > > > > > > > > > > > > > Thanks for taking the time to reply, John. > > -- > You received this message because you are subscribed to the Google Groups > "Satchmo users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<satchmo-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/satchmo-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
