Friday, July 25, 2008

The Post Editor And HTML

Most web pages that you will view on the Internet are written in HTML.

HTML, or Hypertext Markup Language, was designed long ago to enhance simple text, giving it ability to display more than simple letters, numbers, special characters, etc. What you're looking at is mostly simple text. Here, on the other hand, is an example of bold text. And here, italicised text. And here, red text. Interested yet?

Here's how I coded the above paragraph in HTML:

Most web pages that you will view on the Internet are written in HTML.<br /><br />HTML, or Hypertext Markup Language, was designed long ago to enhance simple text, giving it characteristics beyond simple letters, numbers, special characters, etc. What you're looking at is mostly simple text. Here, on the other hand, is an example of <span style="font-weight:bold;">bold text</span>. And here, <span style="font-style:italic;">italicised text</span>. And here, <span style="color:rgb(255,0,0);" >red text</span>. Interested yet?


Wednesday, July 23, 2008

Blogger and Entry of Sensitive Data

Security awareness, in almost every feature of every computer application, operating system, and security program, is reaching an intense level. Any time that you enter a password, don't be watching the screen and counting the number of "*" or "#" characters displayed there, expecting the count to match the number of characters you know that you put in the password.

Just in case there's somebody standing behind you, shoulder surfing your password entry process, a masked password of "n" number of characters won't necessarily be displayed as "n" number of "*" or "#" characters on the screen.

Blogger is part of the paranoia, too. In various places where Blogger accepts entry of a password, after you hit "Enter" or "Save", the number of "*" may change. This is to keep people from walking up to the screen, counting the number of "*" displayed there, and guessing that 7 "*" could be your wife's name. Or maybe the car that you drive. Or ... (I'm sure that you get the picture by now). When you see the number of "*" suddenly reduced, if you don't pay close attention, you might think that it's truncating the entry.

The above describes interactive entry of a password, after it's been set in a database. In one case, FTP password entry, this appears to be the case when you're setting the password for accessing the host server, for later use when you publish your blog.

As you enter a password, keep the count in your head. Don't be expecting to see the count verified on the screen, before or after you hit "Enter", consistently.

>> Top

Tuesday, July 22, 2008

Separating Your Identities

If you've been blogging for a while, you probably have a small collection of blogs. Some blogs may deal with your personal life - maybe your family life, hobbies, political or social activities. Other blogs may deal with your professional life. Sometimes, you may consider that the two (or more) personalities should be kept separate. Maybe your personal life would conflict with professional issues, or maybe your politics need to be kept separate from your family.

The safest and most effective way to keep the two separate would be to have separate Google accounts. If you're an experienced blogger, though, you know that's not an easy task. If you have access to only one computer, that's a recipe for disaster.

Short of having separate accounts, consider two isolation techniques.
  • Remove the "About Me" page element from the sensitive blogs. You can have your own version of "About Me", with very little trouble, if you wish.
  • From the dashboard, Edit your profile, and change the list linked from "Show my blogs", to not show the sensitive blogs.
These are two simple techniques that, properly done, will at least prevent the casual reader from connecting the wrong blogs with your different identities.

>> Top

Help Your Readers Search Your Blog

When your blog gets larger, you'll want your readers to be able to find the content easier - sometimes using more detail than can be found in the Archives index.

You can generally use Labels for a more comprehensive index of the blog contents - but both labels, and titles, index the posts based on your vision of the blog. What if you want your readers to view your blog, on their terms?

This is where the Navbar, with its search box, becomes useful.

Sunday, July 20, 2008

Making An Easier 3 Column Template

Making a 3 column template is not as difficult as many bloggers would lead you to believe. I don't recommend this as a cookbook exercise, though - you have to understand what you're doing. It's simply not too hard to understand, when you look at it closer.

You simply look at how the columns are setup.

  • Column A, floating left.
  • Column B, floating right.

