- 1 Blueprint: Form Wizard
- 1.1 Goal
- 1.2 Target Versions/ Milestones
- 1.3 Terms
- 1.4 Concept and Implementation Details
- 1.4.1 Form wizard
- 126.96.36.199 WYSIWYG vs. Wireframing
- 188.8.131.52 Web components vs. jQuery
- 184.108.40.206 Form wizard vs. plain bodytext field
- 220.127.116.11 New ROW object
- 18.104.22.168 New and revised predefined form elements
- 22.214.171.124 Allow multiple recipient addresses
- 126.96.36.199 Minor UX problems
- 188.8.131.52 The future of predefined forms
- 184.108.40.206 Technical side notes
- 1.4.2 Extendability
- 1.4.1 Form wizard
- 1.5 Further ideas and wishes
- 1.6 Risks
- 1.7 Issues and reviews
- 1.8 Dependencies upon other Blueprints
Blueprint: Form Wizard
|Proposal||The future of the form wizard (EXT:form)|
|Owner/Starter||Björn Jacob,Ralf Zimmermann|
|Topic for Gerrit||formwizard|
This blueprint will present a concept on how to harden the USPs of EXT:form. The main focus will be on the improvement of the form wizard and the extendability. Furthermore, it will outline additional features for 8 LTS.
Right now there are 3 major extensions in the TYPO3 universe which allow building forms. The focus and target group of these extensions are different and therefore each single extension has its reason for being considered/ used.
- Target group: administrators, integrators, editors
- Focus: easy/ straight forward forms, no multi step forms
- Skill level: beginners to experts
- Advantages: TypoScript form objects, file based (optional), form wizard, postProcessors, core
- Disadvantages: lacking of trust in community, missing documentation, difficult to customize (pre 7.5), needs knowledge of TypoScript
- Target group: administrators
- Focus: complex forms, powerful finishers
- Skill level: intermediate to experts
- Advantages: file based, actively maintained, well documented, even most complex forms possible
- Disadvantages: for editors too complex to start with
- Target group: administrators, integrators
- Focus: mid-sized forms, maintained by powerusers
- Skill level: intermediate to experts
- Advantages: concentration on powerusers, most of the work done in the BE
- Disadvantages: not file based, update sometimes difficult, breaking changes in minor versions
Target Versions/ Milestones
Till July 2016, a group of 3 students of the EAH Jena is working on some of the mentioned tasks below. They will come up with a detailed concept and a click dummy.
- BE - Backend
- FE - Frontend
Concept and Implementation Details
Instead of solely porting the wizard to a different JS framework, a rewrite is prefered. This also allows us to streamline and optimize the UX and UI. It is not necessary to stick to the current UI. The following tasks will be tackled:
- Analyze solutions of other systems (CMS like Wordpress, Redaxo; generic form builder on the web; etc.).
- Create mocks/ click dummy.
- Create new design.
WYSIWYG vs. Wireframing
The current form wizard adds a form tag with valid form elements to the preview stage/ DOM. Additionally, this form is nested into the TCEform. This is problematic:
- It's not valid HTML.
- The form fields can be filled and the form submitted.
- HTML5 validations are executed.
- Hidden elements are not visible and thus cannot be selected.
The recent implementation contains workarounds to solve these problems.
In the future, the new form wizard does not create form elements. Instead, the wizard adds abstract elements to the preview stage. These visual elements have no functionality. They are easy to recognize regarding their element type. Further information can be displayed to visualize the field has filter or validation rules. That said, the new wizard acts like a sketching/ wireframing tool and cannot be understood as wysiwyg preview.
Web components vs. jQuery
Early during the conception phase, there was the idea to base the new form wizard on web components. The core does not use web components, yet. Furthermore, most of the developers do not have a deep knowledge of this technology. Therefore, we decided to stick with jQuery as JS framework (as the rest of the core does).
Form wizard vs. plain bodytext field
Since TYPO3 8.0 the form wizard is loaded inline. In earlier versions, the editor was able to either use the form wizard or the plain bodytext field. There were quite some issues with this approch:
- Integrators created "unsupported" form configurations. It was no problem to store those forms. But when using the form wizard later on, the custom/ unknown configuration was overridden.
- In fact, beginners/ editors do not have any experience in creating forms using TypoScript. This target group prefers working with an intuitive form wizard.
Based on that, the new form wizard cannot be turned off (locally). The user setting (introduced in TYPO3 8.0) to globally enable/ disable the form wizard will be kept. The new form wizard will also be loaded inline.
For deployment/ export integrators will have the possibility to copy the form configuration. The information is available via a readonly field. Another solution could be a button which copies the TypoScript code to the clipboard. Furthermore, the same is valid for the PageTS which is needed to regiser the form as predefined form.
New ROW object
A famous feature request is the possibility to have form fields organized in multiple columns. To achieve this, the ROW object is introduced. The object will have its own fluid template which allows easy adoption to the prefered CSS framework by the integrator.
New and revised predefined form elements
Currently, there are some predefined form elements available. The integrator will be able to register new predefined form elements easily. The existing elements will be revised.
Allow multiple recipient addresses
The mail postProcessor is able to send the mail to multiple addresses. This must also be possible when setting up forms with the form wizard.
Minor UX problems
The following minor UX problems will be addressed:
- When an editor adds a new field to the form, the name is missing.
- The new wizard generates the name automatically.
- The name attribute could be based on an autoincrement (as handled in the frontend) or a sanitized title (like powermail does it).
- There should be no mandatory values for form elements.
- The only exception are the postProcessors. Right now they are part of the form object (which is questionable). It is mandatory to add global mail data (sender, receiver). If the information is missing, the cursor focuses on the missing data. Furthermore, any email address (needed for sending) is not only mandatory, but also tested for validity (valid email address). This avoids exceptions of the Swift Mailer.
- All necessary data should be generated automatically.
- A static/ dummy label should be added as well.
- With the new wizard, the name attribute is not visible. If the integrator allows this attribute to be displayed, having an empty name should not be possible.
- There are several ways to solve this problem. One solution could be to set a name via PHP while saving the form. A different solution would be to set a name via JS before saving.
- The default set of available attributes in the wizard will be optimized.
- A beginner/ editor does not understand attributes like class, id or autocomplete.
- The integrator needs the possibility to customize the list of attributes in the wizard.
- It will be very easy to edit the attributes of a form element. This could be preferably done via in-place editing.
- The editor shoud be able to easily define the type of an input element in order to add email, search or date fields.
- As described in the issue https://forge.typo3.org/issues/69891 we need a straight forward process to set attribute values.
The future of predefined forms
When working with predefined forms, the postProcessors are defined within TypoScript. Therefore, the postProcessors cannot be changed in the BE by the editor. A possible solution could be:
- Change/ remove the current implementation of predefined forms as separate field.
- Move the field to the new form wizard. I.e., within the wizard the editor can choose to either work with the graphical interface or to load a predefined form.
- If the editor wants to display a predefined form, the wizard itself is hidden.
- Below the wizard and the predefined form drop down a section for the postProcessors is shown.
- If postProcessors are defined in the BE they will completely override the postProcessors defined in the TypoScript.
Right now, we don't want to integrate this feature in TYPO3 8 LTS. We want to concentrate on the form wizard and it's rewrite.
Technical side notes
The current Domain Model and the JSON implementation (https://github.com/TYPO3/TYPO3.CMS/tree/master/typo3/sysext/form/Classes/Domain/Model/Json) will be revised and streamlined.
The following objects of EXT:form should be extendible:
- form objects
- attributes of (existing) form objects
It was discussed, to use YAML as configuration language. Since YAML is not the preferred configuration language of the core, we decided to stick to TypoScript and, if applicable, PageTS.
To flexibilize these objects, most of them need a rewrite. Some work was already done regarding the postProcessors. The validators and filters are still untouched since 4.6 and would require a port to extbase first.
When working on the validators, some further attention could be payed to aria accessibility features, see https://forge.typo3.org/issues/69974.
Further ideas and wishes
This chapter is a collection of ideas and wishes which could be integrated in future releases:
There are no risks. The only problem is time. The new wizard will be part of TYPO3 8 LTS.
Issues and reviews
The issues will be created on forge, category "Form Wizard". The status can be checked here: https://forger.typo3.org/sprint/cig?boardId=FormsNG.
Dependencies upon other Blueprints
There are no dependencies to other blueprints. The whole concept can be implemented with no dependencies on other projects. Everthing needed is already present in the core.