← Back to context

Comment by markcerqueira

7 years ago

> Couldn't you have give also vague, but accurate information as well?

Could you give me an example of what you consider "vague, but accurate information?"

The article's discussion about the NYT election accuracy meter wiggling randomly (but within the error bars) is a textbook example of "vague but accurate" information, perhaps to a fault.

How do you visually represent "error bars" to someone who's not technical enough to have ever seen them? Not everyone takes college stats, math, and engineering.

Technically, wiggling within the error bars is a precise way of saying "the precise location is vague -- it's somewhere within this range", in that at any moment it is showing one precise, acceptable guess.

The most fascinating piece there was that as the error bars decreased, the range of the wiggling decreased as well.

Yeah, it doesn't convey the extend of the error bars instantaneously -- you need to stare at it over time -- but it does convey the idea of error bars.

I think the people upset about the error wiggle are either a) being pedantic that it's not visualized in the way they learned it should be visualized back in college; or b) they haven't accepted the idea that sometimes we don't have an exact precise black-and-white answer (we DO have ways to precisely quantify the degree of our uncertainty though).

All of this not to say it was the best execution... perhaps if they 'ghosted' previous needle positions like how old movie radars ghost a green blip as the thingie spins around, maybe it would have been a kind of hybrid approach where the error bars do kinda appear in the overlapping ghosting shadows but still change over time...

"reticulating splines"

I guess the lesson to be learnt here is that people are more understanding if you appear to be transparent but you don't have to ACTUALLY be transparent to get the affect.

Connecting

Fetching data

Processing query

Preparing for display

  • This, yes. Also, if you're processing discrete items in any measurable way (downloading kilobytes, ingesting database rows, querying servers...) that takes longer than one second flat, display that to users. "Processing record 1/1,000,000... Processing record 2/1,000,000..." gives a positive sense of progress. Even if you don't actually know the final total in advance, you should still display whatever you've got.

    As a bonus, this can occasionally be useful for bug squashing. "I've been waiting for hours and it's only up to row 5681" when you know for a fact that there's <2000 rows is a lot more informative than "My report won't finish."

  • Most of those steps will go immediately, and one of them has the same problem the original issue had: it’ll sit on it for ages...

    • A few of the default Debian packages give feedback messages like "This could take a long time..."

      Most of them used to take a long time, but hardware has caught up. SSH key generation, locale installation. Instead, it's a warning that briefly appears on modern systems, but is visible for quite a while on, say, a Raspberry Pi.

    • I designed and maintain a report-generating component and my system does the same thing. (Plus it is helpful as users can tell me where in the process it failed/hung) It doesn't matter how long each message sits on the screen, as long as it changes every so often. Animated, infinite progress bars also help if you don't/can't estimate ETA

      2 replies →

    • Can it not say "$X items processed..." or have a spinner that updates it's frame at certain intervals? It doesn't have to be a percent, just proof of progress. I had no trouble adding an accurate "$X rows of csv processed" in a laravel (PHP) + VueJS app.

    • I know this won't work everywhere, but if you know how much time the task generally takes, your progress bar can just be a timer for that duration. Still more informative than fake messages.