eCommerce and

Whether you're a business that buys or sells, you've probably heard of EDI. For those of you that haven't, EDI is an acronym that stands for Electronic Data Interchange. EDI is used when two entities want to share a standardized form of data. For example, a buyer sends a seller a Purchase Order EDI file. The seller then sends an acknowledgement EDI file. Then the seller might send a shipment notification EDI file, followed by an invoice EDI file. Makes sense, right? Seems easy…

We've built our own flavors of data interchanges before. However, we had not used the ANSI X.12 industry standardized EDI. We leveraged everything from simple flat files over automated email or ftp to xml via web service, each with agreed upon formats between us and suppliers or vendors. It's easy to do. You say, "Here are the fields and format we're going to send." They say, "Great! Here are the fields and format we're going to send." You both work to parse the data appropriately and agree on a delivery methodology and transaction schedule. So, why use the ANSI X.12 industry standardized EDI? Great question. I'm still trying to figure it out.

We were sort of forced to build it. By "sort of", I mean we were completely forced to build it. As in, one or more strategic partners says, "Oh, if you want to do business (/continue to do business) with us, you'll use this form of EDI." OK. No problem. How hard could it be? One would think that it wouldn't be that hard, as EDI has been around since the 1980's. This was back when data networks and a high level of computer competency was not a mainstream requirement of modern business, especially small businesses. Even the modern version of the standard still looks like it was built in the 80's. It also looks like it was built by a group of guys that desperately wanted job security. Yes, the files are in a standardized format. However, each file includes a copious number of optional elements, and a field representing one piece of data in one file type. For instance a Purchase Order file is formatted completely differently for the same piece of data in the next file type, like shipment. As I was working on the EDI project for our company, it occurred to me that this must have been the inspiration for XML. Someone was staring at this, saying to themselves, "No! Don't make me redefine the field for each stinking file type!" Also, the file has a flat file format, but it's delimited in the weirdest way. You have to build your parser to count out segments and account for optional fields. At least all of our partners utilize each of the standardized documents the same way, right? Nope. Each one takes their interpretation of the standard and we end up having to apply parsing logic by file type and by sender. Doh!

Pay Per Kilocharacter?

But, dealing with the building and parsing of files isn't the really irritating part; and truthfully, we're going to have to do something special for each of our business partners whether we use standard EDI or homebrew XML solution or something else. The REALLY irritating part is the delivery medium that you may be forced to use to communicate with EDI partners. As I understand it (and I could be wrong), back in the day, a very few telecommunications companies controlled data networks. These companies were regulated by government, and in order to charge for specialized services, like assisting in the transfer of critical business EDI files between two business entities, without regulation, they needed to create a new kind of service. So, Value Added Networks (VANs) were born. VANs serve as a go between, like a post office, offering various file transfer mediums, levels of security, tiered and specialized reporting, storage services, et al. You send a file up to your VAN, who holds a mailbox for you, and your VAN checks your file to ensure that it includes the right headers for the appropriate file type, stores your file and alerts your trading partner of a new file ready for exchange. That's it. That's what a VAN does, nothing that you couldn't do yourself. It's not like I can't store the files myself. Storage is cheap. It's not like I can't find a file transfer medium that works securely (simple things like FTPS or SFTP should not be tough for any IT guy to set up really cheaply). The best argument I've heard in favor of using a VAN, so far, is that it eliminates the need to let others have some access to your network. This came from one of our partners. To this I say, "Fine. We won't connect to your network. You can push and pull files on our network." Again, setting up the file transfers is not that hard and also doesn't expose your network to uncommon risk. It's dumb to pay the VAN for services that you can build yourself for very little money and effort. Plus, the VAN charges you by something called the kilocharacter. This is how you know it's from the 80's. A kilocharacter is represented by 1000 characters in your EDI file. Seriously, I feel so ripped off. Twenty years ago, you would have had to have a direct data link with the VAN. I would have really felt ripped off if that was the case today.

