beardscratchers.com - Journal

Highlighting Google Search Result Pages with Stylish and CSS3

2009-03-22T15:03:55Z

Like most websites, a significant portion of the beardscratchers.com audience arrive via a Google search query—you might well be one of them. And like most website owners, I have a minor obsession with viewing the latest stats to keep track of who’s coming in from where, why and what for.

With Google frequently updating SERPs and different result sets showing dependant on the viewer’s geographical location, a small frustration I’ve had is being able to quickly pick out exactly where my site appears on a Google SERP. Wouldn’t it be nice if any time your site appears in the results of a Google search, it would be immediately visible to you?

From this…

To this…

With just a few lines of CSS and a modern CSS3-capable browser like Firefox or Opera, this is incredibly easy to do! Here’s the code we use:

#	Code
0001	@-moz-document url-prefix(http://www.google) {
0002	#res h3.r > a[href*="beardscratchers.com"] {
0003	background-color: #FFFFAA !important;
0004	}
0005	}
0006

download this code

First up, @-moz-document url-prefix(http://www.google) specifies the rule should run only on URLs that have the prefix “http://www.google”. This should cover all the Google bases—UK, US, Canada, Japan, Germany and so on— and avoid having the rule run on any other site.

Next up, we have a CSS selector that makes use of some of the new CSS3 features of attribute selectors that allow us to perform substring matching on element attributes. a[href*="beardscratchers.com"] pulls out any anchor on the page with an href attribute that contains the string “beardscratchers.com” somewhere within it. ^= and $= allow you to match attributes that start and end with a string, respectively. The difference with CSS2 is that pattern matching can only work with exact matches.

Note that substring matches with the attribute selector doesn’t permit the use of multiple strings to match. So in this example, we would need to duplicate the selector to add multiple sites: a[href*="bbc.co.uk"], a[href*="wikipedia.org"].

Finally background-color: #FFFFAA !important; provides our link with a subtle highlight.

Installing the code

For simplicity, I recommend the Stylish Extension for Firefox. This extension is really just a nice GUI wrapper for a special file in Firefox called userContent.css. This file exists in the user profile folder and allows users to add their own custom CSS rules to any site they view. For other modern browsers like Opera, there are some useful details on userstyles.org for alternative solutions.

Once installed, simply create a new Blank rule:

Paste the code in, change the site URL you wish to highlight, give it a title and click Save:

And that’s it. As a quick test, search for the site’s domain in Google and you should find most of the results have been highlighted.

There’s lots of potential here to do interesting things with CSS on Google SERPs; let me know if you come up with anything useful.

Best API Update. Ever.

2009-03-09T23:58:57Z

One thing I love about all the APIs and web-services out there—especially those from commercial entities—is that they’re driven, designed and built by developers for developers.

They bypass all the detritus in ‘economic leveraging’, ‘strategic incubation’, ‘synergistic e-business’ and the rest of the bullshit and produce something simply for the challenge and love of experimentation. Last week flickr exemplified this beautifully, and really renewed my faith in the development and web community at-large having a good sense of humour. Yet at the same time pushing forward at what’s possible with data and technology. I present:

The Rainbow Vomiting Panda of Awesomeness

If the image wasn’t enough to warrant the highest of praise—I foresee pandas as the new meme to beat unicorns— flickr have just launched a couple of very curious and fun API calls that may have limited usefulness but really exalt what today’s Web should be about.

We’re no longer a passive Web of static, inaccessible content. Today’s Web is a huge, living, breathing pool of data and it’s all about seeing what we can do with it!

Long may the renaissance continue!

Doing the Semantic-Web Tango with Wikipedia and Freebase

2009-03-09T00:16:59Z

Behind the scenes, I’m working hard at writing a much improved Beardscratchers Compendium while still trying to trickle out new features in the current version. Recent browsing will have revealed the automatic inclusion of abstracts for both artists and releases direct from Wikipedia. Implementing this feature seemed, at first glance, to be very simple.

In practice it ended up requiring the use of a completely separate API, lots of RTFMing, and plenty of blind hacking. Let’s start with Wikipedia.

The Wikipedia Problem

Wikipedia is built on top of the MediaWiki software; its content is fully accessible via an API without it needing to build one itself. Great, so what’s the problem?! Go check out the documentation in that API link. Actually accessing Wikipedia content directly involves a lot of hard work. I had imagined it would be a simple case of “query artist name” -> “display article text”. I should try and remember that nothing is ever that simple.

Let’s say we want to use the MediaWiki API to retrieve the content for Sting’s Wikipedia entry, to display it on Sting’s Compendium entry. A read of the docs tells us the URL we’re after looks like http://en.wikipedia.org/w/api.php?action=query&prop=revisions&pageids=123456&rvprop=content&format=xml. The important bit here being the need of a pageid value to retrieve the content.

The only useful query value we do have is the artist’s name “Sting”. A further read of the documentation tells us we can use another API call to search the Wikipedia database with a free-text query. However, take note that Sting’s page on Wikipedia is actually Sting_(musician). Like many articles on Wikipedia, it’s a disambiguated title, used to distinguish identically named articles. There are many articles entitled “Sting”. So how do we know which one to actually retrieve once we’ve managed to get a list of article pageids with the title “Sting”?

The short answer is we can’t. Not without lots of string parsing, munging and making assumptions in code. It’s not really possible to do this without producing a lot of false positives.

To make matters worse, have a look at the data returned from the XML response. All the content is still in wiki format. Even if we were able to pull the exact articles we needed, the content would have to be pushed through a MediaWiki parser before being pushed out into a usable format. I’ve as yet been unable to find a decent standalone wiki parser written in PHP. Please add a link in the comments if you do know of one (Pear isn’t standalone!).

At this point I pretty much gave up… until I happened across the mighty Freebase.

The Freebase Solution

What is Freebase? The official blurb says it’s “a massive, collaboratively-edited database of cross-linked data.”. In essence, it’s an encyclopaedia like Wikipedia but favours facts, relationships and explicit data over written content.

It’s Wikipedia for machines and is a seriously fantastic idea. I’m not sure how I’ve previously manage to miss it. Freebase connects up many external data resources as well as its own data and gives them meaning, structure and relationships. The [open] community pitches in and helps maintain and expand the databases. Metaweb then provides a hugely-featured open API to access this data with its own comprehensive query language to query it with— MQL. While I’m a huge advocate of genuine REST APIs with real RESTful endpoints, the flexibility and potential of the Freebase approach for an open webservice has got me very excited. It’s SOAP, but without all the rubbish it introduces.

So how does it help with this problem of accessing Wikipedia content? As mentioned, Freebase connects many existing data-sets together in a structured manner. Two of these data-sets are Wikipedia and a beardscratcher’s favourite, Musicbrainz. Suddenly one of the world’s largest music databases is unambiguously connected with one of the world’s largest encyclopaedias, providing a huge mine of accurately related and structured information.

Connecting Freebase and Wikipedia

Covering the ins-and-outs of working with the Freebase API is well beyond the scope of this entry, and is expertly covered in the Make section on freebase.com.

In summary, the API has two core calls – database read and database write. Both simply take a single MQL query and return a response. You can experiment with MQL in their handy query editor tool.

As I’m not much of a Sting fan, I’m going to continue this entry with a more interesting artist, My Brightest Diamond. Taking a look at the the Freebase front-end, there’s lots to discover about the artist in the database. Here, we’re only interested in a few small specific pieces of data; namely what is the entry on Wikipedia for the artist “My Brightest Diamond”?

I’m repeating myself now, but I’ll reiterate that Freebase entries are interlinked datasets, and this relationship is formulated (in part) by identifying ‘keys’. Such keys are Freebase object types (like a ‘music artist’ or ‘animal’) or keys from external datasets like the Wikipedia article ID we’re after and the Musicbrainz MBID that uniquely identifies an artist in the Musicbrainz database. The MQL we need to use to query Freebase for an artist’s keys looks like the following:

{
 "query" : {
  "name":"My Brightest Diamond",
  "type":"/music/artist",
  "limit":1,
  "key" : [{
    "namespace" : null,
    "value" : null
   }]
 }
}

This MQL should be fairly self-explanatory. We’re asking for a “/music/artist” with the name “My Brightest Diamond” and want just one result. The null values indicate the properties of the query that we want returned. It’s like saying “Hey Freebase, I’m stuck on a few things. Can you fill in the rest plz?”.

Freebase responds with a number of keys in its response, a subset of which look like:

{
 "namespace": "/authority/musicbrainz",
 "value": "15f835dc-ee52-4b74-b889-113678f54119"
},
{
 "namespace": "/wikipedia/en_id",
 "value": "7490642"
}

Perfect. It appears we have the exact page id to use in a query to Wikipedia for the artist’s entry. What’s also fantastic is that we can actually verify the match by checking the MBID it’s linked to, if we have it available (The Compendium always has the MBID available). There are are a surprising number of artists with identical names!

Finally retrieving Wikipedia content

It doesn’t end there. Recall that I mentioned that the output of the Mediawiki api is wiki-encoded content.

http://en.wikipedia.org/w/api.php?action=query&prop=revisions&pageids=7490642&rvprop=content&format=xml

Screw this approach. Let’s do things old-school, and find an actual wikipedia.org page that uses the page id value and returns something approaching HTML or just plain text. Bingo, printable version. Well, at least someone will be making use of a printable version link (I certainly can’t recall the last time I actually needed to use one).

And that’s it! One accurately matched artist bio. With a little bit of strip_tags() and preg_match() voodoo, and a touch of substr(), extracts of Wikipedia articles now appear on both artist entries and release entries.

How to inline Opensocial Message Bundles for improved performance

2009-03-08T18:14:19Z

In my work at team collaboration startup, Huddle.net, we’ve encountered a number of issues with externally referenced message bundles in our Opensocial application, Huddle Workspaces.

Due to the size and scale of of the application—it’s quite big and complex in comparison to many Opensocial apps—our message bundle XML files contain a lot of content and, as a consequence, consume quite a lot of a bandwidth over the wire.

Why is this a problem? Well, it shouldn’t be, but many Opensocial containers opt not to cache message bundles, and instead request them on every application invocation. The result is that network dropouts, latency or server-load can mean your message bundles occasionally fail to reach the consumer server and entirely prevent your app from loading. End-users shouldn’t ever have to suffer as a result of server-to-server communication.

So, in lieu of consistent caching across Opensocial containers, this issue can be sidestepped by inlining the message bundle content inside your application gadget specification. This is a new feature introduced in Opensocial 0.8.1, and so you should ensure the container you’re working with is operating on a 0.8.1 codebase.

How to Inline a Message Bundle

It’s actually very simple, but it’s also something that isn’t officially documented anywhere. Opensocial development often involves shooting in the dark… but fortunately it’s well enough spec’ed that a little bit of guesswork goes a long way.

Message bundles are always referenced from the <ModulePrefs /> block in a gadget spec, and look something like this:

#	Code
0001	<ModulePrefs title="beardscratchers.com" author_email="nick@example.com">
0002	<Require feature="tabs" />
0003	<Require feature="views" />
0004	<Require feature="setprefs"/>
0005	<Require feature="dynamic-height"/>
0006	<Require feature="settitle"/>
0007	<Require feature="opensocial-0.8.1"/>
0008	<Locale messages="http://beardscratchers.com/lang/ALL_ALL.xml"/>
0009	<Locale lang="fr" country="fr" messages="http://beardscratchers.com/lang/fr_ALL.xml"/>
0010	<Locale lang="es" messages="http://beardscratchers.com/lang/es_ALL.xml"/>
0011	</ModulePrefs>
0012

By simply removing the messages attribute from each <Locale /> element, and placing the relevant message bundle content (excluding the xml prolog), message bundles are no longer referenced externally and load along with your gadget spec:

#	Code
0001	<ModulePrefs title="beardscratchers.com" author_email="nick@example.com">
0002	<Require feature="tabs" />
0003	<Require feature="views" />
0004	<Require feature="setprefs"/>
0005	<Require feature="dynamic-height"/>
0006	<Require feature="settitle"/>
0007	<Require feature="opensocial-0.8.1"/>
0008	<Locale>
0009	<messagebundle>
0010	<msg name="hello">
0011	Hello!
0012	</msg>
0013	</messagebundle>
0014	</Locale>
0015	<Locale lang="fr" country="fr">
0016	<messagebundle>
0017	<msg name="hello">
0018	Bonjour!
0019	</msg>
0020	</messagebundle>
0021	<Locale lang="es">
0022	<messagebundle>
0023	<msg name="hello">
0024	Hola!
0025	</msg>
0026	</messagebundle>
0027	</Locale>
0028	</ModulePrefs>
0029

We’ve found that it’s much more common for gadget specs to be cached hard. Thus the additional weight of inlining your message bundle content inside your gadget XML is negated, and the application should—container-dependant—get some improvements to stability and performance.

There is one caveat. Inlining content introduces maintenance and development issues, especially if you’re running several gadget specs for different enviroments i.e. development, QA and live. In respect of this, I’d recommend keeping all your message bundles in external files and instead adding something into your deployment process that will perform the inlining as and when it is needed.

Linux Tip: Connecting to a Remote Shell with RSync on a Port other than :22

2009-01-18T12:39:58Z

It’s fairly common that server admins will change the port that the SSH daemon listens on, to something other than 22. It’s security by obscurity; adding just a little extra hard work for those nefarious people trying to access public-facing machines they don’t own.

Unfortunately this makes it a bit more tricky to use a number of ssh-enabled commands since it’s not always obvious how to pass the alternative port through. With rsync, it’s pretty easy once you know how.

A normal rsync command to sync files from a remote machine to a local machine—over port 22—would look something like this:

rsync -rav nick@myhostname.com:/home/nick/somedirectory .

So, if instead we wanted to use port 12345, we simply add the --rsh= switch (or -e, which is an alias) to our command. This allows us to specify a *r*emote *sh*ell to connect to; in other words, the parameters to pass to the ssh command. Here’s how it looks:

rsync -rav --rsh='ssh -p12345' nick@myhostname.com:/home/nick/somedirectory .

or using the -e alias:

rsync -rav -e 'ssh -p12345' nick@myhostname.com:/home/nick/somedirectory .

Hopefully that saves a few headaches…

5 Hot Icon Sets for your Next Web Application Design

2008-12-30T10:59:24Z

In this age of web-development, where static brochure sites are truly old-hat and every client demands interactivity, having a consistent theme for user interaction has become one of the most important steps in realising a successful design.

One of the first lessons of HCI is the concept of interface metaphors – singular design elements that quickly infer an action or result of the user based on familiarity and association. The Recycle Bin and the Folder being two of the most well-known.

On the web, icon design contributes to this hugely, and the success of a site’s design is largely thanks to a consistent icon set. Unfortunately most of us don’t have the time, patience (or talent!) to create an all-encompassing set of icons for a project, and so we must rely on the excellent work of designers around the World to help us on our way.

Here are 5 free icon sets, available for commercial use, that I believe fit the bill over the plethora of icon sets available:

FamFamFam Silk

How could I not start with the ubiquitous Silk set. It’s a set that is seen absolutely everywhere, for a very good reason. It’s a huge set of 700 beautifully crafted icons that are free of a strong design-style; able to fit into any design and for any purpose.

» Download FamFamFam Silk

FamFamFam Mint

I’m particularly fond of this small set of minty-hued icons (apparently inspired by Shaun Inman’s Mint). While they might not find their place in every design, their minimalism and space-saving dimensions deserves giving them a look.

» Download FamFamFam Mint

Sweetie

Compact, but useful icon set with a glossy and colourful style. Comes with 4 icons sizes, from 8×8 up to 24×24, for a number of the included icons.

» Download Sweetie

n-design Mini Pixel-Icons

A smart and well-featured set of 320 14×14 icons; particularly good for e-commerce sites, as a good number of credit-card, shopping-cart and basket icons are included. Comes bundled with multiple shades to fit into and brighten up a plain app design.

» Download n-design Mini Pixel-Icons

Pinvoke Fugue

A huge, stylish icon set that I’ve not seen as widespread in the wild as Silk. Certainly one of the best large icon sets available on the Web.

» Download Pinvoke Fugue

Closing Note

Most icon sets come prepared with transparent backgrounds, using PNG alpha-transparency. This type of transparency is unsupported in IE6 and produces undesirable results.

The simplest solution to this problem, is to create alternative versions for IE6 in PNG-8 format (which supports 1-bit transparency). A little bit of pixel-pushing will be needed to make them look perfect, but I’ve never had any problems using this workaround. The Pinvoke and Sweetie sets already come bundled with alternative IE6-friendly versions.

Compendium Videos now Triple Filtered for your Pleasure

2008-11-30T20:41:08Z

Since introducing MTV networks into the Compendium, I happened across Yahoo’s excellent Music API, which offers up the Yahoo music video catalogue as part of the service. Good news, these are now available through the Compendium. This brings the total number of officially released music videos to over 60,000.

Well, almost… In combining the two content networks, I’ve had to be quite careful about what appears where, to whom and how. As I mentioned in a previous post about MTV Networks, video content comes from the most restricted datafeeds used on the Compendium, particularly regarding geographical location. Dependant on your location, and licensing, some videos may not be available.

When videos are loaded in an artist profile on the Compendium, an AJAX request invokes two simultaneous server-side requests to go off and retrieve videos from Y!Music and MTVN—this is cached. Once these are successfully retrieved, they are combined and then passed off for pre-filtering.

Filtering the video feeds involves three steps:

Remove duplicate videos, based on the song title
Remove videos that are not specifically by the artist or under the artist’s name, but may have been returned as part of the webservice search query
Remove videos that are restricted either by geographical location or are not available for external embedding.

Geographical filtering is done with the help of the Net_GeoIP Pear package. This is OO version of the regular Pear GeoIP package that queries the flat Maxmind GeoIP databases. This returns geolocation information based on IP. It is still in beta, but appears completely stable. It can be installed from the command-line using:

$ pear config-set preferred_state beta
$ pear install Net_GeoIP
$ pear config-set preferred_state stable

Conveniently it uses a Singleton pattern to stop the flat database files being initialised multiple times within a script. However it is still by far the slowest data lookup in the Compendium. I wrapped my own lookup methods into another Singleton, and used $_SESSION values to store country and city lookups. This prevent multiple database lookups happening, unless they change, since geolocation is used not only in Video feeds but also Events data lookups. Further improvements can be made by pushing the flat database files into memory or into a DBMS like MySQL.

With this geolocation data at hand, MTVN videos are filtered based on attributes in the returned dataset. Y!Music works slightly differently, in that each geographical location has it’s own base API address, returning videos only available in that region. So Y!Music is filtered at the source, rather than at the point of retrieval.

Once this filtering takes place, the resulting array is checked to see if it still contains any valid videos. If there are no videos available, an empty response is returned to the page. This return value causes the Compendium javascript to invoke another AJAX call to retrieve fallback content from Youtube. Youtube nearly always returns results from its catalogue of x million videos; but these still need a little bit of filtering and nudging to produce accurate results.

All these lookups are cached, and the AJAX lookups are bypassed when valid caches exist, meaning that videos are injected directly into the page when it renders.

If you’re in the US, UK, much or Europe and a few other places, you should see official music videos appearing for selected artists. If not, you’ll get Youtube results appearing.

Some examples:

The last, however, is US only. So to end this post on a high-note, here’s the excellent video by Raf Toro of My Brightest Diamond – Inside a Boy. In hi-def, courtesy of Vimeo (coming soon to the Compendium… perhaps):

Inside A Boy from Rafa Toro on Vimeo.

If you find any bugs with the video feeds, please let me know.

Fixing the Enter Keypress Event in ASP.NET with jQuery

2008-11-30T18:38:23Z

One of the most frustrating things about working with .NET from a front-end developer’s viewpoint is the Single Form Model. Enclosing an entire website or web-application in one single <form> element poses a number of accessibility and usability problems surrounding form input and usage. One of these is ensuring the correct default actions are assigned to sets of input fields when the enter key is used.

Traditionally, the default action for a <form> is to fire the first submit button found within the current <form> element. Every form has one default action.

Striking the enter key within a text input field should submit the current set of—logically grouped—fields; this is the expected behaviour. For pages with multiple forms and actions, this is easily separated by having multiple <form> elements, each with their own submit buttons and actions. Each form operates independently, has its own default action, and doesn’t interfere with other forms.

In the Single Form Model, the presence of just one <form> element, means that different default actions cannot be easily separated. Every input field on the page is automatically tied to just one default action – the first submit button on the page.

Take a blog site as an example – like this very page! It has a search form at the top, with associated submit button, a comment form further down the page and perhaps another form for signing up to a newsletter. Implemented with the Single Form Model, only the search form will produce the correct behaviour as it introduces the first submit button on the page. All subsequent fields will be tied to this same button as their default action – submitting a comment by pressing enter would cause the search form to submit, as would signing up to a newsletter. Not particularly useful.

Can we cure this problem?

The answer is yes… partially. The problem we have concerns UI behaviour. Any solution needs to manipulate and override behaviour, and this is the domain of Javascript. We can’t manipulate the markup in our favour as we’re under the control of the Single Form Model (not without a complete switch to .NET MVC anyway). But there’s a conflict here—javascript is not a fully accessible technology. There are many environments where users do not have Javascript available.

However, in this case, using Javascript is an acceptable answer—this is progressive enhancement of sorts. We’re not adding a dependency on Javascript, merely enhancing the usability of the form inputs for those users with it enabled. Javascript-disabled users will still be able to use the form, except they will experience the ‘broken’ behaviour. Form accessibility in .NET is pretty horrendous anyway, so anything we can do to make improvements is better than nothing at all.

Doesn’t .NET provide a solution already?

Yes, it does in version 2.0 and above. This is the defaultbutton attribute, which can be used in <asp:panel /> and <form>. Fine, so why not use this? There’s no real reason not to, if you’re starting from scratch and don’t mind crufty .aspx pages.

But this wasn’t suitable for me. In an existing codebase, this requires a lot of extra change, and the addition of specific panels to group related sets of form fields is completely unnecessary. An HTML element already exists for that: <fieldset>. Yes, the mighty fieldset-who would have thought?! In any sanely coded page, fieldsets group fields, and so we already have part of the solution without needing to make any changes.

#	Code
0001	<fieldset>
0002	<legend>Search</legend>
0003	<input type="text" id="query" name="query" value="" />
0004	<button type="submit" name="search" id="search">Search</button>
0005	</fieldset>

get this code

The other reason for rolling our own solution is that defaultbutton doesn’t offer the flexibility of applying the default action to any type of button—be it a <input type="submit />, a <button />, an <a href="javascript:..."> anchor and so on. Nor provide any custom event handling when default actions are fired.

A Proposed Solution

1. Connect fieldsets with their default buttons using minimal markup

Although fields are grouped, we still need to provide some relationship between a button and a fieldset. We should provide enough flexibility that our default button could be anywhere on the page, not necessarily within the <fieldset>.

A clean and unobtrusive way to provide the relationship is via a common attribute, the classname. We could use the id attribute, but this should be avoided – you have to accept that when you’re working with .NET, it owns every ID attribute.

Using the classname, we create a unique identifier for the fieldset. If we then add the same identifier to the default button for that fieldset, a useful relationship between the two is created. For this to work best, all identifiers should begin with the same string so that we may write a generic function to pick them out of the markup and identifiers for each button to fieldset relationship must be unique. Here I’ve used “submit-…“:

#	Code
0001	<fieldset class="submit-search">
0002	<legend>Search</legend>
0003	<input type="text" id="query" name="query" value="" />
0004	<button type="submit" name="search" id="search" class="submit-search">Search</button>
0005	</fieldset>
0006
0007	...
0008
0009	<fieldset class="submit-comment">
0010	<legend>Add a comment</legend>
0011	<input type="text" id="name" name="name" value="" />
0012	<textarea name="comment" id="comment"></textarea>
0013	<input type="submit" name="search" id="search" class="submit-comment" value="Submit Comment" />
0014	</fieldset>

get this code

Now we have connected buttons and fieldsets, we need to handle events on the page fired when the enter key is hit.

2. Handle enter key events with Javascript/jQuery

There are a couple of ways we can do this:

Be proactive. Scan the entire DOM on page load, find any fieldsets with a “submit-…” class and bind an onkeypress event to every input inside to connect it with the right button.
Be passive. Use event delegation and listen for keypress events on the page and decide whether we need to handle a default action event for it.

Option 1 is quick to implement, but very inefficient. On every page load, we must scan the entire DOM for <fieldset>s, and then do all the work of binding events to the input elements, even to elements that may never be used. This is computationally expensive and will be a real drag on page startup times.

With option 2, we need only find one element in the DOM, bind one event to it and then wait for the enter key to be pressed:

Using a fast ID selector, $('#content'), we find one containing element for the whole page. It could be <body>, but in this code I’ve gone for an imaginary <div id="content"></div> element that might always surround our site’s content. This element will handle the keypresses for all fields on the page.
To this element we bind an onkeypress event listener function to listen out for any keypress that happen within it— $('#content').bind('keypress', function(e) {});.
We start the function by checking for two attributes of the keypress event. These are both contained within the event object that is passed into the function— e:
1. The key that was pressed
2. The target HTML element that the keypress has bubbled up from.
For valid keypresses— an enter keypress from an input target— we find the input element’s parent fieldset, and extract the classname begining with “submit-”. We use the CSS attribute selector and find any value that begins with (^=) the submit string— ('class^="submit-"').
We can now find the button in the page that corresponds to the identifier, and trigger a click event on it. We need to handle different types of buttons, submits and anchors slightly differently.

#	Code
0001	KeyListener = {
0002
0003	init : function() {
0004	$('#content').bind('keypress', function(e) {
0005	var key = e.charCode ? e.charCode : e.keyCode ? e.keyCode : 0;
0006	var target = e.target.tagName.toLowerCase();
0007	if (key === 13 && target === 'input') {
0008	e.preventDefault();
0009
0010	var parentFieldset = $(e.target).parents('fieldset');
0011	parentFieldset = parentFieldset.filter('class^="submit-"').eq(0);
0012
0013	if (parentFieldset.length > 0) {
0014	var classnames = parentFieldset.attr('class').split(' ');
0015
0016	for (var i = 0; i < classnames.length; i++) {
0017	if (classnames[i].substring(0, 7) == 'submit-') {
0018	var button = $('a.' + classnames[i] + ', button.' + classnames[i], $(this)).eq(0);
0019	if (button.length > 0) {
0020	if (typeof(button.get(0).onclick) == 'function') {
0021	button.trigger('click');
0022	} else if (button.attr('href')) {
0023	window.location = button.attr('href');
0024	} else {
0025	button.trigger('click');
0026	}
0027	}
0028	break;
0029	}
0030	}
0031	}
0032	}
0033	});
0034	}
0035	};
0036
0037	$(document).ready(function() {
0038	KeyListener.init()
0039	});
0040

get this code

If no button is found, we leave the function silently. We could re-trigger the default action, but this is what we’re trying to fix. I think it’s better the enter key stops working completely, rather than producing unexpected or potentially dangerous results if the wrong action is triggered.

Official Music Videos Now Available Across the Compendium

2008-11-19T02:52:14Z

In a bid to improve the accuracy of artist profile pages, I’ve been spending a fair amount of time on cleaning up the problem of false positives occuring when media is retrieved and matched to artists.

One major step in this process is bringing good quality, official music videos into the fold. From today, music videos are available for many artists listed in the Compendium, courtesy of MTV Networks. MTV Networks encompasses not only MTV itself, but VH1, CMT and Logo; meaning that a wide variety of artist videos are served.

From worldwide artists such as Led Zeppelin and Britney Spears, to some of the excellent, but perhaps not so far-reaching, artists like Fleet Foxes and TV On the Radio.

In the event that there aren’t any official videos available, the Compendium will still fall back on Youtube as a source of video goodness and attempt to sift through the chaff of potential matches for the artist being viewed. I’m keen to keep this an option at all times, as user-submitted videos are often more revealing about an artist than carefully planned and meticulously orchestrated official videos ever can be – peculiar fan films, shaky concert and festival footage from the pit, interviews from late-night TV you’d otherwise miss and much more.

Since this is brand new, you may experience a few teething issues. I’m still investigating a few details surrounding the broadcast of music videos, and the availability of these videos across the World. Music is global, but copyright and content licenses are sadly xenophobic areas. And currently just a randomised selection of official videos are being shown for each page-view – paging through videos akin to the way Youtube videos are displayed is due shortly.

Oh, and if you happen to find the Compendium a useful tool, please take a moment to vote for it on Programmable Web -it was a proud “Mashup of the Day” at the end of last month-and feel free to add any suggestions or comments to this journal entry.

Linkedin launch new Opensocial platform, featuring Huddle.net

2008-10-31T01:17:02Z

In case you missed the news, one of the largest business networking sites Linkedin have just launched their new platform for Opensocial applications.

In this initial phase of the platform rollout, Linkedin sensibly took the decision not to open the floodgates to developers and launch with just eight selected partners who could provide application features that are relevant and provide value for the core Linkedin userbase. Business deals aren’t made by virtual high-fiving the CEO of a multinational, and dream jobs aren’t won by poking your prospective employer—well at least not without the risk of legal action.

But enough about Linkedin’s launch from me; there’s lots in the blogosphere and the tech press out there. I want to focus on the most important and exciting aspect of this launch. That being the existence of online collaboration startup Huddle.net as one of the eight partners to be featured in the launch. They are the only UK-based partner—in fact the only one outside the US—and a company that I hold in very high regard… it is the company that I work for. It’s a very exciting time to see Huddle sitting up there against big heavyweights Google, Wordpress and Amazon. And, from the development team’s viewpoint, a somewhat frightening prospect too… scalability in code and hardware is a whole new ballgame.

So, without further ado, I present to you the result of a fair amount of blood, sweat and tears [not forgetting the coffee, cigarettes, beer and pizza] amongst my colleagues—it’s been an incredibly intense couple of months— the Huddle Workspaces application on Linkedin.

“Huddle Workspaces offers private online workspaces for secure team collaboration, document sharing and discussions within the LinkedIn network. Users receive 1Gb of free storage and can collaborate with unlimited connection.”

I’m unashamedly biased, but I do highly recommend you to go and get it installed and simply have a play. There’s a lot more going on in the app than anything else on Linkedin’s platform at the moment. It’s a shame that it’s the only properly interactive and genuinely collaborative tool available. All the others seem, at first glance, to suffer from that rather ugly social network trait of passive “look at me! look at me!” signposting and ignore the point of networking in the first place – to actively connect, engage and collaborate with likeminded people. So, in case you didn’t catch that… install Huddle Workspaces on Linkedin here.

Ok. I’ll stop with the shameless pimping. I do have sleep to catch up on. In future entries I want to write about the more interesting stuff of actually working with the Opensocial API. It’s currently a technology lacking general blog chatter. There are lots of questions out there, but usually with few answers; it was peculiar to discover Myspace as a technical resource. And the documentation is currently too dry/technical and lacking in ‘human’ explanation to be a sufficient one-stop Opensocial resource. If in fact there is something out there I missed, please let me know in the comments.