Alex Little

This morning we relaunched the Cohere website. It’s almost a complete re-write of the old site and has a much improved user interface (we did plenty of user testing to try and get this right) as well as:

• Group management – you can now create groups of users for collaborative working
• API – for remotely adding, editing and reading data from the Cohere database
• Scheduled RSS importing – you can now set your RSS feeds to be imported into Cohere daily
• Firefox plugin – for creating ideas and connections as you browse the web

If you find any bugs or have any suggestions for improvement then please visit the Cohere support site.

Today I met attended a workshop with BTCV to try to decide on the future of the Volunteer Passport that I was involved with a few months ago (especially as I’m not going to be here to maintain it).

The Passport hasn’t been used that much yet – but there are several reasons for this, firstly that it’s not been promoted anywhere yet (many people in BTCV don’t know about it), secondly, it’s functionality is slightly confused and thirdly, it still need finishing off.

The original purpose of the Passport was to allow volunteers to record their skills and experience and then use this as evidence to put towards formal qualifications (NVQs etc) and act as an ePortfolio system. However since we decided to use Elgg as the basis for the system, this opened up the possibility of it becoming a social network for BTCV.

Much of our discussion today was about whether or not BTCV should be providing a social networking system for it’s volunteers (why not just use facebook?) and how it could be justified. We eventually came to the conclusion that it probably could be justified if we had some good use cases and evidence of how it would benefit current BTCV activities, but that the system as it stands would need  work on the interface design (layout, structure and terminology).

If there is anyone out there who is interested in following up this work (especially from a technical/development point of view) then please drop me a line and I’ll put you in touch with the BTCV team

This morning I received an invitation to join Fire Eagle – Yahoo’s location sharing application, so I’ve just been having a little play. I’d actually forgotten all about it since I saw a presentation about it at the FOWA last October and must’ve asked for a beta account then.

On it’s own Fire Eagle isn’t much use – but the idea is that you allow Fire Eagle compatible applications and devices to read and/or update your location, so you only have to update your location once for all the applications to know where you are at any time (subject to all the privacy settings available). So to actually try it out I downloaded the Loki toolbar – which can automatically update your Fire Eagle location based on your (wireless) network connection. Though I’ve installed it on my desktop PC so my location is unlikely to change much (I’ve not moved my desktop PC for nearly 2 years!) – but it did pick up my location reasonably accurately for what I assume is an IP based lookup (I’m actually about a mile from where it autodetects).

The privacy with an application such as Fire Eagle is a high priority (as I remember being mentioned in the FOWA presentation) and there are plenty of ways you can allow different applications different levels of privacy (e.g. how exact the locations are) – but then each application (as with Loki) has it’s own set of location sharing privacy options. All of which seems to make for a mind-boggling array of confusing options (in my mind anyway!).

My main reason in looking at Fire Eagle initially was to see whether we could hook MSG up to it, so your MSG location was auto-updated, so I’ll have a look into the Fire Eagle developer section and see how feasible and quick this will be to get set up.

The OU SocialLearn project has been running a little ‘behind the scenes’ for the last few months and I’ve kept broadly up to date with what’s going on, but I’ve not been deeply involved (and OK, I’m still not sure what variation of the words ‘social’ and ‘learn’ make up the proper project title). Rather than me explaining it all here, Martin has posted an overview.

The SocialLearn API is now available (though I don’t think it’s public yet), so I had a catch up with my colleagues Liam and Nick, who have each been building applications using the API. Liam’s work has been on ‘Microlearner’ which links up Twitter to the SocialLearn API, so you can post learning goals to Twitter and they’ll magically be available in your SocialLearn profile. 2Learner is Nicks application, which allows you to search for resources.

From chatting to Liam and Nick it seems there’s still a way to go with the API (unsurprising as it’s a work in progress), for example, there’s currently no way to relate a resource to a learning goals, but I think this may change in the future.

The API has much in common with the Facebook API, in that there is a core set of functions and associated data on the SocialLearn server, then any applications can build upon these, but these applications are siloed, (i.e. applications can’t share any other data than that available through the API). While this might be fine for Facebook, and is entirely appropriate for that (especially with all the privacy issues involved), I’m not sure if this approach may restrict the range of applications that may be developed with the API – I’m assuming throwing buns and being bitten by vampires are not top priorities for SocialLearn.

We had a think about how we can get Cohere talking to the SocialLearn API, and what makes sense as a demonstration using the 2 existing applications. What we came up with was the ability to import your learning goals into Cohere, and then be able to organise then in a more structured way, but additionally to allow you to push out any ideas you enter into Cohere as goals in SocialLearn. Each of these will be fairly trivial to do, albeit in a not very clever way… so best get on with it ready to demo next week.

Yesterday, we discovered that some of the users on Cohere were actually spam, the usernames were random characters and the descriptions on these users profiles consisted entirely of links for loans, pills etc (all the usual spam). To try and stop this happening again I’ve added reCaptcha to the user registration form.

This was really easy to implement, the only slight change I had to make was to fix the code so requests to the recaptcha servers went through our proxy (shame there aren’t optional params to add proxy details – but easy enough to fix).

A couple of weeks ago, Peter (one of the OU graphic designers) asked me if Cohere could produce nice graphical timelines (the BBC has some really nice ones). He’s been tasked to produce one for one of the OpenLearn courses and was thinking about the best way to do it – and so it could be replicated easily (when he gets asked to make another one for another course). Peter pointed me at Simile from MIT – which is a kind of Google Maps API for timelines.

