Is Promotion the Elephant in the SEO Room?

I've listened to many SEO gurus' presentations on SEO over the years. There's always a lot of discussion about keywords, meta tags, url's, page titles, headings, javascript, etc. And usually the presenter mentions that Google puts more weight on the links to your pages (and the "quality" of the referring site) than on the factors you can control on your site. But after that short statement, they always quickly move on. Even Google only reserves two of 31 pages to this subject in its SEO Starter Guide (see pages 28 and 29).

So hold on - the most important factor always gets the least amount of air time? Why is that?

My guess is that the things you can control are many, they are somewhat technical, and so they make site owners feel they need the services of SEO gurus. At the same time, the "external factors" are few, easily understandable, and take a lot of time and effort to get right. And you can probably do a better job in this area than your consultants could anyway.

I'm not saying that keyword research, meta tagging, etc are not important - they are. But those are just table stakes. If you want to differentiate your site, you have to focus on the external factors, and spend the time and effort to get this area right.

So what is it you should be doing? Here is a list of possible activities:

• Find the most influential (i.e., highest ranking) sites that publish about the same subjects as you do on your site. If you make widgets, find out who publishes the most influential reviews of widgets, who posts educational content about widgets, who the biggest users are of widgets, etc.
  
• Review your content to ensure that it will be seen as having value to those influential sites.
• Build relationships with the influential sites' publishers. Show them who you are. Convince them of your authority in your shared market.
• Build out your online relationships with these publishers. In other words, you want them to understand that linking to content on your site will enhance their content. At the same time, if they have content that your site visitors would value, be sure to link to it.
• Use your relationships to find out what content they - and their visitors - want. If it's something that you can provide, and that will build your reputation or make people interested in you, develop that content - and let the publishers know when you have done so.

In other words - you have to promote your site - with the right crowd. If you can build your reputation as a valuable resource, and get influential sites to link to your content, you can optimize your search results rankings much more than you could by solely focusing on your internal factors.

Here's a good article on this subject: http://sites.google.com/site/howtoseo/seo-3-external-ranking-factors.

How a Web Design Goes Straight to Hell

Lately I've received several requests for web site changes that don't make sense, either for our web site visitors or for us. The latest request reminded me of a comic I read a long time ago. It was a great comic, so I spent some time searching for it. I'm sure I'll want to reference it some day, so this post is to make sure I can easily find it again. And you may get a kick out of it.

http://theoatmeal.com/comics/design_hell

converting text to numbers in Excel

I found a helpful trick in Microsoft's Excel help for converting text to numbers in a range of cells. Thought I'd pass it along.

1. Enter any number in a cell.
2. Copy it (Ctl-C).
3. Select the range that you want converted to numbers.
4. Select the menu options Edit, Paste Special.
5. Select "multiply" on the pop-up form.
6. The range you selected should now contain numbers, not text.
   

It's in Microsoft's help, but who looks there?

Drupal - Better way to translate blocks

There are custom blocks on a site I manage that contain simple English text. We just started a push to add Spanish to the site. So I researched how to make blocks multilingual. The documentation I found mentioned 2 ways to do this: 1) use Drupal's string translation to translate whole blocks into different languages, or 2) create separate blocks for each language and enable them only for the nodes in the associated language.

I wasn't happy with either of these options. I don't want my contributors creating and maintaining string translations, and neither do I want them editing blocks.

Meanwhile, content (node) translation in Drupal is elegantly implemented. To translate a node, you go to the node and create a translated version. The translated versions are then always tied to each other. With this my contributors can create English and Spanish content easily.

Happily, I found another - and I think better - way to do this with the "node as block" module. I don't think this module was developed with multilingual content management as a prime driver, and I don't see much discussion about this valuable use.

