In presentation the idea of automatically generated web interface for remote laboratory is presented. The concept is based on suitably prepared set of metadata, that is used to generate web client. In presented solution each remote experiment, sends metadata concerning user interface just before experiment session is started. Main advantages of this solution include: easier deployment and decreased development costs. This concept can be applied for various e-learning areas. The working example of such interface is shown and discussed.

1. The metadata driven
e-laboratory
web client
Mikołaj Olszewski
Jacek Bzdak

2. Outline
1. Idea
2. Metadata driven laboratory
3. Protocol Details
4. Demo
5. Benefits

3. Idea
How it started...

4. Introduction
• SILF is a remote laboratory developed in a
project: “e-physics - the multimedia
environment of teaching physics for upper
secondary schools”
• We are to develop 13 remote experiments in
3 years
• We wanted to decrease per-experiment
development costs

5. SILF characterisation
• Experiment servers written in Python
• Experiment client is written in Coffeescript,
and requires only a browser to work
• Communication is done via the XMPP
protocol
• We use XMPP moderation tools
• Every experiment session is done via XMPP
group chat room

6. SILF Architecture

7. Detailed view of SILF architecture

8. Terminology

9. Components - before
• Experiment server
• One per experiment, though we have some
driver reuse
• Experiment client
• Previously we had a plugin architecture, each
experiment had a client plugin
• Messaging server
• One per laboratory

10. What if we had single client?
• 50% less work on experiment
• Yet, much more work on the infrastructure
• Simplified deployment
• Client updated without any changes to the
WWW server
• Free lunches
• Updates to the client are automatically visible in
all the experiment

11. Metadata driven laboratory
The conclusion...

12. Metadata driven laboratory
• User gets a description of the experiment
from the experiment server
• HTML5 Client is responsible for rendering GUI
according to the description

13. Why Web GUI?
• HTML5 powerful enough
• Real-time communication via websockets
• Works everywhere - everyone has a browser
• but not (for example) Windows
• works on mobile devices - responsive layout
• Social networks seamless integration
• It is simple and natural for modern people
• Easy to upgrade - SaaS model

14. Example experiment session
• Experiment modes -
way to decrease inter
control dependences
• Experiment description
can be different for
each mode

15. Currently supported metadata
• List of modes
• Controls
• label
• type
• validations
• Results
• name
• method of display
• It’s enough

16. Protocol details
Let’s see how it works underneath...

17. Protocol details
• XMPP dialect
• 100% XMPP compliant!
• <labdata> in group chat message
• Action defined by namespace
• Types: query, result, error
• Various content in JSON
Protocol documentation

18. Experiment conversation
1. Mode selection
2. Input validation
3. Session start
4. Incoming results
5. Session ends
6. Experiment ends or go to 1
Conversation details

19. Mode selection
USER
<labdata xmlns="silf:mode:get" id="query1" type="query" />
Experiment
<labdata xmlns="silf:mode:get" id="query1" type="result">
{
"lead": {
"label": "Ołów",
"description": "Badanie osłabienia w ołowiu",
"order" : "1"
}
}</labdata>

20. Mode description
• label - human
readable name
• description human
readable
• unique id - name of
the mode (machine
readable)

21. Mode setting
USER
<labdata xmlns="silf:mode:set" id="query2" type="query">
{"mode": "default"}
</labdata>
Server
<labdata xmlns="silf:mode:set" id="query2" type="result">
GUI description
</labdata>

22. Experiment metadata
{
"experimentId": "urn:uuid:a12e6562-5feb-4046-b98f-d8c40ca1609c",
"mode": "aluminium",
"settings": {
"acquisition_time": {...},
"light": {...}
},
"resultDescription": {
"time_left": {...},
"chart": {...}
}
}
experiment
settings
results / outputs
description

23. Control properties
• name - machine
readable and unique id
• label - human readable
• type - type of the value
(int, timedelta)
• validations - bounds to
values

24. Output field description
• name - of the data
source
• type - data type
• class - styling
• metadata - human
readable metadata

25. Settings validation
USER
<labdata xmlns="silf:settings:check" id="query3" type="query">
{
"acquisition_time": {"value": 150, "current": true},
"light": {"value": false, "current": false}
}
</labdata>
SERVER
<labdata xmlns="silf:settings:check" id="query3" type="result"/>
or error message (omitted)

26. Series start
USER
<labdata xmlns="silf:series:start" id="query4" type="query">
{"acquisition_time": {"value": 150, "current": false} … }</labdata>
Experiment
<labdata xmlns="silf:series:start" id="query4" type="result">
{
"metadata": {"label": "Czas pomiaru 90s."},
"initialSettings": {
"acquisition_time": {"current": false, "value": 90},
"light": {"current": false, "value": false}
},
"seriesId": "urn:uuid:6bd8a024-5a8b-4f04-be84-76dcad89d89f"
} </labdata>

27. Series start data
• metadata - human
readable metadata
• seriesId - unique series
id (needed for storage
and retrieval of data)
• initialSettings - settings
that were sent by the
user to initiate series

28. Results
Sent by the server when ready
<labdata xmlns="silf:results" id="query5" type="result">
{
"chart": {
"value": [[1, 1234], [5, 321]],
"pragma": "append"
},
"time-left": {
"value": [1],
"pragma": "transient"
}
}</labdata>
No response needed

29. Results
• name of result block
• value - value
• pragma - controls
data storage and
presentation

30. End of series
Series ends when:
• Experiments finishes the
measurements
• Operator stops the series
• Timeout has occured
• Messages are slightly
different for each case
USER
<labdata xmlns="silf:series:
stop" id="query6" type="
query"/>
Server
<labdata xmlns="silf:series:
stop" id="query6" type="
result"/>

31. End of experiment
Experiment ends when:
• Operator stops the
experiment
• Timeout has occured
(experiment idle for too
long)
• Messages are slightly
different for each case
USER
<labdata xmlns="silf:
experiment:stop" id="query7"
type="query"/>
Server
<labdata xmlns="silf:
experiment:stop" id="query7"
type="result"/>

32. Protocol
• That is all
• Less than 10 message types
• Yet a fully operational laboratory

33. Demo
That’s what tiggers do best...

34. Benefits
• There is one single client
• Existing experiments "get features" as we
develop the client
• Easy to develop automatically controlled
experiment (working in showcase mode)
• Easy (for example) to build Android client
• Possible to create server in C/C++/Java/your
favorite language

35. Epilogue
• Whole framework is open-sourced
• Rest of laboratory is being open-source
• Refer to the documentation for details
• See also our repositories
• This presentation: http://tnij.org/silf|vu2014
Thanks for your attention