How demo works?
This website shows a demo of Content Glass application that uses the CG API for creating a basic expert system that communicate with Google Glass.
* Due to spam attacks the demo is not widely open. Users that are interested in watching the demo can ask for dedicated demo-user by sending a request to this Email.
First user need to define sharing-context states. In this demo a sharing context state refer to combination of patient bodily measurements assumed to occur in the case of surgery. A state may relate with one, two or three combined measurements. The number of states to define is currently not limited. A state is supposed to represent a case for which we would like to associate some shared information that can help medical team during surgery - in the case of patient get into same condition.
* Note that this application does not intent to present an accurate medical methodologies, only presenting a concept.
After defining sharing-context states, user is able to share widgets associate with defined states. At this point widgets are not organized but in a real application it will be possible to organize widgets, so that information can be presented to medical team in some reasonable order.
Once widgets has been created for states it is possible to use the system during an operation. This demo does not provide real integration with medical devices. Instead it provide a simulator that let user a way to simulate various patient measurements and watch the related widgets invoked based on currently detected states.
To summarize: State are defined, a widget is associate with states, and then at a time of operation widgets are invoked according to detected states. States refer to Content Glass layers and accordingly it is possible to define overlapping states - for example:
State1: Temperature: 36-38
State2: Temperature: 37-38 and Heart rate: 90
The demo include three screens:
1. State Editor: this screen can be used to program states. States are saved by the system and can be used later for setting a related shared content. It is also possible to edit or delete states.
2. Sharing Board: in this screen user create widgets which are then associated with Content Glass layer related with currently selected state. Since demo does not provide at this time ant means for organizing widgets it is recommended to create one or two widgets per states just to demonstrate the concept of working.
3. Simulator: in this screen user can set with sliders values for bodily measurements that simulate a data that in a real application will be received from an integration with medical device. The logic of the application detect any change and check for match states - accordingly the corresponding Content glass layers are set, and this result in Content Glass, loading shared widgets as related with the loaded layers.
4. Google Glass preview: On the simulator screen there is a button that user can use to open a preview page that shoes the data sent to the Google glass system, for the current login account. In practice, when widget is invoked, we take the content of this widget and send to the Google glass Miror API so that a new timeline item is created for the glass of logged-in user.
Setting Sharing Scope
At this time the demo is not yet integrated with a social-account that provide a way for setting different groups for different users. However this feature can be added. At this time all widgets are shared with all users of the application. This is controlled grammatically by ad hoc creation of user/groups and user should not define the peers-group scope by himself.
Some words about developing such king of apps
In a more technical level this application can be used to explain what does it mean to create Content Glass application. In fact when creating such application, the entire mechanism of sharing is handled by CG API and is not a dedicated part of this application. This include, creating widgets, setting widgets on layers, storing widgets in remote DB, loading shared widgets at given states etc'. When creating CG application developer usually need to focus at:
- state wizard (if no ready-made wizards is sutable for app purpose) : in this case we have the state-editor page
- Start (and stopping) the Glass engine and set a layer(s) based on the state that reflect the sharing context. In this app we do it in two places: first in the Sharing-Board screen when user select a state, second in the Simulator when new set of active states is detected.
- Other aspects of interacting with the user
The task of storing, fetching, managing shared data is handled by CG - this saves of course lots of client and server-side work.