If there is one thing I’ve been disappointed with in the last few years, it’s the amount of tedium involved in taking a website sample or template and modifying it to get to something close to what I envision. This is because most templates don’t actually solve the problem I want them to. Often they aren’t even site templates, they are style templates. Often enough, they do come with some demonstration of components, but that can be picked up easily enough on it’s own with a simple web search. What I’d like to explore here is a simple list of functionality that templates should include. The people who search for an buy templates are new to code as often as not. And even when they are expert in one thing, they often are missing some of the expertise needed to adequately apply a template…resulting inevitably in time spent fighting a framework instead of jumping into the meat of their site and working on functionality that drives business more directly. Bear in mind, I am writing from a .Net-centric experience, some of this will need interpretation to other frameworks but it is conceptually language agnostic.
Full disclosure, my reason for writing this is as much to disseminate an idea as it is to cement my own thoughts about what makes a good template. I’m working on a project at DotNetNitro to deliver good templates for .Net developers, so we can all deliver high quality sites faster, more reliably, and within budget.
What Makes a Good Template?
Multiple Pages Framed out with sample content (I like 7–10 as a target)
An easy to extend pattern of navigation with more than 3 demonstrated links
A fully functional component outline of all major controls
Registration and Login screens that are fully framed into easily modified backend code
Demonstrated implementation of partial views
A built-in and easily rigged (via configuration) email collection form. At this point these are ubiquitous but often are absent from templates for some reason.
specific demo pages designed around specific features that you highlight in the template description on your sales/download page
A readme or set of markdown files that are actually worth reading.
Really a rather straightforward checklist in my opinion. Some of these could use a little more detail though. Let’s look specifically at a few.
Framed Out Pages
In general I want to see a homepage (duh), registration/login, generic post, account/password recovery, contact, about, pricing, components, and email signup (which may not be it’s own page but at this point is should be considered necessary for all apps). This isn’t exhaustive, and it shouldn’t be, but we’ve been on the internet long enough to realize that all of these are ubiquitous enough that simple providing a simple functional layout is preferred. They are easier to delete from a project than they are to add manually and the time savings makes it more than worth the effort for a template purveyor to supply.
Easy to Implement (and Extend) Navigation
This one is likely an oversight caused by the tendency of designers to assume that they are selling to designers. This isn’t always the case, and I see a lot of people missing the mark on these. Especially with respect to the asp helpers that really should be leveraged more in templates for dotnet based users. In designing to be more general, templates around the web will completely miss the fact that people searching and using templates are often not CSS wizards and can’t just hit the ground at a dead sprint to deliver a product. From a customer service perspective, consider that making it as easy as possible trumps protecting any IP rights you might claim to what is inevitably a recycled interpretation of previous work. Help your users out folks.
Easily rigged email form
Lets face it, email signups and mailing list subscriptions are a fact of our internet existence and despite grumblings are very useful to both senders and sendees. Places like Mailchimp and Sendgrid and others all use the same basic format with the same basic inputs. How about we start including, as a standard, control sets on a screen that require only very minor changes. No one likes to have to hack that stuff together in a way that fits their the style of their site (which as often as not is also hacked together).
For cripes sake, lets please start providing actually useful documentation. Inference from existing html and css does not equal documentation. I believe firmly that some of the security issues that abound on the internet are created not by bad code, but by bad documentation that leads to poorly hacked together implementations. This boils down to knowing your audience and giving them tools that help them be better and more secure.
These feel like a no brainer, but guess how many I’ve seen in templates in the wild? I can’t remember ever seeing one! There are obvious templates designed for blogs, and postings, and repeated structures on some page or another, but inevitably it is left to the user to figure out how to make it work in their respective frameworks and in a way that won’t require a bunch of hands on manipulation to update in the future. Let’s all resolve to demonstrate decent software design patterns in our design templates. Paying that value forward means you add more value with very little extra work. If your goal is to be useful on the internet, you should be aiming at maximizing delivered value. This is a good place to expand the quality of your deliverable.
All in, none of this is difficult to do, and it still fits within the same paradigms already in use: create a rough template, build multiple variants, bill these variants as their own downloadable product. Lather, Rinse, Repeat. Even if you’re delivering free content as I intend with DotNetNitro, you can still leverage the work you’ve already done to generate additional content and make the internet a more beautiful place.