Nobody’s going to discount the growth of mobile. We’ve all got our collections of phones, tablets, and even the occasional netbook. However, a fortune thrown at mobile development will net you no extra revenue if it doesn’t serve a user purpose.

While users on the desktop may be willing to put up with moderately clunky architectures, and sometimes enjoy clever things which achieve more of a branding goal than a direct sale, such extravagances are lost when your hands are cramped around a tiny screen waiting for data to slowly trundle across a 3G (or semi-4G) connection. The medium, in many cases, directs the message.

Is your sales message necessarily long-form? Remember, scrolling is clumsy to the point of awkwardness even on the best smartphones, and NOBODY likes pinching and panning to read a long novel. For example, if you’re trying to show detailed illustrations of spa services and explain the staff’s experience, nobody’s going to sit through it.

A better choice may be to abandon that messaging entirely for mobile users. A quicker hit with a stronger value proposition can work instead– for example, a downloadable coupon.

It’s also important to consider that mobile users may not even be engaging you for a direct buying opportunity. If I open a brick-and-mortar retailer’s mobile site, my likely concern is less about making a purchase online, and more about finding a nearby location. Feel free to remove your shopping cart, return policy, and such, to put that location-finder front and centre.

Maybe you’re not a retailer, so that’s not the obvious answer. In that case, it’s time to reevaluate the reason someone is on your site in a mobile device.

The first likely choice: he’s trying to find your retail partners. The good old “Where to buy” link is vital. However, that can be risky. If your distribution channel isn’t “tight”– knowing not just which distributors you sell to, but even most retailers– you may not have the details on important local vendors, leading the user to give up on your product as unavailable in his neighbourhood.

The manufacturer does, however, tend to have an edge on product information. Frequently, a retailer’s displays are limited to breif summaries of products, and whatever you can read off the box itself. I can recall trying to peck out manufacturers’ websites on a BlackBerry to do feature comparisons in the store– and when I got there, ending up in large, slow-to-load pages which didn’t fit my needs at all. Honestly, if you look at a screenshot like this, you know– if the information you need is even on the page in the first place– you’re going to be pawing all over the screen to try to dig it out. A simple, appropriately scaled product photo and a table of key features, on the other hand, would close the deal your point-of-sale display already opened.

versus
Indeed, this may be a rare truly appropriate use for QR codes– since it clearly ties to a single product’s packaging, a customer could scan and arrive at full details which won’t fit on the back of the box. A further enhancement could even come by tying it to packaging version– using a different code (and thus a different page) for seasonal, region-specific, or bundled products.

People scream blue murder about Amazon using their mobile presence to aid customers in comparison shopping, but customers who are researching their purchases on mobile devices aren’t just doing so to find the lowest price– information matters. Providing those details on a well-thought-out informational mobile site can help your brick-and-mortar partners outcompete Amazon- if the customers can get their questions answered before even seeing the online price, it increases their chance of closing the deal in-store.

Of course, all these paths lead customers to a purchase– even if not directly through your site. There are retailers who have to consider “maybe my product is simply not purchased off a mobile device”, where the value proposition is primarily informational.

Any sort of transportation product fits there– yes, you might be able to build a clunky product to let me buy a bus pass with a credit card number or mobile wallet payment, but I’m probably just wanting to check the time-table.

Other likely “information only” mobile presences include products which could require emergency aid (i. e. treatment if you swallow cleanser) or field service (repairing a damaged automotive component). While it may be depressing to focus on the crisis aspects of your products, being timely and correct may be a great way to earn customer trust.

Cuba

Problem: You got cut off from the outside world in 1951. People come from far and wide to experience your unique brand of obsolescence. In a way, it’s quaint and cute.

Symptoms: ColdFusion or Perl as significant portions of your application. If you’re using PHP, it won’t run without register_globals or magic_quotes, and no chance at all of working on PHP5. The inability to port your site, without significant modifications, to commodity hosting or cloud services. The overall system may be elegant, but the costs and hassles of finding anyone who can work on it are piling up every year.

