One big problem for WYSIWYG conditional text is allwing the editor to recognize the conditions.
Basically, to do WYSIWYG editing of conditional text, you need to be non-WYSIWYG ... :-(
There are only a few things that you can do to distinguish different conditions:
* use color
* use font bold, italic. Fontsize not so good.
* use background colors
* use marks like underlining, strikethrough, crosshatching.
Anything that is used to indicate conditions might conflict with the same visual effects used in the final document. Not so bad if preparing for publication in the traditional press, which is largely black and white. Bad if you want to use those effects, e.g. on a webpage.
If you have limited colors, say 4, and limited effects, say single and double underling => well, you only get 8 combinations. But even the v123 tABC example exceeds that.
You get to 4x4x4x2 if you allow all combinations of letter color, underline color. and background color. I don't know of a tool that does this. Sure, it would look cluttered - but I suspect that my brain coukld decode.
Of course, have more colors than 4. But conversely, probably don't use exactly the same colors - foreground text red on background red is useless. The system probably needs to automaically adjust, so that it is foreground red on a immd red that can show the contrast. Conventions.
---
Not to mention that we want to see overlapping tags. E.g. reserve background color for one set of tags, v123; text for another tABC. This doesn't scale.
---
Two effects may scale:
underlining with different colors
flyovers - these can indicate arbitrary combos of conditions.
---
Part of the trouble in managing WYSIWYG conditional text is that an upstream usr may decide to user a color that you have already used.
Quite apart from the logic.
Subscribe to:
Post Comments (Atom)
7 comments:
Much of the problem with WYSIWYG conditional text lies in managing the indication that txt is conditional: the colors. Underlining, etc.
This is both non-scalable and non-modular.
Non-scalable in two senses: First, because we run out indications far too soon. Eventually different conditional text tags will need to conflict in indications. Second, because of the difficulty of indicating overlapping tags. You can adopt conventions, such as underlining indicating Tag1, and colors TagA, B, and C. But, again, we run out of indications.
Non-modular: because if user1 uses green underline to mean "Low Power", but user2 uses it to indicate "Extra Cost", they conflict. It is necessary for them to cooperate in how tags are mapped to visual indications.
Some might say "Bad organization, no coordination". But often coordination means allocating non-interfering mechanisms - e.g. the Architecture group uses brown, the RTL group uses green - and the lack of scalability gets in the way.
By the way, static coordination is not so bad. Often the problem is coordination with local extensibility: each group needs to add new features, new conditional text tags.
I believe in technical solutions to organizational problems. Not always possible, but when they work, helps a lot. DVCS is such a technical solution.
Indications:
Colors are not-very scalable in number. hard to indicate overlap. Non-modular because of these problems. Whether foreground text color, or background shading or highlighting.
I diss fonts as conditional text indicators.
Effects such as underlining are middling scalable. Although their repertoire is limited - lines of different colors and thicknesses and dashed, dotted - we can imagine multiple lines. Especially if we are willing to change line spacing for complicated overlaps. (And, moreover, although I want to support overlapping I also want to encourage it not to be used.)
Flyovers can scale arbitrarily, both in number and overlap. They are modular. But they are not as visible.
Variations may be more visible: e.g. bubbles visible in margin (or in text), over regions marked by tet color/shading/underlining.
Here history can inspire us. I learned from Keith Houston's "Shady Characters" book that for centuotations quotation marks did not brackt quoyred text, but were only marks in the margins.
Blogger is stupid. No edit button on comments.
Still, scalability is limited, an conflicts between styles allocated by different authors sharing a document, possibly via transclusion, will always arise.
Q: why should conditional text tags be allocated statically?
In FrameMakr the indications are allocated statically, and are either all on or all off.
Instead, how about being able to enable some but not all conditional text tags?
Get warned if some conflict - either looking alike, or overlapping, or possibly conflicting with visual styles in the actual text.
Be given the option of remapping, in the current view, the visual indications.
Use scalable mechanisms - flyovers, etc. - to make it easier to recognize.
Possibly save certain views, separate from the default.
Probably have an indication for "conditional text not uniquely indicated in the current view".
I.e. use a level of indirection, a dynamic mapping, to handle scalability problems in number and overlap, and cope with conflicts. And use flyovers, margin bubbles, etc., to make it easier to deal.
So far talking about conditional text.
What about diagrams? Figures? Blocks of conditional rows in tables?
Apart from coloring lines and fill in drawings that do not use all colors, I suppose that area highlighting, transparent washes, are the way to go. With flyovers/bubbles/margin notes to provide more info.
This suggests that background color/highlighting might be the easiest thing, since it applies to both text and drawings/tables.
One of my peeves about FrameMaker is that it does not clearly indicate that an entire table, or text inset, is conditional. It will indicate that text within a text cell is conditional, and that the cells of an entire row are conditional (by a "border" on the cells in the conditional row), but you cannot table that a table is conditional by looking at it. Instead, you have to look at the coloring of the anchor point for a table, which may be a long way away.
This is really an example of the interaction of transclusion and conditional text.
Although FrameMaker differs in that the conditional text settings of the includer can be applied to the includee.
The mechanisms already discussed can handle overlap. Go a little bit further, and in the flyover indicate how and where a tag is applied: at include point, table anchor, transitively... Helps even in regular text: consider a section that is transitively marked conditional, as opposed to markings on a flat character by character basis.
Of course, may want edit operations that allow us to take a section transitively marked, andunmark it internally. Whether by an overriding mark, or by applying the section mark to all subcomponents, removing the section mark, and then removing the local mark.
Tables and conditional text:
Conditional rows, easy. FrameMaker does that.
Conditional columns - straightforward, although Framemaker doesn't do it.
Perhaps we need go no further.
But I often want to... Why?
What dos it mean to want to make a cell conditional, but not an entire row or column?
Consider a Karnaugh map table:
| | 00 | 01 | 11 | 10 |
|----+----+----+----+----|
| 00 | a | b | c | d |
|----+----+----+----+----|
| 01 | e | f | g | h |
|----+----+----+----+----|
| 11 | i | j | k | l |
|----+----+----+----+----|
| 10 | m | n | o | p |
If blocks of adjacent cells have the same result:
| | 00 | 01 | 11 | 10 |
|----+----+----+----+----|
| 00 | a | b | c | d |
|----+----+----+----+----|
| 01 | e | X | X | h |
|----+----+----+----+----|
| 11 | i | X | X | l |
|----+----+----+----+----|
| 10 | m | n | o | p |
They can be merged.
Humans find it easier to read tables with merged cells, since important patterns are already recognized.
| | 00 | 01 | 11 | 10 |
|----+----+----+----+----|
| 00 | a | b | c | d |
|----+----+----+----+----|
| 01 | e | | h |
|----|----| X |----|
| 11 | i | | l |
|----+----+----+----+----|
| 10 | m | n | o | p |
But if the block of cells has an exclusion
| | 00 | 01 | 11 | 10 |
|----+----+----+----+----|
| 00 | a | b | c | d |
|----+----+----+----+----|
| 01 | e | X | X | h |
|----+----+----+----+----|
| 11 | i | X | Y | l |
|----+----+----+----+----|
| 10 | m | n | o | p |
Graphically:
| | 00 | 01 | 11 | 10 |
|----+----+----+----+----|
| 00 | a | b | c | d |
|----+----+----+----+----|
| 01 | e | X | h |
|----+----| +----+----|
| 11 | i | | Y | l |
|----+----+----+----+----|
| 10 | m | n | o | p |
Deleting the cell Y
or making the cell conditional
gives the merged cell
| | 00 | 01 | 11 | 10 |
|----+----+----+----+----|
| 00 | a | b | c | d |
|----+----+----+----+----|
| 01 | e | | h |
|----|----| X |----|
| 11 | i | | l |
|----+----+----+----+----|
| 10 | m | n | o | p |
This tends to imply that seeking to delete a single cell should ask the question (delete entire row, column, or merge this cell with what adjacent cell?
And conditional text for that involves sabing the answer to that question.
Post a Comment