Show Advanced KnowledgeHide Advanced Knowledge

Form in ILIAS

1 Initial Problem

There are several usecases where ILIAS could help, when someone needs a form:

1. Contact form
2. Collect data, eg.
   1. Collect abstracts and presentations
   2. Collect data and motivation letter (e.g. for summer school)
3. Feedback form
4. Application form - e.g. <http://www.philhum.unibe.ch/unibe/portal/fak_humanwis/content/e66/e629175/e665499/TPF_antrag_4_ger.pdf>
5. ...

Actually, different ILIAS-objects already fulfill most of the functionalities a form-object should have, but there are still some missing functions to get a form like well-known online-forms:

• Google Forms - http://forms.google.com
• Sharepoint Lists
• Jotforms - http://www.jotform.com

Surveys and datacollection are our favourites objects for this because:

• Both objects have advantages (and disadvantages)
• Both object collect data

We suggest to improve one of those objects with form functionalities.

For the decision-process, we created a matrix.

2 Conceptual Summary

2.1 Comparison Survey vs. Datacollection

ID	Functionality	Survey + already there, - needs improvement	Datacollection + already there, - needs improvement	Exercise + already there, - needs improvement	Importance	Funding maybe possible
1	File-upload field	-	+	+	must	University of Bern
2	Download all files of the file-upload field as a zip-File	-	-	+	must	University of Bern
3	Date field	-	+	-	nice-to-have
4	Regex for Textfield	-	+	-	nice-to-have
5	Results (Tables and charts)	+	-	-	maybe
6	Design forms	+	-	-	nice-to-have
7	Anonymous / without names	+	-	-	must	University of Bern
8	Concluding remarks	+	-	-	must	University of Bern
9	Participants can request participation confirmation	+	-	-	nice-to-have
10	Mailing and Invitation	+	-	+	maybe
11	Routing	+	-	-	nice-to-have
12	Number of characters in text-fields	-	+	-	nice-to-have
13	In courses/groups, one form should allow multiple runs	-	+	-	must	University of Bern
14	Allows to give general read-access rights: "see the different forms other users filled out"	-	+	-	must	University of Bern
15	Admins and owners can give "grant access"-rights for other users (of a superordinate course/group): Read and/or Write	-	-	-	must	University of Bern

When we decide to improve the survey or the datacollection-tool, then we should clarify: Do theses improvements are helpful for a survey or a datacollection in general?

Survey:

• File-Upload question (HJL: interesting)
• Download all files as a zip file (HJL: a must when download files is implemented)
• Date-field question (HJL: I don`t see a usecase)
• Regex for textfield (HJL: interesting)
• Design forms (HJL: Nein, no, just mor complexity)
• Number of characters in text-fields  (HJL: No, I don`t see a usecase)
• Should allow multiple runs (HJL: Very interesting)
• General access rights: See the different surveys other users have filled out (General read-access) (HJL: No, just more complexity)
• Give "grant-access" rights (Read and/or Write) (HJL: No, just more complexity)

Datacollection

• Download all files as a zip file (HJL: interesting)
• Results (Tables and charts) (HJL: interesting)
• Design forms (HJL: interesting)
• Anonymous / without names (HJL: interesting)
• Concluding remarks (HJL: interesting)
• Participants can request participation confirmation (HJL: interesting)
• Mailing and Invitation (HJL: interesting)
• Routing (HJL: No)
• Give "grant-access" rights (Read and/or Write) (HJL: Interesting)

2.2 Features

3 User Interface Modifications

3.1 List of Affected Views

Survey

• Questions > Create Question (File Upload and Date Question Type)
• Results > Details/Overview/Per Participant (File Download)
• Essay-Question > Edit (Regex)

Datacollection

• Content > Manage (File Download)
• Content (Results)
• Tables > Fields or Views (Design forms)
• Tables > Settings (Anonymous Permission)
• Tables > Settings (Concluding remarks)
• Content > Add Entry > Send (Participation Confirmation)
• Tables > Settings (Mailing)
• Tables > Routing

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, please provide a link to separate feature wiki entries for each of them according to the kitchen sink template.}

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

• Author of the Request: Lauener, Hansjörg [lauener]
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• Universität Bern

7 Discussion

AT 2017-03-30: Please consult the idea for a form-ish page element we proposed for the page editor in portfolios: Prompting Element in Portfolio

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.