# VREUD - An End-User Development Tool to Simplify the Creation of Interactive
VR Scenes

Enes Yigitbas, Jonas Klauke, Sebastian Gottschalk, Gregor Engels  Paderborn
University, Germany
<EMAIL_ADDRESS>
###### Abstract

Recent advances in Virtual Reality (VR) technology and the increased
availability of VR-equipped devices enable a wide range of consumer-oriented
applications. For novice developers, however, creating interactive scenes for
VR applications is a complex and cumbersome task that requires high technical
knowledge which is often missing. This hinders the potential of enabling
novices to create, modify, and execute their own interactive VR scenes.
Although recent authoring tools for interactive VR scenes are promising, most
of them focus on expert professionals as the target group and neglect the
novices with low programming knowledge. To lower the entry barrier, we provide
an open-source web-based End-User Development (EUD) tool, called VREUD, that
supports the rapid construction and execution of interactive VR scenes.
Concerning construction, VREUD enables the specification of the VR scene
including interactions and tasks. Furthermore, VREUD supports the execution
and immersive experience of the created interactive VR scenes on VR head-
mounted displays. Based on a user study, we have analyzed the effectiveness,
efficiency, and user satisfaction of VREUD which shows promising results to
empower novices in creating their interactive VR scenes.

###### Index Terms:

Virtual Reality, End-user Development, Authoring, Interactive Scene,
Development Tool

##  I Introduction

Recent advances in Virtual Reality (VR) technology and the increased
availability of VR-equipped devices slowly shift the focus away from the
entertainment area to new application areas in training [1], robotics [2],
education [3], or healthcare [4]. These wider application areas of VR require,
besides affordable devices, a usable process of authoring to reach the full
potential [5]. Although there is a vast pool of authoring tools [6], many of
them presuppose technological background in programming or scripting [7, 8, 9]
or knowledge in modeling languages [10, 11]. This results in a complex and
cumbersome task to develop interactive VR scenes for novices in VR
development, who have typically lower technical knowledge.

One solution to this problem is to apply End-user Development (EUD) methods
and techniques which allow novices to create or modify software artifacts
[12]. Furthermore, modeling languages are used in authoring tools to abstract
the complexity of the development, however, the entry barrier to learning the
language could scare away novices. As a consequence, we believe that the
development of an interactive VR scene should require a minimal entry barrier
to reach a maximum of novices. To reach this goal, we have chosen the EUD
methods component-based and wizard-based development. The component-based
development allows an efficient construction by reusing and configuring of
provided components. Furthermore, we apply wizard-based development to lead
the novice in a step-by-step manner through difficult sections in the
development. These chosen EUD methods are implemented in an open-source web-
based authoring tool called VREUD. It addresses the challenges in the
development of an interactive VR scene by supporting the novice in the
construction of the scene. Furthermore, it supports the specification of
interactions which will be performed by the user of the VR scene, and the
definition of tasks to guide the VR user through the scene. Since novices
usually prefer to learn by exploring or trial and error mechanism [13], VREUD
provides rapid construction and execution that enables the novices to
prototype the developed interactive VR scene at each step in the development.
Consequently, VREUD enables the novice to construct and execute the developed
web-based interactive VR scene. VREUD is inspected by a usability evaluation
to analyze its effectiveness, efficiency, and user satisfaction. 15
participants with mixed backgrounds in VR development have been invited to a
user study to evaluate if VREUD supports a simple development of interactive
VR scenes with a low entry barrier. The results of the usability evaluation
suggest that VREUD enables novices to successfully create their interactive VR
scenes and that VREUD is easy to learn and decreases the entry barrier in the
development.

Our contributions are as following: A technique to abstract the development of
interactions in an interactive VR scene by using a component-based and wizard-
based construction, an open-source web-based authoring tool to develop web-
based interactive VR scenes with a low entry barrier that can be used or
extended by other researchers, and a usability evaluation inspecting the
effectiveness, efficiency, and user satisfaction of the introduced authoring
tool as well as a comparison between the results of users with no and high
experience in VR development.

The rest of the paper is structured as follows. In Section 2, we present and
discuss the related work. In Section 3, we described the conceptual solution
of VREUD. In Section 4, we show the details of the implementation of VREUD. In
Section 5, we present the main results of the usability evaluation and discuss
its results. In Section 6, we conclude the paper and give an outlook for
future work.

##  II Related Work

Augmented Reality (AR) and Virtual Reality (VR) have been a topic of intense
research in the last decades. In the past few years, massive advances in
affordable consumer hardware and accessible software frameworks are now
bringing AR and VR to the masses. AR enables the augmentation of real-world
physical objects with virtual elements and has been already applied for
different aspects such as robot programming [14], product configuration (e.g.,
[15], [16]), prototyping [17], planning and measurements [18] or for realizing
smart interfaces (e.g., [19], [20]). In contrast to AR, VR interfaces support
the interaction in an immersive computer generated 3D world and have been used
in different application domains as motivated already in the introduction. As
the creation of interactive VR scenes is our main focus, in the following, we
draw on prior research into VR Authoring Tools and End-User Development.

###  II-A VR Authoring Tools

VR authoring tools enable the user to develop interactive VR scenes. They
provide the user with the ability to position virtual objects in a scene and
methods to define the interactions between these objects. The game engines
from Unity [7] and Unreal [8] are currently the most popular tools to develop
interactive VR scenes [21]. The area of WebVR, which enables VR on web pages,
has produced frameworks to develop interactive VR scenes as web applications,
for example, Threejs [22] and A-Frame [23]. The problem with these introduced
tools is that they require programming languages like C# and JavaScript that
creates an entry barrier for novices. Arising from this problem, many
authoring tools provide an easier development of scenes to novices [24, 10,
25, 26, 9]. In Spoke [24], the user designs social meeting scenes for
Hubs[27]. Hubs is a web-based VR social meeting platform. Spoke simplifies the
development of the scene to a combination of elements given to the user. These
elements can be modified and configured in their appearance. The design of
user interactions is not possible. PolyVR [9] supports the design of
interactions by scripting. The downside of this approach is that the novice
has to learn the modeling language. Sumerian [10] abstracts interactions with
statecharts. This decreases the entry barrier, but the novices have to be
familiar with statecharts. Game Rules scEnario Platform (GREP) [25] supports
novices in the development of VR games. It decreases the complexity of the
construction by using smaller games that are defined by a given archetype.
These smaller games are configured and combined to a resulting more complex
game. This enables the design of user guidance in the developed VR scene but
the user interactions are only indirectly designed by the chosen archetypes.
This shows a lack of an authoring tool that supports novices in the design of
the scene, interactions, and tasks. Immersive authoring tools enable the
novice to create and modify the interactive VR scene directly inside the 3D
scene instead of the creation and modification of a 2D abstraction of the
scene in non-immersive authoring tools. Another advantage is that Head Mounted
Displays (HMDs) provide the novices with natural interactions. VR GREP [28]
simplifies the development of the scene by supplying the novice with a set of
objects to place in it. The novice can manipulate them directly with natural
interactions. However, in VR GREP, the user is not capable to design
interactions or tasks in an immersive way. This is solved in FlowMatic [11] by
the usage of functional reactive programming [29]. The approach provides the
novice with a way to create interactions in a visual model by connecting
nodes, which are objects inside the scene, and operations, that transform
them. But similar to the usage of statecharts, this presupposes learning for
novices. The results of [30] show that immersive authoring benefits the
authoring of VR, however, the current natural interactions in VR lack the
accuracy of a desktop solution. Additionally, a Head Mounted Display (HMD) is
required to construct the scene and long developing sessions are tiring for
the user. As a consequence, a desktop authoring tool holds still benefits
compared to an immersive authoring tool. The immersive and non-immersive way
of authoring VR scenes is combined in SAVEace [31] to benefit from both
approaches. In summary, we can conclude that existing immersive and non-
immersive VR authoring tools still require a high degree of programming
knowledge which hinders the rapid creation of interactive VR scenes for
novices.

