Some of you might have noticed that I have completely overhauled the theme of my site, this is very much work in progress but at the same time I have finally ditched FTP for deploying my blog so any changes I make, even the incremental ones will be pushed live a whole lot quicker.

What does this mean going forward

Going forward I am intending to blog more, I want to engage my audience more and by this I mean I want to post tutorials which my readers will really want, to do this I need any ideas for tutorials to be suggested to me on twitter.

One of the questions posed to me recently was what plugins I would use as a default set of wordpress plugins to ensure we had a standard base that met the following requirements:

• Security
• SEO
• Core functionality

I thought it would be a good idea to share this list so that others can throw in their 2 cents.

SEO by Yoast

Out of the box WordPress features very little in relation to SEO, the disadvantage of this is the average blogger may not realise they need an addon of some kind to allow them to feature more favorably in search engines.

SEO by Yoast adds the ability to easily customise several aspects that effect SEO, these include the title tags and meta tags.

ServerBuddy

ServerBuddy is a handy little plugin which does the simple job of ensuring your WordPress installation is setup correctly. This includes checking all your file permissions to check that you have set them up correctly.

Bulletproof WordPress Security

One of my clients once told me they did not want to use WordPress for their new site because they were concerned about security. With Bulletproof WordPress Security it gives you the extra control you need to be sure your site is as secure as possible, it does this primarily by using .htaccess security. This works because .htaccess files are processed before any other code on your site which means that they are able to stop malicious scripts before they reach WordPress.

Backupbuddy

This is a lifesaver if you ever want to move servers, restore a broken site (especially after a failed WordPress update), or even just move your site from your development environment to live. It backs up your entire WordPress installation, this includes your widgets, themes, plugins, files and the database.

Gravity Forms

Contact Form 7 has long been my go to plugin for forms until a friend told me about Gravity Forms. One of the core benefits of Gravity Forms is that it stores all the data from form entries into the database, has a really powerful visual form editor and allows you to create multipage forms. While it does have a license fee attached which would put many off, for 1 sites its only $39 (or $199 for unlimited sites) but its worth a look if you want more.

Post Credits

This post is based on some research Paul Halfpenny did and the discussions we had about this. Check out his blog www.paulhalfpenny.com if you want to hear his musings.

Yesterday I talked at London Ajax about Performance, if you want to see the slides check them out http://rvl.io/jonthanfielding/javascript-performance

One thing that has bothered me for years in web development is the backend, frontend divide. By this I mean you have a frontend developer who writes the html, css, and javascript and you have a backend developer writing the backend code, handling CMS integration and databases.

This model kind of made sense 4-5 years ago when javascript wasn’t as prominent so you had frontend developers who were not really programmers but instead people who lovingly crafted the HTML and CSS to look fantastic in all browsers. Fast forward to the present and we have ‘frontend’ developers programming frontends for sites like google doc’s, facebook and twitter all of which rely upon javascript. Within the past couple of years javascript knowledge has gone from a nice to have to a must have when looking for a new developer to join the team.

The main reason this bothers me is that this model does not lend itself to delivering the optimum user experience for the users of the sites. Without someone in the middle who understands both the frontend and the backend, you can end up with a disconnect between the technologies which should be able to work seamlessly together. One example of this was the BT Digital Music awards 2011 which had a fundamental usability flaw with the way you registered. While it had a register with FaceBook option, all that this did was fill in a form which still had a password field the user had to fill in, however when the user logged in with FaceBook this password was not required so this interaction did not really make sense. By the time this issue was noticed it was to late and the site went live with this issue much to the dismay of the creative director on the project.

The ideal solution to this divide is to rip it down, scrap the terms backend developer and frontend developers and instead look at the individual skillsets of individuals. If a developer who predominantly does frontend work has a good knowledge of PHP, utilize that in your next PHP project, this will not only allow them to take greater ownership of the project (which can be linked to writing higher quality of code), but is likely to help motivate them as they will likely find the project more interesting because they get to look at it from different angles.

