Improved keyboard usability

[Frenzie]

• Enter loads the first result
• Up and down arrows focus links in the result list

---

This change is 

[itkach]

instead of passing key event into doLookup return deferred and add callback to it, otherwise doLookup gains new responsibility that has nothing to do with doing lokup

[Frenzie]

Something like this?

[itkach]

Something like this?

Sort of, but then all returns in doLookup need to return deferred, otherwise empty input results in error

Uncaught TypeError: Cannot read property 'done' of undefined
    at script.js:162

But perhaps Enter shouldn't wait for doLookup to finish and instead be similar to what you have for down key - the only difference being that Enter would leave focus in the input field.

Another thing I noticed in your version clearing input no longer clears the content. I think it should. While you're at it, Escape would be a useful shortcut to clear and focus word input field.

[Frenzie]

But perhaps Enter shouldn't wait for doLookup to finish and instead be similar to what you have for down key - the only difference being that Enter would leave focus in the input field.

But then there's either nothing to activate, or worse, the old top result. Typing lookupWord … wait, wait, wait … Enter defeats the entire purpose. I didn't just randomly decide to make that part of the code weirdly convoluted. ;-)

Btw, everything feels a lot spiffier when you reduce the timeout to, say, 100ms (which would also slightly alleviate missed Enter problems as a side effect, but the deferred solution is much, much better).

Another thing I noticed in your version clearing input no longer clears the content. I think it should.

Oh, I thought that was unintentional. I find it rather disorienting and it's downward counterproductive if you want to look up something in a currently open article.

While you're at it, Escape would be a useful shortcut to clear and focus word input field.

Cheers.

[itkach]

But then there's either nothing to activate, or worse, the old top result.

You can make the same argument about your down key handling.

Typing lookupWord … wait, wait, wait …

Don't exaggerate. You don't "wait, wait, wait". You just wait :)

Enter defeats the entire purpose

Then I don't understand what is the purpose of this. If the purpose is to break the wait and force it to do lookup - it doesn't do that. It actually cancels previously scheduled lookup, makes you wait for debounce delay from the beginning and lookup to finish and then selects first result for you.

Btw, everything feels a lot spiffier when you reduce the timeout to, say, 100ms

The purpose is to avoid lookup on every keystroke while user is still typing. What the delay should be is subjective of course, but 100ms seems a bit too short to me.

Oh, I thought that was unintentional. I find it rather disorienting and it's downward counterproductive if you want to look up something in a currently open article.

I don't see it that way. If you want to look up something in currently open article you click a link or copy text and paste it into input field. You can also open result links from the list or article list in a new tab if you want to keep them around. Leaving content behind when you clear input feels like app forgot to clean up after itself.

[Frenzie]

You can make the same argument about your down key handling.

That's a valid concern. I admit I hadn't considered the possibility to lookupWord, ArrowDown because it doesn't really make much sense to me. I mean, why go ArrowDown, Enter when you can just Enter. But if you have two dictionaries it's conceivable that you already know you'll need to press ArrowDown, ArrowDown, Enter to get to the first result of the second dictionary. It'll work now.

Then I don't understand what is the purpose of this […] selects first result for you.

That's the purpose. You type something and you press enter because you want to open the first result instead of being forced to grab the mouse. You make a very good point that it'd be better if Enter triggered an immediate lookup, but that doesn't change the fact that the lookup + DOM change take time and you don't want to perform any follow-up actions until that's been done. :-)

I also realized that there should be a var previousLookup to prevent a double roundtrip. If you press Enter or ArrowDown and the results have already been loaded it should just open the first article.

The purpose is to avoid lookup on every keystroke while user is still typing. What the delay should be is subjective of course, but 100ms seems a bit too short to me.

Hence why I said 100ms rather than keypress. ;-) 100ms feels about right to me because that way it rarely if ever triggers while you're typing without feeling overly slow. Anyway, that's besides the point except that I would in fact like to reduce it. Even 250 or 300ms feels significantly less laggy. :-) Interestingly, on Android I barely even notice the 600ms, but I suppose it takes almost that long to even just hide the touch keyboard.

I don't see it that way. If you want to look up something in currently open article you click a link or copy text and paste it into input field. You can also open result links from the list or article list in a new tab if you want to keep them around. Leaving content behind when you clear input feels like app forgot to clean up after itself.

I completely agree about the search results (I forgot to clear them on Escape), but I think emptying the open article is a bit as if my browser killed this very page I'm typing this in just because I decided to alter something in the addressbar. It shouldn't do that until I press Enter or click something in the dropdown. Anyway, I'll change that back if you don't like it, but I really don't think the article you're viewing should be closed except through an explicit user action. For example by pressing Escape on the article, which would then empty out everything and focus the search bar.

I pushed a new commit that I think addresses the functionality concerns, but I certainly understand if you're not quite happy about some of the code repetition yet. ;-)

[Frenzie]

Hm, I thought of another thing that would improve my experience.

Press right arrow while a result is selected → focus article (as opposed to Enter which just loads it)
Press left article while focus is on article → return focus to results list (without clearing the open article whistles)

Pushed a demo implementation.

[itkach]

Press left article while focus is on article → return focus to results list (without clearing the open article whistles)

This doesn't work well with horizontal scrolling, which shows up some in articles with long math formulas or wide tables: right arrow scrolls, but left arrow doesn't, move focus instead.

Horizontal scroll doesn't happen in word list, but loosing focus on right arrow is still rather unexpected.

emptying the open article is a bit as if my browser killed this very page I'm typing this in just because I decided to alter something in the addressbar

word input is not exactly browser address bar

if you don't like it,

I don't like it

but I really don't think the article you're viewing should be closed except through an explicit user action.

Clearing word input is explicit user action

[itkach]

$lookupResult is already jQuery object, no need to wrap it in $()

[Frenzie]

This doesn't work well with horizontal scrolling, which shows up some in articles with long math formulas or wide tables: right arrow scrolls, but left arrow doesn't, move focus instead.

Fixed, good catch.

word input is not exactly browser address bar

That's just an example that was close at hand. None of my desktop dictionary or dictionary-type applications clear the article just because you clear the search input. However, several of them replace what you're looking at by automatically opening the top result of what you're typing, which I think is the right approach. As in, either you leave the previous result, or you replace it with the current result. Blank in that scenario only (potentially) applies in case of blank input. To some software blank means opening the letter A, which does have a real paper dictionary-like charm to it. :-P

[Frenzie]

The web-based Van Dale professional doesn't clear anything either if you empty out the search or explicitly click the little cross. The Oxford English Dictionary doesn't either, but it's a lot more awkward to use. They didn't implement up and down arrow actions.

[Frenzie]

Oh, I forgot to check Antidote. It's a lot like the Van Dale online interface. :-)

[itkach]

url query parameters are for server, application state artifacts have no business being exposed like this

[Frenzie]

Do you mean you'd like to (ab)use the hash instead or that you are against the very concept? Because I think passing a search query directly is must-have functionality (and besides it's conceptually a server parameter hijacked by JS ;-P) and I have some application-state related suggestions that I think would seriously improve usability. Much more so than this silly clear or not clear stuff, although I'd love to sneak that setting in there as well. :-)

[Frenzie]

Anyway, I stripped out the stuff that's unrelated to the title of this PR and rebased it.