Extending the length of descriptions

Version Relevance: All versions

Issue: Why are many important description fields limited in lenght? Can they be extended?

Mar 9th, 2012

Feedback: All single line descriptions and description-like fields have restrictions imposed on the number of characters that can be entered. A good example of this is customer names and part descriptions, which have limits of 40 and 30 respectively. These restrictions are structural as they are set in the data field definition. These limits can be seen in the window tooltips, for instance {PTMFILE.PTMDESC char national 30} for the part description.

The underlying database stores the data in variable-length format, so the length definition has little effect on database size or performance, especially if the data field is not indexed. You will also notice that all the limited length fields are single-line texts where wrapping is not expected. This is in contrast to large text fields such as Part Individual Sales Text. Such large text fields are shown and edited in multi-line scrollable fields in windows and vertically extending fields in reports. Single-line text fields need to be presented as such in windows and reports and inevitably the width allocated to them in reports must be finite, and it is for this reason that they are limited.

The origins of field character limits goes back to the days of green screens and mono-spaced characters, before the development of proportional fonts and high-resolution printing. However these two technologies did not do away with the need for discipline and that situation still remains the case. In simple terms, if you have a limited space on a column report for a text, you have a choice of allowing the rendered text to run over subsequent columns or force the text's truncation, usually indicated by an ellipsis (...). Recently some developers, notably Apple with their mobile products have added automatic font size and font type adjustments to shrink the text into the required width, but these approaches have their own restrictions and limitations and are not generally available.

In an ideal world we would have the restriction not in crude characters but in pixels or points, so a user could enter text up to a standard column width when proportionally rendered so the following would both be possible:

  • Illustration is ill fitting (27 characters)
  • Were we warlocks we (19 characters)

However, even with this approach problems arise. You would have to fix the font and size and therefore remove the ability to customise styles. And data is exported and rendered on many different devices leading to all sorts of formatting and presentation problems.

As with almost all engineering problems we are therefore stuck with the compromise of the a field's maximum character count. A future version of Caliach Vision will be full Unicode which makes a Chinese solution possible (single Chinese characters contain more meaning) but that is unlikely to help European speakers!

Descriptions, such as part descriptions appear in so many places that discipline in the extent of text used must be enforced. A description of "ZFP 2 loop Panel, 3A PSU, 20 zone indication module fitted c/w name slots b= lank Standard Cabinet, XP95/Discovery Protocol" (123 characters), in most places would only be seen as "ZFP 2 loop Panel, 3A PSU, 20 z..." simply because reports, lists, etc. could not fit the rest in the available column space, or they would have the wrap on multiple lines, reducing the compactness and visual quality of reports.

From a designer's point of view the difference between say 30 and 40 characters for a description in a system such as Caliach Vision is the space needed for one numeric column of report data. So to extend it we would have to eliminate one column per report, and who would be bold enough to decide which data column on each report is superfluous to all users out there?

Sites can of course customise the character limits by customising the file class in many cases but not in key-field cases. This is not uncommon for such fields as the Customer Reference field on SOs. But to do this for such a commonly presented field as part description will, in our opinion only lead to an irreversible deterioration in naming discipline and disappointment in realising any benefit due to text truncation on reports and lists. A much better solution is to exploit the additional texts available rather than the base short-text. Few would consider the need to extend Units of Measure for instance, so that "Individual" could replace "Each" or "EA"; similarly with descriptions.

Chris Ross - Caliach Consultant