Our Search for the Holy Grail of Shopping Cart Systems

Written by Michael Ferrantino   
Thursday, 12 June 2008 00:00

Many of our clients have always wanted the same thing from a shopping cart system: to easily edit their product content, put things on sale, track inventory, add new articles, blog, edit online policies and easily make shipping rate adjustments. In other words (and although it's not standard to refer to it in this way) they want a fool-proof CMS (content management system) included in the backend of their eComm system. In the early days, a good CMS system didn't really exist - but we're happy to say that there's been a lot of progress.

In this blog we're going to talk about our experience / review of the following carts:

  • Yahoo Shooing Cart
  • eBay
  • X-Cart vs. OSCommerce
  • CS-Cart
  • VirtueMart
  • Magento

Yahoo Shopping Cart

We have avoided implementing a Yahoo Shopping Cart because it never fit any of our client's long-term business requirements, and so we were not able to give it a good technical review. However, we have a close business associate that succesfully runs 5 or 6 different eCommerce websites all on Yahoo Shopping Carts. They chose Yahoo Shopping Cart because of the ease of implementation. However, the complaints they have is that they pay a separate monthly fee for each of the carts, even so they process all credit card transaction by securely funneling them into a 3rd party merchant gateway.

eBay

I've personally stopped using eBay (I was a user who successfully sold $thousands of dollars of goods on eBay) and also recommended that some of our clients operate ancillary stores there. However, I stopped using and recommending them because it became what I call, the Cheapskate's Shopping Cart System. Now don't get me wrong, if I find a bargain -I will use them again but I can't recommend setting up an eBay store because the results are sketchy.

X-Cart vs. OSCommerce

A number of years ago, we considered X-Cart but wound up going with OSCommerce for a fairly established small business client. After completing a technical review of X-Cart, we determined that we would need excessive development resources for a successful implementation, because X-Cart's base system only included an incomplete feature set. Even though it touted itself as "out-of-the-box" and "open source," solution, it really wasn't. So we went with OSCommerce for this particular client. In spite of our best efforts, the end result was the creation of a, "white elephant in a black box."

The whole elephant in the box problem was that our client imposed a must-have-feature of, "purchase without an account" -just a month before launch and/or at a time when development was better than 90% complete. In addition to it being a realized project management risk, we were faced with a technical challenge, that oddly colored our work with this particular client for years to come!

Client stated reason for purchase without an account: "Yankee Candle has it, we want it too." We said, "Okay - sure, it's a serious project management risk and, um, was never a feature that we originally discussed when we scoped the project and it does activate change control, but yeah, we'll do it." Oh, we did it - and the purchase-without-an-account feature conflicted with almost all of the other key features / functionality of the site. The end result: it eliminated any promise of an effective CMS for our client, because even so the system was up and running 99% of the time, it was just too delicate for anyone to touch, but us. What a nightmare.

On top of that, the OSCommerce "community" was progressively becoming a circus, with lots of in-fighting -and some very crack-developers being excluded from bulletin boards, etc. We vowed to never implement another OSCommerce system again - and we haven't.

CS-Cart

Modernica

Last year at BlueLab we implemented modernica.net on CS-Cart (the project was handed off completely after a successful launch). For the first time, we were wowed! From what we understand (but don't quote us on the specifics) CS-Cart was created by a group of renegade X-Cart employees, who wanted to improve things by actually delivering what developers, clients and end-users wanted. Ironically, the "purchase without an account" feature is standard on CS-Cart. I also want to mention that CS-Cart is also easily set up for clients who sell products that need to be downloaded. CS-Cart is a win, win, win for everyone concerned. The team at CS-Cart are also readily available for consultation as necessary. There is a small cost for the software, which is under $300 retail and about $100 less than that for developers.

VirtueMart

SpellBy.com

We've successfully implemented VirtueMart several times now. VirtueMart is an add-on Joomla component. So, let me talk a little about Joomla first. The first time we worked with Joomla was on an inherited project that was driven by a savvy publishing client who really needed a backend / CMS that would allow her to make multiple daily edits. Later this particular client decided to implement a shopping cart system because she wanted to get out from under the tightening restraints on self-publishers at Amazon. We chose VirtueMart, because, like Joomla, we thought it would give our client maximum control over her product, coupons, order processing, etc. In addition, for kicks and giggles, we decided to implement one of our internal projects, SpellBy.com on the Joomla / VirtueMart platform -and that has also been a success - even with a great deal of customization and code-tweaking.

Magento

We are closely watching Magento. While we haven't done an implementation yet, they're worth mentioning because the system feature-set is robust, with features like the ability to control multiple stores. We were in-touch with the Magento team back in our OSCommerce days - and they were highly responisve!

 

Client Retention and Attrition

Written by Michael Ferrantino   
Wednesday, 11 June 2008 00:00

One of the most common questions new web business owners ask us, is: "How long can you expect to keep a client?" My answer is always the same, "It depends."

A long time ago, while I was working as an assistant for a successful Boston photographer, he emphatically stated that anyone in the creative business can only expect to keep a client for 2 years. At that time, I thought his statement was cynical. However, he was only accepting the reality of his own business. At Blue Lab, our experience has been different - more varied.

Three types of clients you typically can't expect to retain and/or secure any significant ongoing business from:

  1. One-offs: Clients who want to develop an informational website (individuals, like freelance PR consultants, doctors, small non-eCommerce store owners, etc.). While we certainly take these clients - we don't expect ongoing businsss after launch.
  2. Under capitalized projects: We have consistently worked with clients who were trying to get great business ideas off the ground - from contests to travel, we saw these projects fail because additional funding failed to materialize (this is common in the business world).
  3. Under committed owners: This category of client pertains to small and medium sized businesses alike, where the owner / client is reluctant to take the necessary next steps to reach a tipping point with their business. Once the signs of this become obvious, it's best to let these types of clients go because they will consistently attempt to cut corners and micro manage the process of development.

Three types of clients you can expect to retain and/or secure significant ongoing business from:

  1. Content driven websites: Information driven websites that require continual content updates.
  2. eCommerce sites: Non-static products. Companies /owners that continue to innovate and respond to market trends.
  3. Non-technical creative firms: This includes advertising agencies, PR Agencies, design companies (usually small to medium sized businesses and freelancers). Establishing a relationship with these types of companies can bring consistent business year after year. They will usually serve as the art-director on the project for their clients.

By no means are the above lists all inclusive and there are, exceptions to every rule. At Blue Lab we have clients who have come and gone, others who have stayed with us for 4 or 5 years and some that have been with us since the our first day in business. So, I hope I have clearly answered question - because it really all depends.

 

Project Management 101: The Importance Of Your Team

Written by Michael Ferrantino   
Sunday, 08 June 2008 00:00

I decided to write this blog because 2 project managers at a publicly traded company recently asked me a hypothetical question: "what if the engineers tell you that a component that needs to be developed (using PHP) is going to take 3 weeks to complete - but you need it in 1 week?"

Before I address the above question, I think it's worth mentioning that web development teams are most commonly comprised of the following four groups:

  1. Stakeholders (owners, executives, marketing, editors, etc.)
  2. Tech (web developers, integrators, database engineers, IT specialists, etc.)
  3. Designers (graphic and UI designers)
  4. Project Manager (can be more than one, in hierarchical form)

The normal course of a project almost always begins with a directive that comes from a project's stakeholders (at large companies, it might be a visionary executive or at the grassroots level, an entrepreneur). If they're not already, it's important for marketing to be involved on a foundational level, so that advertising and pr campaigns can be planned well in advance.

With that said, it's now left up to the project manager to assemble the tech and design teams, create a schedule, identify dependencies, budget, and at times, function as gatekeeper, mediator, negotiator and peace keeper. In short, the project manager is the kingpin from which a project's success hinges.

Getting back to our hypothetical question. My first thought was that the team at the company in question was probably in trouble, most likely due to missed deadlines or unrealistic goals that had been imposed upon the engineering team in the past. The company thought that the solution to the problem would be to hire project managers who were highly skilled in various programming languages. However, this is a mistake due to confusion or lack of understanding between a tech lead and a project manager.

A project manager should have an understanding of a project's related programming languages, especially in terms of their respective limitations and current best uses. However, it is unprecedented for a project manager to be required to perform programming work, while simultaneously managing a project's development and coordinating the efforts of the various groups listed above.

My response to the question was that I would rely on input from my engineering team. It was at that point, I noticed the two gentlemen's eyes glaze over and ears fill with wax. What they also didn't know (and quite possibly might have been a foreign concept) was that my response assumed that trust existed between myself and the engineering team (and for that matter, between all the teams on the project). The answer here was so simple, that it was easy to miss!

Two things come to mind: Dilbert and Occam's Razor, which states that, "All things being equal, the simplest solution is best."

 

Project Management 101: Understanding Web Project Management

Written by Michael Ferrantino   
Thursday, 05 June 2008 00:00
At Blue Lab, we've successfully launched, maintained and turned-around hundreds of websites from eCommerce to informational. Since the mid 1990's, we have watched web technology grow and change --and we've learned a lot about what's commonly referred to as, "best practices" for web-development project management.
In the early days, I studied the project management body of knowledge (PMBOK) - and later the Rational Unified Process (RUP), where iterative development was born into and/or out of software development -and later web software development. All this was to unhinge designers and engineers from the classic waterfall approach resulting in bringing a product to market (online) as soon as possible (once a pre-determined minimum feature set was integrated).
Excellent Project Management is built upon two documents:
  1. The Project Plan, which includes the fundamentals: the team, schedule, milestones and budget.
  2. The Feature Specification Document: the blue print for development.
The industry standard software for creating a Project Plan is Microsoft Project. However, I also have experience using a secondary tool, Alexsys Team 2 - particularly for task management.
The Feature Specification Document is primarily authored by the project manager with contributions from the project's engineers, developers and designers. The beginnings of the document almost always begin with a project's business requirements and long-term goals. The Feature Specification Document is known as a "living document," which means that as a project progresses through the basic stages of development (requirements, team building, scheduling, development, integration, QA and launch), the document grows as in a journalistic fashion.
In lay-terms, the Feature Specification Document is the blue print from which engineers, developers and designers build the system. I should mention here that the Feature Specification Document is also the road map for building the data model and database (where applicable).
The Feature Specification Document is what future development teams and/or the webmaster will use as a reference.
The three most common reasons (or excuses) for not creating documentation are:
  1. It's costs to much.
  2. We need to just get the project launched now - we'll document later.
  3. Just let the engineers and developers build it (we don't need much project management or documentation - after all, that Tom guy who built MySpace supposedly did it while sitting on the beach).
When a project is not documented, the end result invariable looks sloppy - and in the long run, development is done twice. There's a saying, "if you buy cheap, you'll have to buy twice."
 
« StartPrev12345NextEnd »

Page 3 of 5

Featured Client: SmartLivingDirect.com

Featured Client: SmartLivingDirect.com

SmartLivingDirect.com carries smart energy saving products for the home, office, industrial workspace and construction industry. Check them out.


CNET News.com
You are here: Home Tech Blog
© Copyright 1997 - 2008 BlueLab.com. All Rights Reserved.
Powered by BlueLab.com: Since 1997.