Solution: Fundamentally, you have to ask– how much longer do you want to keep patching together those ’47 Packards? A complete rewrite is the best way to pull your site into the 21st century. Then you have to follow it with a policy of engagement with the outside world– regular maintenance and support to ensure it’s easily transitionable to future needs. However, your site probably has plenty of well-thought-out specs and a working environment which can provide reference, so development can be cheaper and easier than a full from-scratch implementation.

Somalia

Problem: Nobody’s in charge, steering your investment, and the environment is too unstable to foster any long-term development. If you’re lucky, you have one or two segments of the site which are almost self-managing and work well. (And you expected a “pirated software” joke here!)

Symptoms: Off the shelf software installed and partially-configured. A typical Somalia website has a WordPress 1.x install with the default theme and three posts you put in shortly after installation, a Zen Cart install that never had its payment processing configured, and a stack of static HTML and flash pages that may not link to either.

Solution: Wipe and start anew. In this situation, there isn’t really much to salvage. If you have a functional unit which does work, you might want to grant the team behind it a bit more autonomy because they’ve clearly got a process which works.

Libya (pre-2011)

Problem: There’s no independent structure– there’s just Colonel Khadaffi.

Symptoms: Your “templating system” consists of calling the one guy in IT who assembles a new page on the fly. At best, this is because of a site which grew out of control, and at worst, it’s a deliberate design decision to ensure you can never replace that “one guy”.

Solution: Stop and scope your project, based on your experience and usage patterns. This is huge, because you can speak from it, rather than just guessing what you’ll need. Odds are, you’re asking for the same task to be done again and again (whether it’s “add a new product to checkout” or “update the calendar”) and those are the tasks which should be automated.

Democratic People’s Republic of Korea

Problem: Juche! Self-Reliance!

Symptoms: You’ve got a mountain of house-made custom software– a home-brew cart, a home-brew blogging system, and a home-brew CMS. It probably runs on a custom web server on a home-built PC too. This means you’re having to reinvent the wheel on every cool feature you see elsewhere.

Solution: Figure out which systems can be replaced by cheap, widely-supported, and maintained off-the-shelf packages. If you need a custom checkout system, fine, but if you’re spending $300,000 keeping developers on hand to replicate the feature set of $300-for-life CS-cart, you’re throwing money out the window.

Zimbabwe

Problem: Everything costs $100 trillion

Symptoms: You’ve “enterprised” the crap out of your site. No free MySQL when Oracle will do. Your hosting costs are more than your site generates in sales, because you’ve got a quad-redundant setup in a military-grade data centre capable of supporting the full wrath of Anonymous and still running smoothly.

Solution: Get over yourself. It makes sense to design to scale, but it also makes sense to wait for the system to pay for itself at the current size before you worry about scaling up. If your site does get that big, you’re going to have to refactor stuff anyway.

Disclaimer: No offense is meant to the people or leadership of these countries; it is rather meant for humourous intent.

A staged deployment offers you several benefits at no significant extra costs.

First, you can get something live faster. If you don’t have a corporate presence, or your presence is technically decrepit, it is vital to replace it quickly. Every week you waste is a week your old site is discouraging customers and potentially strangling search engines.

Second, on a related note, it lets you get feedback from users faster. Some people really go the whole nine yards, and hire focus groups to test and prototype their site. But most small businesses start with sites designed based on an estimate of what users need, based on their own customer experience and our analysis. There’s going to be an expectation that things have to change, after you get the third angry “where’s the price list?” email. Rolling out a basic site early allows you to find and correct those mistakes before they’re built into deep links and navigation menus all over the site.

In an ideal world, each phase of development will really be three sub-phases:

• Build the code as specified
• Wait a fortnight to gather real customer experience
• Update the site based on what we learned

Moreover, in many cases, the feedback can help you steer future phases of development. If you find everyone’s looking at the Category A page on the main site, maybe you need a more prominent Category A presence in your shopping cart. Maybe nobody will fill out a contact form asking for Social Security Number, so you’d better not use that to attach all the customer data in your CRM.

