Guys:
Although my amazement at the utility of TW is refreshed every morning during my devotional, I almost daily get tripped up trying to extend or contract a range of selected text. In almost all GUI text-editing environments for as long as I can remember, users can expand or contract a current selection of text with shift combined with one of four arrow keys. Indeed, I have already used that familiar paradigm in the brief time I have been editing this post. And I am well aware that TW does not support this, but almost every morning (because I have almost always been using a "more standardized" environment earlier), I get tripped up again, and find myself looking up at a different section of the current Bible view (having lost my selection and my focus), rather than a modified selection.
I did find a post from 2009 where this issue was broached, but Costas dismissed the poster's suggestions as next to impossible to implement for a variety of reasons related to long-standing design decisions regarding the UI. I do understand and support Costas' logic, but I think one possibility was overlooked in that thread. So, please consider my suggestion, which I THINK is new, as I will soon be sitting down with my pastor to give him another tutorial on TW, and I don't think he will likely be receptive to technical explanations as to why he is also getting tripped up by this behavioral anomaly in TW's UI.
In the earlier thread regarding this issue, Costas explained that there would be inconsistencies and ambiguities if TW were to be modified to support traditional KB shortcuts for extending/contracting a text selection (given current use of the keys). I do understand this, but I also want to point out a piece of the puzzle that seems not yet to have been addressed. Here is my suggestion:
When viewing a Bible and no text has been selected in the view (even if a recently clicked verse is bracketed and selected for study), allow the arrow keys to behave as they already do (in what I'll call "navigation mode"). However, if there is at least one character currently highlighted (as "selected") in the current view, force TW to switch modes for the arrow keys from "navigation mode" to what I'll call "selection-modification mode," and allow traditional use of arrow keys to expand/contract the current range of selected text until the selection activity is terminated by traditional means (unassisted click or unassisted press of an arrow key).
My rationale is that anyone who has actively selected a range of characters will not likely expect their next shift+right-arrow execution to navigate to a different view. Indeed, even if they had intended to abandon the current selection and navigate to a different view, it will be intuitively obvious what is wrong when they note the highlighted text currently selected - an intuitive tap of any arrow key will deselect the currently selected text and revert TW back to the navigation mode for the arrow keys.
Although the potential cost of implementing this change may seem to far outweigh any benefit, I can assure you that almost all users of TW are frequently tripped up by this problem, unless they are spending most of their editing time during the day in TW rather than traditional editors. And even when I have spent several consecutive hours in TW, I still get tripped up because, as I think I recall Costas having pointed out earlier, some of the views in TW do support the traditional paradigm for KB shortcuts while selecting text, while the Bible view does not.
Another minor distraction related to this is the paradigm established long ago for extending the selection of a double-clicked word by dragging the mouse. If I double-click-and-hold the word "dragging" in the previous sentence, and then drag right, the selection will be extended one word at a time. Is there no way this can be implemented in TW? This traditional selection paradigm is not only absent in Bible view, but seems also absent in all other views I have checked. Like I say, this is a minor distraction compared to the above whine, because I do not lose my focus nor my selection, but simply use my other hand to incorporate the shift key with the mouse activity. But why not also fix this in the same revision?
Thanks guys;
David