And split either column (and it's your choice).

  • Column A, floating left.
    • Column A1, floating left.
    • Column A2, floating right.
  • Column B, floating right.

or

  • Column A, floating left.
  • Column B, floating right.
    • Column B1, floating left.
    • Column B2, floating right.

Generally, the choice would be to have the posts ("Main") in the middle of the blog, with one sidebar one the left, and the second on the right. This would leave you splitting the Main column into Sidebar2 and Main2. The asymmetry of this always bothered me.

  • Sidebar1, floating left.
  • Main1, floating right.
    • Main2, floating left.
    • Sidebar2, floating right.

Aside from the asymmetry, with one sidebar defined as a peer to the main column, and the second defined as a portion of the main column, making the widths of Sidebar1 and Sidebar2 identical was an exercise in futility.

But, think outside the box. What if we put both sidebar columns on the same side? Then, we simply split the sidebar column into 2 halves, and leave the main column alone.

  • Main, floating left.
  • Sidebar, floating right.
    • Sidebar1, floating left.
    • Sidebar2, floating right.

This arrangement is simpler than you would think.

Here, as just previously, we'll use a Sand Dollar template, which is a stretch type.

Starting with the Header code.

div#main {
float:$endSide;
width:66%;
padding-top:30px;
padding-$endSide:0;
padding-bottom:10px;
padding-$startSide:1em;
border-$startSide:dotted 1px $bordercolor;
word-wrap: break-word; /* fix for long text breaking sidebar float in IE */
overflow: hidden; /* fix for long non-text content breaking IE sidebar float */
}
div#sidebar {
margin-top:20px;
margin-$endSide:0px;
margin-bottom:0px;
margin-$startSide:0;
padding:0px;
text-align:$startSide;
float: $startSide;
width: 31%;
word-wrap: break-word; /* fix for long text breaking sidebar float in IE */
overflow: hidden; /* fix for long non-text content breaking IE sidebar float */
}

and below, the Body code ...


<div id='main-wrapper'>
<b:section class='main' id='main' showaddelement='no'>
<b:widget id='Blog1' locked='true' title='Blog Posts' type='Blog'/>
</b:section>
</div>

<div id='sidebar-wrapper'>
<b:section class='sidebar' id='sidebar' preferred='yes'>
<b:widget id='BlogArchive1' locked='false' title='Blog Archive' type='BlogArchive'/>
<b:widget id='Profile1' locked='false' title='About Me' type='Profile'/>
</b:section>
</div>

And change that to the Header code ...

div#main {
margin-top:20px;
margin-$endSide:0px;
margin-bottom:0px;
margin-$startSide:0;
padding:0px;
text-align:$startSide;
float: $startSide;
width: 55%;
word-wrap: break-word; /* fix for long text breaking sidebar float in IE */
overflow: hidden; /* fix for long non-text content breaking IE sidebar float */
}
div#sidebar {
float:$endSide;
width:40%;
padding-top:30px;
padding-$endSide:0;
padding-bottom:10px;
padding-$startSide:1em;
border-$startSide:dotted 1px $bordercolor;
word-wrap: break-word; /* fix for long text breaking sidebar float in IE */
overflow: hidden; /* fix for long non-text content breaking IE sidebar float */
}
div#sidebar1 {
float:$endSide;
width:45%;
padding-top:30px;
padding-$endSide:0;
padding-bottom:10px;
padding-$startSide:1em;
border-$startSide:dotted 1px $bordercolor;
word-wrap: break-word; /* fix for long text breaking sidebar float in IE */
overflow: hidden; /* fix for long non-text content breaking IE sidebar float */
}
div#sidebar2 {
float:$startSide;
width:45%;
padding-top:30px;
padding-$startSide:0;
padding-bottom:10px;
padding-$endSide:1em;
border-$endSide:dotted 1px $bordercolor;
word-wrap: break-word; /* fix for long text breaking sidebar float in IE */
overflow: hidden; /* fix for long non-text content breaking IE sidebar float */
}


