After reading this paper, I have the following two thoughts. One is about the overall system architecture and the other is about comparing with software solutions.
I. When designing Proximity technology there is certain 'pattern' in the system architecture aspects, which might offer us a generalized guideline.
In the Relate system, there are three components:
1) The Relate Dongle;
2) The Relate Spatial Engine; and
3) The Relate Toolkit.
This framework is a typical one for designing Proximity technologies. There is a sensor component in charge of collecting data. Then there is an engine for processing raw data and making them proxemically sensible. And finally there is a toolkit for translating the data to the user interface level. If we look back at our home space, we can see similar structure: the Vicon system for collecting raw data, the proximity server for telling the distance, orientation, motion, etc. and then the proximity toolkit for making use of such proxemic relationships.
Apart from generalizing such framework, it is another topic whether it is good enough or needs improvement.
II. Proximity is not the only solution to the problem; so it matters whether your remedy is enduring or just temporal.
In the paper, the authors address the inconvenience of sending files using USB memory sticks. Published in the year 2005, it is understandable that this was considered the 'current' solution. However, nowadays we have more advanced software solutions such as Google Docs, DropBox, etc. which greatly streamline the process of sending or sharing a file. The triumph over using USB memory sticks is no longer convincing nowadays. The application example did not offer a enduring remedy.
It dawns on me whether we need to consider comparing to current or future software solutions when we are working on those based on Proximity.