It is important to note that different development teams will have different compositions of developers with different skill sets and skill levels, not all developers who work on the frontend would want to work on the backend and the same goes for backend developers who may not want to work on the frontend. However it is not safe to assume that everyone is happy being pigeon holed into one role.

So today at work I found the need for a way to manage the focus and blur of input and select elements based on grouping. The idea being that when you click in an item of the group, the group get’s focus and it’s focus event is triggered, you can then do what you will with the rest of the elements in the group however when you click on an element outside the group it will fire a blur event.

The code is simple enough, and infact I managed to throw something useful together on my lunch hour so I thought I would share it with you all. If you want to play with this new plugin take a look on github.

I haven’t had time to through a demo together but basically it works using an element (whether that be a fieldset, div, section) wrapped arround your elements as a container of the group. When user clicks on any element the focused element is logged temporarily within the focusGroup namespace, if you click another element in the group you do not get a blur event as its same group but if you click on an element outside the group you will get the blur event for that group. This is great for validation as it overcomes the limitations of the jQuery validate plugin (which I plan to make changes to myself to incorporate something like this for grouped fields and attempt to get my changes implemented into the main repo)

Anyway play, have fun and if you make changes or feature requests push them to the repo for me, open source is collaboration, so lets collaborate.

So hopefully one or two of you have read my last post about my exciting new jQuery plugin for using the new Notification API which can now be found in both Chrome and Safari.

