Everyone needs SEO. Really, we do. OK, but what is SEO and what does it mean? After all, it’s one of those Internet jargon bandwagons that everyone seems to have jumped on without really knowing what it is or how it works.
This article isn’t about paid search. It isn’t really about SEO (Search Engine Optimisation) either. Mostly because a good website is naturally optimised for search. What this article is then, is a quick guide to what to do to make sure you get the best rankings you can by the search engines.
Code like a demon
This is one of those obvious ones really. If you build the site semantically (in a structured fashion, much like you might write a document), Google and the gang will spot that and work out what is relevant on the page and what is less relevant. It has nothing to do with how high up on the page it is. After all, “how high up” is subjective, depending on whether you’re browsing in Firefox or in a text based screen reader. If your code is semantic, then you’re a step towards search nirvana.
Get the content right
This is really the most important part of the whole process. If you have poor content, then you’re never going to get anywhere in the rankings. How do you write good content? Well, given that Google is effectively a big computer that understands the written word, you’re lumbered with a bit of an issue. First off, search engines scour pages for their content, and work out how many times and in what context words appear. Then when you search for them, it looks up which sites have the most “relevant” words in their content and displays that page as a link. One of the key reasons why the homepage isn’t always the most hit on a site is because there is content somewhere else being hit by search referrals.
In saying that, I’m not suggesting you just write rubbish with loads of the keywords you want people to reach you by. That won’t work. The search bots that spider your pages are clever enough to know if you’re just repeating yourself. Certainly write with search engines in mind. It’ll be no less readable, though you’ll have more keywords within the body of the text, but precisely because of this, it’ll appear higher in a search result.
What do the SEO companies do then?
Not a lot. I’m kidding guys, but it’s true that some of them (read many) are complete sharks. Actually that’s probably true of any segment of Internet based industry, and I’d hazard of any other too.
The ones that do a lot of work know what it takes to make your site appear high up in Google. They will do a few things that will help, but in truth, none of them can guarantee results, and most of it is really down to the content. That’s down to you or your client, whichever it is that is the content admin. They will add a few pages to the site full of keyword laden text that feels natural enough to a search engine but when you or I read it, it looks like a load of twaddle. This, coupled with a sitemap can help because the search engines see more pages with those keywords all over them, but it’s still not going to help if your content is poor.
So content is king, and while paid for software or companies specialising in Search Engine Optimisation can help, you’re better off first making sure your content is up to scratch. And that the search engines can see it.
Your site is playing host to a competition. You’re giving away a nice hefty prize. A TV, a mobile phone, a holiday perhaps for the winner and his or her mates. And the competition revolves around a pure computational figures – how many times someone votes for whatever you’ve uploaded – a picture maybe. A video, or some prose.
The big problem here is that there are some quite savvy users out there who will go almost to the ends of the Earth to win these competitions. And then what if you run another competition and you find the same set of users is trying to manipulate the system again? How do you control this and make sure the people who aren’t cheating get a fair shot at the prize?
That really is the question. How do you stop people cheating? Simply, you can’t. The longer version involves some methods that will certainly help to reduce the amount of cheating that takes place.
One of the first methods is to force people to enter valid email addresses to register – you send them an email and they can’t log in until they’ve activated using a link in the email. The link is usually encrypted and can’t just be guessed. This falls down though when you realise there are sites out there specifically designed to give you temporary email addresses for registering for sites. And the whole process can be scripted by someone with a bit of nouse.
So you make sure that users on your site can police the content for you – they flag it, and you delete it if you feel it’s contravening your terms and conditions – oh yes, and make sure the terms are bullet-proof. Make sure winners aren’t automatically decided by a computer – decide with “judges”.
Good stuff – we now have a user policed site where the users have to have access to the email account, and we’ve even put a CAPTCHA on the registration process to stop computers being able to automatically sign up.
These are wily users though. They’ll still try and get the prize. You could do any amount of verification though but at the end of the day, having a mechanism in place to remove offending users from a competition, or just to pick a different winner is probably the best failsafe. OK, so the whole process can’t be automated – most of it can – but you wouldn’t want to give that one user a TV, a holiday, and a few grand one after the other would you?
It’s well known that Flash makes sites look better. Isn’t it? Well only if you are stuck in the early part of 2000.
I would like to draw your attention to a few sites that use no Flash at all to get their desired effect across:
These are all great sites, some better looking than others, but it’s the technology I’m focusing on here.
Flash is good, but not when it’s used to make an entire site, or to replace content areas that don’t need to be Flash. Use it for videos. Use it for the analogue clock on bbc.co.uk, at least until SVG takes off and you don’t need to use Flash for that any more. Just please don’t use it as a replacement for real websites. Flash, as much as Adobe might say otherwise, still isn’t accessible, and most of the sites that I’ve seen built in Flash are a nightmare to maintain, and look horrendous.
Rant over.
"It Doesn’t Work"
“The site doesn’t work.”
“What do you mean, the site doesn’t work?”
“It just doesn’t work.”
“So what is it doing that it shouldn’t be doing?”
“When I go to the site, I can’t do X.”
“But when I go to the site, I can do X.”
To a developer this is an all too common dialogue between someone looking over the site – usually someone non-technical, and definitely someone who hasn’t read up on Reporting bugs effectively.
After development comes testing, and during testing, bug reports are made. If the bug reports are unclear in any way, then it takes more time to fix them, because it takes more time to decipher their real meaning. So what this article is about is understanding the core elements of a good bug report, and why “It doesn’t work” is bad.
From the perspective of a developer, a good bug report consists of a specific set of things that must always be there in order to be able to replicate it. Without the ability to replicate a bug, the chances of it being fixed are very slim. The above article by Simon Tatham, a very well regarded developer, of PuTTy fame, is probably one of the best groundings I’ve seen for writing good bug reports for software, and it extends to web applications and sites too. The first of these things is a concise but clear summary of the bug. One line is enough – just something that describes the issue, eg. “Firefox 3.0.3 prevents upload of multiple files in new messages”. That’s a good summary that with some additional information as described below is the formative part of a good report.
The concept of “Show me how to show myself” is crucial here. What’s needed is a step by step set of directions by which you came to see the bug. The developer may well not have used the application in this way, and didn’t expect it to be, but users will always do the unexpected! If the issue is a display issue, take a screen shot, and include the whole window, not just a bit of it. If it’s a browser issue, and this happens a lot on the web, the developer needs to know which browser the issue happens in. If the same issue happens in every browser, one screen shot will do, but a comment to that effect is absolutely necessary. There are also some key facts that should be included with any and all bug reports: Operating System, Browser, Browser version, URL on which the error occurs. Some other useful pieces of information, depending on the bug report are: Flash version (or that it’s not installed), JavaScript status (on / off). If you think there are any more, there probably are, so feel free to comment on this article.
So, to conclude, we need a good summary (usually marked down in a subject field if you’re using a bug reporting system), a set of facts about the machine you’re seeing the issue on, a clear set of instructions on how to reproduce the bug, any additional information the developer might need to reproduce the bug, and if you can, a screen shot or set of screen shots to show the developer the problem you’re seeing.
The development process
It’s maybe an unfortunate consequence of the web being so instantly accessible that development process is often forgotten about when dealing with clients and their expectations. I’d like to put forward some suggestions and reasoning behind them as to why development processes should be adhered to, even on smaller projects. The aim of this article is to take you through each step of the process and explain why each bit happens and what it achieves. It’s going to be a fairly lengthy article again I think, so bear with me.
After the strategists have done their thing and come up with a conceptual plan for what could be done to improve the brand/ROI/other business related thing, the next step is to decide exactly what they meant by it all. The best way to look at each project is to take each part as a sub-project of a much larger umbrella project.
Scoping
So… The first one is scoping. Scoping doesn’t mean you have to get technical. It just means you have to decide what you want to achieve from the site, and what you want the site to do as a user. In actual fact, scoping can take on some technical aspect, but I’d suggest looking at RSpec stories as a good way to describe what it is you want the user to be able to do. Scoping can take anything from a couple of days to a few weeks to get right, depending on the size of the project and the number of people who have a say in the matter. I recommend limiting this to the client, an Interaction Designer, and a technical person of some kind (usually a Senior Developer or a Tech Lead, both of whom would have a breadth of knowledge). If you don’t want to use RSpec stories, you’ll probably want to split this project up into two – Scoping and then Technical Functional Specification. RSpec stories allow you to do both at once though, saving time and money in the process. They’re easily understood by non-technical people and they show exactly what needs to happen to the developers later. Deliverables for a successful scoping project would be:
- Project Scope (containing outline business case, the method by which this will be achieved, and the salient parts of the functionality therein)
- RSpec stories for the functionality; giving a bit more detail to the project
- Cost estimate for building the project according to the signed off Scope and Stories.
Note that I added the cost estimate in at this point rather than before the start of the overall project. This is because usually we don’t know beforehand the size of the project. Admittedly it doesn’t always work this way round either, but it’s a good ideal to aim for. If at this point you find the cost is prohibitive, it’s time to push some functionality back into a second phase. One further contributing factor to the cost will be the complexity of the design, though this isn’t dealt with at this stage in the process. Again, this will need to please the designers, yet keep within the required budget as set out in the initial cost estimate. This can change, as a change request, if the design comes in as more complex than was originally specified (this must be detailed in the scoping document)
Interaction Design
A lot of companies are calling this IA, meaning Information Architecture. I think this is a little misleading, as it infers a technical assessment of the data storage and delivery. Those things are dealt with by a separate process later down the line, though the basics will have been thought through during the RSpec story development earlier. Interaction Designers should be highly aware of the various issues surrounding accessibility, web standards and how alternate technologies should be used within the remit of the project. Flash is a good example, and there are countless arguments as to how it should be used on the web. A good ID should understand these fully and design the interaction of a site accordingly. This will take the RSpec Stories into a format that can be visualised by a web designer, and scaffolded (making up a basic page without an overall look and feel) by the developers. Tools like Axure RP Pro can make this a straight forward task. Many ID’s like to use Visio, but the interaction doesn’t exist and Axure allows you to model complex scenarios and demo them to the client.
If you’re using Axure, the deliverable for this part of the project will be a model of the site annotated as needed, and signed off by the client.
Web Design
The contentious part! Anyone can design a website, right? Wrong. A good web designer will know (mostly through communicating with web developers and gaining experience) what should, shouldn’t, can and can’t be done. Often, everything can be done that is desired, but it’s the method by which that should be done that will ultimately come out from the design. The designs should always be done in collaboration with the same group of people involved in the initial scoping of the project. Peer review is an incredibly important part in making a project like this successful. Get it wrong now, and future maintenance costs will soar. Get it right, and you’ll have yourself a beautiful site that is a joy to use.
Deliverables will be a set of designs, along with annotations within the Photoshop files, and guidelines in a document, which would detail general branding throughout the site – colours, link decoration (underlines, colour, etc), fonts and sizes used throughout, and anything else that is to be held consistently throughout the site.
Development
Given an accurate Interaction Design, this phase can actually happen while the design is in progress. At Initforthe, we often provide a timeframe where we’re not doing the designs ourselves by which we need to have final signed off designs. As long as this is met, development can continue, and the project isn’t held up by requiring designs first. There are two aspects to development in this regard. Front-end development, and Back-end development. The former will usually include building the designs once they have been signed off, and the latter involves building the functionality according to the RSpec stories. The back-end developers will usually build the scaffold according to the Interaction Design, and then plug in the front-end when that has been done later on. This allows everyone to get on with their part without affecting the other.
Depending on how the project is being built, parts of it can be put on a development server during build, or working parts can be put up as soon as they are done. These can be shown to the client as working models based on the RSpec stories, which now form an acceptance test, and the wireframes built as the deliverables for the ID. It is important if you’re doing this that the client is made painfully aware that the site has areas that don’t work yet, and they don’t yet look like the design that they’ve signed off. But it does give them some level of confidence in seeing things happening. Each day or couple of days, something new goes up for them to look at.
The key deliverable here is the final working project.
Testing
Testing can be carried out throughout the project. Developers should be testing, and if using languages or frameworks that provide for testing the functionality, this should be used. It takes longer to develop, but you can usually be more certain that the bugs won’t be there if it’s done properly. This is called Test Driven Development. Ruby on Rails is predicated on this as a concept.
Final testing should be carried out to perform a number of tasks. Firstly that the functionality works in the browser. If the functionality works, the acceptance criteria can be signed off as complete. The second is the look and feel. This should be as per the designs signed off by the clients and peer reviewed by the ID and developers. It should be tested in a multitude of browsers, though at the time of writing this article, I’d recommend the following set: Mozilla Firefox 3, Apple Safari 3, Internet Explorer 7, Opera 9.5. The reason for this is because each of these browsers will prompt the user to upgrade when there are new versions available, and as there is no reason not to upgrade, only the latest should realistically be supported. My previous article on supporting IE6 details why old browsers shouldn’t be supported any more.
Once you have functionality and look and feel signed off, you have a working product.
Things to remember
There are always a few things you need to keep in mind when you’re building a project of any size. Firstly is the scope. If something falls outside of the scope, it is important to keep track of these changes as requests. Some will impact severely on cost, and often also on time, which will push the delivery date back if it’s agreed that they’re needed for launch. Alternatively they should be put into a separate project to be started after the end of the current one.
Next is copy. Signed off copy is what should be delivered to developers for inclusion in the site. If the copy changes at a later date, this is also classed as a change request and should be charged for. There is good reason for keeping a strict rule about this. In offline work, if you change the copy after the artwork has gone to the printers, or you change the credits in a video after sending to the distribution companies, they’ll charge an arm and a leg to get the new version out on time and the printing presses/distribution stopped on the version you initially sent. Just because the web feels instant, it should still be adhered to in the same fashion. A lot of the time, copy changes are where money is either made or lost on the project.
The final thing to remember is that it always takes longer than the client wants to build what they’re after! So make them aware of it, and make sure they know they may have to drop some functionality to get the project out on time. Further things can always be added later!
Recent Comments