greg smart

One of the more frustrating development topics I regularly encounter is ecommerce, specifically when and for whom it’s an appropriate venture.

Let me start by saying that given the right set of factors an ecommerce solution can undeniably reap benefits for a business. Over the past few years I have seen some online ecommerce businesses thrive and have seen quite a number fail. There are definitely commonalities for each scenario.

The Good

Most successful ecommerce ventures, that we have dealt with at Pleth, LLC, are businesses that either manufacture their own products, have their products manufactured specifically for them, or are able to rely on a keystone markup for the bulk of their product lines. Essentially what these businesses are able to create is a margin great enough to overcome the costs of delivering their products. For an ecommerce business these costs include:

• the actual cost of site hosting and maintenance
• shipping charges (on both sides of the transaction)
• marketing costs (such as traditional media, pay per clicks, paid inclusions, etc…)
• credit card processing fees (including chargebacks and fraud).

Another positive ingredient in this ecommerce stew is a site that exists as a compliment to an existing business. I see this as an especially important point since this allows a client to devote the extra time and resources that are necessary for a site to mature alongside the internal logistical components required to support a healthy ecommerce site. In this type of situation the site is not asked to generate an unrealistic revenue stream immediately in an effort to support the client’s external financial needs.

The Bad

When I begin a conversation with a perspecitve ecommerce client I often find myself monitoring the dialogue for these ecommerce red flags:

• the client is in a reseller situation (typically 20-30% margin before any product is sold, shipped, or marketed)
• the client is paying full shipping on individual products on each end of the transaction
• an integrated credit card processor is not desired (usually to control costs)
• outside marketing efforts are deemed unnecessary or too costly

Although none of these characteristics will leave me fleeing a meeting, none of these exist in a vacuum either. They usually come bundled together and tend to leave us a little hesitant about initiating a project when these flags are thrown.

The Ugly

As I mentioned above, we often find ourselves in situations where our comfort levels begin to go south. Then there are projects that cause us to start looking for the nearest exit. These tend to posess the following:

• expectations for revenue generation are unrealistic, especially in the short-term
• unrealistic about the amount of client-side work and logistics necessary to support an ecommerce project
• urgency at any project phase (this is a big one)
• multiple failed project attempts (often with subsequent data migration from those failed attempts)

Anyone who comes to us expecting to get rich quick with little to no effort is in for the long hard fall back to reality. It simply doesn’t happen.

Bookmarks:

I have been reading a couple of blog posts this morning which reflect two very polar stances on the use of a CSS reset document. A CSS reset document is utilized to strip away all margins and padding, incluging the default page form elements. Effectively leaving you with a blank, style sheet, slate.  Jonathon Snook’s article, “No CSS Reset“, explores why he believes the use of a CSS reset document is the antithesis of many of the concepts held near and dear by developers within the “Standards Community”. I have to say that I don’t completely disagree with him, particularly in the “Working with Nothing” argument he poses.

One of the principles I took away from the Web Standards community was the concept that pixel perfect precision across the various rendering engines was impractical and a remnant of the table-based layouts of yesteryear. With CSS and progressive enhancement, it was okay that things might look a little different from one browser to the next because of variations in what they supported.

Eric Meyer’s well written article, “Crafting Ourselves“, doesn’t directly advocate the practice, but rather defends it as a legitimate tool of the web design craft.

I’m not saying that craftsmen/craftswomen are those people who reject the use of common tools, of course. I’m saying that they use the tools that fit them best and modify (or create) tools to best fit them, applying their skills and knowledge of their craft to make those decisions. It’s much the same in the world of programming. You can’t identify a code craftsman by whether or not they use this framework or that language. You can identify them by how they decide which framework or language to use, or not use, in a given situation.

As I review both of these posts I find myself intrigued by the use of a CSS reset document. This is actually the first occasion that I have heard of it. I believe that the crux of Snook’s argument lies in the fact that the “Standards Community” had at one time assumed the position that, “the concept that pixel perfect precision across the various rendering engines was impractical and a remnant of the table-based layouts of yesteryear”. While I have, in the past, subscribed to this line of thought it was derived more from practicality than preference. Simply stated, it was more trouble than it was worth to try and control inconsistent cross-browser rendering too tightly.

Will I attempt to utilize a CSS reset document in the future? Absolutely. As I go through the site design process I frequently have the conversation with my clients about browser rendering inconsistencies and why they may see rendering disparities on their end. Eventually they acquiesce to this reality (what choice do they really have?). As I move forward I am hopeful that I may recapture this modicum of design control I once relinquished for the cause of standards compliance.

Eric Meyer’s Reset CSS

/* v1.0 | 20080212 */

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-size: 100%;
vertical-align: baseline;
background: transparent;
}
body {
line-height: 1;
}
ol, ul {
list-style: none;
}
blockquote, q {
quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: ”;
content: none;
}

/* remember to define focus styles! */
:focus {
outline: 0;
}

/* remember to highlight inserts somehow! */
ins {
text-decoration: none;
}
del {
text-decoration: line-through;
}

/* tables still need ‘cellspacing=”0″‘ in the markup */
table {
border-collapse: collapse;
border-spacing: 0;
}

Bookmarks:

Since moving from an Ensim control panel to Plesk I have had trouble many times with previewing works-in-progress on sites that do not yet have the DNS pointed to them. This was not an issue in Ensim as you could use the IP address in the URL to create a direct pathway to the site as it is under construction. Plesk, unfortunately will not allow you to do this and will only allow a site preview from within the control panel.

It finally dawned on me the other day that I could use the Plesk domain alias feature to solve this problem.

Set up the domain in Plesk, as you normally would. Next go to Domains > Domain Alias > Add domain alias. From this point add a subdomain against any domain you like, like project.yoursite.com.

Next go to your registrar/DNS manager and point the appropriate subdomain to the IPA of the host server.

That’s it, nothing else to it.

Bookmarks: