Cropped Text, the "Dot Crop" Feature


The dreaded sliced text, we have all seen text sentenced to the guillotine. Sliced off at the extremities since they dared trespass beyond the edge of the container they sat in. For those with a weak constitution, this was an undesirable consequence of neglect. But what recourse was there?

The first option, far from ideal, was to resize the container to match the length of the text that resided within. Hmmm, sounds like it might work, but then the questions begin. What about text that is too wide, then does it become multiline?
What about text that is too long, do we then introduce scrollbars?
But is it not the responsibility of the layout manager to relocate and resize it children?
Is there not the danger of a cyclical dependency if the text width forces a 'change' to the parent's width and THEN the layout manger changes the children's width conforming to it's own predefined rules?
Does this overlapping in functionality and reordering (from bottom to top) the layout of controls likely lead to significantly more bugs that are harder to find?
The question almost becomes philosopical in nature, are we a centralized system managing the childrens place in this world from above, or are we a self ordering system imposing our order from below.

Well there is a more elegant solution, it is currently implemented in a limited form across various User Interfaces in use today. The most famous of which is Microsoft's Windows User Interface. However Windows dot crop feature is coded independently per control and is not structured in a root control that is inherited or delegated to all other controls. You would see it implemented in the table control (Seen in Explorer's Detailed View) and in its text fields. At the time of this writing I have not seen it implemented in its Listbox, Button, Calendar, Collapsible Menu, Checkbox, Radio, Image Button, slider, status bar, message box, etc... Even though Microsoft exudes an outwardly appearance of calm stability and a standardized "look and feel" it's hiding a chaotic (and far from standard) framework that reigns underneath. This piecemeal implementation of features ultimately introduces more Lines of Code (more bugs) and (more importantly) overlapping functionality with various implementions leading to a kalediescope of test cases to run which invariably leads to the ever friendly creepy crawlies we so fondly call 'bugs'. They certainly had the right idea. The implementation however is open to debate.

It is important to stress that how an application formats and displays its user interface elements greatly affects a user's perceptions on implied behaviour and robustness of an application.
How else are we to categorize, judge and prioritize an application if not for these visual cues. If we see a misaligned text, gaudy colors, hard to read fonts, all this implies sloppy work. Sloppy work implies sloppy code. Sloppy code implies buggy code. Buggy code brings visions of blue screens, late nights and hair pulling.

There have been extensions to ease a users navigations of an application by implementing tooltips and agents. These tools can help streamline an already robust and clean interface, but will only add to the clutter if it already poorly designed. A famous but true axiom comes to mind, "garbage in, garbage out".

It is important to ensure that at all times these visual cues are handled automatically outside of the developers concern. Thus all controls inherit from a base control that automatically understands how to format text when it is right aligned, left aligned or center aligned. All controls in bambookit inherit from the base control that automatically implements this feature. The edit control, calendar, table, collapsible menus, radio's, checkboxes, listboxes, labels, etc... inherit this feature.


How is it handled?
Let's take the example of the controls above.

When typing or resizing the control and the text exceeds the container its placed in, the text gets cropped according to alignment.
This mechanism is event based. The resize event triggers the layout manager of that control which in turn resizes its text and graphics objects contained within it. When the text object gets resized the string length is calculated and the necessary adjustments made to the 'viewable' text to add (on either side if necessary) the leading or trailing 'dots'.

This is a strong example of moving functionality away from the developers realm of concern and empowering the developer to create richer, more stable and consitent interfaces in quicker times then ever before. These essential visual 'housekeeping' chores (anchors, attachements, containers and formatting) can be managed by the framework and should not reside within the application logic or within a few controls.

But how do we judge a feature should reside within the framework. What are the criteria that we use to move functionality (and flexibilty) out of the application logic and into the framework? That discussion is for a later article to cover.

[Home]

[Blueprints]