brookhong
Experimental: Hint Groups
This is an experimental feature which enables hints to be batched into groups.
Note: This isn't intended to be merged into master yet (if ever). Any feedback/suggestions are welcome. I'm currently still testing it to see if I prefer it over the default behavior.
Description:
During hint generation, if the desired number of hints exceeds the number of available hint characters, the hints are split into groups of lengths matching the length of available hint characters.
For example, if the string qwerty represents the available hint characters, and we want to create hints for 15 links, we will create 3 groups of hints:
[ ['Q', 'W', 'E', 'R', 'T', 'Y'], ['Q', 'W', 'E', 'R', 'T', 'Y'], ['Q', 'W', 'E'] ]
instead of the default behavior of increasing hint length to 2 characters:
['QQ', 'QW', 'QE', ... etc ]
Next, display the grouped hints to the user such that the active group is signified visually via its opacity - opacity: 1.0 for the active group, and opacity: 0.25 for the inactive groups.
Upon the user pressing the cycle key(s) ('f' to cycle forward, 'F' to cycle backward), the subsequent group is highlighted.
Finally, the user selects the desired hint by pressing the key corresponding to its label.
In contrast to the default behavior, the net effect is a tradeoff between number of unique keypresses, and number of repetitive keypresses of the cycle key.
For example:
Default behavior : fAH -> activate hints, select hint AH
Group behavior: ffC -> activate hints, cycle forward one group, select hint C.
Some possible enhancements I can think of:
-
Different grouping strategies - Currently, hints are simply grouped sequentially with their neighbors. This generally means that hints near the top of the page have a lower group number, and thus appear first in the cycle. Alternative grouping strategies ("collations") may include: alternate, randomize, group by type, and various other heuristic groupings
-
'F' (Shift + 'f') to initialize group cycling in reverse
-
Remember last group number for subsequent hint instances. If total number of hint groups changes, must be able to handle group index overflowing correctly - either wrap to beginning or clamp to end of group list.
-
Restrict total number of hint groups to some maximum number. This may dramatically decrease hint generation time on pages with extreme numbers of links. Only render additional groups upon cycling.
Thanks for putting this together, it’s a nice addition to an already awesome extension. I’ve been using Hint Groups for the last couple of weeks, and I kind of like it. To me, it feels easier and faster to be able to just hit ffffD rather than fADE (for example).
Two pieces of feedback:
-
It would be good to bump up the opacity for inactive groups just a little bit higher, because a) sometimes they’re barely visible at all, b) see feedback 2 :)
-
Possible enhancement - add the group index number to the in-active group hints. Often when cycling to get to the group I want (by smashing fffff) I’ll sometimes overshoot by 1 or 2 groups, and then I have to hit F (shift f) to go back 1 or 2 - so really I end up doing fffff_F_D. If the inactive group hints displayed an index number it would be easier to know how many times I have to hit f to get to the group I want. For example the third inactive group hints from the current (active) hits would display as 3D, implying hit f 3 times to cycle, then D. To be clear, I do not want to have to hit the number 3 on the keyboard, followed by the letter D. I just want the hint to indicate how many times I have to hit f to get to a particular group.
What do you think?
@darlal
Thanks for the feedback!
I like both of your suggestions.
I propose making the inactive hint group opacity user-configurable via e.g. runtime.conf.hintGroupInactiveOpacity, defaulting to maybe 0.35.
And I agree that adding the index before the hint char would be nice. I'll implement those two things when I get a chance :)
Okay, so I just whipped up a quick version of what was suggested.
I first implemented adding the group index after the hint character. I chose to add it after rather than before the hint characters because it seems more readable and easier to determine the hint char at a glance.
I then tried gradually increasing the opacity to see at what point inactive group indices were readable, but by that time it was too hard to distinguish between active and inactive hints.
So, instead, I changed the style of inactive hints to have a gray background the same as text-mode hints. This ensures they are both readable and distinct from active hints.
My reaction to this change is:
First, I think having distinct colors for active/inactive hints is an improvement.
Next, I am not sure how useful having group numbers listed really is.
It still takes my brain a moment to parse and figure out how many times I'll have to press f, especially if I'm not on the first group.
Maybe instead of listing their static group number, it would be more useful to list their current distance? So the next group would be 1, the group after that would be 2; the previous group would be -1, the group before that would be -2; etc. Edit After re-reading @darlal's initial suggestion, it seems this is what they originally suggested. So I'll have a go at it.
This would require a bit more logic to implement.
Again, any feedback is welcome :)
Alright, updated again.
This time I think it works much better, and seems to be what @darlal originally suggested.
Active hints are displayed as before, with just their hint character.
Inactive hints are displayed with only their distance, e.g. for the next hint group, those hints show 1.
This actually seems to work quite well and is pretty intuitive.
Thanks for the PR.
I think this feature may be more useful when there are many hints(label for hints reaches more than 3 letters). For most cases(label of hints less than 3 letters), it's better to label hints directly without grouping.
@b0o Thanks, the update is working quite nice! and yes, showing the "distance" from the current active group is what I originally meant.
I agree that having distinct colors for active/inactive hints is an improvement, and looks pretty nice.
Question: an inactive group now shows the only the distance from the current group and switches to showing the hint character once it becomes active (which is definitely an improvement). Can you talk a bit about the rational for not showing both the distance and hint character for the inactive groups e.g "D3"? You mentioned the readability aspect, just curious if there's more to it than that.
@brookhong Perhaps ungrouped and grouped hints don't need to be exclusive options, maybe we could have an "automatic grouping" option. In automatic mode, hint labels at/below a certain threshold would be ungrouped, above the threshold it would use grouped automatically (I personally would set that threshold to 2). Just throwing out ideas :) thought..?
@brookhong
Thank you for the super detailed review! I will go through and fix the issues you mentioned.
@darlal
I tested displaying both group number + hint char ("D3" or "3D") for inactive groups, but I felt it just cluttered the interface and made things harder to read. Having just the number makes it really quick to determine how to navigate to a certain group, in my opinion. This could potentially be made a configurable option if you think it would be useful.
Regarding only showing hint groups when there are lots of hints, I somewhat agree.
For me, personally, I like the fact that I'll only ever need to enter a single hint character after cycling through with f. It seems to take less of my attention away from my current task to navigate this way. I think it really comes down to personal preference.
A threshold may be a nice compromise. I'll take a stab at it and see how well it works.
@b0o Thanks for the additional detail. If it's all the same to you and you don't mind putting in a config option, I would use that option. Either way though, Hint Groups is going to be my default. Hopefully it gets merged in. Thanks!