Tags: twitter

36

sparkline

Unlabelled search fields

Adam Silver is writing a book on forms—you may be familiar with his previous book on maintainable CSS. In a recent article (that for some reason isn’t on his blog), he looks at markup patterns for search forms and advocates that we should always use a label. I agree. But for some reason, we keep getting handed designs that show unlabelled search forms. And no, a placeholder is not a label.

I had a discussion with Mark about this the other day. The form he was marking up didn’t have a label, but it did have a button with some text that would work as a label:

<input type="search" placeholder="…">
<button type="submit">
Search
</button>

He was wondering if there was a way of using the button’s text as the label. I think there is. Using aria-labelledby like this, the button’s text should be read out before the input field:

<input aria-labelledby="searchtext" type="search" placeholder="…">
<button type="submit" id="searchtext">
Search
</button>

Notice that I say “think” and “should.” It’s one thing to figure out a theoretical solution, but only testing will show whether it actually works.

The W3C’s WAI tutorial on labelling content gives an example that uses aria-label instead:

<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>

It seems a bit of a shame to me that the label text is duplicated in the button and in the aria-label attribute (and being squirrelled away in an attribute, it runs the risk of metacrap rot). But they know what they’re talking about so there may well be very good reasons to prefer duplicating the value with aria-label rather than pointing to the value with aria-labelledby.

I thought it would be interesting to see how other sites are approaching this pattern—unlabelled search forms are all too common. All the markup examples here have been simplified a bit, removing class attributes and the like…

The BBC’s search form does actually have a label:

<label for="orb-search-q">
Search the BBC
</label>
<input id="orb-search-q" placeholder="Search" type="text">
<button>Search the BBC</button>

But that label is then hidden using CSS:

position: absolute;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);

That CSS—as pioneered by Snook—ensures that the label is visually hidden but remains accessible to assistive technology. Using something like display: none would hide the label for everyone.

Medium wraps the input (and icon) in a label and then gives the label a title attribute. Like aria-label, a title attribute should be read out by screen readers, but it has the added advantage of also being visible as a tooltip on hover:

<label title="Search Medium">
  <span class="svgIcon"><svg></svg></span>
  <input type="search">
</label>

This is also what Google does on what must be the most visited search form on the web. But the W3C’s WAI tutorial warns against using the title attribute like this:

This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information.

Twitter follows the BBC’s pattern of having a label but visually hiding it. They also have some descriptive text for the icon, and that text gets visually hidden too:

<label class="visuallyhidden" for="search-query">Search query</label>
<input id="search-query" placeholder="Search Twitter" type="text">
<span class="search-icon>
  <button type="submit" class="Icon" tabindex="-1">
    <span class="visuallyhidden">Search Twitter</span>
  </button>
</span>

Here’s their CSS for hiding those bits of text—it’s very similar to the BBC’s:

.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}

That’s exactly the CSS recommended in the W3C’s WAI tutorial.

Flickr have gone with the aria-label pattern as recommended in that W3C WAI tutorial:

<input placeholder="Photos, people, or groups" aria-label="Search" type="text">
<input type="submit" value="Search">

Interestingly, neither Twitter or Flickr are using type="search" on the input elements. I’m guessing this is probably because of frustrations with trying to undo the default styles that some browsers apply to input type="search" fields. Seems a shame though.

Instagram also doesn’t use type="search" and makes no attempt to expose any kind of accessible label:

<input type="text" placeholder="Search">
<span class="coreSpriteSearchIcon"></span>

Same with Tumblr:

<input tabindex="1" type="text" name="q" id="search_query" placeholder="Search Tumblr" autocomplete="off" required="required">

…although the search form itself does have role="search" applied to it. Perhaps that helps to mitigate the lack of a clear label?

After that whistle-stop tour of a few of the web’s unlabelled search forms, it looks like the options are:

  • a visually-hidden label element,
  • an aria-label attribute,
  • a title attribute, or
  • associate some text using aria-labelledby.

But that last one needs some testing.

Update: Emil did some testing. Looks like all screen-reader/browser combinations will read the associated text.

Metadata markup

When something on your website is shared on Twitter or Facebook, you probably want a nice preview to appear with it, right?

For Twitter, you can use Twitter cards—a collection of meta elements you place in the head of your document.

For Facebook, you can use the grandiosely-titled Open Graph protocol—a collection of meta elements you place in the head of your document.

What’s that you say? They sound awfully similar? Why, no! I mean, just look at the difference. Here’s how you’d mark up a blog post for Twitter:

<meta name="twitter:url" content="https://adactio.com/journal/9881">
<meta name="twitter:title" content="Metadata markup">
<meta name="twitter:description" content="So many standards to choose from.">
<meta name="twitter:image" content="https://adactio.com/icon.png">

Whereas here’s how you’d mark up the same blog post for Facebook:

<meta property="og:url" content="https://adactio.com/journal/9881">
<meta property="og:title" content="Metadata markup">
<meta property="og:description" content="So many standards to choose from.">
<meta property="og:image" content="https://adactio.com/icon.png">

See? Completely different.

Okay, I’ll attempt to dial down my sarcasm, but I find this wastage annoying. It adds unnecessary complexity, which in turn, I suspect, puts a lot of people off even trying to implement this stuff. In short: 927.

We’ve seen this kind of waste before. I remember when Netscape and Microsoft were battling it out in the browser wars: Internet Explorer added a proprietary acronym element, while Netscape added the abbr element. They both basically did the same thing. For years, Internet Explorer refused to implement the abbr element out of sheer spite.

A more recent example of the negative effects of competing standards was on display at this year’s Edge conference in London. In a session on front-end data, Nolan Lawson decried the fact that developers weren’t making more use of the client-side storage options available in browsers today. After all, there are so many to choose from: LocalStorage, WebSQL, IndexedDB…

(Hint: if developers aren’t showing much enthusiasm for the latest and greatest API which is sooooo much better than the previous APIs they were also encouraged to use at the time, perhaps their reticence is understandable.)

Anyway, back to metacrap.

Matt has written a guide to what you need to do in order to get a preview of your posts to appear in Slack. Fortunately the answer is not yet another collection of meta elements to place in the head of your document. Instead, Slack piggybacks on the existing combatants: oEmbed, Twitter Cards, and Open Graph.

So to placate both Twitter and Facebook (with Slack thrown in for good measure), your metadata markup is supposed to look something like this:

