How to Launch a Successful Website

A client recently asked us for our opinion on how they could better manage the task of bidding and building a new website. Since it’s as much about the process as the product, we were happy to respond from our perspective of a web design and development parter. Here are the do’s and don’ts of launching a successful website.

What you ask for in the RFP is never exactly what we end up building. There are simply too many uncertainties at that stage. Once you’ve chosen a partner, start with an expectation that you will need a discovery phase to more clearly define your needs.

Be agnostic about the technology used. We get a fair amount of “must be in .NET” in RFPs when that’s neither the cheapest nor best development platform… just what the IT guys had recommended. If you have legacy applications, most CMSs can integrate with them. Allow the problem to define the solution.

Understand that good designers can be poor web developers, and vice versa. We run across way too many half-completed jobs where a previous partner failed in one aspect or the other and there’s no budget left to finish properly. It’s critical for you to assess your partner from multiple angles… especially if you need a robust CMS or custom application development.

Find a partner with a host of skills that complement your internal capabilities. The only way to ensure your final online property is an integrated and genuine reflection of the brand is to build the right team. Assess a potential vendor not just upon their ability to provide a single service, but on how they will work with you to cover all the bases.

Treat the estimate… as an estimate. Every RFP response begins with assumptions that can turn into surprises, and managing scope as the job unfolds is arguably the most difficult part of the process. Pad your budget expectations so you have some negotiation room to add features or functionality you (or your vendor) might not have anticipated going into it.

The launch date is important, but getting what you need is more important. Try not to commit to a go-live date until after the discovery phase is complete. Far too often we respond to web design RPFs with built-in, arbitrary deadlines that aren’t based in reality. The final scope of the site should be what ultimately drives the schedule.

Be an active partner in the IA, UX and wireframing stage. It’s critical to get those right and all too often our client’s eyes glaze over when we do the discovery and scope exercise. You know your key audience(s) best, and you play a critical role in helping us lay the foundation and anticipate their needs.

Provide content and other assets early in the process. The more we have to start with, the faster the final website will come together. It’s far more efficient to design and build around actual messaging. Plus, generating approved content is frequently one of the biggest delays to a site launch.

Ensure your site integrates with other marketing efforts. Could you use custom landing pages? The ability to send HTML emails for retention or lead generation? How important are organic search rankings (SEO) to your business? How does your site “play” with your social media efforts? All too frequently these broader online marketing concerns get overlooked. Your customer’s level of engagement depends on how well they all work in tandem.

Shepherd it through. The most efficient (and least painful) site launches happen when there are only a small number of decision-makers involved. We’ve done design by committee, and it rarely ends well. Be an advocate to ensure that internal needs are satisfied without allowing any one person to derail the process.

Plan for growth. It’s tempting to think of the launch as a final product, but your website should always be evolving. Have a content strategy in place so entropy doesn’t take over, and update it regularly to keep it fresh. Actively monitor your site analytics and make incremental changes to increase conversion rate goals and retain users longer. Consider who and how your site will be maintained as part of your yearly marketing budget.

Ultimately, vet the right partner and then trust their instincts. It’s all the little decisions and forethought prior to the launch date that determine whether your site is a true success… or will need to be revamped again in a year. Cost is only one aspect of getting the best value in web design.

Coding for Legacy Browsers, and the Internet Explorer Problem

As a coder, I hate Internet Explorer. Or at least I used to hate it: IE10 and IE11 are actually pretty good browsers. But we’ll get to that in a minute.

We continue to have some clients request that their sites support newer HTML/CSS features in IE9… and even IE8 in rare cases. These browsers are now 3 and 5 years old, respectively. Nearly ancient in Internet years! But even when released they lagged behind their competition. To understand why coding for legacy browsers–and especially IE–takes more resources, you need to appreciate how HTML works (or doesn’t).

The inner workings of web pages are primarily established by an organization called the World Wide Web Consortium, or W3C. Every few years they publish official standards which extend the functionality of HTML/CSS. To support the newest features, you also need a relatively modern browser that understands them. Typically websites will be coded to degrade gracefully for legacy browsers. In other words, content will still display but might be formatted differently and will lack some functionality. With an additional layer of Javascript we can manually replicate newer features in an older browser… but it requires more work, and more testing, for each legacy browser added to the support list. It also usually means some sacrifices need to be made for all users in order to make the experience consistent for the lowest common denominator. The ROI to do this is typically not justified unless you process a large amount of transactions online and can’t afford to ignore any browser fringe cases, no matter how small.