There are a couple of quirks you have to know about. One, by default the block only displays a subset of the content of your node, so you have to include the "<!--break-->" tag to make sure all preceding content is displayed (if you know a way around this, let me know!). Two, when you translate a node, you have to make sure to specify with the translation that you want a block created (even if you've done so with the original node). And yes, this means you'll end up with 2 blocks.

Even with these quirks, this is going to be a much better way for my contributors to edit content in multilingual blocks.

Note that there are several other seemingly similar modules that I haven't researched, including "nodes in block" and "node blocks". If you've found that these or other modules serve this purpose better, let me know!

Can this be called agile?

Background: corporate I.T. talks about wanting to become agile. It has already stopped using the traditional waterfall methodology (requirements, design, development, test, implementation...). High-level requirements are documented. Some development groups document use cases, others document screen shots, data flows...; often the developers simply meet with and email back and forth with customers to understand what's wanted. Most development groups next include the customer when they have questions, or when they are ready to show functionality to the customer. Note, though, the following:

• I.T. follows a standard, hierarchical organizational structure. There is no use of self-organizing teams.
• None of the development groups use pair programming.
• Some groups have developers on the other side of the world. Of these groups, some may have daily scrums or stand-ups via teleconference - though it should be noted that customer representatives do not attend these daily meetings. It should also be noted that there is little overlap in working hours with the remote development staff.
  
• None of the groups have their customers sitting near them during development.
• No one has the title of "project manager" or "scrum master". Customer representatives act as project managers for some projects, and senior developers take on that role for other projects.
  
• Some groups support single applications. Others support many applications. Of the ones that support single applications, some release enhancements on regular schedules (1 - 2 months).
• There is talk about standardizing on using use cases or feature cards and working with customers to prioritize these.
• Large projects (over 100 hours of work) have to go through an approval process, requiring specification of effort, risks, ROI, ...
• Continuous integration, automated testing, and test driven development are NOT being used.

While I.T. has definitely moved far from old-line development methodologies, it seems to me there is a lot lacking with respect to abiding by the agile philosophy.

What do you think?

Beautifying HTML

You may already know that I'm impressed by AirSet. I'm using it to publish the web site of Willowbrook Arts Camp, a non-profit daycamp on which I am a board member.

Although I am impressed by the service - and I will continue to use it - there are some frustrations. The one I want to discuss in this blog entry is editing the HTML in AirSet pages.

AirSet has a WYSIWYG page editor, and most people will probably never use their HTML editor. If, however, you want to do this, you should be prepared for the fact that carriage returns and line feeds are removed every time you leave HTML edit mode. So every time you enter HTML edit mode, the HTML you see will not be formatted in a way conducive to manual editting.

I had a conversation with their developers, and they understand the issue; but changing it is not high on their list of priorities - which I understand, given that most people won't use it.

But since I do use it, I decided to take some time to find an alternative solution.

One solution, the least technical, is to simply maintain the HTML outside AirSet, using another editor. When you want to make a change, edit the HTML, and then copy it over your AirSet page. While simple, this can become tedious. And if you maintain the HTML on your computer, you can't edit your AirSet pages from another computer without your HTML files getting out of sync.

I looked unsuccessfully for a FireFox plugin that could beautify HTML in text area fields. The Web Developer plugin has a tool for validating HTML, but it can't deal with AirSet's pages when you try to have it "clean up the markup with HTML Tidy".

I also looked at the documentation for HTML Tidy. I thought that it might be able to clean up HTML in the clipboard. And while I found it was discussed, it is not currently capable of doing this.

So I decided to use macro playing software to do the following:

1. Copy the HTML to my clipboard.
2. Create a temporary file for the HTML.
3. Copy the HTML to the temporary file.
4. Run HTML Tidy on the file.
5. Copy the cleaned up HTML back to my clipboard.

Before running this macro, I open the AirSet page for editing and change to HTML mode. When the macro is done, I can then copy the cleaned up HTML back into the AirSet page.

It probably sounds more complex than it is in daily usage, as it's really only 2 extra steps (starting the macro and copying the HTML back into the page).

So, in case you want to do the same thing, here is how I'm doing it.

Note that I'm doing this on a Windows machine. I'm also using AutoHotKey. If you don't have it, install it.

Next, download the AutoHotKey script.

You'll probably have to edit the script, as it stores its temporary file in c:\users\bill\desktop\temp, a folder which probably doesn't exist on your pc.

To start the script, double-click on it. When you start it, it does nothing other than registering the hotkey combination a.

When you are ready to edit the HTML of your AirSet page, open the page for editing and change to HTML mode. Make sure your cursor is in the textarea field. Now press a. When the macro is done, the beautified HTML will be in your clipboard. You can now paste it back to your AirSet page.

2 more notes:

One, you can start the macro when you boot your pc by putting it in your Startup folder.

Two, this macro is good for any HTML - not just that in AirSet. For example, if you are editing an HTML file in Notepad, you can use the same method to beautify it.

SharePoint for Internal Collaboration? Fail!

There's a lot of buzz about SharePoint in the corporate world. It seems to have come out of nowhere, but I believe SharePoint has hit its stride because it provides a safe answer for IT management when asked about their strategy for web 2.0 in the enterprise. It's a clear continuation of the IT management thought process that's been around since the '70's - what started with the statement: "you can't go wrong if you buy from IBM." The other cya vendors - IBM, Oracle, CA,... Haven't had a good story here, so Microsoft has won by default.

The only problem is that SharePoint sucks. Ok, maybe that's a bit harsh. SharePoint is ok as a document repository. But really, it does suck at facilitating collaboration in the enterprise. If you've followed my writing, you know that I don't normally use harsh adjectives or make overly bold statements. But this one is easy. SharePoint is just not in the same league as so many other tools. Let's go through some of SharePoint's disadvantages.

Web 2.0 - the philosophy

The premise behind web 2.0 is that:

• People are more than executors of commands - they have important and relevant knowledge, and they are sources of good ideas.
• Significant value is gained by allowing people to collaborate, work out problems on the open stage, and make that knowledge available and easily findable. Better decisions can be made (people will have better information with which to make them), decisions and tasks can be completed more quickly (they will spend less time finding relevant information), and the organization will be less brittle (knowledge will be stored centrally, rather than solely in people's heads).
  
• People - on the whole - are smart and ethical.
  

A change in management culture is often required of organizations that want to take part in this. Historically, organizations were based on "command and control", with jobs and tasks specified from the top down; and information was shared "on a need to know basis." But Web 2.0 in the enterprise requires trust, a willingness to listen to the ideas of people at every level of the organization (and to act and allow action on good ideas), and acceptance of a more open, transparent, and collaborative environment.

SharePoint - Web 2.0 or not Web 2.0?

With roots in document management, SharePoint provides for significant security configuration. While this should be a good thing, in practice it makes it too easy to secure content from general access. Wikis and blogs generally default to open access, and wikis generally default to open editing. This latter approach is better aligned with the philosophy of Web 2.0. You can do this with SharePoint, but you may have a more difficult fight with those who want to stick with access "on a need to know basis."

SharePoint TCO

Proliferation of SharePoint sites is also a common problem in organizations. It's easy to find yourself with dozens - or hundreds - of sites. And unless you know about them or they are referenced elsewhere, they remain hidden from view. Microsoft's response to this? Put in place a governance framework. Microsoft's web site has a whole set of documentation on governance for SharePoint. Of course with this you get added overhead and bureaucracy. Oh, and there's 3rd party commercial software available to help with this.

Which leads to the next issue with SharePoint: it is definitely NOT a "light" solution. Technically, Microsoft recommends development, test, and production environments; you'll need Active Directory, IIS, the .Net Framework, SQL Server databases, and antivirus software for the server. Microsoft kindly provides a sample deployment project plan for deploying SharePoint - 381 tasks requiring 129 days and people in 9 different roles. Organizationally, Microsoft recommends maintaining an ongoing staff of people for the roles of business analyst, creative designer, trainer, infrastructure specialist, developer, and architect.

SharePoint as Antagonist to the Flexible Enterprise

This may be obvious, yet I feel it still needs to be said: SharePoint only runs on Windows. In contrast, many other collaboration tools will run on Windows, Solaris, or Linux. Oh, and if you want integration with Microsoft Office, your users will need to be running Windows (and Microsoft Office).

Productivity Enhancer? Or Drain?

SharePoint's roots are as a document management system - a place to store your Word, Excel, Powerpoint files. Microsoft knows it has a cash cow in Microsoft Office, and it's not going to allow the product to be be put out to pasture without a fight. And Microsoft knows nothing better than how to fight. In this game, Microsoft is building hooks between SharePoint and Office - Microsoft makes it easy to save a file to a SharePoint site, to open and edit a file stored in SharePoint, and to save changes back to SharePoint; and your calendar, tasks, and contacts can be synchronized between Outlook and SharePoint (of course, if you want this latter functionality, you will also need an Exchange Server and Active Directory). Microsoft hopes this keeps you captive. If this were a good solution, so be it. But it's not.

When you click on a link, you expect to see content relating to the text of the link. But with Microsoft's solution, you get a popup window asking if you want to open or save the file that contains the content related to the link. Failure #4. Now I don't know about your experience with browsers, but I've found that opening documents in my browser (IE, Firefox, Opera, ...) is hit or miss. Sometimes it works. Sometimes it causes my browser to grab the CPU and not let go, sometimes it makes my browser greedy for RAM, sometimes my browser crashes. This has trained me to save all downloadable files to my hard disk, and then open them in their native apps. Failure #5. Of course when I'm done looking at the file and I move on, the file is still there, taking up disk space on my PC. I have to periodically empty the folder I've set up for these files - failure #6. And until I do this, these files increase the bandwidth, time, and storage space required by our corporate backup solution - failure #7.

Now let's compare SharePoint with wikis with respect to versioning. With SharePoint your content is in a file. If you want to make a change, you download the file, make the change, and upload it. If you want - and if you know how - you can have MS Word store a record of changes in Word documents. Excel has a change tracking feature, though it's somewhat crippled (e.g. it can't track formatting changes, when you use it some other features become unavailable...). PowerPoint doesn't have a change tracking feature. Additionally, when you save a file back to SharePoint, it doesn't delete the old version. So you could conceivably compare the versions side by side.

Using wiki applications, you write content directly on the page. If you want to make a change, you click an "edit" button, make the change, and click the "save" button. Most wiki applications keep both the old and new versions, and they make it easy for you to see what has been changed.

So it's not that you can't view content changes with SharePoint, it's just that it's so much more difficult than with wikis. Failure #8.

SharePoint as Virus Vector

One more issue to chew on: Microsoft Office documents can be carriers of malicious code, whereas wiki pages have much less risk. Microsoft includes "Forefront Security" with SharePoint, but why should you have to increase your risk, and install - and administer - even more software for your solution?

Bottom Line

If all you want is to enhance communication and collaboration in your enterprise, there is a plethora of tools available that could satisfy your requirements and protect you from all of the problems with SharePoint (for example, check out Atlassian Confluence or Mindtouch Deki). Don't make the mistake I've seen in other organizations - choosing SharePoint without understanding what they were getting into and what alternatives were available.

Consider yourself warned!