Wednesday, December 14, 2011

Enclosing marks (semantics and readability [with nesting])

In my writing I have a tendency to excessively use enclosing marks (parentheses, square brackets, and curly brackets mainly, but also double quotes and single quotes [really matching apostrophes]--dashes should probably also be included in the list, though a dash enclosure can terminate with another termination mark [e.g., period, closing parenthesis]).

This seems to come partially from a self-conceit issue, which presents my thoughts as being less worthy (and so deserving the de-emphasis of parentheses--don't attack me for making stupid comments) and raises doubts about the clarity of my expression (so that explanatory notes are appended in parentheses--don't attack me for being unclear and don't attack me for stating what only an imbecile would not know). Another motivation seems to be a desire to indicate that the content is not essential (whether explanatory [including adding details] or speculative [which might include adding variants])--sometimes being important content (e.g., content without which later statements would be very difficult to understand) which is "subservient" to the non-enclosed content (somewhat like nested lists in html).

While I have sometimes been able to reduce the number of parenthetical comments, it is difficult to do so because the enclosures provide a sense of structure and (I perhaps irrationally hope) allow a communication of details without excessively disrupting the flow--the reader could scan more quickly over the enclosed comment. In some cases, extended parenthetical comments can be broken off into new paragraphs (paragraph breaks do indicate a transition but do not indicate the "subservience" of the material).

While sidenotes, footnotes, and endnotes can provide some of this functionality, the composition tools and presentation tools do not seem to support ease of composition and ease of reading. This is particularly problematic in the presence of even limited media independence. In part because of the lack of excellent navigating tools, sizing html pages to match the functionality of pages in printed media (such that footnotes could be used) would be inappropriate. Even limited layout independence makes presenting notes at the bottom of a view port very difficult (and, in the case of longer notes within a small view port, the note might not fit in the same view port as the text that references it). A reasonable compromise might be the use of a separate, bordered block after each paragraph containing note marks.

Notes also have the issue that there does not appear to be a standard syntax for note marks. Although numeric marks are sometimes used to indicate references (which usually are suitable for endnotes) while asterisks, daggers, and double-daggers indicate comments, there does not appear to be a convention for indicating significance, length of the note, or nature of the note (explanatory, side comment, extension--even references can vary in nature, some being primarily crediting of ideas and some being more about extended explanation or context [and a reference might include an extended quote, which would not be suitable for inclusion in the flow of the text, followed by a reference to the source]). Traditional notes also do not provide a context for the note; a note might apply to a word or term, a phrase, a clause, a sentence, a paragraph or even a larger section of text (though an unreferenced endnote would probably be appropriate for notes relating to a whole section). For shorter contexts, highlighting the context seems reasonable (and the nature and strength of the highlighting could be used to indicate additional information about the link), but even weakly highlighting larger contexts would be distracting (an alternative might be to use a sidenote-like marking, perhaps a vertical bar, though I think that might not be helpful).

Anyway, a significant problem with extensive use of enclosing marks is that nesting urges a means to distinguish levels of nesting. While I commonly use the sequence parenthesis, square bracket, curly bracket (and, if necessary--though this usually indicates a need to reformat--, back to parenthesis), this has the significant problem that square bracket can be used with special semantics (e.g., to indicate a quoted mistake [sic]--which really is an inferior marking because it does not indicate the context or nature of the error nor does it guard against the error being altered in transcription).

A similar problem arises with quotation marks. Sometimes quotation marks are used to indicate approximately used or nonce terms, but that can introduce confusion for short quotations. Likewise nesting of quotations and similar enclosing marks can be difficult.

Obviously, I should reduce my use of parenthesis, particularly with respect to guarding statements. Yet there remains an issue of communicating the importance, relevance/context, and nature of statements. Parentheses also provide a better visual clue of separation than commas, which may make parsing easier (particularly for short comments). In more casual writing such as a blog or forum post, there is less incentive to rework the text to maximize readability; but even in a more formal composition (especially when there is not a length limit to constrain content) there is a place for "inline notes".

Perhaps a better but impractical mechanism would be to use styling to conditionally hide content. The reader would choose the style and the user agent would hide, include, use inline or "near-line" revealable/hidable notes, and other presentation methods to present the content of interest to the reader. E.g., the desired degree of detail, the knowledge base of the reader, the interest of the reader in side comments, or even more complex factors like reputation of the writer among peers, with the reader or the reader's trusted group on the topic--such factors could be used to tailor the presentation of a text to provide a better reading experience. (A side issue with revealing and hiding notes is that such breaks the visual recognition of the reader. The layout of text seems to give powerful visual clues to readers which allow scanning a previously read text very quickly. While text search tools can remove some of the need for such, there remains some difficulty when the reader cannot remember a precise phrasing or worse in terms of automated search if the reader only remembers that there was an interesting comment in the text or a portion of the text.)

In reading academic papers, even such niceties as indicating if the reader has read a particular reference--or a similar version--or an earlier paper on the same basic idea and including any quick notes the reader may have attached to the work. Likewise bibliographies and notes on authors could be useful in filtering and directing interest in references.

It seems that there should be a better mechanism of communicating (though a large fraction of my poor communication practices come from lack of effort), but I do not know how the presentation of text (and so its composition) can be substantially improved without extraordinary effort from the writer (or the reader).

Saturday, December 10, 2011

Beyond keyboard mediocrity

It is a somewhat disappointing that there is so little innovation in computer keyboard design--at least for lower-priced keyboards. In thinking about a better keyboard, I think one significant improvement would be a grid (a.k.a. matrix, rows and columns, non-staggered) layout. While it is not clear to me that such a layout would have significantly better finger movement properties--I have seen at least one claim to that effect, but that claim did not take into account the curve of the hand, only measuring physical distance--, it seems that such could have some nice mnemonic features.

In particular, one could overlay a number/navigation pad onto the main key space using the equivalent of a capslock to activate. The main benefit of such would seem to be not the reduction of movement per se but the reduction of context switching. Even if one can transfer one's hand to a separate number/navigation pad without looking, a bit more attention must be given to the transition compared to pressing a mode key. (One of the problems I have with vi[m] is that the default direction keys are not "intuitive"; a better mapping using the right hand might be: index finger, left, middle finger, down, ring finger, right, row-above-middle-finger, up.)

In addition to a grid layout, it seems appropriate to have a center section with specialized keys. Besides providing a more ergonomic separation of hands during typical use, such might also be more friendly to visual examination (not only would one's hands not block line-of-sight but they might also provide a visual framing context), which may be more common for less frequently used keys, and might be more friendly for from-and-back hand movement than placing such keys to the sides (the strong fingers are near the inside, inward arm movements might be slightly easier) and would seem be be better than placing such keys farther up on the keyboard (again, strong-fingers bias and possibly friendlier hand movement).

Of course, a laptop might have a problem with widening the keyboard, even with widescreen displays. A laptop would also favor a lower width-to-height aspect ration in the keyboard; desktop keyboards tend to have a higher aspect ratio than displays have. This issue requires some additional thought.

In addition to the above, the QWERTY layout is broadly condemned as substantially sub-optimal. However, the Dvorak layout that some promote also seems a little sub-optimal to me even at a cursory examination. E.g., the 'h' and 't' keys are on the right and left of each other when a common English two-character sequences is 'th' and "rolling" the right hand clockwise seems likely to be easier. (It is understandable that this would not be a consideration in the original design since Dvorak was designed for manual typewriters not keyboards. The placement of vowels might have a similar "rolling unfriendly" nature, the benefit of use-frequency placement might dominate. [Interestingly, I found the following quote on a site supporting Dvorak: "When the same hand has to be used for more than one letter in a row (e.g., the common t-h), it is designed not only to use different fingers when possible (to make keying quicker and easier), but also to progress from the outer fingers to the inner fingers ("inboard stroke flow") -- it's easier to drum your fingers this way (try it on the tabletop)." Now I have to think if "drumming" is more appropriate than "rolling" even on a keyboard--and with a more comfortable separation of hands rolling might be even less natural.) In addition, the arrangement of symbol characters seems likely to be sub-optimal for modern uses--especially for programmers.

Somewhat related to layout, a separated grid keyboard might be more friendly to internationalization in that it would be designed to a more common feature (the traits of the human body--variations in hand width, finger length, and other factors are issues with any layout), though a language with a higher count of commonly used glyphs might prefer more keys (that are harder to use) rather than requiring modes or digraph-like operations. Even so, it might be slightly easier to extend a grid layout without conceptual discord since a grid is so regular.

Another small issue I have with conventional keyboards is the relative lack of use of thumbs. While having the space key used by thumbs seems good, it seems it might be more appropriate to have separate keys for left and right hands (effectively required for a separated grid layout) and allow modifier keys to be used with the space key. E.g., it might be appropriate for shift-right_space to map to tab and shift-left_space to map to back tab; it might also make sense for the underscore glyph to map to a modified space--such seems to have a mnemonic appropriateness. While thumbs might only be able to use two keys where most fingers can somewhat easily reach three or more keys--and they may have to be oversized keys--, this would still seem to enhance the interface with the hands. (An alternative to keys might be a trackpad for gesture-based input. I have not learned to use a trackpad in place of a mouse, having difficulty with fine control of movement, but simple gestures such as slide up or slide down, with rapid repetition and motion speed variants as well as press and possible press-hop-press could be simple and coarse enough for common use.)

It also seems that there might be some opportunities to improve the "mnemonic sense" of the layout, though ergonomic factors should probably have priority. E.g., '!' might fit better as a shifted '.' In a similar manner, mapping the function keys to shifted--or otherwise modified--numbers might be appropriate. (Of course, this would break compatibility with having twelve function keys and with full flexibility in applying modifiers to such keys, but this might be an acceptable sacrifice for most people, especially since it could also make the function keys more accessible. This would also require finding suitable mappings for the symbol keys typically mapped to shifted numbers.)

In terms of learning a keyboard layout, as well as avoiding and recognizing mistakes, it is not clear whether "associated" or visually similar glyphs (e.g., 's' and 'z', 'm' and 'n'), should be placed close together or be widely separated. Proximity would seem to more easily allow a hunt-and-peck typist to see the alternate glyph (helping to avoiding typing the wrong key and perhaps guiding vision toward the correct key--seeing something that looks like the desired glyph drawing focus to the area which might then see the correct glyph) and might have some mnemonic value in learning to touch type. (The Dvorak placement of the vowels might have a mnemonic benefit as well as an alternating hand benefit.) Horizontally adjacent placement of opening and closing symbols might be more appropriate than symmetry based on left and right hands. While symmetric placement would balance hand use, the temporal separation of opening and closing would tend to make that immaterial--except in evil languages that force the programmer to use '()' (such an unbearable inconvenience! :-).

At the software level, an argument could be made that different types of key presses could have different meaning, particularly for mode setting keys. E.g., a double-press of shift might be an effective mechanism for setting capslock; it has a mnemonic advantage of using the shift key and avoids the need for a separate key for a relatively infrequently used function. Along similar lines, press-and-hold of a mode key might indicate that the mode should only be maintained while the mode key is held; press-and-release could then be used to indicate a persistent mode change. Unfortunately, this could have issues when another key is pressed while the mode key is still depressed; this would be interpreted as a single-key mode duration when the user might have intended persistence. Forcing the user to pause to account for the computer's inadequacies is inappropriate.

Many of the above thoughts are not unique to me (though the thoughts came to me before I saw that others had already discovered them). E.g., one person built a custom keyboard with several of the above features, and the "Truly Ergonomic Keyboard" has similarities (though it uses a presumably more expensive to manufacture slanted and wavey grid).

Another point that is sometimes made with respect to keyboard design is the lack of independent switching. I am not convinced that the cost of supporting such is worth the benefit. On the other hand, with a separated grid layout, it might be practical in terms of manufacturing and usability to provide more simultaneously distinguishable key presses that are from different hands. I have not even begun to think about trade-offs in that area.

Friday, December 9, 2011

A side effect of a noble wife

Proverbs 31:28-29 declares concerning a wife of noble character that her husband says of her "Many women do noble things, but you surpass them all." (NIV). So beyond drawing praise from her husband, such a woman also causes her husband to respect and recognize virtue in other women.

This presents wives with a significant potential ministry to the broader culture of the current generation, especially when that broader culture tends to denigrate women. A man who sees that "many women do noble things" (recognizing the presence of virtue in many women and by implication the potential for virtue in even more) is less likely to tolerate the expression of radically contrary views (viewing all women as wicked) in his social circle. A noble wife is perceived not as an exception that emphasizes the wickedness of other women but more as an archetype demonstrating the ideal nature of women.

Context-based overloading

It seems that it might not be that involved to extend the object-oriented programming feature of function overloading based on object type to include overloading based on other contextual aspects like target ISA/microarchitecture. Digital Mars' D programming language provides a version feature which allows conditional compilation based on ISA and OS, though microarchitectural features are not included. The pre-defined version names also appear to be flat; some degree of hierarchy might be appropriate. Defining such with classes and objects could allow inheritance (e.g., Linux could inherit from Posix [but not necessarily from Posix-strict] and Nehalem could inherit from x86-64), possibly simplifying management of such names.

As a non-programmer who thinks about programming language design [i.e., an ignoramus but not a complete ignoramus], I think a more elegant expression of such conditional compilation might be to use any statement that evaluates to a boolean compile-time constant as a control for block compilation. The D programming language provides static if, but a short hand form of static if could simply include the expression. Of course, one could then simply provide that syntax for all conditional blocks. It seems that this would also extend to switch-like statements, perhaps along the lines of:

some_function(function_argument)  // returns a positive integer
   == 1 
   == 2
   < 7
      do_things_for_3_through_6 // note this assumes an
                                // explicit fall through
                                // requirement
That might not be a good extension, however.

Using a static keyword does force the compiler to guarantee that the expression can be evaluated at compile time. While an advanced development environment would be able to express the compile-time constant nature of an expression (at least for simple cases), there might be some advantage to explicitly indicating the static nature.

If the C programming language had used ~ for boolean inversion as well as bitwise complement instead of !, then ! might be used as an assert-like indicater, possibly with pre-assert and post-assert forms (analogous to pre-increment and post-increment; pre-assert would be evaluated at compile time, post-assert at run time). Without an associated block, such would act like an assert; with an associated block, such indicate a forcefulness along the lines of "if such is true--and it almost certainly is--then".)

As an extension (and one that might be compatible with C programmers), one could use ? in its pre-expression form to communicate a compile-time hint (like the above pre-assert) that the code in the associated block might be suitable if the expression evaluates to true but the compiler can override that hint (whereas a pre-assert forces the compiler to use the code if the expression is true). One might be able to use a duplication of the symbol to express emphasis, i.e. ?? in prefix form might indicate a low-confidence hint and in postfix form might indicate a low-probability condition; likewise (if one could use the symbol in that way without confusing programmers) !! in postfix form might indicate "almost certain" (and without an associated block it might indicate a higher level exception or more critical failure), though I am not certain what meaning such should have in prefix form (overriding later overloading--a bit like CSS !important--might make sense, but seems a bit dangerous).

Thursday, December 8, 2011

A small thought on the Trinity

Although I have heard expressed the recognition that the Trinitarian nature of God is an essential aspect of God's self-sufficiency in love (i.e., God must express the inter-personal character of love in God's own being), but I have not heard anyone indicating that the begetting of the Son might be a necessary aspect of God as Creator. My thinking in this is that even the creative act (causing to be a non-self which expresses the character of oneself) 'must' have an analogous aspect within the Divine nature both from the necessity of self-sufficiency and from a causal aspect (one's actions reflect one's nature, so even the act of creation itself 'should' have an analogue in the Divine nature).

While this is not a great insight (even if true), it does seem to show forth a certain beauty (which hints that there is some truth in the concept). Not only does such seem to express a rich integration within the Divine nature but it also makes creation (the act and the being) a mysterious and wonderful analogue of the love of God begetting the Son.

Computerized Tickler File

Andy Glew's blog recently presented a link to an article about organization on his personal wiki. This article brought out a few thoughts.

It seems that a computerized Tickler File could organize items so that the ticler alert is triggered at an appropriate time (e.g. during a lunch break).

An even more sophisticated system might use information beyond time of day (e.g., position [seated, standing, walking; workspace, conference room, other's office, hallway, outdoors, restaurant], activity [software application with focus/receiving input; input rate/type; frequency and time of last display update], psychological state [heartbeat pattern, perhaps movement and activity patterns, perhaps information about stress inducing events and healing events]) to trigger notifications (and even time the receipt of messages) to fit one's state.

E.g., the system could exploit 'necessary' context switches caused by delayed responses to inputs as well as introduce productivity enhancing distractions (e.g., perhaps when it appears one is spinning one's wheels working on a problem), well-timed encouragements/refreshments (e.g., a loved one might leave messages of encouragement--like lunchbox notes--which the system could pop up at an appropriate time or a reminder of an upcoming positive event like a work group BS session or one's child's first school play), or even advisory notices (for most people advice has to be carefully presented; rather than "You're getting tired; you should consider taking a break" some might respond better to "Your favorite muffins will be fresh in the cafeteria in five minutes" or "Remember that you wanted to talk with Joe about such and such.").

A human manager cannot afford to be aware of fine-grained conditions (and most people's sense of privacy and self-sufficiency would be violated by such). Even a human 'executive assistant' would not be able to properly support a worker at the granularity that a computer could (and being impersonal, a worker might not have as much concern about privacy--if only the computer knows--or dependence/competence; on the other hand, being corrected by an idiot computer can be more painful/frustrating than being corrected by a semi-competent human being).

In the article, Andy Glew also noted that the artificial size limit of ScanCards was inappropriate for a computer, but it seems to me that sizing can be a disciplining factor to push for concise presentation and might also be useful to present a visual hint of the nature of a note (size of a note and size of font can give clues about complexity, importance, etc.). It might be good to have a standard size note and use hypertext, elision/abbreviation (which can be conditionally unelided/expanded), and font shrinking to include more information.

I am not certain how to handle hypertext display. Endnotes can be frustrating because even with back navigation one can lose one's place in reading; even parenthetical expansion--where one would place a note mark in parentheses and an activation would expand/make visible the note--can interfere with visual orientation because the layout of a paragraph will change (vertical layout changes could be handled with a sidebar that changes color/shade/pattern based on semantic boundaries like sentence starts--interestingly, such a sidebar mechanism might be used to mark content density [side marks have been used to mark importance and other aspects of a text]; such would allow a reader to orient by the sidebar even if insertions moved text).

It is also frustrating that a single mechanism is used to provide notes of different kinds; notes can differ not only in length but also in tightness of the relevance--applies strictly to word, sentence, paragraph or ties to word, sentence, paragraph but applies more generally--, level of knowledge expressed in the note and expected of reader, nature of the note--e.g., a historical note like "this varies from version 2.3 . . ." differs from a warning note like "this is atomic not synchronized" or an explanatory note like "this is a variant of the Smith-Jones algorithm". Sometimes something like "tool tips" might be appropriate (like many browsers handle 'title' elements), possibly activated by a click/press-hold-and-gesture; sometimes a persistent frame--requiring explicit dismissal--might be used; sometimes an insertion into text might be appropriate. (Notes for a Shakespearean play or a poem by Alexander Pope might explain an archaic term or non-obvious allusion, a point of textual analysis, or a reminder of further information being available. Good versions tend to place the first type of note as side notes matched to the line--so they can be easily referenced without disrupting the flow of reading--and the middle kind as foot notes. The last kind of note might be best suited to an end note or be included in an opening or closing commentary.)

It does seem that a dynamic and intelligent display offers significant opportunities for improvement over paper-based information storage and presentation.

A brief introduction

The title of this blog comes from the Peter, Paul and Mary song "Right Field"; it seems a better title than "Just a Technophile" since it is more playful (while still being sufficiently self-deprecating) and recognizes that not all the content will be computer-related (it also provides a better url). The "and other fancy stuff" in the description comes from "Puff the Magic Dragon" (and recognizes that what I am enthusiastic about may be as odd to most people as what a little boy finds 'fancy' compared to an adult--I also thought it somewhat clever!).

The content of this blog is expected to have a heavy emphasis on computer architecture, but I expect to post a few thoughts on Christianity and other topics. I hope to encourage myself to write more freely here than I might on the comp.arch USENET group or the Real World Technologies forum (or elsewhere), particularly in posting raw ideas and, of course, thoughts that would be off-topic in those fora.

[Edit: I forgot to mention that "out of right field" in the description is intentional--not only referring to the song but also indicating that my comments may be even odder than those from "out of left field", perhaps even with a hint that they may sometimes be correct ("right")--"and the baseball falls into my glove".]