Found out this morning that the OU are going to be trialling unified messaging with MS Office Communicator. Up until now we’ve basically used email (and occasionally the phone!) to get in touch with colleagues, but we’ve never had any actual presence information alongside this – so you’re not sure if someone is actually in the office or away on holiday (people don’t always turn on their out-of-office auto-replies).
Some of us use MSG for getting presence info to see if people are around and available and having quick chats, but there hasn’t been a big take up in the organisation for using instant messaging (well, not for work anyway!). So I wonder how much the instant messaging aspects of Office Communicator will actually get used. I guess the integration with Outlook/Exchange would have a big bearing on this. If you know that someone is in the office and free you might just call or IM them instead – so maybe we’ll see a reduction in the number of emails flying around?
Not sure what all of this means for MSG and FlashMeeting (Office Communicator also has video-calling) – though I’m sure they’ll live on, especially for communicating with people outside the organisation.
When I was developing the MSG presence maps we also thought about how we could replace or enhance the BuddySpace custom maps – which give you an office plan and presence icons for who is in the office and where. The original BuddySpace maps worked well, but they were a pain to update when staff started or left – meaning it was often out of date.
As the MSG presence maps were using the Google Maps API, we thought about using a custom Google Map for the office plan. Unfortunately, it remained just a thought and we never got time/chance to actually implement anything.
What reminded me of all this was a posting on the excellent Google Maps Mania blog about a couple of applications using custom Google Maps. The first is a map of the UCL campus, with the buildings overlaid – I really like the option of setting the transparency of the overlay. And the second is an office plan from LaudonTech.
UCL Campus Map:
Now what would be really good is combination of these 2 apps, so at a certain point of zooming in on a Google Map with the campus outline overlaid, you zoom down to the office plan for each building (would need to think about how to cope with different floors) adding in presence info from MSG. How about something like this for the OU campus?
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.
“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…
- Create account on MSG (use the register link)
- Install Pidgin and connect to the msg server (msg.open.ac.uk) using you rnew username and password
- From the ‘Buddies’ menu in pidgin, select ‘add chat’
- Create a name for your room (only seems to like alpha-numeric characters, so no spaces)
- 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?
We’ve just enabled anonymous access to the MSG source code – previously we asked people to contact us via email to get an account. More info
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.
Firstly, a slightly belated Happy New Year!
Yesterday we had an interesting discussion about how we could evaluate and review the social tools included in OpenLearn, namely, the Knowledge Mapping (with Compendium & Cohere), MSG and Flashmeeting. Our feeling is that they’ve not been as successful as we first hoped, and there maybe lots of different reasons for this. For MSG I’ve detailed some of the possible reasons in a JIME paper that will be published soon.
It’s quite interesting to compare how OpenLearn is viewed externally to the OU vs how it’s seen internally (and within the OpenLearn team). The feedback we have from external users is that, to paraphrase, “OpenLearn is great, I can get free OU content”, whereas I’m slightly dissappointed that MSG isn’t used more than it is. I guess the difference is due to the fact that users may see the site as a way of getting content, and not necessarily somewhere they can come to to gain access to tools, such as IM, video-conferencing etc.
Since my post last week, I’ve been trying to get the little bugs fixed up. For the first problem with LiveJournal OpenIDs, the reason turned out to be due to the fact that the parameters needed to be received by the LiveJournal server as a post request, and the association request was being sent as a get – hence the failure. This appears to be due to v1 of the OpenID spec stating that association request parameters should be sent in the post, but in OpenID spec v2 my reading is that parameters can be sent with either a get or post.
In the end I used a different library (openid4java) instead – I couldn’t figure a way to just ‘turn off’ the association requests (they are only optional) with the library I was using, and this appears to have fixed the issue with the delegation too.
So our OpenID server is using the JOID library but the MSG client is using the openid4java library
Since my posting yesterday about allowing users to sign in to MSG with OpenIDs it seems that quite a few people have had a go… all good stuff… but has also highlighted the fact that there are still a few bugs that we need to get ironed out…
Firstly, that LiveJournal OpenIDs (eg alextlittle.livejournal.com) aren’t being accepted, haven’t quite worked out why this is yet
and secondly, that it’s not handling OpenID delegation – this one has only just been reported to me so will take a look when I get chance.
The OpenID login for MSG is still fairly experimental so cheers all for your feedback and keep it coming