Nashville-based Web Design and Development, SEO/SEM, Drupal/WordPress » BancCard http://searchviz.com SearchViz: Get found. SearchViz is an web design and development agency focused on search. Thu, 01 Dec 2011 15:16:45 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 SearchViz State of the Web 2010: Building and Managing Websites Is Difficult http://searchviz.com/blog/2010/02/18/searchviz-state-of-the-web-2010-building-and-managing-websites-is-difficult/ http://searchviz.com/blog/2010/02/18/searchviz-state-of-the-web-2010-building-and-managing-websites-is-difficult/#comments Thu, 18 Feb 2010 18:58:19 +0000 Freddie http://searchviz.com/?p=301 under construction

A few years ago, when debating pricing for a web project that involved a mix of design and development, I wound up on the losing end of the discussion when the account executive concluded, “It’s just a website.” I’ve also been in countless discussions with managers (none of whom have any true technical experience) where they set the expectations for a project (both theirs and mine) by asserting, “That should be easy.” And I’ve also been at the end of the assembly line of idea factories, where the non-technical people hold a brainstorming session and enthusiastically present me with all of them because they’re all good.

One thing that has long appealed to me about information technology and software development is that it is possible to do just about anything. It is possible to implement all those good ideas. The hitch to that as an applied technologist is that it makes it very easy to say “yes” to the question, “Can we do that?” But that doesn’t have any bearing on the answer to, “Should we do that?” or the similarly troublesome, “We need that by next week.”

I’d like to take a little bit of time to explore appropriate expectations for web and software development for non-practitioners who will be responsible for managing them. First and foremost, it’s okay and probably best to accept that web projects are difficult to build and difficult to manage.

I would imagine that 1% of web developers are the sort that have a rich grasp of everything that drives a website, from operating system to database to programming language to interface. Maybe 5% are the sort that can hack great code for years on end just for you. Chances are that you don’t have one working for you, and chances are that the agency building your website doesn’t either. This will complicate things slightly, but it won’t make them impossible.

Let’s remind ourselves of what a website is: it’s a collection of documents and elements (like Ajax modules and so forth) that, when requested by a browser (whether Web, mobile, or other), deliver markup (often some variant of HTML) that can be rendered in a predictable way.

Honestly, despite starting my life in the industry almost 15 years ago working for an internet service provider (ISP), I’ve never maintained a personal website. Actually, while in college, as a result of working as a consultant for the computer science lab, I wound up with some web space that I used for a simple personal site that vanished when I graduated. And that site was a collection of static HTML documents that I edited manually (probably with vi).

At it’s most basic, a web page looks like this:


<html>
  <head>
    <title>Hello, World!</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Easy, right?! It’s just a website!

(Here’s an aside. We maintain this blog in WordPress, which, for a robust blogging platform, still makes it surprisingly difficult to include examples of markup because of the aggressive desire for its editor to render everything. So I had to include a bunch of individual HTML entities to get the above example to show up correctly.)

Sure, it’s just a website. But it doesn’t have any images or links, it’s just one page, and I haven’t thought about how I’m going to manage it. I don’t know what the domain name is or where I’m going to host it. I don’t know whether it’s going to be a static HTML document or the output of a dynamic document (e.g., PHP). I haven’t thought about whether referencing the document reveals whether it is static or anything else about its implementation (e.g., does it live at /hello-world.html, /hello-world.php, or /hello-world with the help of server rules?). I don’t have an update schedule or anything else. And every website is different.

Let’s survey the common types of website that exist out there (and if you think I’m omitting anything or oversimplifying, please feel free to elaborate in the comments):

  • brochure: A mostly static site with relatively few (< 100) pages designed to present a person, place, thing, or idea with a focus on basic text and image content with occasional opportunities for rich media.
  • blog: A content-oriented site typically presented with posts in reverse chronological order and often providing visibility into most popular posts, tags/labels, and other ways of considering the content.
  • content: A rich content site like a news, government, or academic site that is constantly producing new content, often not in a simple, steady stream like a blog.
  • e-commerce: A site wherein any content is a pre-cursor to a financial transaction of some kind, whether a donation or a purchase.

Our site, for instance, is basically a brochure paired with a blog. I expect that someday there might be e-commerce considerations. Depending on what happens, there could be a content site in there somewhere.

All of the above types likely include some variety of form, which is the essence of interactivity built into the primitive Web. A contact form, an order form, a comment form, a rich text editor (which might need to be submitted to publish a news story, for instance). And forms invite the first of our series of complicated decisions: What happens to the output of the form?

Form submissions could be emailed. They could be emailed to a single email address or to multiple email addresses. They could be stored in a database. They could trigger a server-side action of some kind. They can do any and all of the above.

