The idea of N-Screen (demo) is to have real-time small-group non-text communication – so for example, sharing a programme (or perhaps a specific point in a programme) with a person, with a TV, or with a group, using drag and drop.
We had a number of very specific requirements:
- Real time communication
- Different types of receivers (people, TV/video players, others)
- Structured data transfer
- Anonymous usage
We also needed good, open tools and libraries available because of the limited amount of time we had to implement.
I’ll talk a little about the requirements in more detail, mentioning some implementation issues as we go.
This is essential for drag and drop between devices to be ‘realistic’ – i.e. for a good user experience. Network issues can always be tricky here, particularly under demonstration (rather than real-life) conditions.
Different types of receivers
A ‘TV’ listens for ‘play’ and ‘pause’ messages and does something with them. A ‘person’ listens for ‘drop’ messages and displays them appropriately. There might also be other kinds of listeners – loggers perhaps, or bots that enhance or modify content dropped to them. All types need to take account of who is joining the group and the kind of thing that they are so that they can do the right thing and display them appropriately.
Structured data transfer
For user experience reasons a fair bit of data needs to be send on most interactions. A shared item needs to have basic metadata (identifier, URL, title, description, image) and also who shared it. Other kinds of message include announcements about the kind of thing you are. We chose Json as the body of the XML XMPP message, though XML would also have been fine or better. One issue is that ‘IQ’ (hidden data) messages cannot be sent to group chats, so that all group messages are visible in a standard chat room if connected to with, say, PSI.
Although there is plenty of potential for connecting N-screen with Twitter and / or Facebook, we didn’t want to require it. In N-Screen you need to give a name so that other people using the application can refer to you, but that’s the limit of the requirement for identification. For scalability and maintainability reasons we didn’t want to create a lot of named users on the XMPP server. Fortunately, XMPP allows you to create group chats with anonymous users, which is perfect for our needs.
We’ve been through many iterations to get here but I’m now pretty happy with the setup we have.
Ejabberd server with Bosh and group chat enabled
Ejabberd is not particularly simple to set up, but once it is up, seems pretty stable. I’ve put some tips on troubleshooting here (scroll to the end). PSI is a great tool for debugging as you can set it to log the XML messages going past.
One thing to note is that for ejabberd at least the group chat URL is
APIs to the content
I used a simple ruby server and mysql backend to generate Json search and random APIs. For content-to-content recommendations for TED we have used TF-IDF analysis of the transcripts using this code by my BBC colleague Chris Lowis.
The workflow is as follows:
- The user goes to a webpage, and gets an alert requesting their name
- All user pages keep a list of all TVs, and on dropping to the TV sends a programme onto all of them
- On leaving the page the user is disconnected from the eJabberd server – this can take a few seconds to percolate to the user interface.
The rest is client-side, which I’ll talk about further in another post. Feel free to try out N-Screen here.