Collaborative Coding in a Robotic Visual Language
Farah Yasser Dawoud, Ahmed Adel and Nada Sharaf
Media Engineering and Technology, German University in Cairo, Third Settelment, Cairo, Egypt
Visual Programming, Google Blockly, Collaborative Programming, Real-time Collaboration, Lego
Mindstorms EV3 Programming, Block-based Programming.
This paper presents a platform, that is a block-based visual programming environment. Students can collab-
oratively interact using a flexible and versatile definition of visual programming code and interface created
using Google Blockly, JavaScript, and Firebase. The web application is designed to allow students to program
the Lego Mindstorms EV3. An experiment was conducted to investigate the effect of real-time collaboration
on students working on the block-based visual programming web application.
Visual programming along with robotic programming
have both been evolving rapidly and are proven to
have a positive impact on students. They allow them
to enhance problem-solving skills and develop differ-
ent solutions to the same problem. (Danahy et al.,
2014). Collaborative tools and technologies facili-
tate teamwork leading to better results, greater in-
novation, and higher productivity. After all, collab-
orative tools cannot be just confined to better shar-
ing of knowledge; collaboration literally means work-
ing together, and collaborative tools can improve the
speed and effectiveness of people’s efforts. Some
popular examples of real-time collaborative tools are
Google docs, Google sheets, Google Slides, eRoom,
and SamePage. Some programming platforms also al-
low this such as CodeR (Kurniawan et al., 2015) and
The world is going towards a technological revo-
lution, anything that saves time and effort would be
very much preferred and appreciated. Visual pro-
gramming has originally supported individual work
where only one person works on a program at a
time. However, based on previous studies, collabora-
tive coding has been proven to be more efficient and
shows that students working collaboratively outper-
formed individual programmers (Nosek, 1998). To
the best of our knowledge, there exist no real-time
collaborative block-based platforms. The aim of the
work in this paper is to introduce a methodology
to enable real-time collaboration in block-based pro-
gramming settings. The methodology was applied
in a platform to control and simulate the Lego EV3
This aim of the work to test the effect of col-
laborative coding on students by allowing some of
the participants to test the application collaboratively
through accomplishing a task and others are given the
same task to accomplish individually. Aspects includ-
ing user’s engagement, mental load, performance, ef-
fort, and frustration levels are analysed for both cases
through surveys to investigate the effect of working
collaboratively on students.
Visual Programming reduces the need to write lond
textual programs. Program thus have multiple dimen-
sions not only the text (Burnett and McIntyre, 1995).
The idea is that with visual constructs, it could have a
better learning curve and be more appealing.
For example, with a robotic visual programming
language, users can program the robot without writing
a textual code and without significant knowledge of
any programming language. Examples include Make
and Open Roberta
for programming differ-
ent hardware systems using blocks.
Visual programming languages have different sev-
eral classes including block-based, diagrammatic, and
iconic visual languages (Myers, 1990).
Dawoud, F., Adel, A. and Sharaf, N.
Collaborative Coding in a Robotic Visual Language.
DOI: 10.5220/0010455501510156
In Proceedings of the 13th International Conference on Computer Supported Education (CSEDU 2021) - Volume 1, pages 151-156
ISBN: 978-989-758-502-9
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
2.1 Block-based Programming
Block-based languages are a class of visual program-
ming languages where the code constrcuts are blocks
that should be connected to each other.
In this case, the programmer has to drag the
needed blocks and drop them in the editor and con-
nect them together shown in Figure 1. Blocks usually
contain visual hints that eliminate the possibility of
having wrong connections or programs.
Figure 1: Block Based Program Example.
2.2 Google Blockly
In the search for the best visual editor, and after exper-
imenting with many Visual Programming Languages,
it was concluded that Google Blockly
was the most
preferable option. It offers the most suited flexibility
to the need.
Users would consider Blockly as a fun way to
build programs. However, on the other side it pro-
vides developers with a means to build their own vi-
sual blocks and language.
Blockly also allows users to export their pro-
grams into well-known languages including Python
and Javascript.
Custom blocks were created to satisfy our appli-
cation’s needs and this was achieved through ’Block
Factory’ provided by Blockly as shown in Figure 2.
The custom blocks that our web application re-
quired were mainly the blocks responsible for con-
trolling and programming the Lego Mindstorm EV3
along with some other basic blocks. Lego Mind-
storm is a programmable robot based on Lego build-
ing blocks (Valk, 2014).
While collaborative approaches have been shown to
be highly beneficial, implementing real-time collab-
orative coding feature in the application is not a
straight-forward task and requires overcoming several
technical challenges.
One challenge of a successful real-time collabo-
rative system is avoiding interference between users
by synchronizing workspace changes across all par-
ties. The application’s synchronization has to be re-
liable enough to guarantee constant user access, en-
sure the right order of applying edits from other users,
and avoiding code duplication so that there is constant
awareness of the state of the workspaces being edited.
Code integration and compilation while others might
still be editing source code as well are complicated by
the presence of collaborators which necessitates han-
dling syntax errors from edits made by other users.
These technical challenges have various solutions that
often force trade-offs between ease of implementation
and usability.
To be able to track changes of the user’s
workspace in our application, the following scheme
is followed:
1. Track and listen to the stream of events
2. Save them
3. Deliver and fetch by other parties
4. Apply them on other parties’ workspaces
3.1 Block Events
Editing code in real-time allows multiple program-
mers to do changes in the code. Such changes should
be automatically reflected for all programmers/col-
laborators with access to the workspace (Kurniawan
et al., 2015). In our application, these changes can
vary from being a deletion, creation, update of a
block, moving a block across the workspace (drag-
ging and releasing), and connecting it to other blocks
or even making a UI change for the arrangement of
blocks. All these changes should be tracked and ap-
plied to other parties and are all considered ‘events’.
Every change on the user’s workspace triggers a
certain event where these events fully describe the be-
fore and after state of each change. For example, the
MOVE event has properties that describe the type of
event, workspace ID, block ID, and old coordinates
(position) of the block and the new ones to determine
where it was moved.
But how do we listen to these events? Blockly
workspaces have an addChangeListener and
removeChangeListener methods that are used to
listen to the events stream. The event listener works
by taking a function (“func” in the example below)
as a parameter. This function is executed whenever
anything in the workspace changes (i.e whenever an
event is triggered).
CSEDU 2021 - 13th International Conference on Computer Supported Education
Figure 2: An example of a basic ‘wait’ custom block created by Blockly factory.
To be able to perform the remaining steps, there
has to be a connection and communication method
between users and their workspaces to allow real-time
data exchange which was achieved through Firebase.
3.2 Firebase
Firebase (Moroney, 2017) was used to implement the
real-time collaboration in the application. Firebase
provides Cloud Firestore that can store document-
structures data. In addition, it is able to synchro-
nize corresponding applications in case of any data
change. This consequently means that the application
is always listening to the database.
To continue with the Four main steps mentioned
above, the code below shows the Listener method and
the instructions that need to execute when a change is
f u n c t i o n l i s t e n e r ( c h a n ge ) {
l e t wo rk sp ac e = B l o c k l y . g e tM a in W or k spa ce ( ) ;
/ / c o n v e r t i n g t h e e v e n t t o j s o n t h e n S t r i n g
l e t c h a n g e j s = cha ng e . t o J s o n ( ) ;
l e t c h a n g e j s s t r i n g = JSON . s t r i n g i f y ( c h a n g e j s ) ;
/ / a d d i ng t h e e v e n t
/ / t o t h e d a t a b a s e a s a s t r i n g
var number2 = S t r i n g ( number ) ;
f i r e b a s e . f i r e s t o r e ( )
. c o l l e c t i o n ( ’ e v e n t s + number2 ) . a d d ( {
wo rk sp ac e : wo rk sp ac e . i d ,
e v e n t : c h a n g e j s s t r i n g ,
t i m e s t a m p : f i r e b a s e . f i r e s t o r e .
F i e l d V a l u e . s e r v e r T i m e s t a m p ( )
/ / u p d a t i n g t h e co d e o f t h e w ho l e
/ / w or ks pa ce and s e n d i n g i t t o s i m u l a t i o n
var cod e = B l o c k l y . J a v a S c r i p t .
works p a c eT oC od e ( w or ks pa ce ) ;
l o c a l S t o r a g e . s e t I t e m ( ” cod e , c o de ) ;
We start by saving the event to the database.
The event or change is initially of type ‘Blockly
event’. The Blockly event is first converted to JSON
(JavaScript Object Notation), which is a minimal,
readable format for structuring data. The JSON ob-
ject is then converted to a String. Figure 3 shows the
example document in Firestore collection.
Figure 3: Example event document in Firestore collection.
Collaborative Coding in a Robotic Visual Language
Once the event is triggered by any of the users,
it is fired automatically by the listener function to be
saved in the Events collection in Firestore. This en-
sures achieving step 1 and 2 (Listening to the stream
of events and Saving events). However, the applica-
tion needs to make sure that all workspaces are syn-
chronized with the required state of awareness.
3.2.1 Real-time Updates
This section discusses the etailed steps to achieve
the required synchronization. As shown in the re-
altimeEvents() function below, we need to fetch
the document, convert the event field from String
to JSON then back to a Blockly event. This
event can then be applied to other workspaces using
blockly command. Cloud Firestore
was used for to keep the data synchronized accross
the client applications through the realtime listeners.
The onSnapshot() method is executed whenever
there is a change in the data.
To explain the process with an example, if two
users are working collaboratively and user1 created a
block, the event is detected by Blockly’s event listener
and is saved to Firestore by adding a new document
of the new event to the Events collection. A docu-
ment has been added to the collection and a change
is now detected by the realtime updates, thus the on-
Snapshot() function is subsequently executed and the
event is now applied to other users.
f u n c t i o n r e a l t i m e E v e n t s ( ) {
l e t m a i n Wo rk s pa ce = B l o c k l y . g e tM a in W or k spa ce ( ) ;
f i r e b a s e . f i r e s t o r e ( )
. c o l l e c t i o n ( ’ e v e n t s + S t r i n g ( number ) )
. o rd e r B y ( ” t i m e s t a m p ” , ” as c ” )
. o n Sn a ps h ot ( f u n c t i o n ( q u e r y S n a p s h o t ) {
q u e r y S n a p s h o t . d ocCh ange s ( )
. f o r E a c h ( f u n c t i o n ( ch a ng e ) {
l e t wo rk sp ac e = c h a n ge . doc . d a t a ( ) . w o rk sp ac e ;
i f ( wo rk sp ac e !== ma i nW o rk sp a ce . i d ) {
B l o c k l y . E v e n t s . d i s a b l e ( )
l e t e v e n t = JSON . p a r s e ( c h a n ge . doc . d a t a ( ) . e v e n t ) ;
c o n s t b l o c k l y e v e n t = B l o c k l y . E v e n t s .
f r o m J s on ( e v en t , ma i n Wo r ks pa c e )
t r y {
b l o c k l y e v e n t . r u n ( t r u e ) ;
} c a t c h ( e r r o r ) { c o n s o l e . l o g ( e r r o r ) ; }
B l o c k l y . E v e n t s . e n a b l e ( )
} } ) } )}
This section describes in more details the experi-
ment,its design and results. The main purpose was
to test the effect of real-time collaboration. In other
words, the aim was to test whether it enhances the
process, makes it easier, faster, more efficient, more
interesting with a less mental demand or not.
4.1 Participants
The experiment was conducted on 10 participants, 7
males and 3 females. Their ages ranged from 9 to
14. All of the participants were children who have
previous knowledge and were familiar with block-
based programming applications such as Scratch, or
have previously been programming the EV3 using the
Lego Mindstorms EV3 Home edition. None of them
had a history of any health problem.
4.2 Procedure
All of the participants had their experiment on the
same conditions and surroundings to be able to eval-
uate correctly only for the effect of one aspect that is
collaboration. They were all given the same set of al-
gorithm to solve written in pseudo-code in which they
are required to implement using our block-based ap-
plication. Some of them were asked to perform the
task completely on their own (individually). Others,
on the other hand, were asked to finish the task to-
gether using the real-time collaboration feature. The
participants were then asked to fill a post-experiment
survey with their feedback and experience. The sur-
vey is divided into three parts; System Usability
Scale (SUS) (Brooke, 1996), User Engagement Sur-
vey (Pearce et al., 2005; O’Brien et al., 2018; O’Brien
and Toms, 2010), and NASA Task Load Index (TLX)
workload survey (Hart and Staveland, 1988).
4.3 Statistical Results
Data collected from the post-experience questionnaire
of all participants were analysed to calculate the re-
Starting with the first section of the survey, the
System usability score provides a useful measure for
the usability of a product (Bangor et al., 2008). Final
scores for the SUS range from 0 to 100. Higher scores
indicate better usabilities.
The mean SUS score of all participants was calcu-
lated to be 89.25.
The total workload scores were analysed as well.
Final scores for the Nasa TLX workload survey can
CSEDU 2021 - 13th International Conference on Computer Supported Education
range from 0 to 100. In this case, a higher score in-
dicates s higher workload on the student while per-
forming the task (Colle and Reid, 1998). The average
Workload score of students who worked individually
was 33.75 while the average of those who used the
real-time collaboration feature was 9.4 as illustrated
in Table 1.
Table 1: Mean overall workload on students with respect to
their group.
Group Mean overall workload
Collaborative 9.4
Individually 33.8
Results for four different aspects; performance
level, effort level, mental demand, and frustration
level were analysed for each participant. Mean scores
are shown in Table 2 according to their group and final
scores can range from 0 to 10.
Table 2: Mean scores of Performance, Frustration, Effort,
and Mental Demand on students with respect to their group.
Dimension Group Mean score
Performance Level Collaborative 10.00
Performance Level Individually 9.00
Frustration Level Collaborative 1.67
Frustration Level Individually 4.00
Effort Level Collaborative 2.67
Effort Level Individually 6.50
Mental Demand Collaborative 1.17
Mental Demand Individually 4.25
Data collected was also analysed to calculate the
results of the User Engagement Scale (UES). The
UES is a measure of the engagement or depth of in-
vestmenent. (O’Brien and Toms, 2010). UES-SF
which is a Short form of the UES was used in the
post-experiment survey. The final UES score can have
values ranging from 0 to 5. The mean UES score for
each group is shown in Table 3.
Table 3: Mean UES Score with respect to the students’
Group Mean UES Score
Collaborative 4.3
Individually 2.9
4.3.1 Correlation
There is a significant negative correlation between
students working collaboratively and the mental de-
mand on them while performing a task with Spear-
man’s correlation coefficient of -0.913, Kendall’s tau
coefficient of -0.840, and Pearson’s coefficient of -
There is a significant negative correlation be-
tween collaborative work and effort done in the task
with Spearman’s correlation coefficient of -0.799,
Kendall’s tau coefficient of -0.719, and Pearson’s co-
efficient of -0.757.
There is a significant positive correlation be-
tween collaborative work and performance level in
accomplishing the task with Spearman’s correlation
coefficient of 0.612, Kendall’s tau coefficient of
0.612, and Pearson’s coefficient of 0.612 as well.
There is a significant negative correlation be-
tween collaborative work and frustration level in ac-
complishing the task with Spearman’s correlation co-
efficient of -0.761, Kendall’s tau coefficient of -0.722,
and Pearson’s coefficient of -0.764.
There is a significant negative correlation be-
tween collaborative work and total workload on par-
ticipants while accomplishing the task with Spear-
man’s correlation coefficient of -0.853, Kendall’s tau
coefficient of -0.730, and Pearson’s coefficient of -
There is no significant correlation between col-
laboration and system usability. Spearman’s correla-
tion coefficient is 0.434, Kendall’s tau coefficient of
0.387, and Pearson’s coefficient of 0.5.
There is a significant positive correlation be-
tween collaborative work and user engagement while
accomplishing the task with Spearman’s correlation
coefficient of 0.775, Kendall’s tau coefficient of
0.705, and Pearson’s coefficient of 0.747.
Table 4 shows a summary table for all factors with
Spearman’s, Kendall’s, and Pearson’s correlation co-
efficient values along with the p-value (significance
value) of Pearson’s correlation.
This study was performed to investigate the effect of
real-time collaborative programming on the process
by investigating several aspects including effort, per-
formance, engagement, and mental workload. An ex-
periment was conducted on a representative sample
of 10 normal children (7 males and 3 females) who
Collaborative Coding in a Robotic Visual Language
Table 4: Correlation coefficient and significance values for all factors.
Factor Spearman’s Kendall’s Pearson’s p-value Significant correlation
User Engagement 0.775** 0.705* 0.747** .006 YES
System Usability 0.434 0.387 0.500 .042 NO
Total Workload -0.853** -0.730** -0.891** .000 YES
Performance Level 0.612* 0.612* 0.612* .030 YES
Frustration Level -0.761** -0.722* -0.764** .005 YES
Effort Level -0.799** -0.719** -0.757** .006 YES
Mental Demand -0.913** -0.840** -0.930** .000 YES
**. Correlation is significant at the 0.01 level
*. Correlation is significant at the 0.05 level
are familiar with block-based visual programming ap-
plications. They were given a task to accomplish
in a set time interval. Results showed users work-
ing collaboratively expressed higher levels of confi-
dence about their work, engagement to the task, less
levels of frustration, mental demand, and total work-
load, and higher performance level while accomplish-
ing the task than programmers who worked and per-
formed the task alone. This was concluded by calcu-
lating the SUS, NASA TLX workload, and engage-
ment scores then calculating the correlation and re-
In the future, working on a larger sample size
would help in getting more reliable and accurate re-
sults. It would be better to a large number of par-
ticipants for each age and gender. In addition, mak-
ing sure all participants have approximately the same
years of experience in using block-based applications.
Bangor, A., Kortum, P. T., and Miller, J. T. (2008). An
empirical evaluation of the system usability scale. Intl.
Journal of Human–Computer Interaction, 24(6):574–
Brooke, J. (1996). Sus: a “quick and dirty’usability. Us-
ability evaluation in industry, 189.
Burnett, M. M. and McIntyre, D. W. (1995). Visual pro-
gramming. COMPUTER-LOS ALAMITOS-, 28:14–
Colle, H. A. and Reid, G. B. (1998). Context effects in
subjective mental workload ratings. Human factors,
Danahy, E., Wang, E., Brockman, J., Carberry, A., Shapiro,
B., and Rogers, C. B. (2014). Lego-based robotics
in higher education: 15 years of student creativity.
International Journal of Advanced Robotic Systems,
Hart, S. G. and Staveland, L. E. (1988). Development of
nasa-tlx (task load index): Results of empirical and
theoretical research. In Advances in psychology, vol-
ume 52, pages 139–183. Elsevier.
Kurniawan, A., Soesanto, C., and Wijaya, J. E. C. (2015).
Coder: Real-time code editor application for collab-
orative programming. Procedia Computer Science,
Moroney, L. (2017). The firebase realtime database. In The
Definitive Guide to Firebase, pages 51–71. Springer.
Myers, B. A. (1990). Taxonomies of visual programming
and program visualization. Journal of Visual Lan-
guages & Computing, 1(1):97–123.
Nosek, J. T. (1998). The case for collaborative program-
ming. Communications of the ACM, 41(3):105–108.
O’Brien, H. L., Cairns, P., and Hall, M. (2018). A practi-
cal approach to measuring user engagement with the
refined user engagement scale (ues) and new ues short
form. International Journal of Human-Computer
Studies, 112:28–39.
O’Brien, H. L. and Toms, E. G. (2010). The development
and evaluation of a survey to measure user engage-
ment. Journal of the American Society for Information
Science and Technology, 61(1):50–69.
Pearce, J. M., Ainley, M., and Howard, S. (2005). The ebb
and flow of online learning. Computers in human be-
havior, 21(5):745–771.
Valk, L. (2014). Lego mindstorms Ev3 Discovery Book: A
beginner’s guide to building and programming robots.
No Starch Press.
CSEDU 2021 - 13th International Conference on Computer Supported Education