Making the additional header rule sets ("Sidebar1" and "Sidebar2") wasn't difficult. Sidebar1 and Sidebar2 are simply mirrors of each other, and each has width of 45% (inside its parent Sidebar), allowing for a 10% margin between the 2. Note that 10% of 40% = 4% of the total width - and the float between Main and Sidebar = 5% of the total width - so that's pretty symmetrical too.

Since both Sidebar (inside its parent Content) and Sidebar1 (inside its parent Sidebar) both float to the left, they use the same basic rules. I just copied the ruleset for Sidebar, and renamed it as Sidebar1. I made a second copy of Sidebar, inverted its left and right ("start" and "end") variables, and named that Sidebar2.

and again below the Body code ...

<div id='main-wrapper'>
<b:section class='main' id='main' showaddelement='no'>
<b:widget id='Blog1' locked='true' title='Blog Posts' type='Blog'/>
</b:section>
</div>

<div id='sidebar-wrapper'>
<div id='sidebar'>
<b:section class='sidebar' id='sidebar1' preferred='yes'>
<b:widget id='BlogArchive1' locked='false' title='Blog Archive' type='BlogArchive'/>
<b:widget id='Profile1' locked='false' title='About Me' type='Profile'/>
</b:section>
<b:section class='sidebar' id='sidebar2' preferred='no'>
</b:section>
</div>
</div>


Here, too, a fairly simple task.

I changed

<b:section class='sidebar' id='sidebar' preferred='yes'>

to

<b:section class='sidebar' id='sidebar1' preferred='yes'>

and added

<b:section class='sidebar' id='sidebar2' preferred='no'>

And, added

<div id='sidebar'>
...
</div>

surrounding sidebar1 and sidebar2.

<div id='sidebar-wrapper'>
<div id='sidebar'>
<b:section class='sidebar1' id='sidebar' preferred='yes'>
<b:widget id='Profile1' locked='false' title='About Me' type='Profile'/>
</b:section>
<b:section class='sidebar2' id='sidebar' preferred='no'>
<b:widget id='BlogArchive1' locked='false' title='Blog Archive' type='BlogArchive'/>
</b:section>
</div>
</div>


And, I'm done.

>> Top

Saturday, July 19, 2008

Less Traffic To Our Blogs?

I've been advising bloggers about an essential and sensitive subject - getting more traffic to their blogs - for years. Such a simple activity - post accurate, relevant, and useful articles - and advertise responsibly - the search engines will see you - and the readers will come. But there's a problem here, similar to the chicken and the egg paradox.
If more search engine visibility depends upon more readers, and more readers depends upon better search engine visibility, how do you start the process?


Where did the first chicken come from, anyway?

With Blogger, there is a way around the paradox - the "Next Blog" link, driven by the "Recently Updated Blogs" list. When you post to your blog, your blog goes onto the "Recently Updated Blogs" list. People using the "Next Blog" link access the RUB list, and there they are reading your blog. The more that you post, the more readers you get from "Next Blog".

But, there's a limitation here. Recently, Blogger started making the "Next Blog" link more "family friendly". This effort, prompted by thousands of complaints from people tired of seeing material not suitable for minors - or in some cases - for anybody - was welcomed by many bloggers. Many malicious or unsuitable blogs, detected as spam blogs - simply disappeared from visibility.

But this effort has side effects, not welcomed by all bloggers. The Google spam blog detection is fuzzy, and it's prone to both false negative detection and false positive detection. The former means that not all spam blogs will be detected, and the latter means that not all blogs detected will be spam. This is similar to known problems with automated locking and / or deletion of spam blogs, and with TOS actions against accounts used for setting up and maintaining such blogs.

In my opinion, locking out spam blogs, from "Next Blog" links or from the Recently Updated Blog list, can be tuned to produce false positives, and eliminate false negatives. Locking and / or deletion of blogs, on the other hand, must be much more carefully balanced, as too many false positive detections will lead to too many complaints from owners of blogs falsely locked or deleted. Check the normal forum activity, in GBH: Login Issues and GBH: Publishing Trouble, if you don't understand this problem.