Of all the legacy browsers the most problematic is IE, which for years decided it would set its own standards apart from the W3C. Microsoft pushed their own proprietary features, which meant pages specifically created for IE wouldn’t work properly in any other browser. And they consistently lagged behind supporting the most recent HTML base spec, so IE was buggy and always required workarounds when viewing code that worked great everywhere else. While IE had a vast majority of the market share, Microsoft could afford to be the exception and force web designers to bend to its will. As recently as 2009 IE still had over a 50% adoption rate–even after years of better, faster, and more secure browsers had chipped away at it. Then along came Chrome, and later the rise of the mobile OS, and that was the beginning of the end. As of today, IE has around a 20% adoption rate and has been dropping precipitously.

And yet, even though IE8/9 combined comprise only around 5% of the 2014 market, we continue to see a unusually high number of institutional clients who are using these browsers. Why? One word: Vista. Microsoft’s Vista OS was so universally hated that users stayed on XP and refused to upgrade. For years, new PCs shipped with Vista installed would often be “downgraded” to XP. Along came Windows 7, and now 8, and many businesses continued stick with XP. As of 2014, this OS has a disproportionately large user base even though it’s now over a decade old. Why? Primarily because Microsoft has continued to support it’s flagship Office Suite for legacy systems. But, they abandoned any updates to IE long ago.  So many large organizations–whose IT departments don’t want to deal with the headache of updating or replacing a hundred machines–have locked their users into using an outdated version of IE on XP.

We are happy to report that Microsoft has finally conceded the battle, and both IE10/11 show great support of W3C standards and render modern pages reliably. And also that in mid-2014, they will stop releasing updates of Office for the XP operating system. This forced obsolescence means that the unnaturally high adoption rate of XP… and legacy IE browsers… will finally fade into the mists of Internet past. In the meantime, if you are still using XP, encourage your IT department to install Chrome or Firefox as an alternative. Both will greatly improve your Internet experience and are safer from a security standpoint.

We would love nothing more than to look forward than backward when designing and coding new websites.


The CMS and the Future of Content Publishing

Not too long ago, websites were a bunch of manually integrated pages of code. The IT guy made site updates because no one else knew how. Lacking a unifying structure, legacy web properties often suffered from entropy and devolved rather than evolved. Then along came the CMS to manage content and navigation, which also allowed anyone to publish a web page without being a coder. It ensured brand consistency and easy site maintenance. Initially too expensive for any but the largest companies, with the advent of open-source solutions this capability is now nearly universal.

While it’s substantially cheaper now, the decision to have a CMS manage your content still comes at a cost. The up-front fee of installing and configuring it is the obvious one. But perhaps more importantly, a CMS can be as limiting to content management as it is liberating. Because it is based on inflexible publishing rules, authors are forced to “draw within the lines” when adding new content. We usually do a great job anticipating our client’s content needs and designing a solution that meets them. But inevitably, they’ll create an exception… embedding a video on a page that wasn’t designed for it… posting a custom landing page… adding a unique call-to-action…

So we’ve started thinking about CMS development a little differently, beginning with the Spiezle redesign we just launched. Currently, nearly all CMSes are developed based on a fixed set of paged design templates. Each template is created to fit a particular type of content: a blog, or a contact page, or a home page. Choose a template and fill in the blanks. But… what if CMSes weren’t template driven, and instead allowed an author to select from a number of “content type” blocks that could be added, stacked, and re-arranged on a per-page basis? Instead of just a handful of templates, this would allow for a range of customizable page layout permutations. SquareSpace has implemented a system that is similar to this in concept, but because it’s a hosted service it’s not a good fit for large, complex websites with deeper functionality.

Spiezle was a proof-of-concept for us. Their home and project pages allow for a degree of flexibility, so the client can change the layout to prioritize content rather than tailoring the content to fit the template. We created a custom module in Expression Engine that allows for this functionality inside of an existing open-source CMS. It was so successful that we’ll be developing this concept even further future web sites. We can’t wait for the day that “templates” largely disappear and sites are no longer like a big Mad Lib… and neither can many of our clients.