<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@adactio">
<meta name="twitter:url" content="https://adactio.com/journal/9881">
<meta name="twitter:title" content="Metadata markup">
<meta name="twitter:description" content="So many standards to choose from.">
<meta name="twitter:image" content="https://adactio.com/icon.png">
<meta property="og:url" content="https://adactio.com/journal/9881">
<meta property="og:title" content="Metadata markup">
<meta property="og:description" content="So many standards to choose from.">
<meta property="og:image" content="https://adactio.com/icon.png">

There are two things on display here: redundancy, and also, redundancy.

Now the eagle-eyed amongst you will have spotted a crucial difference between the Twitter metacrap and the Facebook metacrap. The Twitter metacrap uses the name attribute on the meta element, whereas the Facebook metacrap uses the property attribute. Technically, there is no property attribute in HTML—it’s an RDFa thing. But the fact that they’re using two different attributes means that we can squish the meta elements together like this:

<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@adactio">
<meta name="twitter:url" property="og:url" content="https://adactio.com/journal/9881">
<meta name="twitter:title" property="og:title" content="Metadata markup">
<meta name="twitter:description" property="og:description" content="So many standards to choose from.">
<meta name="twitter:image" property="og:image" content="https://adactio.com/icon.png">

There. I saved you at least a little bit of typing.

The metacrap situation is even more ridiculous for “add to homescreen”/”pin to start”/whatever else browser makers can’t agree on…

Microsoft:

<meta name="msapplication-starturl" content="https://adactio.com" />
<meta name="msapplication-window" content="width=800;height=600">
<meta name="msapplication-tooltip" content="Kill me now...">

Apple:

<link rel="apple-touch-icon" href="https://adactio.com/icon.png">

(Repeat four or five times with different variations of icon sizes, and be sure to create icons with new sizes after every. single. Apple. keynote.)

Fortunately Google, Opera, and Mozilla appear to be converging on using an external manifest file:

<link rel="manifest" href="https://adactio.com/manifest.json">

Perhaps our long national nightmare of balkanised metacrap is finally coming to an end, and clearer heads will prevail.

Indie web building blocks

I was back in Nürnberg last week for the second border:none. Joschi tried an interesting format for this year’s event. The first day was a small conference-like gathering with an interesting mix of speakers, but the second day was much more collaborative, with people working together in “creator units”—part workshop, part round-table discussion.

I teamed up with Aaron to lead the session on all things indie web. It turned out to be a lot of fun. Throughout the day, we introduced the little building blocks, one by one. By the end of the day, it was amazing to see how much progress people made by taking this layered approach of small pieces, loosely stacked.

relme

The first step is: do you have a domain name?

Okay, next step: are you linking from that domain to other profiles of you on the web? Twitter, Instagram, Github, Dribbble, whatever. If so, here’s the first bit of hands-on work: add rel="me" to those links.

<a rel="me" href="https://twitter.com/adactio">Twitter</a>
<a rel="me" href="https://github.com/adactio">Github</a>
<a rel="me" href="https://www.flickr.com/people/adactio">Flickr</a>

If you don’t have any profiles on other sites, you can still mark up your telephone number or email address with rel="me". You might want to do this in a link element in the head of your HTML.

<link rel="me" href="mailto:jeremy@adactio.com" />
<link rel="me" href="sms:+447792069292" />

IndieAuth

As soon as you’ve done that, you can make use of IndieAuth. This is a technique that demonstrates a recurring theme in indie web building blocks: take advantage of the strengths of existing third-party sites. In this case, IndieAuth piggybacks on top of the fact that many third-party sites have some kind of authentication mechanism, usually through OAuth. The fact that you’re “claiming” a profile on a third-party site using rel="me"—and the third-party profile in turn links back to your site—means that we can use all the smart work that went into their authentication flow.

You can see IndieAuth in action by logging into the Indie Web Camp wiki. It’s pretty nifty.

If you’ve used rel="me" to link to a profile on something like Twitter, Github, or Flickr, you can authenticate with their OAuth flow. If you’ve used rel="me" for your email address or phone number, you can authenticate by email or SMS.

h-entry

Next question: are you publishing stuff on your site? If so, mark it up using h-entry. This involves adding a few classes to your existing markup.

<article class="h-entry">
  <div class="e-content">
    <p>Having fun with @aaronpk, helping @border_none attendees mark up their sites with rel="me" links, h-entry classes, and webmention endpoints.</p>
  </div>
  <time class="dt-published" datetime="2014-10-18 08:42:37">8:42am</time>
</article>

Now, the reason for doing this isn’t for some theoretical benefit from search engines, or browsers, but simply to make the content you’re publishing machine-parsable (which will come in handy in the next steps).

Aaron published a note on his website, inviting everyone to leave a comment. The trick is though, to leave a comment on Aaron’s site, you need to publish it on your own site.

Webmention

Here’s my response to Aaron’s post. As well as being published on my own site, it also shows up on Aaron’s. That’s because I sent a webmention to Aaron.

Webmention is basically a reimplementation of pingback, but without any of the XML silliness; it’s just a POST request with two values—the URL of the origin post, and the URL of the response.

My site doesn’t automatically send webmentions to any links I reference in my posts—I should really fix that—but that’s okay; Aaron—like me—has a form under each of his posts where you can paste in the URL of your response.

This is where those h-entry classes come in. If your post is marked up with h-entry, then it can be parsed to figure out which bit of your post is the body, which bit is the author, and so on. If your response isn’t marked up as h-entry, Aaron just displays a link back to your post. But if it is marked up in h-entry, Aaron can show the whole post on his site.

Okay. By this point, we’ve already come really far, and all people had to do was edit their HTML to add some rel attributes and class values.

For true site-to-site communication, you’ll need to have a webmention endpoint. That’s a bit trickier to add to your own site; it requires some programming. Here’s my minimum viable webmention that I wrote in PHP. But there are plenty of existing implentations you can use, like this webmention plug-in for WordPress.

Or you could request an account on webmention.io, which is basically webmention-as-a-service. Handy!

Once you have a webmention endpoint, you can point to it from the head of your HTML using a link element:

<link rel="mention" href="https://adactio.com/webmention" />

Now you can receive responses to your posts.

Here’s the really cool bit: if you sign up for Bridgy, you can start receiving responses from third-party sites like Twitter, Facebook, etc. Bridgy just needs to know who you are on those networks, looks at your website, and figures everything out from there. And it automatically turns the responses from those networks into h-entry. It feels like magic!

Here are responses from Twitter to my posts, as captured by Bridgy.

POSSE

That was mostly what Aaron and I covered in our one-day introduction to the indie web. I think that’s pretty good going.

The next step would be implementing the idea of POSSE: Publish on your Own Site, Syndicate Elsewhere.

