I attended a Webinar hosted by Vortx recently and had a chance to learn a few things that can affect conversions of shoppers.

1. 75% of shoppers use the search box to find products. They pointed out that the top 10 e-tailers all have the same style search box: a long narrow search box prominently displayed in the header.

2. You have 7 seconds to impact a shopper with the product detail, after that they will typically go to another product.

3. There are 3 main pieces of information shopper want to see quickly:

• Product Image
• Product Description
• Pricing/ Add to Cart

These items need to be clearly defined and prominent. Add to Cart button should be above the fold and use a color scheme to draw the eye to it.

4. The use of tabs is fading, major e-tailers are no longer using them to convey information.

There’s in interesting war of words going on between Microsoft and Google regarding search. An article at Search Engine Land alleging that Microsoft was copying search results from Google was the first salvo in the war. Microsoft followed up by accusing Google of click fraud.

The gist of Google’s claim, seems to be that Microsoft’s uses the data collected from the suggested sites/Bing toolbar feature to populate Bing’s search engine results even if the search results come from Google’s website.

Microsoft’s defense appears to be that they do incorporate the results into Bing, but it is one of many parameters when ranking a link. That the scenario Google executed was not legitimate since Google created false links to nonsensical search terms and then had there employees click on those links.

Who’s right and who’s wrong? Well both are right and both are wrong. Google’s honeypot essentially peeled away Microsoft’s aggregating of the parameters used to rank sites. By using uncommon search terms, Google was able to populate a false relationship between the search term and the site. If a popular term had been entered, the other parameters would have minimized the ranking. Microsoft however is using the search results from a competitor as part of it’s ranking algorithm. They are just letting their end user’s be the means of populating the data. Google’s honeypot just showed that when the other parameters are not relevant, then Google’s results will appear.

The implementation of a new website project often creates conflicts between the clients business requirements, the designer’s “Vision” and the websites capabilities.
This is especially true when using “out-of-box” software solutions that were created without the current project in mind. As a system engineer, it is my job to find economical solutions to these conflicts. In the recent upgrade of version 8 to version 9 of ASPDotNetStorefront, we encountered one of these conflicts with a 3rd party add-on for storefront.

In the previous version of the site, a third party add on was being used to add custom filtering and listing on a category landing page. However this add on was not compatible with version 9 of ASPDotNetStorefront. So we couldn’t use the existing solution. In browsing ASPDotNetStorefront‘s marketplace, we found a vendor that offered an add-on that offered similar functionality for version 9, so we purchased that and installed it. The installation was rather straightforward and went well. During testing the functionality appeared to correct. All that needed to be done was the “styling”, and that is were the conflict arose.

We had designed the layout of the form such that there was a header area and a left navigation area with categories. A pages content would display in a defined “div” area wrapped by the header and left navigation. This had been implemented at the template level in the previous version of the site and had worked well. In version 9, however, the new Add-on wasn’t designed to work with the left navigation, instead, it wanted the entire width of screen for its processing. This posed a problem because the category appeared below the left navigation, with a large gap between the header and the content.

Re-engineering the 3rd party add-on or redesigning the site was outside the remaining budget for the project. So we had to find a solution using the existing functionality offered by ASPDotnetstorefront, that could fit in the resources remaining. Ideas explored included using a different master page template for the category listing page, modifying the existing template to have two different areas for the left navigation and dynamically control which was visible. We finally came up with the idea of moving the left navigation into an XML config file where the display logic could be handled with XSLT parsing.

The benefits of doing this were two fold. First, the existing master page only needed to be modified to call the navigation code via the xml config file, no custom background code need to be created. Second, we could centralize the left navigation code so that the maintenance would be reduced.

To implement the changes we needed to modify the master page to call the left navigation using the XML config file, add the display logic to the XML config file, and modify the 3rd party’s category listing XML config file to call the left navigation config file.

Total implementation time for this was approximately 1 hour, which was substantially less than creating a custom master page or customizing the processing code. By analyzing the problem, defining options and examining available resources, we were able to successfully meet the requirements for design, business and software.

