Statistics with graphics and export for entire wiki and single wikipages

1 Requirements

The ILIAS wiki is a great didactic tool. But if instructors use a wiki which in fact flourishes in terms of many authors and many pages, it is worthwhile to get access to some statistical data about the usage of the wiki. This data can be used both to do pedagogical reasearch on how students work and learn and to improve the didactic integration of wiki in a course. If you will, this might be seen as another step towards integrating useful learning analytics into ILIAS.
 
All statistical data should be collected anonymously. It should be accessible for a freely defined period of time, similar to the ILIAS usage statistics in the Administration view. It should be presented in a nice graphical way (with pdf export) and should be exportable as csv or xls(x) for further "offline" usage.

Types of data that should be collected and presented:

Since no more features can be integrated into ILIAS 4.4 we would need this feature as a plugin first and would like to see this implemented into the core for 4.5, if the jour fixe agreed.

2 Status

• Scheduled for: Release 5.0
• Funding: Funded by Universität Freiburg
• Maintainer: Alexander Killing, LEIFOS
• Implementation of the feature is done by Alexander Killing, LEIFOS
• Contract settled: Yes
• Tested by / status: (name, e-mail), (status information set after implementation)

3 Additional Information

Contact the following persons if you want to know more about this feature, its implementation or funding:

• Information about concept: Marko Glaubitz (marko.glaubitz@rz.uni-freiburg.de), Barbara Müller (barbara.mueller@rz.uni-freiburg.de)
  
• Information about funding: Marko Glaubitz (marko.glaubitz@rz.uni-freiburg.de), Barbara Müller (barbara.mueller@rz.uni-freiburg.de)
• Information about implementation: Marko Glaubitz (marko.glaubitz@rz.uni-freiburg.de), Barbara Müller (barbara.mueller@rz.uni-freiburg.de)

4 Discussion

Alex Killing, 23.10.2013

• We cannot strictly anonymously collect the data (on the db level). We already store which user made what change and if we need to collect "averages per user" we need to store additional numbers per user. However the export and presentation can be done anonymously.
• What would the "average number of pages per user" be if not the "average of modified or new pages per user"?
• Number of internal links, external links, words, characters, footnotes: It is impossible to give "average numbers per user" for all of these, since it is impossible to track "user assignments" of these items. Example: In a given large text element, a user moves (using ctrl+c and ctrl+v) text passages around and adds other stuff in between. After saving, ILIAS will not be able to count which of these elements have been newly created by the user and which not. Totals and averages per page of these numbers would be possible.

Marko Glaubitz, 23.10.2013
Hi Alex, you're absolutely right. Some of the values we listed do not work out as averages. SInce everything had to happen very fast, we did not think every detail through to the end. So, your second and third point: strike the non-sensical values :)
Regarding the anonymity: an anonymous presentation is entirely fine for us. There is no need to collect the data anonymously as we had suggested should be done in the survey.
We have talked abou the interval of collecting the data. Every couple of hours would be fine, if this cuases problems a daily update might do as well.

Marko Glaubitz, 20.02.2014
The alpha schreenshot looks very good :)

JL, 12 Mar 2014: To make the permission handling more flexible we need a new wiki permission "read_statistics", which would give access to both page-statistics and wiki-statistics. As the latter one is currently tucked away in the wiki-"settings"-area, where "normal" users have no access at all, we should rename the "settings"-link to "statistics" in that case.
As there already is an rbac-operation "tst_statistics" we propose to rename this to a more generic name and re-use it for wikis. This could be done with only a few changes in the code. All rbac-operations should be checked for consistency (position) and proper naming.

Alex Killing, 13 Apr 2013: I fully support this request (duration of editing is not contracted).

Matthias Kunkel, 13 Apr 2014: I support this request, too. Based on the recommendations by the maintainer and the head of development I schedule the feature for 4.5.

5 Implementation

JL 11 Jul 2014: This feature has been implemented as a prototype for trunk/4.5. Some details still need to be discussed.