###  II-B End-User Development

The related work of EUD is focused on component-based development and wizard-
based development.

In component-based development, the software is described by a connection of
components. These components have an embedded functionality and a defined
interface to use them. These interfaces are used to connect them. This
abstracts the development. With the help of visual or textual interfaces, the
connection of components can be further abstracted to decrease the entry
barrier for novices. Another advantage is the flexible construction of
software since components can be added easily to the component network or
existing components can be switched with other components. In [32], component-
based development is combined with a domain-specific language to enable
chemistry teachers the development of virtual chemistry experiments. This
resulted in a fast and easy construction. Furthermore, in [33, 34, 35],
component-based development has been applied to support the engineering of
adaptive user interfaces. Cicero Designer [36] enables novices the development
of multi-device museum guides. XRT [26] enables novices the design of cross-
reality interactions by a connection of predefined components. This shows that
component-based development is an often-used approach to supply novices with
methods to develop software themselves. In wizard-based Development, the user
is guided through the development process with a wizard. This requires that
the performed task can be split into smaller steps. As a consequence, the user
is focused on one step instead of all steps at the same time. This approach is
combined with other methods in [37] to customize the visualization of data in
smart homes and in [38] to enable novices to develop e-government services.
Altogether we can observe that existing EUD methods are already used in
various application domains to ease the development of different application
types. Inspired by these approaches, our goal is to provide an end-user
development tool to simplify the creation of interactive VR scenes.

##  III Solution Overview

The goal of VREUD is to decrease the complexity of the development of
interactive VR scenes by supporting novices with a way to create interactive
VR scenes themselves. Component-based and wizard-based development are chosen
to minimize the learning effort for novices to guarantee a low entry barrier.
Consequently, the interactive VR scene is built completely by the combination
of components, and complex development processes are split by the usage of
step-by-step wizards. In our solution approach, the development of interactive
VR scenes consists of the following steps: Construction of the Scene,
Construction of Interactions, and Construction of Tasks.

###  III-A Construction of the Scene

The construction of the scene supports novices in the development of the
visual appearance of their interactive VR scene. The development is abstracted
by a combination of entities to build the VR scene. These entities describe 3D
virtual objects that define the appearance of the VR scene. To provide a
comprehensive design of VR scenes the entities have sub-classes to fit
different needs of the specific virtual object. These types are shown in the
class diagram in Fig. 1. For example, the entities can describe the Geometry
primitives like a box or cylinder, 3D Models which can be added from external
sources, external Media like pictures, videos, and PDF documents, Interaction
Entities like a button, a counter, or a pressure plate which provide new
interactions methods, Taskbars which show tasks to the VR user and a
Navigation Mesh which limits the VR user in the navigation by defining the
area the VR user can move onto.

Figure 1: Class diagram of the entities to describe the scene in VREUD

Every entity contains parameters, that define the representation and behavior
of the virtual object. For example, a 3D box has representative parameters
depth, height, and width to configure the shape of the box and color, or
texture to set the appearance. The parameters position and rotation define the
location of the entity in the scene and behavioral parameters configure, for
example, the shadow and physics of the entity.

The novices are supported in the construction by visualizing the interactive
VR scene in the development. This ensures direct feedback of added entities to
the scene and modified representative parameters of the entities inside the
scene. This enables the novice to spot mistakes immediately. The modification
of parameters is either performed in a form-based representation of all
parameters and the associated values, or by a direct manipulation interface
that utilizes the visualization of the interactive VR scene to change
position, rotation, and scale of the entity directly inside the shown
interactive VR scene.

###  III-B Construction of Interactions

To transform the developed static VR scene into an interactive VR scene,
interactions have to be added. Interactions describe modifications of the
entities inside the VR scene. They enable the VR user to interact with the
entities inside the interactive VR scene. The developed interactions are
event-based. Every interaction describes only an atomic modification of a
specific entity and is triggered by a single event. As a consequence, the
resulting interaction is not powerful, but interactions can be combined to
create more expressive interactions. However, this restriction allows defining
interactions by components that are configured by a simple selection of given
elements. An interaction is defined by the following elements: An Event, that
describes the trigger of an interaction. If the event occurs the designed
interaction is performed. These events can be either triggered by the VR user
or other entities in the scene. For example, when the VR user touches the
entity and presses the trigger button on the controller. An Effect, that
defines the modification of an entity in the scene. For example, an effect can
change the color of an entity. Parameters, which might be needed to perform
the effect. For example, the color blue to change the entity to blue.
Entities, that define the context of the interaction. Every interaction is
defined by two entities. These entities can be the same entity or two
different entities. The source entity defines the source of the event and the
target entity sets the target of the effect. Conditions, which can be added to
an interaction. Conditions define when an interaction can be performed by a VR
user in the scene. All applied conditions have to be fulfilled to perform the
effect of the interaction. For example, the interaction can only be performed
if an entity is placed in a specific location.

A simple interaction can be performed by the VR user at every time. As a
result, the interaction contains no conditions. This allows the usage of an
interface that selects only a source entity, an event, a target entity, an
effect, and parameters needed for the effect which is shown on the left side
of Fig. 2. Since the event is triggered on the source entity and the effect is
performed on the target entity, the chosen source entity defines the set of
possible events and the chosen target entity defines the set of possible
effects. The interface adapts the chosen event and effect to changes in the
selected source and target entity. This guarantees a correct construction of
the interaction since the novice can not choose an event or effect which is
not possible for the chosen source or target entity.