Paying Sticker Price

If you do have to do EDI through this type of channel chances are you'll be put in the position of explaining to your boss why your company has to spend money to send an order. It will end up being only pennies, maybe nickels depending on your volume, per order, but you won't feel any better about it. My advice if you're stuck in this position is this: Negotiate, Negotiate, Negotiate. When I started looking around for the right VAN solution, I was surprised at the breadth of offers. After getting quotes I went back to the same places and pitted them against one another. Not a single vendor stuck to their original quote. Everybody folded in one way or another. I finally found the two that would meet my needs that would give me a good price and I focused in on them. Just when I thought I had done a great job of negotiating and had gotten the best price I possibly could have, I went to my boss with my final contract terms for VAN services. He balked. "Why do we have to spend this much, again?" I explained it to him. He told me to go back and get better terms and better pricing. Feeling like I had done the best I could, I told him I would see what I could do. Surprisingly, when I went back and told the two vendors that I was going to have to decline because the price was too high and the terms weren't as good as we wanted, I was able to negotiate even better pricing and even better terms from both vendors.

Key Takeaways

The point here is this, if you can avoid having to use the antiquated and expensive ANSI X.12 industry standardized EDI, avoid it. If you can't (and chances are if you work with any large companies from traditional verticals, you can't), do this: Ask your partner to skip the VAN and exchange files directly with you. If they won't, get your customer or supplier to pay for it. If they won't, negotiate the heck out of the VAN services, then go back and negotiate again; you can get much better than published pricing on VAN services. Finally, if you're transacting via EDI with more than one customer or supplier, don't count on the files being used consistently across all of them. Portions of the standard are open to interpretation.

The possibilities are endless with a bathroom remodel. Discover your classic side with a clawfoot tub, experiment with fresh bathroom vanities and coordinate it all with matching faucets. Shop PlumberSurplus.com 24 hours a day, 7 days a week for all of your bathroom needs.

Google has recently made it obvious that site speed is an important issue. So important that they've discussed including site performance as a possible contributing metric to search rankings. Consequently, we've been paying very close attention to site speed and elevated it as a key area of focus for the development team. One area where I'd like some feedback from the SEO community or other web masters is the area of images.

