Archive for the 'Code' Category

Hidden text that works for everyone!

Thursday, July 10th, 2008

So hidden text on the web is a BAD THING, we all know that. Gone are the days when it was considered cool to stick loads of words on a page — usually at the bottom — in the same colour as the background, possibly in 5px type.

Of course the search engines got wise to this “keyword loading”: it contributed nothing to the content of the page, after all. It got dumped into that category of “Blackhat technique”.

Good content is all about value to the reader and every word should count, so stuffing lots of “invisible” text on a page is simply wasted pixels. If you want to increase the keyword densities of your pages, simply write more (or at least write better).

But hang on. Never say never. There is a very good reason for including “invisible” text on your page, and not just the correct use of alt- and title-tags.

Those with a visual impairment rely on the text on a page completely: pretty pictures make no difference to them, so make the page work for people who can only read text. That means fully explaining text links and adding blocks of text to substitute for images.

This is all achieved using the CSS attribute display: none;

Create a style called .accessible (or .ted or .jarvis or whatever, it’s not important) thus …

.accessible {display: none;}

Now, any time you want to add “hidden” text, you can do it simply by wrapping it inside this class.

That means that the phrase …

The <span class=”accessible”>cat sat on the </span>mat

renders to an ordinary browser as …

The mat

but to a screen reader as …

“The cat sat on the mat”

Of course it’s a frivolous example but you might use this technique to improve a list-based navigation.

One site I worked on had a left nav where the code was a horrible table-based affair …

<table width="180" border="0" cellpadding="0" cellspacing="0"  class="bgrleftmenu"> <tr> <td width="20"> <img src="../images/default/spacer.gif"width="20"   height="36"></td> <td colspan="2" class="headerleft">Menu</td> </tr> <tr> <td colspan="3"> <img src="../images/default/spacer.gif"width="20"   height="8"></td> </tr> <tr> <td>&nbsp;</td> <td width="13"> <img src="../images/default/spacer.gif"width="4"  height="7"></td> <td width="147"> <a id="ctl00_LeftUserMenu1_LeftMenu1_hlinkHome" class="linkyellow12"  href="default.aspx">Home</a></td> </tr> <tr> <td>&nbsp;</td> ... <td>  <img src="../images/default/spacer.gif"width="4"  height="7"></td>  <td> <aclass="linkyellow12"   href="../en/help.aspx">Home</a></td> </tr> <tr> <td colspan="3"> <img src="../images/default/spacer.gif"width="1"  height="12"></td>
 </tr> </table>

However, the Semantic alternative was not only much more elegant, it worked better in terms of accessibility AND in terms of SEO!

<h2><span class="accessible">Site </span>Menu</h2> <ul>
 <a href="./." title="Go to the Home Page"> <li> <span class="accessible">Go to the </span>Home<span class="accessible">Page</span> </li> </a>  ... <a href="../en/help.aspx" title="Need Help? Get it here!"> <li> <span class="accessible">Need </span>Help<span class="accessible">? Get it here!</span> </li></a> </ul>

In a common or garden web browser both of these would produce a standard vertical navigation …

:: Home

:: Help

But via a screen reader you get ..

:: Go to the Home Page

:: Need Help? Get it here!

“But what’s the point of all this?” I hear you cry. “Are you just being nice to blind people?”

Well, yes — and remember that a MAJORITY of the world’s population has some sight impairment — but there’s one “blind” individual that’s important to everyone interested in content and SEO: your local search engine.

Search engines, whatever flavour (but we’re all thinking Google, aren’t we) are effectively “blind”. That text-light, image-heavy page may look good to humans with perfect eyesight and a true sense of colour dynamics, but to Google it’s just a load of source code.

Make your site more accessible to those with a visual impairment and you also make it more accessible to the search engine spiders, but use a technique like this and you actually get more keywords on your page with no penalties!

Going for the one?

Friday, December 7th, 2007

The question is, would one database be superior to many? This is, as usual, more complicated that it at first seems.

From a practical point of view, the amount of data involved is no great shakes: for example, one might compare the amounts involved with, say, the transaction history of a large retail site. It would take three years or so to accumulate as much data as this company produces as the retail site produces in a day. At this level, almost any type of database is available, even those with supposed scalability issues such as MySQL.

So if size is not important, what is?

In the first instance, resilience may be a problem, especially in the case of a media organisation tied to publication deadlines. Imagine the whole thing crashing, with perhaps an estimated restoration time of 18 hours.

  • For online, such a delay may mean at least 18 hours of downtime, with associated loss of revenue from ad banners and click thrus as well as any online sales.
  • For print, workarounds could probably mean that copy was saved locally and added to the database at a later time; however, the exact timing of the crash would be important — the closer to deadline, the more damaging.

With a large single database, every catastrophic outage would hit all teams. In this case some fall back position would be a necessity, for example real-time mirroring of the database. Yet the amount of data means than there would be little noticeable affect on performance.

An alternative would be a single large database with local repositories. In this case in the event of a catastrophic failure, teams could carry on using data stored in the repositories, with the main database being updated when it comes back online.

Another alternative is to use many smaller linked databases with front end software carrying out necessary housekeeping to ensure co-ordination. With a multiple database option it may be harder maintain integrity: with many smaller databases comes the opportunity for users to add their own tables (possibly complicating the situation). A multiple database solution would ideally require more complex policing.

The main overhead in all these scenarios is that the amount of data involved, which is not great. This should be an encouragement to mirror any datbase, no matter how big it might be to ensure continuity of supply in the event of calamity: this might also mean mirroring the databases at a remote venue to ensure complete security.

Five ways to damage your SEO with content

Monday, August 27th, 2007

1. Write Rubbish

If your content makes no sense, if it’s dull and irrelevant, if not even your mother would make it all the way through, then you can be sure it will be bad for SEO. Make content interesting, make content readable, make content fun!

2. Duplicate It

There’s nothing quite so annoying as content repeated again and again. I mean, there is NOTHING so annoying as content which is repeated time after time. Really, repeating content again and again and again is really, REALLY, really annoying. The search engines don’t like it either, you might even describe it as SEO’s worst nightmare. Don’t use content which is duplicated (or even just summarized) elsewhere on the internet — even if it’s your own copyright, especially if it’s duplicated on the same site. Check for originality on copyscape.com if you’re not certain, and even if you are. Even if the content is your copyright and has been copied by someone else, it can hit your SEO if the copying site has a higher Page Rank than yours.

3. Make It Invisible

For search engines, invisible text equals SEO scam. Technically, making content invisible to the naked eye — for example, making it the same colour as the background or making it transparent or putting it in comment tags — comes under the heading of “Black Hat SEO”, or cheating. It’s a way of artificially loading content with keywords [SEO, content, search engine, timeshare, cialys, pre5cription5] to bump up the density, and the search engines got wise to it years ago. It will hurt your SEO.

4. Use JavaScript To Present It

Search engines just won’t index content which is provided by JavaScript. There have been too many SEO scams using scripts in the past and Google and the rest aren’t taking chances any more. If all you can see in the content source code is a ton of JavaScript, then you can be sure that the search engines won’t be seeing it either.

5. Make It Chaotic

Content should make sense. Part of that is how it is organised. One of the best ways to ruin your SEO is to order content in an illogical, inconsistent fashion so that the reader doesn’t know whether they are at the beginning, middle or end. This extends to your <h> tags: use them in the order <h1>, <h2>, <h3> … <h6>. Keeping content organised means the search engine spiders can crawl it, index it and rank it to the best effect.