Figure 2: The interface of the interaction construction. The current
configuration results in an interaction that changes the color of Box1 to blue
if the controller touches Box1 and the trigger is pressed. The complex button
opens a wizard to add conditions. The configured condition checks if Box1 has
not the color red before performing the interaction.

A complex interaction is an interaction that can not always be performed by
the VR user. Consequently, conditions are applied to the construction of
interactions. To not overload the interface, a button is added to the
interaction interface shown on the left side of Fig. 2 to open a wizard that
performs the construction of the complex interaction. The setup of a condition
is shown on the right side of Fig. 2. A condition is configured by a condition
type and parameters associated with the chosen type. This enables the usage of
a component to check the specific condition that is configured by a simple
selection. For example, the condition type Entity fulfills a specific
attribute creates a condition that checks if a chosen attribute of a selected
entity fulfills a configured expression. As a result, the complex interaction
can only be performed by the VR user if the attribute of the entity fulfills
the expression. The conditions can be combined to define more complex
conditions. The interface of the condition construction adapts to already
created conditions to prevent conditions that conflict with each other. The
previously introduced interfaces produce interactions for atomic actions that
require an understanding of the events and effects in the scene. To further
decrease the cognitive effort required to perform the construction,
interactivity patterns are supported in VREUD. These patterns are components
in the editor which use a wizard to configure the pattern. The components have
defined input and output to ensure the easy extension of new patterns. The
patterns can result in a set of added entities, interactions, tasks, and
changed parameters of existing elements. As a result, these patterns can
perform a set of construction steps in one step. Consequently, the abstraction
level is higher. Fig. 3 shows one step in the wizard of the construction of
the interactivity associated with a video in the scene. In the pattern, the
novice has to only select entities, which, in this example dialog, start and
pause the video. As a result, the novice has not created both interactions
manually which saves her time in the construction.

Figure 3: The pattern dialog to create interactivity around a video. The user
creates interactions just by the selection of entities. Box1 is configured as
entity to play the video by pressing on it.

###  III-C Construction of Tasks

The construction of tasks supports novices in the development of tasks to
guide the VR user through their developed interactive VR scene. Tasks define
actions the VR user has to perform in the interactive VR scene. The
construction of tasks is inspired by the approach of GREP[25], which resulted
in an easy-to-use and understandable construction of education games. Similar
to GREP, a task is defined by a set of smaller tasks. These smaller tasks will
be called activities. An activity is configured by an activity type that
defines the atomic action the VR user has to perform. This action is tracked
by the activity in the interactive VR scene. This allows encapsulating the
activity in a component that is configured to the specific needs of the
novice. Since the VR user has to be aware of the tasks inside the interactive
VR scene, the tasks and activities have parameters to configure the names and
the descriptions that are shown inside the interactive VR scene. The
construction uses two dialogs to create the task and the activities so that
the novice only needs to focus on the current task or activity. The two
dialogs are shown in Fig. 4. Since some activity types are location
dependable, an area has to be defined. These areas are spawned after the task
construction and they are set up similar to the entities in the construction
of the scene. These areas are also used to decrease the issue to describe the
area in the activity description by showing the transparent area directly in
the interactive VR scene to the VR user. An area is shown in Fig. 5. To not
overload the scene, the area of a solved activity disappears.

Figure 4: The dialog to create a task and the dialog to create an activity.
The task consists of two activities and the shown activity tracks if the VR
user has entered a specific location.

Figure 5: An interactive VR scene developed with VREUD. It is a living room
that shows a presentation (a) to the user. An interaction enables the user to
open the next page by pressing on the remote (b). To complete the task, the
user has to go to the area (c).

##  IV Implementation

VREUD is an open-source web-based authoring
tool111https://github.com/VREUD/VREUD. VREUD has a server-side and a client-
side. The system architecture is presented in Fig. 6 and the architecture of
the VREUD Generator, that generates the interactive VR scenes, is shown in
Fig. 7. The server-side uses Express [39] as a web server. The stored data on
the server is divided into three repositories. Models and Media stores added
models and media by the novices, Interactive VR Scenes saves the generated
interactive VR scenes, and A-Frame Components stores components that implement
the developed interactions and required behavior of the entities since the
generated interactive VR scene uses A-Frame[23]. A-Frame is a web-based VR
framework. The VREUD client-side utilizes React [40], a library for building
user interfaces, and Threejs [22], a framework for web-based 3D scenes, to
implement the component-based interface and to show the interactive VR scene
directly in the interface. The component-based architecture enables easy
extensions of new features in the interface. The interface is presented in
Fig. 8. The interactive VR scene is defined by objects instantiated from a
class system implemented in JavaScript that provides objects for activities,
entities, interactions, and tasks. These objects are stored in the Current
Session. VREUD uses these objects to generate the interactive VR scene with
the help of the VREUD Generator component. The generated interactive VR scene
is translated in A-Frame. A-Frame builds on Threejs to describe VR scenes.
Consequently, both representations of the interactive VR scene do not conflict
with each other, since both use Threejs.

Figure 6: The system architecture of VREUD

The VREUD Generator produces an interactive VR scene implemented in A-Frame
from a given set of objects stored in Current Session on the client-side.
Virtual objects in A-Frame are defined by an entity-component-system
architecture. In it, virtual objects are described by entities containing
components. These components define the appearance or the behavior of the
entity. To implement the component-based approach of VREUD, the generator uses
predefined components that are configured by the novices. These components are
stored in A-Frame Components. The architecture of the generator is shown in
Fig. 7. First of all, in the Scene Generator, the entity is mapped to an
A-Frame entity to implement the appearance. If an external model or media is
used, the generator maps the entity to the stored model or media in Models and
Media. Then Control Components are added if the entity requires them. For
example, a PDF document uses them to control the shown page. After this step,
the scene is completely generated and interactions are added by the
Interaction Generator. These interactions are implemented by Effect Components
which are associated with the chosen effect in the interaction construction.
The component is configured and applied to the source entity since the event
has to be listened at this entity. The optional conditions are also
implemented by Checker Components which are also configured by the novice. The
Task Generator adds new invisible A-Frame entities to the scene to implement
the tasks and activities. Activity entities use Tracker Components to check
the configured actions in the interactive VR scene. If the activity uses an
area, a 3D box is used as the body. The activities are connected to the tasks
to inform them about the completion. Finally, basic user controls are applied
to the scene by the usage of specific User Control Components. The resulting
interactive VR scene is stored in Interactive VR Scenes on the server-side to
provide access to the VR user.