Among the results from the multitude of tools that we've used to tune our site performance (another good topic for an upcoming blog post), most have recommended we serve static content from a separate, cookieless domain or, even better, use a content delivery network. For our sites, that mostly means images. Great. No problem. We know that we can make pretty significant gains. Take this page: http://www.plumbersurplus.com/Cat/Bathroom/543. This page contains nearly 180 images. Nothing large (the entire page's contents amount to 572 KB), there are just lots of images. {UPDATE: Since I wrote this post, we've reduced the number of elements on this page considerably.}

So, currently, we serve most of those up from www.plumbersurplus.com/images... on the webserver. A handful of the images are master page content that we're going to continue to serve up from the www domain, but the rest need to be separated out to another domain or taken off of the page. We know that on a typical low end DSL connection each of these images takes about 175ms to download. We also know that if we serve up all content from the same domain, then most browsers will limit the number of simultaneous downloads of resources. In fact, most older browsers will only allow 2 resources to be downloaded from the same domain at a given time. Additionally, since www.plumbersurplus.com is not a cookieless domain, the client is transferring cookie data with each and every request! Oy! With an older browser allowing only 2 downloads at a time, assuming 180 images at 175ms each, that means the client can download all images in about 16 seconds (180 images / 2 at a time = 90; 90 * 175ms each = 15750ms = 15.75 seconds).

That is way too freakin' long.

Instead of allowing all that content to be downloaded in serial, we would be well served to parallelize resource downloads. We can do that by serving up content from alternate domains. Too many alternate domains is bad, because the DNS lookups take some time, too. But eliminating the cookies and allowing the downloads to run in parallel should improve load times considerably. When I brought this up to our manager of SEO, the STOP sign came out. We don't want to wreck whatever SEO value we've garnered from images.

According to analytics, we get a significant enough amount of traffic from images that making a change to our image domain could be detrimental. So, here's the dilemma: Which ranking factor do we chase, existing images SEO or improved site speed? We decided to tip-toe into an image subdomain by changing the way images are served on a few pages on OutdoorPros.com: http://www.outdoorpros.com/Cat/Skateboarding/85 and http://www.outdoorpros.com/Cat/Skateboard-Decks/26/List. Images on these pages are served from images.outdoorpros.com, a cookieless domain. In addition, those images are still available from the www.outdoorpros.com/images... subfolder so that links to existing images aren't broken.

Before we go head first into serving up all image content from the images.outdoorpros.com subdomain, we want to see that content get indexed. We did this a few weeks ago. No index. In looking for a solution to the index problem, I've found lots of people saying it took as long as 6 months to see an index of their images. We've been around linking to images.outdoorpros.com to see if we can siphon an index of the images.outdoorpros.com subdomain, but haven't had any luck yet. Although we really have little reason to believe there will be issues with this, we would like to make sure before making site wide changes.

I'd love to hear recommendations on how to get the new image subdomain images indexed. Or, better yet, I'd love to hear an educated opinion on the move to an image subdomain as it relates to SEO and the balance between SEO and the SEO benefits of improved site speed (aside from the other known benefits of improved site speed, like improved conversion rates).

With Google rolling out ranking factors based on page load time, it's obvious to say that if our site is slower, our pages will rank lower, and if our site is faster, our pages will rank higher.  In the most basic form, the lower our ranks, the less we sell. The longer we wait, the more we risk severe and unpredictable consequences. In all probability, of the more than 200 ranking factors (who knows?), site performance will only be a slight influence. So, it's likely that the sky is not falling, but we don't know. Barry Schwartz, in the aforelinked searchengineland.com article, even says that "virtually no one complains that their [Adwords] quality score is low because of having a slow site." Despite this assumption, we still want to make this transition as quickly as possible in order to improve site performance.

Comments please!

Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. PlumberSurplus.com is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

Google released their newest gadget for developers yesterday, called "Speed Tracer". It's a plug-in for Chrome's brand-new extension system that purports to show developers exactly where their pages (or web applications, as Google emphasizes) are slowing down.  Its run much like any other trace application: open your site in one window and the tracer in another, hit "record", and go about your site performing standard tasks. Speed Tracer will capture data from your site, process it, and display statistics and details for your perusal.

The central feature of Speed Tracer is the "timeline", a graph that shows how "busy" your browser is: presumably 100% would mean that your browser was entirely consumed processing the site, and thus unresponsive to the user. Sections of this timeline are highlighted and displayed in the details pane below, with information on the events causing any slowdowns. You can also view tips or "hintlets" that give advice on how to improve performance.

So much for the tool itself; now, how does it fit into our toolbox? If you're a developer for a standard web site, unfortunately the answer is "not very well". Google is clearly targeting web applications rather than standard web pages with this tool. The main feature of Speed Tracer, the timeline, is somewhat helpful in visualizing the workings of the page, but it's really geared toward ongoing AJAX-like events and performance over multiple pages. For precise page load monitoring, other tools like Firefox's Firebug and the standalone Fiddler utility do a better job of pinpointing event dependencies and bottlenecks. The hintlet system is another disappointment, producing limited and unreliable data (my colleague received no hints at all, and I was only able to pull up a confusing list of hints on one or two of the topics that Google's Page Speed plugin for Firebug already displays).

However, Speed Tracer is not without its uses. For a quick head's up on page performance, the timeline makes a good visual, and if you plan to develop a web application many features could prove useful. For general web developers, though, Speed Tracer will probably be relegated to a subsidiary role next to your main workhorses. This is Google, however, and there's a good chance they'll be adding features and improving the interface, which could turn this tool into a first-class performance tuning device.

Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. PlumberSurplus.com is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

