Content
View differences
Updated by Eric Schubert over 1 year ago
# Pattern Input Component
## Context and Problem Statement
We need a component which allows us to define patterns containing free text combined with predefined options, that can be selected from a auto-completion/suggestion list.
We did some explorational coding and developed a component using primer base view components and native browser API (in prototype state).
## Decision Drivers
* The component needs to be maintained in future.
* The component must be reusable in different contexts, e.g.
* work package subject configuration
* File Link upload naming
* project name configuration
* read only custom fields
* Possibly for PDF export (ordering columns) given we extend the component functionality
* The UX for creating the pattern must be intuitive.
* Ease to use/intuitive
* Discoverability of token inputs
* The component must be accessible in regard to WCAG 2.0.
* Angular is considered to be discontinued.
## Considered Options
* Editable container with custom made autocompleter style
* Editable container (text-based) with custom made autocompletion and syntax highlighting
* ~~Editable container with ng-select~~
* Draggable autocompleter with custom text
* Editable container with suggestion hover menu
* Customized BlockNote input
* ~~Text-only input~~
## Decision Outcome
_What is the correct decision?_
### Consequences
* _What will be the consequences?_
### Confirmation
_Who confirms this decision?_
## Pros and Cons of the Options
### (Option 1) Editable container with custom made autocompleter style
A custom built input component that looks and feels like an autocompleter while allowing text and "tokens" to be inserted in any part of the text.
[Exploratory implementation](https://github.com/opf/openproject/pull/17472)
* Good, because it is versatile and offers a "natural" UX
* Good, because we can reuse this component in the future for other
* Good, because the component can be implemented without dependencies to JS frameworks
* Bad, because we need to implement accessibility ourselves
* Bad, because it has likely the highest cost of maintenance
* Bad, because we need to implement hacks to support different browsers
### (Option 2) Editable container (text-based) with custom made autocompletion and syntax highlighting
A custom build input component that feels more like a text editor allowing "tokens" that behave like a "@ mention". Selection happens in an autocompleter style.
[Exploratory implementation](https://github.com/opf/openproject/pull/17634)
* Good, because practically as versatile and natural UX as _option 1_
* Good, because we can reuse this component in the future for other
* Good, because the component can be implemented without dependencies to JS frameworks
* Bad, because we need to implement accessibility ourselves
* Bad, because we need to maintain this additional custom component
### (Option 3) Draggable autocomplete with custom text ❌
The existing component that allows adding tags to a input and them reordering them by dragging
[Draggable autocomplete](https://github.com/opf/openproject/tree/dev/frontend/src/app/shared/components/autocompleter/draggable-autocomplete) (TODO: find better reference)
* Good, because it is a battle tested component that is already in use
* Good, because we (mostly) do not have to take care about the accessibility
* Neutral, because it is a component made in Angular
* Bad, because it is not the UX we strive for
* Bad, because user acceptance is low
* Bad, because usage limitation leeds to problems when predicting the final text (white spaces in custom text)
### (Option 4) Editable container with suggestion hover menu
A custom build input component that uses word completion with a hover menu and a trigger character (`@` or `/` or `{`). Similar to Option 2, but replaces the autocompleter look and feel.
* Good, because the simplicity in UX makes it versatile and reusable
* Good, because less impact on accessibility of the input component itself (same as option 2)
* Good, because the component can be implemented without dependencies to JS frameworks
* Bad, because hover menu needs to be custom made (with accessibility)
* Bad, because we do not have an example implementation yet
### (Option ~~(Option 5) Customized BlockNote input ❌ input~~
A third party fully featured text editor with a custom hovercard which allows to insert tags like "@ mentions". Similar to option 2 in feel.
[Block note suggestion menu](https://www.blocknotejs.org/docs/ui-components/suggestion-menus)
* Good, because it offers a natural UX
* Good, because we can reuse in the future, even considering replacing CK editor
* Bad, because of cost of integration (need to be able to integrate React components)
* Bad, because usage is contradicting to the original purpose of BlockNote
* TBD - state of accessibility?
## More Information
* Block note has an option for integrating "vanillajs" -> [https://www.blocknotejs.org/docs/advanced/vanilla-js](https://www.blocknotejs.org/docs/advanced/vanilla-js)
* If we did this it would mean doing a lot of custom/manual javascript implementation and probably would fall in the same cases as options 1 & 2
* Integrating fully with React means likely extending our frontend
## Context and Problem Statement
We need a component which allows us to define patterns containing free text combined with predefined options, that can be selected from a auto-completion/suggestion list.
We did some explorational coding and developed a component using primer base view components and native browser API (in prototype state).
## Decision Drivers
* The component needs to be maintained in future.
* The component must be reusable in different contexts, e.g.
* work package subject configuration
* File Link upload naming
* project name configuration
* read only custom fields
* Possibly for PDF export (ordering columns) given we extend the component functionality
* The UX for creating the pattern must be intuitive.
* Ease to use/intuitive
* Discoverability of token inputs
* The component must be accessible in regard to WCAG 2.0.
* Angular is considered to be discontinued.
## Considered Options
* Editable container with custom made autocompleter style
* Editable container (text-based) with custom made autocompletion and syntax highlighting
* ~~Editable container with ng-select~~
* Draggable autocompleter with custom text
* Editable container with suggestion hover menu
* Customized BlockNote input
* ~~Text-only input~~
## Decision Outcome
_What is the correct decision?_
### Consequences
* _What will be the consequences?_
### Confirmation
_Who confirms this decision?_
## Pros and Cons of the Options
### (Option 1) Editable container with custom made autocompleter style
A custom built input component that looks and feels like an autocompleter while allowing text and "tokens" to be inserted in any part of the text.
[Exploratory implementation](https://github.com/opf/openproject/pull/17472)
* Good, because it is versatile and offers a "natural" UX
* Good, because we can reuse this component in the future for other
* Good, because the component can be implemented without dependencies to JS frameworks
* Bad, because we need to implement accessibility ourselves
* Bad, because it has likely the highest cost of maintenance
* Bad, because we need to implement hacks to support different browsers
### (Option 2) Editable container (text-based) with custom made autocompletion and syntax highlighting
A custom build input component that feels more like a text editor allowing "tokens" that behave like a "@ mention". Selection happens in an autocompleter style.
[Exploratory implementation](https://github.com/opf/openproject/pull/17634)
* Good, because practically as versatile and natural UX as _option 1_
* Good, because we can reuse this component in the future for other
* Good, because the component can be implemented without dependencies to JS frameworks
* Bad, because we need to implement accessibility ourselves
* Bad, because we need to maintain this additional custom component
### (Option 3) Draggable autocomplete with custom text ❌
The existing component that allows adding tags to a input and them reordering them by dragging
[Draggable autocomplete](https://github.com/opf/openproject/tree/dev/frontend/src/app/shared/components/autocompleter/draggable-autocomplete) (TODO: find better reference)
* Good, because it is a battle tested component that is already in use
* Good, because we (mostly) do not have to take care about the accessibility
* Neutral, because it is a component made in Angular
* Bad, because it is not the UX we strive for
* Bad, because user acceptance is low
* Bad, because usage limitation leeds to problems when predicting the final text (white spaces in custom text)
### (Option 4) Editable container with suggestion hover menu
A custom build input component that uses word completion with a hover menu and a trigger character (`@` or `/` or `{`). Similar to Option 2, but replaces the autocompleter look and feel.
* Good, because the simplicity in UX makes it versatile and reusable
* Good, because less impact on accessibility of the input component itself (same as option 2)
* Good, because the component can be implemented without dependencies to JS frameworks
* Bad, because hover menu needs to be custom made (with accessibility)
* Bad, because we do not have an example implementation yet
### (Option
A third party fully featured text editor with a custom hovercard which allows to insert tags like "@ mentions". Similar to option 2 in feel.
[Block note suggestion menu](https://www.blocknotejs.org/docs/ui-components/suggestion-menus)
* Good, because it offers a natural UX
* Good, because we can reuse in the future, even considering replacing CK editor
* Bad, because of cost of integration (need to be able to integrate React components)
* Bad, because usage is contradicting to the original purpose of BlockNote
* TBD - state of accessibility?
## More Information
* Block note has an option for integrating "vanillajs" -> [https://www.blocknotejs.org/docs/advanced/vanilla-js](https://www.blocknotejs.org/docs/advanced/vanilla-js)
* If we did this it would mean doing a lot of custom/manual javascript implementation and probably would fall in the same cases as options 1 & 2
* Integrating fully with React means likely extending our frontend