Legends of the Sun Pig

I just finished reading Kate Grifin’s The Midnight Mayor, and last week I read Christopher Fowler’s Bryant & May Off The Rails. Both books are love letters to London. They revel in the thick layers of history, above ground and below. The city is a living thing, metaphorically for Arthur Bryant and John May, and literally for Matthew Swift, the protagonist of Kate Griffin’s series. In both cases, the city can be angered or appeased, coaxed and cajoled into giving up its secrets. Bryant and May, detectives, discover a vital clue in the different patterns of upholstery used on the Underground’s 12 lines; Matthew Swift, a sorcerer, uses the Underground’s terms and conditions of carriage as a powerful magical ward to defend himself.

I’ve never lived in London, only visited, and so I only know it through the eyes of a tourist. But my most vivid memories of the city are of walking through it, not of the shopping or glitzy attractions.

Walking around Covent Garden when Abi and I took the train down from Edinburgh on day in the late 90s, just to have lunch at Belgo’s, and coffee with James. Walking from my hotel near Victoria to the QEII conference centre in the mornings and back again in the evenings, in June 2006 for the @Media conference; a steady soundtrack of At War With The Mystics by The Flaming Lips on my iPod. Walking from Waterloo to the Tower with Abi & the kids, and Jules & Becca; deciding that we were too tired to visit, so camping out at a nearby Starbucks for a cool frappucino instead. Walking from Victoria to Southwark last September for lunch with Bora, because it was a glorious day, and I had the time; gazing up in awe at the Shard under construction.

I’m more than a little tempted to plan a holiday in London solely for the purpose of walking the city, North to South, East to West. Not planning for any stops along the way; just taking it as it comes. Getting underway before dawn, and watching the city come to life around me. Lunch from a sandwich shop, dinner from a chippie. I don’t know how far I’d get, or what I’d see; I don’t actually know the city that well; but that’s part of the point. To walk, to see, to be.

For bookmarks, I like using markers of a time and place: bus, train, and plane tickets; cinema or concert tickets; significant receipts, especially from holidays; appointment cards; other people’s business cards, just after I met them.

After finishing the book, I leave the marker in the book for my future self to discover, years later, and to remember the circumstance of the journey or meeting. Sometimes fondly, sometimes not at all.

…But it doesn’t end there.

On MobiForge a few weeks ago, Ronan Cremin pointed out that most top sites use some form of server-side detection to send different HTML to different devices. In a follow-up article, he takes Google as a specific example to show just how widely its content varies between an iPhone, a BlackBerry Curve, and a Nokia 6300.

I’m not arguing against server-side detection, and sending different content to different devices. I think it’s an essential part of an adaptation strategy. But I just want to quickly point out a few reasons why it’s not enough in order to cover the whole spectrum of browsers. Here are a few things that you won’t know when a browser makes its first request to your web server:

• The height and width of the viewport being used. (Including the device’s portrait/landscape orientation.) If you detect a mobile device, you will be able to look up the device’s “standard” dimensions in a device database, but the user’s actual viewport may be different. If you place a web app on your iPhone’s home screen, and run it without browser chrome, it will send the same user-agent string as when it is running in a browser with chrome (thus reducing the available height). The user may be viewing your site in a browser panel embedded in a separate app, which may present a different viewport. As Stephanie Rieger explained in “Viewports all the way down…“, anyone can create embed a web view of arbitrary size in a home-made ebook.
• The zoom level. Lyza Gardner wrote about how zoom levels and different text sizes can mess up pixel-based responsive layouts. A user-agent string contains no information about whether a user has changed the default font size in their browser. It does happen, and probably more often than you think.

• Whether the user has cookies, and/or JavaScript enabled. I mentioned some of the reasons people disable JavaScript last year. I think that on mobile devices, which are commonly bandwidth-capped and/or rate-limited, people have a greater than normal incentive to disable JavaScript. (I don’t have any statistics to back this up, though; it’s just a feeling.) Lack of JavaScript can play havoc with some client-side detection techniques. (And lack of cookies will trip you up in many more ways; treat that as a general personalization problem.)

