HTML Export Extensions

1 Requirements

A) HTML-Download with "edit content" permission
At the end of a learning sequence it's often important, that the whole Wiki is a collection which is always accessible. In the current version of the ILIAS-Wiki it's possible to create a HTML-export. But only the person who has the "edit settings" permission can export the wiki. Students normally have "edit content" permission, so the person with "edit settings" permission (a tutor or a lecturer) has to do this work.
 
It should be possible, that users with the "edit content" permission can create an Export in HTML or XML.
 
B) Userfriendly HTML-Download of zip-files
The download should be without a storage on an export page. Userfriendly would be a process analog to the download function in the portfolio.
 
C) HTML-Export: Playable videos in browser
In the actual version of the wiki HTML-export videos are unplayable in some browser (eg. Chrome 33 or Safari 6 on Mac OS X).
It should be possible, that videos and audios are playable in all browsers with a videoplayer.
 
 
proposal:
The export function should appear in the block "Wiki Functions"
 
step 1)
It is possible to activate the HTML-export directly in the block "Wiki Functions" and not on the setting page.

step 2)
The download should directly start by clicking the function "Export as a HTML-file"
 
requirements for the download:
2.1) The name of the zip-file should be the wiki-title. (e.g. “Experimentieren - Mensch und Umwelt”)

2.2) After unzipping the file the new folder should have the name of the zip-file. (e.g. “Experimentieren - Mensch und Umwelt”)

Note:
The last two steps 2.1/2.2 would also be desirable for the export of a learning module, blog, portfolio, forum, test and survey, etc.
 

2 Additional Information

• Idea / concept: Sarah Schilling, Werner Willi, werner.willi@phzh.ch
• Funding: PH Zürich
• Maintainer: Alex Killing
  
• Implementation of the feature is done by Leifos
• Contract settled: Yes
• Tested by / status: (name, e-mail), (status information set after implementation)

3 Discussion

Alex Killing 13 Apr 2014:
 
A) and B): An HTML export always involves copying a lot of data on the server side. If we do not have any intermediate storage mechanism, this could lead to severe server load issues in wikis with a lot of data (e.g. videos) and a lot of users, since all users would invoke the export process and would copy around the same files. A similar scenario is the folder download feature in the ILIAS repository which gives us headaches due to the same reasons. Also using titles as names results in character set issues, since this is not supported in general by zip cross-platform. Related bugs: 12620, 4076
 
Do you think an scenario like the HTML export of learning modules would be helpful for you? It would required a user having "editing settings" permission to create an export file and make this available to the learners.
 
 
C) Has more a bug character. We support everything that is possible with the current media player (mediaelement.js). There are always restrictions related to video formats on different platforms.

Werner Willi, Sarah Schilling, 23 May 2014:
 
A) and B): We would like to give the opportunity to any wiki user to create an HTML-export of the wiki at any state or time, like it is possible in the portfolio or blog in the personal workspace.
 
In our point of view, implementing the learning module’s scenario is not reasonable here, as the students would be dependent on the user having “editing settings” permission. This person would have to regularly provide an up-to-date wiki export file.
In learning modules it’s ok if this person has to provide the export file for learners, as he/she is the author of the content and knows exactly, when it is necessary to provide a new export file as the content has changed.
But in a wiki students are contributors / authors themselves. The content may change quickly and currently without being realized by the teacher at once. The students want to save / export their products (and the content of their colleagues) at any time or state. The reason for this is either storage of their own products / contents, adding their texts to their own portfolio etc. Printing or creating a (linear) PDF file of the content isn’t enough and not reasonable for a wiki format at all.
 
Server load issue:
In contrast to downloading / exporting a folder we don’t think all wiki users export a wiki at the same time. We know this happens with folders and may cause severe server problems, especially at the beginning of the semester when all students download the files for a new lecture at the same time. This scenario isn't likely to happen with wikis in our point of view.
 
Nevertheless we have a suggestion for this server load issues:
If a user starts the “export as HTML-file” function, the server checks in the background, whether there exists an up-to-date export file from a previous export in an invisible storage.
a) If so, this stored (already existing) file is directly provided for download (download dialogue appears according to browser settings).
b) If there is no export file in storage or the file is outdated (there were content changes since the last export), a new export file is created in the background. In the front, a dialogue indicates that the export file is being created (possibly with progress bar or some kind of animation indicating a background action to avoid that the export function is started several times). As soon as the export file is packed, the download dialogue appears in the front.
This new export file is stored in the background in case someone else uses the export function of the same wiki version.
 
To keep it simple, we clearly think that the export storage ribbon shouldn’t be visible for contributors (users with edit content permission). All actions should happen in the background, the function should be provided as mentioned above (step 1).

Alex Killing, 12 June 2014: @Sarah/@Werner, this would increase the effort of implementation, but it should all be possible from the technical side. However I would give the control to a user having "edit settings" permission, if the HTML export should be available or not, see the discussion at Extending User Activities for Page Editing, Protecting and Deleting. A tutor/admin must be able to disable the export feature in some cases (e.g. lots of videos included).

Werner Willi, Sarah Schilling, 20 March 2015:
Unfortunately, we answered this post only in the discussion at Extending User Activities for Page Editing, Protecting and Deleting, as there is a reference to that discussion in Alex's post. So here is our answer as already given on 20 June 2014 in the discussion mentioned above:
 
We support the suggestion of adding a fourth permission for the HTML export as mentioned by Alex. It is reasonable to treat this different options / additional permissions the same way.
In the discussion at Extending User Activities for Page Editing, Protecting and Deleting you opt for adding these four additional permissions not on the settings tab but on the permissions tab (either on the original one or on a new tab called "permissions" only containing those four permissions). Although we understand your points, we would still prefer to have those four additional permissions listed on the settings tab, like the newly added section "Activate Additional Wiki Page Properties" with "Feature Status", "Eigenschaften Blatt / Blüte" a.s.o. They could be separated by a title like these additional properties (see our points at Extending User Activities for Page Editing, Protecting and Deleting).

Killing, Alexander [alex], 6 July 2015: I support this request.

JourFixe, ILIAS [jourfixe], 13 July 2015: We support the feature and the idea to introduce a separate permission for it and schedule it for 5.1.

4 Implementation

Killing, Alexander [alex], 11 Aug 2015: Will be available in edge installation with the next release.

"HTML Export" is now available in block "Wiki Functions". Multiple simultaneous html export processes by different users are prevented. New export files are only created if pages have been changed. Progress bar shows creation status.

Test Cases

Test cases completed at2015-08-17 by Alexandra Tödt 

• http://testrail.ilias.de/index.php?/cases/view/6198: C6198 Beschränkte Vergabe von Rechten konfigurieren

Approval

Tested successfully and approved at 2015-08-26 by Werner Willi.