Type-able Text Markup for Structured Writing
TypeText -- Why?
====
Christian Augustin
2012-02-15 17:02
en-US
Draft
-------------------------------------------
Reasoning
Many kinds of writing, especially documentation and technical writing, are about _structure_ in the first place, and the visual representation is "hired" to convey this structure to the reader.
HTML (and other markup in the tradition of SGML) is also about structure and should be - at least in theory - a good choice for defining text structures. But it does not make the structure instantly visible: One has to _read_ the tag names to "see" the structure. This is the reason why syntax highlighting or "tag view" is so important when editing HTML and XML documents, but even than you don't immediately "get" the structure (and often comments are used to add visual hints).
WYSIWYG is better at "showing" the structure, but more often than not things that are different have the same or a similar look, and there often is hidden "metadata" (as in links or the names of image files) that is part of the text structure. Everybody seems to think that it is about the visual appearance only, and it makes it hard to see and add all the necessary metadata. And if the structure gets more complex and layout becomes part of the equation it gets nearly impossible to clearly see what is what.
Many variants of lightweight text markup try to be as light as possible and to be as "unintrusive" as it can get by using as few additional characters as possible - and therefor fail to visualize the text structure on the first glance. They make it hard to _see_ the structure by scanning the document, and often they have to resort to HTML for "everyday needs" (like showing content side by side). Some elaborate Wiki markups are good at structuring, but again they fail on visualizing the structure. (Look at the use of horizontal rules in Wikipedia to get structure into the source code and into the rendered page - but they are no structural element, the headlines are meant for that!)
So this is the point where TypeText jumps right in:
Instead of trying to use as few characters as possible, it deliberately uses lines of characters to distinguish content elements as visually clear as possible, mimiking some of the later layout characteristics these elements normally have. For example it distinguishes "block labels" whith their "integrated" horizontal rule from classic "separator rules", and it has special character lines for all sorts of more layout-like elements like columns and tables (clearly distinguishing these two too).
And instead of using the number of markup characters to state the "level" of a list item, it uses a form of visual indentation (whith a little trick) that instantly visualizes it.
????
About abstracting layout
????
====
Christian Augustin
2012-02-15 17:02
en-US
Draft
-------------------------------------------
Reasoning
Many kinds of writing, especially documentation and technical writing, are about _structure_ in the first place, and the visual representation is "hired" to convey this structure to the reader.
HTML (and other markup in the tradition of SGML) is also about structure and should be - at least in theory - a good choice for defining text structures. But it does not make the structure instantly visible: One has to _read_ the tag names to "see" the structure. This is the reason why syntax highlighting or "tag view" is so important when editing HTML and XML documents, but even than you don't immediately "get" the structure (and often comments are used to add visual hints).
WYSIWYG is better at "showing" the structure, but more often than not things that are different have the same or a similar look, and there often is hidden "metadata" (as in links or the names of image files) that is part of the text structure. Everybody seems to think that it is about the visual appearance only, and it makes it hard to see and add all the necessary metadata. And if the structure gets more complex and layout becomes part of the equation it gets nearly impossible to clearly see what is what.
Many variants of lightweight text markup try to be as light as possible and to be as "unintrusive" as it can get by using as few additional characters as possible - and therefor fail to visualize the text structure on the first glance. They make it hard to _see_ the structure by scanning the document, and often they have to resort to HTML for "everyday needs" (like showing content side by side). Some elaborate Wiki markups are good at structuring, but again they fail on visualizing the structure. (Look at the use of horizontal rules in Wikipedia to get structure into the source code and into the rendered page - but they are no structural element, the headlines are meant for that!)
So this is the point where TypeText jumps right in:
Instead of trying to use as few characters as possible, it deliberately uses lines of characters to distinguish content elements as visually clear as possible, mimiking some of the later layout characteristics these elements normally have. For example it distinguishes "block labels" whith their "integrated" horizontal rule from classic "separator rules", and it has special character lines for all sorts of more layout-like elements like columns and tables (clearly distinguishing these two too).
And instead of using the number of markup characters to state the "level" of a list item, it uses a form of visual indentation (whith a little trick) that instantly visualizes it.
????
About abstracting layout
????