Project topics and materials
Get Complete Project Material File(s) Now! »
Improvements to the OpenDSA Book Configuration System
This chapter covers improvements made to the OpenDSA book configuration system. First, we describe some issues with the prior OpenDSA book configuration system. Next, we present steps taken to simplify the format used to store OpenDSA book configurations in files, so as to make manually creating and maintaining OpenDSA book configurations easier. We then present a graphical user interface we developed that makes it easier for non-expert users to create and customize their own book configurations without having to manually modify JSON configuration files. We also include a comparison of OpenDSA’s book configuration system to the book configuration systems of two other eTextbook platforms.
Prior Issues
Prior to this thesis, OpenDSA book configuration files were always hand-crafted, and had to be manually kept in sync with the corresponding module RST files. So, for example, if the name of a section changed, any configuration files containing the module with that section had to be updated. If a new exercise was added to a module, it had to be added to every configuration file containing that module. In addition, settings for each and every exercise and visualization had be specified in the configuration file.
Prior Issues
visualizations have the same or similar settings, so this resulted in verbose configuration files with a large amount of duplication. We will refer to this book configuration format as the “full” configuration format. A sample of the full configuration format is show in Listing
A New Book Configuration Format
In an attempt to resolve some of the issues with the original book configuration formats, we developed a new configuration format. The main feature of this new configuration format is that it allows for default settings to be specified for each exercise and visualization type, but also allows for those default settings to be overridden for specific exercises and visualizations. A sample of the new configuration format is shown in Listing 3.3. This new format is significantly less verbose than the full configuration format since settings do not have to be specified unless they deviate from the defaults. In addition, it is not required to list
A New Book Configuration Format
each individual section, exercise, and visualization in the configuration unless the settings are being overridden for a given section, exercise, or visualization. To give an idea of the conciseness of the new format, one of the configuration files in the full format is 3,236 lines and 98,977 characters long, while the same configuration in the new format is only 623 lines and 14,220 characters long.
Book Configuration GUI
In order to make it easier for non-expert users to create and customize their own book configurations, we developed a graphical web interface. This interface allows users to load one of the reference configurations that are created and maintained by OpenDSA developers. The user can then modify the reference configuration to suit their needs, and save it to the OpenDSA database so that it is available for them to choose when they create their course. Users can also load a previous configuration that they saved to the OpenDSA database, upload a configuration file that they have saved locally, or build their own configuration from scratch. The interface also allows users to modify book meta-data and global settings such as title, description, and the programming language(s) used for code examples. In addition, the user can set the default settings for each exercise and visualization type.
Issues Addressed
The new book configuration format addresses the issue of the original “full” configuration format being verbose, since it only requires that the settings for sections and exercises be explicitly listed if those settings differ from the default settings. Since the new configuration format only requires that sections and exercises be listed in the configuration file if the settings are different from the default settings, this also somewhat mitigates the issue of configuration files having to be kept in sync with the module RST files, although it does not completely eliminate it. For example, if a section in a module RST file is changed, only configuration files that are overriding the default settings for that section have to be updated with the new configuration format, whereas the old configuration format requires updating every configuration file containing the module with that section. The new format also addresses the issue of the “simple” configuration format not allowing for exercise and section settings to be customized.The book configuration GUI mitigates the issue of configuring OpenDSA books not being friendly to newcomers, while still allowing for book customization on par with crafting a book configuration file manually. The GUI makes it so that users do not have be familiar with the JSON book configuration format that OpenDSA uses in order to create or customize their own book configuration. Users also do not have to be familiar with the possible settings available for different book options since the options and possible settings are listed and enforced by the GUI.
A Comparison With Other eTextbook Platforms
Two other interactive eTextbook platforms that allow for some level of book configuration are Runestone Interactive [1] and zyBooks [2]. In this section we compare the book configuration systems of these two eTextbook platforms with OpenDSA’s system.
Runestone Interactive
Runestone Interactive is an open-source platform for interactive Computer Science eTextbooks that offers a library of ready-made books. Like OpenDSA, Runestone uses reStructured Text (RST) as its authoring format, with Sphinx being used to compile the RST files into HTML. Runestone textbooks are each stored in a separate Git repository that contains all of the RST files that will be included in the book, with all of the RST files stored in a directory named _source. These RST files are organized into folders within the _source directory, with each folder containing the RST files for a single chapter. In order to control what RST files are included in a book, Runestone uses the Sphinx toctree directive, which directs Sphinx to generate a table of contents based on the RST files listed under the directive. Each chapter’s folder contains an index RST file with a toctree directive that lists the relative path to each of the RST files that are to be included in the chapter in the order that they are to be included. All of the chapter folders are contained in a parent folder, along with a main book index RST file with a toctree directive that lists the relative file path for each of the chapter index files in the order that the chapters are to be included in the book. Runestone does not currently offer a GUI for customizing books. Thus, modifying a Runestone book would require modifying potentially multiple index RST files, depending on what customizations were desired. In order to re-order the chapters in a book, one needs to modify the order that the chapter index files are listed in the book’s main index file. In order to rename a chapter, one has to modify the chapter’s RST file. To re-order, remove, or add content to a given chapter, one must modify the index RST file of that chapter. However, having a separate index file for each chapter is not a strict requirement of Sphinx; it is also possible to have a single index file that directly lists the RST files for all of the chapters.
1 Introduction
1.1 Motivation
1.2 Objectives
1.3 Contributions
1.4 Structure of Thesis
2 Background
2.1 Learning Tools Interoperability
2.2 OpenDSA
3 Improvements to the OpenDSA Book Configuration System
3.1 Prior Issues
3.2 A New Book Configuration Format
3.3 Book Configuration GUI
3.4 Issues Addressed
3.5 A Comparison With Other eTextbook Platforms
4 Interoperability Improvements and Issues
4.1 Becoming an LTI Tool Consumer
4.2 Improving OpenDSA Content Reusability
4.3 Issues and Limitations
5 The Future of the E-Learning Ecosystem
5.1 Background
5.2 Problems, Goals, and Issues
5.3 Learning Analytics Specifications
5.4 Learning Record Stores
5.5 Architectures for Sharing Learning Analytics Data
5.6 Summary and Discussion
6 Conclusions and Future Work
6.1 Conclusions
6.2 Future Work
GET THE COMPLETE PROJECT
Improving the Interoperability of the OpenDSA eTextbook System