Exclusion of a non spam blog from "Next Blog" links or from the Recently Updated Blog list will be much easier to get away with, even with egregious false positive detection, simply because many blog owners don't know or care about "Next Blog" and the Recently Updated Blog list, nor is it easy to measure "Next Blog" activity. With that in mind, Blogger will likely tune their scanning with the goal of eliminating false negatives - excluding all malicious blogs from "Next Blog" and the Recently Updated Blog list - and there will be many more false positives.

So enjoy the cleaner and more useful "Next Blog" link, but note that there may be a price.

>> Top

Thursday, July 17, 2008

Google Webmaster Tools And Web Crawl Logs

One of the most useful selections in Google Webmaster Tools, that your readers will appreciate, is the Web Crawl logs. These logs show various problems that your readers might encounter, as they surf through your blog.

Of these errors, the easiest for you to correct, and possibly the most consistently useful, will be those listed in the "Not found" log.

These are actual coding errors, somewhere in the blog posts. My readers probably find these, from time to time. They shouldn't, though.


So, click on the link "Download this table". That downloads the display, into Excel. Then, copy and paste the first column. That gives me a list.
URL
http://blogging.nitecruzr.net/2...evil-blogs.html
http://blogging.nitecruzr.net/2005/05/troubleshooting-network-neighborhood.html
http://blogging.nitecruzr.net/2006/07/Hyperlink
http://blogging.nitecruzr.net/2006/07/corrupted-templates.html
http://blogging.nitecruzr.net/2006/08/blogger-beta-design-deficiencies.html
http://blogging.nitecruzr.net/2006/08/blogger-beta-problems.html
http://blogging.nitecruzr.net/2006/2007/publicisingyourblog%3E
http://blogging.nitecruzr.net/2007/06/template-corruption-components-missing.html
http://blogging.nitecruzr.net/2007/11/custom-domain-publishing-and-404-error.html.
http://blogging.nitecruzr.net/2008/05/google-custom-domains-two-step-
http://blogging.nitecruzr.net/feedReaderJson

I'm not so sure about the last entry, but the first 10 look resolvable.

>> Top

What FTP Is - And What It Isn't

We see this query in the forums almost weekly
I need the address for the Blogger FTP server.
or
How do I FTP my updates?
or
Why do I get nothing but FTPConnectionClosed when publishing?

Coming from a normal web site publishing environment, you're used to composing your web site offline, then publishing the web site by sending the updates, using FTP, to the host server for the web site. That's similar to what you do with a Blogger blog, but with one major exception.

When you use FTP to publish a blog, Blogger is the FTP client. There is no Blogger FTP server. You still use the plain old Blogger Post Editor (with one rare alternative) to compose the posts. FTP Publishing under Blogger simply lets you publish the blog, instead of to BlogSpot, to a third party provided host server, outside the BlogSpot name and physical space.


(Update 2010/03): And now, even FTP Publishing is no more.

>> Top

Tuesday, July 15, 2008

Path Variances When Publishing By FTP

Occasionally, settings which identify the location of your blog, relative to the FTP folder on the server where your blog is hosted, may change. Some changes may be related to changes at Blogger, other changes may be related to changes in the server itself. Symptoms may vary, but will typically mention denied access, or missing content.
Access is denied.
Requested action not taken: file unavailable.
The system cannot find the path specified.


Most frequently, the change required will be the relative root designation. The change will probably involve the main publishing path ("Settings" - "Publishing" - FTP Path) and / or the archives path ("Settings" - "Archiving" - Archive Path).
  • If the current value is ".", change it to "/".
  • If the current value is "/", change it to ".".
  • If the current value is, for instance, "blog", change it to "/blog".
  • If the current value is, for instance, "/blog", change it to "blog".


