014 - Ambiguous Intentions

Summary:

The paper describes NAPKIN, a system which allows users to draw sketchy shapes and then define them in different domains. An example would be to draw a box with four boxes around it denoting a table with four chairs. The system would then beautify and label the object. The objects are ranked by how they are recognized and by how many domains they are recognized in. The system stores all this data and saves it for later, in case a new napkin wants to use information from a previous napkin. This allows for multiple domains and ambiguous gestures, such as the above square as a table to be used in a bar graph, etc. The symbols are usually related to each other, such as the chairs to the table, because they are smaller and near. Different constraints would be made for different domains.

Discussion:

Honestly, I think this system has limited uses. While it seems and fine and dandy to have all these attachment features and ambiguous data, when people are ACTUALLY sketching something they usually don't intend anyone else to use their sketches. Since everyone has their own sketching style, labeling things would only hinder someone who is sketching something for their own personal use. Why bother labeling something as a table if the sketcher KNOWS it's a table? Also, I believe too many domains should be handled seperately, because the more domains a recognizer takes on, the less likely it is to correctly label objects in the right domain. Also, it's just as easy to write two systems for two domains as it is to write one system for two domains - if you've written the code well, that is.