Feature List / Database Structure

[Chris Jordan]

It seems to me that we should come up with a base feature list. A list
of must have features for the thing to even be of any use to folks. In
my mind this doesn't have to be an exhaustive list of features, but
just a bare minimum to get the thing going.

Then I think we ought to come up with a solid database structure, that
will support the feature list. We perhaps should also discuss database
field naming conventions. I personally, like very descriptive field
names, and so I avoid abbreviations or acronyms like the plegue. Also,
I typically use CamelCase when it comes to naming fields (and
variables, but that's another discussion, right? ;o). I understand
that some prefer the underscore_method. I don't particularly care
which we use as long as we decide on a way and stick to it.

I've already mentioned two features although they're sort of higher
level, and perhaps not necessary for an alpha version. Those were:

* Make the thing easily skinnable
* Come up with some scheme for developing plug-ins

[Peter Bell]

Probably want to consider breaking the app down into areas.

Typically I look at commerce as a product catalog, a shopping cart and a
checkout system. You also need an authentication/registration system, a
my-account system and an admin system. Breaking it down into each area, it's
possible to brainstorm features and then decide which ones to include . . .

Best Wishes,
Peter

[Chris Jordan]

Good thinkin'.

I think those sound like reasonable ways to divide up the program:

   * Product Catalog
   * Shopping Cart
   * Checkout System
   * Registration/authentication
   * 'My Account' system (a place for the user to edit their account details)
   * Admin

Each of these pieces are necessary for the program to even be usable, right? So should we break up each of these sections into a separate thread and have feature suggestions there? Or just keep it here?

I've not worked on a team before or on an Open Source project. So someone yell at me if this isn't the "right way" to do stuff. I'll start by assuming that we'll keep all these post in this thread

For the Product Catalog (and I think this fits under a couple of the above sections) I think it's maybe essential for us to allow the use of thumbnails and larger images separately. I would have thought this was a no brainer, but it turns out that osCommerce (which I'm using for one of my client's right now) only uses one image per catalog item. then they scale it down with the width and height css properties. That to me is a bad idea, as it slows things down considerably, if the image files are too large or not optimized.

Cheers,
Chris

--
http://cjordan.us

[Andy Jarrett]

I like where this is going. I've been mentioning in my other posts
that I think we need a core to start from something we can base all
discussions off afterwards. Your list seems pretty complete. Below
I've played around with the wording, and given an idea of a priority
order (i'm open to ideas)

* Back-end Admin
* Registration/authentication
* User Admin

* Product Catalog
* Shopping Cart
* Checkout System

Also don't forget that the CF team did a Pet Market/Store at
http://www.adobe.com/devnet/blueprint/instructions_cfhtml.html It
might be worth looking at this as well for ideas.

Andy J
www.andyjarrett.co.uk

On Oct 15, 5:12 pm, "Chris Jordan" <chris.s.jor...@gmail.com> wrote:
> Good thinkin'.
>
> I think those sound like reasonable ways to divide up the program:
>
> * Product Catalog
> * Shopping Cart
> * Checkout System
> * Registration/authentication
> * 'My Account' system (a place for the user to edit their account
> details)
> * Admin
>

>

> Cheers,
> Chris
>
> On 10/15/07, Peter Bell <pb...@systemsforge.com> wrote:
>
>
>
>
>
> > Probably want to consider breaking the app down into areas.
>
> > Typically I look at commerce as a product catalog, a shopping cart and a
> > checkout system. You also need an authentication/registration system, a
> > my-account system and an admin system. Breaking it down into each area,
> > it's
> > possible to brainstorm features and then decide which ones to include . .
> > .
>
> > Best Wishes,
> > Peter
>

[Mark Mandel]

I'm gonna sit by the sidelines and throw out ideas now and again :o)

Maybe it would be better if you guys started with designing the model
first.. rather than the DB?

Just a thought ;o)

Mark

--
E: mark....@gmail.com
W: www.compoundtheory.com

[Chris Jordan]

I think I know what you mean, but can you explain a bit more? By model are you talking about designing the different objects for each of the required features? I'm new to developing as part of a team, and like I told Nick back on the CF OS Contributors list, I'm still cutting my teeth on OO design concepts and techniques, and than I'm a complete noob when it comes to frameworks.

So, if you could clarify for me, what you mean that'd be great! :o)

Cheers,
Chris

[Mark Mandel]

Yup, that is *exactly* what I'm talking about.

You design your Object Model and your system API before you design
your database.

The database is simply a means to the end for your Object model.

Mark

[athanasiusrc]

I think that like the external site, the admin is going to need to be
broken down into a bunch of areas:

User management
Inventory Management
Data Entry
Reporting
Fulfillment which includes order processing, receiving and shipping
Content management
Marketing (if you want to have email blasts integrated with your
system)
Possible retail point of sale
Affiliate management
Data feed management (Froogle, Shopzilla, etc.)

Features that should be integrated into the catalog/checkout process:

Custom items with n options that can be priced per option selected
Personalization

Okay, I'm stopping there and going to bed.

[tpet...@gmail.com]

another idea is to look at other open source ecommerce projects out
there and see what features they offer. Currently I think the leading
project is oscommerce written in php.

http://www.oscommerce.com/

[athanasiusrc]

A few more considerations:

Integration is going to be key to getting adoption of the project.

Credit Card Processing:

Authorize.net
Worldpay
Google Checkout
Paypal

Shipping Info

Fedex
UPS
USPS
DHL
Melissa Data (address verification)

Mailing List Integration

Icontact
Lyris

Accounting Integration

Quickbooks
Peachtree

Datafeed Integration

Amazon
Ebay
Shopzilla
Shopping.com

[Chris Jordan]

This post has generated a good list of features so far, but I'm wondering if some of the ideas may be too lofty for the "first draft" of the program.

Shouldn't we be coming up with a list of base features to start with, and then developing our object model? Also, if we come up with a good system for adding plug-ins then lots of these things can be written as plug-ins (I think).

Any thoughts on that?

Also, I must admit I'm really enjoying the participation in this thread. I hope folks are finding it worthwhile. :o)

Cheers,
Chris

[Peter Bell]

Talking of credit cards - do you want to store them? Limited ability to
re-use and recharge cards on the one hand or a requirement to become PCI
compliant on the other. I'd probably suggest that the system not store card
details - what does everyone else think?

[Josen Ruiseco]

I think it should be a user configurable option. Obviously, turning it on
means a whole lot in terms of design and functionality. Many of us do
comply with PCI and need to store per our business requirements.

Josen

[Adam Reynolds]

I do think some of you are thinking too deeply about certain things.

You don't need to list a series of shipping agents. You need the
facility to import shipping pricing models.

Similarly with payment providers. Give example implementations but don't
start listing the ones you will want to see.

Your issues are one of providing a 'global' solution and not one that
appears to be US centric.

This means implementing different tax regimes as well.

Is anybody managing a wiki to manage the requirements set? Has anybody
else been involved in a design by committee project?

Adam

[Peter Bell]

I generally agree with you, but it's not bad to have a list of samples as it
makes it easier when you try to create a generic shipping or payment
processing API. I find that looking at a few concrete examples helps to
bring out issues that might otherwise not be apparent in a simple top down
design. You are however completely right that if this wants to be more than
a US only solution, the tax, shipping and payment processing implications of
that need to be thought through - even simple things like the different
fundamental approaches between sales taxes that you add (like in the US) and
those that are already built into the prices (more typical in the UK).

Talking of generic shipping, tax and payment processing API's - anyone got
anything they're willing to share and add to the specs?

+1 for the wiki - probably the best interface for capturing the requirements
- along with some kind of feed so we can keep a handle on the updates.

Best Wishes,
Peter

[athanasiusrc]

I agree that we want to keep the main ap "agnostic" in functionality
but these various integrations should be considered as plugins that
would be very nice to have available when the ap is ready to give
people a better argument for trying it out.

I am much more likely to use an ap that has a bunch of ready-to-use
plug ins available than one that will require me to write a bunch more
code to make useful.

Not having been into oop much, I think this will be a great project to
help out with since I was just wishing that there was an oop ecommerce
example ap that was more complex than the "Hello World!" aps usually
given as examples.

If you need a wiki set up somewhere, I can do that.

[Adam Reynolds]

athanasiusrc wrote:
> I agree that we want to keep the main ap "agnostic" in functionality
> but these various integrations should be considered as plugins that
> would be very nice to have available when the ap is ready to give
> people a better argument for trying it out.
>
> I am much more likely to use an ap that has a bunch of ready-to-use
> plug ins available than one that will require me to write a bunch more
> code to make useful.
>
>

Oh I agree, I just think it should be written and delivered with a set
of plugins in place. However those should be used as examples to allow
further submissions.

[Paul Marcotte]

Hey all,

Regarding wikis, Andy Jarrett has created a page within the google groups for the feature list. 

http://groups.google.com/group/cfcommerce/web/cfcommerce-feature-list

I'd like to suggest that we use the google groups pages as our requirements/spec and development notes wiki for group members and the trac based wiki for "how-to", installation notes for users (when we get to that point).


Paul

[Daniel]

keep in mind to store credit cards number in database is no legal in
certain countries unless you 'certified' ( to be certified is not a
cheap process...).

to add pay system (paypal, etc) should be possible with a plugin. the
differ also a lot from country to country.

daniel

On 16 Okt., 16:56, "Josen Ruiseco" <josen.ruis...@gomotorbids.com>
wrote:

> I think it should be a user configurable option. Obviously, turning it on
> means a whole lot in terms of design and functionality. Many of us do
> comply with PCI and need to store per our business requirements.
>

> Josen-----Original Message-----

> From: cfcom...@googlegroups.com [mailto:cfcom...@googlegroups.com] On
>
> Behalf Of Peter Bell
> Sent: Tuesday, October 16, 2007 9:45 AM
> To: cfcom...@googlegroups.com
> Subject: [cfcommerce:36] Re: Feature List / Database Structure
>
> Talking of credit cards - do you want to store them? Limited ability to
> re-use and recharge cards on the one hand or a requirement to become PCI
> compliant on the other. I'd probably suggest that the system not store card
> details - what does everyone else think?
>

[Daniel]

multi-language support is for me a key feature! it's best to implement
it right from the beginning.

mach-blog has a nice implementation of in18 to look at.

daniel

[Chris Jordan]

Can you provide a link to the example of how mach-blog handles language support.

I've been working with osCommerce recently, and found that they keep a folder called languages and under each one is a folder for the language:
   languages>english
   languages>spanish
   etc...
then in each of those language folders are files that define text strings, like TEXT_CHECKOUT_SUCCESS might be set to "Your packages will be delivered in 7-10 business days"...

This way, in the code all you ever see when they're outputting text to the screen is TEXT_BLAH_BLAH... then once per session, they figure out what language is preferred (or defaulted), and they use the defined strings from that language file.

I'd be interested in how other folks do that sort of thing.

Chris

http://cjordan.us

[Daniel]

[Multi-Language Support]

mach-blog uses 'java style' properties files
http://svn1.cvsdude.com/mpwoodward/machblog/trunk/i18n/

there are handled by a ResourceBundleService.cfc
http://svn1.cvsdude.com/mpwoodward/machblog/trunk/org/machblog/i18n/ResourceBundleService.cfc

which builds the wrapper for the methodes provide by Paul Hasting's
in18 components
http://svn1.cvsdude.com/mpwoodward/machblog/trunk/org/hastings/locale/

the approach used in mach-blog seems to me convenient and the
properties-files are easy to edit. there is even a
resourceBundelEditor-PlugIn for eclipse

Daniel
- > by the way apart of OSCommerce there is new php opens-source
commerce application to look at http://www.magentocommerce.com/

On 16 Okt., 19:14, "Chris Jordan" <chris.s.jor...@gmail.com> wrote:
> Can you provide a link to the example of how mach-blog handles language
> support.
>
> I've been working with osCommerce recently, and found that they keep a
> folder called languages and under each one is a folder for the language:
> languages>english
> languages>spanish
> etc...
> then in each of those language folders are files that define text strings,
> like TEXT_CHECKOUT_SUCCESS might be set to "Your packages will be delivered
> in 7-10 business days"...
>
> This way, in the code all you ever see when they're outputting text to the
> screen is TEXT_BLAH_BLAH... then once per session, they figure out what
> language is preferred (or defaulted), and they use the defined strings from
> that language file.
>
> I'd be interested in how other folks do that sort of thing.
>
> Chris
>

> On 10/16/07, Daniel <daniel.sch...@gmail.com> wrote:
>
>
>
> > multi-language support is for me a key feature! it's best to implement
> > it right from the beginning.
>
> > mach-blog has a nice implementation of in18 to look at.
>
> > daniel
>
> > On 16 Okt., 18:52, "Paul Marcotte" <pmarco...@gmail.com> wrote:
> > > Hey all,
>
> > > Regarding wikis, Andy Jarrett has created a page within the google
> > groups
> > > for the feature list.
>
> > >http://groups.google.com/group/cfcommerce/web/cfcommerce-feature-list
>
> > > I'd like to suggest that we use the google groups pages as our
> > > requirements/spec and development notes wiki for group members and the
> > trac
> > > based wiki for "how-to", installation notes for users (when we get to
> > that
> > > point).
>
> > > Paul
>

> --http://cjordan.us

[Chris Jordan]

Oh, that's cool! It's sort of like I was describing, only I think I like this better. ;o)

