Spike: There is a way to properly edit column headers in the new decision table layout

[pinussilvestrus]

What should we do?

After we investigated a new decision table layout which improves the understandability of decision logic, we should invest in a way on how to edit table column headers.

Why should we do it?

Given the following, new decision table layout ...

(Cf. https://dmn-prototypes.netlify.com/decision-table-layout/)

... there should be a way to edit column headers properly in

• setting the input/output name
• setting the input/output type
• creating new columns
• defining engine variable names

Additional stuff is ...

• changing the column order?
• predefined values?
• hiding the When/And/Then clauses?

Resources

• DMN Hypothesis Board
• Summary Docs
• dmn-prototypes
• Demo

[pinussilvestrus]

[pinussilvestrus]

Variants

A: Popup Modal

A1 Dynamic Column width

• Single line expressions per default
• Possibility to manually adjust the column width
• Break content if adjusted

Demo

A2 Fixed Column width

• Single line expressions only
• Cut text if overflow
• Show full content only in editing mode

Demo

B: Direct Editing

B1 Dynamic Column width

• Single line expressions per default
• Possibility to manually adjust the column width
• Break content if adjusted

Demo

B2 Fixed Column width

• Single line expressions only
• Cut text if overflow
• Show full content only in editing mode

Demo

C: Centered aligned cell content (resizable)

Demo

[pinussilvestrus]

🚧 This is Work In Progress

We came up with the following concept:

• Remove Engine Variable Name, for now, we can use the <?> indicator as new DMN feature
• An input/output header follows the layout we see above (one cell only)
• There will be no dedicated fields for output label and name since they can be merged (these are assumptions according to the DMN specifications)
• Direct Editing version as the edit component (variant B)
• Set a max-width for labels per default and crop content with an ellipsis on text overflow (variant B2)
• See full content in edit mode
• edit mode contains the label itself, an expression, the allowed-values/data-type in a combined input (autocomplete functionality)
• Make it possible to resize columns if the user needs it (variant B1)
• Only allow one-line expressions, no text-wrap per default
• Make expression be able to be multiline by pressing
• FEEL will be the default language, other used languages will be indicated
• The Context Menu will be updated as shown in the demo, the functionality stays the same + an option to enable the editing mode will be added
• Adding new columns to the right will be handled as shown in the demo

cf. Demo

Reason

• Direct editing: It makes way clearer what the user is actively editing (input/output expression), reduced noise in comparison to an editing modal (variant A)
• We want the user to shorten its expressions by setting a max-width per default and only go for one-line-expressions
• If he really needs it he is able to use the resize OR should go to literal expressions if he needs multi-line expressions
• We restrict the user a bit per default to not use too large expressions but let him the flexibility to adjust it afterward.

--> That's the behavior user knows from a normal spreadsheet editor like Google Sheets

We won't do user tests for now as we are happy with the solution we found. We think about testing the implementation and iterate over it.

[pinussilvestrus]

We close the concept phase. Shaping all issues will happen in another epic.

Cf. Miro board