For years, my husband and I have said “We will never build a house.  It is too time consuming and there are too many decisions to make.  It’s just too overwhelming”.  Well, here we are, building a house.   

During the process of building this house, I realized it’s just a process – just like building a website is a process.  I often hear the same concerns from our clients “We want a new website but it’s too much work, it is overwhelming, how do we get started”. 

First, you figure out what you need and what you want.   It’s important to distinguish between needs and wants because often times the wants do not fit into the budget.   

Then you have the task of deciding who is going to build it.  Someone with the technical expertise as well as the skills to hold your hand through the process and make it easy.  This builder or website developer needs a team behind them to accomplish the many varied tasks required to go from concept to completed product. 

The next step is the blueprint.  How is everything going to be organized to fit together.  In the web development industry, this is referred to as a site hierarchy.   

After many modifications to the blueprint, or the site hierarchy, the construction can begin.  First the foundation or the website template is built.  Then the walls or the content/functionality of the site are integrated.  And so forth, step-by-step, the house, or the website is put together.  Along the way, there are many, many decisions that need to be made but with any luck, your developer can break it into manageable pieces and use their expertise to consult with you on every aspect. 

We can’t forget the beloved change orders.  Early in the process of building our house, our contractor went to great lengths to make sure we understood change orders.   I assured him I understand because it’s the same process used when building a website.  If you want something different than what was originally defined, and it is not in the plan or on the blueprint, it’s a change order and it costs time and money.   

Being very familiar with the change order process, I knew it was important to take our time and make sure everything we wanted was on the blueprint and in the plan.  This up front analysis period requires a significant time commitment by the client and the builder, but it pays off later when the construction crew can work through the process, hopefully with out any change orders, and get it right the first time.

…or are they just another vendor trying to get as much of your IT and Marketing budget as possible?

(more…)

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.

One of the most interesting and rewarding aspects about my job here at Beacon Technologies is the fact that we are constantly looking for ways to integrate technologies together.  As a CMS Specialist, I’m always looking for ways to use our Content Management System, Hannon Hill’s Cascade Server, to further allow our customers to manage their sites on their own…completely on their own.

We all know about Flash:  a widely-used, extremely popular Web technology that allows site owners to jazz up their site with quick-loading animation.  But how would a site owner even think about maintaining that Flash application?  Have you ever seen the code that Flash is written in?  It’s complicated to say the least.  So we needed a way to allow our customers to have Flash applications on their site, but also allow them an easy way to maintain their images and content.

Enter Cascade Server.  With our innovative solution, customers can use Cascade’s Microsoft Word-based editor and intuitive interface to edit content and images within a Flash player that Beacon custom-built for them.  Since Cascade Server is based on XML, and Flash is a pro at reading XML files, you have your integration of technologies.  Cascade Server can take the content that you put into it, publish it out in XML-format, and the Flash application reads that XML and displays the changes.

We took this solution even further, and built an all-Flash site.  Instead of an HTML-based site calling a few Flash applications here and there, this site is completely built with Flash, and managed by Cascade.  Using Cascade, our customer can add, remove, and delete pages, edit content using the Word-based editor, and insert images and tables.

It’s just another way that we create innovative Web technologies for our customers.  To learn more, visit our Web site at http://www.beacontechnologies.com/.

The number one question that seems to be asked is “What should I test on my site”. Ultimately, that depends on the type of site you have (i.e. eCommerce, brochure, etc.) and the goals of your site. When I’m analyzing a site for website optimization strategies, the first thing that I ask is “What is the primary goal of the site?” (i.e. lead generation, purchase a product, sign up for a newsletter, etc.) I believe that this is the most important question to know the answer to because it dictates all subsequent actions that you should take. Let’s look at one example answer to this question and how it affects the testing that should be done: “I want to generate qualified leads that I can use in email marketing campaigns.” From this statement, you can deduce that the best place to generate these leads is through some type of sign-up form.

A Sample Contact Form Analysis

Let’s assume that Google Analytics (GA) is already installed on the site. Let’s also assume that a “Contact Form” goal has been established. The image on the right is a sample funnel visualization for the contact form. Click on the image to enlarge it and see the detail. Notice that 201 visitors landed on the contact page and only 13% completed the first step in the funnel and moved on to the contact us form. This generally means that you have lost 77% of the potential new leads. Scary isn’t it? Now notice that of the 13% that completed the first step, only 40% actually completed the form. Overall, only 7.9% of all visitors that entered the funnel actually completed it. Now what?

Since 77% of visitors are abandoning the funnel from the Contact Page, that’s the first place to look to perform testing. The image below shows our fictitious contact page. Notice that the contact page also includes a phone number and mailing address. It’s very difficult (if not impossible) to identify how many of the 174 visitors that didn’t continue into the funnel actually called or send a snail mail in lieu of filling out the form. Or if any of them contacted the company at all.