You could do this using something as simple as If This, Then That e.g. everytime something crops up in your RSS feed, post it to Twitter, or Facebook, or both. If you don’t have an RSS feed, don’t worry: because you’re already marking your HTML up in h-entry, it can be converted to RSS easily.

I’m doing my own POSSEing to Twitter, which I’ve written about already. Since then, I’ve also started publishing photos here, which I sometimes POSSE to Twitter, and always POSSE to Flickr. Here’s my code for posting to Flickr.

I’d really like to POSSE my photos to Instagram, but that’s impossible. Instagram is a data roach-motel. The API provides no method for posting photos. The only way to post a picture to Instagram is with the Instagram app.

My only option is to do the opposite of POSSEing, which is PESOS: Publish Elsewhere, and Syndicate to your Own Site. To do that, I need to have an endpoint on my own site that can receive posts.

Micropub

Working side by side with Aaron at border:none inspired me to finally implement one more indie web building block I needed: micropub.

Having a micropub endpoint here on my own site means that I can publish from third-party sites …or even from native apps. The reason why I didn’t have one already was that I thought it would be really complicated to implement. But it turns out that, once again, the trick is to let other services do all the hard work.

First of all, I need to have something to manage authentication. Well, I already have that with IndieAuth. I got that for free just by adding rel="me" to my links to other profiles. So now I can declare indieauth.com as my authorization endpoint in the head of my HTML:

<link rel="authorization_endpoint" href="https://indieauth.com/auth" />

Now I need some way of creating and issuing authentation tokens. See what I mean about it sounding like hard work? Creating a token endpoint seems complicated.

But once again, someone else has done the hard work so I don’t have to. Tokens-as-a-service:

<link rel="token_endpoint" href="https://tokens.indieauth.com/token" />

The last piece of the puzzle is to point to my own micropub endpoint:

<link rel="micropub" href="https://adactio.com/micropub" />

That URL is where I will receive posts from third-party sites and apps (sent through a POST request with an access token in the header). It’s up to me to verify that the post is authenticated properly with a valid access token. Here’s the PHP code I’m using.

It wasn’t nearly as complicated as I thought it would be. By the time a post and a token hits the micropub endpoint, most of the hard work has already been done (authenticating, issuing a token, etc.). But there are still a few steps that I have to do:

  1. Make a GET request (I’m using cURL) back to the token endpoint I specified—sending the access token I’ve been sent in a header—verifying the token.
  2. Check that the “me” value that I get back corresponds to my identity, which is https://adactio.com
  3. Take the h-entry values that have been sent as POST variables and create a new post on my site.

I tested my micropub endpoint using Quill, a nice little posting interface that Aaron built. It comes with great documentation, including a guide to creating a micropub endpoint.

It worked.

Here’s another example: Ben Roberts has a posting interface that publishes to micropub, which means I can authenticate myself and post to my site from his interface.

Finally, there’s OwnYourGram, a service that monitors your Instagram account and posts to your micropub endpoint whenever there’s a new photo.

That worked too. And I can also hook up Bridgy to my Instagram account so that any activity on my Instagram photos also gets sent to my webmention endpoint.

Indie Web Camp

Each one of these building blocks unlocks greater and greater power:

Each one of those building blocks you implement unlocks more and more powerful tools:

But its worth remembering that these are just implementation details. What really matters is that you’re publishing your stuff on your website. If you want to use different formats and protocols to do that, that’s absolutely fine. The whole point is that this is the independent web—you can do whatever you please on your own website.

Still, if you decide to start using these tools and technologies, you’ll get the benefit of all the other people who are working on this stuff. If you have the chance to attend an Indie Web Camp, you should definitely take it: I’m always amazed by how much is accomplished in one weekend.

Some people have started referring to the indie web movement. I understand where they’re coming from; it certainly looks like a “movement” from the outside, and if you attend an Indie Web Camp, there’s a great spirit of sharing. But my underlying motivations are entirely selfish. In the same way that I don’t really care about particular formats or protocols, I don’t really care about being part of any kind of “movement.” I care about my website.

As it happens, my selfish motivations align perfectly with the principles of an indie web.

Adactibots

I post a few links on this site every day—around 4 or 5, on average. If you subscribe to the RSS feed, then you’ll know about them (I also push them to Delicious but I don’t recommend relying on that).

If you don’t use RSS—you lawnoffgetting youngster, you—then you’d pretty much have to actually visit my website to see what I’m linking to. How quaint!

Here, let me throw you a bone in the shape of a Twitter bot. You can now follow @adactioLinks.

I made a little If This, Then That recipe which will ping the RSS feed and update the Twitter account whenever there’s a new link.

I’ve done same thing for my journal (or “blog”, short for “weblog”, if you will). You can either subscribe to the journal’s RSS feed or decide that that’s far too much hassle, and just follow @adactioJournal on Twitter instead.

The journal postings are far less frequent than the links. But I still figured I’d provide a separate, automated Twitter account because I do not want to be that guy saying “In case you missed it earlier…” from my human account …although technically, even my non-bot account is auto-generated: my status updates start life as notes on adactio.com—Twitter just gets a copy.

There’s also @adactioArticles for longer-form articles and talk transcripts but that’s very, very infrequent—just a few posts a year.

So these Twitter accounts correspond to different posts on adactio.com in decreasing order of frequency:

Notes from a small website

A week ago, I tweeted:

After a long weekend of coding, I’ve got a brand new section on my website.

http://adactio.com/notes/

But that tweet did not originate on Twitter. That tweet is a copy. The original is here.

To be honest, I’ve never been that pushed about having my own bite-sized updates hosted on my own site and syndicated out to Twitter. I’m much more concerned about my photos. Still, I thought it was pretty cool the way that Chloe, Aaron, Amber, and Barnaby have a “notes” section on their sites hosting the canonical URLs of their updates, so I thought I’d give it a shot too.

Michael Bester has written about his online homesteading process. You can also read—or listen toChloe’s process.

Creating a new section on my own site is pretty straightforward. My home-rolled CMS is really creaky and ropey but it gets the job done. The notes section is just another kind of post, same as journal, links, and articles. The tricky bit (for me) was figuring out how to post a copy to Twitter.

It was pretty clear which API method I needed to use. The hard part was all the OAuth stuff. I’ve never meddled with that kind of voodoo before.

I signed into dev.twitter.com and created an application called adactio.com. I’m given an API key and an API secret. This application will only never need to post as me, so I was able to take advantage of single-user OAuth to generate my access token and access token secret:

By using a single access token, you don’t need to implement the entire OAuth token acquisition dance.

