This is one of those things onto which I’ve been really slow to catch, but which seems to have eluded many other developers so far, so I don’t see sharing it being a waste of time. I eventually decided to look into it this evening and found it’s just as simple to implement as I’d hoped.
I’m talking about allowing browsers to ‘discover’ the search functionality on a site so that users can add it in a couple of clicks to the list of search engines available in the browser’s built-in search box (to the right of the address bar in Firefox, Internet Explorer 7+, etc).
This can be achieved by describing your search engine with an XML file called an OpenSearch description document and providing browsers with a link to that XML in the head of your HTML:
The specification is described in meticulous detail on the OpenSearch site but the examples of the XML description documents are breezily self-explanatory.
Just be aware that if, like me, you can’t be bothered to return results in RSS or Atom and would rather use your site’s existing old-school get query URLs, you probably want to use the following sort of Url element (instead of the fancy-pants RSS one in the “simple” example):
It’s not as if there aren’t already several URL-shortening services, but nonetheless I decided not long ago to start making this and now I’ve got a working version (of sorts) running on the web.
I suppose the challenge that I want to relish is to add something unique to my variation on this simple concept in order that my variation will have a reason for existing. I’m still thinking about what that unique element might be.
MySpace. Home to some of the greatest user-created eyesores on the Internet. Inflictor of immeasurable pain upon web developers employed to shoehorn hacked and mangled code into custom profile layouts—creations of which Dr Frankenstein would be proud. Plagued by reliability problems and exploited by dangerous user-created scripts.
That’s my view of the social network, at least.
On MySpace’s developer site, the long preamble to OpenSocial on the MySpace Developer Platform is a gem of autobiographical prose which presents an entirely different (and patronisingly worded) perspective on MySpace’s code pedigree. A view from the inside, perhaps, where everything we thought MySpace were doing wrong was actually what they were doing right; where the apparently well-deserved repercussions of their shoddy code and lax security were no less than unwarranted assaults on their pioneering social “utopia”.
And a view where MySpace’s inevitable catching-up to Facebook’s well-executed application platform is varnished over with a smug account of how MySpace got there first:
MySpace has a very interesting history with applications written by users. You, gentle reader, may very well have participated in that history.
…
Through a little known technology known as “cut and paste”, users could “install” applications they liked on their own profiles.
There may be more to come here about MySpace’s application platform as I try to develop for it in the near future. If this introduction was supposed to repair relations with developers for whom MySpace has long been a source of mirth, however, it’s had the opposite effect on me.
Recently I wrote about using an image as a form submit button. Essentially I described some basic CSS which most browsers will accept to style an <input type="submit" ... /> as an alternative to using <input type="image" ... />.
What I wrote is anything but groundbreaking and is widely used. And I’ve just found an even better way to do it, by using a button element instead of an input.
What prompted me to look for something better was noticing that Camino, the native OS X Gecko browser, lacks the depth of CSS support for input elements that the more popular browsers, namely Firefox, IE and Safari, have. This means that the many sites which use the technique I described in that post can be unusable in Camino, as form submit buttons appear grey and empty.
But apparently (and I did not realise this until today), using <button type="submit">Submit</button> is a valid and functional replacement for a form input element. And a button is more flexible, allowing you to put an image inside it instead of text, for example. Best of all, though, a button accepts styles more readily in most browsers.
I fixed my form submit button in Camino by changing it to a button and applying exactly the same styles that I had applied to my input. Rather than link you to the post again, here’s the code with the “input” prefix to the class name, just to help you avoid making the same mistake I made.
I’m excited about the potential of the budding SwitchABit platform.
It shows promise of breaking the monopoly that various social tools hold over certain types of social content. It will also help to mitigate one of the causes of these monopolies—the network effect; the runaway success of a particular service once its user base reaches a certain fraction of its market.
We already have services and tools which ease our simultaneous use of the many discrete social tools by helping us to post the same stuff to more than one place. A very simple example is the Twitter Facebook application, which solves the problem of many people using Twitter and their Facebook status for the same purpose by automatically updating their Facebook statuses whenever they tweet.
Most of these existing tools, as far as I’ve seen, require us to feed our data into the helper tool first in order that it can distribute it for us, or that the helper tool (e.g. the Twitter Facebook app) be controlled by the service from which we want to set free content (in that example, Twitter). If I understand it correctly, the paradigm shift in SwitchABit is that the helper tool becomes a transparent intermediate layer, distributing our social content without us needing to know how, or from where, it works.
I recently started using Dave Winer’s TwitterGram: Flickr-to-Twitter service, which has just been ported to become one of the first applications on the beta SwitchABit platform. Flickr-to-Twitter scans my Flickr photostream for me and finds photos which I’ve tagged with a ‘twitterthis’ tag. It creates a tweet-friendly TinyURL for the full Flickr URL of a photo, then tweets the photo’s title and the URL from my Twitter account. Simple steps, but ones which are tedious to perform myself at best, and downright awkward if I’m using a mobile device. Now I can email a freshly snapped photo from my iPhone to Flickr and see it tweeted to my friends very shortly afterwards.
I can’t wait to see more transparent helper tools like this come together to form a pervasive medium for the diffusion all sorts of social content.
Yesterday, during my daily read of Dave Winer’s own RSS feed, I discovered that it was RSS Awareness Day. I really wanted to blog it there and then but hadn’t the time because, ironically, I was working hard at the coalface, hacking away (I like this metaphor) at a client’s RSS-driven microsite.
So in lieu I now declare today “RSS Awareness Day” Awareness Day, because I’m very aware that yesterday was RSS Awareness Day.
During yesterday’s frenzied session I was reminded poignantly that not all of the data in an RSS feed is as reliably parseable as the XML itself. In this case, I was extracting tags from a comma-separated list and putting them into a database.
In my infinite wisdom I put an index on the table which forbade duplicate tags within an item. While parsing 50 items in a test feed nothing went awry but, of course, the very first item on the client’s real feed contained sloppy repetition of tags, exposing my lack of foresight with a nasty SQL duplicate key error.
Most of the sites I develop involve a form of some sort, and usually the designers style the forms with custom buttons.
A simple way to deal with this is to use <input type="image" ... /> which gives the desired appearance and functionality with no fuss.
This is fine for method="post" forms where the information sent to the server isn’t visible to the user. When using a method="get" form, though, there’s an unsightly side effect of using the image input type. The URL will turn into something like this:
http://www.example.com/form.php?foo=bar&x=36&y=18
The X and Y coordinates of where the user clicked on the image are being added to the querystring. Presumably this information was once useful back in the days when people did arcane things like server-side image maps.
I neither need nor want this information and it could even confuse the user. So I go back to my input element, change it back to a type="submit" and get to work on manipulating its appearance with CSS.
First, I take off the border, add a background-image, set the width and height and make the text invisible using color : transparent. This works fine in all of the browsers I want to support except Internet Explorer (6 and 7), which ignores the transparent colour value and displays text on the button in black.
I can still hide this text, though, by adding overflow : hidden and then making padding-top equal to the height of my button. Now it works, in Safari, Firefox and IE!
I think this is awesome. Starting tomorrow (Sunday 27th April - later today if you’re a New Zealander), the Museum of New Zealand Te Papa Tongarewa is going to be thawing and then dissecting a Collossal Squid. According to the BBC article on which I found this, the process will take days, and all of it will be streamed live.
The video streams are live now and I can see an empty thawing bath, a dissection table and some people walking around. I hope to catch them getting started tomorrow.
It would be great to see more engaging stuff like this from other museums and universities over the world. Science and nature encompass us; they’re not just things to be respectfully studied within the walls of a museum. In particular, the great but fairly static institutions in London would do a lot of good for themselves if they could offer something as fascinating as this.
Entries (RSS)