The code that I had used as my basis had worked fine with a clean install of WP2.8 but didn’t like widgets that had been created under WP2.7.

An hour later of googling & trawling through the source code and I was none the wiser. Then I noticed that WP_Widget automatically adds on ‘widget_’ as a prefix to the id_base property. I had used a different naming convention when I had built custom widgets (e.g. starting them with the project or client name, such as ‘redefine_’…).

If I set the option_name property so that it was just the id_base then all of my widgets successfully reappeared in the upgraded site – but not the default WP widgets. So I was halfway there.

Finally I stumbled across a reference to  an alt_option_name property for WP_Widget – that was the solution to my problem. I could set that to the id_base of each my custom widgets & leave the new WP_Widget class alone.

Hopefully this will be of use for other people who have also used a different naming convention for widgets on previous versions of WordPress.

Anyway it was nice to see that the indent button no longer uses the BLOCKQUOTE tag to achieve the desired styling, and that the alignment buttons have dispensed with the ‘align’ attribute.

It’s been a bugbear of mine that whilst the developers and designers of a site might be required (& also have a passionate desire) to work to standards, the content providers are being offered tools that makes all that effort redundant. In the case of these particular buttons they would have stopped a page from conforming with the Double-A WCAG 1.0 accessibility requirements and produced invalid XHTML 1.0 Strict code.

So well done moxiecode! Hopefully the other editors have already followed suit, or well do shortly.

I recently came across Pearl Crescent Page Saver and I can see that it will be another useful tool to be used in 2008 when I’m working on template designs. Rather than just producing an image of what is visible on the screen, as happens with normal screenshot programs, it will include the whole of the web page. There’s also an option to run it from the command line, so it would be possible from a single command to create a batch file (or similar shell script)  to capture a range of templates that I’m working on.

I’ve found that it has been very useful for documenting the evolution of templates & I can see that it will be handy for comparing different versions (e.g. how a template looks as plain HTML/CSS pages and when it is integrated into a system, or to ensure that there have been no side effects when upgrading a look and feel).

Ideally there would be a similar tool for Internet Explorer as you would then be able to track the majority of the users – and it other browsers would be included it could then be used for cross-browser checking.

It’s over a year since Internet Explorer 7 (IE7) was released so I thought it was time to revisit the issue of browser market share, especially after the dramatic take-up of IE7 in the first few months.

However, first things first. Before getting to the detail of versions it’s worth looking at the overall market share for the browsers themselves. Over on Net Application’s Market Share site they’ve got this graph for November 2006 – 2007. You’ll see that whilst there’s some variation over the period, in general there’s not that much movement – Internet Explorer under 80%, Firefox hovering around the 15% mark, Safari reaching 5% and the rest less than 2%. The statistics collected by TheCounter for November 2007 show a roughly equivalent situation.

There’s a gradual shift from Internet Explorer (IE) towards Firefox and Safari that appears to be continuing from their earliest figures in December 2005, but only a few percent a year. Interestingly if you switch over to the operating system trends then you’ll see that there is an increase in the use of Macs of about 1.5%. That covers a fair proportion of the change, especially as Microsoft stopped developing IE for the Mac.

When it comes to the specific versions of the browsers the most significant development is the slow-down in the take-up of IE7, especially when compared to the use of the latest version of Firefox. The increases in the first few months (9% from November to December 2006 and 7% from December 2006 to January 2007) is of the same scale as the total increase from January 2007 to November 2007 – 11%.

Microsoft made the upgrade part of its automated Windows Update system, but it hasn’t been classed as critical. Presumably we’re now left with the users who either don’t use this facility or who ignore the optional upgrades – the majority are using Windows XP which supports IE7, so it’s not a matter of incompatiblity.

There is also the factor of the corporate IT policy, where the reasons for upgrading need stronger justification and have greater repercussions (e.g. support, training, etc.). For example, the US Department of Transportation is reported to have placed a moratorium on Microsoft upgrades.

So after sifting through all these figures, what’s the real significance?

For those of us developing web sites it’s the decline of IE6 into obscurity that we’re looking for. It’s only with version 7 that Microsoft have fallen in line with the standards that other browsers have supported for a number of years, and there seems to have been an interesting number of bugs to deal with as well. So having to deal with IE6, and until recently the different problems with the earlier versions, has added to the workload of developing and testing web sites but without increasing the features available.

There’s also the issue of whether what influences real users in their choice of browser. At a recent Bristol Skillswap there were a number of lively/provocative discussions about this subject. Looking through these statistics though, I can’t see that the majority of users make any conscious decision. Even in the refuge of the alternative community, the Mac, we find that most people stick with the first browser that is installed with their system – in this case Safari (even though it hasn’t been able to access online WYSIWYG editors & until the last month or so it hasn’t been possible to restyle buttons in forms).

That could mean that the balance could shift when/if mobiles and other devices start to be used to access the web in meaningful numbers, as Opera is far more dominant in that market.

As I’ve been testing it out I have been struck by the similarities with the screen magnifier demonstration that I posted about before. There have been discussions in the past about the link between improving your search engine ranking and meeting accessibility requirements through the same techiniques (for example this article on A List Apart). We may find that the (possible) rise of the mobile web continues this trend. For example I’ve noticed that with the iPod I’ve wanted:

