Yesterday I was sitting in a very interesting meeting with some experts in data visualisation. There was a lot of impressive things presented and the name of Wii remote and Kinect were mentioned a couple of time. As I observed so far, these devices are used as cheap way to get sensors. And they certainly deliver, in the field of user interfaces as well as for robotics there have been achievements made thanks to these peripherals. But why does nobody seem to be using the complete gaming devices? Even the research field of serious gaming shows little overlap with the console gaming industry.
I’m a fan of Nintendo so my argumentation will be a bit Nintendo-centric, but the same point could easily be made about the devices from Nintendo competitors. Developing data visualisation on a Wii-U, or a handled device like the 3DS, has the potential to save time and reach a greater audience. The development kit sold to the gaming industry are reasonably priced and give access to a consumer-product grade gaming toolkit that are just ready to use. As far as the cheap hardware argument goes, the Wii-U is rather interesting: it’s a strong GPU with HDMI output associated to a tablet with all the sensors one may expect. There are also pointing capabilities inherited from the Wii and a dedicated social network for applications running on the Wii-U. Outside of gaming, this social network is already being used on the Wii-U for social TV and will certainly be used for new incarnation of services that used to be on the Wii (Weather, Polls, …). All of this works out of the box, no need to hack new things to get on making great interactive visualisation or serious games.
Then comes the argument of coding for a dedicated platform. It is true that the Wii-U runs a dedicated operating system which can be expect to be deployed on all Nintendo’s devices but not outside of Nintendo’s realm (pretty much like Apple’s iOS !). So far, Nintendo has applied a generation-1 compatibility to his devices meaning that things developed on one generation of console will work on the next one. The Wii-U runs Wii-U and Wii software. The Wii runs Wii and GameCube software, etc… Previous iterations of the backward compatibility required dedicated additional hardware but they seemed to have stopped doing that now. Thus, looking at a new generation of gaming consoles every 6 or 7 years, this gives a 12 to 14 years stability for anything developed on one platform. Another goody is that as a developer you will not need to update your visualisation to deal with the console update that will happen over this period. Actually, things are always developed for a dedicated platform. As far as picking one such platform goes, I would rather bet on the Web platform rather than Java, Android, iOS or Flash. This is the only one focusing on open standards that everyone can implement. Applications developed with modern Web technologies can run everywhere these technologies are supported (including the Wii-U, thanks to the popular WebKit !). The Google street view application for the Wii-U has been coded in HTML5, using no native code.
In term of outreach, developing our research prototype for the hardware from the gaming industry would bring our products to the living room. That is closer to a wide, diverse, share of the people whose money is actually used to fund the (public) research. If the output of a research project can make it to the market place of a console device, everybody will be able to just download it and use it from the couch. Eventually involving other family members and, now, remotely connected friends via the integrated social networking features.
Nintendo and his competitors are working hard at bringing new entertaining and social experiences. This go well beyond the mere gaming they used to focus only a couple of years ago. Entertainment giants expect us to throw out our DVD players, media players, smart TVs and music players to just use their console and a dumb (big) screen. I think it would be a waste not to consider their hardware when we plan our research activities. Let me know if you think otherwise
Here it is: the first fully featured release of SemanticXO! Use it in your activities to store and share any kind of structured information with other XOs. The installation procedure is easy and only requires and XO-1 running the operating system version 12.1.0. Go to the GIT repository and download the files “setup.sh” and “semanticxo.tar.gz” somewhere the XO (these files are in the directory “patch_my_xo”). Then, log in as root and execute “sh setup.sh setup”. The installation package will copy the API onto the XO, setup the triple store and install two demo activity. Once the procedure is complete, reboot the XO to activate everything.
There are two demo activities which are described in more details on the project page. Under the hood SemanticXO provides an API to store named graphs containing description of one or several resources. These named graphs are marked with an author name, a modification date and, eventually, a list of other devices (identified by their URI) to share the graph with. This data is used by a graph replication daemon which every 5 minutes browse the network using Avahi, find other triple stores, and download a copy of the graphs that are shared with it. The data backend of the mailing activity provides a good example of how the API is used.