Feature Wiki

Information about planned and released features

Tabs

Abandon Special Character Selector

1 Reasons to Abandon Feature

There are multiple open issues around there char selector, which make it very hard to use. Examples:

  • https://mantis.ilias.de/view.php?id=31400
  • https://mantis.ilias.de/view.php?id=30791
  • https://mantis.ilias.de/view.php?id=27634
The component resides in UIComponent Service of ILIAS (legacy UI Components). The Page Layout Revision Project is currently to migrate components residing in there to be replace by the new UI Components from src or to migrate components towards new src UI Components. The folder is currently implicetey maintained by Killing, Alexander [alex]. However the feature has been implemented by Neumann, Fred [fneumann] who does only feel partly to be responsible for this Component, see 27634, "I maintained it in the past, mainly by fixing bug related to changes in the GUI of new ILIAS versions. Since it was introduced with the migration of the T&A branch there were no further requests for it". He also notes that "The whole component would benefit from a larger rework". 

We discussed this Issue in the Bugfixing Task Force and agree to propose to abandon it, if nobody like to take responsibility for the code. Since there seems to be nobody in sight, Amstutz, Timon [amstutz] proposes to abandon the feature completely. 

2 Technical Information

The Char Selector is currently used in the following Services and Modules:

  • Test -> ilObjTestSettingsGeneralGUI and ilTestPlayerAbstractGUI
  • Form -> PropertyFormGUI, getContent (Button is added to Title Section)
  • User Settings -> ilPersonalSettingsGUI, initGeneralSettingsForm (Char Selector is a Setting for Users)
  • Administration (for Config)
As far as Amstutz, Timon [amstutz] can see, the tool is mostly used in the test. Since the maintainance seems somewhat unclear, the TA Maintainer Strassner, Denis [dstrassner] has been entered as maintainer for this component.

3 Contact

4 Funding

Removing the feature from the ILIAS code base might need funding. If you are interest in funding this request, please add your name and institution to this list.

  • Uni Bern

5 Discussion

Use the following discussion section to express your objections against this request or your consent to get rid of this feature.

Hilbert, Mirco [mirco.hilbert], 02.12.2021: The Char Selector is very important for us in e-exams and self-assessment tests. We use it for example in Phonetic and Phonology exams where the participants have to enter a phonetic transcription of an English text inserting the phonetic IPA symbols via the Char Selector. Besides small Cloze Questions this is a main task in these kind of exams.
Other applications are inserting characters from the cyrillic alphabet in the Slavistics or fill out Cloze Questions in Math inserting simple mathematical formular symbols.

Amstutz, Timon [amstutz], 02.12.2021: Thx @Hilbert, Mirco [mirco.hilbert] for the feedback. We like the feature too. Unfortunately it is not really usable in the current state, and there is no maintainer who is willing to take responsibility for the code behind it. If we find somebody willing to take over, we would be more than happy. Note that our resources to invest here are very limited, since we already did invest quite a lot into trying to fix the issues around it.