• layout and navigation conventions maintained – as with the screen magnifier you need to know where you are on a page and how to get to the content that interests you when you’ve zoomed in to see some detail
• space around links – ironically it’s harder to use some web sites that have been designed for standard handheld devices as you don’t have the same degree of accuracy if you’re pointing at a link with your finger rather than a stylus, this is similar to the experience desktop users will have with poor hand-eye co-ordination
• alternatives to scripting – the iPod Touch doesn’t support Flash at the moment so I’ve come to a shuddering halt with some sites that rely on this technology, so I could find something to see at the Watershed but not St George’s and couldn’t go into sysadmin mode with Google Analytics when I wanted to check up on clients’ websites

In the past month there has been interest about the novel approach that Radiohead took for charging to download their latest album, and all things connected with mobile phones has gone into a frenzy after the launch of the iphone & Google’s involvement. In amongst the hype there have been some good articles redressing the balance on Mashable (Radiohead: comScore Doesn’t Have a Clue) and The Register (Analysts talk telephone numbers on mobile games).

These also act as a timely reminder that the hard part of putting together a (useful) online poll or survey isn’t the technology. Instead it’s framing the questions correctly, finding a representative sample and interpreting the results.

Read the book & keep those sceptical antennae twitching.

I liked the fact that it hasn’t been through their marketing department – the user demonstrating the magnifier obviously has Google as her default home page.

That’s no change since 1999! At that stage we were just discovering the joys of Internet Explorer 5.0 and the Netscape browser was stuck on version 4 (as the Mozilla project that produced Firefox got under way). The first graphical browser had only came out in 1993. So we’re talking about the early days of web design and development when the accessibility working group would have been drafting the recommendation.

In practice this has meant that the guidelines are now addressing problems that are no longer applicable (who after all still uses ASCII art?); new technologies aren’t addressed; old techniques are retained even though better options are now available; and badly drawn-up checkpoints remain on the tick lists for compliance. So it is possible to create an accessible website that doesn’t comply with the WCAG 1.0, and a website that conforms that isn’t as accessible as it could be.

The W3C have been working on a revised standard (since 2002), but there was a furore last year when they made the proposed standard available for ‘final’ comments – for example Joe Clarke’s article To Hell with WCAG 2. Out of that an independent group known as the WCAG Samurai decided to work on providing a set of errata for the current WCAG 1.0 standard – removing parts that didn’t work and bringing it in line with 2007. Their draft version was made public last week, with a final version promised by the end of the month.

After being the butt of numerous April Fools’ announcements, a revised WCAG2 working draft was released last month, with at least another version promised before moving into the final stages of the recommendation process. No deadline has been set. In fact the W3C site states WAI anticipates WCAG 2.0 may be completed in 2007 [my emphasis]. This time round though the draft has been met with more appreciative comments.

I suspect that the WCAG Samurai work might not become a widely used benchmark in its own right. Standards have come from the grassroots in the past, but I would think that there would need to be more of a groundswell of support and lobbying to have say the UK government adopt the WCAG Samurai Errata as their next standard (and from there be taken up by the rest of the public sector).

Instead its legacy might be that it will serve as a source of best practice techniques to be implemented by those of us concerned about accessibility; that it was part of the barrage of criticism that has led to the improved WCAG 2.0 draft and hopefully that it will also serve as a reminder when the W3C starts on the next cycle of amendments.

In the meantime it’s worth starting to look at the WCAG 2.0 drafts – particularly the Quick Reference and  Comparison with WCAG 1.0 documents.

If we move forward to the present day, then in Web 2.0 the idea of bringing in content from other sources is the distinct flavour of the month. In some cases this is still just images (for badges), but the norm is either to have RSS feeds (essentially bringing in HTML code, usually with no filtering of what is displayed) or JavaScript files (running programs in the end-user’s browser).

So you can imagine the following fictitious scenario. A well-known charity runs an extremely successful campaign using all the tricks of the social web trade. They’ve had fund-raising plugins downloaded & added to thousands of WordPress blogs; widgets on MySpace to email the key people concerned; badges appearing left, right & centre and RSS feeds being devoured. All being served from www.examplecharitycampign.org, which once the campaign is over is no longer required and the domain registration lapses.

In those circumstances it could be very easy for someone else to step in, and cause havoc – unsuspecting people could find themselves on what looks like a legitimate donation page, email addresses could be harvested if those were in forms, JavaScript programs not adding visible content to a page but still active (waiting for a browser security loophole, analysing what else is on the page, etc.), hidden links in RSS feeds to help with search engine ranking schemes, etc.

So it is important to plan what happens at the end of a campaign right from the start, rather than casually abandon it or start the process once it’s up and running. Amongst other things you need to decide whether you’re going to keep the domain name for the long term (in which case it needs to be treated like your organisation’s domain), where content is going to be made available (e.g. it could come from your organisation’s domain or from another ‘permanent’ address such as YouTube) and develop methods to try to keep in touch with your supporters/activists (not the easiest thing with viral marketing).