Work at and on the Hamburg Open Online University (HOOU) is leading to a variety of ideas and new creative approaches at the TUHH. Processes such as “digitization” and “opening” in universities are being discussed and interpreted at different levels, and technical solutions are being considered and evaluated in a new light against the backdrop of current trends and developments. The development of the HOOU is thus impacting on the TUHH. In recent weeks it has led to the conception and implementation of internal solutions, the experience and results of which are to feed back into the broader context of the HOOU. This paper presents the initial results of this development. This phase was guided by the basic principles of Open Educational Resources (OER), an approach of loose coupling of technical systems, and above all prioritization of didactic requirements over technical possibilities.

Technical requirements for OER

If in implementing this approach one is closely guided by the principles that David Wiley proclaimed as the mission of the OER movement, specific requirements for technical implementation result. Analogously to Richard Stallmann, who recorded the essential freedoms for free software in the GPL, Wiley formulated his “5 Rs.” Accordingly, users of OER should be able to:

“1. Retain – the right to make, own, and control copies of the content (e.g., download, duplicate, store, and manage)
2. Reuse – the right to use the content in a wide range of ways (e.g., in a class, in a study group, on a website, in a video)
3. Revise – the right to adapt, adjust, modify, or alter the content itself (e.g., translate the content into another language) 4. Remix – the right to combine the original or revised content with other material to create something new (e.g., incorporate the content into a mashup)
5. Redistribute – the right to share copies of the original content, your revisions, or your remixes with others (e.g., give a copy of the content to a friend)”¹

Along with the 5 Rs, Wiley goes on to suggest the technical environment to be considered when producing and delivering OER. His ALMS Framework is as follows:

“1. Access to Editing Tools: Is the open content published in a format that can only be revised or remixed using tools that are extremely expensive (e.g., 3DS MAX)? Is the open content published in an exotic format that can only be revised or remixed using tools that run on an obscure or discontinued platform (e.g., OS/2)? Is the open content published in a format that can be revised or remixed using tools that are freely available and run on all major platforms (e.g., OpenOffice)?
2. Level of Expertise Required: Is the open content published in a format that requires a significant amount technical expertise to revise or remix (e.g., Blender)? Is the open content published in a format that requires a minimum level of technical expertise to revise or remix (e.g., Word)?
3. Meaningfully Editable: Is the open content published in a manner that makes its content essentially impossible to revise or remix (e.g., a scanned image of a handwritten document)? Is the open content published in a manner making its content easy to revise or remix (e.g., a text file)?
4. Self-Sourced: It the format preferred for consuming the open content the same format preferred for revising or remixing the open content (e.g., HTML)? Is the format preferred for consuming the open content different from the format preferred for revising or remixing the open content (e.g. Flash FLA vs SWF)?”²

If one takes these rights and technical requirements for OER as a strict specification for the conception and implementation of a technical environment, there are consequences at the detailed level in respect of the file storage format and the nature of the location where open teaching and learning materials are made available. The software used must be taken into consideration, along with the skills and motivation of the players involved.

Against the backdrop of these conceptual stipulations guiding action in the context of the Open Education Movement, initial experiences of Early Bird supervision at the TUHH are taking shape.

OER: Decoupling of content and structure

At the TUHH the view has become established that separation of a teaching-learning arrangement into structuring and content units makes sense. This separation has the advantage of making content accessible openly and independently of a chronological process, thereby improving its shareability, further use and re-contextualization. In practice this means that interested parties can formulate their own questions and ideas to engage with a learning resource outside a structured process, and to develop it further where appropriate. Wikis and forums are examples of tools for creating places of this kind. At best, a learning community will come into being that attracts many interested parties because it permits high degrees of freedom for situating topics and content³. However, newer formats and tools for the provision and collaborative further development of content are also possible, as will be shown below.

There are some inspiring examples of the separation of content and structure in P2PU, such as the learning community “Play With Your Music”. Here, learning activities are centered around a modern forum based on the free software Discourse that calls on learners to engage cooperatively and/or collaboratively with the content. Upstream is a website that gives interested persons the choice of learning alone or with others in a group. If a sufficient number of interested persons come together, the cohort is guided through the content in a structured way⁴. This idea is implemented with a Mechanical MOOC by P2PU.