To just provide a quick update, you can find latest codebase at github (https://github.com/jonathan-fielding/jquery-notifications) so please take a look. It works great in both safari and chrome already and the polyfill for older browsers is now coming into shape with an initial prototype tested in firefox.

Anyway I have loads more to do but please follow me on twitter (twitter name is my name misspelled jonthanfielding).

For a while now chrome has had the ability to show notifications from tabs you have open, this is through taking advantage of the new Notifications api and it is used by some of google’s services including gmail.

With the launch of Mountain Lion, Apple has leapfrogged this feature by making it so that notifications show at an operating system level within notification centre, however after testing some of the code people have written for chrome I found things were not working as I expected, also I felt that older browsers were being left out of the notification party so the aim of this project is to provide a standard way to implement notifications across browsers.

The benefits of this using this plugin is that as the notification is implemented more fully and by more browsers the plugin will be updated to allow native notifications in these browsers and by the time the spec is finalised this plugin will aim to support the spec fully and provide an acceptable fallback for older browsers.

Planned Browser Support:

• Safari 6 – Native Notifications
• Chrome 4+ – Native Notifications (only tested in latest version however the API was introduced in Chrome 4)
• Safari iOS 5 – Window based polyfill
• Firefox – Window based polyfill
• Internet explorer – Window based polyfill
• Opera – Window based polyfill

 Things I would love help on

• Firefox plugin to add native support to Firefox (ideally supporting many old versions), this plugin could then be an option in the plugin to suggest the user installs it (optional feature, not all site owners will want their visitors to download a plugin to get notifications, if plugin is not installed it will fall back to the window based polyfill
• Safari extension for older versions of Safari (i can foresee Safari 5.* hanging around a while)
• Designing the default look and feel of the window based polyfill notifications (I am no designer so I expect other people able to do it much better than I)

I will shortly be writing a article about how to use web notifications to provide notification to your websites users however I thought it might be useful to provide a bit of insight of my ideas on places it might provide a good user experience to do this.

One of my initial thoughts for web notifications would be to move common notifications from sites like Facebook and twitter into web notifications. While this would be a good user experience it is a bit of an obvious idea and I do see both twitter and Facebook implementing this. After further thoughts on this matter i came up with the following ideas:

• A sales website (e.g amazon) notifying user of order shipment
• A poker site (e.g partypoker) notifying you a new game is starting
• A news aggregator notifying you of articles you have yet to read

Unfortunately there is one problem with this, all these notifications are really useful but with the current implementations of notifications will not work without a tab open with the website in it. This isn’t the ideal solution and I am hoping that in the future this could be made to work without the websites being open.

Anyway watch out as coming soon is my tutorial on how to use the notifications within Safari to add notifications to the Mountain Lion notification centre.

After reading an interesting post on accessibility over on Paul Irish’s blog I thought I would post my musings on the subject.

Accessibility has always been an important issue to me, not only is it the right thing to do it is also a legal requirement for businesses to ensure their websites are accessible (fines have been levied against several large organisations including the Olympics in Sydney back in 2000).

The main issue I have come across when building an accessible website is maintaining a balance between what the client wants from the site and how to make that accessible to everyone. I have worked closely with user experience (UX) directors to help achieve this balance however UX isn’t an exact science and the UX for a website and therefore the accessibility requirements does vary from site to site. For example, a site like Sound Cloud will struggle to offer a good user experience and accessibility to people who are completely deaf, due to the content being user generated its not easy for the to offer text versions of songs. Equally, Flickr consists of a huge number of user uploaded photos but a hard of sight person may struggle with the site as the users may not have put adequate descriptions of the images.

One argument I have heard from clients in regards to making poor accessibility decisions is ‘Apple does it’ however even though Apple is an icon in the digital era, the most valuable company in the world and produces products which lead the market in both usability and accessibility it doesn’t necessarily mean they get it all right. An example of this is the search box on the main navigation which uses AJAX to quickly get results, it also has the functionality to return a search results page if you press enter so to the average user the functionality is good however when I ran tests on this with a screen reader I found that it could get quite confusing to a user who was expecting to press a submit button after filling in the search box, there isn’t one. With no button the only way to submit the form is by pressing enter, obvious to someone who can see the page but not obvious to someone who has difficulty with there sight.

Without a focus group of internet users who have trouble with hearing or with their eyesight it can be hard to get a full understanding of how they use your site. Unfortunately its not always possible to take into account every use case that users may face however we need to ensure we try our best to plan for several different use cases. Fortunately for the Mac users among us there is a tool which helps us with this, Mac OS X ships with VoiceOver, a screen reader aimed to make the operating system accessible. This can also be used by developers for getting an idea of how a screenreader reads your site but it should not be seen as the definitive solution, like the way we have dozens of browsers that render websites differently, there are many different screen readers out there all of which do there job slightly differently.

Jason Kiss wrote a nice article over at his accessibility blog about how HTML5 and ARIA roles work with screen readers, what is very interesting is the differences between the different screen readers and the differences between the way in which they work with different web browsers. The main reason they work differently with different web browsers is due to the way in which the web browser provides the content to be read by the screen reader, unfortunately this inconsistency makes a developers lives multitudes more difficult  as it is often impossible to take into account every browser/screen reader combination simply due to project time constraints.

Reading about screen readers can only provide you with an idea of how your site might work in a screen reader however Zoe Mickley Gillenwater has posted a series of videos demonstrating this over on her blog. This is very useful to give us an idea of what to expect from screen readers, the one thing that I really noticed is that some screen readers are still using very unnatural speech generation, very much ‘I am a robot’ type talking and if it were me personally using a screen reader I would read the minimum amount of text possible to find out what I want to know, it would be useful to see case studies on how long someone with a screen reader spends on a page, is it longer than someone without or is it shorter.

Fortunately it looks like the W3C are coming to our rescue with the HTML to Platform Accessibility APIs Implementation Guide which should hopefully start to clear things up for both browser vendors and developers about how the APIs should be implemented and used. However W3C do have a reputation for taking there time with these things (CSS 2.1 was only finalised June 2011) so I don’t expect a final draft for at least a couple of years but this does not stop us starting to look at it (after all we have all been using CSS3 for a couple of years already and thats not finalised).

In conclusion, there is a lot to think about when it comes to accessibility on the web, but as developers its our job to not only make our websites accessible but to also push browser and screen reader vendors to start to make our lives easier. Through working together we can make the web more accessible, to quote Paul Irish ‘Accessibility should not be opt-in but opt-out.’.