Show Advanced KnowledgeHide Advanced Knowledge

Add field with dropdown-menu - without a second table

1 Initial problem

The actual implementation for adding a single-choice is too complicated

• User creates a second table
• User adds a new field in the second table
• User adds values in the second table
• In the first table, the User adds a reference to the second table and field

2 Conceptual Summary

There are already first ideas and discussions (see Discussion).

And JF wrote on May, 23. 20016: "We highly appreciate this request and schedule it for 5.2. We would like to have solution B and have the creation and edit process for the dropdown entries in the form where I add the field (using the multiple input form element). A related table will be created automatically in the background (like currently done manually) so no need of the data structure is necessary.

This idea could help to improve to make it more userfriendly. But if you need a datacollection with different value-lists, then you still have to manage a additional tables for each value-list.

We now suggest that ILIAS datacollection gets a new  Datatype "Choice" (without a second table)

1. In the tab "Fields" of each table, there could be a new Datatype "Choice" with two options: "Text" and "Date"
2. The creation and edit process for the dropdown entries is in the form where I add the field.
3. It is possible to a) add new entries, b) delete existing entries,  c) edit existing entries and d) change manually the order of these entries.
4. ILIAS does not adds separate tables for these entries.
5. Each entry gets an internal ID. When a admin edit an existing entry, then ILIAS changes the corresponding datacollection entries.
6. Three additional options are available:
   1. "Single Selection"
   2. "Single Selection (Dropdown)" (=> in Surveys called "Combobox")
   3. "Multiple Selection"

3 User Interface Modifications

3.1 Datacollection » Table » "Add new field"

4 Additional Information

• Idea / concept: Lauener, Hansjörg [lauener]
• Interest in funding: Universität Bern
• Maintainer: (will be set by Jour Fixe / maintainer)
• Implementation of the feature is done by (will be set by Jour Fixe / maintainer)
• Testcases by: (please add your name if you want to create the testcases for this feature)

5 Discussion

Kunkel, Matthias [mkunkel], May 10, 2017: I fully support this suggestion. It is a sound improvement in usability. Only one question: what exactly is the difference between the two options for "Add entry to list". I know "[+] Add New Entry". But I do not really understand what these both options do...

, May 24 2017: We appreciate the feature in general but we think that the current proposal is too broad. In our opinion there exist two possibilites to provide a simplified way of creating dropdowns:

1) Extend current reference field to support the creation of selectable values

As already proposed, the current reference field gets extended so that a user can create dropdowns and its values more quickly. Instead of selecting an existing table/field pair, one could directly add options. In the background, ILIAS automatically creates a table AND field, where these values are stored. This solution can be seen as a "faster way" of creating a reference field. As managing the values in nested subforms can get complex, we would suggest to use a roundtrip modal instead. The workflow could look like this:

1. Create a reference field: The user can choose between an existing table/field or create options directly
2. Create options directly
   1. Table name: Name of the table which gets created
   2. Field name: Name of the field which gets created in the new table
   3. Field type: The existing field type for the field, e.g. Text, Integer, Date, Boolean
3. After saving, ILIAS creates the reference field and also the new table/field holding the references. A modal can be opened over a link to add new entries quickly in the referenced table. This workflow is also available for existing reference fields.

Advantages:

• We can support almost all existing types (Text, Integer, Date...) for the values, not only "Text" or "Date"
• After the referenced table/field is created, one can still configure more advanced settings under the field, e.g. for a text field: Length, Textarea, Regular Expression etc.
• The existing solution of adding new entries can be used

2) Introduce a new field "Choice"

This solution does not need an additional table and offers a quick way of creating multiple text options that are selectable over a dropdown (or multiple values). We think that introducing other types e.g. Date and permissions (Add new entries) at this level is too complicated, as this already exists on tables. This is where one should use referenced tables, which already allows to control this behaviour through permission settings.

Advantages:

• A very quick way of adding simple text values, if only a few are needed

------------------------

Regarding "Open Answers"