Roeser, Nico [nicoroeser], 2021-12-02: uh-oh. The character selector is an important feature in our (=Uni Regensburg) e-assessments, mostly in language tests (e.g. Spanish). In addition to that, teachers have asked us whether we could add convenience blocks for easily inserting characters from the IPA (see Mantis #27634 comment 76690). We expect even an increase in use of this feature when we add tests in Asian languages. We have also been asked about this by people who like students to enter a formula, like in Chemistry tests.

I agree that having old and broken code in ILIAS is not a nice thing. If a rewrite could solve the issue, we’d be happy. I do not insist on keeping the current specific implementation of a character selector, but would very much like to have any well-working method of entering characters outside of the US-ASCII range (esp. not on a German keyboard) that is implemented in ILIAS.

While I normally do not use such features myself, and prefer local input methods provided by my operating system, which I’m used to, “ordinary users” do not know how to do that.

  1. This causes a massive requirement for support (and our support people have to know about every crazy web user agent, operating system, software and hardware platform out there – impossible…), and
  2. some ugly devices (like some tablet computers) may not even have dedicated input methods for entering characters outside a certain range.
When we discussed these things some weeks ago, we decided that we’d rather have an end-user-ish, semi-ugly feature than to have that other support hell.

If we can help with money to still have a (rewritten) character selector in ILIAS 8 and later, we’d be happy to hear about an estimation, which I’ll bring to the attention of the right people here. Normally, I’d prefer to offer to help with time and code in this area, but unfortunately this doesn’t look realistic in the nearer future in our current situation and workload.

Amstutz, Timon [amstutz], 2021-12-03: @Roeser, Nico [nicoroeser] thanks for the feedback and your willingness to contirute in some way or the other here. Highyl appreciated. A alternate version of it, might be the way to go. Max Becker e.g. suggested to integrate it with the tiny. Not sure if this is the best way to go, but could be discussed in a FR for 9 (not that this FR proposes to abandon the feature for 9). A rewrite or refactoring of the existing component could also be possible. In this case it would be enough, to have somebody willing to take responsibility here, fix existing and future bugs (possibly against funding). So @Roeser, Nico [nicoroeser], you (and anybody else interested) have multiple options:

  1. Take responsibility yourself. I have seen that you are a capable dev., this is not the easiest component to start with, due to the reasons listed above, but somebody not bringing along some experience and advanced coding skills could pull it off. I know that time is an issue, same everywhere ;-). I looked into it myself, so I do understand if this is not an option.
  2. Find somebody taking the responsibility here (probably against funding).
  3. Create or let somebody create a concept to migrate the essence of the feature to some new workflow (e.g. integrate into tiny), get it off the ground and find somebody to implement it. This could even be better than option 1. Big issue here would be again to find somebody having time to integrate it.
If you need more time to think about one of the option let me know, we do not need to rush this. ILIAS 9 is not tomorrow ;-). Finding an alternative is also in my best interest. Hope this helps.

Hilbert, Mirco [mirco.hilbert], 03.12.2021: I would like to appeal that we first abandon the old feature when we have a new implementation of the feature, so that we do not run into a lack where we do not have a Char Selector at all in ILIAS 9. We should rather keep the old implementation one version longer until there is a replacement. For us, the Char Selector works as it currently is, despite the bugs mentioned. And it would be far worse for us if it were no longer available.
I don't want to get in the same situation as Volker with the Continous Testing Mode. It was abandoned in the promise that there will be an immediate replacement, which due to the known circumstances has not yet come.

Integrating it in the TinyMC is not a full solution for us, as we also use the Char Selector in Cloze Questions. And the feature that we can define our own set of characters in the test settings is still also important in our scenarios. I do not get, if this will still be possible using the TinyMC?

Amstutz, Timon [amstutz], 2021-12-03: Hi Hilbert, Mirco [mirco.hilbert]. Thx for the feedback. 

Note that TinyMC was just a random example of an alternate solution. Main point is, there could be alternatives, but they should not be discussed here. Creating a concept for this will take a substantial amount of time, and should be discussed if this work for such an alternative is done.

Back to the main discussion here: An Appeal will not help the fact, that we need people that take responsibility for code in the core. If nobody takes responsibility, we run in to large issues if things need to be changed, projects like php8 need to be tackled or security concerns arise etc..

You can help here by looking for funding and find somebody willing to care for this part of the code. Note that each line of code comes with cost for each update, even each minor update. We already did invest a lot into this specific part. We also invest year by year large amounts in just refactoring code and keeping it up to date. We can not afford that for the complete code base. The looking for funding for php8 was very tedious up to this point. A clear sign that we have more code that we can manage.

However funding is only one side of the coin. The other side looks even worse; resources of developers. As pointed out to @nicoroeser above, its hard to find people that have the time. So contributions in form of time a long with a long time commitment is even better than funding.