Staged deployments also allow you to stagger your own development efforts. It does take a fair amount of your effort to build a site– get all the images you need, review the branding, sign off on content. If you also have to do this for a shopping cart or other major site module, the labor can be tremendous. You often end up involving many different departments, which can result in trampled toes and wasted efforts. Imagine, for example, if everyone in the office goes to try to obtain logo and letterhead at once. Imagine if they submit three different logos.

Hacing a break between modules allows you to organize and plan for the next phase– lining up any assets we’ll need, and reviewing the results of previous changes to make sure nothing needs to be changed based on them. It also simplifies things if you hope to use a seperate chain of command– maybe main corporate signs off on the front page, and then you introduce the retail division with autonomy over every decision made pertaining to the cart.

All too often, development turns into a “the perfect is the enemy of the good” situation. By waiting until you can build a full questionnaire, instead of going live with a contact form, you’re leaving leads on the table. By holding the entire site while you build out a shopping cart, people can’t find out your address and hours of operation. Is it worth it?

A real doozy is the “can’t we edit…?” line of discussion. Whenever you build a database-driven system, like a CRM system, or even a sophisticated order-tracking or shopping cart system, people decide they want to be able to edit the enterred data.

Now, there’s nothing inherently wrong with allowing you to edit PARTS of your data. The trick is to abstract it– rather than editing data with no constraints, you provide the functions to perform legitimate business operations. For example, it makes sense to have an “update customer address” tool, or a “delete product from order and adjust price tool.” The dangerous aspect comes when you want to start editing any field on a record free-form.

• First, it’s a red carpet to data sabotage. Subtly change a few addresses on your corporate mailing list files, and all of a sudden, you’re sending white-papers to people living at the bus station. The real danger is that it’s subtle. If someone blows away your database in a fell swoop, well, you can identify it immediately and reach for backups. But if you contaminate a record or two a day, by the time anyone notices something’s wrong, the data’s a complete mess.

  A second dangerous angle is the use of editing tools to cover tracks. Say you print those invoices and send them to customers. You send out a $400 one, then edit the job back to $40. Pocket $360, and the database won’t notice the fraud because its numbers match the contents of the till.

• Second, it completely bypasses connections inherent in the data. Say that you store Parts, Labour, and Tax columns in your invoice system. If you are forced to edit that data through a “reprice” tool, it will be consistent. Tax can be correctly re-calculated if you change Parts or Labour. But if you provide a simple box for each field, the connection can be lost, and then the revenuers start coming and asking why the net tax on the invoices is 1.6% instead of 8.1%.
• Finally, editing tools are often an excuse, or a means, to bypass your company procedures. “Oh, we need to make an exception in the system… we’ll use the dumb editing tool because the smart system won’t let us make an exception.” If you’re trying to make exceptions all the time, your rules are likely faulty, or you’re giving your ataffers a lot of leeway. Either way, it’s not a well-run ship.

I suspect this mindset comes from the fact that customers are used to “non-programmed” ways to run their business. Using a flat Excel spreadsheet or pencil-and-paper files doesn’t enforce any discipline. Want to delete your recievables for July and put a graphic of a unicorn in? Excel won’t complain! It doesn’t care! But I care. If you edit your database into oblivion, it will take far more effort to make it right than just letting the system enforce its rules.

While it often makes sense to make a shopping cart, or a blog, the central aspect of your site, you do have to recognize the tradeoffs.

Many canned back-end systems are designed for easy template-driven management of specific info. A cart “sees” data as products and orders. A real-estate system “sees” listings and neighborhoods. As a result, it’s simple to expand a cart from 3 items to 4. To streamline those tasks, you give up power when it comes to adding, say, a streaming video showcase and downloadable press releases- it doesn’t fit the back-end metaphor.

So why not use a non-specialized system like Mambo or Joomla instead? Because you don’t want to try to emulate that special ‘streamlined’ functionality. It might be coaxed into doing property listings or products, but it’s hardly the most efficient way, and leaves you more prone to errors and inconsistencies when the paradigm isn’t built into the software. Such an incomplete vision often means empty templates and incomplete entries, as there aren’t the needed sanity checks you’d see in a system built for the task.

