File: XTree:\Forum archive |Bottom_of_page

| View Thread | Return to Index | Read Prev Msg | Read Next Msg |

XTree Forum archive

Re: Shift-Letter / Spell Mode Comparison - RESPONSE

Posted By: Walter Rassbach <>
Date: Saturday, 12 September 1998, at 3:16 a.m.

In Response To: Re: Shift-Letter / Spell Mode Comparison (John Gruener)

This posting is intended to be a response to the "underlying content" of John's comparison rather than to "minor" features (although this or that may not seem minor to different people...), which I think both of us agree can, for the most part, probably be provided in either proposal.

In fact, I am only going to cover part of the "territory", mainly from a "global" or philisophical viewpoint of what/why we are trying to accomplish with these proposed enhancements and why I think what I have proposed satifies them somewhat better, PLUS a couple of clarifications to comparison points I think are not quite right. This does NOT mean that I don't see and appreciate the things John is trying to accomplish as well, just that I see or weigh the tradeoffs differently.

THE MAIN REASON why this is going to be abbreviated is that John has managed to pull off one of those rare and enviable synergies where the "whole is greater than the sum of its parts" (and, from at least my [fairly heavy] experience in these areas, it RARELY occurs in this kind of design ideation -- 'tis a shining example to all of us John). As a result of thinking about what John has proposed, his comparison, and my response to it, I had a SECOND flash and think I have a way of integrating BOTH together almost seemlessly (for, I hope, very little extra effort on Kim's part) and thereby cover both sets of concerns, desires, different preferences, etc. It will take me a couple of days to get it properly written up and posted here (I will probably be somewhat precise/pendantic/etc. again), so please be patient while I get it out... In addition, the top of this thread is getting old and deep, so I will post the new integrated proposal separately, with a reference to this thread at the top of the new one.

First, from my viewpoint (and I started using XTree a LONG time ago), the history of "this" feature (i.e., what I call "navigation") is as follows:

1) In the original versions of XTree, people did not have that many files on their disks (this is back when 10MB was a BIG disk -- files [especially .EXEs] were smaller too, but...), and simple cursor movements (arrows, PgUp/PgDn, etc.) were more than adequate to get around efficiently. Scroll lists of files were at most 100-200 files an one had maybe 20-40 directories.

2) As hard disk sizes hit 50-90 MB, the number of directories hit 100-150 and a large file scroll list might be 500-1000 files (in addition, having TWO or more disks or partitions became more comon). At this point, having only the simple cursor movements started to awkward and insufficient, and the shift-letter/numeric "quick jump" feature was added to XTree (I think that TreeSpec was added at about the same time...).

3) Unfortunately, as disks went through the next growth stage (the 200-300 MB sizes), XTree was no longer being updated or enhanced. Various people had asked for some kind of enhancement of the shift-letter features, but no one was there to enhance XTree (Symantec's loss...).

4) Today, with ZTree and 10+ GB disks and 1-8 GB partitions, cursor movements and the shift-letter features are no longer adequate to get around efficiently in file lists which commonly have 15,000 files or more and directory structures of 300-500+ directories on a single disk. Kim has been spending his time doing a bang-up job of getting the basic functionality of the old XTree translated to the Windows usages, implemented using the API, and stable, but has NOT had time to think about or attempt to implement any enhancements like the ones we are talking about here. However, it is now "steam engine time", and what we are looking for is the right kind of enhancements to make it easy and efficient to get around in file lists that are an order of magnitude larger than anything XTree was designed for (I never could manage more than about 6-7000 files in XTree).

This brings us to my take on what I think we are trying to accomplish here. It is clear that shift-letter (there may be 1000+ files with a name starting with 'N') and cursor keys (one tends to hold them to get fast repetition and then have to correct overshoot) are inadequate. Using the FileSpec feature just to LOCATE files is very awkward (it was NOT intended for that anyway...) and ineffecient. What we need to do is to find an enhancement which is EASY TO USE, EFFICIENT (both in terms of locating files AND in terms of keystrokes), FAST (again, keystrokes), and USEFUL (i.e., it does the job we want it to do and maybe some extra, nice and useful, bells & whistles).