Thanks for the links!

Chris

On 10/16/07, Daniel <daniel...@gmail.com> wrote:

http://cjordan.us

[tpet...@gmail.com]

About handling resources.

This is something that I'm doing now in a project that I'm working. I
was going to use resource files, however the client wanted all data in
the database and didn't want files floating around for the
configuration. Basically they wanted each site to have their own
resource, but a master one that each site inherited from. The reason
for this was so that if a new site came online, it would use the
default resources and then they could easily update the resources they
wanted for that site

The solution I came up with was having a resource text field in the
database for each site and filling it with key value pairs like a
resource, for example:

TitleErrorCode:Title is required.
DescriptionErrorCode:A description must be provided.

You get the idea.

Now if you wanted to change the TitleErrorCode for a site, that sites
resource text filed would just contain:

TitleErrorCode:You must provide a title.

By doing this I'm able to pull out the resource text field for the
default site and create a structure out of it. Then I pull out the
resource text field for the site and override the resources in the
structure.

I have the code and if this sounds like something the team would
consider, I will post it to my blog for download.

On Oct 16, 3:50 pm, "Chris Jordan" <chris.s.jor...@gmail.com> wrote:
> Oh, that's cool! It's sort of like I was describing, only I think I like
> this better. ;o)
>
> Thanks for the links!
>
> Chris
>