Publishing by FTP, to remote (third party) servers can be a challenge, and one of the unpreventable challenges will be the unpredictability of the third party maintenance policies. Try and be aware of changes being made, and encourage the support staff for the servers to provide you some documentation describing changes, when possible. Barring that, get used to trying these changes, on your own, when things stop working.

And, try to resist the temptation to blame Blogger for every problem. Some problem will require you, or you and the server support staff, to sort.

>> Top

Monday, July 14, 2008

Diagnosing Problems With Custom Domains - Case Study #8

Some time ago, I noted a technique being used by Blogger to combat the spread of spam blog referrals, which was creating some inconvenience for legitimate blogs using custom domains.

That inconvenience seems to continue, even today. A prettier display, but the same inconvenience.


This isn't good for your readers - nobody wants to surf to possibly malicious content - intentionally or otherwise. Nor is it good for your search engine reputation - this extra page will stop the spiders cold. Check your Google Webmaster Tools Logs if you see this one day, if you don't believe me.



Let's look at the browser logs for myblog, and mydomain.


7/14/2008 09:24:54 Trying http://myblog.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Date: Mon, 14 Jul 2008 16:24:56 GMT
Expires: Mon, 14 Jul 2008 16:24:56 GMT
Cache-Control: private, max-age=0
Content-Length: 3473
Content-Type: text/html
Server: GFE/1.3
Connection: Close

Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Date: Mon, 14 Jul 2008 16:24:58 GMT
Expires: Mon, 14 Jul 2008 16:24:57 GMT
Cache-Control: private, max-age=0
Content-Length: 3473
Content-Type: text/html
Server: GFE/1.3
Connection: Close


Neither redirect contains the new location, so the search engines won't update their records to indicate your new custom domain. That's not going to give your new URL any reputation at all.

Compare that with the log for this blog, "bloggerstatusforreal.blogspot.com".


7/14/2008 09:30:01 Trying http://bloggerstatusforreal.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://blogging.nitecruzr.net/
Content-Type: text/html; charset=UTF-8
Date: Mon, 14 Jul 2008 16:30:04 GMT
Expires: Mon, 14 Jul 2008 16:30:04 GMT
Cache-Control: private, max-age=0
Content-Length: 212
Server: GFE/1.3
Connection: Close


See the "301 Moved Permanently" here?

HTTP/1.0 301 Moved Permanently
Location: http://blogging.nitecruzr.net/


That's where the search engines pick up my new URL - "blogging.nitecruzr.net". And that's one of the benefits of having a properly operating custom domain.

>> Top

Sunday, July 13, 2008

Server Changes At GoDaddy, And FTP Publishing Problems

Publishing a Blogger blog by FTP, to a third party server, presents a challenge, may I risk making an understatement. Bloggers choosing to host their blogs externally have traditionally been subject to numerous experiences, not all good. One of the least enjoyed is possibly seeing the advice
Your publish is taking longer than expected. To continue waiting for it to finish, click here.


It appears that a recent server change (some time in the last 3 to 6 months) at GoDaddy may be at least partially responsible for some of the FTP Publishing experiences, such as the latter advice.

GoDaddy appears to have 3 server configurations right now.
  1. Linux, "hosting configuration 1.0", PHP 4.x.
  2. Linux, "hosting configuration 2.0", PHP 5.x.
  3. Windows, ASP.Net 1.1, IIS 6.0 .


In at least one case, service moved from Linux configuration 1.0 to configuration 2.0 appears to be related to the symptom discussed above.

According to the Original Poster in the thread linked above, service migrated from Linux V1.0 to Linux V2.0 is not reversible. That's not an unusual restriction for any IT service methodology. Unfortunately, that left him with the sole option of moving to the third configuration, hosting on a Windows platform. People changing from Linux to Windows server hosting (or vice versa) should be aware of some significant technical differences between the two platforms, such as (but probably not only) differences in case sensitivity and in path description.

>> Top

Friday, July 11, 2008

New Blogger June 2008 - Displaying HTML

