Foundational Design and SEO Considerations

ML Jan 29, 2006

Now, it’s time to consider aesthetics and search optimization considerations. As many people in the SEO field will tell you, there is a balance to strike between SEO best practices, and design perfection. If you were just going after perfect search optimization and usability, everything would look like Jakob Nielsen’s useit.com (talk about a dated look). But to go after uncompromising design, you would do the entire thing in Macromedia Flash, and make the entire site invisible to search, defeating a primary purpose of a website—generating the sales opportunity in the first place. But just as a skilled poet can communicate perfectly while maintaining pentameter and rhyme, a skilled Web developer can seamlessly combine optimization and design. I have three extreme advantages going in my favor…

  1. I’m creating the site from scratch, so all my decisions are foundational.
  2. I’m a V.P. of the company AND the entire art/programming team on this project, so I have no artist to satisfy.
  3. I’m proceeding with a very clean and sparse Google-like look, so art’s not a large project.

I should not use the Google sparse look as a license to go boring. Remember my comment about Jakob’s site? I don’t want to be a hypocrite. So, I do indeed plan on spicing up the look of the site. I’m quite partial towards the look of the blog-site too-biased, the blog site for which the Ruby on Rails Typo program was developed. So, what design parameters do I have to work with?

  • Logo
  • Value proposition in the form of a tagline
  • Navigational elements
  • Pervasive Sign Up form
  • Space to push out message du jour—when the MLT app is done, this space will be where we give a preview of the sizzling visual of HitTail.

The logo placement is already decided. The sign-up form will initially be just a single line positioned like a search box. The initial tagline is already written. So, I need to nail down the navigational elements. I think I’ll make them very Google-like in that they’re plain text links, easily changeable, and implying tabs even though the tabs aren’t really there. Plan text links being used as-if they were tabs (and maybe making them look like tabs wholly through CSS) is a perfect example of the 80/20 rule in design. I could spend a whole weekend just designing a cool tab look that someone, somewhere would hate (or would break some browser). Design is so subjective and pitfall-ridden, that you have to choose your battles carefully. I’m sure to do a dedicated post on that topic later. But for now, I’m starting out with the navigational elements:

  • Home
  • Why Sign Up?
  • SEO Best Practices
  • Blog
  • FAQ

The visual proportions and weighting when these words are laid out are perfect. I would like to add the terms “PR” and “Pod” to the navigational links, but it really throws off the balance right now, and I won’t have content to add to the Pod section right away. Everything from the PR link could be put under the FAQ link. FAQ feels a little old school, but PR is too obscure. Everyone understands what an FAQ is these days. And everyone understands Blog. But even Blog is getting to feel a bit old school. Pod is the way to go, but I can’t right now. I’ll be able to populate the FAQ quite easily using the CMS.

But I will be able to do Pods soon. I’m going to set up a tiny but adequate audio/video production facility. Talk about humanizing a sight. I can video-document the birth of a Web 2.0 company, and my becoming a part of the Manhattan scene. I’ll try to produce something that maybe could be picked up by Google Current (Google’s cable TV channel). They call Pods VC^2 for viewer contributed content. I’ll attend the iBreakfasts and more conferences, helping generate buzz for my own site by promoting them. Maybe I’ll pitch the idea to my neighbor, Fred Wilson, who publishes submitted Pod-format elevator pitches on his Union Square Ventures website. I’m not going to make an extensive PodCasting post here, but it does merit mention. Just as developing public speaking skills is necessary for certain types of careers, being able to speak well is turning into an optional, but compelling part of Web publishing.

Another important aspect is that I’m putting all my content, with the exception of the logo, into plain text. The headline and tagline definitely look better as graphics. But I need every scrap of SEO-power I can muster in constructing this site. As is the overwhelming trend these days, I’ll be using div’s to format style. But unlike today’s trends, I’ll very deliberately be using tags like p (for paragraph) and b (for bold) to keep the semantics in place. Nothing has set back the Semantic Web like the proliferation of the use of meaningless div id’s, and the stripping out of all conventional document context. HTML tags like h1, p, b, i, blockquote, and many others are still very much worth using, because it is part of the clues you’re leaving search engines about what’s important. Just use div’s to block together elements for stylization.

Span’s are an interesting question, because they are inline. On the one hand, you can avoid them completely by putting id’s on elements such as bold or italics. But then you change the conventional presentation of these tags and risk the search engines parsing engines not knowing what they are at all. A compromised solution is to continue to use bare-bones tags like b or i, and just put a span tag AROUND the conventional HTML tag. It’s a bit of extra code, but it purges out all ambiguity. You know with certainty that div’s and span’s will be parsed for attributes. It’s also very likely that a lot of dumb parsers are not expecting parameters on p’s and i’s. So, this combination removes all ambiguity, and forces search engine to accept the meaning that you intend.

May be misinterpreted…

stylize me

Withholds information from the Semantic Web…

stylize me

A little bit of extra code, but cannot be misinterpreted…

stylize me

There are important facts to consider. If you are willing to make all your “b” tags look alike, you can just create a style that applies to all your bold’s. This is how so many blogs change their anchor-text style from a solid underline to a dotted underline. If you’re able to do this, you don’t need the extra span tags, and you don’t need ID’s on your bold tags. That’s another best-case scenario. But what I’m considering here is the main homepage of HitTail.com, and main homepages always have a different set of rules. You need to stylize elements on a case-by-case basis without affecting the whole rest of the site.

Now the issue to keep in mind here is the “C” in CSS. C stands for cascading, meaning that how things are nested controls which style wins. Last style wins. Inline elements like span cannot/should not contain block element attributes. So, you can’t use margins and padding on a span element. Use div’s when it’s like a blockquote, and use span’s when it’s like a bold.

Styles are rendered outside-in. That is, the definition of span will override the b tag. This is great for inline text, and really helps with the Semantic Web. But when you’re using the above bling example with a paragraph tag, it doesn’t hold up. Div’s and span’s are only meta-container tags. That is, they only exist to contain other elements, and add some meta-data such as ID’s and class names, and imply nothing about content relevancy or importance. Everything belonging to such a unit belongs INSIDE the container—especially if you’re using the container to move things around, such as you do with div’s. So you see, you can get away with the bold tag outside a span, because it will cascade properly, and you never MOVE a span. You get the semantic value of the bold tag, but the span tag wins in applying style, because it’s working outside-in.

But you can’t do that with div’s, because a bare-bones paragraph tag inside a div tag will override the div’s style with the paragraph’s default style. And you can’t change the default paragraph’s style without affecting the rest of the site (or page), and you can’t add an ID to the p or you throw off creating a perfect document structure for the Semantic Web. It’s something of a conundrum, and those who can solve it get a sliver of potential SEO advantage. Many things in SEO are not about whether they definitely provide a boost today, but are rather about whether they may ever produce a boost someday, and can never be interpreted as bad form or spanning. Often, the solution is to stick to the bare bones HTML code in order to get the semantic advantage, but to use a second style definition for just that page that overrides the global style. Practices like this may seem over-the-top, but it’s the weakest link in the chain principle. Much more on that later.

Well, this has been quite a post. I could break it into smaller posts, but it really was part of one unit of thought, so I’ll keep it intact. But that leads the SEO issue of what to name the post. The title transforms into the title tag, the headline of the permalink page, the words used in anchortext leading to the page, and the filename. This all combines to make it the single most search-influential criteria for the page. If I were going wholly for optimization, I would break this post into many smaller posts, using the opportunity to create more titles, and consequently more sniper-like attempts at Web traffic on those topics. But more on that later!

Leave a Reply

Your email address will not be published. Required fields are marked *