> On 10/16/07, Daniel <daniel.sch...@gmail.com> wrote:
>
>
>
>
>
> > [Multi-Language Support]
>
> > mach-blog uses 'java style' properties files
> >http://svn1.cvsdude.com/mpwoodward/machblog/trunk/i18n/
>
> > there are handled by a ResourceBundleService.cfc
>

> >http://svn1.cvsdude.com/mpwoodward/machblog/trunk/org/machblog/i18n/R...

>
> > which builds the wrapper for the methodes provide by Paul Hasting's
> > in18 components
> >http://svn1.cvsdude.com/mpwoodward/machblog/trunk/org/hastings/locale/
>
> > the approach used in mach-blog seems to me convenient and the
> > properties-files are easy to edit. there is even a
> > resourceBundelEditor-PlugIn for eclipse
>
> > Daniel
> > - > by the way apart of OSCommerce there is new php opens-source

> > commerce application to look athttp://www.magentocommerce.com/

> --http://cjordan.us

[tpet...@gmail.com]

A feature to consider,

Something that would be great would be the ability to enter in
dropshippers as vendors. With dropshippers, you hold no inventory, but
instead forward the order to the dropshipper where they would fulfill
the order for you.

It would be great in cfcommerce if with dropshippers, if you could
assign an email address or webservice address. Then the system would
bundle all orders for that dropshipper and automatically send the
dropshipper the information. This makes the system completely
automated and it's a feature that no other commerce system that I know
of has.

