The Farmisht Freelancer is a column for the (oft irreverent) discussion of all things related to being in the business of developing, building and theming Drupal sites. Farmisht is a Yiddish word with a nuanced meaning. Picture yourself waking after not enough sleep and stumbling around in search of coffee to help your eyes focus.

Don't Put the Cart Before the Horse (Sense)

I found myself having difficulty selecting a topic for this inaugural edition, sometimes a broad brush with a wide swath makes it challenging to focus. Then, the phone rang.

“I need a quote for creating an e-commerce site...nothing special...just the typical checkout,” said the potential client, at which point my brain displayed Run Forrest on a wide selection of flashing marquees. There was some possibility that his sentence-long spec would be the harbinger of fact, though much more likely (read: betting odds) that he: (a) Knew little-to-nothing about what 'typical' implied, (b) Knew just as little about how a truly 'typical' cart compared to the out-of-the-box cart, (c) Had even less of an understanding about stepping back and seeing his business with an eye towards specs, or (d) Was posturing its ‘typicalness’ in hopes of a lower price. My bet was on (e) All of the above.

There are many differences between being a freelancer and being a company, but one commonality is that both depend on the word of mouth from satisfied clients to continue and to expand their business. Some would say that the most important element of satisfying a client is that they end up with what they asked for. I agree, but with the proviso that it is in the freelancer’s best interests to make certain, beforehand, that the project specification will leave the client with not merely what was asked for, but what is needed.

It can be a hard lesson discovering that the two can be mutually exclusive, let alone that it is fairly common for them to be so given a raw client-authored spec. One way to best ensure that they are similar, if not the same, is to understand the business need, the limitations of the tool being considered to address that business need, and ask the questions that relate the two. In this edition we will look at some of those questions with regards to a very common source of want vs. need disconnect: the shopping cart.

Let us take a look at some of the Other questions; those often forgotten before a project begins, the answers to which come back as 'gotchas' later.

Will any information need to be captured beyond the standard billing/shipping contact info?

Always enumerate at the field level the data to be captured, its format, the location, the type of widget used to capture it (Select box? Radio buttons?) and the intended use.

What is the total number of product categories, subcategories and products?

This regards effort. Make sure that the effort is understood, so that enough time is budgeted and the task not dumped in your lap later. Sure, if that happens you can point to the project agreement, but at the point that you are forced to do that, your relationship with the client has hit a low point.

What is the most number of category levels?

Category levels can impact a number of things, such as the planning and design of category pages, the structure of drop-down menus, and the format of a user-viewable site map. If the quantity of anything can make a difference to its handling or presentation, find out what it is.

What is the total number of product options?

Effort is not always a function of complexity. Identify which tasks have the larger potential impact on elapsed time. Sometimes you can recover from overlooking something like this by throwing bodies at it, but not always. You can’t make a baby in one month with nine women.

Are there any dependent product options?

This could be a show stopper in regards to the budget. Dependent product options are a hole in the capabilities of most on-line carts. If you are a module writer and the client has the budget, you will love a “Yes” on this one, but only if you have identified up front the worst-case-scenario tasks regarding project constraints.

Do any product options affect a product's SKU, Price, Weight or Dimensions?

This is an example of understanding the limitations of the product/tool/platform being pitched and making sure that the business model falls within those limitations.

Will there be any product kits? Dynamic products? Products with variable pricing?

A dynamic product is one that doesn't exist until the buyer creates it: for example, 'Create your own gift basket.' Variable priced products, such as a salami that is priced by the pound, are very hard to accommodate with an on-line store, because the weight is not known until the order is fulfilled. Depending on how seasoned you are, these could very well be examples of not knowing what you don’t know. The more experience you have with the type of business need you are trying to satisfy and the tools you are using to do so, the less chance there is of that. If you’re bland (not seasoned in the context of the project at hand) consider obtaining some time from a SME (subject matter expert).

Will coupons, gift cards or gift vouchers be required?

Gift cards can introduce a requirement for multiple payment merchants; not a standard feature. There are many, many, many modules available for use with Drupal, but it is still common to find a requirement for which no contributed module exists. This is one area where assumptions can kill a project. Find the module, compare its description to your requirement, chat with a few people at #drupal-support to make sure the module does what it advertises, and carefully stroll through its current issue queue.

If on-line quotations will be offered, will the shipping weight and dimensions of each product be available at the time of data entry?

It used to be that shipping was based solely on weight, but these days you can ship a bowling ball for less than a wicker hamper, because the weight and the dimensions factor into the cost. Be certain that the data crucial to the project are quantified, qualified, and the process that will make them available verified.

Will invoices and other communications need to be themed?

This is a consideration that often falls through the cracks until the client is testing. Get an answer early, and get the graphic artist lined up. Identify resources you are going to need. They have their own calendars and priorities, which could very well be in conflict with yours.

Which reports will be necessary?

A recent client listed thirty reports that they expected, four of which came with the cart. Not all can be done with Views. Not everything that seems cookie-cutter is.

If on-line shipping quotations will be given, do you already have an API account with each intended vendor?

‘Jaguar’ tasks are the ones that wait to pounce in the dark and crunch your brain…the Murphy’s Law of risky tasks. The type best situated to do that are the ones where a third-party is involved in a way that impacts the critical path of the project (the time line that has the least or no flexibility) and over which you have no control. Try to have a contingency plan for these tasks.