Feature Wiki
Tabs
Exercise: Auto-Save for Text Assignments
Page Overview
[Hide]- 1 Initial Problem
- 2 Conceptual Summary
- 3 User Interface Modifications
- 4 Additional Information
- 4.1 Involved Authorities
- 4.2 Technical Aspects
- 4.3 Privacy
- 4.4 Security
- 4.5 Contact
- 4.6 Funding
- 5 Discussion
- 6 Implementation
- 6.1 Description and Screenshots
- 6.2 Test Cases
- 6.3 Privacy
- 6.4 Approval
1 Initial Problem
If working on longer text in the text assignments, students may lose their input if they accidently navigate to another page.
2 Conceptual Summary
The text assignment input view should automatically save the user input each 30 seconds. A status message box thould show the last save action in minutes (e.g. saved 3 minutes ago). If the input is not changed, no auto-saving should be done.
3 User Interface Modifications
3.1 List of Affected Views
- Exercise: Text Assignment Input View
3.2 User Interface Details
The view will get a message box on top for showing the last save message.
3.3 New User Interface Concepts
No new UI concepts.
3.4 Accessibility Implications
The message box will not get any live-area for screenreaders since this would disctract the user too much.
4 Additional Information
4.1 Involved Authorities
- Authority to Sign off on Conceptual Changes: Killing, Alexander [alex]
- Authority to Sign off Code Changes: Killing, Alexander [alex]
If this request is related to multiple components, please list both authorities for all related components.
4.2 Technical Aspects
No technical issues.
4.3 Privacy
Killing, Alexander [alex]: We will not save any additional data. However data will be "saved sooner" by auto-save. I do not consider this being a privacy issue.
4.4 Security
No security issues.
4.5 Contact
Person to be contacted in case of questions about the feature or for funding offers: Killing, Alexander [alex]
4.6 Funding
Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.
If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.
5 Discussion
05 JAN 2026, Lowe, Simon [simon.lowe]: Thanks a lot for this feature request, which users of the Test already be familiar with and appreciate it. After looking at the FR a few questions came up to me:
- Will there be a setting in order or de-/activate the autosave function (globally or for every Exercise itself)?
- Will there be a setting for changing the intervall of the autosave?
- Is it possible to have a delta between the autosave text and the version of the text, which is finally handed in? Or is just always the newest version of the text handed in as submission and shown at the tab "Submissions and Grades"?
07 JAN 2026, Giercke-Ungermann, Annett [Annett_Giercke]:
Thank you very much for this feature request. From an accessibility perspective, it is understandable and appropriate that the message box does not use a permanently active live region for screenreaders, as repeated announcements during regular automatic save cycles could significantly disrupt the user experience. In this context, I would like to ask two questions regarding the planned implementation:
- Is it intended to provide a one-time screenreader announcement upon the first successful automatic save, informing users that changes will be saved automatically from that point onward? If not, are alternative solutions being considered to ensure that this information is reliably accessible to screenreader users?
- Are there any plans to trigger a screenreader announcement for relevant events, in particular when changes could not be saved?
Thank you in advance for your feedback and for discussing possible accessible solutions.
Killing, Alexander [alex], 12 Jan 2026. Here the answers to the questions above
- There is currently no setting planned to deactivated the auto-save function.
- There is currently no setting planned to change the intervall.
- There is no delate feature. Handed in is the last saved text regardless if this is auto saved or manually saved.
- It is not intended to provide special screenread (one-time or error announcements). As far as I know we do not have any KS elements providing this. I guess it would at least need an extension of the messageBox KS elements.
JourFixe, ILIAS [jourfixe], 12 JAN 2026: We highly appreciate the current suggestion and accept the feature for trunk. To prevent future accessibility problems, we need extending the KS Message Box to notify the screenreader that the actual input is stored every 30 sec. This notification should only made once at the beginning.
Fuhrer, Thibeau [tfuhrer], 13 JAN 2026: From a UI framework perspective, we should aim for a general auto-save feature on our input containers (forms), which does not try to implement the storing mechanism, but rather orchestrates the interactions between server and client. I think we already have some parts of this in place, i.e. the prompt and progress bar utilise a concept of "component states", which may be reused and/or extended for this.
We also try to avoid putting a design decision, like whether an `aria-live` HTML attribute should be rendered or not, on the public interface and thereby onto our consumers. This is why I discourage from an extension of the message box. We want to bind logic like this to more elaborate (parent) components and make i.e. the message box be rendered differently in this components context.
Besides that, I am not sure if the `aria-live` attribute would be sufficient on the message box. If e.g. the status and hereby `role` attribute change, screen-reader would probably not pick up on this.
I therefore suggest to pursue a general auto-save feature on forms. This is a more sustainable solution from which other components will benefit as well. If this is out of scope, you should introduce a wrapper local to the exercise using a legacy component. For client-side rendering we already offer an `AsyncRenderer` which can be used.
6 Implementation
Feature has been implemented by {Please add related profile link of this person}
6.1 Description and Screenshots
{ Description of the final implementation and screenshots if possible. }
6.2 Test Cases
Test cases completed at {date} by {user}
- {Test case number linked to Testrail} : {test case title}
6.3 Privacy
Information in privacy.md of component: updated at {date} by {user} | no change required
6.4 Approval
Approved at {date} by {user}.
Last edited: 13. Jan 2026, 11:30, Fuhrer, Thibeau [tfuhrer]