Effectively Testing Reader Access To Your Blog

People reporting a problem with blog access / performance, in Blogger Help Forum: Get Help with an Issue, will be frequently advised to diagnose their problems using affinity / differential testing.

Some diagnostic advice starts with simple instructions to "clear cache, cookies, and sessions". Some people, alternately, advise "use a different browser" - and test as a reader. These different strategies, seemingly redundant, will frequently lead to different results.

When you test reader access to a blog, some experts will casually advise you to "use a different browser" or "use a second computer".

There are specific reasons why this strategy may or may not be successful, when part of affinity / differential testing. When you test blog access, you're going to see varying reliability - based on a number of browser and reader details.

There are multiple ways to test blog access, of owner vs readers.

Any experienced testing technician knows that the most reliable testing, in affinity / differential analysis, will use identical browsers, on identical and separate computers.

Very few blog owners will have use of a bank of identical computers, for testing. There are alternate possibilities, when identical computers can't be used.

• This browser, in the primary session - after "clear cache, cookies, and sessions".
• This browser, in a secondary session - aka "Incognito" / "Private" browsing.
• A different browser, on the same computer.
• The same branded browser, on a different computer.
• Any browser, on a different computer.

All of these details will be relevant, sometimes - though not always. The differences between "always" and "sometimes" will lead to some testers using incomplete testing techniques - and cause inconsistent results.

This browser, in the primary session - after "clear cache, cookies, and sessions".

The best way to avoid environment based inaccuracy is to re use the environment, sequentially. This approach requires more time - plus development of a testing script, to keep testing procedures consistent.

It is, however, the best way to avoid confusion from inevitable testing variations.

Using the same browser, in the same browser session, one can try using a different identity. This technique starts with the apocryphal instructions to "clear cache, cookies, and sessions".

This browser, in a secondary session - aka "Incognito" / "Private" browsing.

Some browsers support multiple sessions. In Chrome, a secondary session is provided as "Incognito" mode - and in Firefox, a similar (not identical) option is called "Private" browsing. The differences between the "Incognito" and "Private" features are significant - and can cause different testing results.

This blog, displayed in "Incognito" mode.



A different browser, on the same computer.

Each different browser will have differences in the browser itself. Plus, different add-ons and settings, on the different browsers, will produce differing results.

Having both browsers on the same computer will eliminate computer setup differences, present when multiple computers are involved.

The same branded browser, on a different computer.

If the branded browser, on the two computers, is maintained identically, there is a chance for consistent results. Having two different computers involved, however, may offset the consistency gained by using identical browsers.

Any browser, on a different computer.

This is the most inaccurate testing procedure, of the choices listed. Any difference between the browsers, or computers, can lead to inaccuracy.

The differences, in testing, involve multiple details.

• Login identity in use.
• Cookie filters, that block identity.
• Script filters, that block identity access.
• Browser add-ons, that may or may not be present.
• Browser brand and design differences.

Login identity in use.

This is the one difference that you intentionally need, to test the reader experience. In the primary session, you are logged in as the owner. You require at least one secondary session - where you are not logged in as the owner, to test your blog as a reader.

The secondary session is where the need for sequential session reuse - or use of a different browser and / or computer - becomes necessary.

Cookie filters, that block identity.

Many Blogger features - involving both the dashboard, and access to the blog - use cookies to determine identity and permissions. Cookie filters, inappropriately managed, can cause havoc with Blogger. As an example, consider commenting ability, and third party cookies.

Different browsers may have different cookie filter settings. In some cases, identity is not relevant, for testing as a reader.

If you are testing access to a private blog, though, reader identity - which is cookie based - will be essential. A cookie filter involved, with a private blog being tested, will cause problems.

Similarly, testing Google+ comments requires known identity - for both the blog owner and readers. With Google+, identity is essential, to guarantee consistent display of comments.

Script filters, that block identity access.

Many Blogger features - involving both the dashboard, and content in the blog - are JavaScript based. Script filters can cause havoc with Blogger.

Different browsers may have different script filter settings - and different browser brands may have completely different script filters.

Browser add-ons, that may or may not be present.

The Firefox browser does not have native script filters, so many computer owners who use Firefox will add NoScript.

NoScript is a very intense add-on, with a lot of options, and opportunities for confusion. If you were to use Firefox on two different computers, you would need to carefully synchronise NoScript settings on both computers, for reliable testing.

Firefox with NoScript is the best known example - but it's not the only possibility for confusion. Every browser can have script filters, which will make browser to browser testing comparison a challenge.

With Chrome, one can select each individual add-on to be present in the secondary session ("Allow in incognito") - and this will create uncertainty. Some advice to "try using a Chrome incognito window" will be successful, with other advice being useless - and the absence or presence of the necessary add-on will be one of the issues.

AdBlock, optionally included in incognito mode, will produce uncertainty in testing - and is a well known script block.



Browser brand and design differences.

Every different browser produces differences in displayed content. Even a formatting discrepancy can lead to difference in test results.

The end results.