Now I had the four pieces I needed to send with a status update:

  1. my consumer key,
  2. my consumer secret,
  3. my access token, and
  4. my access token secret.

I found a small PHP library that uses Andy’s OAuth code. Looking at the source code, I was able to figure out what I needed to send to Twitter. The OAuth class is doing all the hard work—my PHP code is fairly basic.

Imagine my surprise when it actually worked.

I fiddled around with my site’s crude templating system so that if I’m logged into my little CMS, I’m presented with a simple update form on the front page of adactio.com.

Speak your brains on Dribbble

When I type a note into that form and hit “post”, here’s what happens:

  1. I store the note in my own database.
  2. I send a copy to Twitter as a status update.
  3. Twitter returns a JSON object with info about the tweet I just created.
  4. I take the ID of that tweet and store it in my database along with the original note.

Having the ID of the copy on Twitter allows me to provide some Twitter-specific actions from my own site: reply, retweet, fave, etc.

Note on Dribbble

Okay, so now I’m posting to Twitter from my own site. Nifty! But what about receiving notifications from Twitter? If someone replies to, or likes, or favourites the copy of my note on Twitter, it would be nice to get notified about it on adactio.com.

This would be a really complex problem to attempt to solve for myself, but fortunately I don’t have to. Brid.gy is a magical tool written by Ryan Barrett that you can authorise to watch your Twitter profile. It will send a webmention back to the canonical URL on your own site whenever anyone replies to, or retweets or favourites a post.

Because I’ve already got webmentions on my site, Brid.gy worked straight out of the gate—a lovely demonstration of some small pieces, loosely joined.

Responses on Dribbble

Like I said, I wasn’t all that pushed about hosting my own short updates but now that I’m doing it, I’m really, really enjoying it. It feels good.

It feels good to be using my own website for “microblogging”. I know that’s a distasteful phrase but it’s a fairly accurate way of describing how I tend to use Twitter. My earliest tweets definitely feel like short blog posts.

Conversely, looking back on how I was blogging very early on, a lot of those short posts feel like tweets. So it feels good to bring those notes back to adactio.com.

Battle for the planet of the APIs

Back in 2006, I gave a talk at dConstruct called The Joy Of API. It basically involved me geeking out for 45 minutes about how much fun you could have with APIs. This was the era of the mashup—taking data from different sources and scrunching them together to make something new and interesting. It was a good time to be a geek.

Anil Dash did an excellent job of describing that time period in his post The Web We Lost. It’s well worth a read—and his talk at The Berkman Istitute is well worth a listen. He described what the situation was like with APIs:

Five years ago, if you wanted to show content from one site or app on your own site or app, you could use a simple, documented format to do so, without requiring a business-development deal or contractual agreement between the sites. Thus, user experiences weren’t subject to the vagaries of the political battles between different companies, but instead were consistently based on the extensible architecture of the web itself.

Times have changed. These days, instead of seeing themselves as part of a wider web, online services see themselves as standalone entities.

So what happened?

Facebook happened.

I don’t mean that Facebook is the root of all evil. If anything, Facebook—a service that started out being based on exclusivity—has become more open over time. That’s the cause of many of its scandals; the mismatch in mental models that Facebook users have built up about how their data will be used versus Facebook’s plans to make that data more available.

No, I’m talking about Facebook as a role model; the template upon which new startups shape themselves.

In the web’s early days, AOL offered an alternative. “You don’t need that wild, chaotic lawless web”, it proclaimed. “We’ve got everything you need right here within our walled garden.”

Of course it didn’t work out for AOL. That proposition just didn’t scale, just like Yahoo’s initial model of maintaining a directory of websites just didn’t scale. The web grew so fast (and was so damn interesting) that no single company could possibly hope to compete with it. So companies stopped trying to compete with it. Instead they, quite rightly, saw themselves as being part of the web. That meant that they didn’t try to do everything. Instead, you built a service that did one thing really well—sharing photos, managing links, blogging—and if you needed to provide your users with some extra functionality, you used the best service available for that, usually through someone else’s API …just as you provided your API to them.

Then Facebook began to grow and grow. I remember the first time someone was showing me Facebook—it was Tantek of all people—I remember asking “But what is it for?” After all, Flickr was for photos, Delicious was for links, Dopplr was for travel. Facebook was for …everything …and nothing.

I just didn’t get it. It seemed crazy that a social network could grow so big just by offering …well, a big social network.

But it did grow. And grow. And grow. And suddenly the AOL business model didn’t seem so crazy anymore. It seemed ahead of its time.

Once Facebook had proven that it was possible to be the one-stop-shop for your user’s every need, that became the model to emulate. Startups stopped seeing themselves as just one part of a bigger web. Now they wanted to be the only service that their users would ever need …just like Facebook.

Seen from that perspective, the open flow of information via APIs—allowing data to flow porously between services—no longer seemed like such a good idea.

Not only have APIs been shut down—see, for example, Google’s shutdown of their Social Graph API—but even the simplest forms of representing structured data have been slashed and burned.

Twitter and Flickr used to markup their user profile pages with microformats. Your profile page would be marked up with hCard and if you had a link back to your own site, it include a rel=”me” attribute. Not any more.

Then there’s RSS.

During the Q&A of that 2006 dConstruct talk, somebody asked me about where they should start with providing an API; what’s the baseline? I pointed out that if they were already providing RSS feeds, they already had a kind of simple, read-only API.

Because there’s a standardised format—a list of items, each with a timestamp, a title, a description (maybe), and a link—once you can parse one RSS feed, you can parse them all. It’s kind of remarkable how many mashups can be created simply by using RSS. I remember at the first London Hackday, one of my favourite mashups simply took an RSS feed of the weather forecast for London and combined it with the RSS feed of upcoming ISS flypasts. The result: a Twitter bot that only tweeted when the International Space Station was overhead and the sky was clear. Brilliant!

Back then, anywhere you found a web page that listed a series of items, you’d expect to find a corresponding RSS feed: blog posts, uploaded photos, status updates, anything really.

That has changed.

Twitter used to provide an RSS feed that corresponded to my HTML timeline. Then they changed the URL of the RSS feed to make it part of the API (and therefore subject to the terms of use of the API). Then they removed RSS feeds entirely.

On the Salter Cane site, I want to display our band’s latest tweets. I used to be able to do that by just grabbing the corresponding RSS feed. Now I’d have to use the API, which is a lot more complex, involving all sorts of authentication gubbins. Even then, according to the terms of use, I wouldn’t be able to display my tweets the way I want to. Yes, how I want to display my own data on my own site is now dictated by Twitter.

