Skip to a section of this page:

Ramblings

Archive

Large content, an eternal golden conundrum

May 3rd, 2010

I’ve always been a fan of flexible layout and trying to avoid introducing horizontal scrollbars whenever possible. Large content however poses an eternal conundrum: How to accommodate large content in tight spaces?

Some web designers like to lock a page design to a fixed width (or set a minimum width) forcing a horizontal scrollbar at lower resolutions for the entire site. This approach however does not accommodate some of the larger content types and I feel its a missed opportunity to maximise accessibility. A flexible layout allows your design to be adaptable and optimised for the device/resolution currently being used to view it.

I’ve been playing with some ideas that can be used in conjunction with any layout to accommodate wide content as easily as possible at lower resolutions.

With this example, trying resizing your browser window, make it fairly narrow.

  • Large content such as tables should expose a horizontal scrollbar just below the table at low resolutions.
  • Images will be scaled down to fit the width available automatically. Scaled images also gain the ability to zoom to full size on click (which also introduces a horizontal scrollbar for the image).

The code is not production ready yet (IE6 in particular needs work) but it should give you an idea of where it’s heading.

Let me know what you think!

Posted in
Accessibility, CSS, DHTML
Tools
1 Comment

On detecting keyboard focus

April 11th, 2010

Strong/clear focus highlighting for links and UI elements has great accessibility benefits, but it can also detract from the appeal of a site/application or distract users who are not used to this type of UI feedback. It is keyboard and alternate input device users that benefit most from strong/clear focus highlighting.

I’ve created a new jQuery plugin that allows you to style elements focused via keyboard navigation clearly while leaving elements focused via mouse events with default highlighting (or at least less dramatic highlighting).

This plugin takes the default behaviour of the Chrome browser (as of version 4) and replicates it across all browsers. Chrome gives strong yellow/orange highlighting to links/inputs that have received focus via the keyboard.

Let me know what you think? Is this useful to you? Is there a better way to make the distinction?

Posted in
Accessibility, DHTML
Tools
2 Comments

Harvest the web

April 5th, 2010

The last few weeks I’ve been trying to find ways to interact more easily with the Steam Community data that is exposed for all Groups and Users with public profiles. I was frustrated by the fact that Valve have not publicised an official API for interacting with this data and that the unofficial efforts failed to meet the scope I was looking for — not to mention being badly broken due to changes to the HTML of the target website.

My initial thought was to follow a model similar to this new project. But this approach leaves a number of common scraping problems unresolved:

  1. No caching. Each time data is required, the code will request the source HTML from the target URL
  2. Linear performance. Each time data is required, the code must process the HTML into API objects
  3. Relies on well-formed XML. If PHP’s SimpleXML extensions receives tag-soup the solution will fail
  4. Complex code to maintain. When the target website changes the structure of their HTML, it means a complete re-write of the majority of the API code

Enter the Reaper

To address these issues, I have been developing Reaper. Currently a PHP implementation that doesn’t require any extensions or external libraries. Reaper attempts to condense the common tasks of scraping into small blocks of efficient code and cache the results transparently for best performance:

  1. Reaper requests the URL (via YQL). HTML returned is tidied into well-formed XML and cached
  2. Reaper accepts your data definition array which maps data labels to XPath queries, RegEx expressions and/or callback functions to scrape the relevant data
  3. Reaper caches the resulting data object and returns it to you

There’s more work to do to improve error-handling and documentation, but so far I’m pretty pleased with the results.

Meanwhile, I’ve stumbled onto Steam Condenser, so I may not need to roll my own Steam Community API after all :)

I’m keen to hear suggestions and feedback, so let me know what you think as a comment, using the contact form or on Twitter.

Posted in
PHP
Tools
No Comments

My first public WordPress plugins

March 22nd, 2010

I’ve been playing with WordPress for a fair while now. Hacking together themes, trying and modifying existing plugins, writing my own simple plugins from time to time. Generally doing too much in the theme files, and not enough abstraction into proper plugins.

