Wednesday 7 October 2009
Thursday 1 October 2009
Tuesday 29 September 2009
This is why I haven't (until now) implemented Google Analytics on my site. A user comes to my site for some content they are interested in, not to enable me to track my user population. So what's change?
Friday 18 September 2009
I'm really pleased. Having spent more time on finding solutions for front-end issues has certainly been worth it. I have been trying to minimise network load through the use of deflating resource sizes, minifying css and js, and easily managing version numbers of resources so that lengthy expiry dates can be used. There are certainly some great solutions out there... so this is what I did:
Deflating resource sizes: For the php files I used
ob_start("ob_gzhandler");. For the css (and future js) used Minify which worked for me when other solutions would not. All full automated.
Minify resources: This is quite labour intensive. To do this, I manually replaced all
@import statements in other css files with the css from those files. Then I ran YUI Compressor to minify the css files.
So what is the outcome of this effort? For my homepage browsers were doing the following:
(ie8 and ie6/7 have conditional comments to load additional css rules) and afterwards:
That's faster page delivery and a snappy response (Host Provider permitting).
Thursday 17 September 2009
There are some really great solutions out there, but none worked for me when it came to deflating stuff. It seems gzipped items, whilst delivered to the browser, are delivered empty. It's definitely due to my host provider's configuration although they say you can gzip php files, so may be there's away.
Over the next few weeks I'll try some different ideas and see if I can get these resources deflated. Until then I'll stick with minimisation using YUIcompressor on the development client.
Thursday 10 September 2009
The architecture I've been creating for a general solution that can be used across different customer sites without changes, is to have a small amount of inline js in each page (preferably as the last tag before the close body tag) that loads up a small external js file when DOMContentLoaded fires that then loads all the other js the developer wants and any additional CSS files that are only used for js the enhancements to a page. In the web page the developer is able to define which js and css resources are needed by using a couple of simple api provided by the inline script; ct.resources.loadJS() and ct.resources.loadCSS().
So far I've been able to keep the inline js portion down to about 1200 bytes compacted (gzipping the HTML page should reduce the network load to about 700 bytes for the inline js), so it's pretty light. It also means that all the js and additional css is loaded _after_ the page has rendered keeping pages light and responsive from the users perspective.
Having researched into loading scripts dynamically and referring to Steve Souders lastest book, Even Faster Web Sites, I decided to base the external file's code around Steve's solutions with some modifications. However, when modifying someone else's code to address issues others have resolved when using similar techniques, as well as optimising the code and making it ready for production use from years of painful experience, always seems to take longer than first thought. Hopefully I'll have it ready in the next day or so, and then I'll be able to add Google Analytics and client libraries such as jQuery and Dojo to my pages without affecting initial page rendering responsiveness.
Wednesday 9 September 2009
Sure I've got skip links on my pages and I'd turned off all styling to 'read' my homepage. But if you close your eyes and run a web page through a screen reader, you quickly find that it's very different from 'reading' an un-styled page. Every time a page is read, all the skip links are read out one after another. The user can use keys to follow links and jump around the page, but if the user has a motor impairment and clicking links or pressing keys is difficult, the accessible usability of the skip links is significantly reduced.
Listening to the links being read out means 'remembering' the links readout. There is automatically an increased cognitive load on the user's memory, and if a user's cognitive ability is slightly impaired then your 'accessible' website is not what you thought it once was. A web site is there for a reason; to allow a user to buy something, find some information, etc. It's not 'to allow a user to buy something, find some information, etc. so long as that user is not disabled'.
So taking the position that a website should be usuable by everyone, what can be done to recover the accessibility of our 'accessible' website?
- Don't crowd all the skip links at the top. Place the skip link immediately before the item to skip. Doing this has the added benefit that the user 'knows without listening' they are not skipping over other items of the site they might want to go to.
- Place a 'Jump to' link (maybe links) at the end of a item to other important items such as navigation, page top, or page index.
- Move the placement of items in the html source. Should the navigation bar always be read before the content of the page the user just told you they wanted to read? What about the header/ banner of the site? These placements are important when visually accessing the site and can still be acheived with a little css.
Why bother? Disabled users have the collective spending power of tens of billions of dollars in the US alone. If a user is visiting your site it is because they want access to what you are offering. Why put up a sign that says 'if you can't reach the counter we don't want your custom'?
I've got some work to do on my own site. I used a modified version of the 960 Grid System that works really well and then added some accessibility features. The site (and yours) would be far more accessible if the placement of un-styled items in the HTML source is considered first and then doing some work in CSS to move those items around into visually pleasing positions.