Basically, just because the user-agent string says “iPhone” doesn’t automatically mean you’re dealing with 320 x 480. Server-side detection alone will not give you the full picture, and only doing adaptation client-side robs you of the opportunity to perform really useful server-side optimizations. The best approach is a blend of the two, as Luke Wroblewski describes in “RESS: Responsive Design + Server Side Components“.

RESS is MORE.

Further reading:

• Dave Olsen: RESS, Server-Side Feature-Detection and the Evolution of Responsive Web Design
• Ronan Cremin: Mobile web content adaptation techniques

I used to use the Flickr Uploadr tool a lot to upload photos to Flickr, but over the last year or so I’ve found myself doing it less and less — even to the point of wondering if I should keep up my Flickr Pro membership. I think this was because I started using iPhoto. I don’t used iPhoto a lot, but adding one more tool to my photo workflow was enough to make the act of working with photos a burden.

Before iPhoto, my workflow was:

1. Copy photos from camera memory card onto my computer
2. Rename folders & organize photos into archive structure
3. Use Flickr Uploadr to upload photos from hard disk to Flickr, setting correct rotation, photo set and tags
4. Go to Flickr to add photos to the map. Maybe add some titles manually.

iPhoto never simplified these steps for me. It only added to them:

5. Import photos into iPhoto
6. Use iPhoto to organize photos into events, and set the correct rotation. Maybe add some titles manually.

Over time, I drifted into the habit of only placing photos into my own archive and importing them into iPhoto, and skipping the steps of uploading to Flickr. Flickr is not a bad tool by any means, but rotating and sorting in iPhoto is much faster and more immediately rewarding. The extra effort of doing all this again for Flickr put me off doing it at all.

However, at some point in the past, I must have noticed that iPhoto allows you to connect a Flickr account. (Go to iPhoto → Preferences → Accounts, and you’ll see the option to add Flickr, Facebook, MobileMe, and Email accounts. Selecting Flickr will take you to the Flickr website, where you can authorise iPhoto to post photos to your stream on your behalf.) I just didn’t do anything with this option until yesterday, when I discovered the “share” button in the bottom right corner of iPhoto:

From here, you can add the selected photos to an existing Flickr set or create a new one. You can set the usual privacy options, and you can choose whether to upload a scaled-down image or the full version.

This means that I can organize all of my photos in iPhoto, rotate them, name them, add descriptions, set a map location, etc.; and then push them up to Flickr at the press of a button. No added effort. Awesome. This is a workflow I can live with.

Which are the blog entries I will enjoy looking back on most in ten years’ time: the hard-core techie ramblings about irrelevant ancient technical obscurities, or the personal musings that give insight into where my heart was at?

Thought so.

I don’t remember when I got to be as tall as my mum, but Alex is getting pretty close now. This photo is from last week (21 March 2012). Alex will be 11 in just a couple of weeks.

Whenever I’m tinkering with CSS for experimental or debugging purposes, I usually end up adding a ton of properties to help me figure out how things fit together: weird background colours, borders, alternate fonts, etc. I don’t want to leave these properties in place when I put the CSS live, though. To mark a CSS property as a temporary/debug property, I outdent it, putting it at column 0 in the file:

.monkey{
    position:absolute;
    height:200px;
    width:300px;
    top:20px;
    left:20px;
    background:url(/images/monkey.jpg) no-repeat;
border:2px solid green;
    z-index:10;
}

If you diff your code and review your changes before you commit to your version control system (you do use a VCS, don’t you?), it’s often easy enough to spot a debug property, and fix it before you actually check it in. But sometimes the changes are subtle, and they slip through anyway. By outdenting properties, they remain visually obvious in your code even after accidentally pushing them to production.

Sometimes adding a property isn’t the right debugging technique. Sometimes you want to override a property instead — and set yourself a reminder to change it back when you’re done. Because later property values overrides earlier ones, this technique works just as well:

.fez{
    position:absolute;
    height:200px;
    width:300px;
    top:20px;
top:100px;
    left:20px;
    background:url(/images/fez.jpg) no-repeat;
    z-index:10;
}

You can do the same by commenting out the original property, of course, but I find the outdenting technique faster to clean up afterwards.