So I am unsure what we can do with your appeal, if it is not backed by some form of major contribution either by your institution taking responsibility for the code or at least by your funding of a developer/maintainer willing to take some responsibilities.

Tödt, Alexandra [atoedt] 2021-12-13: If precedent is worth anything, then we wait for another year after someone appealed against the abanonning - even though is highly inconvenient for the core.
The time then can be used by the appealing party to take measures.
In those precedents this meant typically that not-maintained code / badly-mainatined code was kept a part of the release for another year.
There is only one exception to the precedents I know of and that was due to severe threat to data base integrety by the code in question. 

Amstutz, Timon [amstutz] 2021-12-13: If somebody is willing to step forward here, I am more than happy. We are one of the insitutions actively using (and up to know also funding) this. However, currently, there is nobody taking responsibility for the code. This would not be abandoned for ILIAS 8, but 9. @Amstutz, Timon [amstutz]: As we currently quite impressively see by security threads in the web in general, it is really important not to let unmaintained code just linger and rot in our codebase but either a) actively care for it or b) get rid of it. I know, that we left room for it in the past, we should seriously reconsider our stance concerning this.

Strassner, Denis [dstrassner] 2021-12-13: I support the dropping of the 'Special Character Selector' with ILIAS 9 in the T&A. If another maintainer gets the function through a re-implementation, I would be happy.

Neumann, Fred [fneumann] 2021-12-13: Proposals for a re-implementation:

  • Abandon the cascading configuration (global/user/test) and offer the feature for the test only
  • User the tools in the slate to present the selector
  • Use manually maintained pages with characters for specific purposes instead on the raw unicode blocks
  • Copy selected characters to the clipboard instead of trying to insert them at the current editing position

JourFixe, ILIAS [jourfixe], 13 DEC 2021 : We abandon the current implementation of the Special Character Selector with ILIAS 9. Amstutz, Timon [amstutz] will take responsibility for getting the code out of ILIAS. We ask all stakeholder that need such a feature to push a re-implementation of this feature and to participate at the conceptual work and the creation of a related feature request for ILIAS 9. Otherwise, no special char selector will be available in ILIAS 9.

Bei uns (JGU Mainz) werden seit Jahren sehr viele E-Klausuren mit Hilfe dieses Features geschrieben. Gerade Klausuren in Mittelhochdeutsch, sowie Lettisch, Schwedisch, Finnisch, Spanisch und alle Phonetik-Klausuren mehrerer Sprachen sind seit Jahren darauf angewiesen bei ihren E-Klausuren. Wir möchten gern innerhalb des Feature Freezes eine Neuimplementierung auf Basis der KitchenSink vorschlagen. Vielleicht kann man sich mit denen, für die das Feature ebenfalls sehr wichtig ist, zusammenschließen bei Fragen der Finanzierung und der Suche nach eine:m Maintainer:in.

6 Implementation

Implemetation is provided by pull request https://github.com/ILIAS-eLearning/ILIAS/pull/6093

Assigned the Mainters of the components Modules/Test, Services/AvandecEditing, Services/Form, Services/UIComponent and Services/User as reviewers.

Removed Testcases

The following testcases have been removed from Testrail or modified because the feature is no longer part of the ILIAS core.

  •  C239 : Auswahlmenü mit Sonderzeichen (Unicode)

The following test cases are temporarily added to Testrail for ILIAS 9:

  • C58212:  Editor-Einstellungen  
  • C58213:  Persönliche Einstellungen  
  • C58214:  Testeinstellungen  
  • C58215:   Omega-Button im Frageneditor  
  • C58216:   Omega-Button in den Testeinstellungen  
  • C58217:   Export und Import von Tests  
  • C58218:  Testdurchführung  
  • C58219:  Setup  
  • C58220:  Sprachvariablen  

Approval

Approved at 20.07.2023 by Amstutz, Timon [amstutz].

Last edited: 20. Jul 2023, 10:22, Amstutz, Timon [amstutz]