Content
View differences
Updated by Parimal Satyal 3 days ago
#### Current approach
When configuring a form for a type or variant, the meta information we provide on a field can be confusing.
Here's how it is today:
<img class="image_resized op-uc-image op-uc-image_inline" style="width:587px;" src="/api/v3/attachments/924814/content">
**The problem:**
Things are a bit message and inconsistent:
* We have a "Built-in" label for fields that come standard with OpenProject, but no "Custom" label for the others
* Custom fields also note the type of field ("Hierarchy", "List") but the built-in ones don't.
* In combination, it looks like we're mixing field type information with origin information, but with different visual codes.
#### **Possibles remedies**
There are a few ways to improve on this:
**Rosanna approach**
<img class="image_resized op-uc-image op-uc-image_inline" style="width:572px;" src="/api/v3/attachments/924816/content">
* Consistency:
* Every field has a label: Built-in or Custom
* Every field also has a field type, contained within the label
* Fewer elements: one label that's always there for `origin: type` and another one for `required`
* Downsides:
* Two labels makes it look heavy
* Do we need to distinguish built-in from a custom field at all?
* Built-in fields don't really have a type
**Simplified**
<figure class="image image_resized op-uc-figure" style="width:572px;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/924817/content"></div></figure>
* Very easy to read: labels only for `required` and type displayed in regular text only for custom fields
* Cleaner: No "built in" label at all; it's not too relevant for the admin user
* Makes a subtle distinction between "standard/built-in" fields vs. custom fields, simply by not showing the type for built-in ones
* Downsides:
* Slight inconsistency: built-in fields don't have a 'type' text, since they simply don't have types
<br>
**Simplified but everything has a type**
<img class="image_resized op-uc-image op-uc-image_inline" style="width:563px;" src="/api/v3/attachments/924820/content">
* All the advantages of simplified, except we also add type information to built-in fields
* Most consistent, although we'd need to hard-code type information
* Downsides:
* Hard-coded types for built-in fields can sometimes be absurd (eg. Dates being of types Dates)
#### On the topic of marking fields as built-in
I don't actually think we need to mark fields as 'built-in' for a few reasons:
* The term isn't particularly clear and sounds a bit awkward
* In the near future, we're headed towards named forms that can be reused. If we do this, we can also allow the admin to define one of these forms as default
* The distinction then would simply not be as relevant; this information doesn't help the admin user too much when building a form for a type
When configuring a form for a type or variant, the meta information we provide on a field can be confusing.
Here's how it is today:
<img class="image_resized op-uc-image op-uc-image_inline" style="width:587px;" src="/api/v3/attachments/924814/content">
**The problem:**
Things are a bit message and inconsistent:
* We have a "Built-in" label for fields that come standard with OpenProject, but no "Custom" label for the others
* Custom fields also note the type of field ("Hierarchy", "List") but the built-in ones don't.
* In combination, it looks like we're mixing field type information with origin information, but with different visual codes.
#### **Possibles remedies**
There are a few ways to improve on this:
**Rosanna approach**
<img class="image_resized op-uc-image op-uc-image_inline" style="width:572px;" src="/api/v3/attachments/924816/content">
* Consistency:
* Every field has a label: Built-in or Custom
* Every field also has a field type, contained within the label
* Fewer elements: one label that's always there for `origin: type` and another one for `required`
* Downsides:
* Two labels makes it look heavy
* Do we need to distinguish built-in from a custom field at all?
* Built-in fields don't really have a type
**Simplified**
<figure class="image image_resized op-uc-figure" style="width:572px;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/924817/content"></div></figure>
* Very easy to read: labels only for `required` and type displayed in regular text only for custom fields
* Cleaner: No "built in" label at all; it's not too relevant for the admin user
* Makes a subtle distinction between "standard/built-in" fields vs. custom fields, simply by not showing the type for built-in ones
* Downsides:
* Slight inconsistency: built-in fields don't have a 'type' text, since they simply don't have types
<br>
**Simplified but everything has a type**
<img class="image_resized op-uc-image op-uc-image_inline" style="width:563px;" src="/api/v3/attachments/924820/content">
* All the advantages of simplified, except we also add type information to built-in fields
* Most consistent, although we'd need to hard-code type information
* Downsides:
* Hard-coded types for built-in fields can sometimes be absurd (eg. Dates being of types Dates)
#### On the topic of marking fields as built-in
I don't actually think we need to mark fields as 'built-in' for a few reasons:
* The term isn't particularly clear and sounds a bit awkward
* In the near future, we're headed towards named forms that can be reused. If we do this, we can also allow the admin to define one of these forms as default
* The distinction then would simply not be as relevant; this information doesn't help the admin user too much when building a form for a type