Interpreting test results, based on comparison of different browser displays, will be a challenge for anybody trying to produce reliable conclusions. The most reliable results will come from testing using the same browser session, sequentially. This will start with instructions to "clear cache, cookies, and sessions" - a painful but necessary process.

---

Many #Blogger problems need to be diagnosed using repetitive testing, and affinity / differential analysis. People who don't understand organised testing will sometimes recommend testing procedures, such as use of different browser sessions - which will produce inconclusive results.

AutoSave, And Draft Mode Post Editor

Recently, we've been seeing a few reports, in Blogger Help Forum: Get Help with an Issue, suggesting more problems with Post Editor, in Draft mode.

I keep getting an error, when editing my posts.

An error occurred while trying to save or publish your post. Please try again.

I am editing Draft posts, some of which are fairly large.

This blog owner is discussing yet another facet of the Post Editor feature, AutoSave.

Early AutoSave Experience

Long ago, people would report a different problem, when composing posts.

When I compose my post, my typing is way ahead of what is displayed.

Blog owners, long ago, discovered that AutoSave, which applied to posts being composed before publishing, made their computers slow down. This made their on screen post content show noticeable delay, from their typing.

With newer and more powerful computers, and people who still type at the same speed, Post Editor slow down has become a thing of the past - but at a price.

With highway traffic engineering, a well known problem involves the regional effects of upgrading a local arterial street, to handle more traffic. This might improve traffic in your neighbourhood, but at the expense of another highway in the next city.

Similarly, upgrading the speed of your computer improves your Post Editor typing problem, but puts more load on the networks and Blogger servers. Thus we see the symptom, reported above.

An error occurred while trying to save or publish your post. Please try again.

Pre AutoSave Experience

As you compose a post, what you type is saved on your computer - and displayed in Post Editor. This lets you see what you are typing, in a "what you see is what you get" display. If you hit "Save", periodically, what you have typed gets saved to the Blogger servers.

Originally, many blog authors did not think to Save, when composing a post. Some would just type - then eventually Publish, when convenient. This technique created two problems.

1. The longer an author waited before Publishing, or Saving, the greater the chance that something would happen with the computer being used, causing loss of what was being typed. And the greater the catatrophe from the loss.
2. The longer the author waited before Publishing or Saving, the more work would be done by the Blogger servers, when the author finally did Save, then Publish.

Blogger added AutoSave to Post Editor, so the effects of Publishing massive amounts of unsaved post content would not affect Blogger resources so abruptly - and so less people would see their hard effort go down the drain.

Current AutoSave Experience

One known problem with AutoSave is that it generates load on the local computer, on the networks connecting to Blogger, and on the Blogger networks and servers - thus the slow typing problem, long ago.

Another problem is that it saves automatically (hence the name) - and for some people, who may have just cleared the contents of a post, AutoSave saving an empty post tends to cause a problem. The longer people work on pages or posts, without publishing, the greater the chance that this disaster may happen.

Unfortunately, having a more stable publishing process, thanks to the reverse effect of AutoSave, will just encourage people to take longer before Publishing or Saving. Thus the complaint.

I was working on my new post for weeks. Right in the middle of highlighting a section for deletion, AutoSave kicked in, highlighted the whole post, deleted the highlighted section, and saved an empty post. How do I get my post back?

And for this unhappy author, there can be no helpful answer.

Future AutoSave Prognoses

For a while, I've been suggesting that when possible, you should publish a post immediately, then continue editing your post after publishing - since AutoSave only affects post editing, before the initial Publish. Recently, I discovered that it may be possible to use Google Docs as a Content Management System, for long term post development.

A third possibility is that you compose your unpublished posts in HTML mode, instead of Compose mode. The effects of AutoSave, in HTML mode, are not as objectionable. Some of my posts, I might develop for a week or two before Publishing, using HTML mode. If you use this technique, and you include anchor links in your posts, beware of switching back and forth between Compose and HTML.

A fourth alternative, use of Microsoft Word instead of Google Docs, is known to cause problems with auto pagination and with various posts newsfeed accessories. We do not recommend use of Microsoft Word.

However you develop a post, the longer you wait before Publishing, the greater the chance that AutoSave will make you unhappy - either by sudden destruction of your post - or by contributing to the latest symptom.

An error occurred while trying to save or publish your post. Please try again.

Publish sooner, develop offline, or become a victim.

Tweak The Post Template, Only When Necessary

Occasionally, we see the query, in Blogger Help Forum: How Do I?

How do I change these captions? / Add this feature? / Remove specific components of this feature?

Conversely, we see in Blogger Help Forum: Something Is Broken

Why does this new Blogger feature not work in my blog?

These questions, in many cases, may be related. We can see the connection, when we look closer at how the changes are applied.

Many changes to our blogs, that are part of the comments / posts / post header / footer, are made in the post template.

The post template is an unobtrusive section in the blog template, that lets us change the blog template as we wish - while allowing Blogger to update the comments and posts code, as they add new features, or update existing features.

Blogger lets us change the post template, using "Configure Blog Posts".