Thanks to Jo Brodie I found an alternative service called Twitter RSS that gives me the RSS feed I need, ‘though it’s probably only a matter of time before that gets shuts down by Twitter.

Jo’s feelings about Twitter’s anti-RSS policy mirror my own:

I feel a pang of disappointment at the fact that it was really quite easy to use if you knew little about coding, and now it might be a bit harder to do what you easily did before.

That’s the thing. It’s not like RSS is a great format—it isn’t. But it’s just good enough and just versatile enough to enable non-programmers to make something cool. In that respect, it’s kind of like HTML.

The official line from Twitter is that RSS is “infrequently used today.” That’s the same justification that Google has given for shutting down Google Reader. It reminds of the joke about the shopkeeper responding to a request for something with “Oh, we don’t stock that—there’s no call for it. It’s funny though, you’re the fifth person to ask today.”

RSS is used a lot …but much of the usage is invisible:

RSS is plumbing. It’s used all over the place but you don’t notice it.

That’s from Brent Simmons, who penned a love letter to RSS:

If you subscribe to any podcasts, you use RSS. Flipboard and Twitter are RSS readers, even if it’s not obvious and they do other things besides.

He points out the many strengths of RSS, including its decentralisation:

It’s anti-monopolist. By design it creates a level playing field.

How foolish of us, therefore, that we ended up using Google Reader exclusively to power all our RSS consumption. We took something that was inherently decentralised and we locked it up into one provider. And now that provider is going to screw us over.

I hope we won’t make that mistake again. Because, believe me, RSS is far from dead just because Google and Twitter are threatened by it.

In a post called The True Web, Robin Sloan reiterates the strength of RSS:

It will dip and diminish, but will RSS ever go away? Nah. One of RSS’s weaknesses in its early days—its chaotic decentralized weirdness—has become, in its dotage, a surprising strength. RSS doesn’t route through a single leviathan’s servers. It lacks a kill switch.

I can understand why that power could be seen as a threat if what you are trying to do is force your users to consume their own data only the way that you see fit (and all in the name of “user experience”, I’m sure).

Returning to Anil’s description of the web we lost:

We get a generation of entrepreneurs encouraged to make more narrow-minded, web-hostile products like these because it continues to make a small number of wealthy people even more wealthy, instead of letting lots of people build innovative new opportunities for themselves on top of the web itself.

I think that the presence or absence of an RSS feed (whether I actually use it or not) is a good litmus test for how a service treats my data.

It might be that RSS is the canary in the coal mine for my data on the web.

If those services don’t trust me enough to give me an RSS feed, why should I trust them with my data?

Twitter permissions

Twitter has come in for a lot of (justifiable) criticism for changes to its API that make it somewhat developer-hostile. But it has to be said that developers don’t always behave responsibly when they’re using the API.

The classic example of this is the granting of permissions. James summed it up nicely: it’s just plain rude to ask for write-access to my Twitter account before I’ve even started to use your service. I could understand it if the service needed to post to my timeline, but most of the time these services claim that they want me to sign up via Twitter so that I can find my friends who are also using the service — that doesn’t require write access. Quite often, these requests to authenticate are accompanied by reassurances like “we’ll never tweet without your permission” …in which case, why ask for write-access in the first place?

To be fair, it used to be a lot harder to separate out read and write permissions for Twitter authentication. But now it’s actually not that bad, although it’s still not as granular as it could be.

One of the services that used to require write-access to my Twitter account was Lanyrd. I gave it permission, but only because I knew the people behind the service (a decision-making process that doesn’t scale very well). I always felt uneasy that Lanyrd had write-access to my timeline. Eventually I decided that I couldn’t in good conscience allow the lovely Lanyrd people to be an exception just because I knew where they lived. Fortunately, they concurred with my unease. They changed their log-in system so that it only requires read-access. If and when they need write-access, that’s the point at which they ask for it:

We now ask for read-only permission the first time you sign in, and only ask to upgrade to write access later on when you do something that needs it; for example following someone on Twitter from the our attendee directory.

Far too many services ask for write-access up front, without providing a justification. When asked for an explanation, I’m sure most of them would say “well, that’s how everyone else does it”, and they would, alas, be correct.

What’s worse is that users grant write-access so freely. I was somewhat shocked by the amount of tech-savvy friends who unwittingly spammed my timeline with automated tweets from a service called Twitter Counter. Their reactions ranged from sheepish to embarrassed to angry.

I urge you to go through your Twitter settings and prune any services that currently have write-access that don’t actually need it. You may be surprised by the sheer volume of apps that can post to Twitter on your behalf. Do you trust them all? Are you certain that they won’t be bought up by a different, less trustworthy company?

If a service asks me to sign up but insists on having write-access to my Twitter account, it feels like being asked out on a date while insisting I sign a pre-nuptial agreement. Not only is somewhat premature, it shows a certain lack of respect.

Not every service behaves so ungallantly. Done Not Done, 1001 Beers, and Mapalong all use Twitter for log-in, but none of them require write-access up-front.

Branch and Medium are typical examples of bad actors in this regard. The core functionality of these sites has nothing to do with posting to Twitter, but both sites want write-access so that they can potentially post to Twitter on my behalf later on. I know that I won’t ever want either service to do that. I can either trust them, or not use the service at all. Signing up without granting write-access to my Twitter account isn’t an option.

I sent some feedback to Branch and part of their response was to say the problem was with the way Twitter lumps permissions together. That used to be true, but Lanyrd’s exemplary use of Twitter for log-in makes that argument somewhat hollow.

In the case of Branch, Medium, and many other services, Twitter authentication is the only way to sign up and start using the service. Using a username and password isn’t an option. On the face of it, requiring Twitter for authentication doesn’t sound all that different to requiring an email address for authentication. But demanding write-access to Twitter is the equivalent of demanding the ability to send emails from your email address.

The way that so many services unnecessarily ask for write-access to Twitter—and the way that so many users unquestioningly grant it—reminds me of the password anti-pattern all over again. Because this rude behaviour is so prevalent, it has now become the norm. If we want this situation to change, we need to demand more respect.

The next time that a service demands unwarranted write-access to your Twitter account, refuse to grant it. Then tell the people behind that service why you’re refusing to sign up.

And please take a moment to go through the services you’ve already authorised.

Tweetpolice

A recent post on the Twitter developer blog called Changes coming in Version 1.1 of the Twitter API has been causing a lot of consternation amongst developers of Twitter apps (and users of said apps). Now it may well be that a lot of this consternation may be caused by some misunderstandings—the post is not very clearly written.