Figure 7: Architectural overview of the VREUD Generator

Figure 8: The interface of the VREUD. (a) lists all entities to instantiate in
the scene, (b) visualizes the interactive VR scene, (c) shows the direct
manipulation interface of the selected entity, (d) shows the form to modify
parameters of the selected entity, (e) lists all entities, interactions, and
tasks of the interactive VR scene, (f) shows the interface to create
interactions and (g) executes the developed interactive VR scene.

In summary, VREUD can execute interactive VR scenes. To utilize this, the
construction is designed to enable prototyping at each step to experience the
current interactive VR scene. This provides direct feedback of the developed
interactive VR scene and the novice can explore the construction.
Additionally, an interactive tutorial supports the novices in their first
construction.

##  V Evaluation

We conducted a usability evaluation to evaluate the effectiveness, efficiency,
and user satisfaction of VREUD. To rate the effectiveness and efficiency, the
participants had to solve assignments whose required time and successful
completion are measured. The user satisfaction is measured by a questionnaire.
The evaluation is performed to gain insights into the required entry barrier
of VREUD and to assess the construction of scenes, interactions, and tasks. To
estimate the usefulness of VREUD for novices, we have invited participants
with mixed knowledge in VR development to compare the results of VR novices
against VR experts. We have decided to perform the usability evaluation
remotely, due to the situation caused by COVID and the web-based architecture
of VREUD that provides easy remote access.

###  V-A Participants and Procedure

We recruited 15 volunteer participants for the usability evaluation via e-mail
invitation. The reported experience level of the participants in VR
development is divided into 9 novices (8 no and 1 low experience) and 6
experts (3 medium and 3 high experience). All experts are familiar with other
VR authoring tools.

The usability evaluation was structured in the following way. At first, we
sent the participants an archive file containing all required data. The
archive file included an introduction to the evaluation process and VREUD, an
assignment list, an image file, and a scene as a starting point of the
evaluation. After reading the introduction, each participant had to solve a
list of assignments. The assignments were divided into the following tasks:

  * •

Navigation in the Scene: To evaluate the navigation interface of VREUD, each
participant had to navigate to a specific point, select an entity and delete
it.

  * •

Scene Adaptation: To evaluate the direct manipulation interface of VREUD, each
participant had to add an external image. This image had to be manipulated to
cover a specific area in the scene by modifying the position, rotation, and
scale of the entity.

  * •

Single Interaction: To evaluate the first construction of a simple
interaction, each participant had to add an interaction to start a video by
pressing a button. The video and button are already contained in the scene.
Finally, the participant had to test the interaction in the VREUD web editor.

  * •

Combined Interactivity: To further evaluate the interaction design, each
participant had to set up a pressure plate, that provides location-based
events since it detects when a VR user enters and leaves the plate.
Afterwards, the participant had to add 5 interactions concerning the
interactivity of a presentation. The first interaction enables to open the
next page by pressing on a button, the second interaction shows the
presentation when the VR user enters the pressure plate, the third interaction
resets the presentation when entering the plate, the fourth interaction hides
the presentation when leaving the pressure plate and the last interaction
changes the color of a plate to green when the presentation is completed.
Finally, the developed interactivity had to be tested in the VREUD web editor
by the participant.

  * •

Task Construction: To evaluate the construction of a task, the participant had
to create a task. The task contained two activities. The first activity is to
go on the stage in the scene. It requires setting up an area. The second
activity is to complete the presentation. If the participant has given up on
the previous assignment, the participant has to create an activity to look on
the fridge in the scene. Finally, the developed task had to be tested in the
VREUD web editor by the participant.

While performing the assignment, each participant had to measure the time for
completing it. The participant was allowed to give up on the assignment which
was noted down by them. The participants were not monitored by us,
consequently, they had to save after each assignment their session. These save
files were used to check if the participant succeeded in the assignment. The
succession rate in the combined interactivity assignment is calculated by the
successfully designed interactions since the assignment is more complex. After
the assignments, the participant had to fill out an online questionnaire that
consisted of a System Usability Scale (SUS)[41] and statements about the
difficulty and learnability of the construction of the scene, interactions,
and tasks. The statements were rated on a 5-point Likert scale (1 strongly
disagree and 5 strongly agree). Finally, the participants had to sent their
measured times, their list of given up assignments, and their set of saved
sessions to us.

###  V-B Results

The results concerning efficiency are presented in Fig. 9. The navigation in
the scene was completed in close average times by both groups (37s experts and
40s novices). The scene adaptation was successfully performed on average in
115s by the experts and 206s by the novices. The single interaction
construction was succeeded on average in 175s by the experts and 286s by the
novices. In the combined interaction, the two groups have a bigger average
difference (562s experts and 819s novices). But the median of experts and
novices is closer (553s experts and 666s novices). The task construction was
completed on average in 437s by the experts and 504s by the novices.

Figure 9: The efficiency results of the usability evaluation.

The results concerning effectiveness are presented in Fig. 10. The navigation
in the scene was completed by all participants. The scene adaptation was
successfully performed by all experts. Two novices manipulated successfully an
image in the scene but they did not add an image. The single interaction
construction was succeeded by all except one novice and one expert. In the
combined interaction, the novices had constructed two interactions incorrectly
and missed adding three interactions. The expert missed adding two
interactions. The two participants who failed the previous assignment have
succeeded. The task construction was completed by all, except for three
novices. Two did not set up the area and one put the area at an incorrect
spot.

Figure 10: The effectiveness results (in percent) of the usability evaluation.

The results of the questionnaire about the construction of the scene,
interactions, and tasks are presented in Fig. 11. The highlight of the results
is the confidence of the participants to design interactions with VREUD (Q5)
which was agreed by all except one novice and one expert. This also affects
the results of the effects of the created interactions (Q4) that are clear to
the participants and the results of the easy-to-learn statement (Q2) of the
interaction construction. The only not so well-performing statement is the
understandability of the events in the construction of interactions (Q3) that
shows there is room for improvement in the self-explanatory of the events
compared to the results of the effects and activity types. However, the
participants had still fun in the construction of the interactive VR scene
(Q9), which was agreed upon by all except one novice. The best results
produced the statement if the prototyping supported the participants in the
development of interactive scenes (Q8).

Figure 11: Results of the questionnaire. The results of the negative
statements are inverted