The concept of Course in a Box by P2PU brings another idea into the discussion. Fully in line with the OER idea, the aim is to enable interested persons to develop a learning offering themselves or to adapt and re-contextualize existing offerings for their own purposes. The approach to teaching how to create a Course in a Box is not just to supply a guide to organizing a learning arrangement of this kind. Instead, the guide itself is the software engineering starting point for your own offering. The Create Your Course page contains a description of what to do. This process refers to fork and contribute, a new cultural technique of sharing that has developed in the organization of software development work processes. I will explain below how these influences can be utilized for the OER concept and the HOOU.

Steps for developing an HOOU technical environment at the TUHH

A kind of self-experiment can be held responsible as the starting point of the step towards an HOOU technical environment at the TUHH, as described below. When I had to redesign the “Informatics I” course, I discovered there was no specific script or textbook to support students in processing the course topics. It quickly became evident that I should compensate for this lack by producing new and customized material. This gave rise to the idea of making this material available to prospective vocational school teachers on the course in the form of an OER resource that they could subsequently adapt to their own professional requirements and utilize for designing their own lessons. Guided by Wiley’s requirements and degrees of freedom for OER, I looked for a technical implementation tool that I could use to produce the material. In doing so I found the GitBook website and software, which seemed ideal for developing learning resources. Hence, the script Python.Processing.Arduino was generated online while the course was running. It changed frequently as a result of criticism and suggestions by students and tutors during production⁵. The students mainly used the online version, which exists in a simple HTML construct with an outline function and scroll function and enables incorporation of videos and other media. From time to time they also downloaded the PDF version⁶. My experience with the tool and the online service was very positive and I enjoyed authoring a living document in this way. The only thing that disturbed me was that in order to do so I was dependent on a service that was not under my control as regards data retention and functionality. As I will show in the following sections, it was possible to reduce or even remove these dependencies by meaningful coupling of individual free software components.

The simplicity and clarity of GitBook suggests a further use that implements the separation of structure and content I described at the beginning. Learning arrangements can also be mapped in the form of a GitBook. As a rule, these are linear in structure and in their most elementary form consist of a succession of work instructions and interaction offers (see again the structure of Course in a Box)⁷. Thus the use of GitBooks in HOOU serves a dual purpose, with a conceptual distinction between the two:

• Content GitBooks are multimedia HTML pages of linear structure that can be used to prepare information and supply it in a similar way to a textbook.
• Learning Arrangement GitBooks (LA GitBooks) are HTML pages of linear structure that can be used to structure a learning arrangement in the form of a sequence. They contain less specific specialist content, but rather formulations of goals, assignments, proposed methods, interaction offers, and general information on processing and dealing with content.

This idea gave rise to a design for the technical landscape at the TUHH with which several Early Bird projects are now being implemented. The overall construct with its individual units and interfaces will be presented in more detail below.

Technologies, software and interfaces

The developing HOOU technical environment at the TUHH is divided into various components that are currently being evaluated in the first Early Bird projects. Fig. 1, which is referred to in the following sections, should serve to demonstrate the structures and software solutions presented.

GitBook

GitBook is both an online service and a collection of free software tools that can be used for collaborative processing of text documents of linear structure. Thus GitBook is nothing but a simple and effective Static Site Generator⁸. Along with the aforementioned script Python.Processing.Arduino there are further examples of GitBooks on the service’s online presence.

Markdown: the online lingua franca

GitBooks are written in Markdown. Markdown is a widespread way of marking up text, or marking parts of it as headings, lists or emphases⁹. The Markdown documentation on the GitBook website conveys a visual impression of the concept. The aim of writing in Markdown is to convert documents subsequently into different formats, usually into HTML. This also happens in the GitBook production process, which involves generating a static HTML page from several structured Markdown documents.

Markdown is very helpful to the OER idea, since texts can also be converted into PDF and Office documents. Even presentations are possible¹⁰. Because the ultimate format has not been decided when producing Markdown texts, it is easy to comply with the requirement to distribute OER material not only as open source but also in a form that is technically easy to edit. The only thing required for editing is a text editor (Notepad, TextEdit or GitBook Editor), and the estimated cost of training qualified authors is low. Since Markdown is increasingly widespread on the Net, writers learn a modern means of expression that enables participation in collaborative processes in many other places.

