We simply cannot have democracy be held hostage because the minority wants to prove a point
WI Senate Majority Leader Scott Fitzgerald (R-Juneau).
Republicans in Wisconsin clearly not on board with Federal Republican policy. American politics: Racing downhill, out of control, wearing nothing but a pair of lollerskates.
Source: Wisconsin GOPers Threaten Contempt For Fugitive Dems, Talking Points Memo.
Yesterday, as everyone is no doubt aware, Radiohead released the digital edition of their new record The King of Limbs. I’m infatuated with it, which is not terribly surprising given my love for this band over the past fifteen years or however long it’s been.
One thing I particularly like is the second track on the album: Morning Mr Magpie. It’s a song that’s been around for a very long time indeed, and was first played in 2002, as part of their Radiohead TV Christmas Webcast, prior to the release of Hail to the Thief. I remember being sat up late at night, curled up in a desk chair in my university digs, watching a tiny, pixelated show of bizarre films, DJ sets and obscurity over the course of a few hours (until my connection dropped and never recovered.) This was during their two titles per song phase, and was introduced as ‘Good Morning Mr. Magpie (Good Morning M’Lord)’. It’s not really a very good recording (ripped from a Realplayer stream as it is) and it’s not one of Radiohead’s finest bootleg gems either, but I’ve attached here, for historical note, perhaps.
It’s a song they’ve carried for ten years, reworked and sounding as fresh and brilliant as if they’d just written it.
You can also listen to it on Hype Machine, which you want to do, since it scrobbles.
Gawker has had all kinds of flaming attention for their network redesign, but this is not another post about their broken URLs. I’m not a regular reader of any of their sites, so it’s been interesting to check in and out periodically to take in a first judgements, with what I hope is less prejudice and expectation. I do this because these are interesting redesigns: Lots of fixed positioning; lots of big, dominant imagery; pleasant serifs throughout; and good detail on the UI widgets. It’s not been cheap, and away from the web architecture, it’s not a shoddy realisation of a design.
There are two major flaws that I identify. One is bugs in the right hand navigation, which lists recent headlines. There’s no scrollbar, and it responds very badly to scrolling with a mouse (moving too far too quickly, with an Apple Magic Mouse.) There’s a button at the base of the column for ‘More Headlines’, which scrolls the list by a page, but this is a misguided idea: Nobody thinks to click a custom button to scroll, it’s kinda janky, and you can’t scroll up again. It too scrolls too far, not overlapping items enough to leave you confident you didn’t just skip a headline.
This could be fixed quite easily: Just restore the native scrollbar.
The second problem is more fundamental, and on this issue I think Gawker are in some trouble. They’ve applied the same design to every site on their network. Huge banner image for the featured article, followed by smaller promos. It’s visually arresting and on io9 I think it’s really great. io9 regularly features great images: Screengrabs from movie trailers, comic books, scientific phenomena, or portraits of recognisable actors, or writers. No matter what they write about in a day, there’s almost certainly going to be some great accompanying photography and art to fill that space. The new design is a huge reward for their subject matter (and some credit needs to go to whoever there is responsible for curating it, because they pick good stuff.)
But this design is applied to all the sites in the network. Gizmodo and Lifehacker also have to fill this same, gaping space. Sometimes Gizmodo will get a story about a product that will justify that image: iPhone launch days will look great (not that they’re be there to report in person.) But in general, most new gadgets are uninspiring looking, there are few recognisable personalities, and no rich, illustrative art whatsoever. So the result is what’s seen above. Sparse screenshots of websites overlayed with GIGANTIC TEXT(reverbang.)
It’s made worse because the execution of this oversized lettering is also bad.
It’s application of generic design with no regard for the subject matter and content of the individual sites. It’s trying to brand a network over delivering a functional presentation. I’m pretty sure that’s covered in Design 101.
It’s a shame, because a lot of these ideas, whether they succeed or not are interesting and valuable research.
Updated on 2011-02-19: Redrafted the piece throughout, fixing various typing and phrasing mistakes.
Oh, Github, even when you crash and burn you win at the internets.
Oh no! The #! Internet standards witch hunt mob is at our door!
— Anthony Volodkin, Hype Machine
“Internet-hipster retarded”. #! has created whole new classification… in the minds of cretins.
I have a reasonably well known passion for music, a passion which so far outstrips my passion for blogging that I never actually wrote a ‘Best Of 2009’ music post. There’s one for 2008, and even that took a month to write.
So, no more. Late as it is, I’ve tried to assemble a little list. If anything I’m disappointed because there’s nothing really here that you shouldn’t have heard about already. Trawling through iTunes metadata threw up a number of records which were decent and enjoyable, but hardly seem worthy of a claim to being a defining album of a year. Foal’s [Total Life Forever], Los Campesinos! [Romance is Boring], Jonsi’s [Go], Arcade Fire’s [The Suburbs], and Mumford and Son’s [Sigh No More] were all very good records, with great individual moments, and I listened to them all a lot at various points. Yet when it comes to put them on a pedestal I can’t. So won’t. You should definitely hear those records, though. (Last.FM should be able to springboard you onto Rdio, MOG, Spotify or Hype Machine depending on what’s available to you.)
What remains are the six exceptional records I bought this year then, in alphabetical order by album:
Of all of these records, including those I was a little underwhelmed by and brutally culled from a proper description, there are great tracks.
There are things that we can do in the air that we can’t do when our feet are rooted to the ground, we’ve tried skipping and it wasn’t good enough. Now, we’ve taken a running jump off a cliff, having knitted a parachute out of rope. Even though the rope wasn’t really designed for this, so long as we’ve bound it tight enough it will actually probably work well enough to glide and land. Of course, there are almost certainly a few loose holes that will make the descent a little scary at times, and if it’s wrong then whole contraption will unravel in the air and we’ll fall to our deaths.
Since we’re really good at knitting we will certainly survive, but when we do eventually land, we’ll still be left dragging a parachute that weighs a lot more than it should.
As our feet leave the ground and we look back at the solid ground we’ve left behind, we might wonder if it would had been adequate to use to the rope to abseil down the face instead.
I’m considering presenting all future tech commentary in this format.
This week in web architecture, JavaScript routing hit the fan. Or at least, it did in vast majority of situations where the fan and all of its dependencies loaded over a reliable internet connection. A few were staring at a blank screen, or still trying to figure out how to navigate the new Gizmodo.
Tedious disclaimer because I-work-for-Twitter-but-don’t-represent-the-views-of-anyone-but-myself-nor-and-especially-not-of-our-magnificent-webclient-team-who-are-actually-responsible-for-this-stuff-on-twitter-dot-com-and-may-or-may-not-have-other-priorities-at-this-time-of-night-let-alone-during-the-day.
Let’s get something very clear: Hash-bang URLs are shit. They’re ugly, brittle and a furious hack in the absence of anything else. This week, friend and former Yahoo co-worker of mine Mike Davies wrote up many of the problems with #! URLs, and off the back of Gawker’s massive (and already controversial) redesign it caught on. Attention has been turned on Gawker—who have created a JavaScript application to render each of their sites, with persistent, updating side navigation and a separate content pane, and Twitter which adopted the practice on New Twitter which launched back in October. Facebook do it too.
There are better placed people than me to comment on the Twitter aspect of this, principally anyone who actually worked on the new Twitter site. I did not (in fact, I joined the company after.) In general, I agree with the sentiments and wish for the pattern to go away. (It turns out that it was me who wrote “if site content doesn’t load through curl it’s broken”, and I’ll stand by that.) However, it’s not quite that clear cut, and what I want to document now are faults in the criticisms which have been published recently. Misleading errors and tangents in vitriolic argument really don’t help anything, and distract us from making a clearly robust case and documenting the facts of a risky methodology.
Update: And, lo, better placed co-worker and Other Ben, Ben Cherry has written up #! from a Twitter perspective.
The #! in a URL is a client-side content routing pattern codified by Google. Before this, a small number of sites enhanced with Ajax were either using a solitary # to differentiate content, or nothing at all. The original # hack was developed so that the back button would work in browsers, and so that media playback not be interrupted whilst moving between articles (e.g. on Hype Machine.) It also allows separate content to be bookmarked. Since Google doesn’t read content rendered with JavaScript, they enhanced the # pattern with another character ! so they could differentiate it and handle these sites.
The reason # or #! is in the URL at all is twofold. Firstly, it’s because the site is doing client-side routing: Rather than content being resolved on the server like usual, code in the browser is interpreting the path after the #!, building a custom data query for an API and then rendering the returned data into an existing page.
Secondly, it’s there because it has to be. At the time of writing, there is no universal browser support for altering the actual path of the browser’s displayed URL without causing the browser to also reload the page. When your client is resolving the content instead, that’s not what you want to happen. So instead you listen to the hashChange event in the browser, and work entirely within the URL fragment that is never sent to the server.
Twitter and Gawker redirect requests to old twitter.com/benward/ paths to new-style twitter.com/#!/benward URLs on the server-side, because you can do the redirect very quickly, and maintain a single set of active URLs for all content on the site; always based in the root of the domain.
In the not-too-distant-future, it may become feasible to use new, HTML5-era APIs for pushState which do allow the entire URL path to be rewritten without a #, and doing so will allow for client-side routing without the ugly mark. # will be the fallback for older browsers. Github are doing this already in their repository browser. A different Ben at Twitter wrote about this last July: For a quick write up and demo, see Sane HTML5 history management by Ben Cherry.
Something that Mike wasn’t able to pontificate on in his piece was why a site chooses to to this. Actually, he did suggest that developers were doing this “because it’s cool”. That’s a quite unhelpful line of argument.
The reasons sites are using client-side routing is for performance: At the simplest, it’s about not reloaded an entire page when you only need to reload a small piece of content within it. Twitter in particular is loading lots, and lots of small pieces of content, changing views rapidly and continuously. Twitter users navigate between posts, pulling extra content related to each Tweet, user profiles, searches and so forth. Routing on the client allows all of these small requests to happen without wiping out the UI, all whilst simultaneously pulling in new content to the main Twitter timeline. In the vast majority of cases, this makes the UI more responsive.
Google have studied and documented that even 200 millisecond differences in performance affects a user’s long term satisfaction and engagement with a site.
In Google’s ‘spec’, there’s something very strange. They document that when they crawl the content, rather than just—say—removing the #! and requesting the resource directly using the same path, they take the path and throw that back as an _escaped_fragment_ parameter. That is pretty ugly. Mike goes off on a tangent and talks about equivalence with pre-URL-rewriting formats of index.php?content_id=1234 query strings and the like. This is a red herring.
That uglier URL actually returns the content of the article. So this is the canonical reference to this piece of content. This is the content that Google indexes. (This is also the same with Twitter’s hash-bang URLs.)
The implication is that this is something regular people will see, and that this is a big deal. It isn’t. They won’t. This is used only by crawlers to pull the cached, static version of a piece of content, nothing more. In fact, despite the claim that Gawker’s articles have disappeared from Google, you can search for the Lifehacker announcement post on Google and see that it renders the #! form URL under the result.
It’s not ‘good’, but it is documented, and it doesn’t affect regular users. It also doesn’t affect the art of URL design: You still need to create logical paths with which to query content and hint to users about content. The presence of a #! in the middle is not a substantial difference in that resultant user experience. It is very important not to overstate the _escaped_fragment_ parameter as an important issue. It’s shit, that’s all.
I’ve lost a reference here, sorry. Elsewhere, I read another criticism of #! URLs: That they result in you browsing to confusing locations like http://example.com/dog#!/cat. This is another troublesome line of argument because whilst a badly implemented client might fuck that up, none of the examples cited do. Twitter and Gawker both handle an initial path rewrite on the server side, ensuring that the JavaScript routers always operate from the root of the domain. Let’s not waste paragraphs making hot air of problems that don’t actually happen.
To end: The ‘hash-bang’ problem is a few separate problems with different solutions:
pushState (and a bug in Webkit that meant you can’t update the URL whilst there’s also data transfer going on.) Until a majority number of a site’s user’s have a capable browser, it will be necessary to do the # redirect server-side, else the initial page load (loading a full page, redirecting on the client, loading another page) will be far too slow and hurt perceived performance (which gets us right back to Google’s performance/engagement study, and the reason for doing any of this in the first place.) And although ugly, Google handles them without further disruption to end users (although, Bing doesn’t yet.)The counter arguments to either of these are still numerous, and very well documented all over the web at this point. But you are not arguing against some group of web developers trying to be ‘cool’. You’re arguing against putting content in front of users faster. For some sites that matters a lot (Twitter.) For some sites, it’s fair to argue that their implementation is less appropriate (Gawker.) There are also very fair arguments about granular implementation of this sort of thing (perhaps parts of a site being routed client side, but maintaining crawlable URLs for the permalinks of content.)
I’ll reiterate: I do hope that #! is a short-lived pattern on the web. I hope to see the bugs and browser-share limitations of pushState overcome quickly. I hope to see efforts in frameworks that make it easier to share rendering code between server side and client side. I hope that all the talk over the past few days results in a definitive, facts and measures based reference to consider carefully before adopting client-side routing in other sites, and I hope that this little piece of documentation helps to focus only on problems that are actually exhibited in sites, rather than strict URL theory.
For what it’s worth, my personal overriding argument against #! remains this, based on my experience visiting Vancouver last year: The number of users who choose to disable JavaScript is small and of questionable relevancy; JavaScript errors breaking execution can be almost entirely avoided with good development practices. However, there are people who find themselves on shitty hotel wifi, or tethering over a 3G network, or just daring to live somewhere in the world where packet loss is a problem. It will always be different people, and it can affect us all, even briefly.
We’re all building tools around information and real time communication, and it matters that it works as often as possible.
Changelog:
For the pages in the application that we can do it, we create mirror HTML pages. Those pages are out there on the web — they can be shared, they can be searched, you can find them out there… We know there are billions of other people sharing content on the web, and we want to be part of that.
— The Daily’s editor-in-chief Jesse Angelo
Andy Baio has created a Tumblr blog to index all of The Daily’s content every day, linking to the web-based ‘sharable’ versions of articles primarily published through an iPad app. He expresses some concern about legal challenge, but later updates with this quote from Jesse Angelo.
It strikes me that regardless of the relative merits of The Daily itself this mechanism might be a decent hint at the future of newspaper publishing.
There is tension against pay-walls cutting from the world. Both because it’s annoying for non-regular readers of a publication not to access individual articles, and also because it results in articles skipping historical archival.
There is also tension against entirely advertising driven journalism. The negative impact on the experience of reading an article to begin with, the negative impact on the quality of journalism as it veers toward link-bait, flame-bait sensationalism to drive advertising revenue at the expense of story, and of course the risk of editorial compromise.
The Daily’s strategy is a dedicated app for one particular device, that operates in place of the traditional newspaper, with the bulk of the article content mirrored on perfectly serviceable web pages, but with no index, no front page, no way for someone to read their content as a publication without investing in the app.
Put aside their decision to release specifically on iPad and apply the theory to anything, even just to having a separate website. Newspapers could publish this way, putting atomic articles onto the web for reference and people would pay for their news from their chosen publication to get access to the actual edited aggregation of daily content. Perhaps as an ad-less front page on the web, perhaps in the form of dedicated device applications.
You charge people for the heightened experience of reading, not for the content itself. And, of course, it doesn’t need to be a binary arrangement; arguably existing ad-supported newspaper sites like the Guardian are doing this by charging money for their apps, they’re just not framing it as analogous to buying a newspaper. It’s also the model of the relaunched Readability, which offers to compensate publishers for their ad-free re-rendering of content with cuts from each subscriber’s monthly fee.
The new BBC Broadcasting House: So what does £1bn buy? The Guardian
That’s $1bn over ten years, mind you. Frankly, I think it’s brilliant, beautiful and the various considerations for public access and galleries is outstanding. The comments, of course, are full of the whining fuckwads who always get upset when the BBC do anything nice because it inevitably spends ‘their’ money on something much better than they would have thought of themselves.
Clearly Apple are keeping it a little classier on the Mac than the iPhone.
Citizenship with a small ‘c’: proof not of birth or naturalization, but rather of personal engagement in the virtues of community.
This is something that has come to my mind quite a lot since I started living abroad. There’s a dissonance between the legal and emotional concepts of ‘residency’, ‘citizenship’ and nationality.
(Or: In which I review Instagram, stating various social and technical factors behind its success that you’ve all realized months ago when you started using Instagram.)
Instagramme (I’m still in England) provoked a fairly negative reaction from me when it first launched last year. It seemed to be the latest in the faddy line of fauxlaroid camera apps, had the nerve to lock its social network inside an iPhone-only app, and then that app itself turned out to be a bit on the clunky side.
Curiously, despite my change of attitude, none of those original complaints have been fixed. Gimmicky filters are still ruining great photographs, social features are still locked away on the iPhone (and the website view doesn’t scale properly on the iPhone web view), and scrolling through the activity stream in the iPhone 4 app is still stuttering where Path is smooth like butter.
The most brilliant example of this filters nonsense is the following picture by Jack Dorsey: “Odd light in San Francisco right now. Very yellow.”, wrapped up in a sepia filter. I’m rather hoping that was the joke. I usually get jokes like that, but this time I’m not really sure. Either way, it still makes the point.
Filters are a success besides gimmickry though, because sometimes—especially on non-iPhone 4s—cameraphone pictures come out flat and lifeless. Harsh increases in contrast and saturation make the images pop out, and swapping between filtered and original views inevitably leaves the raw shot looking dull. Wrapped up they way they are, the ‘X-Pro’, ‘Inkwell’, and ‘Gotham’ filters will often fix an image for display.
So Instagram makes it quick to take a picture, supplies a one click fix for lacklustre colour, and then pushes it to lots of people who are far more likely to react than they are on Flickr. This is a reflection on the dismally dated state of Flickr’s new-photos UI, and also on the challenge that Instagram presents by pushing everything together into a single stream in the first place: That you must make each shot count. You’re taking pictures for the purpose of sharing, so you are challenged to make it worth someone’s time to scan over it. It’s a fun challenge.
The picture above is of a milk bottle. We still have those in England you see, delivered to our door by an actual milkman. At Christmas time, the tin foil tops get a seasonal design. This is one of my favourite shots of the year (not that I’ve taken many.) There’s no filter or correction applied at all; just the square crop that Instagram puts on all photographs. The lighting, saturation and depth of field is all from the iPhone 4’s camera, focused on the bottle top, and the slight vignette effect in three of the corners is just how the light falls on our kitchen worktop at 11am. I’m really happy with it.
Though Instagram didn’t do anything to alter the image, it did set the constraints, and it’s that which won me over.
I dearly wish that Instagram had an option to use saturation and contrast sliders (along with a ‘border colour: black or white?’ picker) in place of the olde camera fakery. I’m all for a little bit of colour correction, but the filters are too clumsy for that.
I also wish that I could take something like Path’s lovely cropped expand-contract-scroll display model to browse these photographs, rather than the glitchy overlapping headers that Instagram goes with.
Finally, metadata would be nice. That everything gets lost and stripped out by the time it reaches Flickr (which Instagram natively supports) is a real shame.
In short: I went home to England and became less of a miserable bastard about something that everyone else already liked. What a revelation.
Titles appear to have quietly died again.
They used to be alive: In email subject and body form, in newspaper articles, books and academic papers. The first popular forms of independent, online writing imitated these, basing themselves on the opinion columns of print.
The earliest blogs (such as that of Ev Williams, circa 1998 briefly did away with headings for entries, and instead became title-less streams of paragraph updates. But, when b2, Movable Type, and later WordPress popularised blogging further, titles had returned as an accepted part of the norm.
Everything of that generation separated titles: Flickr had both a title and description for photographs. Delicious had a title and description for links. Upcoming had a title and description for events. RSS—and therefore Atom—had titles separate from body.
One exception for all time was SMS, and maybe that’s important as our generation has come of age and dominates the demographic of the social web, because everything new that today appears to rebel against titles: Tumblr came amongst the first; text entries like this one mark the title field as ‘optional’. Twitter is the most significant, each entry just a little snippet of text. If things had gone differently, Twitter might have ended up as a real microblogging service; a one-paragraph-per-entry blogging tool in the guise of Ev’s old blog, rather than the realtime network it is now.
Instagram? No separation of title and description. Path? No titles, and the descriptions themselves are built structurally from metadata.
Perhaps it’s just a trait of apps simplifying and requiring less of users to create content, especially desirable on portable devices where if not restricted by cramped input, people are restricted by time. Alternatively, it’s a necessary pattern for streaming content, since the frequency of regular updates need to be skimmed and a formal title interrupts that flow. Either way, I don’t think mandatory titles will come back this time.
Sunday afternoon in the park. Photograph by Kelly Hoffer.