For the best prices, on the largest selection of faucets, from your favorite brands like Kohler, Danze, and American Standard shop PlumberSurplus.com 24 hours a day, 7 days a week.

I am a fan of open source software.  The main characteristic of open source software is that the source code is freely published.  This contributes to the success of the programs in many ways: the code is available for modification making it flexible, users are able to collaborate to correct defects, authors are more likely to stand behind their claims (because the code can be read), oh and it’s typically free.  Linux (Ubuntu) is my main desktop operating system at home and on my personal laptop.

However, as do many open source enthusiasts, I use Windows at work.  But, of course, I would prefer to use an open source solution. The question is, how does one “infiltrate” open source into their primarily Windows based work environment?
     
First I thought about letting everyone know that we should be running Linux (*BSD, OpenSolaris) on everything regardless, no matter what it is or who is running it. What stopped me is that I am still unable to grow a proper Unix/Linux Beard:

Little bit of nerd humor, but joking aside, for the everyday office circumstance this is probably not the best approach for integrating open source software into a work environment that has been based on a Windows operating system. What does make sense is starting small and simple.  Instead of replacing the current platform, build on top of it.  That is, find open source software that runs on Windows.

If you don't know where to start there is the OpenDisc which is a CD you can download that has open source software to try out.

Also, here is a list of programs that I use at work:

• Open Office: Office productivity suite that is able to open the new docx and xlsx out of the box unlike office 2003.


• FireFox: Even you don't know about open source you've most likely heard of this web browser that offers many custom features, add ons and plug-ins.


• FreeMind: A java based mind mapping program.


• GIMP: For image retouching, editing and authoring.


• SharpDevelop: A free IDE for C#, VB.NET and Boo projects on Microsoft's .NET platform.

Of course check with your IT Manager to make sure that the use of these programs is allowed.  Also, check out this presentation by Chad Wollenberg titled “The Free and Open Advantage”.

Kohler is arguably one of the most innovative brands in the home improvement industry. The new Karbon faucet has completely transformed the kitchen and more specifically revolutionized the kitchen faucet. Meanwhile Kohler seems to effortlessly create bathroom fixtures that are not only sleek but save water, like the Escale toilet.

A couple of months ago our awesome Adwords team was able to hook us up with five free hours of assistance from a third party to help train and setup Google Website Optimizer tests. We had mentioned to them that we were interested in trying some tests but did not have much experience in doing so and through that conversation they were able to help get us resources to get started. Looking back (as we are collecting the final data from our first test) having that help was invaluable. With that in mind I wanted to share the steps we took with the third party to get things going before our first test kicked off.

First, get familiarized with Google Website Optimizer (GWO). There are several resources available in video and written forms which explain how it works and what needs to be done.

Second, review the website for tests which might be a good jumping off point. Typically, good first tests are variations of an add-to-cart or checkout button, text location or color, banner / promotion variations, etc. For the first test you want something which is easy to setup and has many creatable variations as to get some experience before moving onto more complex tests.

Third, open up your GWO account and start to setup the test. This will include tasks like, telling GWO what kind of test you want to run, and installing the tracking codes on the test and order complete pages.

Fourth, the variations of what is going to be tested need to be created, reviewed and loaded to GWO. At least for multivariate tests GWO handles what code gets swapped out, be it an image or text. Once the codes are in place for the test, developers don't need to be the ones setting up all of the variations as they are created inside the GWO console. All of the buttons, badges, text, etc. will need to be created though (get your designer on the horn ahead of time) and setup inside of the GWO interface. Depending on where your developer setup the test codes it may require a little HTML or CSS knowledge but nothing too crazy.

Fifth, once everything is setup and ready to roll you’ll want to make sure to test that all of the codes are setup (especially the conversion tracking), and then use the preview tool in GWO to preview how all of the variations will look. Test! Test! Test! You don't want to turn on a multi variant test which does not work, has broken variations or takes your site down.

