For some of you that requested to be added to the beta team consideration list know, I’ve been toiling with shipping calculations in Shopp as of late. Last week I sent out an e-mail to those who had asked to participate in the beta looking for input on what is really needed for calculating shipping costs in an e-commerce plugin for WordPress. I got a decent amount of response (thank you!) and was finally able to find a solution.

The Shipping Problem

The crux of the problem is that you can create a really simple shipping cost system, but at the expense of it not being flexible enough to capture costs very accurately. So how do you do that, and keep it as simple as possible?

I had already planned on adding real-time shipping estimates from shipping services eventually, but I really needed a solution for setting custom rates both until I get those modules developed, but also for those that don’t want to use them.

When I broke this problem down, I just couldn’t find a nice easy way to solve it. I did look at other solutions. It was either a gigantically complex shipping table with shipping classes and zones, or two little inputs for zone-only rates. I found both severely lacking, one for usability (the shipping table) and the other because it was too limiting.

Finding the Solution

My solution only came about after lots of conversation with my soundboard, longtime friend and collaborator, Dave – someone I’m sure you’ll be hearing more from as this project develops. When I still couldn’t come up with it, I sent out an e-mail to anyone who had expressed interest in the project asking for ideas, what their shipping needs were, etc. Thanks to all of you that responded!

All of the insight into what people were looking for was really enlightening. There was one resounding theme through all of the messages: “My needs for shipping costs are rather simple, so don’t over do it.” From a solution standpoint though, most of the messages seemed to offer very little that I hadn’t already considered. There was one message though, that even though it didn’t hand me the solution, it had some language in it that helped me think of the problem differently.

Method Calculators

What I came up with is a scalable compromise. Shipping rates are calculated based on shipping methods. This allows for different shipping “calculators” that will eventually allow me to add the real-time estimates in the future. Each calculator will have it’s own sort of sub-entry interface specific to how that calculator operates. You’ll be able to add as many as you like. Use just one to keep it as simple as possible, or multiple to offer your customers options and capture your shipping costs more accurately.

Geography

The second issue in all of this, is shipping zones. My solution is based on the same idea of a shipping table, but I think I’ve implemented it in a way that is far easier. The shipping table I looked at, gave you shipping classes identified by letters in rows with 5 shipping zones as the columns. Each product then gets a shipping class and when a customer enters their shipping information, it can calculate based on which zone that customer lives in. I thought that this was on the right track, but to make it easier, you really need to know which countries fit in which zones at more or less, a glance.

I realized that this is a case of finding the right level of detail to simplify the data entry process. Say you operate a store in the US. To capture shipping costs with the most accuracy possible (and with the most complex data entry), you would have to setup rates to: each of the 50 states, the countries closest to you (Canada & Mexico) and then each of the regions of the world (Central & South America, Asia, Africa, Europe, etc). Of course, setting up rates for one shipping calculator with 58 different rates, is a bit much to manage. So I boiled it down to 3 absolutely necessary rates: country (domestic), geographic region (continental) and everywhere else (worldwide). In the same scenario, you can still capture costs at the most important geographic “cost tiers” and will not be completely overwhelmed in data entry and management.

To add that extra bit of flexibility, I even added an option (that must be enabled in the settings) to turn on domestic regions if you operate a store in the US or Canada. For calculators that use shipping zones, instead of having one country (domestic) rate, you get 4 regional rates (like Northeast, South, etc) for the US and 3 regional rates for Canada. So if you need that level of detail, you can have it. It’s not as accurate as setting rates for all 50 states, but it’s better than having to manage that many rates and you are still able to capture some of the extra cost of shipping from Maine to California, versus Maine to Florida.

Not bad eh? At it’s maximum complexity, you’ll have 6 rates to enter. Of course, if you’re using a tiered rate system, you’ll have to multiply that by however many tiers you use. Probably most important of all, they are not labelled “Zone 1″, “Zone 2″. They are labelled naturally using “USA”, “North America” and “Worldwide” for example. Or if you’re in Ireland, you’d see “Ireland”, “Europe” and “Worldwide”. Much easier to keep track of than ambiguous zone numbering.

Status of Development

Last week’s development wholly focused on solving the interface challenges of implementing this solution. I happy to say the interface is done and working great! It really makes it easy to use, at least to me. I’ll let you, the store owners tell me what you think in the beta.

The core work for implementing the shipping calculations in the shopping cart/checkout is also done. What I am now left with is to convert all of this into a better engineered, modular architecture that will allow development of different plug-in shipping calculators. This will provide for the development of the real-time shipping estimates from service providers down the road and will make managing all of the other calculators I have planned much nicer from a developer’s perspective.

All of this work is way over and above what I had originally planned for shipping, but I felt it was necessary enough for the system architecture foundation that it needed to be done for the 1.0 release. Unfortunately, with that and other development work on my plate, it looks like the beta won’t start until the end of May, with the release sometime at the end of June or beginning of July. Once the shipping is fully in place, I can start sharing screenshots since the interface won’t be in flux as much as it has been.

Thanks for taking the time to read this very dry report on shipping calculations. I’ll have more next week.

Of course, I’m always interested in your thoughts about my approach. Sound like I’m on the right track? Or does it sound like I’m over doing it?

You can leave a response, or trackback from your own site.