5 Keys for Multichannel Holiday Success

For the 2013 holiday shopping season, consumers will increasingly rely on marketplaces and comparison-shopping channels.  Amazon, Newegg, Ebay, Google Shopping — all have huge numbers of motivated shoppers.  Ecommerce merchants large and small can sell on these channels. But not all of them will do it profitably.

 1. Products. Identifying winning products is the first step. Research last year's best sellers, evaluate new products, and consider niche offerings and up-sells. 

2. Sourcing and inventory management.  Ensuring product availability is crucial. The necessity of placing orders early and check for add-on items.

3. Product content and feeds. Compelling images, descriptions, and videos are all important for selling products on marketplaces and comparison-shopping channels. Optimize your product content and data feeds.

4. Pricing. Understanding your margins is vital for profitable multichannel selling. Understand dynamic pricing and strategies for mass-market pricing.

5. Fulfillment. Selling on multiple channels can produce dramatic peaks in holiday sales volume, which can cause back-office catastrophes. Make sure your company is prepared.  

https://www2.gotomeeting.com/register/438169698

Writing Objects doesnt' make it OOP

Lots of developers understand that object oriented code offers advantages over procedural programming. And so, they begin working on creating objects in their own projects, and eventually feel pretty good about what they've done. After all, if they're using objects, their code must be object oriented, right?

Well, not exactly. They quickly find out just how limited their code is when they try to implement the concepts of object oriented programming, like reuse and extensibility. And they quickly find that their code is really procedural code wrapped up in classes, not the grand object oriented application they thought it was.

But how can you know ahead of time what kind of code you have? Is there a set of tools you can use to determine if your code is truly object oriented, or is it just procedural code wrapped in classes? Let's take a look at the hallmarks of truly object oriented code and find out.

Object oriented code splits responsibilities between classes.

The biggest indicator of truly object oriented code is whether or not it correctly splits responsibilities up between classes - a principle known as the single responsibility principle.

In object-wrapped procedural code (OWPC), many responsibilities will exist within the same objects. You'll have database connections being made, queries being run, data being evaluated, and even possibly display functions being performed. But truly object oriented code will break these behaviors apart into their component parts, focusing on each one individually.

Object oriented code is polymorphic.

So, I just used a big word: polymorphism. But even though the word seems scary, it's not: polymorphism is just a principle which means "one behaviour, many forms." For example, all SQL databases perform similar behaviors, but they have individual implementation details for connecting and passing messages around. A polymorphic database layer will implement a common behaviour for all the databases, and obscure the specific implementation details for each unique database type.

What this leads to is easy reuse of objects throughout your code. For example, you can switch easily from MySQL to SQLite if you have a true object oriented application that has a truly polymorphic database layer.

Object oriented applications apply dependency injection.

A truly object oriented application will correctly apply dependency injection. Often in OWPC applications, objects are instantiated directly, either inside classes or inside procedural files. But an application designed to be object oriented will utilize dependency injection as a means of allowing for inversion of control.

This is done in PHP usually in one of two ways: first, there can be a layer responsible for instantiating objects (usually a controller). Or, there can be a dependency injection container that holds (or creates) the objects needed in the application. Both approaches are reasonable, and both are widely used.

Object oriented design is challenging, but worthwhile.

The truth is that designing applications to be object oriented is challenging, frustrating, and extremely worthwhile. Conquering the challenges results in reusable, segmented, small bits of code that are easy to maintain, simple to understand and incredibly powerful when used correctly.

8 Ways to Save Sales from Negative Customer Reviews

1. Add link back to category that allows sort-by-customer-review.
2. Include star ratings on cross-sells.
3. Use Expert / Staff Reviews
4. Show money back guarantees right on product page when available.
5. Allow customers to ask and answer questions on your page.
6. Include manufacturer’s website URL and contact number on the product page.
7. Enable comments on customer reviews.
8. Know when to offer live chat.

Source: http://www.getelastic.com/thinking-positively-negative-reviews/

The Pros and Cons of One-Page Checkout

Shopping cart abandonment is an epidemic in online retailing, with some companies reporting that more than 60% of checkouts end without a conversion.

Preventing even a relatively small percentage of these abandoned carts would significantly improve revenues and profits.

While purchase price and shipping costs are the leading reported causes of shopping cart abandonment, ease of use is close behind.