For example, in the section headed Display Guidelines will be Display Requirements, the following dictum is issued:

We will require all applications that display Tweets to adhere to these. Among them: linking @usernames to the appropriate Twitter profile, displaying appropriate Tweet actions (e.g. Retweet, reply and favorite) and scaling display of Tweets appropriately based on the device. If your application displays Tweets to users, and it doesn’t adhere to our Display Requirements, we reserve the right to revoke your application key.

As it happens, I’ve started recently embedding tweets on my site here using the embed code provided by Twitter. But it seemed pretty clear to me that the new proclamation wouldn’t apply to me: the blog post is talking about usage of the Twitter API. So if you retrieve a tweet using the API, you must display it according to the display guideli—er, requirements. Fair enough.

Just to double-check, I asked one of my (many) friends who work at Twitter. “These display requirements …they don’t apply to me quoting a tweet on my blog, right?”

The answer I got surprised me. Apparently the display guidel… requirements do apply to me. If I want to quote a tweet on my website, I’m supposed to use the embed code to make sure that people can favourite/retweet/follow, etc.

Fuck. That. Shit.

If I want to quote something from another URL, I will do it. I’ll use a blockquote element of course, but I will not be told what markup and JavaScript I must include on my site.

This reminds of those companies that don’t get the web, that have rules in their terms and conditions about how you’re supposed to link back to their website. Twitter’s hammerheaded approach seems remarkably clueless for such a hitherto clued-up company.

I’ve gone back through my previous blog posts where I was using the official embed code and I’ve stripped it out of each and every one. If you are quoting a tweet on your site, I strongly encourage you not to use the offical embed code. I strongly encourage Twitter to stick their display requirements where the sun don’t shine.

Here’s something Jason Kottke said:

I love Twitter the service and I am starting to really dislike Twitter the company.

That’s a tweet. I’m quoting it. I’m not using Twitter’s embed code. I’m not adhering to the display requirements.

Come at me, bird.

Update: So, according to Ryan Sarver the new display gui…requirements only apply to API-retrieved tweets after all (as I first thought). I told him that wasn’t what I heard from a Twitter employee and he said:

We need to be clearer, internally as well.

He went on to say:

We don’t expect every reporter/blogger to do the full thing. However, we do want them to link back to author, attribute, etc.

I said a guideline to that effect would be just fine, but a requirement would not. He agreed, comparing it to journalistic standards and ethics.

I could have linked to those tweets I just quoted from. I chose not to.

Hashcloud

Hashbangs. Yes, again. This is important, dammit!

When the topic first surfaced, prompted by Mike’s post on the subject, there was a lot of discussion. For a great impartial round-up, I highly recommend two posts by James Aylett:

There seems to be a general concensus that hashbang URLs are bad. Even those defending the practice portray them as a necessary evil. That is, once a better solution is viable—like the HTML5 History API—then there will no longer be any need for #! in URLs. I’m certain that it’s a matter of when, not if Twitter switches over.

But even then, that won’t be the end of the story.

Dan Webb has written a superb long-zoom view on the danger that hashbangs pose to the web:

There’s no such thing as a temporary fix when it comes to URLs. If you introduce a change to your URL scheme you are stuck with it for the forseeable future. You may internally change your links to fit your new URL scheme but you have no control over the rest of the web that links to your content.

Therein lies the rub. Even if—nay when—Twitter switch over to proper URLs, there will still be many, many blog posts and other documents linking to individual tweets …and each of those links will contain #!. That means that Twitter must make sure that their home page maintains a client-side routing mechanism for inbound hashbang links (remember, the server sees nothing after the # character—the only way to maintain these redirects is with JavaScript).

As Paul put it in such a wonderfully pictorial way, the web is agreement. Hacks like hashbang URLs—and URL shorteners—weaken that agreement.

The medium is the short message

I awoke on my final morning in Florida to find that Jeffrey had written some kind words about a post of mine on responsive design. He also tweeted the link which prompted many questions and comments on Twitter.

I didn’t respond to them.

I have written about responsive web design here in my journal and I’m sure I will have much, much more to say on the matter. But this kind of subject—the sort that requires nuanced, thoughtful discussion—is completely unsuited to Twitter. If anything, Twitter’s tendency (or “twendency”, if you will …’sokay—I just punched myself in the face for that) is to reduce more complex discussion down into simplified soundbites and Boolean values.

Personally, I still get the most value from Twitter when I treat it as a sort of micro-journal, much as I did when I first started using it four and a half years ago. I like Twitter, but it is definitely not the best platform for every kind of online discourse.

This has prompted a call-to-arms from Chris Shiflett:

Most conversation has moved from blogs to Twitter, and although Twitter is more active than blogs ever were, there are fewer quality conversations and debates taking place as a result of this transition. I’m hoping you’ll join me in a blog revival.

The Web Standardistas are rallying behind it:

It might just be the call to arms that shifts our priorities slightly, focusing just a little more on the longer, more considered pieces; posts that are more rewarding to write, hopefully more rewarding to read, and conceivably more likely to be curated.

Drew is on board too:

This isn’t a backlash against Twitter, however. There’s room for both — for quick headline thoughts and for more reasoned posts. I think it would be a shame to have only the former and none of the latter. As such, I’ve been making a bit more of an effort to dust off my own blog and to post some of the things I would normally just tweet.

So is Jon:

The real banquets are blog posts, though. I’ve learnt more from them in the last ten years than I ever will from 140 characters. That’s why blogs are something to be treasured. Blogs and RSS may be dead according to some, but I like that I disagree.

I’m very happy to see my friends and peers make a concerted effort to return to long(er) form writing.

Some of us never stopped.

If you’d like to debate and discuss responsive web design or anything else, I encourage you to take the time to write a blog post. It doesn’t have to be very long, but it’ll probably require more than 140 characters.

Going Postel

I wrote a little while back about my feelings on hash-bang URLs:

I feel so disappointed and sad when I see previously-robust URLs swapped out for the fragile #! fragment identifiers. I find it hard to articulate my sadness…

Fortunately, Mike Davies is more articulate than I. He’s written a detailed account of breaking the web with hash-bangs.

It would appear that hash-bang usage is on the rise, despite the fact that it was never intended as a long-term solution. Instead, the pattern (or anti-pattern) was intended as a last resort for crawling Ajax-obfuscated content:

So the #! URL syntax was especially geared for sites that got the fundamental web development best practices horribly wrong, and gave them a lifeline to getting their content seen by Googlebot.

Mike goes into detail on the Gawker outage that was a direct result of its “sites” being little more than single pages that require JavaScript to access anything.

