Allow Zoom of DMN Tables in Modeler

[berndruecker]

Font size should be scalable to be able to make DMN tables readable even in presentations. Works well with browser zoom for bpmn.io/dmn version.

Tasks

• [ ] Be able to increase font size / make table visible in presentation mode

[nikku]

What exactly would you like to zoom in? Font size?

[berndruecker]

Jepp. But typically it would then also make sense to make cells bigger accordingly. But definitely font size (you cannot read anything on a typical presentation setup for talks or inhouse meetings)

[nikku]

Could you provide a few screenshots how the typical presentation setup would look like?

How would you compensate the fact that the display width is much smaller? Extensive scrolling?

[berndruecker]

For talks I typically have small tables - no need to scroll that much. For real-life meetings I would scroll, yes. Better than if things are not readable.

Don't have screenshots at hand now - but my Eclipse is set to font size 20 if that gives you a good indication what proofed to be readable in most settings

[ArtunSubasi]

I'm also struggling with wide columns in a customer project. Some lines have a long list of strings. This leads to very wide columns which cannot seem to be resized. Getting a good overview is hard because we have to scroll horizontally a lot.

Zooming out would not solve the problem but would help to get a better overview.

I'm also thinking about creating new feature request for line wrapping or line abbreviation (displaying long lines shorted as ...). But this is a different story.

[barmac]

@ArtunSubasi Can you share any of the tables where the width of a column is a problem?

We are considering either cropping the content or line wrapping, but haven't decided yet.

[ArtunSubasi]

@barmac, sure. I anonymized an shortened a table that we are using. I'm pasting the DMN XML content since I can't seem to attach the file here.

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/DMN/20151101/dmn.xsd" xmlns:biodi="http://bpmn.io/schema/dmn/biodi/1.0" id="orders" name="DRD" namespace="http://camunda.org/schema/1.0/dmn" exporter="Camunda Modeler" exporterVersion="3.7.3">
  <decision id="products" name="Products">
    <extensionElements>
      <biodi:bounds x="156" y="81" width="180" height="80" />
      <biodi:edge source="pg">
        <biodi:waypoints x="534" y="259" />
        <biodi:waypoints x="717" y="364" />
      </biodi:edge>
    </extensionElements>
    <decisionTable id="DecisionTable_1r8pfs2" hitPolicy="FIRST">
      <input id="InputClause_075hnks" label="Product number">
        <inputExpression id="LiteralExpression_0wtxgvb" typeRef="string">
          <text>productNumber</text>
        </inputExpression>
      </input>
      <output id="OutputClause_0egi8da" label="Product Category" name="productCategory" typeRef="string" />
      <output id="OutputClause_0yaho31" label="Subscription Possible" name="subscriptionPossible" typeRef="boolean" />
      <rule id="DecisionRule_0d85vx1">
        <description></description>
        <inputEntry id="UnaryMAGZs_0exmpwk">
          <text>"BOOK0000","BOOK0001", "BOOK0002", "BOOK0003", "BOOK0004", "BOOK0005", "BOOK0006", "BOOK0007", "BOOK0008", "BOOK0009", "BOOK0010", "BOOK0011", "BOOK0012", "BOOK0013", "BOOK0014", "BOOK0015", "BOOK0016", "BOOK0017", "BOOK0018", "BOOK0019", "BOOK0020"</text>
        </inputEntry>
        <outputEntry id="LiteralExpression_1965u6x">
          <text>"Book"</text>
        </outputEntry>
        <outputEntry id="LiteralExpression_0vv7dkf">
          <text>false</text>
        </outputEntry>
      </rule>
      <rule id="DecisionRule_16ehzvj">
        <description></description>
        <inputEntry id="UnaryMAGZs_0qpk3to">
          <text>"MAGZ0000","MAGZ0001", "MAGZ0002", "MAGZ0003", "MAGZ0004", "MAGZ0005", "MAGZ0006", "MAGZ0007", "MAGZ0008", "MAGZ0009", "MAGZ0010", "MAGZ0011", "MAGZ0012", "MAGZ0013", "MAGZ0014", "MAGZ0015", "MAGZ0016", "MAGZ0017", "MAGZ0018", "MAGZ0019", "MAGZ0020"</text>
        </inputEntry>
        <outputEntry id="LiteralExpression_1fbi7a6">
          <text>"Magazine"</text>
        </outputEntry>
        <outputEntry id="LiteralExpression_0artb0w">
          <text>true</text>
        </outputEntry>
      </rule>
    </decisionTable>
  </decision>
</definitions>

[barmac]

Thank you!

This is how it looks like on my computer:

I experimented a bit with how we could change the behavior. You can view the screenshots below.

If we introduce ellipsis for overflowing content, this could look like:  or, when we introduce width limit:  With word wrapping, full content could be displayed at the cost of increased row height:  or, when we introduce width limit: 

Generally, I think that solutions with maximum width make that the cells with lists of items do not overwhelm the table. Even with ellipsis the full-size cell takes more than half of available space which is not the case when we add width limit. On the other hand, with text wrapping the table can display less rules due to increased row height. I am also not sure, if we really need to see all of the rule content for each rule at the same time. It seems to be unnecessary, especially if the cell content is a list of repeatable items.

What do you like the most? What could we also try out?

[ArtunSubasi]

Great suggestions! I must say, all options look better than the current one. I'm not sure if inline editing would work well with ellipsis for overflowing content. What would happen if you click on a row to edit? We could convert to line wrapping or remove the ellipsis overflow content to edit (as in the current version). In both cases, the layout would jump back and forth which could reduce the usability. Therefore, using line wrapping could be a better choice for better editing.

Would it also be possible to change a column width manually by dragging it? That would be a good combination either with ellipsis or line wrapping. The cherry on top would be persisting the adjusted column with in the XML if the DMN standard allows storing such layout data.

[pinussilvestrus]

The cherry on top would be persisting the adjusted column with in the XML if the DMN standard allows storing such layout data.

+1 for this one!

[nikku]

It does not allow but still worthwhile having it :arrow_double_up:

[barmac]

I believe that for the ellipsis case we could solve it in a similar way as Google Spreadsheets:

The good point of this is that we keep the same layout of the table. On the other hand, you don't see any columns to the right as soon as you start editing.

---

Regarding the manual adjustment of the column width, we are actually already discussing this feature in the bpmn-io/dmn-js repository. We could save the column width via extension elements. That would not be interchangable between DMN tools, but still the diagram would be valid in the context of DMN.

[ArtunSubasi]

The good point of this is that we keep the same layout of the table. On the other hand, you don't see any columns to the right as soon as you start editing.

Personally, it wouldn't bother me if some columns are hidden during the editing. I think using ellipsis and the Google Spreadsheet way to edit would be a good solution.

Thumbs up for https://github.com/bpmn-io/dmn-js/issues/500 :)

[barmac]

Thank you for your feedback :) If you have any more ideas/thoughts regarding this or other subject, please feel free to post them!