Fighting Frustration

One increasingly popular method used to slash cart abandonment rates is to introduce single-page, Ajax-driven checkout forms that combine the convenience of a single page format with asynchronous form validation.

As we start this discussion of the pros and cons of single-page, Ajax checkouts, I need to describe why these two methods—one pagers and Ajax—are employed and what frustrating problems they seek to solve.

Single-Page Checkout is Faster, Easier to Understand

Single-page checkout is faster and easier so that more customers convert.

When you're trying to decide if your checkout process should be a single page or several pages, consider the analogy of a supermarket. When grocery shopping, consumers always gravitate toward the shortest checkout lanes or fastest cashiers. By definition, a single-page checkout is faster than a multi-page checkout if for no reason other than there are no additional pages to load.

Single-page checkout forms, particularly those that use JavaScript to march shoppers through the process, also provide better step-by-step visibility. Shoppers know what they must do and where they are in the process.

If you need more evidence, consider a simple A/B test conducted on the 2010 Vancouver Olympics online store earlier this year.

In the test, half of all potential customers were directed to a two-page checkout and half to a single-page checkout. Almost immediately, the single-page checkout proved to have a better conversion rate. In fact, the successful completion rate for the entire checkout process rose some 21.8% thanks to the single-page form.

Ajax Validates Forms Before Users Submit

If you have ever filled out a long online form, clicked submit, and then had the form erase everything they input and return a message like "address not valid," "passwords don't match," or "please answer question #2," you will understand the value of Ajax.

Ajax stands for asynchronous JavaScript and XML, and it is a web development technique that uses several client-side languages and server calls to make web pages more interactive or better performing.

Ajax's best trick, if you will, is getting data from the web server without reloading a page or doing server-like actions on the client side. In a non-Ajax web form or checkout, the user fills out the entire form and submits it. The form data is sent to the web server, and a server-side scripting language validates the form to make sure that it is filled out properly and completely. If there are errors in the fields, like a missing "@" in an email address or a missing postal code, the web server sends an error message to the browser, which reloads the page for the user to fill out again.

In non-Ajax checkout forms, if the shopper is lucky, the web server may return the field data along with the error message for the browser to render, so that not everything will have to be filled out again. But the process still takes time and can be frustrating, especially if the user doesn't completely understand what went wrong.

Ajax addresses this issue by validating the form while the shopper fills it out. Server calls—if needed—are made asynchronously without reloading the page or potentially erasing the form. Users get feedback as soon as a form field is complete (when the click into the next field), not once the form is submitted. In some cases, the JavaScript might be able to do the form validation without connecting to the server at all.

The PROS of Using a Single Page, Ajax Checkout Process

Having explained what both single page checkouts and Ajax forms seek to accomplish, it is time to address the advantages these techniques provide.

• More conversions As mentioned above, single-page checkouts may significantly improve sales conversions, boosting a merchant's bottom line.
• Better page performance While dozens of factors contribute to page load times, using a single, Ajax-powered checkout form should improve user experience. This is important since studies from Akamai, Shopzilla, Google, and Bing all suggest that consumers won't tolerate slow loading pages.
• Better customer satisfaction With better performance and no agitating form validation issues, customers should enjoy a better overall shopping experience.
• Advanced Interactivity Once a merchant has decided to add Ajax, it’s possible to make the page more interactive, which again, may improve customer experience.

The PROS to using an Ajax, one-page checkout process tend to focus on customers and profits. By contrast, the CONS tend to be development related.

The CONS of Using a Single-Page, Ajax Checkout Process

While there is generally no reason to use a multi-page checkout, there are things to consider when using Ajax.

• It won't work without JavaScript Ajax depends on JavaScript, if a user has JavaScript disabled, the page will revert to server-side validation.
• Some browser functions won't necessarily behave as expected—Because Ajax does not reload a page to update content the browser's back button will not bring the user back to an early step in the checkout as might be expected. There is a work around, but it requires more development time.
• Ajax requires more upfront investment Because Ajax will increase development time, merchants may have to pay a little more or use more development hours.

Ajax on the Scale

If you're trying to decide whether or not to employ Ajax in your company's checkout process, weigh the potential benefits in customer satisfaction and more sales with the additional development costs. Even after you make your choice, continue to test your checkout process, since even a minor improvement can mean more revenue for your business.