The results of the SUS are presented in Fig. 12. The highlights are the
results of the statement if the participants require assistance from a
technical person which was disagreed by all except one novice. Another
highlight is that the participants agreed on the statement that they did not
need to learn much to use VREUD. The statement that VREUD is easy to use was
only disagreed by a novice and an expert which is equal to the statement if
VREUD is too complicated which was only disagreed by the same participants.
The worst results have produced the statement about the cumbersomeness of
VREUD. This shows that the usability of the editor can be improved to provide
a more intuitive construction. The average SUS score is 71. This is above the
mean score of web interfaces (68.2) and close to the average score of the
adjective good (71.4) [42].

Figure 12: Results of the SUS questionnaire. The results of the negative
statements are inverted

###  V-C Discussion and Limitation

Our results suggest that VREUD is easy to use and easy to learn. This
indicates the potential of VREUD to aid novices in the construction of
interactive VR scenes since the results of efficiency and effectiveness from
both groups are often close together. The user satisfaction also suggests that
the component-based and wizard-based development have successfully simplified
the construction of interactive VR scenes, due to the wide acceptance of the
participants. The efficiency results of the single and combined construction
of interactions suggest that the novice can design interactions fast after an
initial small learning time. This is shown by the fact that the average time
of the combined interaction design is not five times higher than the single
construction of interaction, although the participant had to create five
interactions. The additional setup of the pressure plate indicates that the
interaction setup was even faster in the combined interaction construction.
However, the results also present that the participants required three to five
minutes on average to set up their first interactions. Consequently, the logic
embedded in the construction of interactions indicates to require an initial
learning time. Combined with the mixed results of the understandability of
events, it could affect the results of novices with no technical background. A
solution to this issue could be the construction of interactions with the help
of interactivity patterns since the higher abstraction suggests that it could
help novices who have issues to understand the embedded logic. On the other
hand, compared to the great results of the participants in the statement that
they felt confident in the construction of interactions, this suggests being a
smaller issue. The results of the construction of tasks indicate that a wizard
combined with the definition of a task by a set of smaller activities that are
configured by an activity type and associated parameters has successfully
lowered the complexity of the development. The self-explanatory of the
activity types was greatly accepted by the participants. Compared to the logic
used in the construction of interactions, the task construction uses generic
activities which should be also clear to novices without a technical
background, since they are comparable to actions in the real world. For
example, an activity type asks the VR user to put an object into an area.
However, the usability evaluation shows an issue in the current
implementation, since three novices have forgotten to set up the area after
the construction. Apart from that, the construction of tasks is still well
accepted among the participants. Finally, the results of the statement if the
participant had fun constructing the interactive VR scene suggests that VREUD
supplies novices with a playful construction of interactive VR scenes, which
could motivate them to develop their first interactive VR scene.

A limitation of the conducted usability evaluation is that VREUD was not
evaluated by novices with no technical background, since all participants had
a background in computer science. The results could not apply to novices with
no technical background. These users could have issues with the embedded logic
in the construction of simple interactions. However, the interactivity pattern
provides a higher abstraction in the construction and the interactive tutorial
supports the novice in their first session. These features combined with the
low entry barrier of VREUD could successfully support novices with no
technical background in the development.

##  VI Conclusion and Future Work

In this paper, we introduced a web-based authoring tool for web-based
interactive VR scenes called VREUD that lowers the entry barrier for novices
to develop their interactive VR scenes. We achieved this by supporting novices
with a component-based construction of the scene, interactions, and tasks of
the interactive VR scene. We decreased further the complexity by using wizards
to focus the user on smaller steps in the development. The effectiveness,
efficiency, and user satisfaction of VREUD were evaluated by a conducted
usability evaluation. We recruited 15 volunteers with mixed backgrounds in VR
development to compare the results of novices and experts. Our results show
that our tool is easy to learn and that it succeeds in lowering the entry
barrier of the development of interactive VR scenes.

In future work, VREUD has to be evaluated with a larger group of heterogeneous
end-users. With this regard, it should be especially investigated if VREUD
supports novices with no technical background in constructing their own
interactive VR scenes. The web-based architecture of VREUD and the generated
interactive VR scenes animate to use them collaboratively. This arises new
challenges in the development, for example, in the construction of social
interactions. VREUD could connect desktop users and VR users to support a
collaborative design and development of interactive VR scenes.