There are many tests that could be performed on this page such as moving the form here with and without the phone numbers and addresses below the form; putting the form on this page and providing a link to the additional information, especially if the primary goal is to get visitors to fill out the form; or this page could contain 2 links, one to the contact form and the other to the additional information.

Use your imagination and see how many variations you can come up with. Share them here as an online exercise. Happy Testing!

Every usability expert, designer or developer could give you different opinions about what makes forms more usable, less confusing and less daunting. I sought out to research all the experiments and form a general list of things that developers, designers, and gurus should and should not do. The rest, as usual, always depends on the context of the project.

After combining this research with fellow co-workers and everyone’s combined knowledge, I generated a short list of common things you can do to improve your forms, but I want to discuss what types of forms I’m talking about first.

One type of form is the generic one: I’m talking about the generic “contact” form on the web, the one with fields that aren’t even new to my grandmother anymore. Fields are empty areas for you to fill in data, usually personal data. Fields like “Name”, “E-Mail Address” and “Comments” are very well known. Also, forms like “Request for Quote”, “Search” or “Sweepstakes” have much in common with the “Contact” form: they are generic, no task required, “enter in that information yet again”, forms.

The other type of form is one that requires more thought on the user. Forms like these include insurance quotes, submitting payment, government forms, loan requests, etc. These are the types of forms you receive in the mail in a booklet and have an instruction book accompanying it. These forms are quite different from the “generic” forms I mentioned above. The more data and thought necessary required from the user, the more division and instruction is needed in the form itself. In general, I think each form in this division should be designed in each instance, so I don’t think general tips apply all the time, but most of the ones I will list can apply.

So we will only be discussing the generic form, which is a good base for any working professional in this area I think. This form shares a commonality with many others, your contact form will be at least 50% identical the next guy’s contact form, and this means that already your user base is experienced with your form. Which brings me to the first tip:

#1 Don’t break convention just because it looks neat or you think it’s better
Break convention only if it works better. Your forms should be putting your user first. They are active participants ready to endure your form gauntlet – do not change their minds! Making your forms work should be the number one priority. What’s the only way to know if it’s working better? Field testing.

#2 Do field testing
I can’t agree with the usability experts more: field testing always shows you what went wrong or right with your forms. I understand that many companies lack the resources to hold usability tests, but they are a necessity. My favorite thing to do is actually allow the client to field test by bringing them in and watching them use your form. Make your coworker do it. Make your mom do it. Don’t tell them you’re testing the usability, make something up. If you are able to watch them use it, you did not guide them through it and you learned something from the experience, congratulations, you just did usability testing. Now take notes and correct what went wrong. This won’t be as accurate as some measurement tools the experts have, but it’s just as helpful and it was free. Have to say, nothing is more embarrassing then to watch that client months later use it and complain because it makes them frustrated or simply does not work. Field test before it’s too late.

#3 “Use the right field for the right task”¹⁸
Crescimanno and Nielsen argue that every field type should be appropriated correctly with the label. For example, if your label said “First Name” you should not use a radiobox for your field because then the user cannot correctly fill in their first name. A more complex example would be if your label said “Expiration Date” and you gave the user 3 drop down menus, 1 for month, 1 for day and 1 for year. The month and day fields have an absolute beginning and end, 01-12 for month and 10-31 for day. The year field, on the other hand, is a bit arbitrary since we are concerned with when said subject expires. Do you list the years until 2012? 2050? Should the user have to endure a very, very long drop down menu or should the user face having their year not even listed? If you put into too many years or not list enough, respectively, this could happen. Why not just make all 3 fields free entry? Or why not require just month and year in the same format and make it easier not only for the user, but also your developer? Usually there is a good solution to every type of data you need. And like Crescimanno suggests, stay away from multiple-selection boxes that are confusing (and may not even work in all browsers).

#4 Don’t let your clients pick your form structure for you
Unless your client is a certified master in creating usable forms, don’t allow them to pick what type of data they “think” they need. Have a good sit down with them and ask considerate questions about why they think they need this form, what do they expect from the user, what data are they looking for, how do they intend on using the data, and so on. I guarantee that your company (full of qualified, wonderful people) can create not only a more usable form, but also a form that integrates better with the database, integrates better with the graphical design of the website it is in, does not deter the user away, that takes the least amount of time to fill in, etc. Clients are blind-sighted by the bigger picture, take control of this crucial analysis process.

#5 Use informative error messages¹
Don’t tell me the form encountered a critical error after I hit “submit”. Don’t tell me my e-mail address is invalid when I only have not registered with it yet. Don’t tell me my password is not strong enough, tell me why. Please.

#6 Use better placed labels¹²³
Do not make them bold, do not place them far away, make them consistent with other labels, right-align if you won’t place the label above the field and don’t use illegible fonts.

#7 Quit putting in a reset button⁴
Reset buttons are accidentally hit instead of the “submit” button when the user submits a form, so what purpose does it serve?

