The development of ECT has been motivated by previous work involving the construction of ubiquitous computing experiences undertaken as part of the ACCORD project and the EQUATOR Interdisplinary Research Collaboration (IRC). Work in ACCORD focussed on the construction of domestic ubicomp experience, and ongoing work in EQUATOR has focussed on themes such as Playing and Learning, Citywide Performance and Digital Care.
Although the ubicomp experiences constructed as part of these activities have been very different, a common theme that has emerged from all of them is that the construction of experiences is difficult and time-consuming to get right. Some common problems that have been encountered include:
ECT has been developed as a result of the experiences that have been gained in solving these particular problems in the activities listed above. ECT allows:
As such, the ECT package is a combination of
ECT uses the term component to refer to an item of software running on a particular computer which can be used to control a particular device. For a piece of software to be usable as a component in ECT, it must conform to certain requirements (although there will be many existing items of software that already conform to these requirements and that will therefore be directly usable in ECT without modification). ECT is supplied with a large number of components to allow interactions with popular ubicomp devices, and many of these components are listed in component documentation provided on this web-site (for example, see the Categorised components list).
It should be noted that, in addition to the components supplied with ECT that can be used to control hardware devices, ECT is also supplied with a number of software-only components that can be used to perform processing operations. For example, Dynamic BeanShell is a component that allows scripts written in the BeanShell language to be used in the ECT environment.
All components define named properties, which can be used to control their operation, and as a result the operation of any hardware device with which they may commmunicate. For example, the Camera component, which can be used to take a picture using a webcam, defines the following properties:
Note that the names of some of the properties on the Camera component are examples of property names that follow certain conventions (you will also find these conventions regularly used in other ECT components):
In general a component which communicates with a particular device will run on the computer to which the device is attached, and may require the installation of various items of driver software on that machine for its operation (requirements for driver installation are documented by each component - for an example, see the PhidgetInterfaceKit component).
However, in general, properties defined by a ECT component running on one computer are controllable using ECT from another computer, as long as this computer is connected over a network and is also running ECT. To allow components to be controlled in this way, ECT has the concept of a container, which is an item of software which runs on a computer, and which manages the components running on that machine.
A container must be installed onto every machine on which components should run. When a container is started up, it will
Note for developers - ECT is currently supplied with a container written in Java, which is capable of hosting components which are defined as JavaBeans. Properties of a supplied bean are then interpretted by ECT as being properties of the component. See ECT Developer documentation for more information.
Although components provided with ECT can simplify the process of setting up software that can control ubicomp devices, setting up a ubicomp experience is likely to involve much more work than just installing ECT on a cluster of machines, attaching devices to machines, installing drivers for devices, and configuring components that can communicate with these devices. Designers are likely to wish to specify much more complex behaviours in theirs systems than can be provided using this process alone.
The primary mechanism in ECT for the specification of behaviour involves the creation of connections between properties on different components. Connections can be established between components, even when they are hosted in containers running on different machines. If a connection exists between two properties, and if one of these properties is set to a new value, then ECT will propogate this new value to any other connected properties. Note that new values might be supplied by either users or by the component to which the property belongs.
A simple example of this connection mechanism might involve two components - a Camera component and a Simple Media Viewer component. If a connection is created between the imageLocation property of the Camera components, and between the browserURL property of a Simple Media Viewer component, then every time the Camera component triggers its attached device to take a picture, the URL where this picture can be found will be placed on the imageLocation property, and will get propogated along the connection to the Simple Media Viewer browserURL property. This will cause the picture at that URL to appear in a browser window maintained by the Simple Media Viewer component. This browser window can easily be on a different machine to the one to which the camera device is attached.
Of course, there are limitations to the complexity of behaviour that can be specified by this property connection mechanism. Adding connections between components representing hardware devices is useful in the creation of reactive systems (eg ones in which the principal behaviour of the system involves a number of events causing a number of actions). However, it is not sufficient to create systems which exhibit data processing functionality. In ECT at present, data processing functionality can be added through the addition of software-only components. These are components which are still controlled through the modification of property values, and which can therefore be connected to components representing hardware devices, but which themselves do not connect to any hardware device. Instead, they may provide useful data storage or processing functionality.
ECT is currently provided with a wide range of software-only components, which have been developed to add behavioural features to existing installations. Examples of software-only components include
The combination of
ECT provides functionality to manage multiple installations. Computers running ECT can be involved in multiple installations at once, and users can switch between different installations that have been created at different times. This process works as follows:
Note that it is of course possible to run ECT on just one computer (rather than on all computers in a cluster) and if an installation is created on this computer, then this computer will automatically be the master computer for the installation.
The first part of this document has described core concepts and entities in ECT, including components, component properties, containers, connections and installations. The rest of this documentent briefly introduces the different types of graphical user interface (GUI) functionality which are provided with ECT to manipulate these entities.
Different types of GUI functionality have been provided with ECT which are targetted at the needs of different categories of users. Types of functionality currently include:
The combination of the graph editor and capability browser is currently the most commonly used interface to ECT, and as such is also the most well-developed and bug-free. This section gives a brief overview of the functionality of this interface - for much more detail, including a number of screenshots of these interfaces - follow the Learning to use ECT tutorial.
The capability browser is a window that displays views of all components that are available in any container which has been attached to a particular ECT installation. It allows users to view any documentation defined by a particular component, request that an instance of a component be created, and to request that existing instances of components be deleted.
Once a component instance has been created through the capability browser, it will appear in the graph editor. This allows users to view the properties defined by a component, modify any values they may have, and to establish connections between properties. As properties on components change (for example, when caused by someone providing an input using a hardware device) then these property changes appear on the graph editor, and if a user uses the capability browser to delete a component instance, it will disappear from the graph editor.