Tuesday, October 14, 2008

Moving Content from Site to Blog?

I'm starting to wonder if moving all, or most, of my content from web site(s) to a blog would work. The step is not as easy as it seems.
The question requires analysis and direct comparison between positive and negative sides of either type of content hosting and presentation. I'll try to list, ad hoc, the advantages and disadvantages of both and compare them.
I'm interested in your comments, too.

One of the main reasons I would use blog over a typical web site is search. Blogs tend to be searched much more frequently than a typical web site. Also, moving web site around does not help in that regard. An important thing to note is that the web site is hosted at a free host. Some of the drawbacks come from that fact alone. There is no active content. In fact, with Google offering Appspot active hosting with Python, that element does not weigh so much today but I haven't had the time to use Python on the web site yet.

Another important point is that I love Project Wonderful. I love the idea behind it and find it fair for both advertisers and publishers. It is similar to Entrecard, another very nice concept. But, PW does not work well with free-hosted sites. That may change in the future but right now it doesn't.

So, against these two main reasons I'm trying to list advantages of a web site built with HTML, JavaScript, and CSS. Here are some of the initial thoughts:
- navigational links
- formatting
- standardized links, templates
- ?
Hm, I can't really add much more to it. And, all of the "advantages" are not really holding true.

Navigational Links

Navigational links, meaning that every page has its URL and is easily converted to bookmarks and saved on desktops or linked from other web sites and/or locations, works well for blogs, too. It is exactly the same or even better with blog posts. Plus, they get sorted by different elements - by posting date/time and tags.
In addition to that, blog posts allow comments as a direct way of communicating with the audience. Something I always missed on my html pages until recently, when I built a contact form using Python. That solution is not transparent in a way that the comments from readers are not visible to others. These can be extremely useful sometimes. I receive some very good comments on the topics I write about and people come with interesting ideas, views, solutions, links... Hm... I'm on the blog for this one.


Formatting using CSS and having the whole page as a canvas is attractive. HTML pages can be customized with CSS, JavaScript, Java applets, Flash, embedded objects like music or video, etc. This can work well sometimes but also can be disastruous. Most of these can be embedded or adder to a blog post, anyway. So, unless there is some form of artistic expression, I'd say blog offers enough freedom for mixing different type of content.
There is CSS involved anyway in the creation of the blog but that links to the next point.

Standardized Links and Templates

By "standardized links" I mean links to pages, that appear on groups of pages. It can be achieved using templates and adding certain link elements to the template. Then it appears on all the pages built on this template. This can not easily be achieved with a blog.
I worked with so many different topics and my web site contains lots of different pages. I used different CSS styles for them to make them distinct from others. Also, the content was assembled over the years and styles changed, got updated, new ones were used for new things, etc. Just as it happens in real life.
So, templates would work with blog in case another blog site is started for each different topic. That's one solution.
Common links among different pages work in a bit different way. Each blog has a template that is used to set the look and feel of the blog site. All those template nowadays include different main sections displayed on the page. These sections can include link section as a pure HTML block and then this block can be set to contain links to some standardized posts/pages that lead further. This approach works well with setting a new blog site for each topic. In that way every site could have standardized links.


Another, quite important, issue is updating the content. Until recently, I was not even aware that blog post edits were so useful. I was aware of the feature but it was not readily available with the tools I was using to post and so I used it only rarely. Then I had to go to the blog site, find the post, select editing, fix the post and update it. But now, with an add-on for Firefox - ScribeFire, editing of previous posts gets incredibly easier. This tool shows the posts on the blog and allows easy editing of the posts. This puts blog posts at the same level to standard web sites. I'd say that updating content was the major advantage for HTML web sites. Obviously, not any more. It is such an insignificant issue now that both approacehes have this option. I got so used to editing posts that I even forgot to list the issue previously.

Active Content

Here I mean an engine behind the pages. Server processing, dynamically generated content, etc. Example would be ASP.Net, Python, PHP, and other server-side scripting/programming languages. Google offers free Python hosting and there are other providers offering other types of "active" hosting. This is something that is not readily available on a blog site. But, there might be workarounds. The workarounds depend on what is required for the dynamically generated content. The only real need I had before was the contact form and that is already handled by blog sites very well. Other content can be linked into posts, as stated previously, so the question remains on what the real usage would be for dynamic content. I assume, if there is a need for a dynamically generated content, these pages can be linked from the blog and kept at a separate, active hosted site. This question remains open while I find some real usage for active content. I mean, of course Facebook applications would not be built as blog sites. But it is hard for me to find other usage for active content. This is a consequence of using free hosting over years and getting burned whenever some site-specific features were used. I've changed so many different hosting environments, offering different abilities, different versions of PHP, different sets of options available that I gave up on most of those and kept it simple and clean with only the client-side scripting, if needed, and keeping even that to a minimum. HTML and CSS are still the core of my web pages. And these are beautifully handled by blog engines in a very simple and effective manner, eliminating the whole hosting and posting mess with ordinary web sites. With blogs, author can focus on content only.
Come to think of it, most of my content would be more appropriate to blog format that to web pages as I have them now. Especially the whole development section. That stuff gets outdated so quickly. There are new things emerging all the time. The whole content part gets rearranged over time that its cumbersome to maintain it as a web site. This is the very reason I very rarely update that portion of the web site these days. I prefer to post stuff to my IT blog and have it there, easily searchable, than to update my IT section of the web site.
What I could do is, maybe, to link different blog posts to a summary web page, that can be used as kind of Table of Contents or Index.

So, let me try to summarize these in a table, next to each other...

 Web SiteBlog
Project WonderfulDoesn't work
EntrecardDoesn't workWorks

custom providersWorks
availablen/a, maybe

Navigational Links (URL)

Formatting (CSS)
Works part of template;
Common Links (site index)Works
Site TemplatesWorksWorks, predefined by provider
Content Update


I don't see too many reasons to continue to use web site as opposed to blogs. Especially since Google discontinued the Pages project and is pushing with the Sites project. I still haven't migrated but, when the time comes, that might be a reason to move some web sites to a blog format instead of keeping them as web sites.
Another issue that prevents me from migrating right away is the shear amount of work required to move all the content to a new format. But, after listing the arguments pro and contra, I might pick one of the sites and start migrating the content slowly. I'm in no hurry. It could be an interesting project.

No comments: