Determine and regulate language pertaining to shipping methods

On deeper review of the code, and in anticipation of some heavy lifting I'll be doing tomorrow and Friday to support a variety of quoted shipping services, I think we have a vocabulary problem. It's going to serve us well to clearly define terms, so this is my attempt. The approach I'm taking will be to consider the most complex scenario using terms that are sufficiently abstract to encompass the simpler shipping scenarios. Some terms are very loosely defined across the web, but others are more standard terms in the shipping industry.

• Shipping method - this is perhaps the most fluid term with no canonical definition. The one that seems to best serve us, though, is "the method of determining how a product will be shipped to the customer." This can include:
  • "flat rate" shipping, where a flat rate is chosen from a list of predefined rates based on some factors of the order
  • "weight based" / "quantity based" shipping, where a rate is calculated based on some base rate increased by unit of weight or quantity
  • "USPS" / "FedEx" / "UPS" or other methods where rates are calculated for a variety of services available for the order; these companies should be technically referred to as carriers
• Shipping service - this is the actual service selected by the customer for any given shipping method. This is a technical industry term used by all the major carriers that I've seen. Even though it seems odd at first, I think our simpler shipping methods should adopt the "service" language, even when our "services" are locally defined flat rates and calculations.
  • If I'm using flat rate, I might define a flat $10 rate for "Standard shipping" and $20 rate for "Expedited shipping" with a $0 rate for "Free shipping" on orders over a certain total. In this case, the service is standard, expedited, or free, and Rules will determine which services will be available for a particular order.
  • Using locally calculated rates will be similar to the above. The service will correlate to some configuration of the calculated rate (say a base price + $1 per pound).
  • With USPS, this will be something like Parcel Post, Priority, and Media Mail. With FedEx / UPS, it's other names like Ground, 2nd Day Air, Overnight. You can see a hefty lift of services per carrier here at ConnectShip. Note also that UPS lists everything it does under a services heading and that USPS even calls its various flat rates services.
• Shipping quote - this term is used to refer to a shipping rate quoted by a carrier or calculated locally for any given service. This term is a little funky, because in the case of flat rate, we are really just displaying the flat shipping rate (no calculations going on in determining the rate), so it's not like we're giving the customer a "quote" based on the contents of their order. I think the term is generally understandable, but we might consider a Magento inspired use of collect rates instead of calculate quotes since there may in fact not be any calculation going on.

Why does all this matter? We really need to be consistent in how we refer to these things in both the code and the UI. A shipping method should not be conflated with the services defined for or returned by the shipping method. A shipping quote variable shouldn't be referred to as shipping or shipping costs but as a shipping rate.

Additionally, we need to take a hard look at the use of CTools and our interaction with the checkout form. A user isn't selecting from among various shipping methods but rather shipping services. The merchant needs to be able to define conditions for the availability of shipping services, not shipping methods. This is the way I presume flat rate is working right now - you can define as many flat rates as you need in the form of separate rules, thus accommodating the scenario I mentioned above in my shipping service example. However, if I want to add a carrier quoted shipping method, I'm stuck. Conditions would be applied at the method level when they should be applied at the service level. Accordingly, I also need to have a unique price component per shipping service instead of method (which is impossible with the current plugin architecture).

I'm sorry for not sorting this out earlier, but I think it's important to get it right now. And please don't take my comment here as critique of the module's development; I understand carrier quoted shipping rates are more or less prevalent in different markets and that this module was developed with flat rate type shipping in mind. I don't fault anyone but myself for not trying to sort out terminology much sooner. : )