Blogger provides the "Configure Blog Posts" wizard - and lets us change specific features in the post template.

The options in "Configure Blog Posts" do not satisfy everybody - and here is where many problems start. Some blog owners want features or selections that are not provided by "Configure Blog Posts" - but are part of the post template.

Some features have to be installed as post template tweaks.

To install these features, the blog owner uses the Template Editor, and tweaks the "Blog1" template widget.

Once the post template is tweaked, by the blog owner, the blog has a non standard post template. When Blogger applies their next post template update, to install or update a Blogger supplied feature, against a blog with a non standard post template, they have 3 options.

1. Overlay the entire post template, with their updated post template. The blog owner sees all tweaks previously made, suddenly vanish. Some of the owner applied features simply disappear, others stop working - with no explanation or warning.
2. Overlay specific portions of the post template, with their updated post template changes. The blog owner sees some tweaks previously made, suddenly vanish. Some of the owner applied features simply disappear, others stop working - with no explanation or warning.
3. Not install the updated post template. The new Blogger feature doesn't work - and the blog owner is left complaining about broken Blogger updates, while other blog owners are enjoying the new feature.

When Blogger upgrades the post template, what happens to your tweaks?

If Blogger updates the post template, and some owner applied features disappear or stop working, the blog owner can simply install the necessary tweaks, again. Having kept the notes, or code snippets, from the original install, many blog owners simply install everything again.

Unfortunately, if the Blogger post template changes were applied in the same post template section as the owner applied tweaks, the owner retained notes or code snippets may be out of date - and installing them again may break one or more Blogger supplied features.

Some post template tweaks can have effects outside the post template.

Some owner applied changes, if installed improperly, can affect other sections of the template, in general - and cause mysteries such as problems updating accessory gadgets, and problems using the Template Designer.

The end result is that owner installed post template tweaks must be made, selectively - and any Blogger changes, publicised or non publicised, may necessitate re install of any owner applied tweaks. Owner applied tweaks must be re installed, character by character - and frequently with the readers complaining about an unexpected change or broken blog.

The post template is actually another example of "well enough", for many blog owners.

---

Tweak The Post Template, When Necessary - And Only, When Necessary

Always Test Your Changes

Periodically, we see an anxious query

I just got an email from a friend

Your blog looks like crap.

What do I do now? Help! Oh yes, I think I tweaked the template a couple weeks ago.

So if you made the change to the template "a couple weeks ago", why did you wait until today, to find out from your friend that you have a problem?

Blogger Blogs are easy to work on. As easy as they are to work on, though, they still demand respect, and responsible practices are still relevant.

If you make changes, test your changes using different browsers.

Any time that you make a change to the blog, or even when you post a new article, check out the change, preferably using multiple browsers. When you test, you need to see the blog as your readers may see it - so prepare to logout and login a few times, to view changes then make adjustments.

If you have a second browser or computer, this would be an excellent way to use one - to stay logged in on one browser, and make changes much easier. Or, using a sandboxed browser is an alternate way to check what your readers see - you won't be logged in, from there.

Alternately, an online website display service may be useful.

When making template changes, setup a test blog and change there first.

If you're making changes to the template, consider setting up a blog for testing, and make your template changes there first. Blogs are free - Xanax isn't.

1. Setup a test blog.
2. Save the template from your production blog, to your computer.
3. Load the template, saved in Step 2, to your test blog.
4. Export posts from your production blog, then import them to your test blog. This gives you a real test bed.
5. Make changes, and test them, without worrying about what your readers see. They only see the production blog. If you mess up badly, go back to Step 3.
6. When you're happy with the test blog, save the template to your computer.
7. Load the template from Step 6 to your production blog.
8. Save the template copy from Step 2, as a fall back.
9. Wasn't that easier on the nerves?

Just copying the template won't give you a cloned blog.

Nowadays, and if you develop a template and decorate it using a lot of custom gadgets, merely copying the template from one blog to another may not leave you with an elegantly developed blog.

Right now, there is no procedure for backing up or restoring gadgets. If that's a problem, you develop the template, then transfer the comments, posts, and URL to the newly developed blog.

This is a bit more work, but it will preserve your gadgets.

1. Setup a test blog.
2. Save the template from your production blog, to your computer.
3. Load the template, saved in Step 2, to your test blog.
4. Export posts from your production blog, then import them to your test blog. This gives you a real test bed.
5. Make changes, and test them, without worrying about what your readers see. They only see the production blog. If you mess up badly, go back to Step 3.
6. When you're happy with the test blog, transfer the existing comments, posts, and the URL to the new blog.
   • Extract the comments and posts from the existing blog, to an XML file.
   • Import the XML file to the new blog, and publish all posts not already handled in Step 4.
   • Re publish the existing blog to a new URL.
   • Publish the new blog to the publicly known URL.
   • If you have administrators / members / readers, you'll have to add them to the new blog.
7. Save the old blog, published to the new URL, as a fall back.
8. Wasn't that slightly easier on the nerves?

And of course, in both cases, backup the blog and the template, before and after making any major changes.

Don't wait for your friends to complain.