Finally, kick off the test and let the data roll in! Remember that depending on site traffic and how many variations are being tested it could take days or weeks to get enough data for GWO to show recommendations about which variations are the best.

Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. PlumberSurplus.com is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

As a developer, I'm always looking for ways to make people's jobs easier. If I can automate a repetitive task in order to help us get more done, that's usually great, but every once in a while it can come back to bite you.  There is a point when automation can lead to the detriment of basic logic.

healthBase is a sort of health-oriented search engine. It's powered by a technology called NetBase that combs the web for information, flagging and extracting relevant information based on the semantics of a sentence. Sounds good, right? You can look up treatments for a headache,  or pros and cons of Tylenol. You can see it's not perfect, but it does seem to have the right idea.

However, while healthBase's search algorithm seems acceptable, they unfortunately forgot or didn’t have the resources to put any sort of filtering on the results. This can produce some hilarious misapplications. Want to know what treatments there are for Obama? They've got that covered. How about the causes of rap? Or the pros and cons of vampires? Feel free to experiment yourself; these are some of the tamest results.

We can all laugh at those results. But what about when people are actually searching the site for medical advice and the wrong results are returned? What if someone is searching for treatments for Appendicitis, for example, for which immediate surgery is the only proven treatment? HealthBase returns a whole list of treatments (including things like licorice!), which could lull a reader into thinking surgery is only one of several options. Or how about the pros and cons of suicide, at the top of which is listed "provide relief"? While it's true that you can click the "+" button next to a phrase and read the scrap of text from which it's extracted (often entirely out of context), the fact remains that the lists themselves are in some cases dangerously misleading.  I mean they can use the “Beta” excuse but that will only last for so long.

There are two key differences between an automatic process and a human: the automatic process is much faster and easier, but a human has common sense. Both need to be taken into account when considering automating part of your business. If you do decide to automate something, be sure to test and test again, and the more vital the application is, the greater the depth and breadth of your testing needs to be. At Gordian Project, we try to balance automation for speed and convenience with a human element for sanity and a personal touch.  Surely no one here, which I know of, promotes Nazis, but surprisingly healthBase managed to find a whole list of pros:

Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. PlumberSurplus.com is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

You may already know that Gordian Project users are in the cloud.  Well, on Tuesday, we hit our second bump in the road with Google Apps. An outage. You may say to yourself, "An outage? With Google Apps? Really?" Well. Yes. Really. Totally freakin' down. Apparently, Google had an issue Tuesday morning that brought down the email interface for apps users.  Déjà vu?

Here is the error I got in Chrome:

At first I thought to myself, "Hmmm. That's weird." So I literally waited 30 seconds and tried again. Same thing. So I asked the person next to me to try. Same thing. So, I tried my iPhone and got:

OK. Seems likely to be a global problem. So, I alerted users on our network that I was aware of an issue with Google Apps and was looking into it. Because the error says, "Please try again in 30 seconds.” I figured it would be a temporary outage and waited only a few minutes. The problem persisted. So I checked Google News and, sure enough, there's a widely recognized outage. From the news, I noticed two things that were particularly interesting:

1. I wonder if the "tip-toeing" of wave into apps created yesterday's havoc.
2. Google has an Apps Status Dashboard

So, after I found out that there was an Apps Status Dashboard, I checked it out and here's what I got:

Google, why didn't you show this to me on the 502 error page? Instead, you told me to try every 30 seconds. I can't imagine how many people wasted hours of their day refreshing every 30 seconds to try to get to critical email. You may remember this article highlighting good custom error pages.

After the incident was stabilized, Google posted an incident report here. According to the report, Google "underestimated the increased load that some of the new updates placed on request routing." Not sure what the "new updates" were, but it doesn't seem like Google should underestimate the anticipated load.

Noting the red "X" by Google Mail, I clicked on it at 1:48 PM to find:

It says there will be an update at 1:53 PM, so I waited until 1:58 PM and clicked again:

Hey! Wait just a second! Ten minutes ago there was not an update at 1:02 PM. What gives Google? Don't you know that 45 minutes after I announced it to everyone, people are still coming to my desk to say "Hey Josh. My email's down."? Please, just tell me what I need to know when you know it! Also, I love that there is a link to the "How to use IMAP or POP", where the first step outlined is to "Enable POP or IMAP in your Google Apps email account". I can't get to my apps account! Then I realized, I already had IMAP enabled on my account and had it set up in Outlook. So, I started up Outlook... only to be woefully reminded of why I wanted desperately to switch to Google Apps to begin with. I quit Outlook before I even used it, as it was either Outlook or every other application, and a choice had to be made. Instead, I waited for the Google update. At 2:40 PM I refreshed the Status Dashboard to find:

Hooray! We're back up! Not without a few lessons.

1. Google, or any other cloud service provider, when a critical service goes down, don't show me an error that tells me to retry every 30 seconds; especially if that's not really what you want me to do. Send me to the place with the relevant information. I know, based on your incident reports, that you "published ongoing reports to the Google Apps dashboard, Gmail Help Center, the Enterprise and Gmail blogs, and the GoogleAtWork and Google Twitter feeds, to help provide customers with the latest status and available workarounds.", but the error was unhelpful. Please don't make me Google it.


2. IT managers, if you're going to start using SAAS and cloud enabled services, find out, in advance, what the notification mechanism is for outages. In this case, it would have been a simple thing to have added the Apps Status Dashboard to one of my feeds.


3. Don't count on Google Apps, or any other cloud service being available 100% of the time. If you have a critical meeting or a conference call that requires you to have a cloud stored document or email or presentation up and ready to go, make sure it's ready and pulled up long before your event, or make sure to store it locally, as well. Also, based on Google's comments, it may be good to enable IMAP on your account just in case you can't web-surf your email; at least then you can get to critical emails with Outlook or Thunderbird.
   

The possibilities are endless with a bathroom remodel. Discover your classic side with a clawfoot tub, experiment with fresh bathroom vanities and coordinate it all with matching faucets. Shop PlumberSurplus.com 24 hours a day, 7 days a week for all of your bathroom needs.

On July 2, 2009, at approximately 11:15PM PST, as I was lying snugly in bed, I had nary a clue that Authorize.net was going down. Apparently, there was a fire at the data center. Many of you have probably already read this story; or, perhaps you are/were a customer of Authorize.net's and were made aware by errors. I wanted to share our experience with the major outage and why the lesson is valuable for others in eCommerce. I could be writing a blog post about how much it sucks that Authorize.net even went down, given that it was only one data center scorched. I could be asking, "Where in the world was the backup data center? "Rackspace, how does a sprinkler system kill backup generators? Where is the backup for your backup's backup?!" I could also be writing about how quickly the status was updated on the situation thanks to some smart person at Authorize.net building a Twitter account that day. But this is a post about a shift in our philosophy.

So, as I slept I had no idea that our payment gateway, Authorize.net, was getting wrecked by a fire. When I woke up at about 7:30AM I had already received a text from one of the managing partners alerting me that we had received a pile of errors related to Authorize.net failures. Let me explain what that means for us. An error from our order system that there was an Authorize.net failure means that an order was placed, but no payment was collected. You might be saying to yourself, "Why in the heck would you guys place an order without first confirming that payment could be collected?!" Well, the reason is simple and goes back to our roots. Early on in our eCommerce venture, we prayed for orders every day. Our strategy on many fronts, including payment processing, was to protect orders; in this case, let the customer place the order on the customer site without failure or error (or some other barrier to transaction) and clean up the mess manually. As a consequence of this strategy, when we made a call to Authorize.net for payment processing and it failed, we would have a placed order in our system with no payment from Authorize.net. So, an email with the customer info would be forwarded over to the tech team to review and contact the customer to process a manual payment. This was a good solution for us, early on, as we didn't want to miss a single transaction. We needed the business!

