eCommerce and

• 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.

I try not to discuss technical subjects in my posts because, being a developer, I understand that most of the stuff I find fascinating just wouldn't be interesting to most of you. But sometimes I run across something that's both useful and understandable, and I have to share it. So I hope you'll bear with me.

Cross-browser compatibility is a major headache for web developers. The web is built on standard protocols like HTML, CSS and Javascript. This is great, because it allows all sorts of different computers to communicate with each other. However, there are many different browsers out there to interpret these standards: Internet Explorer, Firefox, Safari, Opera, Chrome, and many more. And each of these browsers comes in multiple versions. And every version of every browser interprets the standards a little differently. Sometimes that's because the standards aren't clear, but usually the browser is simply in error, or a decision was made not to support the standard. So instead of being a simple job of following the standard when developing web sites, a web developer has to consider the unique behavior of the most common browsers to make sure most users see the website correctly. Usually this is done by developing in a more "standards-compliant" browser and then trying to fix the quirks in other browsers while not accidentally introducing any in the original. It's a balancing act that involves a lot of knowledge of the browsers' inner workings.

Troubleshooting Browser Errors

So, I ran across a strange bug on our website, PlumberSurplus.com, that I knew immediately was a browser problem, but hadn't seen the problem before. There were several "divs", or blocks of content, on a page that were displaying differently in different browsers. In Firefox and Internet Explorer, the page looked something like this:

However, in Google Chrome, the page looked like this:

Obviously, Chrome was displaying the page differently than the others. To understand why, we have to dig into CSS, the standard web language that dictates how pages are formatted. CSS works hand-in-hand with HTML: in CSS, HTML elements are given attributes whose values determine how the elements are formatted. For example, you could take some text in HTML and use CSS to make it bold. In this case, the first div (in red) has a CSS attribute called "display" that's set to "inline-block". That means that the div acts like a solid block, that doesn't wrap or change shape because of things around it, but that it also stays inline, so that if there's text around it, it fits right in as part of the text. We'll revisit this later. The second (blue) div has an attribute called "float" that's set to "right". This means that instead of simply being inserted into the text of the page, the div gets attached to the right side of the page (or the section it's in), and the rest of the content flows around it. The third (green) div has no special attributes associated with it; it's just there to illustrate page flow.

So it looks like what's happening is that the first div is forcing the second div down in Firefox and Internet Explorer, but flowing around it in Chrome. Let's do some tests to find out why. First, let's get some text in there to see better how the content flow works. Here's how Firefox looks:

As you can see, the first div is right in the content flow where it's supposed to be, and the second div is sitting on the right as the content wraps around it. Looks good so far. Here's Chrome:

This looks pretty much the same except for one subtle change. The second div is one line higher than in Firefox. Why is that? I've colored the text to demonstrate. The black text is all before the floating div. The blue text is actually after the floating div, but since the div floats, it wraps around it so it looks like it comes immediately after the previous text. So the difference between the two browsers is this (and this is important, so I'm setting it out):

In Firefox and Internet Explorer, a floating div floats below all previous content. In Chrome, a floating div only floats below content that is directly above it.

W3C (Wide Web Consortium) Standards

So, which is correct? For that, we turn to the World Wide Web Consortium, W3C, the standards body that determines the specifications for CSS. Now, just as there are several versions of each browser, there are also several versions of CSS. The main version of CSS in use for some time has been CSS2.1, but recent browsers have begun adopting parts of CSS3 (which is itself still in development). However, for our purposes they are identical. They give these rules for positioning floats:

4. A floating box's outer top may not be higher than the top of its containing block. When the float occurs between two collapsing margins, the float is positioned as if it had an otherwise empty anonymous block parent taking part in the flow. The position of such a parent is defined by the rules in the section on margin collapsing.
5. The outer top of a floating box may not be higher than the outer top of any block or floated box generated by an element earlier in the source document.
6. The outer top of an element's floating box may not be higher than the top of any line-box containing a box generated by an element earlier in the source document.
8. A floating box must be placed as high as possible.

Those rules are somewhat technical, but the two most important ones here are six and eight. Rule six says that a floating div can't be higher than any line of content that came before it. Rule eight says that, unless another rule conflicts, a floating div should be as high as possible. So, looking at the pictures again, it looks like Firefox and Internet Explorer both line up with the bottom of the previous line of text, whereas Chrome lines up with the top. That means that Firefox and Internet Explorer violate rule eight; Chrome is indeed in the right.