Recently I’ve decided it’s time to bite the bullet and formalise some of these hacks, so I bring you my first two public WordPress plugins:

  • Custom default avatar

    Plain vanilla WordPress provides a list of default avatars to choose from, but doesn’t allow you to choose an image of your own making. This plugin allows you to specify your own default avatar

  • Custom app icons

    This plugin allows you to specify icon(s) to be used when iPhone / iPod Touch users create a shortcut to your site using the ‘Add to Home Screen’ function in Safari

I hope you find these useful, and eventually I will think about submitting for inclusion in the Wordpress.org plugin directory. Before I do however, I’d appreciate any and all feedback, for example: any functionality limitations, plugin faux pas, coding style issues, etc…

Let me know what you think!

Posted in
PHP, WP Plugins, iPhone
Tools
No Comments

WordPress performance revisited

December 6th, 2009

Stefano asked if I had numbers to back up my previous performance claims regarding WordPress performance plugins. Today I ran some tests to be able to provide those numbers.

All tests were performed:

Results

The “baseline” results represent tests without DB Cache Reloaded, Hyper Cache, or GZIP Output plugins installed. Different combinations of these plugins were then tested. Each combination was tested 10 times and the results have been averaged.

This site (irama.org) — number of seconds to render HTML of the homepage
test baseline DB Cache Reloaded Hyper Cache DB Cache Reloaded + Hyper Cache DB Cache Reloaded + GZIP Output
1 0.325 0.294 0.299 0.409 0.292
2 0.458 0.447 0.322 0.318 0.335
3 0.366 0.267 0.493 0.290 0.313
4 0.287 0.299 0.765 0.331 0.269
5 0.740 0.319 0.393 0.311 0.512
6 0.807 0.276 0.315 0.435 0.354
7 0.351 0.270 0.348 0.280 0.343
8 0.347 0.403 0.361 0.292 0.290
9 0.412 0.298 0.321 0.336 0.263
10 0.418 0.263 0.286 0.364 0.267
Avg. 0.451 0.314 0.390 0.337 0.324
A more complex client site — number of seconds to render HTML of the homepage
test baseline DB Cache Reloaded Hyper Cache DB Cache Reloaded + Hyper Cache DB Cache Reloaded + GZIP Output
1 3.116 2.477 2.198 2.287 2.693
2 2.663 0.749 2.542 0.712 0.895
3 2.820 1.008 2.382 1.143 1.221
4 2.390 0.799 2.501 0.827 0.880
5 2.304 0.758 2.581 0.939 0.939
6 3.348 0.795 2.364 1.068 1.109
7 3.150 0.866 2.248 2.483 1.172
8 3.139 0.989 2.512 1.125 0.912
9 3.115 0.789 2.667 0.939 1.092
10 2.525 0.776 2.306 2.613 0.910
Avg. 2.857 1.001 2.430 1.414 1.182

Analysis

My previous recommendation of Hyper Cache was primarily because it provides GZIP compressed HTML. Since the results for DB Cache Reloaded + Hyper Cache were not as strong as DB Cache Reloaded alone, I looked for an alternative plugin that might provide GZIP compression without as much of a page render performance cost.

I tested the GZIP Output plugin, and while it still seems to negatively impact on page render time, I believe the addition of GZIP compression — which will lower the size of the transmitted HTML file — is worth the small hit on render performance.

Note: If your web server compresses HTML output from PHP files automatically (or it can be configured to do so) then use that approach instead of using the GZIP Output plugin as it is likely to perform slightly better. The other benefit of this approach is that compression will also be applied to the HTML output of PHP files that are not part of WordPress (if you have any).

Conclusion

In terms of performance (on a shared hosting environment) disk IO is expensive, but DB access is more expensive. So while Hyper Cache alone makes a difference, DB Cache Reloaded makes a greater difference. YMMV, but in light of this data, I would update my recommendation…

For best WordPress performance, use the following plugins:

  1. DB Cache Reloaded
  2. WP Minify
  3. GZIP Output (only if your web server doesn’t GZIP HTML output from PHP automatically).

Note: If DB Cache Reloaded is not an option with your hosting provider, or you aren’t able to get it working, Hyper Cache is still a good option (remember: you won’t need GZIP Output if you have Hyper Cache installed).

Finally…

I hope this helps. Let me know if you have feedback about my methods/results, or if you have other WordPress performance tips.

Posted in
Wordpress
Tools
2 Comments
« Older Entries
Newer Entries »