## References

  * [1] E. Yigitbas, I. Jovanovikj, J. Scholand, and G. Engels, “VR training for warehouse management,” in _VRST ’20: 26th ACM Symposium on Virtual Reality Software and Technology_ , R. J. Teather, C. Joslin, W. Stuerzlinger, P. Figueroa, Y. Hu, A. U. Batmaz, W. Lee, and F. R. Ortega, Eds. ACM, 2020, pp. 78:1–78:3.
  * [2] E. Yigitbas, K. Karakaya, I. Jovanovikj, and G. Engels, “Enhancing human-in-the-loop adaptive systems through digital twins and VR interfaces,” _CoRR_ , vol. abs/2103.10804, 2021. [Online]. Available: https://arxiv.org/abs/2103.10804
  * [3] E. Yigitbas, C. B. Tejedor, and G. Engels, “Experiencing and programming the ENIAC in VR,” in _Mensch und Computer 2020_ , F. Alt, S. Schneegass, and E. Hornecker, Eds. ACM, 2020, pp. 505–506.
  * [4] E. Yigitbas, J. Heindörfer, and G. Engels, “A context-aware virtual reality first aid training application,” in _Proc. of Mensch und Computer 2019_ , F. Alt, A. Bulling, and T. Döring, Eds. GI / ACM, 2019, pp. 885–888.
  * [5] R. Dörner, M. Kallmann, and Y. Huang, _Content Creation and Authoring Challenges for Virtual Environments: From User Interfaces to Autonomous Virtual Characters_ , 04 2015, pp. 187–212.
  * [6] M. Nebeling and M. Speicher, “The trouble with augmented reality/virtual reality authoring tools,” in _2018 IEEE International Symposium on Mixed and Augmented Reality Adjunct (ISMAR-Adjunct)_ , 2018, pp. 333–337.
  * [7] Unity. (2021) Unity real-time development platform 3d, 2d vr & ar engine. Accessed: 2021-05-07. [Online]. Available: https://unity.com/
  * [8] Unreal. (2021) The most powerful real-time 3d creation platform. Accessed: 2021-05-07. [Online]. Available: https://www.unrealengine.com/
  * [9] V. Haefner, “PolyVR - A Virtual Reality Authoring System,” in _EuroVR 2014 - Conference and Exhibition of the European Association of Virtual and Augmented Reality_ , J. Perret, V. Basso, F. Ferrise, K. Helin, V. Lepetit, J. Ritchie, C. Runde, M. van der Voort, and G. Zachmann, Eds. The Eurographics Association, 2014.
  * [10] Amazon. (2021) Amazon sumerian overview. Accessed: 2021-05-07. [Online]. Available: https://aws.amazon.com/sumerian/
  * [11] L. Zhang and S. Oney, “Flowmatic: An immersive authoring tool for creating interactive scenes in virtual reality,” in _Proceedings of the 33rd Annual ACM Symposium on User Interface Software and Technology_ , ser. UIST ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 342–353. [Online]. Available: https://doi.org/10.1145/3379337.3415824
  * [12] H. Lieberman, F. Paternò, M. Klann, and V. Wulf, _End-User Development: An Emerging Paradigm_. Dordrecht: Springer Netherlands, 2006, pp. 1–8. [Online]. Available: https://doi.org/10.1007/1-4020-5386-X_1
  * [13] M. Rettig, “Nobody reads documentation,” _Commun. ACM_ , vol. 34, no. 7, p. 19–24, Jul. 1991. [Online]. Available: https://doi.org/10.1145/105783.105788
  * [14] E. Yigitbas, I. Jovanovikj, and G. Engels, “Simplifying robot programming using augmented reality and end-user development,” _CoRR_ , vol. abs/2106.07944, 2021. [Online]. Available: https://arxiv.org/abs/2106.07944
  * [15] S. Gottschalk, E. Yigitbas, E. Schmidt, and G. Engels, “Model-based product configuration in augmented reality applications,” in _Human-Centered Software Engineering - 8th IFIP WG 13.2 International Working Conference, HCSE 2020, Eindhoven, The Netherlands, November 30 - December 2, 2020, Proceedings_ , ser. Lecture Notes in Computer Science, R. Bernhaupt, C. Ardito, and S. Sauer, Eds., vol. 12481. Springer, 2020, pp. 84–104. [Online]. Available: https://doi.org/10.1007/978-3-030-64266-2_5
  * [16] ——, “Proconar: A tool support for model-based AR product configuration,” in _Human-Centered Software Engineering - 8th IFIP WG 13.2 International Working Conference, HCSE 2020, Eindhoven, The Netherlands, November 30 - December 2, 2020, Proceedings_ , ser. Lecture Notes in Computer Science, R. Bernhaupt, C. Ardito, and S. Sauer, Eds., vol. 12481\. Springer, 2020, pp. 207–215. [Online]. Available: https://doi.org/10.1007/978-3-030-64266-2_14
  * [17] I. Jovanovikj, E. Yigitbas, S. Sauer, and G. Engels, “Augmented and virtual reality object repository for rapid prototyping,” in _Human-Centered Software Engineering - 8th IFIP WG 13.2 International Working Conference, HCSE 2020, Eindhoven, The Netherlands, November 30 - December 2, 2020, Proceedings_ , ser. Lecture Notes in Computer Science, R. Bernhaupt, C. Ardito, and S. Sauer, Eds., vol. 12481. Springer, 2020, pp. 216–224. [Online]. Available: https://doi.org/10.1007/978-3-030-64266-2_15
  * [18] E. Yigitbas, S. Sauer, and G. Engels, “Using augmented reality for enhancing planning and measurements in the scaffolding business,” in _EICS ’21: ACM SIGCHI Symposium on Engineering Interactive Computing Systems, virtual, June 8-11, 2021_. ACM, 2021\. [Online]. Available: https://doi.org/10.1145/3459926.3464747
  * [19] S. Krings, E. Yigitbas, I. Jovanovikj, S. Sauer, and G. Engels, “Development framework for context-aware augmented reality applications,” in _EICS ’20: ACM SIGCHI Symposium on Engineering Interactive Computing Systems, Sophia Antipolis, France, June 23-26, 2020_ , J. Bowen, J. Vanderdonckt, and M. Winckler, Eds. ACM, 2020, pp. 9:1–9:6. [Online]. Available: https://doi.org/10.1145/3393672.3398640
  * [20] E. Yigitbas, I. Jovanovikj, S. Sauer, and G. Engels, “On the development of context-aware augmented reality applications,” in _Beyond Interactions \- INTERACT 2019 IFIP TC 13 Workshops, Paphos, Cyprus, September 2-6, 2019, Revised Selected Papers_ , ser. Lecture Notes in Computer Science, J. L. Abdelnour-Nocera, A. Parmaxi, M. Winckler, F. Loizides, C. Ardito, G. Bhutkar, and P. Dannenmann, Eds., vol. 11930. Springer, 2019, pp. 107–120. [Online]. Available: https://doi.org/10.1007/978-3-030-46540-7_11
  * [21] S. Stephenson. (2019, 8) Tiga survey reveals that unity 3d engine dominates the uk third party engine market. Accessed: 2021-05-07. [Online]. Available: https://tiga.org/news/tiga-survey-reveals-that-unity-3d-engine-dominates-the-uk-third-party-engine-market
  * [22] R. Cabello. (2021) Three.js. Accessed: 2021-05-07. [Online]. Available: https://threejs.org/
  * [23] A-Frame. (2021) A-frame. Accessed: 2021-05-07. [Online]. Available: https://aframe.io/
  * [24] Mozilla. (2021) Spoke by mozilla. Accessed: 2021-05-07. [Online]. Available: https://hubs.mozilla.com/spoke
  * [25] T. Zarraonandia, P. Diaz, and I. Aedo, “Using combinatorial creativity to support end-user design of digital games,” _Multimedia Tools Appl._ , vol. 76, no. 6, p. 9073–9098, Mar. 2017. [Online]. Available: https://doi.org/10.1007/s11042-016-3457-4
  * [26] A. Bellucci, T. Zarraonandia, P. Díaz, and I. Aedo, “End-user prototyping of cross-reality environments,” in _Proceedings of the Eleventh International Conference on Tangible, Embedded, and Embodied Interaction_ , ser. TEI ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 173–182. [Online]. Available: https://doi.org/10.1145/3024969.3024975
  * [27] Mozilla. (2021) Hubs - private social vr in your web browser. Accessed: 2021-05-07. [Online]. Available: https://hubs.mozilla.com/#/
  * [28] T. Zarraonandia, P. Díaz, I. Aedo, and A. Montero, “Inmersive end user development for virtual reality,” in _Proceedings of the International Working Conference on Advanced Visual Interfaces_ , ser. AVI ’16. New York, NY, USA: Association for Computing Machinery, 2016, p. 346–347. [Online]. Available: https://doi.org/10.1145/2909132.2926067
  * [29] C. Elliott and P. Hudak, “Functional reactive animation,” _SIGPLAN Not._ , vol. 32, no. 8, p. 263–273, Aug. 1997. [Online]. Available: https://doi.org/10.1145/258949.258973
  * [30] T. Zarraonandia, P. Díaz, A. Montero, and I. Aedo, “Exploring the benefits of immersive end user development for virtual reality,” in _Ubiquitous Computing and Ambient Intelligence_ , C. R. García, P. Caballero-Gil, M. Burmester, and A. Quesada-Arencibia, Eds. Cham: Springer International Publishing, 2016, pp. 450–462.
  * [31] R. Holm, E. Stauder, R. Wagner, M. Priglinger, and J. Volkert, “A combined immersive and desktop authoring tool for virtual environments,” in _Proceedings IEEE Virtual Reality 2002_ , 2002, pp. 93–100.
  * [32] Y. Zhong and C. Liu, “A domain-oriented end-user design environment for generating interactive 3d virtual chemistry experiments,” _Multimedia Tools Appl._ , vol. 72, no. 3, p. 2895–2924, Oct. 2014. [Online]. Available: https://doi.org/10.1007/s11042-013-1554-1
  * [33] E. Yigitbas, K. Josifovska, I. Jovanovikj, F. Kalinci, A. Anjorin, and G. Engels, “Component-based development of adaptive user interfaces,” in _Proceedings of the ACM SIGCHI Symposium on Engineering Interactive Computing Systems, EICS 2019, Valencia, Spain, June 18-21, 2019_ , J. I. Panach, J. Vanderdonckt, and O. Pastor, Eds. ACM, 2019, pp. 13:1–13:7. [Online]. Available: https://doi.org/10.1145/3319499.3328229
  * [34] E. Yigitbas, I. Jovanovikj, K. Biermeier, S. Sauer, and G. Engels, “Integrated model-driven development of self-adaptive user interfaces,” _Softw. Syst. Model._ , vol. 19, no. 5, pp. 1057–1081, 2020. [Online]. Available: https://doi.org/10.1007/s10270-020-00777-7
  * [35] E. Yigitbas, A. Hottung, S. M. Rojas, A. Anjorin, S. Sauer, and G. Engels, “Context- and data-driven satisfaction analysis of user interface adaptations based on instant user feedback,” _Proc. ACM Hum. Comput. Interact._ , vol. 3, no. EICS, pp. 19:1–19:20, 2019. [Online]. Available: https://doi.org/10.1145/3331161
  * [36] G. Ghiani, F. Paternò, and L. D. Spano, “Cicero designer: An environment for end-user development of multi-device museum guides,” in _End-User Development_ , V. Pipek, M. B. Rosson, B. de Ruyter, and V. Wulf, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2009, pp. 265–274.
  * [37] N. Castelli, C. Ogonowski, T. Jakobi, M. Stein, G. Stevens, and V. Wulf, “What happened in my home? an end-user development approach for smart home data visualization,” in _Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems_ , ser. CHI ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 853–866. [Online]. Available: https://doi.org/10.1145/3025453.3025485
  * [38] D. Fogli and L. Parasiliti Provenza, “A meta-design approach to the development of e-government services,” _Journal of Visual Languages & Computing_, vol. 23, no. 2, pp. 47–62, 2012, special issue dedicated to Prof. Piero Mussio. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S1045926X11000747
  * [39] O. Foundation. (2021) Express. Accessed: 2021-05-07. [Online]. Available: https://expressjs.com/
  * [40] F. O. Source. (2021) React. Accessed: 2021-05-07. [Online]. Available: https://reactjs.org/
  * [41] J. Brooke, “Sus: A quick and dirty usability scale,” _Usability Eval. Ind._ , vol. 189, 11 1995.
  * [42] A. Bangor, P. Kortum, and J. Miller, “Determining what individual sus scores mean: Adding an adjective rating scale,” _J. Usability Studies_ , vol. 4, no. 3, p. 114–123, May 2009.

  *[VR]: Virtual Reality
  *[EUD]: End-user Development
  *[GREP]: Game Rules scEnario Platform
  *[HMDs]: Head Mounted Displays
  *[HMD]: Head Mounted Display
  *[SUS]: System Usability Scale


###### Abstract

In 2016 one arm of the AFP detector was installed and first data have been
taken. In parallel with integration of the AFP subdetector into the ATLAS TDAQ
and DCS systems, beam tests and preparations for the installation of the
2${}^{\textrm{nd}}$ arm are performed. In this report, a status of the AFP
project in the ATLAS experiment is discussed.

##  Chapter 0 Prospects and Results from the AFP Detector in ATLAS

###  1 Introduction

ATLAS[1] is a general purpose detector operating at the LHC[2] . Apart from
the main apparatus a new group of forward detectors is installed in order to
extend the scope of possible measurements. The existing Zero Degree
Calorimeter[1] mounted $140\text{\,}\mathrm{m}$ away from the nominal
interaction point (IP) is dedicated to the measurement of the forward neutrons
and photons. The Absolute Luminosity For ATLAS (ALFA)[3] detector, situated
about $240\text{\,}\mathrm{m}$ from IP, is devoted to the measurement of
elastic scattering. The latest detector is named ATLAS Forward Proton (AFP)[4]
. It is dedicated to studies of diffractive processes and its main purpose is
to measure forward protons.

###  2 The AFP Detector

The AFP detector is designed to consist of four stations, two on each side of
ATLAS along the beam-pipe. The stations are located
$\pm{}206\text{\,}\mathrm{m}$ and $\pm{}214\text{\,}\mathrm{m}$ away from the
ATLAS IP. Each station is equipped with Roman Pots which allow the horizontal
movement of the detector components and their insertion into the beam-pipe.
This enables precise positioning of the detector in the vicinity of the beam.
Positions of the stations and detectors result in acceptance of protons with
relative energy loss of about ${\xi=(E-E^{\prime})/E\in(0.02,0.12)}$, where
$E$ and $E^{\prime}$ are incoming and outgoing proton energies, respectively.

Each station is designed to house four planes of the tracking detectors. Far
stations (i.e. the ones placed at $\pm{}214\text{\,}\mathrm{m}$) will be
equipped with time-of-flight counters.

Silicon pixel detectors are used for tracking. Each plane contains $336\times
80$ pixels of size $50\times 250$${\mathrm{\SIUnitSymbolMicro m}}^{2}$. The
modules are similar to the ones used in ATLAS IBL[5] and are radiation hard.
The detectors are tilted by $14\text{\,}\mathrm{\SIUnitSymbolDegree}$ with
respect to the vertical direction, which makes that majority of the protons
pass two pixels.