However, now we need to know what to do to fix the issue so that all the browsers display the same thing. There are two ways to do this: we could fix Firefox and Internet Explorer to display correctly, or we could "fix" Chrome to display the same as the other browsers. In this case, I actually wanted all the browsers to put the floating div below the first div rather than to the side, so I chose the second option. My fix was to change the first div from "display:inline-block" to "display:block". This took it out of the content flow and pushes everything after it to the next line, like so:

That includes any floating divs below it, so now the second div is positioned the way I want it (as in the first picture) even in Chrome. Since there wasn't any text on the page in that section, it didn't interrupt the content flow. If there was text there, I would have had to find a way to keep the first div as "inline-block" while pushing the float down; possibly by moving the floating div itself lower in the content flow.

If, on the other hand, I had wanted to make Firefox and Internet Explorer work the way Chrome does, allowing the floating div up beside the first, I would simply have to move it to just before the first div in the content. That way it wouldn't be below the div at all: it would be first, and the div would "wrap around" it by staying to its left. Both solutions are relatively easy once you understand why each browser is behaving the way it is, but it took some digging to do that. I wasn't able to find anyone else detailing this discrepancy, so I hope this post is helpful to you web designers out there, and for the rest of you, chalk it up as a glimpse into the life of a developer.
 

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.

I was struck recently by a video I watched on Fora.tv, Google's Vic Gundotra: Mobile Phones as Answer Machines. In the video, Vic Gundotra describes how he was having lunch with a friend and his four year old daughter. His friend asked him a question and he replied, "I don't know." His daughter piped in, "Daddy, where's your phone?!" At first he thought nothing of it, but then he and his friend realized that his four year old had surmised that when information was needed, one could simply pull out a phone to obtain it. Remarkable! I have a two year old, and even he has displayed what I perceive as a shift in thinking about information retrieval from my generation to his. We were recently watching "Mickey Mouse Clubhouse" on TV and I said to him, "You and I are going to go to the store." He got in the car, climbed into his car seat, and asked me for my iPhone. He turned it on, unlocked it, and started the YouTube app so that he could continue to watch "Mickey Mouse Clubhouse" clips in the car. Naturally I had to search for the clip, but I am amazed that he is aware of this resource portability.

Until I owned a "cloud-enabled" phone, I was skeptical of the mobile revolution. Sure, I have recognized Generation Y as the text message generation, but until recently I hadn't seen the utility in being connected to cloud applications via a sensory-based platform. My 49 year old father-in-law once proclaimed to me that online shopping would never overtake physical retail shopping in overall revenues. Though I am sure people will still want to go to the grocery store to make sure their melons feel ripe, I'm not sure I believe that the shopping experience or buying decision process will look anything like it does today in 20 10 5 years. More and more, I use the cloud to make buying decisions. What's more, I find myself diving ever-deeper into my phone while I'm shopping in physical retail stores. Whether I'm doing price comparisons, or reading product reviews, or searching for similar products or services, I find that I'm more inclined to trust information found from reliable sources in the cloud than I am information found at a retailer's store. 

I wonder… how will cloud-connected customers affect eCommerce and vice-versa? More specifically, how will this affect PlumberSurplus.com, OutdoorPros.com, and any other venture we decide to undertake? Well, in order for us to be able to make an impact in mobile, we have to know what success looks like in order to understand whether or not we can execute in an easy and scalable way. With this type of marketing in its infancy, how can we really measure this? 

I came across this article today, Search Giants Encounter Challenges in Mobile Ad Market.  In the article, Frank Reed discusses a company that starts off with mobile ad campaigns running on five mobile Internet networks. After only one day, the company pulled Google and Yahoo campaigns because they were not effective. Frank cites two reasons as the primary hurdles for behemoths like Google and Yahoo in the mobile ad market: "First, the ads that are run on their traditional platform don’t often translate or fit well in the mobile environment... Secondly, the position of the ads on a mobile device will not correspond to the ‘top of the page’ and ‘right hand column’ look that is now ingrained in everyone’s way of seeing and reacting to the ads." These seem like relatively easy problems for resource heavy organizations like Google and Yahoo to overcome over time. However, it's a good indicator to me that mobile advertising isn't mature (certainly not mature enough for a small business like ours to throw money at).

