Five Web Design Concepts Ecommerce Merchants Need to Know
Editor’s Note: Ecommerce merchants operate businesses using complex technologies. We launched our “Need to Know” series to help merchants obtain a basic understanding of these technologies, recognizing that most merchants are not web developers or programmers. In this installment, contributing editor Armando Roggio explains five helpful web design concepts.
An ecommerce venture, to be successful, needs marketing, design, development, accounting, and operational expertise.
Ecommerce merchants can outsource most of these services. But just because there are providers available, doesn’t mean that a merchant shouldn’t have some basic understanding of the concepts. This includes web development issues.
So I have put together a list of five important web design concepts that non-technical ecommerce merchants should understand. These concepts can have either a positive or negative effect on site performance and, therefore, site success.
Understand the Limits of HTML Tables
Tabular data is helpful, especially for comparing products or service plans on an ecommerce site. You can line up product attributes and give shoppers just the information required to make a good buying decision.
Positive examples of HTML tables on ecommerce sites abound. You could check out a laptop comparison table at Newegg or the recent virus threat table at MacAfee (remember software sales are ecommerce, too) as examples. Both of these tables improve the user experience and convey information quickly.
But the use of tables can be overdone, and ecommerce merchants should understand this. Some web designers and developers cheat and use HTML tables for page layout. For example, placing a headline in one table cell, an image in another table cell, and some copy in yet another. While this might not seem like a big deal, it can cause several problems.
- Using HTML tables for layout confuses some search engine bots and hurts search engine optimization (SEO). Tables as layout break up natural content flow and reposition unrelated material together, making it harder for some spiders to properly index.
- There are accessibility concerns too. Because layout tables can, and often do, separate related items. For example a table of products might have product images in one row, headlines in another, and links in a third, rather than associating image with headline with link. The table associates image with image with image.
- Bloated code. Generally speaking using HTML tables for layout requires more markup, which can make your site’s pages slower to load and require you to invest more in web hosting depending on the size of your site.
- Layout tables may make your site harder to upgrade and harder to transition to other platforms like mobile devices.
As a rule, ensure that the web designer you hire only uses HTML tables for tabular data. You’ll have to decide for yourself, if you think product category pages, for example the “Guys” page at Seventh Ink, is tabular data or not; but FYI, Seventh Ink is not using tables for layout.
Document Type Declaration (Delimiter, Definition) Directs Browsers
Another important web design concept is document type declaration (DTD). DTD, which is also referred to as document type delimiter or document type definition, serves to tell web browsers what sort of document they are dealing with and thus make it easier for those web browsers to properly render the associated web page.
Put another way, a DTD tells the browser what set of rules—XML, XHTML 1.0, HTML 5—the page follows.
If the wrong DTD is chosen, or if your web designer ignores the very rules she decided to use, a web browser might not be sure how to act, and could render your page improperly, making your site look unprofessional or, worse, messing up some of the site function.
The key to this concept is making sure that your web designer validates the code. A validator, like the World Wide Web Consortium (W3C) Markup Validation Service can tell you if your site follows its own, declared rulebook. If it validates, great. If not, have your web designer fix it, or at least explain why not.
Web Standards and Browser Adoption Are Essential
The web has standards. It is not the wild west. The Internet would not be capable of ecommerce except for web standardization. In fact, the aforementioned DTDs are standards.
Essentially, web standards are an agreed-to set of behaviors so that I can write some bit of standard compliant code and expect that code to behave in a generally similar way regardless of whether I am using a PC or an Apple Mac; Internet Explorer or Firefox; or a laptop or mobile phone.
Without web standards, I would have to create a completely different web page for each browser and each platform. (Web designers actually used to do this in the early 1990s.)
Generally speaking, web standards work, but there are still some problems. For example, Microsoft’s Internet Explorer (IE) web browser is the least compliant browser that I am aware of. It doesn’t, for example, support event capture, rounded corners in CSS, standard margin and padding methods, and, until version 7, portable network graphic (PNG) alpha transparency. This means that your web designer or developer will have to do extra work in order to ensure that your site renders properly in IE.
I should note that no web browser is fully compliant, but usually the more compliant a browser is, the more capable it is. Check out this demonstration of a forthcoming scalable vector graphic (SVG) API. At the time of writing, the demonstration, which I realize is not exactly a practical application, only worked in relatively new versions of Google Chrome or Apple Safari. Once more browsers adopt this standard, developers will be able to introduce a lot of extra functionality into ecommerce websites.
As a merchant, the thing to remember is that you should check your site in at least three different browsers—IE, Firefox, and Chrome—to make sure that it is being rendered consistently.
Separate Content from Presentation
From a development standpoint, ecommerce web pages have three basic aspects: content, presentation, and rules.
Content describes the good stuff you put on your website, like product descriptions, how-to articles to help customers, or even product reviews.
Rules—or the model as it is often called—represent the logic behind the site; for example, calculating real time shipping rates, adding tax, or calculating discounts.
In good web design and development, content, presentation, and rules are separated, so that the site is easier to maintain. For example, it is clearly better to have all of my cascading stylesheets (CSS) in one or two external files rather than putting style (presentation) directly on each page.
If three months from now, I want to make a change to how the page looks, I can make that change in one external CSS file and I am done. If I had not separated my style, I would have to manually change every single page on the site.
Separating content and presentation in this fashion seems pretty intuitive, but there are still a lot of old-school web designers that don’t do it.
You want to verify that your site has stylesheet links and script references in the header. These will look something like these examples from Barnes & Noble:
<link href="http://images.barnesandnoble.com/presources/community/css/community.css" rel="stylesheet">
By contrast, you never want to see code that looks like this example, which I took from a real ecommerce site:
Content Management Systems Are Necessary
A content management system (CMS) is a kind of collaboration, version control, and storage software that is often implemented as a web application. Essentially, a CMS lets your business store content—product specifications, for example—in a database and then access that database in order to create dynamic web pages as they are needed.
Imagine that you have ten products. It would not be that hard to create ten HTML pages—one for each product. And if you needed to change something on one of those pages, it might not be too hard to open up that page and make the change. Of course, if the change was to site-wide navigation, you’d need to make ten changes, which could be a burden.
Now imagine that you have 100 products. How much harder would it be to manage 100 individual web pages.
What if you have 1,000 products? You get the idea.
A CMS solves this problem by storing content in a database and using page templates. When it needs to render a page for a shopper, it grabs the proper product specification from the database and places that specification into a template. The combine content and template are rendered and you have a dynamically created web page.
If you need to change product information, you only need to make a single change to the database, and if you need to change a template, you probably only have to make one change to a template file, regardless of how many total products you have.
For your ecommerce store, you will want to use a CMS. Some shopping carts, by the way, are also ecommerce CMSs. For example, Elastic Path, Magento, Volusion, Interspire, LemonStand, Shopify, and many others are very capable ecommerce CMSs. While other shopping carts, like Instinct’s WP e-Commerce, plug into other web CMSs.
Just find the solution that fits your business case, and note that there is virtually no business case for not using a CMS.
There are many good web design professionals. By understanding these five basic design concepts, ecommerce merchants can communicate better with these professionals, and understand the design issues involved with their own ecommerce sites.