> Is there a reason why that text needs to be sent before the user clicks the "translate" button?

Yes - UX latency. I would expect this kind of thing to take a few thousand milliseconds, and shaving off a few hundred milliseconds from between when the user highlights text and when they select "translate" is significant. The fact that this data is being sent to Wikipedia of all places further signals that the usage is likely to be innocuous.

Do I think that this is globally a good design decision? No, for both engineering and privacy reasons. There's definitely no good reason why it should be sent to Amazon at all.

> There's definitely no good reason why it should be sent to Amazon at all.

I was wracking my brain on this, and all I could come up with was "to independently verify the invoicing for Bing translations" and "how many times are people accessing the definition/translation and not highlighting". So, analytics, not something that explicitly benefits the user.

Can we stop pretending that analytics don't explicitly benefit the user? Product Engineering organizations rely on analytics to improve user experiences.

Analytics can be done less granularly and still benefit the user. Also, surely not every data point collected is used to benefit the user.

For example, Amazon doesn't need to know where I am when I request a definition or translation. If they're concerned about usage, they only need to know how many times I actually used one or both of those features per day, per week, or month. They don't need to know instantly every single time a word is highlighted.

> Analytics can be done less granularly and still benefit the user. Also, surely not every data point collected is used to benefit the user.

How? For all we know, it isn't granular - it might be aggregated at the server level to hide specific user's actions. But they'd still need to be sending in the data from the device to the server.

The device could keep a daily count of interesting actions, and sync that to analytics servers on a daily or weekly basis. That preserves 95% of legitimate use cases while leaking much less private data (like how my reading habits are distributed across the day)

I mean, you're still collecting most of the problematic data. And you might legitimately be interested in what you're leaving out - knowing time of day that people do things is actually important for plenty of use cases.

They can but they're often much more than that.

Also it should really be opt in. Our at least opt out. I hate Amazon looking over my shoulder while reading a book.

That's why I don't use their reading app and use a custom OS.

The word choice we want here is directly vs. indirectly.

I'm surprised you'd say that. Out of interest, how does analytics help websites not use blathery, unhelpful text in overly-small fonts, done too-pale to make them unreadable. A lot of UI failings are of this most basic kind.

When you play an online slot game where you bet money that some numbers will appear on screen, and they use analytics to "improve user experience" (read: engagement, read: you losing more money), is that benefiting you or is it benefiting them?

Kindle devices have a dictionary on device. By looking into which words are most frequently defined, they can add these to the local dictionary to help improve the speed of the UI.

The screen refresh rate on these devices is measured in seconds, so a few hundred millis of network latency is impossible to display.

This isn't universally true - Dan Luu's computer latency page[1] lists three Kindles, all below 900 ms of latency. And, since some devices have latency as low as 570 ms, it makes sense that they would use this optimization.

[1] https://danluu.com/input-lag/

have you actually used a kindle? it certainly doens't take seconds for the definitions to pop up. a full-page refresh might take a second, but most page turns or UI interactions are partial draws and are much faster.

I suspect that they were overstating a limitation of these devices rather than speaking from inexperience. While it has been years since I've used a Kindle, I do use Kobo devices and the delays are perceptible. While changing a page may be quite quick, user interface elements (such as a box containing a definition) seem to take longer. I suspect that they have to be more agressive when refreshing the screen before and after these user interface elements are displayed in order to make the ghosting less perceptible.

If you want to see what I mean by the ghosting of user interface elements being more perceptible, try using KOReader. The ghosting after using a menu can be quite noticable (at least on Kobo devices, which are based on the same technology).

You're exaggerating how slow the screens are.

And the fact that the screens are slow should be motivation to make the rest of the system as responsive as possible. A good software engineer will work around bottlenecks, not shrug their shoulders and introduce new ones.

Also remember that "Kindle" can refer to an app on your phone or desktop computer, all of which may share code related to highlighting and translating.

That doesn’t seem right. Let’s consider the screen refresh to be like a subway station, where the train shows up every few seconds. We need the text we want to show to the user to be at the stop waiting when the train arrives. If we miss the train, we need to wait for the next train to get our text on the screen. The network latency delays when we show up to wait at the station.

If the refresh rate is 5 seconds, and the network response time is 500ms, than eliminating the 500ms response time means we are 10% less likely to miss the train. On average, the time for the text to appear on the screen decreases by 500ms.

All this assumes the refreshes happening on a static schedule. If the software can trigger the refresh, then it’s a lot simpler. The 500ms improvement in latency would apply equally to every engagement with the translate feature.

There's no static schedule. It's an e-ink display. Refreshes happen when software tells it to display something new and take several hundred millis per blank - and a screen can be up to three blanks (because if it doesn't go white-black-display, then some pixels get stuck "on" or "off" or "halfway").

In that case, it’s clear that eliminating the network request before triggering the refresh directly reduces the amount of time the user has to wait to see the result.

There isn't a "translate button" - the selection of the word i the button for define/translate/wiki. You swipe between the three cards.

I like this, as a user. I don't want MORE buttons to tap through when I'm trying to define or translate a word. Especially since the Kindle eink screen and UI is not the most responsive.

This is literally my #1 used feature of my Kindle. I read texts in different languages to have a quick access to single-tap translations.

If it took 2 taps, I would switch platforms.

On the iOS app it all appears instantly-ish when I highlight, so I'm guessing it's just the same codebase.