In Traction

I spent some time the last weeks to support type decoding plugins in Uiml.net. This is mainly useful when you want to interact with applications or web services that have their own types that need to be converted to something the widget set understands. Suppose for example a web service returns a set of Persons, which need to be represented in a list view. The renderer does not know how to transform a Person into an item of a list view, so you need to define a custom component that sits between the renderer and the web service, and can provide this conversion. However, since you don’t know which widget set is used, you have to do this for every possible widget set (e.g. System.Windows.Forms, Gtk#, System.Windows.Forms on the Compact Framework, etc.). Furthermore, it would be better to let the renderer manage this code.

So I created a type decoder plugin system and while I was at it, also cleaned up the code. This resulted in only one general TypeDecoder instance being created in the renderer, while we previously had one instance per backend. Now we have a container class in each backend to host widget set-specific type decoders. This container class get registered with the TypeDecoder, and is in fact also a plugin.

Instead of going into the implementation details, let’s have a look at an excerpt from the System.Windows.Forms container class (SWFTypeDecoders.cs):

37
38
39
40
41
42
43
44
45
46
47

using Uiml.Rendering;
using Uiml.Rendering.TypeDecoding;
 
public class SWFTypeDecoders
{	    
    [TypeDecoderMethod]
    public static System.Drawing.Point DecodePoint(string val)
    {
        string[] coords = val.Split(new Char[] {','});
        return new System.Drawing.Point(Int32.Parse(coords[0]), Int32.Parse(coords[1]));
    }

The only thing we have to do to define a type decoder method is add the [TypeDecoderMethod] attribute and support as a parameter the type we want to convert from. The return type is what we will convert to. In the above listing, the DecodePoint method converts a string to a System.Drawing.Point. The [TypeDecoderMethod] attribute is used to declare that the corresponding method is a type decoder. This way other auxiliary methods will not be registered and won’t pollute the type decoder registry.

To test the implementation, I created a simple class that connects to del.icio.us and gets all my tags. I use this class to show them in a Gtk# UIML GUI. To be able to convert between the XML document that is returned by del.icio.us and the user interface, I wrote a custom type decoder, and connected it to the renderer. I also have a short screencast showing its workings.

I have extended the Uiml.net type decoder to combine existing type decoding methods if direct conversion is not supported. In this example I created a type decoder to convert from a System.Xml.XmlDocument to a Uiml.Constant. But the Gtk.TreeView widget requires a Gtk.TreeModel. The renderer will therefore look for a conversion from a Uiml.Constant to a Gtk.TreeModel and apply the type decoders in sequence. Although we could have converted directly to this data type, this is not as flexible since it is widget set-specific. Although the interface will remain the same, I will probably change the underlying implementation to a graph with the types as vertices, and type decoders as edges to better support these indirect conversions.

Yesterday I went to the FITCE event on the Internet of Things I blogged about earlier together with my colleague Geert Vanderhulst. At first, I wanted to go by car, but then I realized that meant going through the rush hour on the Brussels ring road. Eventually, we decided to take the train to Leuven, take another one from Leuven to Brussels North station, and from there take the train to Vilvoorde. Unfortunately there were some difficulties with the last element in this chain

Apparently there was a train that arrived at the exact same time and at the same platform at Brussels North station as the train we were supposed to take. This train also went to Antwerp Central Station, but had Amsterdam as its final destination. When we were on it, we realized too late that it didn’t stop in Vilvoorde. So we got out in Mechelen (the first stop) and took another train to Vilvoorde. Normally this train would be in Vilvoorde on time to allow us to take the bus to Living Tomorrow, but this evening it changed to an L train, meaning that it stops at every station on its way. When we finally arrived in Vilvoorde, the last bus to Living Tomorrow before 19:00 had already left. The next one was at 20:15. After asking a bus driver, we found another bus that stopped close to the venue (bus 47). After taking this bus, we finally arrived somewhere in the neighborhood of the Indringingsweg, but didn’t know where to go. Of course, then it started raining Luckily Geert had his satellite navigation system with him to lead us the way. When we finally arrived in the room, we had to pass by the speakers and all the lights went on, so we couldn’t make an unremarkable entrance

So what about the talks? Although it’s always interesting to see how people appreciate ubicomp technologies when they get integrated in their daily lives, I didn’t learn anything really new. A lot of the technologies or prototypes that were mentioned were familiar to me. One of the things I hadn’t heard about yet were washable RFID tags.

After the talks we got a tour through the house of the future. Again, a couple of the technologies they showed had already been integrated in real-life products or were already well investigated in research. There was a prototype by Volvo about parking sensors, dead angle cameras, lane tracking and a system to avoid collisions in traffic jams. The more advanced technologies here were mentioned in Donald Norman’s talk last year in Leuven. There was also a store of the future and a kitchen of the future. The presentations and film fragments of the talks are going to be put online soon. If I don’t forget, I’ll update this post with a link to the material.

But even after the event our public transport nightmare wasn’t over I entered some information wrongly on the travel planner of De Lijn, so the bus we wanted to take back to the station didn’t drive until after our train left. Luckily Geert Houben (another colleague) came by car and dropped us off at Vilvoorde station in time. So then we went back from Vilvoorde to Brussels North, where we took the train to Genk. But not before having an unhealthy, but satisfying snack

Adam Greenfield would like to know how people respond to his talks, so hereby a call to everyone that will be attending his talk in Leuven to blog about it

Via Gizmodo:

This Wiimote hack is one of the more astounding mods we’ve seen to Nintendo’s pride and joy, but even more remarkably, it’s really only taking advantage of the Wiimote’s IR and Bluetooth capabilities to create what may be the multitouch mecca — multitouch without the touch. So would you wear little reflective rings on your fingers to have tactile control of your television screen? We would. In a heartbeat. And then we’d call Captain Planet to kick some ass when we’re finished watching 30 Rock.

Very cool stuff. Since almost anyone at our institute has a Wii nowadays (including me), this should not be too hard to create ourselves.

The author of the video is Johnny Lee and works at Carnegie-Mellon. Just had a quick look through his impressive list of publications (UIST, SIGGRAPH, DIS, CHI, etc.), and found an interesting paper on how one can predict the task a user is currently performing by analyzing his EEG signals. This one is on my reading list about general sensing techniques (I hope I find some time soon to start reading papers again).

On Monday afternoon, I participated in a Smart Reading course together with a few colleagues. Although the basic techniques of speed reading were explained, it left me wanting to know more. Since I don’t feel like paying more than a thousand Euros for a full, three-day course, I started to look for some more information on the topic.

If you want more or less the same information that we received in the course, have a look at this excellent overview of speed reading techniques.

For those of you who want to speed read through information on your computer display instead of in books, there is software available that uses the technique of Rapid Serial Visual Presentation to help you read faster. One of these applications is RapidReader. They have a nice video illustrating that reading faster doesn’t significantly hamper your comprehension:

There are also some free alternatives, such as Spreeder (an online speed reader) and dictator.

Apparently there is a yearly contest called the World Championship Speed Reading Competition. The current record holder is Sean Adam with 3850 words per minute with comprehension. There were also some famous people in history that could speed read, including Jacques Bergier and USA presidents John F. Kennedy and Jimmy Carter. There are also some claims of a child prodigy that could read more than 400 000 words per minute, but that might be attributed to her photographic memory.

Although a lot of the claims around speed reading are unrealistic and it is surrounded by the typical vagueness of pseudoscience, the idea still intrigues me. I went to the book shop yesterday and found a few books (some exclusively in Dutch, others translated from English) that seem interesting to have a look at. I also included books on Mind mapping since this is the technique used to summarize the books you read. There is another book in English that seems to be recommended by a few people: Breakthrough Rapid Reading by Peter Kump.

The Dutch books I might have a look are:

• Gebruik je Hersens, Jan-Willem van den Brandhof
• Snellezen, Tony Buzan
• Mindmappen, Tony Buzan
• Gebruik je verstand, Tony Buzan