The program has already proven itself distrustworthy by showing the inaccurate progress bar and ETA. It needs some way to assure the user that "something is happening" in a way that the user isn't inclined to immediately distrust.
No, it's shown itself to be exactly as trustworthy as every other program on their computer that has shown a progress bar. Users already know well that ETAs are estimations, and that every progress bar they've ever seen has been somewhat inaccurate. Given that users don't see every single program fail all the time on their machine (in fact, most are unlucky if they see 0.01% of them failing) they have no reason to suspect that this one has too.
You claim that showing one known-inaccurate progress bar and one known-inaccurate ETA and requiring the user to plug in or pair a keyboard and open a terminal to see why it's taking so [expletive] long are "better than any of the alternatives." Not everyone agrees with you.
No, I claim that showing a known-inaccurate progress bar and a known-inaccurate ETA is better than showing a known inaccurate progress bar, a known inaccurate ETA, a known inaccurate second progress flickering upwards and downwards, and a load of log file which contains no information that should not be displayed in a better way to the user.
While things are progressing normally, the user should be informed "something is happening", and your best guess of when it will be done. When things go wrong, they should be told about it in a way that's more friendly than "here's a big log". If they really want to see the big log (extremely unlikely), it's still accessible.
But until the program has had a chance to discover what the user "knows very well", the ETA is a lie. So how should the program display an accurate ETA before it has completed enough steps to determine all variables? These include the speed of the primary storage in random writes, B. the speed of the primary storage in sequential writes, C. the speed of the operating system's system-wide configuration repository, and D. the speed of the network? Someone installing software before he has to leave to catch a bus or a flight doesn't want to see the ETA suddenly increase from 5 minutes to 5 hours. Or should the ETA be displayed as "30 seconds + 100 MB download + 100 small files + 100 MB disk + 100 registry entries" until the installer knows how many milliseconds each MB of download, each small file, each MB of disk, and each registry write takes? That's exactly the same as displaying multiple progress bars.
No, the correct solution here is to simply display one progress bar, and one ETA, and let the user continue to stew about how inacurate progress bars are, because it's better than any of the alternatives.
Are you recommending to hide from the user the reason that the printer could not be detected despite the user having told the program that the user had already plugged it in?
No, I'm suggesting that at the point at which the printer was not detected, you have no information more than "uhhh, I couldn't see it on the USB bus", and you present the common options for what's gone wrong. Your log file display is going to provide 0 useful information, because it's simply going to say "uhhh, I couldn't see it on the USB bus".
That depends on the difference between "installation" and "initial configuration". Is a device driver "installed" if no device is connected? Is a program "installed" if it hasn't been able to download essential components through the network? Here, I am including any initial configuration step that does not involve user interaction in installation.
both of these can be solved in far better ways that showing log files to the user. 1) by moving to a screen saying "now plug your device in to complete installation" 2) by popping up an alert saying "hey, no internet connection" or "I can't contact our servers just now" as apropriate.
Consider programs that install by downloading components through the network, programs designed to communicate with a network service, and programs that verify the user's license to execute them through the network. If the server is unreachable, the installation will fail.
Yes, and an alert explaining why it failed is the correct way to handle it, not displaying a log file or multiple progress bars.
If the network is unexpectedly slow, such as 0.05 Mbps dial-up or EDGE where the developer was expecting 5 Mbps cable, the estimation of remaining time will jump around, and the user will be curious as to why.
No they won't –they'll know very well how their network connection tends to behave.
A user who can't easily view why will suspect that the program is hiding something from him.
No they won't – they'll simply think that the program is taking a while to install.
Or consider the installer for a printer driver. If the user hasn't connected the printer, seated the ink cartridges, and inserted paper correctly, initial configuration will fail.
Yes, and a screen will be presented saying "Your printer could not be detected. Please make sure you've plugged in it's USB and power connections" with a nice diagram showing where they need to be plugged in. No log file will be displayed.
No, but software that can't even install without failing is pretty spectacular.
You claim that the availability of logs necessarily induces fear. I'd like to see evidence of this.
Not the availability of logs, the display of logs (even in a semi-hidden way) while performing a task that should silently work every time. It suggests that something is going to go wrong, and you're going to need to read them.
Perhaps it's because I'm a geek, but I disagree that it's a "very rare occurrence".
That sounds like you spend a lot of time using a lot of broken software. I can't honestly remember the last time I had to look at an installation log, or kill an application because a progress bar appeared to have stopped doing anything. I don't think it has anything to do with being a geek,.
Say the progress dialog has a show/hide button [microsoft.com] to show or hide this tail display, placed next to the random number generator labeled "estimate of remaining time". How exactly does removing this show/hide button produce an overwhelming "overall gain in cleanliness and layout of the UI"? What it does is provide an incentive to keep the "estimated remaining time" honest.
It doesn't take much gain in cleanliness to account for the inconvenience of typing tail/var/something.log once every 100,000 installs. For reference, the reason I think the above UI is poor is because users will click it – users who are not geeks and who are not having any installation problems. They will get bored, and push the button, and then a whole bunch of logging will go on. To 99.9% of users (no, not idiots, users who are not geeks) this will simply look like "some linux scrolling by" or "the matrix". Those users will instantly be made fearful of the application, and what it's doing.
This is why logs should be stuck in/var, where they belong, not displayed to the user at all times.
As an app developer for a different, more closed platform, that passes on none of this information, I can say for certain there is one good reason for at least the email information. This information would be extremely useful in stopping people who have pirated your application from using your online services – iOS has no way to determine whether someone has legitimately purchased your app or not.
A few years ago is not now. Try writing a game running in html5 canvas. You'll find roughly:
Chrome's rendering and javascript is plenty fast enough for most stuff.
Safari's rendering an javascript is plenty fast enough for most stuff on Mac OS. On windows, the rendering is dog slow. Firefox's rendering and javascript is mostly fast enough, but can get bogged down.
IE's rendering is blistering fast, but it's javascript is abysmally slow.
Opera's javascript is somewhat slower than Firefox's, but faster than IE's. It's rendering is abysmally slow (even slower than safari on windows).
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? Or a large write vs. a write to a nearly full, overly fragmented file system? Or distinguish an installer that just happens to take a long time on a specific step on a specific machine from a completely frozen installer? There are a lot of things that can interfere with an accurate ETA that the installer won't know about until it gets to that step.
They would debug all these things by opening a terminal, and typing tail/var/something.log. There is no reason to indicate any of them in the actual installer/application. The situations you describe a 0.0001% occurances – stuff that matters nearly never. They should not be shown in a day to day UI, they should be accessible, but require some hoop jumping. The reason you put up with the hoop jumping is because the overall gain in cleanliness and layout of the UI dominates the very rare occurance of wanting to see this information.
Well, because of all the other features. The rendering engine was never a reason to choose opera over them in the first place – it was much slower, especially the javascript engine.
No, no it isn't. A second progress bar flickering up and down all the time tells the user nothing. Just put the one general progress bar there, and you're done.
Bullshit, stop clinging to a delusion spawned from a known bug.
"they" defined "kilo", "mega" and "giga" to mean 10^3, 10^6 and 10^9 long before binary computers even existed. The only reason 2^10, 20 and 30 have ever been used is because a coder working on an ancient system decided that 1 clock cycle for a right shift 10 was better than a few hundred odd clock cycles for a divide by 1000 in software, especially when trying to display the sizes of a good number of files on a system clocked at only a few kilohertz (that's 1000 Hz, not 1024 Hz). They were right at the time to introduce a known bug in order to make the system usable. It's totally wrong now to just compute these values incorrectly, when division can be done in hardware, and we have multi GHz (that's 1,000,000,000Hz) machines.
The typical arguments for using binary units is simply "computers are binary, we should use binary units", which is bullshit for two reasons: 1) Not all computers are or have ever been, or necessarily will be binary. 2) The job of the operating system is to abstract the behaviour of the machine into behaviours users expect. Humans are good (mostly through practice, but still) at thinking in base 10, this makes it the job of the OS to work in the human's base 10 terms.
Why on earth are you building a system with a generation old, overpriced i5? It's like you're *trying* to make intel look expensive. Or just trolling...
Huh? I don't dispute your main point, but where did you pull those $300/$500 figures from?
For an AMD system, at $300, I could get myself something along the lines of an FX 8320, 8-16GB of RAM and a fairly bargain basement (about $60) motherboard. To compete with that with an intel system I'd need an i5 3470, 8-16GB of RAM, and a fairly bargain basement motherboard, which would run me about $260 (mostly because the CPU is $40 cheaper).
As an aside, while the two CPUs are roughly as fast as each other for most tasks, for games, the i5 is actually about 25% faster (http://www.anandtech.com/bench/Product/702?vs=698).
So where's the $500 coming from? As far as I can see, the only way to hit that figure for intel mobo CPU and RAM would be to buy an i7 3770k, and a pretty high end motherboard, which is an awful lot faster than the FX 8320 for everything, let alone games (http://www.anandtech.com/bench/Product/551?vs=698)
IBM, K-Mart, Hechts and Kodak didn't operate in free markets. They operated in regulated markets that enforced the lack of monopolies, along with other things that are detrimental to economic growth that the free market allows.
I don't actually understand why demanding a higher price is necessary. As an example, if I bought a CD for $10 with 15 tracks on it, I'd likely listen to those tracks a good few hundred times. That's a likely 15,000 plays for $10, aka between 0.6 and 0.06 per play. When you consider that only 10% of that is likely to ever see the artist, that's gonna be 0.06-0.006. By that metric, this woman is getting great value from the streaming services compared to me actually buying the music.
Of course there's an element of "the country with the largest army wins" (for a given definition of win), but the idea that these systems are stupid enough to shoot down missiles that aren't going to hit targets is laughable.
Amazing how that works. Company does a bunch of research work, and then says "hey, you can use the research work we did if you pay us". It's almost like the people there are normal human beings who want to live and eat!
I use it day to day. The issue is that if you're running a desktop app on a tablet you have a choice – make the buttons big enough to tap on, but for no content to fit on the screen (because it wasn't designed to run on a tablet), or make content fit on the screen, but the controlls to small to use. By contrast, software actually designed for tablets does not have this problem, because it's UI is laid out in such a way that content is accessible despite big chunky controls. This also does not solve the hovering or right clicking issue.
touchpads
Again, I use one every day. The surface pro does not have one, it has a touch screen. One is available as a $150 optional accessory. If you're going to use it all day with the optional accessory attached then what you have is a screen with a keyboard and touch pad that fold up into it, we have a name for that, a laptop. We can already buy cheaper, lighter, smaller, better ones than the surface pro.
Uh, what? Being able to play Crusader Kings 2 on a tablet is a huge selling point.
Unfortunately... you can't actually play it, because it's designed with a mouse/track pad/track point in mind, not a touch screen. As soon as you want to get your character sheet open, and try to right click on that portrait you're going to realise why this was such a terrible idea.
Slashdot Mirror
The program has already proven itself distrustworthy by showing the inaccurate progress bar and ETA. It needs some way to assure the user that "something is happening" in a way that the user isn't inclined to immediately distrust.
No, it's shown itself to be exactly as trustworthy as every other program on their computer that has shown a progress bar. Users already know well that ETAs are estimations, and that every progress bar they've ever seen has been somewhat inaccurate. Given that users don't see every single program fail all the time on their machine (in fact, most are unlucky if they see 0.01% of them failing) they have no reason to suspect that this one has too.
You claim that showing one known-inaccurate progress bar and one known-inaccurate ETA and requiring the user to plug in or pair a keyboard and open a terminal to see why it's taking so [expletive] long are "better than any of the alternatives." Not everyone agrees with you.
No, I claim that showing a known-inaccurate progress bar and a known-inaccurate ETA is better than showing a known inaccurate progress bar, a known inaccurate ETA, a known inaccurate second progress flickering upwards and downwards, and a load of log file which contains no information that should not be displayed in a better way to the user.
While things are progressing normally, the user should be informed "something is happening", and your best guess of when it will be done. When things go wrong, they should be told about it in a way that's more friendly than "here's a big log". If they really want to see the big log (extremely unlikely), it's still accessible.
But until the program has had a chance to discover what the user "knows very well", the ETA is a lie. So how should the program display an accurate ETA before it has completed enough steps to determine all variables? These include the speed of the primary storage in random writes, B. the speed of the primary storage in sequential writes, C. the speed of the operating system's system-wide configuration repository, and D. the speed of the network? Someone installing software before he has to leave to catch a bus or a flight doesn't want to see the ETA suddenly increase from 5 minutes to 5 hours. Or should the ETA be displayed as "30 seconds + 100 MB download + 100 small files + 100 MB disk + 100 registry entries" until the installer knows how many milliseconds each MB of download, each small file, each MB of disk, and each registry write takes? That's exactly the same as displaying multiple progress bars.
No, the correct solution here is to simply display one progress bar, and one ETA, and let the user continue to stew about how inacurate progress bars are, because it's better than any of the alternatives.
Are you recommending to hide from the user the reason that the printer could not be detected despite the user having told the program that the user had already plugged it in?
No, I'm suggesting that at the point at which the printer was not detected, you have no information more than "uhhh, I couldn't see it on the USB bus", and you present the common options for what's gone wrong. Your log file display is going to provide 0 useful information, because it's simply going to say "uhhh, I couldn't see it on the USB bus".
That depends on the difference between "installation" and "initial configuration". Is a device driver "installed" if no device is connected? Is a program "installed" if it hasn't been able to download essential components through the network? Here, I am including any initial configuration step that does not involve user interaction in installation.
both of these can be solved in far better ways that showing log files to the user.
1) by moving to a screen saying "now plug your device in to complete installation"
2) by popping up an alert saying "hey, no internet connection" or "I can't contact our servers just now" as apropriate.
Consider programs that install by downloading components through the network, programs designed to communicate with a network service, and programs that verify the user's license to execute them through the network. If the server is unreachable, the installation will fail.
Yes, and an alert explaining why it failed is the correct way to handle it, not displaying a log file or multiple progress bars.
If the network is unexpectedly slow, such as 0.05 Mbps dial-up or EDGE where the developer was expecting 5 Mbps cable, the estimation of remaining time will jump around, and the user will be curious as to why.
No they won't –they'll know very well how their network connection tends to behave.
A user who can't easily view why will suspect that the program is hiding something from him.
No they won't – they'll simply think that the program is taking a while to install.
Or consider the installer for a printer driver. If the user hasn't connected the printer, seated the ink cartridges, and inserted paper correctly, initial configuration will fail.
Yes, and a screen will be presented saying "Your printer could not be detected. Please make sure you've plugged in it's USB and power connections" with a nice diagram showing where they need to be plugged in. No log file will be displayed.
No software is shipped perfect.
No, but software that can't even install without failing is pretty spectacular.
You claim that the availability of logs necessarily induces fear. I'd like to see evidence of this.
Not the availability of logs, the display of logs (even in a semi-hidden way) while performing a task that should silently work every time. It suggests that something is going to go wrong, and you're going to need to read them.
Perhaps it's because I'm a geek, but I disagree that it's a "very rare occurrence".
That sounds like you spend a lot of time using a lot of broken software. I can't honestly remember the last time I had to look at an installation log, or kill an application because a progress bar appeared to have stopped doing anything. I don't think it has anything to do with being a geek, .
Say the progress dialog has a show/hide button [microsoft.com] to show or hide this tail display, placed next to the random number generator labeled "estimate of remaining time". How exactly does removing this show/hide button produce an overwhelming "overall gain in cleanliness and layout of the UI"? What it does is provide an incentive to keep the "estimated remaining time" honest.
It doesn't take much gain in cleanliness to account for the inconvenience of typing tail /var/something.log once every 100,000 installs. For reference, the reason I think the above UI is poor is because users will click it – users who are not geeks and who are not having any installation problems. They will get bored, and push the button, and then a whole bunch of logging will go on. To 99.9% of users (no, not idiots, users who are not geeks) this will simply look like "some linux scrolling by" or "the matrix". Those users will instantly be made fearful of the application, and what it's doing.
This is why logs should be stuck in /var, where they belong, not displayed to the user at all times.
As an app developer for a different, more closed platform, that passes on none of this information, I can say for certain there is one good reason for at least the email information. This information would be extremely useful in stopping people who have pirated your application from using your online services – iOS has no way to determine whether someone has legitimately purchased your app or not.
A few years ago is not now. Try writing a game running in html5 canvas. You'll find roughly:
Chrome's rendering and javascript is plenty fast enough for most stuff.
Safari's rendering an javascript is plenty fast enough for most stuff on Mac OS. On windows, the rendering is dog slow.
Firefox's rendering and javascript is mostly fast enough, but can get bogged down.
IE's rendering is blistering fast, but it's javascript is abysmally slow.
Opera's javascript is somewhat slower than Firefox's, but faster than IE's. It's rendering is abysmally slow (even slower than safari on windows).
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? Or a large write vs. a write to a nearly full, overly fragmented file system? Or distinguish an installer that just happens to take a long time on a specific step on a specific machine from a completely frozen installer? There are a lot of things that can interfere with an accurate ETA that the installer won't know about until it gets to that step.
They would debug all these things by opening a terminal, and typing tail /var/something.log. There is no reason to indicate any of them in the actual installer/application. The situations you describe a 0.0001% occurances – stuff that matters nearly never. They should not be shown in a day to day UI, they should be accessible, but require some hoop jumping. The reason you put up with the hoop jumping is because the overall gain in cleanliness and layout of the UI dominates the very rare occurance of wanting to see this information.
Well, because of all the other features. The rendering engine was never a reason to choose opera over them in the first place – it was much slower, especially the javascript engine.
No, no it isn't. A second progress bar flickering up and down all the time tells the user nothing. Just put the one general progress bar there, and you're done.
Bullshit, stop clinging to a delusion spawned from a known bug.
"they" defined "kilo", "mega" and "giga" to mean 10^3, 10^6 and 10^9 long before binary computers even existed. The only reason 2^10, 20 and 30 have ever been used is because a coder working on an ancient system decided that 1 clock cycle for a right shift 10 was better than a few hundred odd clock cycles for a divide by 1000 in software, especially when trying to display the sizes of a good number of files on a system clocked at only a few kilohertz (that's 1000 Hz, not 1024 Hz). They were right at the time to introduce a known bug in order to make the system usable. It's totally wrong now to just compute these values incorrectly, when division can be done in hardware, and we have multi GHz (that's 1,000,000,000Hz) machines.
The typical arguments for using binary units is simply "computers are binary, we should use binary units", which is bullshit for two reasons:
1) Not all computers are or have ever been, or necessarily will be binary.
2) The job of the operating system is to abstract the behaviour of the machine into behaviours users expect. Humans are good (mostly through practice, but still) at thinking in base 10, this makes it the job of the OS to work in the human's base 10 terms.
Why on earth are you building a system with a generation old, overpriced i5? It's like you're *trying* to make intel look expensive. Or just trolling...
You can't buy a faster system for $300. Intel's cheapest quad core is $179.
$149 http://microcenter.com/product/400664/Core_i5_3470_32GHz_LGA_1155_Boxed_Processor
And that's a quad core that's faster than AMD's 8 core FX 8320.
Toss in $100 for the motherboard
Why would you spend $100 on motherboard? You can get perfectly good H77 or B75 boards for $60-80.
$150 for the GPU
Uhh, your assertion was for CPU, motherboard, and RAM, why does the intel system suddenly get a GPU added to it?
Huh? I don't dispute your main point, but where did you pull those $300/$500 figures from?
For an AMD system, at $300, I could get myself something along the lines of an FX 8320, 8-16GB of RAM and a fairly bargain basement (about $60) motherboard.
To compete with that with an intel system I'd need an i5 3470, 8-16GB of RAM, and a fairly bargain basement motherboard, which would run me about $260 (mostly because the CPU is $40 cheaper).
As an aside, while the two CPUs are roughly as fast as each other for most tasks, for games, the i5 is actually about 25% faster (http://www.anandtech.com/bench/Product/702?vs=698).
So where's the $500 coming from? As far as I can see, the only way to hit that figure for intel mobo CPU and RAM would be to buy an i7 3770k, and a pretty high end motherboard, which is an awful lot faster than the FX 8320 for everything, let alone games (http://www.anandtech.com/bench/Product/551?vs=698)
IBM, K-Mart, Hechts and Kodak didn't operate in free markets. They operated in regulated markets that enforced the lack of monopolies, along with other things that are detrimental to economic growth that the free market allows.
Because some countries have more than a couple of hundred years of history. Oddly, it wasn't always a parking lot.
Ugh, Slashdot ate my units. Those 0.6/0.06/0.006 should all be post fixed by a cent symbol.
I don't actually understand why demanding a higher price is necessary. As an example, if I bought a CD for $10 with 15 tracks on it, I'd likely listen to those tracks a good few hundred times. That's a likely 15,000 plays for $10, aka between 0.6 and 0.06 per play. When you consider that only 10% of that is likely to ever see the artist, that's gonna be 0.06-0.006. By that metric, this woman is getting great value from the streaming services compared to me actually buying the music.
Of course there's an element of "the country with the largest army wins" (for a given definition of win), but the idea that these systems are stupid enough to shoot down missiles that aren't going to hit targets is laughable.
No, they won't be famous at all if they're last.
Amazing how that works. Company does a bunch of research work, and then says "hey, you can use the research work we did if you pay us". It's almost like the people there are normal human beings who want to live and eat!
Surface Pro: 64GB/4GB/ivy bridge i5 dual core 1.7Ghz/4 hour battery, $899 + $130 type cover – $1029
MacBook Air 11": 64GB/4GB/ivy bridge i5 dual core 1.7Ghz/5 hour battery, $999
And the MacBook Air is hardly the cheapest ultra book out there ;)
adjustable screen DPI
I use it day to day. The issue is that if you're running a desktop app on a tablet you have a choice – make the buttons big enough to tap on, but for no content to fit on the screen (because it wasn't designed to run on a tablet), or make content fit on the screen, but the controlls to small to use. By contrast, software actually designed for tablets does not have this problem, because it's UI is laid out in such a way that content is accessible despite big chunky controls. This also does not solve the hovering or right clicking issue.
touchpads
Again, I use one every day. The surface pro does not have one, it has a touch screen. One is available as a $150 optional accessory. If you're going to use it all day with the optional accessory attached then what you have is a screen with a keyboard and touch pad that fold up into it, we have a name for that, a laptop. We can already buy cheaper, lighter, smaller, better ones than the surface pro.
Uh, what? Being able to play Crusader Kings 2 on a tablet is a huge selling point.
Unfortunately... you can't actually play it, because it's designed with a mouse/track pad/track point in mind, not a touch screen. As soon as you want to get your character sheet open, and try to right click on that portrait you're going to realise why this was such a terrible idea.