In order for us to be able to be effective in mobile, I think three things need to happen. First, testability. We need to be able to stare at an anticipated baseline of performance and easily test and measure performance. Second, match ad campaigns to targets. Mobile advertising seems like a moving target at this point. This seems pretty tough to do. Finally, figure out how to take advantage of the sensory aspect of today's mobility. Phones have eyes, ears, skin, they know where you are, they know where you've been, they know who your friends are... how do we leverage these to create an experience that leads a customer to buy?

No matter what happens, at this point, I'm pretty convinced that the way my son finds information and shops when he's my age will be very different than the way I do those things now. I can't wait to see what happens next.

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.

Recently, Elastic Path presented a great webinar on the topic of Buy, Build, or Leverage? It was a really great webinar which presented some great information and posed some interesting questions. Now of course Elastic Path is an eCommerce vendor and therefore certainly have some reasons to push their own product, however, overall I thought it was very interesting and that they did a good job of presenting the points and issues from all sides.

Since the Gordian Project uses a custom platform there are many instances where our problems and solutions can get technical in nature and be solved by an array of solutions. While our platform is mostly custom we have certainly assimilated solutions which we would rather buy or leverage than build such as LivePerson, PowerReviews, Google Analytics, Mcafee Secure, etc. All of these solutions we decided not to build, find a partner and then integrate their solution into our platform, each provides value for us in its own unique way. Most of these solutions were relatively easy to come to an agreement on, integrate and begin using. The webinar does a great job addressing this and I applaud them on their great presentation.

This webinar got me thinking about possible issues though and what we have faced in the past. What happens when things do not work out the way you intend or a solution is no longer providing the value you are looking for? Our saga in this regard has been the site search and merchandising elements of our website. When our website was first created it had custom site search functionality which worked well enough, nothing spectacular, no killer bells and whistles. After several years with this solution we decided that something more robust was needed, preferably with better search, marketing and merchandising capabilities. After looking at all of the options we decided to take on a 3rd party vendor who was considered best of breed in this field. After all negotiations were finished, and documents were inked, we were able to begin the task of integrating the solution, which was no small task. 

The solution worked especially well for most of our commitment with our partner, but issues with scalability arose when taking into account multiple websites.  Product upgrades on their part, required further development on our part became frequent and with less and less accurate notice.  Website changes on our part required cooperation on their part.  While there were few there were enough reliability issues and while any downtime is inopportune, two weeks before Christmas can really hurt an internet retailer.  Finally, there was a hefty price tag associated with the service.  In looking at all of these pieces together, the perceived value of the service began to dwindle. 

With all of that in mind, late last year we decided to forgo renewing our contract and instead decided to build something in-house.  While our solution would have fewer bells and whistles the resolution would be more than sufficient for our current needs, and far better than what we had initially. After some intense planning and development, using what we had learned, taking notes from what industry leaders were doing, and utilizing the research available to us, we created, what is in my opinion a pretty great solution.  It’s our own, and we have full control. While we continue to make tweaks it has been a very positive experience, and it turned out to be a financially smart decision as well.

PlumberSurplus.com offers its customers tens of thousands of plumbing, home improvement, and building products in a range of categories including Kitchen and Bathroom, Water Heaters, Lighting, Pumps, Tools, Access Doors, Valves, Commercial and more. Individuals and businesses can shop quickly and easily at PlumberSurplus.com 24 hours a day, 7 days a week.

Oh no. It's happened. I was making a fairly ordinary update to one of our eCommerce websites. I had tested it pretty thoroughly and gone through the whole procedure of preparing it for launch. I held my breath and launched it-- and got an error screen. I refreshed the site homepage, and my heart sunk. The site, the entire site, was broken. We lose literally thousands of dollars an hour when the site is down, so this was a huge deal.

As a developer, what do you do when something goes very, very wrong? You're not expecting it: you may have prepared for it but you didn't believe it would happen. And now it's staring you in the face. And depending on how you handle it, you can either recover quickly with minimal losses or you can flounder and make it even worse. Here are a couple of points I've learned that can help avoid the latter.

1. Calm Down - I can't tell you to stay calm, because you probably lost that when things started going wrong. But you can calm yourself, and you're going to need to if you are to respond properly. Rash mistakes can easily compound the problem, making it many times harder or even impossible to recover from. So take five seconds, sit back, breathe, and tell yourself, "OK, this is bad, but panicking would only make it worse. So I'm going to be careful and do things right." Then just follow through, solving the problem as you would any other. The urgency of the situation is useless in helping you solve it, so forget about it. You'll be more likely to see solutions you otherwise wouldn't, and less likely to miss further dangers.


2. Be Honest - Your first impulse may be to try to cover up any mistakes you made or anything that could lead blame to fall on you. However, your first priority is to fix whatever's gone wrong, and that often runs directly counter to that impulse. The first step to solving a problem is figuring out exactly what the problem is, and that can't happen if everyone involved is afraid to release any information in case it might inculpate them. Remember that you need to be honest with yourself, as well. Don't try to convince yourself that it wasn't your fault or it's not that bad if it was or is. This is also a management issue: managers should make it clear in their policies and behavior that, while subpar performance isn't acceptable, no one will be punished or scapegoated for owning up to their mistakes (my own managers were very understanding!).


3. Look Forward - Computers are (usually) programmed to obey logical rules. They perform the task given to them, exactly as it is given to them. They don't worry about things like pressure or situation. Humans, however, aren't made that way. We have emotions and operate, more often than not, on general heuristics and hunches rather than logic. This is good in many cases; we can do more with less than computers. But in certain situations it's a problem, and one of these comes up often in crisis situations. One of our rules of thumb that we tend to follow is that if we've already invested ourselves in a certain course of action, we try to protect that investment and, if necessary, follow it with more. Unfortunately, if it's a bad investment, we end up "throwing good money after bad", losing more and more while becoming more and more attached to one course of action. This shows up in crisis situations when we get fixated on one course of action, trying more and more variations on the same ineffective theme. We can even end up stupidly repeating the same action over again, hoping that this time it'll work. Instead of doing this, try to forget about what you've already done and think instead about where you want to go. When making a change to a website, for example, I might be tempted to think, "Well, since we've already put the changes on the site, we should try to fix those changes." However, my immediate priority is to get the site working; if it's faster to do that by undoing all my changes and going back to the original version of the website, that ought to be my course of action instead.


4. Be Lazy - This one may surprise you. Being lazy isn't usually thought of as a good quality, and of course I don't mean that you should be slow and unwilling to do the work needed to fix things. However, there is a place for laziness in being smart about your time and effort. Let's take an example to clarify. Suppose I've got a problem that has two possible solutions. There's a 90% chance that I need to undo all my work, figure out what the problem is, fix it, and put it back in place. However, there's a 10% chance that all I have to do is re-apply my change because it got corrupted the first time. My initial impulse might be to go the undo-and-fix route. However, if I'm smart and lazy, I could realize that I could at least try the other option. Even though it's less likely to fix the problem, it takes an insignificant amount of time and energy. That way I'm more likely, in total, to get the problem fixed sooner.

That last point actually turned out to be the case when the site went down on me. While I was starting a large roll-back to a backup version of the site which would require a lot of cleanup, someone else suggested simply restarting the site on the server. That turned out to be the problem, and it was back up with a minimum of downtime and cleanup work. While I learned that point the hard way, I plan to keep all of these in mind in the future.

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.

Documentation, the recording of organizational structures, policies, actions, and goals, is vital to any business, and doubly so for those of us in development. When I came on board I inherited roughly 200,000 lines of code that I had to learn well enough to find and pinpoint individual errors, within the span of about a week. While experience and clues from within the code help somewhat, the job would be nearly impossible without documentation of some kind. And documentation will continue to be important going forward: with so much to manage, it's unlikely I'll remember exactly what a particular piece of code does even a few months down the line unless I leave some easily understandable record. Even outside of the development world, documentation plays a fundamental role in business. It codifies procedures, ensuring everyone in the company does things the same way (hopefully the right way!). It streamlines processes, allowing people to look up answers instead of asking coworkers or reinventing the wheel. And it acts as protection during audits, helping to pinpoint any actions taken against policy. So, how should documentation be developed and integrated into your business practices?

First, it's important to develop your documentation alongside the actual process. Too often developers take the attitude, "Code first, document later." That would be fine if we could stick to it. But in practice it tends to become, "Code first, then code something else, and put off documentation for another time." Instead, you have to consider documentation a priority, updating it while the work you've done is fresh in your mind. Will that make you work slower? At first, yes, but over the long run it should save you time. Instead of thinking of documentation as something that hampers your real work, consider it as part of that work. You can't set aside part of your job because it's slowing down another part.

Second, streamline your documentation process to require the least amount of extra work. It's especially important not to duplicate information. When I'm documenting code, for example, it's often possible to intersperse the code and the documenting comments so that half of the documentation is the code itself. That way I'm not duplicating information by writing it once in code and once in the documentation. Another possibility is to set up automatic documentation procedures, so that you only need to manually fill in specific information. I have a Google document to record changes I make: it automatically fills in several fields for me, and other fields are set up to ease entering that information. This took a bit of extra effort to set up at first, but it reduces the ongoing work.

Third, be sure to structure your documentation. If you're documenting your work as you do it, it's likely that the documentation will be close to the actual work, both in detail and in location. That is wonderfully helpful when you're already looking at a specific piece of work, but what if you're trying to find that piece among all the rest? For that, you need higher-level documentation that gives the general structure of your work, explaining each piece and where to find it. It might also be helpful to give pointers to this general documentation from the specific pieces so you will be able to follow it back. However you choose to do it, make sure that your documentation gives a clear starting point to someone who doesn't already know what they're doing. Hunting for the right documentation is often just as frustrating as trying to understand the work itself.

As I come to grips with the code I have to work with and the duties I'm expected to perform, I'll be reading, updating, and creating the documentation to go with them. I'm hoping that with these principles I can efficiently create documentation enabling me and anyone else who reads it to get up to speed quickly and get the work done.

No doubt retailers that offer Google Checkout as a payment option are now aware Google is changing their transaction processing fees to a new tiered structure and removing the Adwords processing credits. This is a pretty large change they plan on implementing, and one that will likely be adding much higher processing fees for Google Checkout Merchants.

Old Fee structure V. New Fee Structure

Under the old model if you processed $100,000 in one month through Google Checkout which represented 1,000 orders you would be charged $2400 in processing fees, which include the per transaction fee of $0.20.  Seems legit right? But let’s say you also spent $10,000 on Google Adwords the previous month, you would get that $100,000 processed for free because they will process 10 times whatever your Adwords spend is for free and everything else at the normal rates.  Nice kicker huh, for taking on Google checkout and also using multiple Google services?

Under the new model if you processed $100,000 in one month through Google Checkout which represented 1,000 orders (this pushes merchants into the lowest tier of processing fees at 1.9%) you would be charged $2200 is processing fees, which includes the per transaction fee of $0.30.  The fees are slightly lower than the previous model, that's great right?  Maybe not, let’s say you still spent that same $10,000 on Adwords the previous month, under the new model you now owe the full $2,200 in processing fees! They are removing the Adwords processing credits.  Wha wha wha!

Our wonderful checkout representative plans on calling me this week to review the changes and let us know what they plan on accomplishing with the fee changes, but still that's a pretty steep increase in fees. The fees are especially high when you take into consideration, that we made the upfront investment to take on Google checkout, pay for the development and fully integrate Google checkout. Granted, they have tossed on some awesome promotions since we implemented the feature and have successfully heavily engaged users.  It’s still a hard chunk of change to write a check for (or never see as the case may be). On top of the hard economic times, I hope that this does not affect too many merchants in an extremely negative fashion.  I could see merchants with large Adwords budgets who process a lot of dollars through Google Checkout possibly getting thrown under the bus on this one.

Jeff Hirsch spoke at the OMMA Behavioral conference on Tuesday of this week in New York.  The audience took note when he proclaimed “Behavioral targeting will surpass search in online ad spend by 2020”.  This may sound implausible in a search driven industry, but check out the other proclamations that once sounded extreme and are now true:

“A day will come when we can get all of our newspapers by home computer.”

“All bills and transactions will be carried out electronically.”

These are just some of the statements you will find in the following videos.  The first, from 1969, is an overview of what life will be like with electronic consoles or computers as we like to call them today. The other is a news report from 1981 about getting news on your home computer, as the video states one person was currently already using the service!

Some favorite quotes:

“Fingertip shopping will be one of the homemaker’s conveniences.”

“What the wife selects on her console will be paid for by the husband at his counterpart console.”

“With this system we have the option of not only viewing the newspaper on the screen, but also, we can copy it, so anything we are interested in we can go back in again and copy it on to paper and save it, which I think is the future of the type of interrogation the individual will give to the newspapers.”

“Also at his disposal is an electronic correspondence machine, or home post office, which allows for instant written communication between individuals anywhere in the world.”

“It takes over two hours to receive the entire text of the newspaper over the phone, and with an hourly use charge of $5.00, the new tele-paper won’t be much competition for the $0.20 street addition.”

Flash forward to this week:

• George Simpson is discussing the downfall of print media.  He points out that “67% of surveyed respondents feel traditional journalism is out of touch with what Americans want from their news”.
• Facebook is being utilized by developer entrepreneurs to run their own businesses.  This is part of an economic shift that will require individuals to maintain an online presence.
• TechCrunch was at Microsoft’s TechFest this week and posted a video of technologies to come:

Normally I try to keep my blog posts “above the fold” technically, and shield you from the code that makes everything work under the hood. I realize that there are many great tech blogs out there, many of which I read, and that readers of this blog are more interested in the business of eCommerce rather than the technical aspects that make it work. As such, I try to talk about technical things of interest, but without any tech jargon or degree needed.
 
Recently this has begun to backfire on me, however, as some now view my job as “plug and play”. In discussing the available technologies and possible usages of them, I’ve been hearing comments like:

“Doesn’t SQL just do that already?” – In response to trying to figure out the best way to write search relevancy logic.

 “I’m sure Microsoft has figured out a way to do that” – Yes, they have. They have developed programming languages and technologies that allow highly skilled professionals to spend long hours writing code to accomplish that task.

Or my personal favorite, when comparing our needs to a product written for a different database, in a different language, and has been in development for 7 years – “we can likely do whatever they are doing”.

In an effort to reduce complexity when talking to non-technical users and speak in plain English, I’ve apparently erroneously conveyed to them that there is really nothing technical involved in eCommerce development. As far as some know, we have a “website”, a “server”, a “database”, and a long 3 pronged cord that connects them all seamlessly. Fortunately for us, this cord also connects to Amazon, Google, and our supply chain network as well.
 
I considered just posting a few large blocks of code to keep you on your toes, but figured it would get the same blank look I do when I try to explain what I do to my kids. So instead, just a friendly reminder to all you business types to give your developer a hug today, and be thankful you don’t have to hear about fine tuning SQL procedures for maximum speed and relevancy.

Lately over here at the Surplus we’ve been focused on a lot of internal development to better streamline our processes, interactions with customers and suppliers, and other types of projects that add value to us as an organization but remain invisible to our customers. However, we have been looking ahead to this year’s development projects and have plans to do a lot of work on what we call “Customer Experience”.

With this focus, I’ve been poking around, looking for ideas and the technologies that may support some of the cooler features we may want to implement. In a post Web 2.0 world, we are looking for things that really add value to the customer, not just every cool little gadget, widget or flashy thing that might look cool.

One topic that has been particular warm in the online developer community as of late is the pros and cons of the new interactivity features as well as the tools used to develop them (read: AJAX, JQuery, javascript). In an effort to make the web work much more like a desktop application, developers are using more and more sophisticated techniques to push data back and forth without the user noticing. This provides much more real time feedback to the user, as well as adds a lot of functionality and makes interacting with the internet a lot more convenient with fewer time-wasting page reloads.

Take, for example, a familiar concept I’m sure you’ve seen and used yourself, what we call the “Product Selector”, where a user can choose a high level product they want to purchase, such as a bathtub, and using various slider bars, checkboxes, and other mechanisms, narrow down the result set to see the products that match their filtering criteria. BlueNile.com has used this for their diamond search for a long time. Product selectors like this are often very helpful and kind of fun to use. It increases customer retention and gives customers the ability to really find what they are looking for, or better yet, shows them a range of products that meet their criteria. However, there are drawbacks to the product selectors, including the inability for Google to crawl your products that are only accessible through the selector, the inability to have direct links to filtered results, and the ability to build a tool that the customer finds intuitive and helpful.

One big problem web-developers face in this post web 2.0 world is finding the balance between cool and functional. There is a fine line between enhancing a customer’s experience and frustrating the heck out of them. What is intuitive for a developer may seem obtuse to a customer (I’m pretty sure the developer is right though).

You can make a web page take you through 5 steps to create an account, choose your options, confirm your purchase, and agree to the terms, all in one single, seamless AJAX-enabled application. That is, until they realize they want to ship it to Aunt Gertrude instead, click their browser’s back button, and lose all the information they’ve entered, frustrating them to the point of abandoning the process.

Many of these new technologies break the expectations of the browser’s back button and bookmarks. Often these technologies can completely block search engine’s ability to find relevant data on your site. Often a page refresh or other unexpected action can cause the user to lose their place and what they were doing.

As a fan of emerging web technologies, I am looking forward to tackling some of these challenges in the coming year. However, I will be sure to be on the lookout for the unexpected consequences of clever web development.

So stay tuned, keep hitting F5, and look for some new features coming soon!