The other morning, when my wife and I went to get our boys, we had one of those moments parents both love and hate.  When we opened the door, we were greeted by a smiling giggling toddler.  G. looked at us, smiled and said “Big Poopy!!” then held his arms apart to to indicate something being big.  This statement was then corroborated by our nostrils.  As parents we were appreciative of the warning and hopeful that this may be the first step in him being ready for potty training, but we were also dreading the cleanup.  After all, how big does it have to be for a 2 year old to say it is big (it was).   Later that day, Microsoft gave me a “big Poopy” moment

I was reading an article about Microsoft’s plans for Internet Explorer 9 to support HTML5, the work in progress update to the HTML standard.  Microsoft has announced it will be supporting the version under the governance of the World Wide Web Consortium (W3C), but not recognize the Web Hypertext Application Technology Working Group (WHATWG).  As a developer this fills me with hope (the new features of HTML5) and dread (Microsoft’s definition of “support” and “standards”).  HTML5 will be offering several new tags to add features that currently have to be done via third party mechanisms and should really enhance  the web experience for end users.  Microsoft’s implementations of standards in the past has been less then thrilling however (IE6 anyone).  In fact I just encountered a “bug” with a standards issue in IE 8, that has been around since IE 6.

For several days, I had been working on an update for a website that required the use of cascading drop down boxes using AJAX.  The goal was for the values of a drop down box to be populated from a database, based on a previous value selected by an end user.  All seemed to going well, until I tested my code in IE8.  In my other browsers (Firefox, Chrome and Safari), my AJAX code worked fine, however it would not work in IE8.  When my code was executed, an extra “option” tag was being pre-pended to the HTML string, thereby blowing up the HTML in the select boxes.  My code was using the “innerhtml” attribute of the Document Object Model (DOM) to do the update to the select box, however Microsoft’s implementation of the DOM standard has had issues with the “innerhtml” attribute since version 6 and has not addressed it.  After finding this out, I had to rip out my code and rewrite it using JQuery. This lack of addressing bugs with existing standards, makes me very wary of Microsoft’s support of “New” standards.  This trepidation is further exacerbated because HTML5 makes extensive use of the DOM.

Microsoft and my son’s pronouncements that day give me hope for a less messy future, but both still make me fear the cleanup. The worst thing to happen would be if Microsoft causes a fracture in the standards and developers have to continue to browser specific code.

“Click here, edit this, move that, and save, there it’s that simple” said the presenter, with a shiny new website, upgraded to version 9 of ASPDotNetStorefront on the monitor, unfortunately the real world is never that easy. Recently, we completed the upgrade of a version 8 ASPDotNetStorefront website to version 9. Upgrades always have there own challenges and pitfalls and this project was no different. One of the biggest challenges for this project was ASPDotNetStorefront’s change to Microsoft master pages.

When upgrading, the first issue you will need to deal with is the change from ASPDotNetStorefront’s previous model of templates and skins to Microsoft’s master page model. I initially used the Upgrade Guide PDF for the conversion, but ran situations not covered by the PDF. The change to using master pages resulted in the use a server form tag wrapping the content in the master template. If you have any content that uses it’s own form, then that code will need to be modified. In this upgrade, we had two forms defined in the template that are present throughout the website, a website search form and a email sign-up form.

For the website search form we had 2 options: either use version 9′s new web control “as is” or modify the code to not use the form. We chose to modify the code because we are using a third party search add-on that offered extended search capability desired by our client. The modification we performed to the form were to use a JQuery function to capture the data submission event and do the post of the form data to the processing page instead of a normal form element.

For the email sign-up form, we had to use a different method. For this client, the email sign-up was handled by a 3rd party vendor, who’s form needed to be posted to. After posing the question to the ASPDotNetStorefront support forum and getting several answers involving some moderate to large programming changes, our web designer came up with a simple alternative: place the sign-up for in it’s own page outside of ASPDotNetStorefront’s name space and call the page in an iframe. Problem solved. For all intents and purposes the form is seamlessly integrated into the site.

Using both new and established technologies allowed us to meet the business requirements of the project without sacrificing the core programming benefits of ASPDotNetStorefront’s master templates. In the next issue, I’ll describe some of the issues we ran into with third party add-ons and working with the new templates.