For years, bloggers have complained about the inability / complexity of displaying HTML code in a blog post. Being told to display "<" as "&lt;" and ">" as "&gt;" confuses many folks - it's not easy typing "&lt;" and "&gt;" - and it's still harder to type "&amp;lt;" and "&amp;gt;", which is how you display "&lt;" and "&gt;", respectively.

Don't ask me to go any deeper.

Anyway, with New Blogger June/July 2008, comes a new setting, under Post Options.
Interpret typed HTML.


The phrasing there is confusing, to me anyway. What it means, in effect, is that typing "<" will display "<" and ">" will display ">", without any work from us, with "Interpret typed HTML" selected for that post. No more having to type "&lt;" and "&gt;".

In other words, in a single post, you'll be able to copy and paste raw HTML and have it display as raw HTML.

This feature may hasten the elimination of the toolbar in "Edit HTML", and make that mode still less usable for composing content. And this should make the New Blogger June/July 2008 Post Editor more attractive, at least slightly so.

>> Top

FTP Publishing and the Complexity

Blogger is constantly fixing problems with FTP publishing, and more problems come up at the same time. Anybody who says that there is one problem, and waits for the one problem to be fixed, is assuring that the one problem won't ever be fixed.

FTP Publishing involves scripted communication with hundreds of different "servers" (with Blogger acting like a "client") all over the world. Each different server, being owned by a different company, will be different from each other server; and each server will have different problems, which make the the Blogger scripts progressively more complex. Sometimes, changes by the server owner to some, though not all servers, may make a difference.

And just because you were able to publish to your blog last week, that doesn't assure that you will be able to publish this week. Nor does it assure that somebody else will be able to publish today.

What all of this means is that anybody who insists that his problem has to be fixed by Blogger, and waits while Blogger fixes it, will possibly be waiting a good long time. Some problems will involve you, and some will involve your server host support team. Each problem really should be attacked by three parties, working together.

When you have problems, checking your settings, and verifying them against updated instructions from your host support team, is a good place to start. Maybe a look at the server access logs is a good idea too.

Just don't post your complaint, go about your daily business, and wait. Get to work, and get involved.

>> Top

Diagnosing Problems With Custom Domains - Case Study #7

Google Apps, which I originally identified in my second custom domain case study, and later in a separate article, Custom Domain Publishing, And Google Apps, is what I shall call a Web Services Aggregator. Google Apps gives us the ability to combine a Blogger blog using a non-BlogSpot URL in a domain with other Google and non-Google services.

Google Apps is not the only web services aggregator that we have identifed recently. Yahoo provides a similar setup.

Let's look at a Yahoo Web Services setup, using a hypothetical domain, "mydomain.net" (name changed here to protect the unfortunate).

First, let's dig the DNS records for the primary domain "mydomain.net".

 ;; QUESTION SECTION:
;mydomain.net. IN A

;; ANSWER SECTION:
mydomain.net. 1200 IN A 68.180.151.21
mydomain.net. 1200 IN A 68.180.151.22
mydomain.net. 1200 IN A 68.180.151.23
mydomain.net. 1200 IN A 68.180.151.24
mydomain.net. 1200 IN A 68.180.151.25
mydomain.net. 1200 IN A 68.180.151.26

p2w12.geo.sp1.yahoo.com (68.180.151.21)
68.180.128.0 - 68.180.255.255
Yahoo


Next, the "www" alias "www.mydomain.net".

 ;; QUESTION SECTION:
;www.mydomain.net. IN A

;; ANSWER SECTION:
www.mydomain.net. 600 IN CNAME ghs.google.com.
ghs.google.com. 40765 IN CNAME ghs.l.google.com.
ghs.l.google.com. 300 IN A 72.14.207.121


You'll have no problem with publishing to "www.mydomain.net", as the primary URL for "mydomain.net". I don't think that Yahoo Web Services provides an option to "Redirect mydomain.net to www.mydomain.net.", though.