And Web interactivity involves all kinds of corner cases. Let’s say we’re considering a limited inventory retail operation. And let’s say it involves an online shopping cart. And let’s say I, a potential customer come along and, perhaps unknowingly, put the last item in my shopping cart. And then I remember that I have to run an errand before the place I need to get to closes for the day, and I leave. Maybe I even leave my browser window open. And then you come along. And you were looking for the item I just put in my shopping cart. Has the merchant considered how his or her site will behave in this scenario? After all, it’s just a website.

And all this is to say nothing of security considerations. After testing performance for a while, Google recently decided to make secure communication the default for Gmail. Not just for authenticating but for the entire session. For transmitting each message body. Google is judicious about its use of secure connections across its services. I’ve often wondered why secure connections aren’t the default for all web-based authentication from financial services to FTP.

Let’s get into the basics of what it takes to build a website:

Domain Name, Registrars, and DNS

The first thing you really need for a website is your domain name. Until Yahoo! shut down GeoCities, you could go there to get a free site. You can try Google Sites, but it’s not quite the same. And if you’re just doing a blog and you don’t care about owning this basic asset, you can do something like Blogger or WordPress, which will give you something like justawebsite.blogspot.com or justawebsite.wordpress.com. How do you do this? Well, geez. We’re just trying to pick a domain name, and we’ve opened a can of worms. Because a domain name gets us tied up in the Domain Name System (DNS). So first we need a registrar, and then we need to make sure that we can configure DNS appropriately to work with our web hosting environment (see next item).

Web Hosting

So you’ve registered your domain name. Now you need to make it so that when someone types in justawebsite.com and it successfully resolves to an IP address that the server at that IP address is listening, probably on port 80, and is ready to serve pages. I’ve mentioned previously that we host with A2 Hosting.

Shared Web Hosting

Most websites just need shared web hosting, which basically means a bunch of other websites about the same size (disk space, traffic) as yours are using shared resources. Which is fine.

I used to host some sites with TextDrive, which became Joyent, which seems no longer to offer easily understood web hosting services (despite TextDrive at one time having been a semi-official Ruby on Rails hosting service).

The two other major web hosts that I’ve seriously considered using in the past are DreamHost and pair Networks. I’ve also recently evaluated Media Temple for WordPress hosting. Yoast seems to like WestHost for WordPress hosting, but that could be helped by their paying him to like it. ;)

Managed Hosting

If, however, you’re doing something where you expect to be doing a lot of development or managing a number of services that require a dedicated server, you probably want a managed hosting solution like Rackspace or Tilted Planet. In these cases, you get access to a server or servers on a network that should be reliably managed, and you can get various packages and levels of management in the event that you don’t want to hire a system administrator (and, unless you’re doing something very innovative, why should you?).

Based on the coming of the cloud and the maturity of managed hosting and dedicated (and virtual servers), I would never encourage any but the most ambitious of enterprises to buy a piece of enterprise hardware. Someone else has already hired several sysadmins better than yours and is making the process of administration more efficient than you ever could.

Content Management Systems

Content management systems (and frameworks) are web software packages that typically give you a rich text editor, some basic formatting rules and templates, and let you run wild adding pages, posts, widgets, and the like.

In recent years, I’ve developed the most familiarity with Drupal and WordPress. Both have some maturity as platforms and both have vibrant developer communities that make support possible if not always reliable (especially as the ecosystem frays around the edges, sometimes even with popular modules and plug-ins). WordPress came to prominence as a blogging platform, but it’s now mature enough to be able to support brochure + blog sites if not outright content sites, although I still think Drupal is a better fit for full-featured content sites.

We’re about to begin work with a bastardized version of Joomla, and a professional acquaintance recently suggested that I take a look at MODx. I’ve spent a long time admiring TextPattern, although I’ve never used it. And I used to want to try Bricolage because it was built by default on PostgreSQL. For some reason, a number of local designers seem to enjoy paying for ExpressionEngine.

We also have done some projects that leverage Sitemason, a locally developed web-based content management system and hosting platform. While still a little more dotcom than Web 2.0 just because of the history of the company (where I worked as we launched into the dotcom implosion) and because of the dynamic nature of open systems (or closed systems that happen to be named Google), Sitemason continues to innovate quietly. In recent years, besides building incredibly innovative JavaScript libraries and a brilliant database abstraction, they also recently moved their entire hosting operation into the cloud, leveraging Amazon’s EC2.

Competing locally with Sitemason is Bondware. I can’t give Bondware awards for administrative interface, but I will say that they’re one of few products I’ve used where the Web and email platforms fit together nicely.

