5 ms·

Could be far fewer keystrokes with character prediction. First would be 7 instead of 19, ignoring Enter/arrow/mouse clicks.

by gibolt 7y ago

contingencies 7y ago
You could also treat 也 as ; in some other language syntaxes (eg. ruby), so newline could be semi-synonymous, so the use of 也 becomes superfluous unless you are writing one liners. So that's down further to 6 characters. Even if 'f mandelbrot(width,height' was used in an autocompletion IDE, the traditional syntax weighs in at 24 characters or 4x.
thaumasiotes 7y ago
A couple notes on keystrokes: 1. Ignoring prediction, you need more than three keystrokes to type 事 ("shi"). You type the s, the h, and the i, and then you select the character you want from a menu of suggestions. If you're typing a rarer character (which 事 is not), you'll need additional keystrokes to page through the suggestions. 2. If you're serious about minimizing keystrokes, you'd use double pinyin input, not pinyin input. Two keys per syllable; probably three per character since a lot of repetition means the characters you want are likely to be top suggestions.
- contingencies 7y ago
  This is not strictly true. On modern IMEs, usually the first character is enough if the compound you are typing is predictable. Examples: dnxb would input 东南西北. Then there is learning. While on OSX's pinyin input 曼德波 requires mandebo the first time, it then becomes the first result for all subsequent inputs. We may assume that most multi-character function names would quickly benefit from similar prioritization.
  - thaumasiotes 7y ago
    > dnxb would input 东南西北. Yes, that's why I started out by saying "ignoring prediction". However, it's perfectly fair to note that you can and should enter phrases all at once as opposed to one character at a time, which would reduce the double pinyin input from 3 keystrokes per character to two per character plus one per "input unit". > Then there is learning. While on OSX's pinyin input 曼德波 requires mandebo the first time, it then becomes the first result for all subsequent inputs. We may assume that most multi-character function names would quickly benefit from similar prioritization. Yes, I noted this specifically: >> a lot of repetition means the characters you want are likely to be top suggestions
    - contingencies 7y ago
      Apologies I mentally switched off when you mentioned 'double pinyin'. Maybe I use that anyway.
- aasasd 7y ago
  > and then you select the character you want from a menu of suggestions Notably, anything reasonable that lets the user just keep mashing the keys is gonna be faster than selecting stuff on the screen, assuming the user is experienced with typing. Because seeing a wrong predicted character, then looking at the menu, then—crucially—locating the necessary character and then selecting it will be way slower than punching keys in without interaction. Making choices and, separately, selecting stuff on the screen are both slower than just jerking the fingers from muscle memory. More so if the user is a touch-typist. If you know that your ‘事’ is something like ‘shi down-down-enter’, it would still be faster than the same thing with unfamiliar choices in the menu—or if the prediction and the choices change between invocations. Though this handicap would diminish after the choices settle on the user's typical most-used characters and the user in turn gets used to them.

Could be far fewer keystrokes with character prediction. First would be 7 instead of 19, ignoring Enter/arrow/mouse clicks.

by gibolt 7y ago

Could be far fewer keystrokes with character prediction. First would be 7 instead of 19, ignoring Enter/arrow/mouse clicks.

contingencies 7y ago

You could also treat 也 as ; in some other language syntaxes (eg. ruby), so newline could be semi-synonymous, so the use of 也 becomes superfluous unless you are writing one liners. So that's down further to 6 characters. Even if 'f mandelbrot(width,height' was used in an autocompletion IDE, the traditional syntax weighs in at 24 characters or 4x.

thaumasiotes 7y ago

A couple notes on keystrokes: 1. Ignoring prediction, you need more than three keystrokes to type 事 ("shi"). You type the s, the h, and the i, and then you select the character you want from a menu of suggestions. If you're typing a rarer character (which 事 is not), you'll need additional keystrokes to page through the suggestions. 2. If you're serious about minimizing keystrokes, you'd use double pinyin input, not pinyin input. Two keys per syllable; probably three per character since a lot of repetition means the characters you want are likely to be top suggestions.

contingencies 7y ago
This is not strictly true. On modern IMEs, usually the first character is enough if the compound you are typing is predictable. Examples: dnxb would input 东南西北. Then there is learning. While on OSX's pinyin input 曼德波 requires mandebo the first time, it then becomes the first result for all subsequent inputs. We may assume that most multi-character function names would quickly benefit from similar prioritization.
- thaumasiotes 7y ago
  > dnxb would input 东南西北. Yes, that's why I started out by saying "ignoring prediction". However, it's perfectly fair to note that you can and should enter phrases all at once as opposed to one character at a time, which would reduce the double pinyin input from 3 keystrokes per character to two per character plus one per "input unit". > Then there is learning. While on OSX's pinyin input 曼德波 requires mandebo the first time, it then becomes the first result for all subsequent inputs. We may assume that most multi-character function names would quickly benefit from similar prioritization. Yes, I noted this specifically: >> a lot of repetition means the characters you want are likely to be top suggestions
  - contingencies 7y ago
    Apologies I mentally switched off when you mentioned 'double pinyin'. Maybe I use that anyway.
aasasd 7y ago
> and then you select the character you want from a menu of suggestions Notably, anything reasonable that lets the user just keep mashing the keys is gonna be faster than selecting stuff on the screen, assuming the user is experienced with typing. Because seeing a wrong predicted character, then looking at the menu, then—crucially—locating the necessary character and then selecting it will be way slower than punching keys in without interaction. Making choices and, separately, selecting stuff on the screen are both slower than just jerking the fingers from muscle memory. More so if the user is a touch-typist. If you know that your ‘事’ is something like ‘shi down-down-enter’, it would still be faster than the same thing with unfamiliar choices in the menu—or if the prediction and the choices change between invocations. Though this handicap would diminish after the choices settle on the user's typical most-used characters and the user in turn gets used to them.