My iFrame usability-gaffe (dommigheid met iFrames)

A couple of days ago I created a small survey to see what people consider sexism (a hot topic currently in the local press and online). For that purpose I embedded a Google Docs Form in an iFrame in a HTML-page on my own site. While following up on the results as they got posted, I noticed a significant amount of respondents were male and aged below 15. Weird, as I had expected that group to be somewhat absent from the results and as the next age-group, 15-20, was indeed barely present. What the heck was happening? My stupidity, that was what was happening!
A long time ago I wrote about problems with iFrames and (simple) solutions for some of those issues on this blog, and more specifically:

When a visitor clicks a link at the bottom of a long page inside an iframe and the target is a shorter page inside the same iframe, then he/she will see a blank page which is … well not very usable, no?

And that was exactly what was happening; after having filled in the first, long page of the Google Docs Form, respondents clicked on “Continue” and -depending on the screen resolution- all they saw was a “Submit”-button and not the questions (age, gender and optional e-mail) before that were hidden from view. How utterly stupid of me, especially as I created a small JavaScript thingie, frameMagic.js, to fix just that problem. I implemented frameMagic.js (and made a small change in there for it to work on iFrames without an id) so the number of male participants aged under 15 should drop considerably as. And I guess I’ll have to do some math to make the results less skewed.
(in Dutch: door een stomme technische fout van mij en mij alleen, is er een significant aantal antwoorden op de “Korte zomerjurkjes-seksisme-enquête” toegekend aan de categorie “man van jonger dan 15 jaar”. Het probleem is rechtgezet en ik zal de antwoorden op een correcte manier  herwegen om min of meer relevante dingen te kunnen zeggen over de resultaten.)

Quick hack: making Journalist slightly more responsive

I’ve been using the Journalist WordPress theme ever since I migrated to my self-hosted instance, away from back in 2007. The Journalist is a pretty basic theme, 2 columns and fixed width. The last version on dates from mid 2008, but the developer did work on support for threaded comments and sent me a beta-version (1.9.1) in January 2009 which I currently use. A couple of months later, after having been stalked by yours truly for info on further development, Lucian replied he was busy with other projects and that he could not do too much “free” work any more (which is completely understandable). Ever since, I’ve been making small changes left and right, fixing minor bugs and making small improvements.
But the problem with fixed width themes such as Journalist; they’re not responsive. Although responsive design is great and all, I didn’t really bother with it until I needed some responsiveness to be able to test upcoming changes to my own WordPress plugin. And that’s why I added the following in /wp-content/themes/journalist/style.css:

@media only screen and (max-width: 880px), only screen and (max-device-width: 880px) {
  #container, #content { width: 98%; }
  #sidebar { display: none; }
  #bubble { background: none; height: 32px; margin-top: -24px; position: static; }
  #bubble p { background: none; color: #000000; font-size: 14px; }

This is just a quick hack, making the main content div variable in width, hiding the sidebar and moving the tagline from the bubble on the right to the left, underneath the site title for all screens with a width of 880px or less.
Feel free to use and to provide improvements in the comments or via the contact-form! And Lucian, if you happen to read this: any chance anyone could resume work on the Journalist?

Content Security Policy; Great! or Wait?

A couple of days ago I had another look at Content Security Policy, a technology that allows a site to tell a browser resources are allowed to be loaded to protect against XSS and some other types of web application vulnerabilities. CSP was originally devised by the Firefoxians, but is in the process of being standardized by the W3C with support in Firefox, Chrome, Safari and even the upcoming Internet Explorer 10.
The functionality offered by CSP (blocking requests that are not allowed) is pretty close to what WP DoNotTrack tries to do, so I decided I’d try to integrate CSP in my plugin, based on the following assumptions:

  • CSP-mode will only work for WP DoNotTrack if it is configured to use a whitelist
  • As most WordPress+plugins installations are bound to have pages with at least inline JavaScript and/or style, I have to add “unsafe-inline” to allow those to continue to work (which indeed limits the level of protection against XSS-attacks)
  • Given that a lot (most?) WordPress installations implement WP Super Cache of W3 Total Cache, it will -at least in a first stage- only kick in if WP  DoNotTrack is configured to filter unconditionally
  • Ideally the JavaScript-based component of WP DoNotTrack would “see” that CSP was activated and would not perform those nifty JavaScript AOP trickery

The “proof of concept”-quality code I ended up adding to wp-donottrack.php was pretty simple:

function wp_donottrack_csp() {
 global $listmode;
 if ($listmode==="1") {
  $csp="default-src 'self' 'unsafe-inline'";
  if (is_array($whitelist)) {
   foreach ($whitelist as $white) {
    $csp.=" *.".$white;
  header("X-Content-Security-Policy: " . $csp); //FF & MSIE10
  header("Content-Security-Policy: ". $csp); //new standard
  header("X-WebKit-CSP: " . $csp); //chrome & safari
add_action('init', 'wp_donottrack_csp', 10, 0);

With this code on my testblog I started playing around in a couple of browsers. Based on that experience I found the following limitations:

So in this particular context (and specifically the absolute need for “unsafe-inline”), I’ve decided to hold off implementing CSP (I might implement iFrame sandboxing as support for that is coming with IE10 and will probably also land in Firefox 17). But if you have full control over a particular website or -application (meaning you can remove all inline JavaScript and CSS and all instances of evals in insourced JavaScript) and you want to harden your installation to stop cross-site scripting, you really should start thinking about implementing CSP (as Twitter seems to have done already)!

As found on the web (August 15th)

blog (feed #46)
youtube (feed #51)
frank liked 2 videos.
blog (feed #46)
youtube (feed #51)
blog (feed #46)
youtube (feed #51)

My take on “Web design in a Retina world”

I read an interesting article on Johan Ronse’s blog about how to design (or is it “develop”?) for a Retina world (Retina being Apple’s marketing speak for high pixel density screens, but you guys knew that). I’ll be honest, I’ve not followed up on all the Retina-buzz, if only because this performance-nut isn’t particularly happy about the sudden need for higher quality images being shoved down people’s data-throat (same with webfonts actually). Because, after all, 14Mb really isn’t “nothing” Johan, given the average webpage is around 1.1Mb.
What seems to be missing in the few articles I did read up until now is this; why do we want to deliver high resolution images to high pixel density screens to users on a broadband connection (assuming we can keep others safe from these high fidelity images, but that is doable)? Because it looks better? Maybe, but what purpose does that serve? What purpose does your site serve? Do you want people to stick around and return, reading your stuff for a long as possible? Or are you in the ad displaying business? Maybe you sell products or services? The question is; how are Retina-ready images going to impact your KPI’s?
Let’s assume those nice crisp images will have a positive impact on your site’s usage and/or ad views and/or sales and let’s also assume (although it is a proven fact rather than an assumption) that the longer download time will have a negative effect on your business. Given these two assumptions; which one will have the biggest impact? My hunch would be the negative impact of longer download time, but I’m biased. The answer to that question really depends on your KPI’s, on your business and on the technical implementation.
The only sound advice anyone could give: do multi-variate testing, compare your KPI’s for your site with and without Retina. Going Retina might help your business, it might harm it. I for one am not switching to Retina any time soon, I don’t see the need for it from the safety of my ivory performance-tower. I’m biased, you know.

Everything in its right place, om ter mooist gecoverd!

“Everything in its Right Place” van Radiohead (ja, daar ben ik weer) is al veel gecoverd. De Brazil/deep house versie van Osunlade ft. Erro kent ge ongetwijfeld, die had ik hier als eens geplugd. Maar er zijn even goed interpretaties van klassieke geschoolde muzikanten zoals pianist Christopher O’Riley (hier ook samen met het Entropy Ensemble) en cellist Joshua Roman (met DJ Spooky) of hier nog Steve Polydorou and the Stellar Quartet. Er is de brave koormeisjes-versie van Scala & gebroeders Kolacny, er is een big band interpretatie van Beats & Pieces Big Band en ook jazz-pianist Brad Meldhau speelde het. De Japanse Math rock-groep Lite  heeft een nogal bizarre instrumentale cover terwijl Sonos dan weer volledig a-cappella gaat.
Maar de hoofdprijs van deze avond gaat naar Robert Glasper, een jazz-pianist die “Everything” subliem laat versmelten met het superbe “Maiden Voyage” van Herbie Hancock. De studio-versie zit achter deze link, maar hieronder zie en hoor je het Robert Glasper Trio live Radiohead en Hancock combineren. Ma-gis-traal (als ge niet bang zijt van jazz-drummer gone wild, anders begint ge misschien beter met de bravere versie van Brad Meldhau)!

Robert Glasper Trio - Maiden Voyage/ Everything in its right place - Bridgestone Music Festival `09

En ja, op 18 oktober sta ik ook in het Sportpaleis. Natuurlijk!