The Site (Road) Not Taken

For many years I've strongly advocated for having as much control over your website as possible, as evidenced by
several posts in this blog. This perception has grown for the "committed technical novice" with many of the DIY products that have come along since I wrote "What A Website Can Do" in 2010.

But there are still limitations with website builders, not the least of which is the charge for the most basic
requirement, using your own domain; typically about as much as it costs for a hosting package complete with gigs of disk space.

However, let me say at the outset that I'm not as partisan against website builders as I was. They serve a purpose
of getting a presence on the net quickly, and some have a nice selection of templates.

But for a truly scalable and flexible long term solution, to name just a few advantages, there are better platforms.

As usual, knowledge pays.

I was recently contacted by a past client seeking help with their website, currently written in php. My first
contract with them, I implemented a WordPress site, upgrading from a website builder that allowed just 5 pages, addressing one problem of crowded content. A support plan was not negotiated. The WordPress site stayed up for a
while, then I noticed one day that it had switched to a website builder platform.

I don't know why it was decided to go back to a closed platform; I can only assume the WordPress admin dashboard
might have been intimidating (a situation that appears to be common among those who have yet to be convinced otherwise), or were overwhelmed by the nearly daily plugin update emailed notifications (updates which can be managed by -- say it with me -- a plugin).

Some years passed, during which I de-emphasized work for clients who decided to abandon provided solutions, feeling
it might create a negative perception.

Such was the case of the client I mentioned who now needed help updating content. As I said, when I'd last visited
their site it was using a website builder; now it was written in php (a scripting language that can generate html).
(When I learned this my first thought was '...but - but so is WordPress...?')

I agreed to provide an analysis which revealed a few things that went beyond their scope.

For example, I found pages where a tagline was rife with misspellings. I found text obscured by an image.

The template I use for detailing specs and tasks has space to show business rationale/advantages. I think it's important to be as explicit as possible in the hope that what is quoted is agreed to be fair and accurate. At least it helps.

That being said, ultimately the client determines what services they'll receive and the provider must decide if they are the right one to do so. It's not as if disclaimers can appear in mid-air like a holograph when work they may be credited with is viewed by the general public. Cost can be a primary driver, and it is up to all parties concerned what that cost, immediate and future, will be.

1 Comment

  1. Brandon GuillermoDecember 1, 2018

    Update: The client informed me that the WordPress site I initially implemented “didn’t have everything ” and they thought the most recent site was implemented in WordPress. I have an opportunity to find out more about what was meant by “didn’t have everything”, but the latter statement:”thought [the site] was implemented in WordPress” really caught my attention. I suspect that “didn’t have everything” was a misperception of the capabilities of WordPress. I had used a default theme for the year the site went live, to aid in debugging. I believe there’s an awareness of the flexibility of WordPress now. The developer that was hired after that implementation obviously did not accurately convey what they were delivering. All communications must be explicit so that all agree to terms. And I will try to emphasize the extensible nature of WordPress; what seems limiting is far from it.

Comments are closed.

Scroll to top