Sometimes the alternative to insufficient control is overkill. Some packages try to do it all. Magento offers a fairly sophisticated page editor. Add the right modules, and WordPress will make tea and biscuits. These packages, however, often end up being complicated to operate. Metaphors mash poorly when you need to read blog posts as property listings, or generic pages as a live catalog. Moreover, you end up fighting the divided needs– templates ideal for a cart are suboptimal for corporate information pages, or you have to suppress blog links on your main page.

For many users, the right answer is a hybrid system. Multiple tools for different jobs. Static pages or a non-specific CMS for their main content, but harness a specialized tool for the big “moving parts” of the site– the cart, the blog, the searchable inventory. In such a way, you minimize the time spent dealing with the specialized product’s limits, and still enjoy its strengths.

Many of our larger projects work so at Web-Op. For example, Belleza Olive Oil can use the full power of a cart to sell their wares, but never show the cart’s ugly category or home pages. Static pages ensure they get the image they want with no compromises.

Of course, it’s got its costs– more development time, and sometimes more of a learning curve, but it’s often worth it to ensure you’re not trying to drive nails with a spoon.

Apple has steadfastly avoided the Netbook trend– the sub-$400, 7″-12″ laptop which now represents a significant amount of all PC sales. No surprise– a $399 iNetbook would cannibalize sales of their $1,000 and up machines.

Instead, the iPad runs a limited system most reminiscent of an iPhone scaled up to twice its original size. Among the major limits: limited developer access, crippled multitasking, and the same interface conventions.

Limited Developer Access doesn’t sound like a big fear. Get anything you want from the App Store. It’s all pre-vetted and safe too! Consumers initially like the concept of a ‘safe’ source for software. Apple drools over a cut of every sale. But what happens when there isn’t the App you want, because of Apple’s policies? We’ve seen it plenty of times on the iPhone platform already– Google Voice was delayed and hobbled, turn-by-turn navigation arrived late to the party. Unfortunately, the truly breakthrough products– from the open-architecture PC to Facebook– have benefitted from an ecosystem which allowed someone to bring out the “out of left field” application.

Why does multitasking matter? The more hardware resources you have– whether it’s screen pixels, processor cycles, or memory– the less likely you’ll need them all the time. Moreover, the more convinient it can be to have something else in the space. If you have a big monitor, you probably don’t keep one window full screen all day– so it becomes worthwhile to have media players, IM clients, and such which can fill in the extra space. A device like the iPad will be fundamentally limited if you have to stop and go to a different program every 5 minutes.

Finally, the interface conventions. Once you get to an 8″ or 10″ screen, you’re making excuses if you can’t have a decent keyboard. In such a situation, it seems like you’re really just trying to keep the device a toy– if people can’t write a document on a touch-screen, they’ll buy that $1,000 MacBook.

All in sum, it means Apple delivered a compromise device– built more around their desires and product-segmentation aims than a real consumer desire. It also means thaat it’s unlikely to become a true “platform” the way the iPhone and iPod systems did.

For the person who wants a full-scale device, the Asus EEE Tablet can do anything the iPad can and a thousand things more. For the customers who want a little less, single-purpose devices like the Kindle offer a experience built around a single need. The eBook sales logic for the iPad seems a little weak when you realize the Kindle offers 10 times the battery life and a text-friendly screen.

Finally, how does it fold back into the whole web thing? Simple: The “Our Company is an App” thing will not scale past a certain point. Yeah, when it’s a mobile phone, fine, but when you’re looking at bigger screens, bigger memories, and bigger expectations, you’d better return to the basics of the Web:

* There won’t be one master device to emulate the behavior of. The iPhone apps which follow Apple’s style guide are fine. But a website designed to match the feel of OSX looks out of place on Windows XP. It’s true even on “midsize” devices like netbooks and tablets, which may run the iPhone OS, Windows XP, Vista, or 7, Linux, or potentially even Android.