My response was that Cohere couldn’t currently provide exactly what he was looking for (we’ve not really worked on many different visualisations yet), however, you could use Cohere as the repository for providing data (via the Cohere API) to Simile. All we’d need to do would be add the facility to add a date to an idea/node, and another formatting output options to get the data in the way that Simile requires. (Note to self: should also add location option for ideas/nodes so they could be displayed on a Google Map as another visualisation option for Cohere)

Yesterday I had a go with this on my Cohere development server, so can now add dates to nodes and export in the correct format for Simile. I also created a little script so that I can show my blog postings on a Simile timeline:

This timeline is dynamically generated and shows the last 100 of my blog postings. If you’d like to have a look at the script I’ve used for generating this, then you can download it. Depending on where you post it up (relative to your WordPress installation), you may need to slightly alter line (no. 14) to point to your wp-config.php file.

The main downside that I’ve found so far with Simile is that is will only allow data to be dynamically loaded via XMLHttpRequest. This means that the data source must reside on the same domain as the page you’re displaying the timeline on (unless you can use a iframe as I have done above) – it would be fantastic if Similie could also accept data via JSON and so avoid the cross-domain problem (I’ll need to check whether this has already been added as new feature request in their issue tracker).

Then completely coincidentally, this morning I saw this post from Stuart about Dipity – an online timeline creator. So I’ve had a very quick play with it this morning – creating the following timeline (also of my blog):

This took about 30 seconds to produce, buy just adding the URL of my blog feed.

These two timelines, although displaying the same data, are obviously quite different with Dipity is far more graphical, though IMHO a bit cluttered and not so easy to read. Simile looks quite grey in comparission, though I’ve not yet explored the API fully and how you can customise the colours/display. Dipity is much quicker to get up and running with, but my feeling is that Simile would offer more flexibility (within bounds), for example I can’t tell yet if Dipity has the capability to show events which span a period of time (i.e. have start and end dates – as Simile allows).

(Looking at Dipity has reminded me that we should create an RSS feed for Cohere nodes).

Any pointers to other timeline visualisations appreciated

I’m surprised it’s taken them so long… (admittedly it might have been there a little while and I just haven’t noticed!)

Will have to investigate and see what it’s actually built in, whether you can log in using a different client and if you can add contacts from outside FB? I suspect that you’re tied to using their client and your only contacts are your facebook friends.

“Does MSG do multi-user chat?” is something we’ve been asked about countless times, and our response has always been no, and we’re not intending to add this feature, on the basis that many other clients already offer this functionality and we’re not here to reinvent the wheel.

Well, this is only partly true! The MSG web-client interface doesn’t offer the facility to create and join chat rooms, but the server that MSG runs on does (OpenFire Jabber server). This means that if you have an account on our MSG server, you can log into this account with another Jabber compliant client, which does have chat rooms.

Liam and I have been trying this out this morning using the Pidgin client (he’s also just had a meeting with few people using it) and all seems to be running well, these are the steps you need to go through…

1. Create account on MSG (use the register link)
2. Install Pidgin and connect to the msg server (msg.open.ac.uk) using you rnew username and password
3. From the ‘Buddies’ menu in pidgin, select ‘add chat’
4. Create a name for your room (only seems to like alpha-numeric characters, so no spaces)
5. Fill in the options you want, or just leave on the defaults

We found the ‘invite’ function a bit flaky (didn’t track down the exact cause or where it was going wrong), but you can just give people the name of the room you’ve created for them to join.

Any feedback/comments etc welcome

I’ve finally got around to having a look at OpenSocial, following it’s launch last year (and all the subsequent blog postings) I’ve not really heard too much about it, or who’s actually implemented it, but it seems quite a few social sites have done (though obviously not facebook): hi5, Ning, MySpace to name a few. My comments below are my first impressions from only having looked and played with the docs/examples for couple of hours, so feel free to correct me if I’m wrong about anything below!…

The first thing I needed to find out was what OpenSocial actually is and what it gives you (apart from the generic description that it’s an API for social web applications). My impression had been that (and I don’t know why I thought this), as well as a way to write applications (Google Gadgets) that can run in compatible social sites, OpenSocial would also help solve the problem of having multiple disparate networks of friends on different social sites, so you didn’t need to recreate your friends network when moving between different social sites. Unfortunately this doesn’t appear to be the case (please correct me here if I’m wrong!), but it does give application developers the chance to build applications for social sites which will run in multiple sites, rather than having to learn a different API each time.

The problem of friends being on different networks was one we came across when thinking about developing a Facebook application for MSG. Users would already have a set of contacts in MSG, but how to link match these up to Facebook friends. The point of having MSG in Facebook, or any other social site, would be so that you can chat directly to your friends within that network. It seems we could run up against the same problem if we created an OpenSocial MSG Gadget too.

I did find this little video about Shelfari and their OpenSocial implementation that we should be able to learn something from – though even after watching this I’m still a little confused as to how your Shelfari friends match up to your friends in Orkut :-/ . Then I got slightly distracted looking at some blog postings about Shelfaris invitation process – it appear rather similar to how Facebook used to (or still does?) automatically invite all your email contacts.

The part that I found most interesting (and also most confusing) was how you could make a social site compatible with the OpenSocial API (i.e. allow users to add applications to their profiles). It certainly seems a non-trivial task to create a site which would be compatible with the OpenSocial API – which is why in the tutorial I get pointed to a number of “container” sites which will allow me to test out my new (hello world) Gadget.

So… will be having a think now about how we can apply some of this to Cohere – and what should a Cohere Gadget embedded in a social network site actually do/look like?

I’ve just posted up some installation screencasts for MSG server to help out anyone trying to install it… more info.

Has also made me think that maybe I should go back and create one for using MSG within OpenLearn – specifically with a scenario for why you would want to use MSG within OpenLearn.