I’m always surprised when I come across as site that deliberately chooses to make its content harder to access.

Though it may not seem like it at times, we’re actually in a pretty great position when it comes to front-end development on the web. As long as we use progressive enhancement, the front-end stack of HTML, CSS, and JavaScript is remarkably resilient. Remove JavaScript and some behavioural enhancements will no longer function, but everything will still be addressable and accessible. Remove CSS and your lovely visual design will evaporate, but your content will still be addressable and accessible. There aren’t many other platforms that can offer such a robust level of .

This is no accident. The web stack is rooted in . If you serve an HTML document to a browser, and that document contains some tags or attributes that the browser doesn’t understand, the browser will simply ignore them and render the document as best it can. If you supply a style sheet that contains a selector or rule that the browser doesn’t recognise, it will simply pass it over and continue rendering.

In fact, the most brittle part of the stack is JavaScript. While it’s far looser and more forgiving than many other programming languages, it’s still a programming language and that means that a simple typo could potentially cause an entire script to fail in a browser.

That’s why I’m so surprised that any front-end engineer would knowingly choose to swap out a solid declarative foundation like HTML for a more brittle scripting language. Or, as Simon put it:

Gizmodo launches redesign, is no longer a website (try visiting with JS disabled): http://gizmodo.com/

Read Mike’s article, re-read this article on URL design and listen to what John Resig has to say in this interview .

The URI is the thing

Here’s what’s on my desk at work: an iMac (with keyboard, mouse and USB cup warmer), some paper, pens, a few books and an A4-sized copy of Paul Downey’s The URI Is The Thing—an intricately-detailed Boschian map of all things RESTful. It’s released under a Creative Commons license, so feel free to download the PDF from archive.org, print it out and keep it on your own desk.

I love good URL design. I found myself nodding vigorously in agreement with just about every point in this great piece on URL design:

URLs are universal. They work in Firefox, Chrome, Safari, Internet Explorer, cURL, wget, your iPhone, Android and even written down on sticky notes. They are the one universal syntax of the web. Don’t take that for granted.

That’s why I feel so disappointed and sad when I see previously-robust URLs swapped out for the fragile #! fragment identifiers. I find it hard to articulate my sadness, but it’s related to what Ben said in his comment to Nicholas’s article on how many users have JavaScript disabled:

The truth is that if site content doesn’t load through curl it’s broken.

Or, as Simon put it:

The Web for me is still URLs and HTML. I don’t want a Web which can only be understood by running a JavaScript interpreter against it.

If I copy and paste the URL of that tweet, I get http://twitter.com/#!/simonw/status/25696723761 …which requires a JavaScript interpreter to resolve.

Fortunately, those fragile Twitter URLs will be replaced with proper robust identifiers if this demo by Twitter engineer Ben Cherry is anything to go by. It’s an illustration of saner HTML5 history management using the history.pushState method.

Pattern praise

Two months ago, I called Twitter out on their insistence that developers use OAuth when authorising with Twitter while they themselves continued to use the password anti-pattern when they wanted to peek into third-party address books.

I’m happy to report that Twitter have since fixed this. If you go to the Find Friends portion of the “Who To Follow” section, you’ll now be greeted with links that lead to correct authentication with LinkedIn, Gmail, Yahoo and Hotmail.

Thanks, Twitteroonies!

Meanwhile, Flickr recently launched their own “Who to Follow” functionality. There is nary a password request in sight: they’ve implemented correct authentication right out of the gate for Yahoo, Gmail, Hotmail and Facebook.

Thanks, Flickroonies!

See? I’m not always bitching’n’moaning.

Crowdscribing

I mentioned in my last post that I was looking for volunteers to help transcribe the video of my talk at Fronteers 2010. I didn’t get much of a response so I put the word out on Twitter. Then I got plenty of offers.

I owe a pint to these people:

You can see the results of their work here: The Design Of HTML5. Each volunteer transcribed about ten minutes of the talk, which equates to about an hour’s work.

As it turned out, the Fronteers folks had commissioned a transcription from Casting Words, the service built on Amazon’s Mechanical Turk. You can see the result—not bad. I’ve used Casting Words in the past to get transcriptions done although lately I’ve found they take far too long for somewhat inconsistent results.

I think that, for the best results, you can’t beat hiring a professional transcriber. But, in lieu of that, I think the aforementioned volunteers did a great job, for which I am very grateful.

Incidentally, the talk—The Design Of HTML5—is licensed under a Creative Commons attribution licence so if you want to republish it or adapt it, please go ahead.

Continuous partial annoyance

Twitter have been rolling out a new redesign. Thanks to Dustin, I got to try it out when the switch was flipped.

As with any redesign, the initial reaction tends to be It’s different! I fear change! Therefore I dislike this. See also: redesigns of The Guardian, Last.fm, Flickr, BBC…

With Twitter, that initial knee-jerk fades pretty quickly because the new site is undeniably beautiful. The visual design is top-notch.

There’s a nice little addition in the markup, too. The body element has a class name that you can hook into for user stylesheets. This is a very, very, very good thing. For example, my class name is .user-style-adactio so I can add some declarations to my user stylesheet.

The first rule simply hides the egregious Trending Topics and Who To Follow features (and I love that Who To Follow abbreviates to WTF):

.user-style-adactio .trends-inner,
.user-style-adactio .wtf-inner {
 display: none !important;
}

By the way, a user stylesheet is the only time it’s acceptable use important! in your CSS.

My other rules adjust the layout a bit when the viewport gets smaller. It’s just a quick little hack and it’s not great but it’s handy if, like me and Norm!, you don’t like a site dictating how wide your browser window should be. Thanks to user stylesheets, you can fix this:

@media screen and (max-width: 995px) {
 .user-style-adactio #page-container,
 .user-style-adactio #page-outer {
  min-width: 590px !important;
 }
 .user-style-adactio .dashboard {
  float: none !important;
  clear: both !important;
  max-width: 0 !important;
 }
}

Handy tip: if you use Dropbox, store your user stylesheet there. That way, you can point multiple machines to the same stylesheet. I’ve got my laptop at home and my iMac at work pointing to the same CSS file.

There’s one aspect of the new Twitter redesign that I really don’t like, and I can’t fix it with a user stylesheet: infinite scrolling. As I said (on Twitter, of course):

I’m allergic to infinite scrolling

Notice that I didn’t say that infinite scrolling is wrong, it’s just wrong for me. There’s nothing wrong with peanuts unless you have a nut allergy.