Yahoo provides 6 servers, in contrast to 3 provided by Google. To date, nobody has succeeded in configuring the 6 Yahoo servers to address anything but Yahoo content. This makes Yahoo Web Services useless for using the primary domain in a Google Custom Domain.

>> Top

Wednesday, July 09, 2008

Google Webmaster Tools And Label Searches

As a publisher of a Blogger blog, besides publishing articles, you have to know how those articles are being read.

Just as knowing who is reading your blog, you need to know who is indexing your blog. The Google Search Engine, which feeds 2/3 of the known major search engines, provides Google Webmaster Tools, so we can monitor how well our blogs are being indexed.

Tuesday, July 08, 2008

Custom Domain Setup, Your Blog, and Your Readers

Periodically, someone interested but uncertain asks about the practical effects of publishing their blog to a custom domain.
Will all the posts (the comments, the customised template, ...) be the same?
or
Will my readers be able to find my blog?
or even
Will I lose Page Rank, and if so, how long?
These are all valid concerns.

Publishing your blog to a custom domain is pretty much like publishing it to another BlogSpot URL, except you end up with two (maybe 3) URLs, each of which will work equally well.
  • The BlogSpot URL.
  • The primary URL for the domain.
  • A possible secondary URL for the domain.


There's no visible change to the content - it simply republishes to the new (non-BlogSpot) URL. If you want to go back to normal publishing, you republish to BlogSpot. Simple?

Since the BlogSpot URL continues to work, everybody who has the BlogSpot URL bookmarked can continue to access the blog, transparently. You'll experience a brief loss of page rank, but you'll still get some traffic from your established readers, and from the search engines, and other robotic services.

You will have to update your membership in external services, such as search engines and similar robotic processes.

If you are vigorously attentive to the needs of your readers, and external services, your search engine reputation / Page Rank will pick up, somewhat faster than you acquired it originally. And if you publish content and update the blog at the same rate as before you got the custom domain, your search engine reputation / Page Rank will keep on going up, after it has regained its former level. And that's what a custom domain will do for you.

>> Top

Monday, July 07, 2008

FTP Publishing and Network Issues

I've been discussing FTP Publishing, and comparing it to native BlogSpot and Custom Domain publishing, for many months. Besides the functionality and style differences, there are network issues - several key differences between custom domain and FTP publishing, which cause problems. The problems will come and go, and will randomly affect a different segment of the blogger population each time.

  • Authentication. Blogs published by FTP are copied to servers with differing, and not always appropriately maintained, authentication policies.
  • Control. Blogs published by FTP are copied to servers that aren't owned or supported by Google.
  • Distance. Blogs published by FTP are copied to servers that are distant from Google.
  • Dynamics. Blogs published by FTP are published statically. Each time a post is published, the entire blog is copied to the distant server.
  • Overall. Looking at these issues, what should we expect?


Authentication
Authentication, the process of establishing your identity, and your right to access a given host server, isn't a simple process. Modern security precautions contribute to problems with establishing an authenticated FTP connection.

When you publish your blog to a Google server, you're already authenticated. This is simply not an issue.

Control
There are hundreds of servers, each with a different owner, that are used for FTP published hosting. Each server, with a different owner, will be setup and maintained differently. Sometimes, a server owner may even change the configuration on some, though not all, servers. Even though any single detail of the setup or maintenance, of any server, can affect the ability of Blogger to communicate with that server, Blogger has no way of knowing what problems it may face at any time. Any given server, that was successfully published to yesterday, may change at any time. Some controls may depend upon documentation by Blogger, which however benevolent the intent, simply won't be 100% reliable.

With blogs published to a Google server, the entire publishing process is controlled and supported by Google. Every detail of each server is predictable. This makes publishing to a Google server much more reliable.

Distance
The hundreds of FTP published host servers are located all over the world. Besides the ownership factor, the distance factor is different for each server. A constantly changing distance (and network speed) between the Blogger servers and the FTP publishing hosts servers makes for a challenge, and ever varying stability.