[Chris Jordan]

That sounds like a good idea, tpetruzzi. I think it would make a better plug-in though, and probably wouldn't be a part of the core.  We should maybe start a thread that talks about different plug-in ideas so that we can keep track of them all in one place.

Anyone agree with me?

Chris

On 10/19/07, tpet...@gmail.com < tpet...@gmail.com> wrote:

A feature to consider,

Something that would be great would be the ability to enter in
dropshippers as vendors. With dropshippers, you hold no inventory, but
instead forward the order to the dropshipper where they would fulfill
the order for you.

It would be great in cfcommerce if with dropshippers, if you could
assign an email address or webservice address. Then the system would
bundle all orders for that dropshipper and automatically send the
dropshipper the information. This makes the system completely
automated and it's a feature that no other commerce system that I know
of has

--
http://cjordan.us

[Peter Bell]

It is a cool feature, and I did this for a client not too long ago. The only
thing that becomes a pain is the shipping costs as often you have to
associate different shippers or shipping rules to each shipment and then sum
them to get the total shipping/handling price. If you do this you may also
want to have the idea of an order having n-items but also m-shipments so if
some products are in stock and others are not the admin has the option of
sending out a partial shipment with different status and tracking
information per shipment. Just a thought . . .

Best Wishes,
Peter

