Don’t forget about the small things
During the build of a website, developers tend to concentrate on the large, complicated, or most challenging aspects first. This may be the e-commerce portion, specific business rules that require extensive integration, or a tricky new third party API you need to implement.
Once the dust has settled and you have already pat your own back on how your totally awesome super-duper search system can catalogue star systems, tired eyes may overlook the simpler things. Here are some obvious “catch it in QA” pieces of functionality that become white-noise during the focus on the bigger picture.
Forgotten Password and Change Password
It's ironic that the one of the first things forgotten during build is the Forgotten Password form. These insignificant little forms are Security 101 and no site should launch without them. A logged in user must be able to change their password whenever they want, and there should be minimum quality requirements for said password (i.e. length, mixed case letters, numbers and symbols). A user who can’t remember their password should be able to have a new one either generated (not ideal) or be sent a unique link via email that allows them to reset it.
Log Out
Following on from the above forms is the site Log Out. It seems obvious when written in a list such as this, but what goes up must come down. What logs in must log out. Make sure that closing their browser is not the only way a user can terminate their session.
Social Media logins
Oh those horrible little 32x32 icons that sneak onto the design. Yes, everyone has Facebook and many have Google+ and Twitter, so it stands to reason that a user can (partially) bypass your own authentication layers. Every time I need to do this there’s been enough time between drinks that new versions of the relevant APIs are available and I need to relearn the basics. If you are using MVC 5 (if not, why not?) things are remarkably simpler with the new OWIN providers. Find out exactly what information you are expecting to gather from your social providers and how they integrate with your existing authentication, and take care of this early – I guarantee the Facebook icon will be the first button the client will click.
Google Analytics
Clients very quickly (and rightly) want to know how well their investment is performing, and Google Analytics is a simple way of justifying the expense of a website to Phil from Marketing. If your site is CMS manageable, I’ve found it excellent practice to allow the admin to copy and paste script blocks into predefined areas before the </head> and before the </body>. This way you don’t need to worry about chasing for accounts, and also other tracking scripts can be installed without developer involvement.
SEO
Even if nothing is specifically mentioned in your requirements documentation, if your site is CMS manageable, allow the basic SEO (i.e. Search Engine Optimisation) fields to be editable; browser title, meta description/keyword and human friendly URLs. An SEO expert may run through the site one day and having these fields manageable without developer input will make your life simpler later.
Advanced Search
I won’t lie; I’ve seen the scary “Advanced Search” link show up in a design and quietly made it go away. For a less Grumpy Cat response, you’ve got to build the thing, and it’s better to consider how you will build it up-front. “Search” means so much more than allowing a user to find references to “my cat’s breath smells like cat food” in mountains of site content. The search will inevitably power your product listings, your events calendars and all manner of underlying technology. With so many options available (SQL, NoSQL, Lucene) you need to consider the requirements of the search, the complexity of the on-page filters, and how user data can effect results. Do this early, do it well and get it out of the way.
Advertising
So the design has mock-up banner advertisements plastered all over it, but has anyone decided how they will be managed? DoubleClick for Publishers is a good solution and gives all the power to the customer, but it requires setup, thorough understanding of the technology and integration – it’s not just a matter of slamming script blocks into the markup. You will probably need some ability to manage how and where the scripts are inserted. If you are lucky these locations will be fixed, but don’t count on it.
Bug reporting
If the site has issues you need to be able to determine precisely where they occurred. Live bug tracking is essential. For .NET sites I can’t recommend Elmah highly enough. By default it will track all errors on the site and present you with a list and detailed view of the exception (via webpage, RSS, emails, however you like). You can also manually throw errors in the code directly to Elmah, which all developers really need to get in the habit of doing in their exception handling. Which brings me to the next item…
Friendly 404 and 500 pages
If the end user sees a big red and yellow stack screen, you have failed. The end user instantly loses faith in the website. If there isn’t one designed, ask for it to be designed.
Hosting, SSL, Payment gateway accounts
I’ve touched on these aspects before but they are worth restating. Anything that requires time from somebody else to organise cannot be left to the 11th hour. Even if it is not specifically your area to worry about these things, if you don’t see any progress on them it is worth bringing them up. Make sure you have the live credentials for all APIs, especially payment gateways. Make sure that the SSL certificate is bought and installed on the server. And as for the server itself, this is most important. If the site is complex in nature and/or expects to receive huge traffic, make your voice heard about the requirements for hosting – and get that hosting established well before the launch date.