With blogs published to a Google server, the entire publishing process is local. Both Blogger and BlogSpot / Google servers are on the same network, again owned and supported by Google. This makes publishing through the Google network much more reliable.

Dynamics
When you publish a blog using FTP, you're doing static publishing. The entire blog is copied from the Blogger server to the FTP publishing host server.

Most Blogger blogs have Layouts templates and are published dynamically. Do you remember the Spinner of Death? For most of us, it's but a distant memory, as our publishing process involves each blog post, dynamically. If you publish or update 1 post, that's all that gets published, and that only when the post is initially referenced. If you update the template, each post is, again, published when it is referenced.

This lets you, the blog owner, get on with your life and work on the next post, while your readers initiate the actual publishing of the posts. The older posts don't even get republished at all, if they aren't needed (read by the blog readers). With the majority of bloggers using Layouts templates and dynamic publishing, you'll find that Blogger resources will be allocated for that.

When you publish a blog using FTP, the entire blog gets copied to the FTP publishing host server, each time that you publish a post, or each time that you update the template. Many blogs published by FTP are commercial in nature, making the average blog larger (you have to pay for blog hosting, and larger blogs are generally more profitable), and constantly growing even larger still. FTP publishing may be done from less Blogger servers too, increasing the overall workload on the specific servers used for that task.

Absolute size * ever increasing size * the necessity of copying the entire blog each time you publish * possible resource limitations makes static publishing a significant problem.

The Overall Effect
Taking these issues together, do you not see a problem? Combining authentication issues * lack of control * distance and network issues * static publishing issues, produces inevitable results.
  • Speed. You never know how long a blog is going to take to publish, at any time.
  • Stability. You never know if a blog is even going to publish successfully, at any time.


But wait - - there's more.

One of the challenges of FTP publishing is the diagnostics (or lack thereof) when publishing. If you can use an FTP client interactively sometime, watch the FTP log as you copy a file. You'll see a command or two when the copying process finishes, and a response from the FTP server when the copying finishes.

What if the FTP server simply stops responding? This will happen, and the client server (or Blogger script) has no way of knowing when this happens. At any time, if the script has not finished a copy, there's no definitive way to tell if the script (the copy process) will ever finish. Combine the speed and stability issues, and how do you know if an FTP copy process will be successful?

The Blogger script can only estimate how long the publishing should take, run a timer, and stop when the time expires. If the timer expires before the copy finishes, the copy is aborted, and your publishing doesn't complete. Or, you watch the Spinner Of Death for an eternity, before giving up.

Watch It Spin.

Small wonder that Blogger Support would prefer that more people publish to Google servers.

>> (Update 9/4): Besides the many details discussed above, there are two newly discovered tweaks, which have provided relief to some.

>> Top

Saturday, July 05, 2008

LinkList + Feeds = Blogger BlogList

When we want to connect our blogs to our friends blogs, and vice versa, the first thing we think about is a linklist. Taking a basic list, and attaching a link to each list member, gives a nice structured list of links, called in some cases a BlogRoll, and called by Blogger a LinkList. That's simple, and that's boring.

So Blogger went one better, replacing the links with blog feeds, and voila - the BlogList. For each LinkList entry, you provide a caption, and a link (URL). For each BlogList entry, you provide only a URL. Blogger does the rest, and you have a list of feeds.

You can display the feeds in several different formats. For each feeds, you can choose to display
  • The FavIcon of the blog.
  • Title of most recent item.
  • Snippet of most recent item.
  • Thumbnail of most recent item.
  • Date of last update.
THis gives you a nice set of choices what you want your BlogList to look like.

Want to see one in action? Look at the bottom of my sidebar, for my current BlogList (subject to change).
  • Roberto's Report.
  • Blogger Developers Network.
  • Blogger Error Codes.
Use your imagination, and enjoy the results with your readers.

>> Top