There is a further advantage to using Markdown. Since Markdown documents are pure text files, technically they can be treated in exactly the same way as those that contain software code. As sec. 4.2 is intended to show about GitLab, that is a major advantage in terms of the shareability and re-usability of OER materials.

Markdown can easily be mixed with HTML elements. That external media and resources can be incorporated into the GitBook at any point with the help of the HTML tag iframe could be seen as an advantage¹¹. The benefit of this possibility will become clear in a later section on the interlinking of LA GitBooks and Discourse (cf. sec. 4.2.4).

Cooperation with the Early Bird teams

The production of LA GitBooks and Content GitBooks takes place collaboratively at the TUHH. Early Bird supervisors, research assistants and teachers initially work together on larger Markdown documents that are shared on TUHH Owncloud. Later, this content is divided into individual files in accordance with GitBook conventions and developed further collaboratively (cf. Fig. 1). But how do these files become a GitBook that can be used, copied, edited and used further by others? To meet these requirements, an instance of GitLab software is used. Its functionality and role will be explained in more detail below.

Collaboration with GitHub and GitLab

The page Course in a Box: Create Your Course invites you to act with the following sentence: “Fork this repository on GitHub”. Fork is the core concept of sharing in the manner of the GitHub service and means copying someone’s project files into your own GitHub account. This gives users the freedom to do what they like with the files without having to ask the originator for permission to become involved. As a rule, fork in this case is not an aggressive act that initiates entry into a competition for the better product¹². Rather, it is customary for improvements and changes resulting from the fork to be reported back to the originator with a pull request to integrate the changes into the original. In terms of OER ideas this signifies a decisive difference from Wikis. In this form of cooperation all involved are in principle always full participants in the data that constitutes a resource. In the classic database-based Wiki, it is not possible to fork without a request for and release of the appertaining data(base)¹³. However, this is not the only advantage in terms of maximum forkability. Compared with a Wiki, re-contextualization is performed relatively quickly in a fork, especially if the raw data consists of Markdown files, for example in the form of a GitBook. Such changes can range from changing the university logo to restructuring, supplementing, or omission of units, or enrichment with media.

Maximum Forkability with GitLab

Forking is also possible with GitLab. GitLab is free software that emulates the proprietary service GitHub and the Web-based exchange of files according to the principles of the version control system Git. If universities want to be independent of services that can change data use and handling rules at any time and even lock the data in their technical environment, free software solutions such as GitLab exist that are freely configurable and extendable. GitLab can be hosted on university servers and the current version is used at the TUHH for the HOOU.

Learning to share with Git and GitLab

So far there are few research findings on the use of Git/GitHub/GitLab in teaching and learning contexts, but in general the learning curve can be estimated as steep (see Zagalsky, Feliciano, Storey, Zhao & Wang, 2015). During the semester I am currently testing with my students the use of GitHub as a collaboration platform in teaching in order to identify the stumbling blocks and to learn more about the introduction of this promising tool.

In view of the steep learning curve we at the TUHH have decided not to burden colleagues at the interfaces with the Early Bird teams with acquiring Git/GitLab skills. We only ask them to file their articles in the form of Markdown files in a shared Owncloud folder. GitBooks are prepared by individual colleagues who are curious to explore the possibilities of this new form of collaboration. Simultaneously, we are trying to find out how meaningful and affordable Git/GitLab is for the production and further use of OER materials at the TUHH, including for research associates, student assistants and teaching staff.

Continuous publication of GitBooks

GitLab brings with it a component that enables automatic tests in software development (Continuous Integration). This quality assurance tool is repurposed in the context of GitBook production to ensure automatic generation of the GitBook HTML page every time changes are uploaded in GitLab (push). This means that the “source text” of a GitBook is always available on GitLab, but that the LA GitBook or Content GitBook can be published automatically anywhere on the Net.

This Continuous Deployment offers great added value, and not only for work with and on GitBooks. The workflow also makes sense in combination with other static site generators that process Markdown and then build good-looking and structured websites. So GitBook is only an exchangeable generator at the end of a flexible technical process.

Embedding of other media and tools

