No, they said "worked out," as in drove it around and counted the laps (which you can see in the show).
No, "worked out" means "calculated". It does not mean "tested". At no point did the car run out of charge.
Do you seriously think that all these reputable reviewers are actively conspiring against Tesla (on two separate continents, no less)
"All these". You mean 2. Made five years apart. About two completely different models. No they are not conspiring. They are two completely separate dishonest reviews.
And they aren't "against Tesla" per se. They couldn't care less about Tesla.They are both made by people that are on record as opposing fossil fuel alternatives, and that make their money from being sensationalist journalists. Those are there motives. It's hardly surprising there are two, separated by a continent and 5 years.
The fact that it wasn't judged to be libellous doesn't mean it wasn't intentionally deceptive. It certainly was intentionally deceptive. They showed a picture of it being stationary at the side of the middle of the course with commentary "Although Tesla say it will do 200 miles we have worked out that on our track it will run out after just 55 miles and if it does run out, it is not a quick job to charge it up again,". And then they showed it being pushed back into the hangar. Yet at no point did the car actually run out of charge. An honest depiction would have shown it driven back into the hangar.
The bullshit here is yours "crazyjj". You have some sort of axe to grind that means you have no respect for the facts. Much as Top Gear and the NYT journalist do.
So how should the end user distinguish a step that's doing something that inherently takes a long time, such as a large transfer through the network, from something that's taking far longer than it should, such as a transfer through the network running at an unexpectedly low throughput or unexpectedly high latency?
And there we get to the point of the story. By providing a decent progress bar. One that fulfils it's two requirements. 1) To reassure users that progress is being made. 2) To give the user some feel for how long until the process will be finished.
The ideal for an installer is a progress bar that steps forward in reasonably small increments. And an ETA or Time remaining display. The user will be reassured that the install hasn't frozen so long as the continue to get progress and/or ETAs. Even if the ETAs are increasing rather than decreasing because of the slowdowns you mention, they will still be reassured that the process hasn't frozen.
An ETA doesn't need to be accurate. It's an estimate. It only needs to fulfil the two requirements I mentioned. And if you know it's rarely going to be a good estimate, then it's best to make it a time remaining display.
For example (a bit off, but here we go), the EU hires people (professional troll's) to make positive comments on the EU on fora that are 'critical' about that institution.
Why would the user have to Google anything? I can't remember the last time an installer failed for anything other than out of disk space and the network failing. Either of which just requires a simple error message, not the perusal of log files. Have you got used to an OS where installations fail and users have to debug them?
Ron Paul went to WIPO to assert ownership over something that the law says he owns. WIPO is the legal authority that makes this determination. Libertarians have no problem with people asserting property rights. Even if Ron Paul believed that this property right or this particular legal authority shouldn't exist, as long as it does, it's the proper place to assert his rights.
Libertarians have no problem being hypocrites.
Just because you have completely wrong ideas of what libertarianism is about doesn't make him a hypocrite. And I suggest you look up "eminent domain" if you don't want to keep sounding like a complete moron.
I suggest you look up libertarianism if you don't want to look like a retard.
I do hope this is a joke, because these look like entries to the UI Hall of Shame. #2 is particularly amusing. As if a set of 3 nested progress bars wasn't bad enough, there are 2 cancel buttons.
Then what is it measuring a percentage of? Bytes? Files? Steps? Arbitrary chunks defined by nothing more than where you happened to drop progress bar updates in your code?
If you don't say what it's measuring, don't be surprised when the user makes a reasonable guess. Then gets pissed off because your unlabelled bar is poor at living up to it.
Reminds me of the old "Time and Motion" studies. Where someone performing a multi-step task is watched by a man with a clipboard and a stopwatch.
And funnily enough, that gives the answer to your question when applied to computing tasks. Measure the tasks on a typical machine, and use that to form the initial ETA. Then recalculate the ETA all the way depending on whether this machine is going faster or slower than the reference machine.
After hundreds of comments here saying that good progress bars are impossible, it'll be funny if Apple's cracked it, and next week everyone here claims their solution was obvious.
Yeah, but that's complicated and scary. Everyone knows that for consumer products, the best thing to do is hide as much info from the user... excuse me, person... as possible. At least, that's what the focus group said.
No, that is what the usability testing would say. And if you think that usability testing makes a UI worse, then you're a fucking idiot, who should never be allowed anywhere near UIs.
Sounded good for a moment. Then I thought about it.
When the spinner freezes, the user thinks it's stopped working, and kills it and retries. When in reality there was just a particular work unit that took longer than the watchdog timeout.
I'm pretty sure users would panic faster with a frozen spinner than they would panic with a progress bar that wasn't moving.
Horses for courses. A spinner is fine for an operation that takes a few seconds. For sure, for longer operations a user needs more assurance that progress is actually being made.
And see what Gnome has become for where your approach takes you.
I wouldn't know. I used to try Linux once per year to find out if it was ready for the prime time yet. Different distros each time. They all made me cringe at the amateur and inconsistent UIs. Eventually I gave up. It wasn't getting significantly better.
Whether or not they can do anything, and regardless if they ask anyone for assistance, just seeing a detail of "copying file foo..." can help alleviate their short-term frustration.
If the user initiated a user file copy operation then there's nothing wrong with displaying that message. It's an understandable affirmative message that reassures that the computer is doing what was asked of it.
If however it's something like an installer, then there is no useful information conveyed by the message "Copying file: discombobulator.spn". It's useless clutter and shouldn't be there. Progress should be indicated only by things which are fully understandable by a typical user. Progress bars, spinners or ETAs for example.
There is no overlap between libertarian and green. Green is an altruistic philosophy, libertarian is a selfish one. If there's ever any overlap in policy between the two it's purely coincidence.
What you are describing is stuff to go into log files. Not stuff to go into the UI.
Or would you prefer to solve this by giving one manufacturer a monopoly in order to limit the variety of end users' hardware?
The users hardware is irrelevant. Variety makes the job of estimating remaining time harder, but it makes no difference to what constitutes good UI design.
No. You're assuming all users are idiots and ALWAYS uninterested.
No, I have a very realistic view of what users are like. And it doesn't involve the term "idiots" for those who aren't tech experts or enthusiasts. It's bad UI design to add clutter because some geeks might be interested on what's going on under the hood. That's designing for yourself and other programmers, not for users.
The simple solution is make the dialog expandable to hide/show the lower bar.
No, because you are still cluttering the UI unnecessarily. Good design is finding what you can reasonably remove, not hiding things you're too attached to as a programmer. See Vuze preferences for where that approach gets you.
Due to the variable nature of the end-user system components, ETAs will end up with something like this: http://xkcd.com/612/
Only if you're a lazy programmer (or not given the time to do it right by management.)
No he isn't wrong. Just because the Amiga did something does not mean it's a good UI.
When the top bar filled the job was done.
That's the only part of the UI that is significant for the user. The rest is clutter. As a geek you might be interested in the fact that the system is on the step "discombobulating splines", and has done 34% of that sub task. A real user isn't. (S)he just wan't to know how long till the entire task will be done.
If a progress bar that only ever moves forward, and does so reasonably often is impossible, because the size of the complete task is not known in advance, then an ETA display is better. Get rid of the progress bar.
That's ugly and meaningless for the user. All it does is make the developer feel OK that he's progressing some sort of progress bar when he didn't know how big the total task was when he started.
What is the problem you're trying to solve here? Expressed in user needs?
1) To reassure them something is happening, and the long running task hasn't frozen. 2) To give them some idea of how long till the task finishes.
Your solution solves part 1. But then so does a spinner. It does not do any better at part 2 than a single progress bar does.
A single progress bar is fine when the total size of the task is known in advance, and it's steps are reasonably similar in size, such that the scale of the progress bar is fixed, the bar always advances forwards, and it advances reasonably often.
If that can't be managed because the size of the task isn't known in advance, and a progress bar would sometimes go backwards, then a better solution is an ETA. People know what an ETA means for a journey, and are aware that the ETA can get bigger if unexpected hold ups are experienced.
Where estimating time is beyond the developers ability, the best that can be done is an "X steps of Y" display, where the Y can increase.
Ah, OK. It has a different meaning that it does in the UK then. In the UK Social Security is a means tested benefit, and it doesn't rely on having first paid enough in.
Slashdot Mirror
No, they said "worked out," as in drove it around and counted the laps (which you can see in the show).
No, "worked out" means "calculated". It does not mean "tested". At no point did the car run out of charge.
Do you seriously think that all these reputable reviewers are actively conspiring against Tesla (on two separate continents, no less)
"All these". You mean 2. Made five years apart. About two completely different models. No they are not conspiring. They are two completely separate dishonest reviews.
And they aren't "against Tesla" per se. They couldn't care less about Tesla.They are both made by people that are on record as opposing fossil fuel alternatives, and that make their money from being sensationalist journalists. Those are there motives. It's hardly surprising there are two, separated by a continent and 5 years.
The fact that it wasn't judged to be libellous doesn't mean it wasn't intentionally deceptive. It certainly was intentionally deceptive. They showed a picture of it being stationary at the side of the middle of the course with commentary "Although Tesla say it will do 200 miles we have worked out that on our track it will run out after just 55 miles and if it does run out, it is not a quick job to charge it up again,". And then they showed it being pushed back into the hangar. Yet at no point did the car actually run out of charge. An honest depiction would have shown it driven back into the hangar.
The bullshit here is yours "crazyjj". You have some sort of axe to grind that means you have no respect for the facts. Much as Top Gear and the NYT journalist do.
So how should the end user distinguish a step that's doing something that inherently takes a long time, such as a large transfer through the network, from something that's taking far longer than it should, such as a transfer through the network running at an unexpectedly low throughput or unexpectedly high latency?
And there we get to the point of the story. By providing a decent progress bar. One that fulfils it's two requirements.
1) To reassure users that progress is being made.
2) To give the user some feel for how long until the process will be finished.
The ideal for an installer is a progress bar that steps forward in reasonably small increments. And an ETA or Time remaining display. The user will be reassured that the install hasn't frozen so long as the continue to get progress and/or ETAs. Even if the ETAs are increasing rather than decreasing because of the slowdowns you mention, they will still be reassured that the process hasn't frozen.
An ETA doesn't need to be accurate. It's an estimate. It only needs to fulfil the two requirements I mentioned. And if you know it's rarely going to be a good estimate, then it's best to make it a time remaining display.
UKIP's village idiot as interviewed on Russia Today! Ah ha ha ha ha ha. Thanks for that. Couldn't have made my point better myself.
For example (a bit off, but here we go), the EU hires people (professional troll's) to make positive comments on the EU on fora that are 'critical' about that institution.
Evidence, or you're wearing a tin-foil hat.
Why would the user have to Google anything? I can't remember the last time an installer failed for anything other than out of disk space and the network failing. Either of which just requires a simple error message, not the perusal of log files. Have you got used to an OS where installations fail and users have to debug them?
Ron Paul went to WIPO to assert ownership over something that the law says he owns. WIPO is the legal authority that makes this determination. Libertarians have no problem with people asserting property rights. Even if Ron Paul believed that this property right or this particular legal authority shouldn't exist, as long as it does, it's the proper place to assert his rights.
Libertarians have no problem being hypocrites.
Just because you have completely wrong ideas of what libertarianism is about doesn't make him a hypocrite. And I suggest you look up "eminent domain" if you don't want to keep sounding like a complete moron.
I suggest you look up libertarianism if you don't want to look like a retard.
I do hope this is a joke, because these look like entries to the UI Hall of Shame. #2 is particularly amusing. As if a set of 3 nested progress bars wasn't bad enough, there are 2 cancel buttons.
Then what is it measuring a percentage of?
Bytes?
Files?
Steps?
Arbitrary chunks defined by nothing more than where you happened to drop progress bar updates in your code?
If you don't say what it's measuring, don't be surprised when the user makes a reasonable guess. Then gets pissed off because your unlabelled bar is poor at living up to it.
How to do an accurate progess bar ?
Reminds me of the old "Time and Motion" studies. Where someone performing a multi-step task is watched by a man with a clipboard and a stopwatch.
And funnily enough, that gives the answer to your question when applied to computing tasks. Measure the tasks on a typical machine, and use that to form the initial ETA. Then recalculate the ETA all the way depending on whether this machine is going faster or slower than the reference machine.
CPU usage is not the bottleneck for file transfers. Your sensation of speed up is imaginary.
After hundreds of comments here saying that good progress bars are impossible, it'll be funny if Apple's cracked it, and next week everyone here claims their solution was obvious.
Yeah, but that's complicated and scary. Everyone knows that for consumer products, the best thing to do is hide as much info from the user... excuse me, person... as possible. At least, that's what the focus group said.
No, that is what the usability testing would say. And if you think that usability testing makes a UI worse, then you're a fucking idiot, who should never be allowed anywhere near UIs.
Horrible. If it's only on servers, then OK. But I hope this abomination isn't on client Windows.
Sounded good for a moment. Then I thought about it.
When the spinner freezes, the user thinks it's stopped working, and kills it and retries. When in reality there was just a particular work unit that took longer than the watchdog timeout.
I'm pretty sure users would panic faster with a frozen spinner than they would panic with a progress bar that wasn't moving.
Horses for courses. A spinner is fine for an operation that takes a few seconds. For sure, for longer operations a user needs more assurance that progress is actually being made.
And see what Gnome has become for where your approach takes you.
I wouldn't know. I used to try Linux once per year to find out if it was ready for the prime time yet. Different distros each time. They all made me cringe at the amateur and inconsistent UIs. Eventually I gave up. It wasn't getting significantly better.
Whether or not they can do anything, and regardless if they ask anyone for assistance, just seeing a detail of "copying file foo..." can help alleviate their short-term frustration.
If the user initiated a user file copy operation then there's nothing wrong with displaying that message. It's an understandable affirmative message that reassures that the computer is doing what was asked of it.
If however it's something like an installer, then there is no useful information conveyed by the message "Copying file: discombobulator.spn". It's useless clutter and shouldn't be there. Progress should be indicated only by things which are fully understandable by a typical user. Progress bars, spinners or ETAs for example.
There is no overlap between libertarian and green. Green is an altruistic philosophy, libertarian is a selfish one. If there's ever any overlap in policy between the two it's purely coincidence.
What you are describing is stuff to go into log files. Not stuff to go into the UI.
Or would you prefer to solve this by giving one manufacturer a monopoly in order to limit the variety of end users' hardware?
The users hardware is irrelevant. Variety makes the job of estimating remaining time harder, but it makes no difference to what constitutes good UI design.
No. You're assuming all users are idiots and ALWAYS uninterested.
No, I have a very realistic view of what users are like. And it doesn't involve the term "idiots" for those who aren't tech experts or enthusiasts. It's bad UI design to add clutter because some geeks might be interested on what's going on under the hood. That's designing for yourself and other programmers, not for users.
The simple solution is make the dialog expandable to hide/show the lower bar.
No, because you are still cluttering the UI unnecessarily. Good design is finding what you can reasonably remove, not hiding things you're too attached to as a programmer. See Vuze preferences for where that approach gets you.
Due to the variable nature of the end-user system components, ETAs will end up with something like this: http://xkcd.com/612/
Only if you're a lazy programmer (or not given the time to do it right by management.)
No he isn't wrong. Just because the Amiga did something does not mean it's a good UI.
When the top bar filled the job was done.
That's the only part of the UI that is significant for the user. The rest is clutter. As a geek you might be interested in the fact that the system is on the step "discombobulating splines", and has done 34% of that sub task. A real user isn't. (S)he just wan't to know how long till the entire task will be done.
If a progress bar that only ever moves forward, and does so reasonably often is impossible, because the size of the complete task is not known in advance, then an ETA display is better. Get rid of the progress bar.
You're lucky to have someone at work to let you know when you made a bad UI decision.
That's ugly and meaningless for the user. All it does is make the developer feel OK that he's progressing some sort of progress bar when he didn't know how big the total task was when he started.
What is the problem you're trying to solve here? Expressed in user needs?
1) To reassure them something is happening, and the long running task hasn't frozen.
2) To give them some idea of how long till the task finishes.
Your solution solves part 1. But then so does a spinner.
It does not do any better at part 2 than a single progress bar does.
A single progress bar is fine when the total size of the task is known in advance, and it's steps are reasonably similar in size, such that the scale of the progress bar is fixed, the bar always advances forwards, and it advances reasonably often.
If that can't be managed because the size of the task isn't known in advance, and a progress bar would sometimes go backwards, then a better solution is an ETA. People know what an ETA means for a journey, and are aware that the ETA can get bigger if unexpected hold ups are experienced.
Where estimating time is beyond the developers ability, the best that can be done is an "X steps of Y" display, where the Y can increase.
Best set of policies I've ever seen from an American President. Hope he manages to get some of them through.
Ah, OK. It has a different meaning that it does in the UK then. In the UK Social Security is a means tested benefit, and it doesn't rely on having first paid enough in.