At the last ILIAS-DevConf, the Technical Board presented a new Strategy Paper (PDF-Download) that outlined the key points of its future work. The paper has its roots in the ILIAS-Vision that was formulated in 2015. We spoke to the Speaker for the Technical Board, Alexander Killing, about the contents of the strategy and the measures that will result from it.

Hello Alexander! In your strategy paper you have taken several points of importance that were already laid out in the ILIAS-Vision and have formulated corresponding objectives. These objectives are, naturally, still  quite broad in their scope. How do you go about making them more defined for the everyday development of ILIAS?

For each objective we keep track of specific measures internally. Some of these measures come into being on an ad hoc basis – as a reaction to current demands. We do however strive to have a systematic approach. As the ILIAS-Vision provides the foundation for our strategy, the strategy is, in turn, the foundation for the measures. They should be derived and prioritised from the strategy. It is our goal to cover all important aspects of the software development with appropriate measures.

Subsequently, we then need to check if the measures are actually working or not. For the future we would like to use performance indicators. These are however not always easy to come up with and the actual value of what they tell us is a matter of dispute.

Do you have examples of this type of problem?

Institutional members of the ILIAS Society have been able to prioritise bugs for a while now in order to get them fixed more quickly if they are problematic for their particular scenario. Since this has been the case, we have maintained an overview of the number of open, prioritised bugs per developer in the minutes of the Jour-Fixe Meetings. At first glance this is a useful performance indicator.

However, this overview doesn't take into consideration the complexity of the corresponding module. You could for example, in addition, see the extent of the code. This is of course much larger in Test&Assessment than in Bookmark-Management. In fairness, you should also take into account the number of reported bugs in relation to the functionality of the particular module. Also, the threat that a bug poses should also be taken into consideration: how dramatic are the errors in the respective components? The consequences of errors in RBAC or Test&Assessment tend to be more problematic than of errors in the comment function.

We will look for performance indicators that will allow us to make statements about the quality of code and processes in order to better monitor measures being taken.

The first chapter of your strategy paper deals with the community-driven development of ILIAS. The overhaul of the maintainer concept is an important theme. What is the goal of this change?

It is our goal to have more people involved in the development of ILIAS. This initially includes programmers, but also many others roles such as testers, authors of Feature-Wiki articles or bug reporters.

At the code level there are people who don't want to be maintainers but nevertheless have something to contribute to the development. For the first time we have defined the role of these 'code contributors'.

What is the function of this role?

The most important thing at first for us was to create a regulated procedure for contributions to the programme code from non-maintainers. These code changes reach us as 'Pull Requests' directly in our repository on GitHub and are also managed there. They are categorised (for example as bug fixes or improvement suggestions) and can be viewed, discussed, adjusted and, with the permission of the maintainer, adopted into ILIAS's main code.

New features still have to go the normal route via the Jour-Fixe. The exact rules for this can be found in our repository on GitHub.

Will anything about the existing role of maintainers change? And what about the role of the Jour-Fixe?

The classic maintainer will continue to exist. The role has in fact acquired new responsibilities with the new contributing process. Now, maintainers should deal with pull requests from outsiders in a similar way to bug reports: the contributor should get feedback within 21 days.

As with bugs, it is also possible to add pull requests to the agenda of the Jour-Fixe meeting. The Jour-Fixe also offers a place to discuss questions and problems – and, if needed, to sort out conflicts. This option is open not only to maintainers but also to outside contributors.

Back to the maintainer model...

At the moment we are working on clarifying the responsibilities of the classic maintainers for different parts of the code. These should be even better documented directly in the code repository.

Additionally, we are also endeavouring to develop an additional maintainer model. The classic model works very well for application-oriented modules like, for example, the Forum, the Learning Module or the Test&Assessment. In these areas, it is necessary to have special knowledge of the concepts and application scenarios.

There are however also parts of the programme code that are the technical foundations of many further components. Especially when these parts are very complex, a more strongly collaborative approach becomes interesting. The Kitchen Sink is a good example of this: the code for our user interface is used by all maintainers and therefore has numerous dependencies. In this case it makes sense to make contributions from a larger number of developers possible.

What problems would arise from such a collaborative model?

Well, firstly we have to make sure that the code maintenance functions. For example in the case of a bug report, such collaborative responsibility can ideally lead to developers who didn't write the code in question getting more strongly involved. However, a large group can also result in everyone thinking 'somebody else will take care of it'. This obviously has to be prevented.

Additionally there is an increase in the amount of effort that needs to be put into communication – especially if you want to follow a clear and consistent strategy with a component. This means a greater need for good rules and documentation.

The topic of a collaborative maintainership will no doubt occupy us for a while yet. Our overall goal is to simplify and improve the joint work on shared functions.

The next large topic in the strategy paper is the reliability of ILIAS. One goal is to make further improvements to quality with the help of unit tests. Can you please explain to us what unit tests actually are?

In the community, the best known tests are the TestRail test cases, which are run through by a large number of volunteers each autumn. In contrast, unit tests can be carried out automatically. Each developer can let them run and use them to check if the elements in the code covered by the test cases still work after the changes that have been made. The unit tests, however, as opposed to the manual tests in test cases, only test individual code elements at a granular level, for example individual code classes.

Being able to test automatically allows the developers to carry out larger revisions of the code far more safely. This was, for example, significant when implementing PHP7 support: revised code was able to be quickly checked using unit tests. This way it is possible to avoid changes in one area causing problems in a different area of the code.