The reason that I don’t like infinite scrolling is that I actually use the scrollbar to scroll. That is, I move my cursor over the scrollbar, click and drag. Infinite scrolling makes this unworkable: the scrollbar under my cursor jumps around as new content is loaded.

I figured that in this day of mouse wheels and trackpads, I must be in the minority with my old-fashioned scrollbar usage. I asked for data on Twitter, and sure enough, most people who responded said they used the mouse wheel, the trackpad, the space bar or arrow keys. Though some people still found the scrollbar useful as a visual indicator of how long the page is …which is also negated by infinite scrolling.

Interestingly, while most of the people who responded to my query on Twitter said they hardly ever use the scrollbar, the Firefox heatmap shows that it’s one of the most used interface features. That was a much larger sampling: 117,000 users.

Still, I can understand why Twitter have decided to go with infinite scrolling. If I’m in the minority in thinking it’s horrible, that’s my problem. I can’t even claim that it’s an accessibility problem: it requires more manual dexterity to use the scrollbar than to use other methods of scrolling.

Twitter could add a user setting to switch off infinite scrolling—perhaps replacing it with the old style “more” button, which I liked—but that’s a cop-out. Whenever something gets shunted off into a preference, it’s generally a sign of indecision in the design. The Twitter redesign isn’t indecisive: it has a very clear and consistent visual and interactive design vocabulary. It just happens that one aspect of the UI vocabulary doesn’t mesh well with my own usage pattern.

So, in this case, the solution may well be for me to change the way I use the site. It still irks me, though. I’m generally against any interactions that happen without an explicit request from the user, such as revealing data and functionality on hover, for example. Twitter avoids that particular anti-pattern but with infinite scrolling, the act of moving down the page is interpreted as a request to load more data. I would much prefer to request that data explicitly with a button or link. Of course, that requires that the user do more, so it could be argued that infinite scrolling actually reduces the number of interactions that the user is required to do …assuming that the inferred interaction is in fact the desired interaction. That’s a big assumption.

On the face of it, it would seem that Twitter are being somewhat dismissive of the scrollbar as a UI element. But that’s not true. While they are reducing the usefulness of browser-native scrollbars by using infinite scrolling, they are, at the same time, replicating the functionality of scrollbars but non-natively. If you reveal a side panel—by clicking on someone’s Twitter username, for example—and if the content doesn’t fit within the viewport, then a non-native scrollbar is generated.

scrollbars

As I said, the new redesign is wonderful. I’m just nit-picking ..but it’s a big nit.

OAuthypocrisy and the Passwordpocalypse

The OAuthcalypse is upon us. Since August 31st, all third-party Twitter services must use OAuth to authenticate. This is a good thing; a very good thing. Before that date, services were allowed to use the password anti-pattern to log you in.

Twitter has put its foot down and declared that the password anti-pattern will no longer be tolerated. Hurrah!

What a shame then, that Twitter is being utterly hypocritical. On their Find Friends page, they encourage you to:

Scan your email address book or contacts to discover which of your friends are already using Twitter.

They do this using the password anti-pattern. You are asked for your Gmail password even though the Google Contacts API would allow Twitter to connect to Gmail using proper authentication …exactly what Twitter is insisting third-parties use when they want to access Twitter’s data.

Twitter asks for your Yahoo Mail password even though the Yahoo Contacts API would allow them access to your address book using OAuth.

Twitter asks for AOL passwords (now there’s an audience that we shouldn’t be teaching to give their passwords away) but even AOL has an API with proper authentication.

Twitter does connect to LinkedIn correctly. That’s one out of four.

There are two solutions to this state of affairs. Either Twitter decides to do the right thing and switch over to using APIs and authentication for Gmail, Yahoo and AOL …or else Gmail, Yahoo and AOL follow Twitter’s example and disallow the password anti-pattern for scraping address books.

Twitter should not be encouraging Gmail users, Yahoo users and AOL users to divulge their passwords but at the same time, Gmail, Yahoo and AOL should be taking steps to ensure that such profligate behaviour is not rewarded.

Twitter has done the right thing with third-party services wishing to access its data. Now let’s see if the third-party services currently being abused by Twitter will follow this example.

Update: There are some very encouraging responses from Twitter. Ryan Sarver says:

all good points and I think there are already plans to fix it

And Josh Elman concurs:

yes - great points and something we hope to migrate very soon

Let the right tweet in

It’s de rigueur for non-human entities to have a twitter account these days; magazines, diseases, spaceships and buildings. Brighton’s Duke of York’s cinema has been on twitter for a while now.

As with most twittering organisations, the stream has news of future events, such as the impending visit by Charlie Kaufman. But rather than simply using Twitter as another channel for announcements, the people behind the account are using it to have a proper conversation with the cinema’s audience. Hence the requests for movie marathon suggestions or late night shows.

A couple of weeks ago, they posted this irresistible tweet:

anyone that fancies seeing Let The Right One In at a spooky late night screening on Thursday 2nd April DM us for tickets

So I did. That’s why I found myself in the Duke of York’s cinema at 11pm last night, sitting on a comfy sofa up in the balcony, drinking a (free) Swedish beer, watching a mesmerising, beautiful, frightening film (imagine if Twilight had been directed by Bergman).

Watch this film. If you live in Brighton, you know where to go.

Speed

From BBC News at 15:07 GMT on Tuesday, March 3rd, Space rock makes close approach:

The object, known as 2009 DD45, thought to be 21-47m (68-152ft) across, raced by our planet at 13:44 GMT on Monday.

From Low Flying Rocks on Twitter at 13:45 GMT on Monday, March 2nd:

2009 DD45 just passed the Earth at 9km/s, approximately seventy-four thousand, eight hundred km away.

Small world, loosely joined

I’m in Seattle. Dopplr tells me that Bobbie is showing up in Seattle on the last day of my visit. I send Bobbie a direct message on Twitter. He tells me the name of the hotel he’ll be staying at.

I use Google Maps to find the exact address. All addresses on Google Maps are marked up with . I press the in my bookmarks bar to download the converted vcard into my address book. Thanks to , my updated address book is soon in the cloud online. My gets the updated information within moments.

I go to the address. I meet Bobbie. We have coffee. We have a chat.

The World Wide Web is a beautiful piece of social software.

Antipatterns for sale

Twply is a straightforward little Twitter app that sends @replies to email. It uses the password anti-pattern. Oh, but don’t worry. It states quite clearly on the site that Your password is safe with us. No worries!

Twply is up for sale …sold. That means all those passwords are available to the highest bidder ($1200 in this case).

Sleep tight, Twply users. May you wake to a better day.