Abandon ship, time for a new website editor

I have taken the plunge and decided to swap website content editor.

Right from when I first created our Holiday Gite website in 2004 I have been using IBM's Rational Application Developer to design, prototype, edit and publish the website. Its had the advantage that I can obtain it through work, it was fairly easy to use, had good preview features, and what I really liked was the templating and site structure editor that meant that once I'd taken several iterations to settle on a website design that I liked and worked in different browsers I could then just write the content and WebSphere Application Developer ensured that this was applied to all pages and the site navigation structure was all automatically built for me.

However this ease of use came with the overheads of Eclipse which being Java based meant it could take a while to launch on my PC, but more worryingly it seemed to stop working in June 2012 when I installed a patch version to the editor and found that the website navigation links all disappeared from the website.

Since I had "got the website working again" (by manually having to edit all the website pages and cut and paste in the HTML for site navigation links) things stayed like that for a while.

Wind the clock forward to December 2012 when I wrote of getting the website content translated into French through Task Panda and I had a reason to want to fix the errant website, I needed to create a French language version of the site.

And there things slumbered through 2013, there were times when I looked at the website editing problem, tried to fix it, but got nowhere (and you can tell that this wasn't my top-most priority).

I tried upgrading from version 8.0 of Rational Application Developer to version 8.5, I then tried version 9.0, and in each time I couldn't get the site structure to build properly and automatically like it had done from 2004 through to 2012.
I tried creating a new website from scratch using the scripts and template pages I had in the main website, I stripped these back to bare bones, and rewrote them and the best I ever got was to get the top level navigation menu HTML to build automatically but the rest, the sub-pages and sub-sub-pages, all never appeared.

So with the turn of another new year I decided to give up and seek out a new website editor, ideally giving me similar features to what I was used to, also wanting the same price point (free or near-free), and something that I could import the existing site into without major change.

As a Google or Wikipedia search will reveal there are plenty of website editors out there, I've tried eclipse, KompoZer, Sea Monkey, I looked at Coffee Cup, Komodo Edit, online website editors like Silex, SnapEditor and Maqetta.

Phew, a lot of editors.

And I have settled on one, and I am now using it.

Blue Griffon

Its based around Firefox as the rendering engine so is up to date with HTML standards, and basically through a series of complex Javascript it provides a tabbed interface to view, edit and preview web pages. The basic product is free but various plugins such as the CSS editor are then an add-on price. So far for my purposes which are maintaining the as-is site its been fine with the basic free editor and the FTP plugin which is also free (pretty much all other plugins are paid for as I mentioned).

My likes:

• Easy to use, multi-tab interface, can do in-place visual editing of the webpage, or swap to HTML source code view at at any time
• HTML5 standards compliance (built on Firefox)
• Automatic signaling of HTML and spelling errors
• FTP plugin can determine what files have changed and need to be re-published

And my dislikes:

• Very much a page editor, although you can open multiple pages there is no concept of site structure, and you have to open pages 1 by 1
• No template editor so have to manually ensure that all your web pages are consistent
• Linked to the above two, no ability to generate the website navigation structure, have to hand-craft appropriate HTML on each page
• Bit slow to load, but OK once loaded
• Because it is based on editing the currently loaded page DOM, if you make a mistake and insert invalid HTML such as putting a closing </DIV> tag prematurely, then a large chunk of your page might disappear - backup regularly!
• Annoyingly any HTML special characters expressed as &&whatever such as &frac12; get automatically changed to the appropriate special character - e.g. ½ - and this messes up on FTP publishing. Fixed in the end by getting the appropriate ASCII conversion configured but having the special characters in the file wasn't what I wanted
• Similar to the above, any comments in the CSS file are stripped out by BlueGriffon. I like the comments to explain what each bit does
• I wonder about its active development, version 1.7.2 was published in June 2013 and although there is a post on the authors blog in August 2013 and another on the Google group in March 2014 stating his intent for active development, nowt much has been seen as he has other priorities.

But overall I do like Blue Griffon, it does pretty much what I want from a website editor, as long as I am careful to not write bad HTML it works fine.

... but I do miss the ability to build a template from which all website pages are then derived. This would be my #1 ask but templates are something BlueGriffon cannot do :-(

Flipping website software

Ever since I setup my Gite website (at www.giteinbrittany.com) I've been using IBM's Rational Application Developer (RAD) to edit and maintain the website.

Two reasons for this, one I work for IBM and thus I am able to use our software for free "for personal self-development", and two, it's actually pretty good for what I want to do with it.

One of the main things I like about RAD is that you can create page fragments and templates and automatically embed them into other pages - so each month of the booking calendar is a separate HTML fragment which gets automatically combined together for the main 'availability' page and also embedded within the separate 'this month's calendar' popup page. When I edit the availability diary then both pages are automatically created by RAD from the single booking calendar fragment.

The other big thing I like is the automatic page templates and website navigation tool. I have defined the structure of the pages and our website in RAD and then when we add or edit pages in the site structure they are automatically generated with consistent HTML and all the left hand menu navigation tree (including all the different styles according to whether it is a level 1 or level 2 hierarchy page you are looking at) also gets automatically generated.
This took a bit to get working the first time I did the site but its been working perfectly ever since.

Earlier this year I upgraded my laptop from Windows XP to Windows 7 and had to reinstall RAD onto the new laptop. Unfortunately something went wrong in the process and ever since then the embedded page fragment stuff for the booking calendar hasn't worked properly and I've had to edit the calendar in both places manually, and the templating has been a bit dodgy - some pages pickup the site template and others don't for no readily understandable reason.

But up to now I've been able to work round these little niggles and all has been well in the garden of website Zen ...

Until tonight. Earlier in the week I noticed there was a new upgrade to RAD available (version 8.0.4.1 instead of version 8.0.4.0 fixpack 1 that I'd been using previously).

So I downloaded and installed it.

Bad move.

Today I went to update the booking calendar as we've taken a booking for July, and of course since this was the first time I'd run the new RAD software it took ages to load up and initialise itself.

Ages later it had finished and I went to edit the website calendar. To my pleasant surprise I found that the automatic page generation was back working again properly and editing the calendar HTML fragment caused both the different calendar pages to be automatically created again - just like it used to be last year.

Made the changes, published the changes, and went to check the availability diary looked OK.

It did and it didn't.

The calendar for 2012 looked fine but the navigation menu down the left hand side of the page had disappeared for reasons best known to RAD (well not known to me).

Most pages had the navigation menu appearing fine, but the website home page and the availability calendar didn't have any navigation menu for some reason.

Looked at the HTML, looked at the RAD config, changed the page template to see if that would resolve the issue .. and promptly made the problem much much worse as the navigation menu got eliminated from every single page in the website.

A website without any visual means of navigating from one page to another is somewhat limiting so I really did need to fix this issue !

So its now 10 past 1am in the morning and I have finally finished fixing the website.
Despite all my efforts, fiddling with the page template, changing the navigation sidebar code, reverting back to an earlier site design, copying the structure file to another filename, and lots of other ideas, nothing worked. No navigation menu on any pages at all.

And to tease me further the website sitemap resolutely correctly showed the entire site structure correctly so I know the site structure isn't corrupted in some way, it just doesn't render in the left hand navigator any more.

After lots of attempts to fix the root cause of the problem I did what any IT person would do when its late at night, I bodged it!

Fortunately I had taken a copy of the entire website earlier in the week before I installed the new RAD software so I knew what the HTML for all the pages should be, so I used this backup copy of the website contents to manually edit each and every page in the website and hand-craft the correct navigation menu HTML onto the bottom of each page so the page now displays correctly. RAD is still playing up and isn't automatically generating these navigation structures for me but I've put the correct HTML onto each page myself so the whole site now looks OK.

Of course going through each page of the website, manually editing it, getting the HTML correct, etc is a laborious task and I made a few mistakes on the way, so it took me several hours to do.

Hence the late night.

Anyway, job done now, time for bed. At some stage I will no doubt find what the problem was and will then have to re-edit all the pages again to take the hand-crafted menu structure off once the auto-generated menu structure reappears.
But that is a problem for another day.

As I said, flipping website software. Grrr

Broken "contact us" form now fixed

On our Gite website we have a contact us rental enquiry form that potential guests can use to enquire about availability, prices, etc.

Unfortunately unbeknownst to me some time in the last few weeks when I'd been re-publishing the website after adding some recent bookings, some gremlins had crept into the system and broke the booking enquiry form.

This mean that if you tried to submit a booking enquiry you got back the ever-helpful message:

Internal Server Error

Could not execute script "/websites/123reg/LinuxPackage06/gi/te/in/giteinbrittany.com/public_html/theme/enquire.cgi"

suPHP 0.7.1

Good error message, eh?

Fortunately some very kind people who were trying to make a booking enquiry and received this error decided to call me to enquire about availability, and in the course of the conversation told me of the problem they'd had in using the website.

Fixing the problem took me only a few minutes because I realised that the CGI script that is used to transmit the booking enquiry to me needs to be "executable" and by FTPing to my website hosting provider I could see that it wasn't.
A non-executable script means that the web server couldn't run the script, and you get a really horrible error message if you try (as above).

FileZilla FTP allows you to change the permissions of any file quite easily so I set it to executable* and job done, everything worked perfectly and booking enquiries were coming through again.

In fact not only were booking enquiries coming through again but so was the trickle of spam messages I get from the website as well. It seems that whenever Spammers come across any submittable form on a website they can't resist filling it with rubbish, I guess on the hope that I will click on one of the links and earn them some money.

Within a few hours of fixing the contact us form I started getting spam booking enquiry messages again and I guess I should have realised beforehand that I wasn't getting any spam enquiries and that there was a problem with the form.

* If you are inclined and want to learn more about Unix/Linux file permissions then there are loads of resources out there on the internet. e.g. how linux file permissions work.

Bonne Année 2011, and a look back on 2010

"Bonne Année", or should I say "Happy New Year" to all my readers and visitors.

At this end-of-one-year, look-forward-to-the-next time of year I thought I'd give an update on how things have been for us personally in terms of website traffic and holiday Gite bookings. I last wrote on this subject two years ago when I detailed the visitors and guest numbers from 2005 to 2008, so an opportune time for an update.

Again using Google Analytics reports, website visitor numbers for both the Gite website and this Blog for the last couple of years have dropped a fraction, but in the main have been fairly constant:

Year	giteinbrittany.com		giteinbrittany.blogspot.com
	visitors	page views	visitors	page views
2008	13,617	42,756	4,492	6,523
2009	11,450	32,104	4,037	5,676
2010	12,961	33,198	3,932	5,331

But unfortunately we have seen a definite downturn in guests over the last couple of years, with 2010 having both the smallest number of guest bookings and the least number of nights where the Gite was rented out:

Year	Rental bookings	Number of nights rented	Average days in advance
2008	22	162	150
2009	15	109	109
2010	12	98	135

Hidden behind these numbers of course are the days and weeks we have occupied the Gite ourselves as a family, and in both 2009 and 2010 we had a number of stays including a 3 week August holiday in the Gite, which is of course prime-time holiday season.

Over the 6 years now that we have been renting our Brittany Gite out we've now broken the Century with 103 different guest holidays, although some of these are families that have been back a couple of times, and two families have been back 3 times, so the number of unique guests is slightly lower.

Again we've had really good feedback from our guests, although I have to admit to not having remembered to copy some of the quotes from the "Gite Diary" that we leave in France onto the online Guestbook comments on our website. Every time I visit I completely forget to sit down and copy some of them over - perhaps this should be my New Year's resolution?

I'm hoping that the booking slowdown is due to the general economic conditions, and we'll see an upturn in numbers as and when things improve. I know other Gite's have really really struggled with just a handful of weeks booked last year, so against this background we've continued to do well. We've kept our rental prices constant for the last two years and are continuing to invest in improvements to facilities at the Gite, so fingers crossed let's hope we are well positioned for a good 2011.

(And so far we've had 5 bookings for the new year, 46 nights in total, with a good chunk of July and August booked, and also an early May booking as well, so things are looking OK so far).

PictoBrowsering again as my photo gallery stopped working, and 8 alternative Flickr photo galleries

Back in the dim and distant mists of time (ok, March 2007), I wrote about how I'd used Pictobrowser to deliver a photo gallery of some of our Flickr photos.

Wind the clock forward to June 2008 and I managed (briefly) to get the PictoBrowser gallery to be W3C compliant HTML, until a week later when I discovered that the PictoBrowser <object> rendering didn't work with Firefox 3 and Adblock so I ended up reverting back to the original HTML.

Well the world (and browsers) move on, and to my shame I noticed a little while ago that PictoBrowser wasn't working at all on my website, but didn't get the chance to investigate why, nor more crucially to fix the issue.

So as if I have any time on my hands, I made myself put some effort into looking at the problem.

A bit of Googling later and I turned up an article on the Flickr help forum entitled why did Flickr disable the PictoBrowser API key, which was basically my problem, that Flickr had identified problems in the way that PictoBrowser was integrated to Flickr and had disabled the application API key - hence my PictoBrowser was no longer recognised as being acceptable to Flickr and had stopped working.

The help article concluded with the good news that the PictoBrowser integration issue had been resolved by the PictoBrowser author, Diego Bauducco, and a new version of PictoBrowser was launched.

Simples to go to the PictoBrowser homepage, run through the handy 'PictoBrowser builder', and create the new HTML to download and fix my photo gallery.

Along the way of investigating the issue I did come across some alternatives:

• FlickrSlidr which creates a simple rolling slideshow of tagged Flickr photos ... but doesn't seem to have a mechanism to change the background colour of the slideshow from black to white. At first I thought it didn't show the photo titles/descriptions, but I later discovered that clicking on a photo causes the photo to reduce and the description to be shown. Still no way to show the title or change the colour though.


• SlideFlickr which is very similar, and has more configuration options (no black background), but the photos always seem too small and I didn't like the way that the 'I' button displays the photo description in a too-large font right across the photo


• FlikrShow is one that shows promise, it's a JavaScript based solution that quite surprisingly doesn't rely on underlying frameworks like JQuery, so comes in at a tichy 7kb in size. FlikrShow is "currently in public beta testing, and will be released properly in Spring/Summer, 2010" (Hmm, a bit late), but looks definitely worth exploring more. My only concern is that it appears to load all the pictures up front before starting the slideshow, so if you have a lot of tagged pictures it could be slow to load. The current demo page is quite slow.


• Flickr themselves of course have a slideshow feature, the new version of which was launched showing a sample Flickr slideshow in July 2008.
  Full screen the Flickr slideshow for my PictoBrowser photos looks really good, but if I want to embed it into my website then the only customisation option for Flickr slideshow is to set the size of the photo, there is no customisation of background colour (black again), show of title/descriptions, etc


• Alternatively Visual SlideShow and Flikr-Gallery which both appear to be the same piece of software go down a different route, they are full PC or Windows applications to allow you to select your photos (including from Flickr), size and style them and the transitions as you wish, then to publish a complete standalone Photo gallery application. Under the covers the built website uses Mootools and JQuery (so that's a 100Kb overhead to the page), but the results produced are quite impressive; take a look at the demo page for VisualSlideshow and visuallightbox.


• Slideoo provides a horizontal slideshow of Flickr pictures, but there's only the option to select photo sets, not tagged photos, and I didn't like the resultant slideshow either


• BigHugeLabs (cute name) have a whole load of free tools and utilities you can use with your photos. I made a BigHugeLabs slideshow of my Flikr Gite photos; it looks quite nice but the selection of photos is a one-time import from Flickr so if you add new tagged photos you have to re-create the slideshow all over again. No good.

So after all this, where did I end up?

Well I decided to take the easy route and stick with PictoBrowser, the latest version now uses SWFObject to render the flash object so someone else has sorted out ensuring full W3C and cross-browser compliance (hurrah), and I do still quite like the interface.

My only minor upset was that I couldn't find a way to make the slide show automatically start so ended up emailing Diego Bauducco the author, who was quick to respond and unfortunately tell me the news that he'd had to remove that feature from Flickr slideshows because there is a limit imposed by Flickr to the number of queries that PictoBrowser can make so he had to remove that feature.

If I'd used Picassa (owned by Google) for my photos then an auto-start slideshow feature is available, it's not documented, but if you need this, just add one line to the PictoBrowser HTML:

so.addVariable("slideshow", "on");

So there we are, a newly completed and updated French Holiday-Home photo gallery page; enjoy!

Being a bit more accessible

Today I managed to cross another item off my to-do list as I have been updating the 'Contact us' booking enquiry form to be Web-Accessible using the WebAim accessibility guidance for creating forms.

In order to make submission forms more user-friendly and in particular to ensure that your form can be handled by screen readers and by users with partially sighted accessibility tools, I needed to associate each input field on form with the corresponding descriptive label associated with it.

So the HTML

Email: <INPUT type=text name=EmailAddress size=35>

which creates an input box that you can enter your email address into, with the text string "Email:" next to it

Email:

becomes

<LABEL for=Email>Email:</LABEL> <INPUT id=Email type=text name=EmailAddress size=35>

which looks identically the same

Email:

Except that this time by adding the LABEL and "for=" you have instructed the browser that the "Email:" label is associated with the input field rather than being just a bit of text that randomly happens to sit next to the input box. This helps screen readers to visually prompt the user as to what the input field is, and also has an added advantage for ordinary web browsers that if you now click on the label associated with the input field then the cursor immediately jumps to the start of the input field - try it and see what I mean.

WebAim has lots of accessibility resources and is well worth exploring to understand more about how to make sure your website is as accessible as possible.

Further details on the HTML <LABEL> tag can be found on many sites including w3school's HTML reference and Web Design Group's HTML reference manual.

Popup windows, Javascript and the longest piece of software development ever?

Let's talk about windows.

I don't mean the glass and plastic type that you look out of, nor the type that's made Bill G his millions of mega bucks, I mean the popup type that shows you more information on a website when you click on or hover over something.

In our holiday gite website we've taken a traditional approach used on many other websites of having thumbnail pictures which when you click on them they are replaced by a full size photo.

I feel it's much better for the user experience if you open the new bigger picture in a separate window which can be easily closed rather than opening the picture in the current window as then the website visitor has to click 'back' to get back to what they were looking at before they clicked the photo.

The simple approach to achieving this is with

<a href="pathname_to_large_picture" target="_blank">

which will open up a new window when the link is clicked ... but as I discovered back in 2008 when I tested the Gite website with the W3C website validation tool, this isn't valid HTML 4.01 as the target tag has been removed, so I ended up (after a lot of searching) with:

<a href="pathname_to_large_picture" onclick="target='_blank'; " >

Which did the job just fine.

And then sometime in mid 2008 I found a little bit of Javascript somewhere on the internet that improved on this:

function opwn(url,wd,ht)
{
var hw=(screen.availwidth - wd)/2, hh=(screen.availheight - ht)/2;
newwindow=window.open(url,'img','height='+ht+',width='+wd+', screenx='+hw+', screeny='+hh+',left='+hw+',top='+hh);
if (window.focus) {newwindow.focus()}
}

That when called from an onclick() event would calculate the screen size and using window.open() would create a new window of the right size as the image, would centre the window on the browser and would open the image in the popup window.

And all was good ... except that whilst it worked in Internet Explorer, it didn't work quite work as properly in Firefox; the popup window was correctly sized but it always opened up in the top left hand side of the screen. In the grand scheme of things I decided I could live with this irritation so implemented this opwn() function across all the pages of our website.

And there things stayed for a while until quite by chance I came across a website, I don't remember where it was, but it blew me away with popup windows that magically dimmed the background and faded into sight from the centre of the screen. There was animated graphics, next and previous buttons to view multiple images, and and and, ... and I was hooked!

Reading the HTML I discovered that the website had used a really neat Javascript package called lightbox written by Lokesh Dhakar and so I was pretty quickly downloading the javascript and CSS files and created a test version of our Gite website homepage with "lightbox powered" popup image windows.

But the more I played with lightbox the more I decided I wasn't happy with this popup solution. Lightbox visually looks great but all that bling comes at a price - bloat !

Lightbox relies on the underlying Scriptaculous Effects Library and the Prototype Framework so with Lightbox's own Javascript there is a total of 5 additional files to be loaded by the web-browser and a total of 186Kb to be downloaded, plus some CSS changes required as well to make it all work properly.

Google to the rescue though and I quickly turned up a number of alternatives to the Lightbox project, with varying attempts by other people to improve on the original design with slimmer Javascript, easier configurability, more options, etc.

I tried all the ones I could find at the time with test versions of our website homepage being created using litebox, lytebox, lytebox_mod, slimbox, myslimbox and thickbox.

By now though the seeds of doom were set and my enthusiasm for using any of them had waned and I concluded that for reasons variable and multiple I didn't like any of the pre-canned lightboxes and its clones. Mainly I didn't like the additional file sizes that would have to be downloaded, but I also was having second thoughts about the bling. In the end I resolved that "I could do better" and I'd therefore write my own piece of image popup Javascript code - "it can't be all that hard" (ha!) and then I'd have something that perfectly fitted my needs and integrated easily to my website.

I'll pause the story here because the actual software development then took me over 2 years to complete ...

Half a day's holiday cottage availability looks better than no availability

I've been fiddling with our holiday cottage website again, making what I hope is a useful but effective tweak to the holiday availability calendar.

When I first created the website I was in a bit of a quandry as to how to show what dates were booked and what were free. I settled on graying out and drawing a line through the booked dates which looked OK but on the day that our guests left or arrived I had a bit of a problem as to how to represent this.

In the end I settled on graying out the nights that the cottage is booked, so the day that our guests were leaving was always left as showing available (because the guests leave in the morning).

This kind of works OK but still has a problem with the first day of the holiday booking because it makes it look like that date is completely booked. In reality the afternoon and evening are booked for our new set of guests but the Gite is still available for the morning.

Where this really becomes a problem is as the diary starts to fill up and there's less and less availability. In the example above from June 2010 we've actually got a free week available from Saturday 5th June through to Saturday 12th June, but as the 12th is marked as booked it's not all that obvious that this is the case. Sometimes I do get booking enquiries where the diary is mis-read, so for instance I'll get an enquiry asking for Saturday 5th June through to Friday 11th June, and I always reply back to offer the extra half day as well.

And of course if I get some customers mis-reading the diary I'm sure there are also some potential customers put off because they think we've not got availability for when they want their holiday.

Well I've found a solution to the problem and rather than just using a solid colour to show whether a particular date is available or not I've hit on the idea of using a background image to show the half-day availability.

Now by appropriate colouring of the left and right halves of the holiday calendar date I can show much more clearly what dates are available and what are already booked. So using the example week in June you can see much more clearly that we're vacant from Saturday afternoon through to the following Saturday morning.

I experimented with different types of half-and-half shading, with diagonals and with vertical and horizontal shading before ending up with this design. I also asked the boss (Liz) what she thought and was given the official "seal of approval" that this was clear and simple.

Full (and clearer) availability for our holiday cottage is now showing on our booking diary!

Improving your image - SEO tips, thoughts and ideas

I recently came across some SEO advice (in webceo's email newsletter) on how to improve the effectiveness of images on your website, and a few tips caught my eye that caused me to stop and think:

• Use high resolution images, if available. Provide different resolutions of images.


• Check how your image looks in thumbnail size. Stronger contrast is needed to better discern an image, which might lead to more people clicking on and linking to the image.


• Provide a small description of an image in the alt attribute of the img tag, but do not fill the alt attribute with tons of keywords, even if they are relevant.


• Think of also using a short image title with keywords in them.


• Use descriptive keywords in your image files' names. Separate words in the file names with a hyphen, not an underscore.

On our main Gite website I've put quite a lot of effort into trying to get decent quality images and photos with the old adage of a "picture tells a thousand words" in the back of my head whilst I've slaved over Photoshop Elements for hours at a time.
I've tried to carefully select, crop, correct, highlight and sharpen to get the best possible results and whilst I have noticed that photos often need the brightness increasing if you're to show them as small thumbnails, I also found that Sharpening and maybe Sharpening a second time improves how well a small thumbnail stands out on the page.

The importance of filling in the image ALT tag cannot be under-estimated in my view as that's your opportunity to help the search engines actually understand what your picture is of.

If your website HTML includes a picture of your holiday home with just the HTML <IMG SRC=gite.jpg> then all that the search engines have to go on is that it's a picture of a Gite.

If on the other hand you've specified the HTML as <IMG SRC=gite.jpg ALT="The front of our lovely French farmhouse Gite"> then think how much more relevant and descriptive this photo becomes?

So following this reasoning I've always filled in ALT text for all the images on my website (and I try too on the Blog as well).

But what about the fourth tip, to use the TITLE tag as well?

Well I noticed some time ago that as well as the ALT text being displayed when an image is being downloaded, in Internet Explorer if you hover your mouse over an image then the ALT text is shown just underneath the cursor as a little 'tool tip'. So if like me you've diligently filled in your ALT tags with a brief description of what the photo is all about then any IE visitors will benefit from your prose automatically.

But I had also noticed that Firefox (which continues to be my browser of choice) doesn't behave this way and your ALT text remains hidden - bum!

When I was working on the most recent addition to our Gite website, the Driving in France page I did some more investigation and discovered that whilst Firefox doesn't make use of the image ALT tag (unless of course it can't download the image for some reason), but it does take notice of the TITLE tag in just the same way as IE by displaying a little tooltip underneath the cursor if you hover your mouse over a picture which has included the TITLE tag.

So putting these together you end up with the best of both worlds with

<IMG SRC=gite.jpg ALT="The front of our lovely French farmhouse Gite" TITLE="Roses climbing over our Gite entrance">

And by carefully choosing different (but equally relevant) text for both the ALT and the TITLE tags then you've doubled the value and meaning that you've given to the photo.

And finally, image filenames.

I have to admit that this is one that I've gone wrong on and have only relatively recently realised that I've got to fix it.

When I started off writing the website I knew I needed semi-meaningful image filenames so I could manage, find and edit the right images (I could never deal with hundreds of images with names like DSCF0583.JPG), but thinking about trying to keep the website HTML page size down as much as possible I decided to use abbreviated filenames so that I didn't unnecessarily bloat the download time.

And so I ended up calling a picture of Josselin Chateau from the riverside "jossch_river.jpg", and Josselin's lovely half-timbered Tourist Information building is "joss_ti.jpg".

In hindsight I realised this is not good and for the sake of a few bytes of text is a futile waste of time.

So last year when I added a new page to the Gite website describing the fantastic world heritage site at Mont St Michel I decided to start my path to correction and duly created far more meaningful image filenames such as "mont_st_michel_narrow_streets_and_shops.jpg".
By doing this I give the search engines much more information to chew on and I'm making it quite obvious that this is a picture of narrow streets and shops at Mont St Michel.

But the webceo advice then partly contradicted this, telling me to use hyphens not underscores - argh, and why?

Well for an answer after a bit of Google searching I came across this excellent post from Matt Cutts of Google's webspam team explaining why you should use hyphens to separate words in a URL.
The summary is that Google treats the underscore as being part of the word so Mont_St_Michel in a filename (or URL) will only result in a match if someone specifically searches for "Mont_St_Michel" whereas if you use hyphens then Google treats this as being a word separator so if your filename is "mont-st-michel-narrow-streets-and-shops.jpg" then your image will be found on a search for "Mont St Michel" - which is what you want of course.

Actually the story doesn't end there as Matt's posting was originally written in August 2005 and it seems that in mid 2007 Google changed its search engine algorithm so that underscores are now treated as word separators.

And sure enough when I tried a search for "mont st michel narrow streets and shops" my picture came up trumps, proving that the underscore is being treated as a word separator now by Google.

Nevertheless I decided to change my image filenames to using hyphens instead of underscores anyway. Long and the short of it is it's more human readable and although Google may not distinguish between underscores and hyphens as as word separators it doesn't mean that other search engines behave the same way. Read the many many comments on Matt's posting for what others think, the consensus seems to be to use hyphens.

I will also make a separate plug for Matt Cutt's Blog, it's one I personally follow and is full of useful (and sometimes not quite so useful) thoughts and ideas.


And finally, I will add one image SEO tip of my own, and frankly I'm surprised that the webceo advice didn't include it because I think it's one of the things that really can put you off a website.

It's to check the size of your images and to reduce them as much as possible. Even with just about everyone on broadband it still takes a few extra seconds to download a 10 Mega-pixel photo saved as 64 million colours. Add that up for several photos on a single website page and you're looking at bored and cheesed off website visitors who might well just click onto somewhere else that's speedier to browse.

To illustrate, the largest image on our Gite website is 74Kb in size and the majority are in the 40-50Kb range. And those sizes are for the fullsize "click for larger picture" variants. The thumbnails that are displayed on each page are all under 10Kb in size and some are as small as 4Kb. I personally recommend the free Irfanview for resizing and shrinking photos.

PS: I now of course have a mammoth job to apply all these improvements across my website. So far I've only applied them all to the hints and tips for driving in France page.

Oh well, will keep me busy in the winter I guess ...

Google BrowserSize - Making it easier to see how others view your website

Last night Google announced on their Blog the launch of Google BrowserSize which was developed as a "20% time" project my employees of Google and has now been publicly launched in GoogleLabs.

The idea behind Google BrowserSize is quite simple, and reflects the importance of having the most important text on your webpage at the top-left hand corner.

Using a sample of browsers sizes from real users of Google.com, Google BrowserSize overlays onto your website a series of coloured zones to show what percentage of users would be able to see that part of your website.

So if for instance you've got some important text or action button that's part way down the page or across to the right hand side then you can see just how many users would have to scroll their browser to see the 'important' bit. Obviously most people will read and act upon the text immediately in front of them when they view your website so if you're relying on them having to scroll to read and act upon your website then you're going to lose impact and potentially of course loose customers.

Here's how BrowserSize looks on my own rental holiday cottage website:

lines it enables you to graphically see representation of how many different web your website looks when viewed

One of the things that is immediately apparent is that because of all the hard work I put in when redesigning the website back in 2006 to ensure that the text automatically flows out to fill the full browser width, it means that even with quite small browser widths (e.g. set to 900 pixels to match a 90% browser coverage of actual Google users) the page is still quite readable.

And in the other direction, with the page width set to the same 900px, I can see that a good half of the navigation menu is straight away visible for everyone (i.e. in the '99%' zone), and the remaining navigation items ('Contact Us', 'Site Map', 'GuestBook Comments', etc) are in the 98-90% zone - i.e. 9 out of 10 people can see the whole navigation menu without having to scroll the browser at all.

And in the middle of the screen I've got my "Stop Press" late breaking news box, and then the main introduction to the holiday Gite starts.

So all in all I'm pretty happy with the results, shows that most of the time the key information I want people to see is visible without requiring scrolling.

But what this has got me thinking though is that I ought to resequence some of the menu navigation items to promote a few of the more important ones up higher on the page. 'Contact Us' is currently in the 95% zone - meaning 5% of website visitors would have to scroll to see it - and I can easily move this up and move 'Rental Rates' down.

In conclusion, another useful WebMaster tool from Google.

Just how big is Brittany Ferries website?

I came across a rather odd article the other day that announced that as a result of implementing some website optimisation software, Brittany Ferries website had leapt from having 3,000 webpages indexed by Google to 308,000 pages being indexed by the search engine.

I have to admit I was astonished by this marketing claim. Just how big is Brittany Ferries website? I can't imagine how they can possibly have three hundred thousand unique pages of website content even if they include affiliated organisations such as their Brittany Ferries Gites & Cottages directory. A thousand or so maybe but that's an absolutely incredible amount of material.

So I did a few searches for myself.

Self SEO have a tool that will search the major search engines and tell you how many pages you have indexed on the search engines.

For BrittanyFerries.com SelfSEO reported 14 indexed pages, but for Brittany-Ferries.co.uk it reported 346,000 pages as being indexed!

Alternatively in the Google search box you can type the query

          "inurl:putyourdomainnamehere.com site:putyourdomainnamehere.com -qwertrew"

where "qwertrew" is some term that does NOT appear on any of your pages.

Try this for www.brittany-ferries.co.uk and then click on the 'repeat the search with the omitted results included' and I got 42,300 pages but if you dig down then an awful lot of the pages seem awfully similar to each other.

So it's odd that the numbers can be so wildly different depending on how you 'ask' Google what it's indexed.

So repeating these queries on something I know the answer to, my very own www.giteinbrittany.com vacation rental website.

SelfSEO revealed 119 pages indexed, and via the 'inurl' Google search trick, 118 pages indexed.

Digging around and counting up I found that there are 27 actual pages of content (Gite description, places to visit, travel directions, current availability) on the Gite website, 74 availability calendar pages (one for each month from January 2005 through to January 2011), 14 different 'test' pages I've written whilst trying out ideas (like the website redesign of 2006) and 5 different PDF documents (booking enquiry form, etc).

So the 'correct' answer is somewhere around 120 if you add all these together - thus the SelfSEO number seems just about on the mark.

Which leads me back to sort of trusting the website index statistics unearthed by SelfSEO, and thus begs the question I started off with, Just how does Brittany Ferries end up with so many unique website pages?

It's taken me long enough to write a hundred or so pages !

Driving in France - hints and tips

French Roadsign

One of the things that I managed to do whilst we were on holiday in August this year was to finish writing the new 'driving hints' page for our Gite website.

I remember when I first registered the www.giteinbrittany.com domain name and I'd placed a Gite advert in the village magazine before the website was finished. The race was on to get the website finished before the magazine was distributed around the village and so I spent night after night churning out the pages of the site.

Since then my output of writing new content has slowed down somewhat ... ok, it's slowed down and awful lot, and the time between writing new pages has stretched into months and months.

Looking back in the Blog archives I can see that I added a 'what is RSS' page in February 2007, the PictoBrowser-powered photo gallery in March 2007 and details of the nearby world heritage site of Mont St Michel in June 2008. So looks like I'm averaging about one page a year - so this could be the only new page I actually finish writing this year!

Anyhow, back to the plot (such that it is) ...

Although we've had a holiday travel options and routes page on the Gite website since launch which has some details about driving in France, it's mainly focussed on whereabouts in Brittany the Gite is, and how easy it is to get there whether you choose to go by plane or ferry, and from wherever you want to travel across the UK and Ireland.

I thought that I ought to supplement this with more specific details of what it's like to drive in France and what the key rules and regulations are for both you and your car. I spent quite a lot of time trawling through different sites on the internet to put this page together, including the AA and RAC motoring in Europe pages, the UK Foreign and Commonwealth 'advice for travellers' and various leaflets and brochures I'd picked up over the years.

There's details of French speed limits (which vary according to whether the road conditions are dry or wet), important things you need to know when driving such as 'Priorité àDroite', how and where to fill up with fuel (and what the different pumps contain) and the legal obligations for taking your car to France such as carrying a warning triangle, spare bulbs and a reflective jacket.

Finally I've included English/French translations for dozens of the most common road signs you could see on your holiday so you're not baffled by Toutes directions, Suivre Rennes or even Cédez le passage!

Hope you find useful the new Driving in France - Hints and Tips.

And as a bonus challenge, test your knowledge of driving in France with the roadsign above. Do you know what it means? On a holiday programme I saw last year they quizzed people on the cross-channel Ferry and hardly anyone knew what this sign meant - do you?

And if you don't know, suggest you surf over to our French motoring information page!!

Turbo blogging - or making your website/blog load faster

Even in these days of always on broadband and hyper-fast connectivity (well if the government get their way with Digital Britain that is), it's still worth taking a bit of time to make sure you've done the obvious things to make your website or Blog as quick as possible.

Over on Blogger's help pages I came across some how to make your Blog load faster tips from Google - and they should know!

I still find it amazing how many websites you see that have massive photos that haven't been properly resized from the multi-megabyte camera image.

I've also been using the Yahoo Yslow plugin for Firebug to analyse my websites for performance problems and whilst it gives some good pointers as to what to do the suggestions are a bit "cryptic" to say the least.

Surfin the web today I came across a Google announcing they've launched Page Speed, another Firebug plugin which does much the same thing, except (in my humble opinion), it's better.
So for example the three tips that Page Speed identifies I should apply to our holiday Gite homepage are to:

• Set expiry dates on items (such as pictures) that don't change frequently so they get cached in the user's browser and thus don't need to be downloaded each time ... and PageSpeed gives me specific details of what should have the cache expiry date set


• Enable gzip compression on the html and linked css files ... and I'm given details of precisely how many kb download this will save


• And to use Minify to reduce Javascript files ... and again the savings I can gain are detailed

Great stuff!

It would be 'even better if' Page Speed gave me details (or a link) to precisely how to implement these suggestions, but the help given is much more specific than Yahoo's Yslow so Page Speed will be going in my Web kitbag and (when I get some time!) I'll be working through the suggestions made.

See the Google Page Speed download page for more details and to join in the community forum to share your own experiences and suggestions.

Follow these tips and do your bit to keep the 'web lean!!

301 rewrite broke the website

I admit it, I'm a muppet.

We tell the kids (especially Jack, our youngest) that they're "a Muppet" when they do something stupid.

I can now confirm, as suspected for a long time, that the kids must get their Muppet genes from me as I managed to completely break the holiday gite website for a week as the Google Analytics graph above all too clearly shows.

Back in January 2009 I wrote about the "extreme website trickery" of using .htaccess and rewriterule to auto-magically transform requests for web pages such as http://giteinbrittany.com/gite.html to http://www.giteinbrittany.com/gite.html.

I concluded with noting that I still had some work to do with ensuring that http://www.giteinbrittany.com (i.e. the default home page) and http://www.giteinbrittany.com/index.html (i.e. the actual home page contents) were appropriately dealt as a single indexed page (in Google and the other search engines) to maximise my page rank opportunity.

Well with some on and off fiddling of the way that the website menu structures were automatically generated I managed to change all the internal home page references from /index.html to just / so this did most of what I needed to do.

All that remained was to do some fiddling with the .htaccess file to return 301 (permanently moved) for any direct page requests to index.html and the job was done.

Although of course 'it ain't never that simple' with me!

I remembered that over the years I had moved around a few of the website pages and I was concious that there were links "out there" on the web that still pointed to the old website pages that were now broken and returning an unfriendly HTML 404 'page not found' error.

Easy I thought, I'll use a bit of .htaccess trickery to return a 301 response code and redirect any 'old page' requests to the shiny 'new page', page rank will improve, broken links will be banished and customer experience will be improved as a result, and all will be well with the world!

In my travels to work out how to decipher the intricacies of page redirection I'd come across an article by Steven Hargrove on redirecting moved web pages which simply said to include an additional line in the .htaccess file:

Redirect 301 /old/old.html http://www.you.com/new.html

So that's what I did, I added a new line like this:

Redirect 301 /test/index_lytebox_mod.html http://www.giteinbrittany.com/test/lytebox/index.html

Job done, I uploaded the new .htaccess file, and left the website to it.

You'd think that after 22 years working in the IT Industry I would know better and remember to actually test any changes I make - especially those that are as 'deep rooted' as this in the webserver config file.

Well, Mr Muppet didn't bother testing this config change at all, and purely by chance a week or so later I went onto the website to check whether a particular week was available or not and found that EVERY SINGLE WEBSITE REQUEST was returning a HTML 500 error - "fatal server error". I hadn't just managed to break requests to the page that had moved on the website, I'd broken everything.

Google's Webmaster console was full of error messages about unreachable pages and most telling of all was the Google Analytics report of visitor details (above), graphically showing how I caused us to "drop off the internet" for nearly a week.

Commenting out the offending line of the .htaccess file immediately fixed the problem, but finding a working solution to redirecting moved pages has taken me considerably more time as all the examples I found were variations on a theme and everything I tried continued to break the website.

Cutting the story short, and pointing out yet more Muppetry on my part, in the end I found out that the problem was that I had an unprintable character in the .htaccess file and as a result whilst 'http://www.giteinbrittany.com/' and 'test/lytebox/index.html' appeared to be contiguous text when editing the .htaccess in Notepad, actually they were separated by another (invisible) character and as a result the Apache server was barfing on the unrecognised 'extra' text.

Along the way I did an awful lot of research and tried lots of different approaches, none of which worked, until I found the actual root cause problem.

I'll point out a couple of things I did find though, the 'redirect to' URL has to be a full URL (i.e. http://www.blahblah/newpath/filename), it can't be a relative path such as /newpath/filename - at least one site I visited suggested that this was the case.

I can also recommend the htaccess elite forum on using redirect and rewrite for other troubled .htaccess users like me, and then a series of posting by 'produke' on sample redirect statements and a full explanation of how to use the redirect directive in .htaccess.

In the latter article I noticed that the server response code, 301 (permanently redirected), was optional and only introduced from Apache 1.2 onwards. All the examples I'd ever seen had included this response code, so if you have redirect problems then check the webserver version (or take omit the response code).

I'm glad to say now that removing the errant unprintable character cured all my redirect woes and so as a result I have a .htaccess file that prevents directory browsing, redirects requests for non www. pages to the www. version and also now redirects requests for moved pages to their new home.

Putting it all together the .htaccess looks like this:

<Files .htaccess>
order allow,deny
deny from all
</Files>
IndexIgnore */*

### redirect any moved pages that still have old links to them
Redirect 301 /test/index_lytebox_mod.html http://www.giteinbrittany.com/test/lytebox/index.html

RewriteEngine on
RewriteBase /

### re-direct non-www to www
rewritecond %{http_host} ^giteinbrittany.com [nc]
rewriterule ^(.*)$ http://www.giteinbrittany.com/$1 [r=301,nc]

Moral of the story therefore, test things before you put them live and look for the obvious (or perhaps non-obvious) typing errors!

Testing Internet Explorer 8 using Virtual PC

Internet Explorer 8

It doesn't seem all that long ago that I was writing about first impressions of Microsoft Internet Explorer 7, but it's actually nearly 2½ years ago (in October 2006), and here we are again with the launch of Microsoft's Internet Explorer 8.

The Microsoft Internet Explorer homepage is all full of news and video's about how it's quicker, more secure, more compatible and overall a 'better browsing experience' than the competitor browsers (most notably of course Firefox and Chrome), but I'm sure the reality is that it's a case of Microsoft catching up and perhaps slightly leap-frogging them, only in turn to be leap-frogged with the next Firefox version.

I have to admit to being a bit worried about this new version as Microsoft have made strides to make IE8 more standards compatible (something they were ludicrously poor at in the past), but of course in doing so many legacy websites will "break" and not render properly.

Some months ago I asked a friend of mine who'd installed the IE8 beta on his machine to see if our holiday rental website rendered properly, and the news and screenshots weren't good, seemingly the website design that I'd spent months on didn't work properly.

Microsoft have tried to ease the transition pain by adding a 'Compatibility View' button (right next to the Refresh button on the address bar), and my friend told me that the site worked OK in compatibility mode with the IE8 beta version, but nevertheless anything that detracts potential customers from the website is something I want to avoid (hence all the pain I've suffered in trying to get the website W3C standards compliant).

On microsoft.com away from the main IE8 public launch section, on the Microsoft Developer Network site, I found an article about the different IE8 website compatibility modes and how you can use a new 'X-UA-Compatible' meta tag in your HTML <head> section to force the visitor's browser into 'legacy compatibility mode', emulating either IE5, IE7 or IE8.

Currently I have IE7 on my home computer and IE6 on my work computer so I can easily test browser compatibility on the two main IE versions. Similarly I have Firefox 2 on the home machine and Firefox 3 and Chrome on my work computer.

I was thinking therefore that I would have to upgrade one of the machines to IE8 to try out the new browser, when I found through MSDN details of a set of Microsoft Virtual PC images for different versions of Internet Explorer.

Provided are images of Windows XP with Internet Explorer 6, IE7 and IE8 and also Vista with IE7. All you have to do to try them out is download and install Microsoft Virtual PC (a mere 30-odd Mb) and then download the selected images. Each image basically comprises a virtual hard disk with the operating system and browser pre-installed; you start up MS Virtual PC, point it at the downloaded hard disk image and then it starts up as a 'PC within a PC' so you can easily test that your website operates properly with the new browser version.

It does take quite a while to download each VPC image as they're 600+Mb in size (and the Vista image is a wopping 2Gb), but they really are a doddle to use.

After trying out XP with IE8 on both the Gite website and this Blog I was really pleased to find out that everything displayed properly without having to revert to compatibility mode.

The only problem I discovered was that the 'Photo Gallery' feature (using Pictobrowser) didn't work with IE8. After a bit of head scratching I realised that the XP IE8 VPC image only had Flash v6 installed. Downloading and upgrading to Flash v10 cured the problem.

The Windows XP images all automatically expire (and stop working) at the end of April 2009 and the Vista image expires 120 days after first use, so these are not permanent test facilities, but they're certainly very useful.

Into year 5, and a look back on 2008

Payment time came around again this week with a renewal request from 123-reg.co.uk to renew another year's website hosting for giteinbrittany.com. Another £25 lighter in my pocket but it got me thinking back to how we've progressed with our Gite website, our Blog and renting the Gite over the last few years.

So courtesy of Google Analytics, here's a summary of how the websites have performed:

Year	giteinbrittany.com		giteinbrittany.blogspot.com
	visitors	page views	visitors	page views
2005	4,363*	15,270*	N/A	N/A
2006	8,114	28,377	2,192	3,540
2007	11,413	40,171	4,081	6,088
2008	13,617	42,756	4,492	6,523

* The 2005 figures have been extrapolated as I launched the website on 22nd January 2005, but didn't start tracking it with Google Analytics until November 2005, so only have visitor numbers and page views for the last 43 days of the year! In reality I expect the actual numbers would have been lower than this. I launched the Blog on 1st January 2006 (a New Year's resolution), so again no data for 2005.

As well as the people that view the Blog on the web there are also a number of people that subscribe to my RSS feed, and according to FeedBurner as at 31/12/08 there were 20 subscribers, 4 who receive daily emails of new entries through FeedBlitz, and the remainder split across Internet Explorer, Firefox, Thunderbird, My Yahoo, Google Reader, etc.

So how has all that translated into holiday rental bookings?

Year	Rental bookings	Number of nights rented	Average days in advance
2005	14	119	67
2006	17	180	118
2007	23	170	147
2008	22	162	150

I've excluded from these figures our own holidays in the Gite which vary year by year; last year we were there 26 days for instance, and this year we have already planned for 35 days stay.

I can't really tell whether the up's and down's of bookings are as a result of pricing, the global economy, ferry costs or just as a result of randomness, but it is pleasing to see that we're getting more and more advance bookings. So far we've taken 5 bookings for 2009, for 40 nights in total, and most of July and August is booked as a result.

We've also had 76 sets of guests stay in the Gite, although some of these are families that have been back a couple of times, and one family has been back 3 times, so the number of unique guests is slightly lower.

When giteinbrittany.com isn't www.giteinbrittany.com - using mod_rewrite to correct the URL

Hopefully the Blog title has added a bit of mystique to my first Blog rambling of the new year (today was my first day back at work after the break so I can't honestly say "Happy New Year" to anyone as I'm reluctantly back in the office ...)

It's been pointed out to me that the home page for our French vacation rental website, www.giteinbrittany.com is actually available via four different URL's:

http://www.giteinbrittany.com
http://giteinbrittany.com
http://www.giteinbrittany.com/index.html
http://giteinbrittany.com/index.html

In other words the whole of the site is available both with- and without- the www prefix, and if this wasn't bad enough, because the index.html page is also served by default when just the domain name is accessed, there are potentially four URLs for the home page.

The upshot of which is depending upon how other websites have linked to my website I can have up to four indexable entries in the search engine databases for the home page and two for all other website pages.

Now although the search engines do tend to work out the best correlation, they rarely do this 100% correctly (some of the different Google data centres are returning different results for instance), and because I have the home page internally linked to /index.html within the site rather than just /, this also has an additional negative effect of page rank dilution.

So what to do?

Well the solution is a bit of website management I'd not really fiddled with much before, the .htaccess file, and in particular making changes to the website configuration so that attempts to access these different URLs results in them being simply and automatically redirected by my hosting provider to a single page.

If you have a really good memory you may remember that back in July 2006 I first created a simple .htaccess file to prevent people browsing the subdirectories of my website. I achieved that with a .htaccess file that contained the following rows:

<Files .htaccess>
order allow,deny
deny from all
</Files>
IndexIgnore */*

The new trick is to use the mod_rewrite directives in the .htaccess file to cause the web server to take the URL that's requested and rewrite it to what you want it to be.

So if someone requests http://giteinbrittany.com you can respond back with http://www.giteinbrittany.com, and what's even cleverer you can (if you want to) tell the client browser that you have done this and return a HTML 301 error code telling them that the page they requested has been permanently redirected to the new page. At first I was a bit worried about this, returning HTML errors back didn't seem to me to be a good idea, but after quite a bit of Googling I found that returning a 301 error is quite safe, it's what browsers and search engines expect, and has the benefit of ensuring that the search engines will then automatically link the 'input' to the 'output' URL, thus removing at a stroke the problem of having duplicate search engine entries for the same website content.

By the by, if you want to temporarily redirect users to a different webpage (perhaps if a section of the website is unavailable for some short term reason) you can return a 302 error code instead.

There are loads of instructions and tutorials on how to use mod_rewrite out there on the web so I won't repeat them here, instead pointing out a couple that I found to be useful over at workingwith.me.uk there's a simple beginners guide to mod_rewrite that explains the basic structure and usage of the .htaccess entries, at HTMLsource there's an explanation of regular expressions in mod_rewrite and on Stephen Hargrove's Blog he shows how to redirect from the non-www site to the www-version.

So putting these different tutorials together I ended up with an extended .htaccess file like this:

<Files .htaccess>
order allow,deny
deny from all
</Files>
IndexIgnore */*

RewriteEngine on
RewriteBase /

### re-direct non-www to www
rewritecond %{http_host} ^giteinbrittany.com [nc]
rewriterule ^(.*)$ http://www.giteinbrittany.com/$1 [r=301,nc]

The first part of the .htaccess is exactly as before, then the RewriteEngine and RewriteBase commands loads the mod_rewrite engine (as it's an optional webserver plugin and may not be loaded by default) and defines the base directory from which rewrite instructions will be derived.

The rewritecond line says to match any URLs where the http_host (i.e. first part of the URL you are accessing) starts with (the upper 'hat' means that the string starts with) giteinbrittany.com. The [nc] simply says to make the match not case sensitive (so GiTeInBrItTaNy is equally matched as is giteinbrittany).

Then for all URLs that match the rewritecond line, apply the rewriterule, which says take any page requests (the ^(.*)$ means match any page name) and return the requested web page prefixed by http://www.giteinbrittany.com. The [R=301 means return the page with a 301 HTML permanently redirected response code and again NC means make the match case insensitive.

So for example when you request http://giteinbrittany.com/fred.html, rewritecond will match http_host to giteinbrittany.com, then the rewrite rule will fire for fred.html and return instead the page http://www.giteinbrittany.com/fred.html with a 301 response code.

All sounds a bit complicated but believe me it does work and it works seamlessly without any problems at all.

To see all this in action take a look at the website server responses provided by the StepForth's HTTP viewer server tool.

And not only can you see it working for giteinbrittany.com, try entering other URLs such as bbc.co.uk and see the same 301 response and automatic page redirection being returned as well.

So this fixes the bigger problem of dual page ranks for www- and non-www pages, but still leaves the issue of the default home page and index.html being separately indexed.

For this one I'm still thinking about the right answer. I've been advised that I should redirect all index.html requests to the default home page (/), and then change the website navigation structure to match but this isn't trivial in Rational Application Developer that I use, or I could use a similar mod_rewrite to change index.html requests to direct them straight to the default home page, but again if I don't change the website navigation structure to match this just seems wrong as all internal navigation links will still point to '/index.html' which then gets 301'd to '/' ... it seems wrong for me to do this.

I think I will celebrate the success I have achieved and will ponder this secondary problem a bit further ...

Have you tried Google Chrome?

Google Chrome

As written about by Bob Toovey over on Computing in France, and announced Google's own Blog and on countless Websites last week, Google have decided to go head-to-head with Microsoft and Firefox and launch their own browser, Google Chrome.

Google have written a lovely cartoon to explain what Chrome's all about, but cutting to the chase, what's it like?

Well firstly it's absolutely blindingly fast. I just can't believe how fast it is, most pages render before they've seemingly had time to download, and it brings a real pleasure to browsing the web again.

Obvious parallels will be drawn with Firefox and from all accounts it's going down a storm across the Internet despite the beta and Windows-only situation. Over on ZDNet for instance they're already reporting that Chrome has overtaken Opera in browser popularity.

When I first heard the news I couldn't understand why Google had decided to build their own browser when they already make a massive funding contribution to Firefox, my initial thought was "surely they would have been better just improving Firefox?". But now I've tried it out I can see why they decided to plough their own furrow a bit.

You could be cynical and take the view that Google want to control everything on the Internet, starting with the browser and working backwards, but I don't think this is the case with Chrome on the desktop at least (on mobile devices it could be a different matter once Chrome finds its way into Android, Google's long awaited mobile operating system).

As Chrome is Open Source there's sure to be bits that find their way into Firefox and vice-versa. Many users are already complaining that their Firefox favourite plugins are missing in Chrome and I do agree with them, the lack of Mouse Gestures and Adblock are the two things I miss the most, closely followed by GreaseMonkey and a few of my favourite scripts (especially the Greasemonkey scripts I use to improve Blogger). I'm sure these gaps will be quickly filled and doubtless some form of Firefox/Chrome cross-browser plugin support mechanism will emerge.

I'm pleased to say my own website appears to work perfectly in Chrome and so far I've not found anything else that doesn't display properly.

So give Google Chrome a whirl, I think it's not going to be disappearing quickly.

Update 9th Sept: I spoke too soon about Chrome's great website compatibility. Discovered tonight that it doesn't work with the Flickr Photo Uploader

Pictobrowser flash movie doesn't work with Firefox 3 + Adblock

Last week I wrote how to display PictoBrowser using standards compliant HTML and get rid of the horrible <OBJECT><EMBED> structure that's normally required to load a flash movie, replacing it with a much simpler <OBJECT object type="application/x-shockwave-flash">.

Tonight a few days after I'd written the article and I'd asked a few friends to test the new page, and finding it all still worked fine, I made the changes to the Gite Photo Gallery, gave it a quick check, and found I got the "cannot load flash movie" message:

Nightmare!!

Cutting a long evening trying to find the problem and a lot of Googling short, I eventually tracked down Jyri Kilpelainen's posting of the self-same problem and the corresponding Bugzilla bug report.

It transpires that there's a problem with Adblock running within Firefox 3 (which I'd just upgraded to), and as a result it doesn't show flash movies if they're embedded with <OBJECT object type="application/x-shockwave-flash"> - lots of other people have reported this problem on the Firefox Adblock plugin page.

Although I could upgrade to Adblock Plus which apparently doesn't have this problem, for now I'm going to leave the photo gallery page as it originally was until the problem's fixed properly as there's potentially lots of other people out there using Adblock in Firefox like me, and I'd rather keep the website working for the majority.

W3C compliant PictoBrowser

W3C HTML validator

Back in March I wrote an article on fixing a number of HTML 4.01 strict errors in order to try to get our holiday cottage home website to be W3C compliant.

At the time I concluded with acknowledging that there were two remaining obstinate problems, the fix I introduced to center-align a clickable image isn't compliant and neither is the Pictobrowser photo gallery.

I've noticed from my website logs since I wrote that article that a number of people have come across the Blog since then, looking for details of how to make the PictoBrowser HTML W3C compliant, and since I subsequently did work out how to fix the problem, I thought I'd pass on my experiences, and at the same time would actually get around to implementing the fix I'd found!

Pictobrowser gives you a natty little Flash-based way of viewing photos from your Flickr photo album, but does this at the expense of browser and W3C compatibility.

Pictobrowser automatically generates the HTML you need to embed into your website page, which looks like this:

<object width="500" height="500" align="middle">
<param name="FlashVars" VALUE="ids=pictobrowser& names=pictobrowser& userName=www.giteinbrittany.com & ..."> </param>
<param name="PictoBrowser" value="http://www.db798.com/pictobrowser.swf">
... some more param's ommitted
<embed src="http://www.db798.com/pictobrowser.swf" FlashVars="ids=pictobrowser& names=pictobrowser& userName=www.giteinbrittany.com &... " loop="false" scale="noscale" bgcolor="#DDDDDD" width="500" height="500" name="PictoBrowser" align="middle">
</embed></object>

This HTML is a slight variant of the so called classic "twice cooked" method of embedding Flash into a website, the <object> tag is there for IE browsers and the <embed> tag is there for Netscape based browsers. Although this works most of the time, the "align=middle" isn't valid in HTML 4.01, the <embed> tag has never been part of the HTML standard, and so if you run the default pictobrowser HTML through the w3C validator you'll end up with a slew of validation errors

Turning to one of my favourite sources of website help, A List Apart, and trawling through all their articles about Flash development, I came across Drew McLellan's Flash Satay article which describes how to drop the <embed> tag and use a simple "container" flash movie that would then auto-load your main movie.

Also on ALA I found Bobby van der Sluis's Flash Embedding Cage Match which describes the cross-browser support problem in far more detail than mere mortals like I can do and describes the embedded-object solution for better standards compliance.

I tried dallying with the embedded-object solution and works in Firefox and IE and if you strip out all the </param> tags it cuts the number of W3C validator errors from 19 down to 1, still with an errant error message from the align=middle coding, but I didn't really like the way it required calling the flash player ActiveX control in IE by using a Windows-specific GUID - this just looked horrible.

Looking back as I write this article now I remember that another of the reasons I rejected the nested object approach was that there was a problem when viewing the page in IE that required you to click-to-activate the Flash active-X control (a behaviour introduced by Microsoft in 2006 as a result of a patent infringement problem). This issue has now gone away as Microsoft's agreed a licence agreement to resolve the patent dispute, and as from April 2008 the click-to-activate functionality has been removed from IE.

Bobby van der Sluis concluded with describing how he felt the strategy for Flash-embedding was to combine the best of the two competing Flash embed solutions, UFO and SWFObject, into a new collaborative projects, SWFfix.

SWFfix is still going strong, there was a new release launched recently on the SWFfix Blog, and the JavaScript is freely available to download from Google Code, but after giving it a play I decided it was all too complicated and adding more JavaScript to my website just wasn't the way I wanted to go.

So there I got stuck for a while until I came back to the seminal Flash Satay article on ALA.

In it Drew McLellan carefully step by step re-engineers the twice-cooked Flash player approach into a standards-compliant approach that works across all different browsers. Drew's realised though that IE waits until the whole Flash movie file is loaded before it starts playing it, i.e. it doesn't start streaming it from the start like 'proper' browsers do. His solution to this problem which becomes particularly acute for large flash movies was to introduce a small "sacrificial" flash file that loads quickly and then starts streaming in the main file.

For me though this isn't a problem as the pictobrowser.swf file is only 8Kb in size, way smaller than some pictures on my website, so any delay in loading it is hardly noticeable.

The solution was therefore before me, to simply take the standards-compliant code that Drew had produced in Flash Satay and exclude the last bit of the sacrificial flash file to stream in the "main" file.

The resultant HTML thus looks like this:

<object type="application/x-shockwave-flash" width=580 height=580 data="/theme/pictobrowser.swf">
<param name=movie value="/theme/pictobrowser.swf" >
<param name=FlashVars VALUE="ids=pictobrowser& names=pictobrowser& userName=www.giteinbrittany.com& userId=53897043@N00& titles=on& source=keyword">
<param name=scale value=noscale>
<param name=bgcolor value="#ffffff">
<span>Unfortunately we are unable to display our Brittany photo gallery in your browser as you do not appear to have the free Adobe Flash player installed.<br><br>Visit the <a href="http://www.adobe.com/go/getflashplayer" onclick="target='_blank';">Adobe Flash download centre</a> to get the latest version.</span>
</object>

And then I surrounded this all within a <blockquoute><div> to indent pictobrowser a little instead of worrying about including an align=middle which isn't valid HTML.

The <span> in the middle is a bit of HTML that's displayed if the browser can't display the Flash movie - prompting the visitor to download the Flash player from the Adobe site.

This new website page passes OK through the W3C validator, it displays properly in all the browsers I've tried, job done methinks!

Update 27/7/08: Found out that an AdBlock bug when used with Firefox 3 causes Flash files not to load in Firefox 3. Until Adblock is corrected I'm not going to implement this change