* Users will expect an experience on their terms. Their MP3s are running in the background, so don’t load music. They may be leaving an instant messenger or video open, so don’t hog every pixel on a display.

* Compatibilty is still king. Yeah, it works in Mobile Safari on the iPad, but for the people who bought someone else’s tablet and are running Firefox or, help us all, IE8?

* There’s no master storefront to get on everyone’s desktop. even if you make apps for the main mobile and “pad” systems, it won’t reach a lot of people, and especially the desktop. Instead, appeal to normal search behavior and live inside their browser. Or do you prefer deliberately reaching only a small percent of the market?

SEO

Obviously, at Web-Op, we tend to think of search as fairly important. However, even sites which have been well designed often fall apart when you arrive at the shopping cart. While much of this can be explained because carts are often taken as “packaged” system, too complex to re-tool, it’s just as often policy decisions or the refusal to add easily-obtainable addons.

• Pretty URLs. Nobody likes standard shopping cart URLs. They generally mirror the internal structure of the cart’s programming.

  http://yourstore.com/cart/product.php?product=2005 is ugly, and ignores keyword-ranking opportunities.

  However, most carts now include powerful extensions, either in the box or as a 10-minute install, to convert that URL into the cleaner, keyword-rich, http://yourstore.com/cart/new-shiny-widget-2005.html. The fact you can still find many shops– even new ones– with the standard URL just suggests laziness or fear the pretty-URL system may have unexpected problems.

• Distinct Product Content. It seems so easy to have a cart with 100,000 products. You can often siphon the product data directly from a vendor catalog or data feed, and why wouldn’t you want to stock everything, especially if it’s items which can be drop-shipped? If it sells once, it’s profitable. The problem is content. If your product listings have the same information as everyone else, hot off that easy-to-access feed, there’s no reason for you to rank over anyone else’s page. Such problems even appear at the inside-the-site level, as your text for the 3, 6, and 24-pack versions of a product read nearly identically to Google. With primarily duplicate content, why even bother deeply spidering?

  If you can’t provide something distinct to say about each product, chances are it doesn’t belong in your catalog, or can be presented in a different way. Don’t do 100 pages for “Cardinals uniform: #00″ to “Cardinals uniform: #99″. Do one page and make the number selectable, and you’ll enjoy superior rankings.

• Sensible Heirarchy Depth. Once your product range hits a certain size, you have to start thinking about how to organize it into a heirarchy. However, one thing often ignored is the further the products are, in clicks, from the well-promoted pages of the sites, the less they’ll be spidered and the worse they’re likely to rank. It’s a balancing act– are you going to need too many clicks to find any product, or are you going to end up with pages stuffed with 500 products per category, and overwhelming visitors?

Usability

Once the customer arrives on site, you have to provide a compelling experience if he is expected to buy. I don’t here mean an all-singing, all-dancing, 3D Flash shopping experience, but rather a shopping experience which leaves them with no questions unanswered.

• Good photos. Often, selling is a matter of providing the right photos. Some of the most common problems with photos are:
  • Too small photo. If you can’t see critical measurements and proportions, the picture is too small. A common related problem is the picture which shows a huge item, but isn’t large or clear enough to display minor but key details: connectors, model numbers, or serial numbers when relevant. Best practices include several photos, or photos with a zoom and pan facillity. A standout here is Newegg.com, whose photo viewer allows you to inspect individual components on circuit boards.
  • Stock Photo. I’ve seen photos where the model number says you’re getting A, and the photo says you’re getting B. If you don’t have the vendor’s catalog memorized, who knows what to expect? In addition, the stock photo can often be mediocre or uninformative– a customer who is visiting you looking for more information may keep shopping til they reach the seller whose photos finally answer their question.
• Sensible Option Grids. Often, stores provide the wrong choices– or the wrong type of choices– for their products. Checkboxes (seperate optional choices) are often mistaken for radio buttons (mandatory choice of one from several options), and needless options are added but must be acknowledged. It’s worth the effort to regularly review product lines and make sure you’re not retaining options which are no longer relevant or merely add confusion. In extreme cases, it may be simpler to break products down into common models, purchased with one click, and custom orders, with more choices or even directions to call in to order.
• Browse by meaningful categories. It’s a fundamental question: where is the product I want? While many users will simply resort to search, it’s a fairly hostile option for customers who want to compare several products, or check for an alternative in the field. Grouping by newest arrival or some other internal construct is guaranteed failure– who will know what to expect? Only your employees. Shop by brand only works if the product lines are already narrow. You really need to have enough categories, in a meaningful structure. Think about how your products work together, or how they’re organized by customers.

Trust

Lastly, your cart needs to build trust. In most cases, it’s not so much generating anything new, as much as avoiding the temptation to do things which will undermine trust.

• No gimmick pricing. Nobody likes it when you play games with them. The most common game is the shipping price one. You can either take a $5 item and slap $15 of shipping charges on it, or you can make promises of free shipping knowing that they don’t apply to most orders, or worse yet, are basically a teaser– free shipping if you’re willing to wait three months.

  Other pricing gimmicks include “$10 off if you’ll sign up for a $200-per-year, difficult-to-cancel savings club”, and “Free add-on, if you’re willing to spend as much as the addon costs in postage.” They do worse than simply looking suspicious. You have to add extra checkout steps to support them, basically forcing the customer to pass through a gauntlet of distrust in order to buy anything. Who’s going to follow through?

• Accurate Inventory. If you lie to me, even a lie of ommission, then call me back and say “it’s back-ordered three months”, do you really believe I’ll wait it out? No, I’m going to find another vendor. All you’ve earned by not giving me correct inventory data is a credit card processing fee. Full-featured carts generally have inventory built-in, so you can easily give yourself a buffer by setting the product to sell out when there’s like 5 left on the shelf for call-in orders. However, the practice I generally see is “put 10,000 of everything in stock, we’ll handle sellouts when they happen”. Real professional.
• Accept payments the way customers want to make them. While many small shops like PayPal for its simple qualifications and easy integration into the site, it can often be a liability. Many customers feel they may need a PayPal account to buy something, and having to find the secret route to make a payment without is more effort than they want to take. Supporting normal payment methods first– with PayPal, Google Checkout, and mailing banknotes in an unmarked envelope as backups– gives you the look of a full-sized company, not someone selling from your garage.
• Fair Return Policies. Most ecommerce is by mail, so customers tend to be especially wary about how they can get out of a purchase which goes bad. Your return policy should be based on a fair understanding of the product being sold, and how it’s likely to be tested and used. If you’re going to have to wait 21 days for the manufacturer to get back with “It’s clearly defective, send it back”, that 7-day return policy is not generous. Moreover, it should be prominent– link it on every page of the site if you want. You can never be too up-front with your policies, and a decent cart will make it easy to put in the template.

In most cases, it doesn’t take huge technical skills to get the most out of shopping carts. A few new features and strong, sensible policies are really the key to shopping cart success.

]]> http://web-op.com/blog/seo/making-carts-work/feed/ 0 http://web-op.com/blog/seo/sensible-cms-decisions/ http://web-op.com/blog/seo/sensible-cms-decisions/#comments Fri, 11 Sep 2009 20:51:24 +0000 jack http://web-optimize.com/blog/?p=94 Whether you have a canned blog install or you’re developing a completely custom content management system, many website owners don’t really consider the consequences of their policy decisions. By making smart choices, both users and search engines can do better.

Limit Control
The “ultimate” in features for content management systems are packages like DotNetNuke or Joomla which allow a free-form editing of almost any content unit on any page.

However, it’s a “power tool” situation– the tool which makes it easy to do complex tasks, can be a tool which makes it easy to shoot your foot off. Full what-you-see-is-what-you-get editors are particularly notorious for it– by allowing users to manually style parts of the site, they often generate bulky code, with needless styling options, and encourage abusing HTML elements which are key for structure for styling. Ever seen an entire page as a header? I have.

Why does it matter if you misuse HTML? Search and performance. A poor page structure appears spammy, or alternatively just hard for search engines to identify key content. Moreover, a page heavy with mountains of extra tags will load slowly for both real visitors and search engine spiders.

