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.

Choosing how you’ll accept payment early is vital, because each payment processing service has a slightly different interface, and it’s important to pick a cart which can talk to your service. Yes, MOST carts can be extended to handle MOST gateways, but it adds time and complexity.

Second, do you need any special shipping features? Many people don’t think about this until it’s too late. Those slick automatic calculators you see on many large e-commerce sites require a lot of cart support, and a lot of product setup. You have to tell the cart the correct weight and often dimensions of each product, and many shippers require an account setup to retrieve quotes. Other users only need a flat or tiered rate system (“Free shipping over $50″) Either way, knowing your intentions can help choose a good cart. There’s no point setting up detailed weights if you tell us “it’s a flat $10″ on the day before go-live. As a side issue, many of the carts offering sophisticated shipping options also require more configuration and maintenance, on tasks like setting up different shipping or tax zones, or adding offsets (to ensure that you don’t lose money on the cost to ship your packaging materials)

Third, know your marketing model. If you intend to do recurring billing, it immediately disqualifies a substantial set of both carts and payment processors. It’s not something you add on in the last minute. In addition, you may need to decide if you’re selling “Red Widget and Blue Widget” or “Widget: select colour – red or blue”. The latter requires the ability to store, and optionally inventory– by attributes– a feature some carts ignore. If you’re only selling one or two products, it may make sense to find a cart that can be “pared down”– removing distracting questions like “do you want to sign up for a newsletter” or even “add and remove products from an order prior to purchase” to keep the customer on a rigid path to the checkout page.

Why is it important to know ahead of time? If you’re building a cart, a substantial amount of the effort consists of adapting the proposed design to the existing moving parts the cart system provides. Having to tear it all up at 80 percent completion means you’re likely to slip deadlines or lose focus from the meat of the project.

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://blog.web-op.com/seo/making-carts-work/feed/ 0 http://blog.web-op.com/seo/sensible-cms-decisions/ http://blog.web-op.com/seo/sensible-cms-decisions/#comments Fri, 11 Sep 2009 20:51:24 +0000 Jack Zeal 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://blog.web-op.com/seo/sensible-cms-decisions/feed/ 0