In an HTML context it is easy to embed other media from the Web. Many services such as Podcampus, Youtube, Twitter etc. offer integration of content into their own contexts. For this, the old HTML tag iframe is used. This loose coupling of media and tools is fully in line with the remix freedom of OER materials. For the Early Bird projects at the TUHH, discussions that take place in a Discourse forum are integrated into a GitBook by means of an iframe. In this way, elements from the learning community are connected with the LA Gitbook (cf. Fig. 1). Podcampus videos are integrated in the same way.

GitLab as an OER repository

A central tenet of the HOOU idea is that all OER materials generated should be provided in an OER repository. Here, too, the TUHH sees GitLab as a possible tool for technical implementation. Raw data and finished OER materials can be made publicly available to download or fork via GitLab. The next steps of our work will be to further develop this approach and test its suitability.

GitLab manages projects that are technically known as repositories. Any number of files can be stored in each repository. They should be text line-based as is the case with program code and Gitbooks. This favors collaboration by means of Git as described above. However, it is also technically possible to store other file formats such as Office documents or presentations, because these, too, can be recorded by Git/GitLab and can be annotated to indicate changes. GitLab is not suitable for storing moving image material and not recommended for managing pictures and graphics.

Since the homepage of a GitLab instance seems very technical¹⁴, a more appealing and functional home page with a search function could conceivably be installed upstream. GitLab’s public interface (API) permits adjusted processing of stored data.

Sandstorm as a further education instrument

Current studies show that by no means all students are as adept at dealing with modern Web applications as is always assumed¹⁵. The same may apply in part to teachers and other colleagues at universities, which is why we can assume a need for information and further education. In the context of Early Bird supervision at the TUHH one sees that it is good to inform everyone involved, first about the possibilities and potential of current tools¹⁶, in order to win them over to the process of joint development of a convincing learning arrangement.

Sandstorm software performs a good service in this respect as it assembles more than fifty free software tools in a single access and enables both teachers and learners to build their own media-based learning environment. In the course of evaluating media-based learning forms for the HOOU, Sandstorm is used experimentally in a variety of contexts so as to ascertain the potential for teaching and further education (see Knutzen & Howe, 2013). I have written about Sandstorm’s functioning and possibilities in my personal blog¹⁷.

Summary

The Hamburg Open Online University has given the TUHH a strong impetus for engagement with the subjects of digitization, openness and university didactics. In this article we have presented an approach to the technical implementation of HOOU learning arrangements at the TUHH with reference to the principles of the open education movement and their technical and didactical implications.

References

• Kerres, M. (2012). Mediendidaktik: Konzeption und Entwicklung mediengestützter Lernangebote. München: Oldenbourg.
• Knutzen, S., & Howe, F. (2013). Digitale Medien in der gewerblich-technischen Berufsausbildung – Einsatzmöglichkeiten digitaler Medien in Lern- und Arbeitsaufgaben. foraus.de/BIBB. Accessed Dec 12, 2013. Retrieved from http://datenreport.bibb.de/media2013/expertise_howe-knutzen.pdf
• Reinmann, G. (2010). Studientext Didaktisches Design. Studientext, Universität der Bundeswehr, München. Accessed May 5, 2015. Retrieved from http://gabi-reinmann.de/wp-content/uploads/2010/04/Studientext_DD_April10.pdf
• Tkacz, N. (2015). Wikipedia and the Politics of Openness. Chicago; London: University of Chicago Press.
• Wild, E., & Möller, J. (Eds.). (2015). Pädagogische Psychologie (2nd ed.). Berlin, Heidelberg: Springer Berlin Heidelberg. Accessed August 10, 2016. Retrieved from http://link.springer.com/10.1007/978-3-642-41291-2
• Zagalsky, A., Feliciano, J., Storey, M.-A., Zhao, Y., & Wang, W. (2015). The Emergence of GitHub as a Collaborative Platform for Education (pp. 1906–1917). ACM Press. http://doi.org/10.1145/2675133.2675284

---

Fotocredits: “Karelia” von Petr Magera@flickr, CC-BY

“Developing an Open Technical Infrastructure for HOOU Learning Arrangements at the Hamburg University of Technology (TUHH)” by Axel Dürkop is licensed under Creative Commons Attribution 4.0 International License.

This article was originally posted on the HOOU blog April 28, 2016 in German and can be found at https://projekte.hoou.de/p/2016/04/28/entwicklung-einer-offenen-technischen-infrastruktur-fuer-hoou-lernarrangements-an-der-tuhh/.