In the ensuing 6 years, I’ve been going over and over what went wrong and discovered more lessons along the way: the market conditions were wrong, we were young and arrogant, and, for the most part, we didn’t really understand the magnitude of what we were trying to accomplish: to remind people, our goal was to launch a website in 16 countries (15 EU countries + the US) on day one, localizing our site for each of them. At the time (1999), no one had accomplished that broad a coverage (nor had anyone even tried to).
So it seemed a little crazy but, then again, crazy people had built Netscape, Yahoo, Ebay, and Amazon in the previous few years. So crazy seemed not only possible but it seemed to be the key to success on the Internet. The problems we encountered fell in a number of areas: currency exchanges, tax issues, language localization, integration with many fulfillment partners and a front-end experience that called for broadband connections. We basically wanted to build eCommerce 2.0 long before there was a web 2.0.
So fast-forward to now. Broadband uptake is nearing 50% in many of the target countries and the number of users has grown tremendously, governments have learned about internet ecommerce and now have specific rules relating to it. And integration across many system is what web services and mash-ups are all about. Do I smell progress? So let’s revisit my old post (which later was published in Business 2.0) points and look at them through the 2006 lens.
The Currency Problem
Back then, the 16 countries we targeted meant 16 different currencies.
Today, with the rise of the Euro as a unifying currency, the same 16 countries only have 4 different currencies (the UK still being stuck on the pound sterling and Denmark keeping its currency a national one pegged to the Euro. The US and the Euro are the other two currencies covered.) This greatly reduces the complexity of pricing models across Europe and makes the overall cost of managing the catalog much lower.
Back then, we actually had to build our own currency tracker, with people inputing the exchange rates daily into the system to keep everything aligned.
Today, you can get access to currency exchanges via web services (just off the top of my head, I can think of Reuters and CBS Marketwatch providing this type of data), therefore automating what was once a manual task and, once again, reducing administration costs for the catalog.
Back then, there was no consistency in the way taxes were assessed on goods sold online. The financial people at Boo.com version 1 spent a lot of time with a big 5 accountant group and a lot of local government to lobby for normalization of rules around taxes on cross-border business.
Today, because all of those governments understand the value of internet commerce and because many have worked in conjunctions with each other (through the G8 and the EU) to normalize rules surrounding taxation of goods sold on the Internet the problem is easier to solve.
Back then, we had to build our own systems to track all the vagaries of the different tax systems. It wasn’t a build vs. buy decision because there were no packages offered on the market to deal with this.
Today, you can buy software packages that has all the taxation rules built in so that problem is no longer one you need to build for. You can just buy the technology and let the vendor worry about the changes in taxation laws.
When we set out to build Boo.com, a strong component was the idea of offering the online store in the local language of the user. Boo.com was actually the first store to offer as high a level of customization by market and we had to make a number of changes to the e-commerce software package to make it into a globalized platform. Remember that, at the time, e-commerce was primarily the domain of US and UK companies so selling in a language other than English was rare. E-commerce sites which sold goods in non-English markets were generally customized on a one off basis but no one, prior to Boo.com, had attempted to have a single back-end system run multiple countries.
Today, more vendors are selling solutions which can be customized across a variety of western languages. The solutions are not yet perfect but, for the most part, they work (there are still a number of issues when it comes to localization across 2-byte languages, especially when it comes to site with mixed languages.) Back then, we also had to develop a content management system that could handle translation workflows and management of content in multiple languages. It wasn’t pretty but it worked and it required a lot of internal translation to happen. Each product had description, sizes, etc… available in multiple languages. That part was actually a fairly large management of content nightmare. Today, modern content management system can handle more complex workflows (allowing to track when translations are completed) and even can provide hooks to farm-out translation of the content to external parties. This substantially reduces the cost of a multi-country offering.
Integration with fulfillment partners
Back then, a fair number of people at Boo.com were experts in EDI (or electronic data infrastructure) because EDI bridges were the only way to integrate into our fulfillment partners. Web services didn’t exist so we had batch jobs triggering every hour to the warehouses at DeutchePost and UPS so they could pick, pack and ship the orders. This was expensive and probably the area where we lost the most money on a single transaction.
Today, services like fulfillment by Amazon provide the same service at a substantially lower cost and with less integration headaches as web services are making it easy to integrate their services into an e-commerce operation. That saving alone could justify the existence of Boo.com 2.0 (actually, it would be 3.0 as FashionMall tried to resurrect Boo.com once already).
No discussion of Boo.com can be full unless we talk about its front-end.
The Broadband Penetration ProblemÂ
Many people laughed at the attempt we made at creating a more user friendly interface to e-commerce. Back then, a more interactive experience meant using Flash. It was the only way to get a lot of parts moving together. Things like Zoom-In/Zoom-out or Rotate type of effects were hard to accomplish with DHTML and much easier to do so with Flash. Since XML didn’t exist, we didn’t have AJAX. Since we didn’t have AJAX, we went with Flash. Since we went with Flash, the assets were large. Since the assets were large and the average user was connecting via a 56k modem, the site looked slow.
The idea was that every click should feel snappy, a model now common with AJAX-based applications but we failed in one assumption, which is that broadband penetration would move at a faster rate. Our expectation were that 1Megabit lines (much slower than what one now gets via cable or DSL) would be readily available within a year. That was a very flawed assumption and we had not planned any contingency for any slower a deployment.
Selling clothes requires details
Another interesting challenge was that we were trying to sell clothes online. Evaluating a DVD, CD, or book online is easy. However, clothing is different: when people shop for clothes, they like to feel the fabric, look at the details in the fabric. That experience was hard to reproduce online. Back then, what we set out to do, in order to help mimic some of the experience was to have highly detailed pictures of the goods.Â
Every product was shot multiple times at a stunning 5 megapixels per picture (the highest possible resolution at the time). This meant picture files that were about 1-2 Mb per file, something that seems small in the era of Flickr and YouTube but was massive in the era of 56k modems. The advantage of such detailed pictures was that you could zoom in to a level higher than what you could do in a store (part of our attempt to compensate for the fact that you couldn’t touch the merchandise). Today, such level of detail is standard among most of the online clothing manufacturers and with more broadband lines, it’s no big deal.
Another innovation we introduced was the presentation of products in 3D. You could basically rotate every product in our inventory any way you wanted. This, at a time when QuickTimeVR was not on the marketplace. This meant getting our photography partners to come up with completely new approaches to taking product shots, sometimes requiring as many as 15-20 shots per product in order to get everything right. Those pictures were then taken into Flash and adjusted so that you could rotate the product and zoom in and out of it, a feat that now seems pretty standard, using QuickTimeVR.
All that photography work didn’t come cheap, especially when you consider that this was done across 5,000 products and that all the assets were then stored on our servers (Hard Drive space was nowhere near as cheap as it is now).Â
Another innovation was the introduction of virtual models you could use to try the clothes on. Today, Sears offers a lower quality version of what we were offering back then (their model still requires a reload of the full page to turn it.) Because all the products had 3D equivalent, modeling them was relatively easy and we decided to throw it in as an extra feature that helped enhance the user experience. Once again, because of the processing and bandwidth required to make that happen, the idea was ahead of its time.Â
So we now all know that chatty avatars on web sites are not a good idea. The concept behind Miss Boo was to help make the experience similar to that of a store, with a sales assistant (Miss Boo), helping you out. Our long term goal was to have Miss Boo attached on the back-end to a real person so we could have integrated IM while you were shopping (that plan never came to fruition as the company had other concerns after launch). In the process, though, we’ve learned that avatars are generally despised and probably helped many sites avoid them.
Because we wanted the experience to be a more communal one, we had a way for users to tag clothing (well, we didn’t call them tags, we called them “LaBOOls” (labels, with a Boo in the middle, get it?) in the great tradition of badly named things on our site). However, because there was no AJAX or other way to quickly get the data back and forth, it required a reload of the whole page after each tag was applied. The feature was quickly killed in order to gain speed but I can’t think of any other site that had tagging on products at the time (if I’m wrong, please rectify me in the comments).
The BooZine (Boo Magazine) was our attempt to create a more friendly, open tone when dealing with users. We didn’t want to be just a store, we wanted to engage the users. When our forums (remember, this is before blogs were popular) started filling up with vitriolic comments, we were forced to shut them down, closing a channel of communication for users to us. It was a real shame but I think our attempt can be mirrored in the way most web 2.0 companies now have a blog that they use to receive feedback from users.
A more mature market
Back then, few people were buying stuff online. Even fewer were buying clothes online and an even smaller number than that was buying hip clothing. Considering all the challenges Boo.com was trying to address, its target market was just too small to make it a successful business.
Today, blogs like CoolHunting, HypeBeastÂ or MocoLoco show that there is a market for the types of goods Boo was trying to sell. That, in itself, could be a good reason for Boo.com to come back: The market they were addressing is finally there. However, it may also be a reason for it to not comeback: theÂ market they were addressing now has competitors in it.
Was Boo.com the first Web 2.0 company?
I have to admit that I’ve been feeling a certain level of uneasiness about Web 2.0: to me, there didn’t seem to be much there that I had not seen before: web services (yup, done since 2000), user generated content (tried it in a limited fashion with with the “labools” and forums), more transparency (tried that with forums in the past), chatty tone (attempted at Boo). What I failed to realize is that where we failed was in the way we implemented things. But looking back now, the reason it didn’t feel new was that much of that experimentation was on our site only, not part of a more widespread phenomenon.
Another thing that got me thinking along the way of Boo.com as a Web 2.0 company was the excellent post on Pixel Acres about the visual design of web 2.0. Let me explain, picking points from the article:
Integral to Web 2.0 is harnessing the input of website visitors. Users can generate content for a web service, promote it in a â€œviralâ€ peer-to-peer fashion, and improve itâ€™s data quality through their opinions and preferences.
Users of Boo could create their model, share it with friends (following the UGC model, I guess). So the input component was there, as was the sharing one.
Most Web 2.0 sites come across as friendly, approachable and small-scale, using subtle design decisions to gain our trust.
Every decision about the front end was to make it appear friendly, chatty and hide as much of the complexity as possible (that’s why so many people thought what we were doing was easy but badly implemented).
Bright, cheerful colors dominate Web 2.0 sites… Bold primary colors suggest a playful, fun attitude and also help to draw attention to important page elements.
One word: orange. The boo.com site had cheerful colors all over the place (sometimes so cheerful that I worried it would be seen as a toy)
Rounded Everything: The friendliness of rounded corners is in keeping with the comfortable, informal tone of many web 2.0 sites… In a great FontShop article analysing the logos of Web 2.0, it was clear that rounded typefaces are all the rage. This smooth approach to type lends a modern playfulness to a companyâ€™s visual identity.
Yup, Boo.com was round, very round, even the logo and the fonts. From a visual standpoint, it was much closer to today’s web 2.0 site than the ones it lived among.
Most Web 2.0 sites devote prime real estate to the message that they offer a free service.
Well, we kept pushing our “Free” boozine (Boo Magazine) and looked at it as a way to hook people into coming back again and again to the site.
You wonâ€™t find any stock photography of smiling support staff on a Web 2.0 site – thatâ€™s a tactic favored by small companies trying to mimic large corporations. Simple icons and screenshots are the order of the day when it comes to imagery on Web 2.0 sites. 3D and beveled icons can lend elegance and polish to a page design that is otherwise fairly stark.
Boo.com was 100% stock photography free. It was all icons and cartoons.
A good Web 2.0 app ought to be lightweight and easy for users to grasp, and clever visual design and copywriting can help remove barriers to entry. Smart use of layout, color, type and copy can go a long way towards easing the pain.
Well, we failed on the lightweight end of things but the design was to be as airy as possible.
As far as Web 2.0 is concerned, bigger is definitely better. Bigger text, that is. Large text is easy on the eye, and coupled with snappy copywriting makes information easy to absorb. And now that accessibility is cool, itâ€™s possible to be a hotshot web designer and use enormous type.
… and back then, people said we didn’t make good use of the real estate because the fonts on our screens were too big. However, note that accessibility was inexistant at Boo.com
The layout of Web 2.0 sites might be described as minimal. With a focus on legibility and ease of use, good use is made of white space. White space allows important information to stand apart, provides rest for the eye, and imparts a sense of calm and order. Generous leading also makes text copy easier for the eye to follow. Some Web 2.0 layouts are so minimal that they verge on boring, but designed well, an uncluttered page can be incredibly tasteful.
Yes, we had a lot of whitespace.
Friendly, informal copywriting allows a more personal relationship with website visitors.
People complained that our content was too informal, actually. I guess taste has changed in the following years.
So, from a visual standpoint, we may have established some of the rules that are now considered good visual rules for Web 2.0 companies. Of course, feature wise, we didn’t have RSS (it had not achieved the level of popularity it now has) and worked largely as a walled garden (all interaction happened on our site) but Boo.com was probably sitting closer to a Web 2.0 sensibility than most companies that existed at the time.
Based on past history, the complexity that existed back then has largely disappeared, making it possible for Boo.com to exist in the web 2.0 world. The market has also evolved to the point where many of the innovations first introduced by Boo.com are now considered mainstream and where many of its barriers to entry seem to have disappeared. This means that Boo.com could have a chance at surviving this round. However, one would have to be careful about overspending on advertising (a crime that Boo.com was responsible of, with its massive multi-country ad budget). A question that remains on the viability of the brand is whether the errors of the past have damaged the brand to a point where it would not be able to come back. It is probably the most dangerous factor in the rebirth of Boo.com and, if the negative press of the past overshadows the re-emergence of this company, it could be a fatal flaw that could ultimately make this a bad idea.
I wish much luck to the parties involved in the relaunch. Hopefully, they won’t suffer from the same arrogance we suffered from in the first iteration of the company and will be able to build a strong business around this brand.