In the Technical Design Report[4] the time-of-flight counters are stated to
have time resolution of $10\text{\,}\mathrm{ps}$ or better and efficiency of
at least $90\text{\,}\mathrm{\char 37\relax}$. This enables measurements in
the environment of about 50 interactions per bunch crossing on average and
allows to identify the vertex from which the proton measured in AFP originates
with resolution of $2.1\text{\,}\mathrm{mm}$ in the longitudinal direction.
Moreover, the detectors have to be fast enough to provide the trigger signal,
which is challenging due to their location at $214\text{\,}\mathrm{m}$ away
from the ATLAS detector. The main purpose of the time-of-flight detectors is
to identify the vertex from which the proton measured in AFP originates. Thus
they are crucial in runs with many interactions per bunch crossing (high pile-
up) in standard runs, in which AFP is expected to take part in 2017.

AFP installation is staged. The first stage during which one arm of the AFP
detector “AFP 0+2” was installed took place before data taking in 2016. The
installation of the other arm, “AFP 2+2”, is scheduled for the beginning of
2017.

###  3 AFP 0+2

The first stage of the AFP detector installation covered placing two stations
in the LHC tunnel. Both stations were situated on the same side of ATLAS. They
were equipped only with tracking detectors. The stations had to pass the LHC
qualification, because the detectors are inserted into the beam-pipe.
Additionally, the detector control (DCS), data acquisition (DAQ) as well as
trigger systems had to be integrated with the ATLAS central systems. As a
result of successful installation and almost flawless detector operation it
was possible to collect first data for physics analysis already in 2016,
although it was not initially planned.

In 2016 AFP participated in two physics runs. In these special runs the pile-
up was low. In total almost $500\text{\,}{\mathrm{nb}}^{-1}$ of integrated
luminosity was collected. The detectors performed very well. In Fig. 1 the
number of hits per silicon detector plane based on the 2016 data is presented.
In most of the events the signal is registered in two pixels which is exactly
what was expected due to the tilt of the silicon planes. A strong correlation
between the neighbouring planes can be observed in Fig. 2 where the pixel row
index in the second plane versus the first plane is plotted for events with up
to two pixel hits in a layer.

A natural physics program for this configuration contains the studies of
single diffractive dissociation (SD). In this process a forward proton and a
hadronic system well separated in rapidity are present in the final state. The
cross section of this process is relatively large which enables studies using
the low pile-up data. So far the ATLAS collaboration did not publish any
result of the SD measurement with identification of a forward proton, which
allows to distinguish between single diffractive and low-mass double
diffractive dissociations. The AFP detector delivers a unique possibility of
performing such measurements in the kinematic region of the relative proton
energy loss in the range $\xi\in(0.02,012)$. Moreover, it will provide access
to so far unavailable kinematic variables like the four-momentum transfer in
the proton vertex $t=(P-P^{\prime})^{2}$, where $P$ and $P^{\prime}$ are the
incoming and outgoing proton four-momenta, respectively.

Figure 1: Number of hits in a plane based on 2016 data.[6]

Figure 2: Correlation of pixel rows between first and second planes of
tracking detectors based on 2016 data.[6]

###  4 AFP 2+2

The final AFP installation is scheduled for early 2017. It includes placing of
two new stations in the tunnel, installation or replacement of the current
tracking and time-of-flight detectors. These actions have to be followed by
the LHC qualification procedure. Additionally, the time-of-flight detectors
have to be integrated with the ATLAS trigger system. The full instrumentation
of AFP will allow data taking in special low pile-up runs as well as in
standard runs with high pile-up.

This configuration, just like the AFP 0+2 one, is good for studies of single
diffractive dissociation in special runs with clean environment. However, the
possibility to measure forward protons on both sides and collect high
integrated luminosity in standard runs gives access to central diffractive
processes with small cross-sections. In addition, information about event’s
full kinematics is provided. A reach diffractive physics program, including
exclusive dijet production or central diffractive photon-jet production, aims
at better understanding of the nature and structure of the colour singlet
exchange. However, the program is not limited to this kind of studies only.
There are also plans to investigate photon-induced processes for which the
proton tag provides a very good background rejection. The exclusive lepton
production measurements[7] can be improved. The possibility to discover new
physics lies e.g. in the studies of anomalous quartic couplings.

###  5 Summary

All operations of the AFP detector, dedicated to measurements of the forward
protons mainly originating from diffractive interactions, are on schedule. The
first stage, AFP 0+2, was finished in 2016 and the data for physics analysis
were collected in special runs with low pile-up. The second and final
installation stage, AFP 2+2, will be finished in 2017. The timing detectors
installed then will allow the measurements of the forward protons in standard
runs with high pile-up, thus providing access to central diffractive processes
characterised by small cross-sections. The usefulness of the AFP detector is
reflected in its reach physics program presented in the “Technical Design
Report for the ATLAS Forward Proton Detector”[4] .

###  6 Acknowledgement

This work was partly supported by the National Science Centre of Poland under
contract No. UMO-135 2015/18/M/ST2/00098 and by PL-Grid Infrastructure.

## References

  * 1. ATLAS Collaboration, The ATLAS Experiment at the CERN Large Hadron Collider, _JINST_. 3, S08003 (2008).  10.1088/1748-0221/3/08/S08003.
  * 2. L. Evans and P. Bryant, LHC Machine, _JINST_. 3, S08001 (2008).  10.1088/1748-0221/3/08/S08001.
  * 3. S. Abdel Khalek et al., The ALFA Roman Pot Detectors of ATLAS, _JINST_. 11(11), P11013 (2016).  10.1088/1748-0221/11/11/P11013.
  * 4. ATLAS Collaboration.  Technical Design Report for the ATLAS Forward Proton Detector.  Technical Report CERN-LHCC-2015-009. ATLAS-TDR-024 (May, 2015).  URL https://cds.cern.ch/record/2017378.
  * 5. M. Capeans et al.  ATLAS Insertable B-Layer Technical Design Report.  Technical Report CERN-LHCC-2010-013. ATLAS-TDR-19 (Sep, 2010).  URL https://cds.cern.ch/record/1291633.
  * 6. https://twiki.cern.ch/twiki/bin/view/AtlasPublic/ForwardDetPublicResults .
  * 7. ATLAS Collaboration, Measurement of exclusive $\gamma\gamma\rightarrow\ell^{+}\ell^{-}$ production in proton-proton collisions at $\sqrt{s}=7$ TeV with the ATLAS detector, _Phys. Lett._ B749, 242–261 (2015).  10.1016/j.physletb.2015.07.069.