What are you plans in this area?

The goal of the Technical Board is to make the implementation of unit tests easier and to set up rules regarding in which areas they have to be created. This is of course important when it comes to cross-cutting components, which affect the work of many developers and are especially important when it comes to the running of ILIAS.

We recently held a virtual meeting with the developers in order to develop 'best practices' and identify typical problems that arise when creating unit tests. Further meetings will no doubt follow.

Two central chapters of your strategy deal with the usability of ILIAS for diverse institutions and user groups. What can you tell us about the chapter 'Usable for Everyone'?

This section makes it clear that ILIAS is aimed at a whole range of different target groups whose technical expertise varies considerably. It is our aim that all users of ILIAS are able to do exactly that – use ILIAS, without difficulty. This should be possible even if they are not particularly tech savvy. Obviously accessibility also plays an important role here.

And what then is covered in the chapter 'Beyond Standard'?

In this chapter we take a closer look at the technical side of things and the adaptability of the system to different contexts. It should be possible to embed ILIAS in existing IT infrastructures, for example via interfaces to other systems such as higher education administration software. Expanding the software using plugins should also be ensured in a simple and effective way.

This chapter is of especial interest for our service providers. The customers' requirements should become easier to fulfil thanks to the software architecture of ILIAS. Plugins, patches and the most diverse configuration possibilities should make it easier to tailor ILIAS to your own needs, above and beyond the standard version.

Are you not walking away from the traditional "integrated" concept of ILIAS? From the very beginning it was an important goal of ILIAS to offer a complete learning platform within the core software. Will plugins start to play a more important role than the core in the future?

You are correct that the standard ILIAS was characterised over many years by a steadily growing number of functions. The plugin concept was a relatively late addition. The Technical Board does not, however, intend to get rid of the existing built-in functionality of ILIAS. We are much more concerned with efficiently supporting an even greater number of application scenarios - without each new feature having to be firmly integrated into the core.

Using plugins has a further advantage: they allow you to adopt new trends or standards and to gain experience before these become part of the core software. An example for this is LTI support. This was first made possible as a plugin thanks to Fred Neumann and, as more and more ILIAS users were asking for it to be integrated into ILIAS, will now become part of the core ILIAS software.

On the other hand, we have also become more rigorous when it comes to removing features from the core that are no longer needed. An example for this would be the Payment module. We keep a close eye on making sure that, despite the many new integrated features, the system doesn't become unmanageable.

Another hot topic in the ILIAS community at the moment is using the software on mobile devices and the desire to have an app. ILIAS users such as the University of Hohenheim and the University of Freiburg have already successfully made apps for some features. You cover this topic under the heading 'Learning Everywhere Anytime' in your strategy paper. What is your take on the current initiatives?

Responsiveness is something that has been a key aspect of ILIAS development for a long time now. This means that ILIAS can be used on both large and small screens. The Kitchen Sink project and the reworking of the user interface both also pursue this goal. ILIAS 5.3 will see further improvements in this area.

These efforts don't go far enough for many ILIAS users however. This has led to the University of Freiburg initiating the development of a proper ILIAS app which was already presented at the DevConf.

This development is mainly an initiative of the SIG Mobile at the moment – this means that it is taking place independently of the processes of the ILIAS core (for example decisions made in the Jour Fixe meetings, use of the Feature-Wiki or the ILIAS bug tracker). The Technical Board wants to try to take those original requirements more into account – also when it comes to developing the core ILIAS. We are in contact with the SIG and will strive for an open and integrated strategy.

The effort required for a complete ILIAS app would surely be considerable. There are, however, those that believe that most of the functionality could also be depicted in a smartphone browser. What problems and possibilities do you see in this?

In the past, native apps had key characteristics such as push notifications, location-based services and the ability to be used offline – characteristics that were not available for browser-based web apps. These characteristics, however, are an important part of mobile-based usage.

This picture is changing continuously however. Increasingly, modern browsers support these functions, meaning they can be accessed via Javascript, which in turn makes an integration into the ILIAS core easier. It is therefore possible, also using a browser, to share your location with software such as ILIAS in order to, for example, realise ideas like the location-based app implemented at University of Hohenheim (called 'Lernorte').

A particular challenge is using ILIAS without a connection to the internet. Modern approaches using 'Service Workers' are still inconsistently supported by current browsers. A group led by Stefan Schneider is currently looking into exactly this whilst developing a new SCORM Offline-Player for ILIAS 5.3.

It is interesting to note that the SCORM Offline-Player did not originally address modern devices such as smartphones or tablets, but was rather intended to be used on a classic laptop without internet connection. These requirements are not at all fulfilled by a native app. That makes the idea of a progressive web app very attractive. The best case would be when the mobile requirements of the users could be realised by using one code base on all platforms that support a browser. A uniform code base would, additionally, automatically mean that existing development processes and resources would be used.

I hope that the approach used for the SCORM Offline-Player can be applied to other ILIAS components such as ILIAS Learning Modules, Glossaries, Files and Mediacasts.

There is no question about it – our mobile strategy will keep us occupied for some time to come. We will certainly need to discuss further in the community how the existing challenges can be best overcome. The Technical Board will, of course, take an active part in the discussion.

Well, we are looking forward to finding out how it goes. Alexander, thank you for your time!