What’s the alternative? Instead of an overarching CMS package, you may want to consider a “silo” package– a mini-blog which can only generate news entries in a controlled, consistent, and attractive formatting, as an example.

Pick Standard Conventions
People expect certain conventions. For example, news sites generally put the the freshest stories at the top. Some people think “I’ve got this one world-beater story, and it belongs on the top all the time.” Big risk. You’re wasting the most valuable space on the page. If you aren’t making it clear in seconds that new content exists- many visitors will leave. In the worst case, your freshest news will be on page 2, where few visitors will find it. You’ll look out-of-date.

Similarly, don’t play games with layout. Some people think that disguising the ads near content helps click-through rates. Yeah, except the people who click through don’t come back.

Finally, even though most CMS systems make it easy to go for a sprawling site, think heirarchy. Are you dividing everything so fine that you have only two sentences per topic? Rein in the divisions then. If you’ve got 85 different main topics, add some greater groupings to keep things tidy. Even inherently complicated sites (i. e. Amazon, WebMD) tend to offer some sort of teired navigation, instead of 75,000 option menus.

Don’t Get Too Dependent on Extensions
If you have 160 extensions for your CMS in play, you are probably trying to shoehorn the system into tasks it wasn’t meant to perform. You may be better served by a custom, or simply different, CMS, which meets the exact needs.

The risk of extensions is in the external developers. Some will change their product, or abandon it entirely. Do you want to have to choose between “fix critical security bug in new version” or “keep my extensions?” Or worse, if you get caught between two mutually incompatible extensions.

Keep Some Static Content
Half the time, doing everything in the CMS is actually harder. Some “moving parts” may not be ideal for a CMS based around fixed page content, for example. If you want a fancy contact menu, or forum, it ends up adding dozens of modules and coping with their limits, not just taking the right tool from outside the CMS.

However, the other argument is safety. If your entire site is on the CMS, if it breaks or is compromised, everything’s going to get ruined. A hybrid approach– keeping a CMS for news, and a static site for fixed content– is more robust.

Don’t Get Paranoid
A content-management system can be a wonderful boon both for ease of maintenance, and for producing quality pages which rank and navigate well. You just have to think as you use it.

]]> http://web-op.com/blog/seo/sensible-cms-decisions/feed/ 0 http://web-op.com/blog/usability/walling-off-the-world/ http://web-op.com/blog/usability/walling-off-the-world/#comments Fri, 27 Apr 2007 17:34:29 +0000 jack http://web-optimize.com/blog/?p=6 Many website owners are, to put it bluntly, login-happy. They love the concept of requiring user registration for everything from showing the price of merchandise to reading posts on customer forums.

From the perspective of the site owner, registration sounds like a hassle-free way to ensure that you get something out of your pageviews, either by tracking logged-in accesses or by simply collecting a profile for each user.

However, in doing so, you’re often cutting off your nose to spite your face. The web is no longer novel, and customers have had time to decide what they do and don’t like. Registration has clearly made its way to the second column.

Minimal Exposure

Many consumers tend to operate, especially online, with a mindset of minimal exposure. They’ve been conditioned from years of phishing scams, spammers, and shady businesses that you don’t hand out information to strangers that is not absolutely necessary.

Many registration systems tend to violate that principle. While a suitable minimum of information for a registered user would be a login name and password, frequently, users are expected to supply an email address (and, if they’re lucky, a choice as to wether or not they want a barrage of email), physical address, or demographic information. The more you have to give away in terms of privacy for the information on the site, the less valuable it seems.

In addition, there’s a subtle fear in creating an account that it’s just another login and password to be forgotten when you want to change a setting or make a purchase.

Allow Six to Eight Weeks for Delivery

The Internet’s most compelling feature is its spontainety. A user can find what he wants in Wikipedia faster than he can find the right volume of his old paper Britannica. Registration tends to shatter that premise. Even if the form is only a couple of fields, many registration systems now will require you to wait, frequently ten minutes or more, for an activation link email to prove you gave them a live address, before you can begin using the content. In the ten minutes it took for the message to arrive, I could well have found the information I wanted elsewhere, and odds are I won’t even bother activating the account.