[athanasiusrc]

What we have done is create an invoice automatically for all shipped
items. This lets us keep track of partial shipments with individual
tracking numbers.

For drop shipping with different shipping rates, we have created a
field in the items table for drop ship fee that gets added on to the
price if the drop ship is optional.

[Peter Bell]

The issue with associating drop fee price to line item is that it may
actually be associated to a collection of items from the same drop shipper.
If I buy 7 items spread across three vendors who drop ship, there will
usually be three shipping fees - not seven. It may make most sense to add
the idea of a "shipment" with a status (so you know which shipments are
where in the process) and a shipping fee, tracking number, VendorID, etc.

Best Wishes,
Peter

[modius]

On Oct 20, 11:52 am, "tpetru...@gmail.com" <tpetru...@gmail.com>
wrote:

> About handling resources.
>
> This is something that I'm doing now in a project that I'm working. I
> was going to use resource files, however the client wanted all data in
> the database and didn't want files floating around for the
> configuration. Basically they wanted each site to have their own
> resource, but a master one that each site inherited from. The reason
> for this was so that if a new site came online, it would use the
> default resources and then they could easily update the resources they
> wanted for that site

Using resource bundles has the benefit of being a defacto standard,
and the knock on of very wide support. If you are stuck with the task
of localising an app with several thousand labels (and that would be a
small app) then having the benefit of some industry standard desktop
tools rather than a web interface is going to make life for
translators a lot easier.

-- geoff
http://www.daemon.com.au/

[athanasiusrc]

That's a good point. Maybe having a default drop ship fee setup per
vendor that can be overridden on an item basis for exceptions would
work better. We call shipments invoices and associate distinct
shipping charges, tracking numbers and items with each. Drop ship
orders each have their own invoice.

[Chris Jordan]

I know that this sort of feature would be unwanted by my current client since they already have an invoicing system and it doesn't hook into their online store the way that most might. The programmer behind the accounting system (it's a custom written deal) doesn't want the web directly interfacing with the accounting system. Rather the accounting system runs a bot that polls the web for certain data once every five or ten minutes and creates invoices where necessary.

That's why I feel like this sort of thing should be a plug-in. I know, that's probably not going to be the popular opinion. It seems to me that it would be nicer to provide hooks into the program so that stuff like this can be added on rather than developed as part of the core. And maybe that's exactly what you guys are thinking and I've just missed that somewhere along the way. If so, then... um... cool. :o)

Cheers
Chris

--
http://cjordan.us

[Andy Jarrett]

Chris has a good point here.

We should be looking at creating something that is extensible enough
to handle this. But for the core we need *basic* (but complete)
functionality.

Andy J

--
www.andyjarrett.co.uk

[Daniel]

I agrree 100% with Geoff. I translated MachBlog to German. Even it's a
small app it's hard work and takes time. The use of a the
"ResourceBundleEditor" in Eclipse was a big help and much easier to
use than any webinterface.

Second, I always like to use the simplest technology for a task... and
text-files are easy to edit, you can also put them in subversion to
get versioncontroll.

Multi-Language support is still not in the featureslist... I hope I'm
not the only one
who votes for it ;-)

daniel
---
www.danielschmid.name

[Chris Jordan]

It's not? Oops... well, I definitely think the hooks for it should be there. Meaning that the thing will most likely be developed in English, but that we should treat English just like any other language and incorporate it just as we would German or French or Spanish or whatever.

Any thoughts on this? Did we all just kind of assume, like I did, that we would of course do language support but just didn't add it to the list? Thoughts?

Chris

[KevinR]

I don't know if this will help or just confuse but here is a link to
the feature list for a product called venda that has a very large
customer base.

http://www.venda.com/page/uksolutions#features

Kevin Roche

[Nick Tong]

@keven - thats a help - can you add them to TRAC?

 

Thanks :)

 

--
Nick Tong

web:         http://talkwebsolutions.co.uk
blog:         http://succor.co.uk
f..works:     http://cfframeworks.com
short urls:  http://wapurl.co.uk
green link: http://wapurl.co.uk/?4Z2YDLX