|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
|
|
hints_auto_exit_delay defaultHi all,
In hinting mode, where dom nodes like links are annotated with visible numbers (hints), and you are prompted to either type a number or substrings of link text, Conkeror is able to automatically select an element when the hints list has been narrowed down to a single possible match. How quickly it automatically selects this single match, thus exiting the hints mode interaction, is controlled by the variable hints_auto_exit_delay. The default is 500 milliseconds. If you set it to 0, that means it will never automatically select a match, and you must always hit return. Recently I was teaching someone about the hinting system, and how you can select a link by typing a substring of link text. The person said that they never used that feature because Conkeror would behave unpredictably if they either made a typo or typed too many characters. In the first instance, Conkeror might automatically follow the wrong link without the user realizing what they did wrong. In the second instance, Conkeror might automatically follow the right link, but the user could still typing because they were not being careful enough, and their extra keystrokes would run unintended commands. I think this person made a very good point. The default behavior should not put the user in the position of having to react to UI events that they did not intend to happen. We strive for Conkeror to have a "proactive" user interface, rather than a "reactive" one. Therefore I propose that the default value of hints_auto_exit_delay be changed to 0, so that by default, the user always has to hit return to end a hints interaction, and Conkeror's behavior with respect to this mode be 100% predictable and dependable. Shall I make this change? Thoughts? -- John Foerch _______________________________________________ Conkeror mailing list Conkeror@... https://www.mozdev.org/mailman/listinfo/conkeror |
|
|
Re: hints_auto_exit_delay default [SEC=UNCLASSIFIED]> I think this person made a very good point. The default behavior should
> not put the user in the position of having to react to UI events that they > did not intend to happen. We strive for Conkeror to have a "proactive" > user interface, rather than a "reactive" one. Therefore I propose that > the default value of hints_auto_exit_delay be changed to 0, so that by > default, the user always has to hit return to end a hints interaction, and > Conkeror's behavior with respect to this mode be 100% predictable and > dependable. > > Shall I make this change? Thoughts? I have hints_auto_exit_delay set to zero because I, too, find the auto behaviour to be unpredictable. There was peripheral comment on this in http://thread.gmane.org/gmane.comp.mozilla.conkeror/1184 regards, David. -- IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. _______________________________________________ Conkeror mailing list Conkeror@... https://www.mozdev.org/mailman/listinfo/conkeror |
|
|
Re: hints_auto_exit_delay default"John J. Foerch" <jjfoerch@...> writes:
> Shall I make this change? Thoughts? I must say, I've been using Conkeror with the default setting ever since this behavior was added, and I've never had a link be inadvertently followed due to this issue. Certainly, if there were no delay, it would be a problem. Note that as long as the user is still typing, the timeout will keep being reset and a link will not be followed, even if the matches had already been narrowed down to only one. This is done precisely to prevent unintended commands being executed. I think the issue is no so much what the default is but rather that people are unaware of exactly how the system works. In particular, you have to make sure not to pause too long if you make a mistake in typing before hitting backspace. I think it may require some adapting to learn how to use the system, and in particular it may be hard to adapt without actually understanding how it works, but overall following links automatically leads to a more efficient user interface, I think. For some people that prefer to type slower, simply setting the delay higher may work well (or disabling the auto following completely). I do generally agree that it is problematic when the effect of a key command is non-deterministic from the user's point of view, due to the possibility of some event occurring in between key strokes and causing the focus/context to change. The main case where this occurs in Conkeror is with the download prompt, but usually it is expected when it comes up, so it is not as much of an issue as it might otherwise be. I don't view the hints system as such a case, though; ruling out what the hints system does would essentially mean ruling out any "dynamic" (meaning time-dependent) behavior in user interfaces. I agree that there are some advantages to purely "static" user interfaces, but "dynamics" also can allow things to be more efficient, so in the end it is a tradeoff. -- Jeremy Maitin-Shepard _______________________________________________ Conkeror mailing list Conkeror@... https://www.mozdev.org/mailman/listinfo/conkeror |
|
|
|
|
|
Re: hints_auto_exit_delay defaultOn Thu, Oct 29, 2009 at 04:14:05PM -0700, Jeremy Maitin-Shepard wrote:
> I think the issue is no so much what the default is but rather that > people are unaware of exactly how the system works. In particular, you > have to make sure not to pause too long if you make a mistake in typing > before hitting backspace. I think it may require some adapting to learn > how to use the system, and in particular it may be hard to adapt without > actually understanding how it works, but overall following links > automatically leads to a more efficient user interface, I think. For > some people that prefer to type slower, simply setting the delay higher > may work well (or disabling the auto following completely). > > I do generally agree that it is problematic when the effect of a key > command is non-deterministic from the user's point of view, due to the > possibility of some event occurring in between key strokes and causing > the focus/context to change. The main case where this occurs in > Conkeror is with the download prompt, but usually it is expected when it > comes up, so it is not as much of an issue as it might otherwise be. > > I don't view the hints system as such a case, though; ruling out what > the hints system does would essentially mean ruling out any "dynamic" > (meaning time-dependent) behavior in user interfaces. I agree that > there are some advantages to purely "static" user interfaces, but > "dynamics" also can allow things to be more efficient, so in the end it > is a tradeoff. Hi Jeremy, long time no see! I'm willing to make the case of the newbie here because it involves perhaps the most important and commonly used subsystem for all Conkeror users, regardless of their level of expertise, typing speed, browsing style, or what they want out of the program. We all need to be able to follow links with the keyboard. It does speak to the heart of the matter to say that people are unaware of exactly how the system works. Yet for such a basic and essential subsystem, should we expect them to? I would propose that changing the default to 0 would eliminate the need for the average user to learn exactly how the system works in order to use it at a basic level, and also to be confident in it as a dependable "black box". Apart from this feature, operating the hinting system is fairly obvious to anyone with any computer experience. We're all accustomed to hitting return at prompts in all variety of other softwares, so there will be no surprise there for anyone. For the person who wants no more out of Conkeror, they can just use it. Those of us who understand how it works don't mind putting a line in our config and forgetting about it, but those that don't will have their lives interrupted to "fix" it. Configuration should be about making the good better, not about making the [perceived] bad tolerable. Since hitting return at prompts is second nature to most of us, I don't think I am out on a limb to call it the base case in this situation. But just because something is the base case does not necessarily make it the best default. Speaking in generic terms, "Feature X" might be a better default, even though it has a steeper learning curve. To decide that matter, I would frame it with the following question: Can it be assumed that, despite a steeper learning curve, using Feature X is in all reasonable cases the preferable and obvious goal for the skilled user? Well, you know my answer to that one. :) Based not only on my own preference but also based on preferences of people I have talked to, such as the one that got me thinking about this again. Auto-selection is definitely more efficient for some people, but not everybody weighs the trade-off the same. Oh, I almost forgot a very important case. When a person is choosing a link via link text instead of via numbers, they may not have seen the link before starting the hints interaction, and they may need a chance to abort with C-g if an undesired link comes up instead of what they expected. "Typing blind" and seeing what comes up is also an efficiency gain, but doing so does not play nice with a timed-autoselect, and that is the main reason I turn off the feature in my own config. -- John Foerch _______________________________________________ Conkeror mailing list Conkeror@... https://www.mozdev.org/mailman/listinfo/conkeror |
|
|
|
|
|
|
|
|
Re: hints_auto_exit_delay defaultHi all,
I made this change today, so the new default value of hints_auto_exit_delay is now 0. To get back the old behavior, put the following in your rc: (and adjust the number to your preference) hints_auto_exit_delay = 500; You might also like to try setting an auto-exit when there is more than one possible match in the hints interaction: hints_ambiguous_auto_exit_delay = 500; Since this is a very popular feature, I think it's important to make sure that it is documented prominently so that new users know of its availability. The first thing I've done to that end is to put an example config of the most common simple settings in contrib/config/common.js, with a link on the wiki at <http://conkeror.org/ExampleConfigs>. If anybody has any creative ideas for other ways to advertise this and other of Conkeror's cool features, let me know. -- John Foerch _______________________________________________ Conkeror mailing list Conkeror@... https://www.mozdev.org/mailman/listinfo/conkeror |
| Free embeddable forum powered by Nabble | Forum Help |