Which brings up a point I haven’t raised yet: the successful integration of a website among all the evolving marketing tools from email to social. There don’t seem to be too many people creating killer apps allowing small and medium-sized businesses to jump in and be truly in control of their inbound marketing. But that’s a topic for another time.

Blogging Platforms

What if you just want to blog? Well, we’ve already mentioned Blogger and WordPress. You could get a little funky and try something like Chyrp, which is pretty but carries the caveat of being a sole developer project.

E-Commerce

The first thing you’ll need if you’re going to build an e-commerce site is a merchant account. Then you’ll need to connect it to a payment gateway. Within the last decade, PayPal purchased Payflow, and CyberSource purchased Authorize.Net. I’m honestly not sure what other major players are even in this space. BancCard, a Nashville-based company, plays nicely with both Authorize.Net and PayPal.

I’ve used both osCommerce and Zen Cart, and I came away unimpressed. I’ve also done custom PayPal integrations, which were fine except that they were custom.

It’s recently been suggested to me that I give FoxyCart some consideration, and it looks like a worthy contender for any upcoming from-scratch e-commerce implementations. Also, somehow it had completely escaped my attention that they’re a Nashville-based company.

Custom Development

Here’s my position on custom development. It’s not all bad, but it should generally be the province of someone who is actually developing something innovative. If what you want is a 3-page instead of a 2-page pipeline for your online marketplace, you should be leveraging an existing e-commerce solution. If, however, you’ve got something you think is worthy of a patent, like single-click shopping, then develop your own.

We try not to do a lot of custom development. We try to strengthen standards for existing content management solutions by, first, relying on them and then, if necessary, extending them. We generally aren’t in the business of projects; we’re in the business of process.

But if you’re going to do it, even rolling your own involves some amount of choice. I’m only going to cover free and open source platforms, but I know there are plenty of sites out there implemented in any of ColdFusion, ASP, etc. Otherwise, popular choices include PHP, Perl, Ruby, and Python. Of course, Google recently unveiled their own programming language, Go, so who knows.

With every language, it seems, comes a framework—Ruby on Rails or Symfony—which allegedly make development easier.

Maintenance

Wow. You finally did it. You launched justawebsite.com! Now what?

Well, if you’re not using fully managed hosting and instead you’re managing your own LAMP stack, you’ll need to keep up with Linux kernel patches, GNU/Linux distribution patches, Apache (or equivalent patches), database patches, and programming language/framework patches. If you’re leveraging a content management system, you’ll need to keep up with patches for the core system as well as for plug-ins/modules.

Generally, you can track security patches, but if you let your system suffer too much bit rot, APIs might change out from under you, so that a must-have feature becomes beyond reach.

And, of course, you’ll have dev, staging, and live versions of your site for testing with version control as necessary for any custom development.

Maybe we should just stick with hello-world.html…

Other Considerations

Recently, SparkFun had their Free Day on the same day that Google launched the Nexus One. Each site suffered. Chris Anderson wryly tweeted, “Google’s servers can’t keep up with Nexus demand; Free Day brings down Sparkfun. It’s 2010–why do we still have these scaling problems?” It’s a good question. To me, the cloud reached adolescence when Amazon EC2 came out of beta. It will reach adulthood when the elasticity is dynamic and demand-driven rather than reactionary on the part of admins who frantically allocate new instances as traffic swamps a site.

The End

My point in writing all this is to give some guidance to non-technical project managers and executives to remind them that asking for the moon is likely to get you the moon from your web development team, but it is likely to be late and over budget. And I also included a number of the individual technologies I’ve had exposure to, either directly or through my network of IT professionals in the hopes that webdevs everywhere will help me refine this post, which might take on a constantly evolving life outside the scope of the blog depending on response.

When you launch a website, you’re not completing a project; you’re kicking off a process that will live for the life of the site. It involves ensuring that the site itself doesn’t rely on moving parts that can’t be maintained. It involves ensuring that if the site is bound by a temporal dimension that it provides a user experience consistent with the passage of time. It involves ensuring that both the user and search experiences are continuously refreshed in order to be optimized.

Over time, my hope is that SearchViz actually improves the Web slightly. Both by helping create standards-compliant websites with an emphasis on both user and search experience and by working to ease the process of building and managing websites, whether by contributing to free and open source software projects like WordPress and Drupal or by building our own solutions for management of the resources required to operate a site. If you have any suggestions, or you’d like to participate as a customer, let us know.

Obviously, I’ve missed a world of options, but that’s what the comments section is for. Let me know what I’ve overlooked.

]]> http://searchviz.com/blog/2010/02/18/searchviz-state-of-the-web-2010-building-and-managing-websites-is-difficult/feed/ 4