You see the new email notice in the corner of the computer screen and open Outlook only to see staring at you the subject you dread,  “Undeliverable:…”, worse the from address says “System Administrator”.  Inside the email is a bunch of techno babble that is meaningless to you.  All you care about is the important document you tried to send, the one with the sales quote that has to be there today,  never made it to the final destination and you’re left wondering what you should do now and what caused it to bounce back.

First, relax, the answer to why it came back and how you can fix it typically lie in the bounce back email message you received.

Second,  the “from” address from System administrator is not a bad thing.  The email was typically auto-generated from your ISP/ Company’s email system.  System administrators typically set up the auto-generated emails to use a generic system account that they can access for system messages.

When reading the bounce back message, the important thing is to find the section of the email that explains why the bounce back occurred.  The lines of the message that appear to have a large amount of techno “gibberish” are called “headers”.  These headers contain processing information from the email servers and can be ignored for the most part.

The explanation of the bounce back will be explained in the body of the message.  The three most common reasons for bounced back emails are:

1.  Specified email account was not found.

2.  The email Domain could not be found by DNS.

3. The message was marked as spam.

Issues 1 and 2 are typically caused by typographical mistakes, joesmith@yahoo.com becomes joesmith@yah00.com.  Look closely in the message body and you should see the email address the message was sent too.  Does it match the intended address?

If not then correct and resend.  If it does, than other causes can be the wrong account was given to you and the account was deactivated, the recipients account may have been removed or de-activated. You should contact the recipient and have them verify that the email address you have is correct and active.

Emails bounced back due to Issue 3 are due to how the recipient’s email system is configured.  Very often we find that a recipient’s email system is employing third party software to evaluate incoming emails and automatically reject suspected spam.  These third party systems may reject an email because the sending system is listed as an email sender, has not been white listed (marked allowed) in the filtering software, or the “From address” in email header does not match the sending systems domain (this is called “Relaying” and is highly discouraged).  In these situations, contacting the recipient’s IT department or third party email provider may be necessary to allow your system to transmit email to the recipients system.

In the case of Yahoo, emails may be rejected because enough Yahoo users have marked email from the sending system as Spam, that Yahoo will just block the sending system.    Resolving this requires contacting Yahoo and having them remove your system from the “Blacklist”.  Typically a system gets blacklisted because another computer on the network has been compromised and has malware or a virus that is sending large amounts of spam through the email server.  Tracing down the offending machine should be done by your IT provider or host.

For the past two weeks I’ve been working on a project that makes use of Microsoft’s new AJAX controls for .Net.  These controls add a bit of snazziness to a website and help to increase usability and appearance.  With the completion of the User Interface data load, I turned my attention to fleshing out the action buttons on the screen.  That’s when progress came to a screeching halt.  When clicking on a button (any button), a nasty .Net error message would appear.  This message was appearing before any of the pages code could execute on the postback.  After researching the error message on the web, I came to the conclusion that this was a known issue others had run into and that some people had some work arounds.  However the example code for the work arounds was in Visual C# and not in the visual basic that this project was using.   After several hours of migrating the code, I got a sample page that worked in the same manner   the projects page.  When I applied the new techniques to project page, the error still occurred.  This aroused my suspicions, so I did what doctor’s do for surgery:  when in doubt: rip it out, thinking that maybe some portion of my code was blowing up the page. I begain by removing all of my custom event processing code:  error still occurred.  I then removed all non useful HTML:  error still occurred.  Next went all of the .Net textbox, literals, combo boxes etc:  error still occured.  When I finally got down to exact match to my working example:  the error still occured.  Ah ha I thought, something has realy snafued on the page.  So I deleted everything from the page, copied the example code over, and tested:  button click works, no error.  I started adding portions of my code back ( I had saved my original code before deleting code snippets), with each successive addition working fine.  When I had all my original code back, the page worked fine, no error.  So after a day of researching and coding my page, it was back to where I started.

The only explanation for original error kept seeing is this:  The page I was working on at some point had been saved as a Unix type file without the standard PC Carriage return/linefeed combo.  I believe this confused the IIS when it parsed the file resulting in the original error message.  When I copied the code, I saved it with notepad, thereby putting in the CR/LF’s.  When the code was copied back, IIS could parse it correctly resulting in no error.

So after a day of research, recoding, testing.  I’m back to were I started know to try saving the file in notepad before I start fixing an error.