References:
1 A List Apart: Sensible Forms: A Form Usability Checklist
2 UX Matters: Evaluating the Usability of Search Forms Using Eyetracking: A Practical Approach
3 UX Matters: Label Placement in Forms
4 Creating Good Websites: Usability
5 Sitepoint: 7 Steps to Usable Forms
6 Krug, Steve. “Don’t Make Me Think: A Common Sense Approach to Web Usability”, 2000, New Riders Press.
7 Nielsen, Jakob. “Designing Web Usability”, 1999, Peachpit Press.

I have a little roster of Google bloggers in my bookmarks and RSS feeds. These are Googler personal blogs and offer insights into Google projects, the party line, and general what doing in life working at the Googleplex.

I’ll start with the first and one of the most well-known:

Matt Cutts- Required reading for those involved in search marketing.

Niniane’s Blog- Google engineer. Comedy and tragedy. Works on super secret stuff. (shhh -it’s Google’s virtual world project)

Mihai Parparita- Part of the Google Reader posse. Browsers, rss, twitter.

Nelson Minar – Google Software engineer. Cali, gaming, tech, la vie.

Jason Warner- Google recruiter. Tidbits on how to walk the walk, talk the talk.

Reza Behforooz – Google engineer. Rises before youz.

Brian White – Google’s Search Quality group. Well, there’s spam egg sausage and spam, that’s not got much spam in it.

Adam Lasnik – Google Search Evangelist. Self-professed geek.

Daniel Russell – ‘Uber’ Tech Lead for Google Search Quality. In ur head eating u brains.

Paul Tyma – Google software engineer. Brewing the perfect cup of Java.

I’m sure there are a lot more Google blogs out there. Send me a link if you know another that you enjoy.

After spending nearly 15 years with AT&T as a software developer/engineer and Program Manager for their Corporate Intranet, where I got hooked on the internet during the late 90’s, I “retired” to start Beacon Technologies during the dot-com craze.  I wish I had a dollar for every person that said or thought “I’m going to open an online store and make a ton of money!”  The ongoing belief was “Build it and they will come!” – a saying stolen from one of my favorite movies (“Field of Dreams” in case you are wondering).

Easy money, right?  Absolutely!  But let’s get on the same page here.  It’s easy to spend money.  Making money is an entirely different story. Okay.  I’ll admit it.  I said the same thing.  After starting up Beacon in 1998 and spending 5 years helping other companies produce millions through the internet, I said, “Hey, why don’t we open an online store and make millions too?”  We just had to pick something to sell, then, of course, we would make money hand-over-fist!

As a North Carolina company, we considered pottery, but we were worried about goods getting damaged during shipment.  We considered kites, but worried about demand.  Then THE product appeared one day while reading the local business journal – NASCAR Furniture.  The sport and the industry have deep roots in NC.  Better yet, we decided to go with leather NASCAR Furniture.  High margin.  Sell one or two a month and we’re good.  We would use our own eCommerce engine, our own securely hosted data center, our own highly successful search engine marketing expertise and simply drop-ship the product to all those NASCAR fans anxious to buy our products.  Like a lot of business ideas (especially back during the dot-com era), it seems like a no-brainer and too easy.  Oh how naïve we were.

So, in November 2004, we launched RaceFanFurniture.com.  In all seriousness, our primary motive was to create a “live” online store as a model, but hey, generating a little revenue would be gravy.  We would operate the store to understand issues that our customers experience with our software services.  This also gave us a site to implement and evaluate new features (including 3^rd party extensions) before recommending them to our customers.  It just made good business sense.  But deep down, I also wanted the “easy money” too.

The site generated 70 orders in 2004; 533 in 2005; 2474 in 2006 and 8566 in 2007 after expanding the product line, revamping the site and changing the name to SportsNutShop.com.  We are conservatively forecasting 24,000 orders this year.  With this growth, you may say, “Well, it is easy!”.  Not even close.  Remember, although we have good business experience, we come from the IT world with very little experience in retail.  We observed how our clients operated their online stores…but primarily from the technical perspective.  There are many, many other factors and requirements that affect success.

Bottom line is that it’s not easy…to make money with an online store.  It truly requires the same thought processes and business planning as a brick-and-mortar business.  After 10 years of ecommerce support, I’ve learned a lot.  I plan a series of posts to share some of this first-hand experience, primarily with specific examples from SportsNutShop.  You may write off some of this advice to what I call the “Duh” factor, but there are so many components to a successful, smooth-running ecommerce business.  So whether you are a rookie or a veteran in the ecommerce world, I sincerely hope you will find some “nuggets” that will make a difference. Some of the topics I plan to post about are below.  Please let me know if there are other topics that you are interested in.

• eCommerce Software
• Payment Gateways
• Shipping & Return Policies
• Product Selection & Management
• Inventory Management
• Accounting
• Vendor Management
• Drop-shipping
• Fulfillment
• Warehouse Management
• Search Engine Marketing (General, Organic, PPC, Shopping Engines)
• Email Marketing
• Hosting
• Site Search
• Online Help & Customer Service
• Gift Cards
• Loyalty Programs
• and More (as I think of them!)