You don’t have a monopoly

Even if you are the only site hosting a specific article, you are almost certainly not the only source for information on the topic. Some users will gladly try several no-registration-required sites to avoid having to use a registration one, especially if it involves the hassle of a new account setup.

Signal to Noise

Somehow, some registration sites do manage to bypass these problems. Success brings its own problems, especially for the marketing department. Given a 10,000 user registration database, instead of a tightly crafted 1,000 user list of marketing contacts, you’ll have to sort out which users are likely to convert to sales. You may end up with hundreds of users who signed up to see one item of interest, such as an article featured on Digg or Slashdot, and dozens of inactive or out-dated registrations. Unless you want to pay for thousands of emails that will be ignored or worse, you’re going to have to filter your registration pool significantly before you treat it as the quality marketing resource you imagined it to be.

Do you really think Googlebot has a login?

People who hide their best content in a registered-members-only area are committing a significant SEO sin. Most search spiders will be incapable of using the submission form to access the registered-user area, even assuming they were allowed access in the first place.

A dangerous new technique has appeared to counter this. Although all the information gets sent, a non-registered user will find his browsing experience hindered, or outright blocked, by client-side scripting. Of course, this will have no effect on the page at the primitive view of the search spider. While this initially seems to be a clever way to let Google in while keeping a nonregistered user out, it runs an extremely high risk of penalty from search engines. Google’s Webmaster Guidelines say

Make pages for users, not for search engines. Don’t deceive your users or present different content to search engines than you display to users, which is commonly referred to as “cloaking.”

The search engine is clearly getting different content than the user, once you take into account the blocked displays. It’s no different from packing a site with keywords that are coloured white-on-white-background or hidden in invisible boxes, and will likely earn you the exact same penalties. All it takes is someone to blow the whistle on you.

You Become Just A Small Obstacle

If you annoy users with registrations, you may soon find yourself the victim of their workarounds. Perhaps the best-known example of this is when many newspapers began to require registration to view recent articles. Some users created “pass-around” accounts… one guy registers, and then he posts the login for everyone to use. The marketing value of that registration is nil, unless you really believe that a single person read every article on your site 300 times in the last hour.

If you have a system which allows non-login access for people referred by affiliates, that will be exploited. Some poor slob will suddenly have 300,000 visits to the site through his affiliate link, and no clue why.

And, of course, there is very little stopping people from just mirroring your site’s valuable content and sharing that link. Again, one person registers, and the whole community gets access. While you may be able to pursue such people with copyright laws, you may wish to ask the recording industry how effective that’s been at keeping their content under their control. In addition, the ephemeral nature of many articles means the mirror may go up and down before you even know what’s going on.

Summary

Customers may want what you have to offer, but they resent jumping through hoops that are perceived as unnecessary or excessively nosy to get it.

Given that, when is it acceptable to ask for registration?

If your site displays a significant amount of customized information, and there’s no solid “fallback” option, then it makes sense to create an account. Just adding a “Hello, Joe Smith, you last visited on April 13″ is NOT enough to sell people on this. On the other hand, a local TV schedule that defaults to Ottawa, Ontario will look more than a little strange to a user in Phoenix, Arizona.

If your site provides per-user information, such as order tracking, prices that depend on the user, or shipping information on file, accounts can provide real benefits to their holders. Even in that situation, users will prefer to create their accounts with the minimal information to complete the order and at the latest possible time, going back to their preference for minimal exposure.

Sites with community features like comment and review posting can usually get away with requiring registration for those features, because it’s recognized as a way to keep spam manageable.

However, even if you have to register to add to the site, the use of registration to merely access the site should be minimized. You can’t wall your content off from the rest of the world, and at the same time expect buzz and search engines to hop the wall to make your site more valuable.

]]> http://web-op.com/blog/usability/walling-off-the-world/feed/ 0