We are not sure how the "Open Answer" feature could be implemented, as we would need to store the selction AND an additional text information. If needed, one could implement this with two separate fields:

• Create a reference field holding the possible selections
• Create a tew field and use the description to indicate that the user should enter additional information based on the selection from the dropdown field.

-------------------------

If all the features proposed in this request would be part of the reference field, we would create sort of a new "data collection" inside a single field. That is why we suggest to extend the existing reference field with a new workflow, offering a quicker way of adding/editing referenced values --> Solution 1)


 

Kunkel, Matthias [mkunkel], June 02, 2017: Let's keep the feature request "stupid simple" and drop requirements 6 and 7. What we really need is an easy option to add choices/options as a dropdown without creating an additional table. That's what the data collection really needs as usability improvement.

AT 2017-06-19: Consider re-submitting 

• The deep nesting of settings does not comply with an accepted set of KS-Guidelines für Forms.  If you nest 3 settings deep the last option may only ask for a date or a number.  Please re-do the control to comply with the guidelines for forms.
• You must revise the labels:
  • "Choice" is loaded, it does not communicate its purpose.
  • Within three lines you use the label "Text" to mean two very different things. 
  • Please consult the rules für labeling buttons for saving forms: "Create Field" should read "Save" unless you can make a very convincing point for it. 
  • Please revise all other labels, too. I did not finish revising all of them. 
• Please consider to create a KS entry for the +- up down control. Not becuase you must, but because it would be lovely to have a central and stylable implemenation of this control whioch is used at several places.

Lauener, Hansjörg [lauener]. A note from Timon: The "KS entry for the +- up down-control" should be done together with forms KS-entries.

Amstutz, Timon [amstutz] 2017-07-28: I personally dislike this heavy nesting in forms. Is there no way to avoid such deep nesting (e.g. moving Choice Date and Choice Text up one level and live with the fact, that they are not in one sub form)?

Kunkel, Matthias [mkunkel], June 29, 2017: I still fully support this feature request and see it as a very valuable improvement in usability. But for me the following changes are necessary to accept this feature request:

1. Avoid "heavy nesting" by splitting the current top level into two datatypes:
   • One for "Text Selection"
   • another for "Date Selection"
2. Change the label of the existing option "Text" to "Text Entry" to clarify that a user needs to do an entry here.
3. Change the label of the new choice type from "Text" to "Text Selection" to clarify that a prefined text has to be selected here.
4. Place the new datatype "Text Selection" straight under the option "Text".
5. Change the label of the existing option "Date" to "Date Entry" to clarify that a user needs to add a date here.
6. Change the label of the new choice type from "Date" to "Date Selection" to clarify that a user has to select one or more predefined dates here.
7. Place the new datatype "Date Selection" straight under the option "Date".

Getting the + - △▽ control into the Kitchen Sink would be highly appreciated.

Amstutz, Timon [amstutz], June 30, 2017: I agree with all suggestions of Matthias. Thanks.

Getting the complete + - △▽ control into the KS would indeed be great. However I would wait for this untill we have the base input PR (for basic forms and controls in forms) which is still expected to come soon. What we do have are the Up, Down, Add, Remove Glyphs which should be used here. They look slighty different, more like buttons. See e.g.: KS-Entry: Add/Remove Glyph and KS-Entry: Up/Down Glyph.

JourFixe, ILIAS [jourfixe], July 03, 2017: We agree with Matthias' suggestions and schedule the feature for 5.3.

6 Implementation

Test Cases

Test cases completed at 22.8.2017 by Lauener, Hansjörg [lauener]

• C272: Update: Felder hinzufügen
• C274: Update: Felder bearbeiten
• C275: Update: Einträge hinzufügen
• C280: Update: Detailansicht (mit Seitenvorlage) anzeigen
• C275: Update: Einträge hinzufügen
• C18780: Auswahlmenü Felder
• C12762: Update: Standardfilter

Approval

Approved at 2017-08-25 by Lauener, Hansjörg [lauener].