The "job" (functionality) we are trying to do (in my view) is to LOCATE files in a FAST and EFFICIENT (emphasis on keystrokes expended) manner in the large scroll lists of files we now have. I am placing the emphasis on File/B/G/S lists since the available tools for dealing with the directory tree are fairly good (i.e., TreeSpec, F5/F6, +/-/*, cursor, shift-letter, partial logging, etc.) -- some enhancements would be nice but are much less crucial than enhancements for locating files in File/B/G/S lists, and the carry-over from whatever we come up with for file lists should be adequate...

As a consequence of my take on this "job", I would expect that the navigation strings are SHORT, i.e., the user is only going to enter a few characters and will stop as soon as the highlight bar selects the file he is looking for... In addition, we need a way to specify navigation using the extension part of the filename since that is quite often one of the more efficient ways of locating a file. This implies that there is an emphasis on characters which appear AT THE FRONT of a filename or in an extension.

In addition, whatever we come up with MUST "fit" into the current overall design and paradigm of ZTree, i.e., it must be a "natural" enhancement. We cannot "rip out" and replace very much or change the definition of keys in common usage (maybe one or two at most and if that, under control of a configuration option). Moreover, it should be EASY for the average user to learn, both new users and people who have been using XTree/ZTree for a long time...

Now, a couple of "corrections" to (i.e., MY take on) some of John's comparison and advantage/disadvantage points, plus some elaboration and counter points:

> -WR-> Spell with Shift-Letters, Numbers and all legal special
> characters except Period, Comma and Space, (and Plus and Minus unless
> configuration option is set).
> -JG-> Spell with any legal characters, including Unshifted
> letters, Period, Comma, Plus, Minus and Space without needing an
> option to disable the main Plus and Minus keys or to add Ins/Del
> key functions.

In a File/B/G/S window, Plus and Minus (and Equals) ARE available without a configuration option. Any configuration option would ONLY affect usage of those characters in the directory/tree/point-to windows. I don't think that these characters are very common in directory names (certainly, not near the FRONT of the name).

Even with the configuration option ON, the Plus and Minus on the numeric pad still do the log/release functions, and having the main keyboard +/- do navigation is actually more consistent with the Windows/Explorer paradigm (in Explorer they ARE navigation keys, only the numeric pad +/- perform the expand/collapse functions).

I do not see that the inability to specify Period (an EMBEDDED ONE, NOT the file extension separator!!), Comma, or Space is that great a loss since those characters are seldom used near the FRONT of a file or directory name (remember, I would not normally expect a nav.string to be more than 3-5 characters...).

I also do not see that enabling the INS/DEL keys to do log/release is a big deal, those keys are currently unused (except for an /XT option), are, in fact, used for exactly these functions when the /XT command line option is specified, and this is a fairly obvious usage for those keys...

> -WR-> Use Colon to toggle to extensions, (since the Shift
> key is probably being held down).
> -JG-> Use BackSlash or ForwardSlash, or both, to toggle
> to extensions, (since the Shift key is probably not being held down).

Having the shift key down is not really a "reason" for selecting colon, but the use of colon is, in practice, quite convenient since the user probably does happen to have the shift key held down. I agree with John that a FowardSlash may be better in the "spell mode paradigm" (I DON'T like backslash). With a little usage/practice those two choices are fairly close in terms of conveniece/usability/naturalness/etc. athough I feel that a colon may be a hair easier/more natural...

> -WR-> Use Double Quotes to recall the last spelled name
> from the Initial State or the Spell mode.
> -JG-> Use an Up/Down key to recall a history list of the
> last spelled names, or the F3 key to recall the most recent spelled
> name, from the Spell mode only.

John misses one point here... The double-quote usage is instant, one keystroke to recall AND "execute" while his method requires a '|', and UP, and TWO [enter]s or a '|', F3, and [enter]. I find both of those sequences awkward.

Moreover, I think John may not visualize the use of double-quote in quite the same way as I do... I see the user hitting shift-C, shift-L, and then double-quote a few times to locate a file, WITH INSTANT VISUAL FEEDBACK at EVERY keystroke. If he hasn't found the file yet, he might hit shift-O to narrow the navigation and then double-quote a few more times... With John's paradigm, one has to enter a "spell string" (guessing how many characters are adequate to narrow the search) and then TAB (or maybe PgDn) a couple of times, and it is somewhat more difficult to extend the string and narrow the search criteria. My guess is that we could find ways to make John's method less awkward here (and provide visual feedback), but it is ALWAYS going to be awkward to move one's hand from the main keyboard to hit (say) PgDn and then back to extend the string with an "O'...

As I said in the "FEATURES" part of the response, a way to provide a "history" can be found (in fact, that is the point I plan to use to integrate the two!), BUT, because I expect the nav.strings to be short, I think re-entry of the nav.string is probably a better option anyway... Same number of actual keystrokes (since one doesn't have to type in the '|', up arrows or [enter]s), instant visual feedback, and less of a break in the "stream of thought" since one doesn't have to (!pre-)decide that the string is in the history, look at a history list and select, etc.

> -WR-> Use Double Quotes in all windows to navigate to the
> next name meeting the spelling and enter/remain in the Spell mode.
> Also use the Tab/Shift-Tab, in the File windows only, (except the
> F8-Split mode), to navigate to the next/previous name meeting the
> spelling, but exit to the Initial state.
> -JG-> Use the PageUp/PageDown keys in all windows, (including
> the F8-Split mode), to navigate to the next/previous name meeting
> the spelling and remain in the Spell mode.

I now think that shift-TAB in a file window should act like double-quote and enter/remain in navigation mode. Also, shift-TAB should ALWAYS be available in a file window, even in F8-split mode (a key redefinition, but I would guess that no one uses shift-TAB to switch sides, they just use TAB...).

Using TAB in a file window is just an "obvious" usage and not really necessary... I was precise about differentiating the usage of TAB and double-quote JUST to make them slightly more useful.

In a directory window, remember that navigation "wraps around" to the top when it falls off the bottom, so a backwards repeat is not as crucial -- Just hit the double-quote and eventually you are there, and, with only a couple of characters speciified there are probably only a few candidate directories anyway... Moreover, TreeSpec is available as well (ASIDE: I can see that a way of switching into navigation/spell inside a TreeSpec prompt might be nice and will include a suggestion for it in the integrated proposal [to be written]).

> -WR-> Use the F4 key to reduce the display to those matching
> the spelling, (questionable, since this is another "command"
> key).
> -JG-> Use the F4 key to reduce the display to those matching
> the spelling, (not questionable, since we're in a dedicated Spell
> mode).

I actually don't think re-defining F4 is questionable, It was defined the way it is as an access feature to allow for one finger (or stylus-in-mouth) usage of XTree. Windows already provides a uniform solution to that problem which I expect that anyone who needs it uses and even they no longer need or use F4.

Moreover, John's method requires entry into "spell mode" to make this feature accessible while, in my method, it is available at ANY time...

> -WR-> No method to get immediately to the first/last name
> meeting the spelling.
> -JG-> Use the Ctrl-Home/Ctrl-End keys to get immediately
> to the first/last name meeting the spelling in the current sort
> order.

As I suggest in the "FEATURES" response, just use the same keys...

> -WR-> Has no "text entry" field.
> -JG-> Has "text entry" field, (just like the "\"
> function in the directory window), but with edit capabilities.

A solution was provided in the "FEATURES" response (one I actually like better than a "text entry" prompt/field!!). In the integrated proposal [to be written], this issue is handled in an even nicer way...

> -WR-> No ability to edit the entered spelling.
> -JG-> Ability to use Left/Right, Ctrl-Left/Ctrl-Right, Home/End,
> Backspace/Delete, and Insert keys to edit the spelling.

Again, I expect SHORT strings, and editing is not that much of an issue (although providing something for typos [e.g., backspace] would be nice -- again, see the FEATURES response...).

In addition, full editting of the string (anything other than backspace and maybe ctrl-backspace) makes any form of instant visual feedback significantly harder, and I think that the instant visual feedback, ON EACH KEYSTROKE, is one of the more important features... The handling here corresponds to the handling of TreeSpec, where the display changes instantly as the user enters characters, and you will note that the TreeSpec prompt also does not allow any kind of "editting" other than backspace and ctrl-backspace for exactly this reason, i.e., visual feedback is HARD or impossible (e.g., how do you handle a case where the user cursors into the middle of the path string and starts inserting or deleting characters and, for a while, does NOT HAVE a valid path since he has to type in 2 or more characters to change one valid path into another...)...

> -WR-Advantages->
> 1. Easier to enter the Spell mode, by one keystroke.
> 2. Easier to recall the previous spelling, by two keystrokes.

My counts are a bit different, as follows (common cases):

Entry&Exit/WR: Shift, letter, letter, and no "exit", just do what you went there for...
Entry&Exit/JG: Shift, '|', letter, letter, [enter]

Recall&Execute/WR: Shift, double-quote (with instant visual feedback, easy repetition, no "exit", etc.)
Recall&Execute/JG: Shift, '|', Up, [enter], [enter] {Alternative, F3 in place of Up and one [enter]}

Since I (at least), find a shift, '|' sequence somewhat more awkward than a shifted-letter (I have a LOT of "practice" hitting capitalized letters, much less for '|'), I would put the entry&exit difference at 2.5 keystrokes, i.e., John's sequence is twice as long as mine. For the repeat, I expect to get a lot of practice with double-quote (and I am anyway since I do use it more often), and would put the difference at maybe 3.25-3.5 keystrokes.

We could argue fractions forever, but the real telling point is, I think, that my method will get used a lot and become even faster while John's will always remain more awkward.

In addition, I want to empasize the instant visual feedback aspects and the easy repetition via double-quote...

> 3. Can find the next name meeting the spelling directly from
> the Initial state.
> 4. A true "extension" of the current find-name-by-first-character
> function.
> 5. The "|" key remains open for other future functions.
> 6. Easier to program.

> -JG-Advantages->
> 1. All legal characters can be used to spell, including the
> commonly used Space and Period.

I disagree with "common" -- we are talking about a few of the leading characters in a filename and Space/Period/Comma are not common in the first 3-5 characters in filenames (remember, this is not the "extension period", it is a period embedded in the name part, i.e., a name with TWO periods...).

In addition, I am looking more for "fast" than for "absolutely complete"...

> 2. No need to go through Shift-Letter, Unshift-Number, Shift-Letter
> combinations.

Doesn't seem to me to be an issue at all, I find such sequences VERY natural since I do it in programming, shift-letter is a (from my point of view) a single keystroke as is a numeric, so the shift/un-shift/shift is automatic...

> 3. Less likely to accidently exit back to the initial state,
> (by pressing an unshifted letter or cursor key).

Agreed... (covered better in the integrated proposal to come...)

> 4. Ability to save/recall history of commonly searched-for
> spellings.

As I said above, I don't find re-entry a problem since it is about the same number of actual keystrokes as recalling something from a history and requires less of a break in thought stream.

> 5. Ability to get to the next file/directory with the same
> (unshifted) keys in all windows.

Huh? Is this the +/-/= "issue"? If so, see item (1)

> 6. Fully functional in the F8-Split mode.

Minor. Only TAB is lost in a file window (and double-quote is available -- the actual difference between the two in minor). In a directory window, repetition is MUCH less critical...

> 7. Ability to navigate directly to the first/last name that
> meets the spelling.

Gone, same extension in my proposal.

> 8. Ability to navigate forward, backward, to beginning and
> end of names meeting the spelling without exiting back to the initial
> state.

Changing shift-TAB definition covers this. Ctrl-PgUp/PgDn can be defined to be "neutral" as to state...

> 9. Ability to see the current specification for the spelling
> as you enter it, including the current placement of the cursor when
> toggling to the extension and back to the name.

Covered in the FEATURES response.

> 10. Ability to edit the spelling with various edit keys.

Yes, but this conflicts with "instant visual feedback"...

> 11. No configuration options are necessary.

Maybe

> 12. No (optional) loss of functionality of the current main
> Plus and Minus keys.

Again, only in a directory window...

> 13. Maintains the current find-name-by-first-character function
> without modification.

Hmmm... I'm not sure this is real -- the only gain might be in Kim's programming, the actual functionality is still available... Also, how often do you actually use a shift-letter followed by shift-different-letter sequence now?? If you do anything else in the middle, you are back to nav.start state, and if it is the same letter, a double-quote will soon become automatic...

SUMMARY: I actually see John's proposal as more of a variant (albeit useful) of FileSpec rather than an enhancement of the shift-letter paradigm. I think both are useful (and will soon provide an integrated proposal) but they are really targetting somewhat different things... I am looking for a really fast way to get to where I am going, WITH visual feedback, while I think John is looking more for something like FileSpec but without quite the same characteristics and feels that complete coverage and history are more important than I do. My guess is that the pivot point is thinking about how long the actual strings will be in practice...

-- Walter

Messages in This Thread

| View Thread | Return to Index | Read Prev Msg | Read Next Msg |

XTree Forum archive is maintained by Mathias Winkler with WebBBS 3.21.

 
---<>---
 
Xtree and XtreeGold are registered trademarks of Symantec Inc.
Other brands and products are trademarks of their respective holders.


FILE COMMANDS:  Directory_view Previous_file   Next_file cuRrent   /Help |Top_of_page