This process worked for us for a good long while, since downtimes on the Authorize.net front were very rare, but when they did happen it was usually only one or two and could be resolved easily. Well, we hadn't had this issue in quite a while and it had not occurred to us that we would need to update our strategy as we grew. Then we grew. By a lot. The consequences of having more than ten times the volume of four years ago becomes readily apparent when your payment processor goes down for more than eight hours. The morning that Authorize.net went down meant that we had a few dozen orders that were placed without payment but had already begun processing for shipment at warehouses across the country. So, we had quite a cleanup effort on our hands. First, ensure that the orders don't get processed out the door, since they haven't been paid for. Second, disable the Authorize.net payment method until we can figure out what happened or is happening and identify when they're back up. Third, contact all of the customers to see if they would like to complete a manual transaction over the phone or retry their checkout using Google Checkout or PayPal (two services that we did not offer at launch). Four, document and share the happenings with the management team. Finally, fix our outdated checkout so that orders do not get placed when the authorization transaction fails.

Our checkout process and a redesign have been on our radar for an update for some time now. This, however, is one issue that escaped us until it became a pain. Hopefully, this will help us to think critically about updates to our site as we examine where we were, where we are, and where we're going.

Kohler is arguably one of the most innovative brands in the home improvement industry. The new Karbon faucet has completely transformed the kitchen and more specifically revolutionized the kitchen faucet. Meanwhile Kohler seems to effortlessly create bathroom fixtures that are not only sleek but save water, like the Escale toilet.

• Tim Berry and his wife Vange collaborated on what they have learned over the last 22 years as small business owners and came up with a list of ten lessons they learned.  They point out that these lessons may not work for every business but in my opinion Tim and Vange may be too humble about their list.  Businesses are still failing today because they either don’t know about the topics discussed in this article or they choose to ignore them.  I chose three points to reiterate for our audience:
  • 2. We built it around ourselves
    Our business was and is a reflection of us, what we like to do, what we do well. It didn’t come off of a list of hot businesses.
  • 5. We spent our own money. We never spent money we didn’t have.
    We hate debt. We never got into debt on purpose, and we didn’t go looking for other people’s money until we didn’t need it (in 2000 we took in a minority investment from Silicon Valley venture capitalists; we bought them out again in 2002). We never purposely spent money we didn’t have to make money. (And in this one I have to admit: that was the theory, at least, but not always the practice. We did have three mortgages at one point, and $65,000 in credit card debt at another. Do as we say, not as we did.)
  • 7. We minded cash flow first, before growth.
    This was critical, and we always understood it, and we were always on the same page. See lesson number 5, above. We rejected ways we might have spurred growth by spending first to generate sales later.
    
    

• The Palm Pre comes out this weekend, and I am quite excited about it!  Search Engine Land reports on Google’s excitement for the release of this smartphone that has Google Search, Maps and YouTube already built into the device.  What’s important about this article is the trend toward mobile apps and how advertisers will choose to plan for future PPC campaigns.


• Bing seems to be the word of the week and (#badabing) the tweet of the week.  Bing even managed to become the number two search engine for a day, which isn’t all that surprising considering the dollars that Microsoft is tossing at their ad campaign, but will it last?  Some think not, and I tend to agree.  I tried to use Bing for a day, but I couldn’t even make it that long.


• Adobe BrowserLab is making it easier for developers to test cross browser compatibility.
  


• We pride ourselves on being problem solvers, in fact that is how Gordian Project came to be our name.  We go about discovering problems and implementing solutions in various ways, but I enjoyed this simple outline for those in their infancy of tackling issues.
  

Kohler is arguably one of the most innovative brands in the home improvement industry. The new Karbon faucet has completely transformed the kitchen and more specifically revolutionized the kitchen faucet. Meanwhile Kohler seems to effortlessly create bathroom fixtures that are not only sleek but save water, like the Escale toilet.