General takeaways:
- Don't store all your data in a single giant tower blocking out the sun
- The most interesting details are buried at the lowest level
- Robots aren't good for much more than handjobs
Friday, August 18, 2017
Metropolis (2001) Review
An excellent example of programming gone wrong, with detailed visuals.
General takeaways:
General takeaways:
Monday, July 10, 2017
Tools for fools
In project management there's this idea of "fast, good, cheap; pick two":
https://en.wikipedia.org/wiki/
But project management triangles like these, for software, are almost always a lie; what works is requirements planning. So I'll list the requirements for a make-like tool:
https://en.wikipedia.org/wiki/
But project management triangles like these, for software, are almost always a lie; what works is requirements planning. So I'll list the requirements for a make-like tool:
- sandboxed / traced model of task execution, capturing dependencies (file I/O, subprocess creation, etc.)
- database (store) of recorded execution traces for each task
- unique stable identifiers for tasks, so you can build subsets of them and modify the task graph from the command line (like --touch and make a.o b.o)
- scheduler, buffering up file changes etc. and deciding which tasks to run when (ideally with the usual enhancements: multicore/multithreaded, perhaps distributed across a build farm)
Thursday, June 1, 2017
The Progress UI Anti-Pattern
Lots of software these days displays progress indicators: spinning hourglasses, bouncing balls, whirling windmills, or cataclysm countdowns. It is well-known in the UI world that animated progress bars improve perceived user experience. Holding the software constant, if nothing is displayed during an ongoing task, the user will lose interest in it and begin to wonder if the computer is frozen. Whereas, if a spinner is displayed, the user will stay within the interface and not complain about it. Finally, when the progress bar has pulsating ribbing moving backwards, time appears to move faster.
What is less well-known is the mechanism for this. As usual in neuroscience there is still no conclusive theory of the perception of time, but instead some competing theories and interesting experiments. In this study they suggest that their rats use head behavior as timing; basically, the rats started a dance, and compared the ending of the stimulus with where they were in the dance. In this paper we see that training can create reasonably accurate neural signals corresponding to interval timing tasks, but that the mechanism for these is still unknown. Finally in this paper we observe multiple timing mechanisms in use in humans; widespread counting mechanisms, a comparison system in "the temporal semantic system", and a switch in collation mechanisms between the default-mode network and the the motor network around 2 seconds. The motor network is active for durations in the hundreds of milliseconds, firing at 30-40 Hz, while the default-mode network is active for longer durations (above 2 seconds), firing at 10 Hz.
So, we can confirm the 1-second flow rule; after 1 second (closer to 1.5 according to experiment), the default-mode network gets activated and the user loses engagement with the task.
But the 10 second rule is pretty arbitrary, and the decision to use progress as the indicator even more so. Following Edward Tuft's simple proviso of "maximize the data-ink", we can create guidelines. For an indeterminate progress indicator, only the state is actual data, and the rest of the animation can be removed. A simple state indicator such as color suffices. I have been testing this myself for the past few years using my Static Throbber theme in Firefox. I can report that I now hate seeing the animated throbbers on other browsers; they just look tacky.
So, this works for short indicators, less than ten seconds. But, sometimes we have longer things. For example, while I was writing the last sentence, Firefox froze for 20 seconds, because of some JavaScript in a background tab. Well... that still doesn't count. The window manager can give Firefox in a "non-responding" window decoration, and since progress is indeterminate that's really all that can be done. (And for the case that the window manager freezes... that's why I have it displaying a clock with second-level precision, so as to see if it's still progressing. If the clock stops ticking, it's time for a reboot). Alright. So 20 seconds is too short to start thinking about estimating progress; how long do we have to go? I would guess the 5-minute range; after that, it's long enough to start thinking about switching tasks and doing smallish routines such as preparing meals.
For estimated times, the only useful data is the time to completion, e.g. 24 minutes. But this changes frequently; a better idea for long-style progress indicators is to display the time of completion, e.g. that it will finish at 3:00 PM today. Calendars are better than ETA's because they let us plan in advance and think about all of life's routines as opposed to the task at hand. There's some debate over whether a clock time is shorter. In practice, estimates will be inexact, and you'll need a confidence interval. So far I haven't seen anybody implement progress estimation using anything approaching statistics... It's really the only way to display time; the progress bar is useless, because it only shows how much time the user has sunk in already. Even in an early study on progress bars, the suggestion is made to display a simple time estimate instead of a progress bar.
Technology hijacks people's minds; is watching a progress bar tick really the best use of their time? Optimizing for software satisfaction leads to hidden costs in other areas of life.
Corroborating evidence comes from a study of keyboard vs mouse: the mouse was easy to use and was objectively faster, but, due to its low cerebral engagement, was rated poorly by users. On the other hand, the keyboard required remembering complex shortcuts, which took significant cognitive processing. But this time was ignored in subjective evaluations, resulting in users thinking that the keyboard was faster. User satisfaction would be optimized by keyboards. But user productivity would be optimized by mice. But, only in the short term; more recent studies suggest that, with experience, keyboard shortcuts are faster than the mouse. So the choice is best phrased as an investment decision: spend more time now for a better memory later, or walk away quickly and cut your losses.
Obviously, if the software will take several days to complete, it is pretty much impossible to remain engaged and you should always switch tasks. Similarly if it's below the threshold 0.1 seconds then maintaining flow is paramount. But in between, we enter a much more complex world than a simple progress indicator. Questions like: How should users spend their attention? Is frequent task-switching a good idea?
Model for why spinners reduce attention span:
What is less well-known is the mechanism for this. As usual in neuroscience there is still no conclusive theory of the perception of time, but instead some competing theories and interesting experiments. In this study they suggest that their rats use head behavior as timing; basically, the rats started a dance, and compared the ending of the stimulus with where they were in the dance. In this paper we see that training can create reasonably accurate neural signals corresponding to interval timing tasks, but that the mechanism for these is still unknown. Finally in this paper we observe multiple timing mechanisms in use in humans; widespread counting mechanisms, a comparison system in "the temporal semantic system", and a switch in collation mechanisms between the default-mode network and the the motor network around 2 seconds. The motor network is active for durations in the hundreds of milliseconds, firing at 30-40 Hz, while the default-mode network is active for longer durations (above 2 seconds), firing at 10 Hz.
So, we can confirm the 1-second flow rule; after 1 second (closer to 1.5 according to experiment), the default-mode network gets activated and the user loses engagement with the task.
But the 10 second rule is pretty arbitrary, and the decision to use progress as the indicator even more so. Following Edward Tuft's simple proviso of "maximize the data-ink", we can create guidelines. For an indeterminate progress indicator, only the state is actual data, and the rest of the animation can be removed. A simple state indicator such as color suffices. I have been testing this myself for the past few years using my Static Throbber theme in Firefox. I can report that I now hate seeing the animated throbbers on other browsers; they just look tacky.
So, this works for short indicators, less than ten seconds. But, sometimes we have longer things. For example, while I was writing the last sentence, Firefox froze for 20 seconds, because of some JavaScript in a background tab. Well... that still doesn't count. The window manager can give Firefox in a "non-responding" window decoration, and since progress is indeterminate that's really all that can be done. (And for the case that the window manager freezes... that's why I have it displaying a clock with second-level precision, so as to see if it's still progressing. If the clock stops ticking, it's time for a reboot). Alright. So 20 seconds is too short to start thinking about estimating progress; how long do we have to go? I would guess the 5-minute range; after that, it's long enough to start thinking about switching tasks and doing smallish routines such as preparing meals.
For estimated times, the only useful data is the time to completion, e.g. 24 minutes. But this changes frequently; a better idea for long-style progress indicators is to display the time of completion, e.g. that it will finish at 3:00 PM today. Calendars are better than ETA's because they let us plan in advance and think about all of life's routines as opposed to the task at hand. There's some debate over whether a clock time is shorter. In practice, estimates will be inexact, and you'll need a confidence interval. So far I haven't seen anybody implement progress estimation using anything approaching statistics... It's really the only way to display time; the progress bar is useless, because it only shows how much time the user has sunk in already. Even in an early study on progress bars, the suggestion is made to display a simple time estimate instead of a progress bar.
Technology hijacks people's minds; is watching a progress bar tick really the best use of their time? Optimizing for software satisfaction leads to hidden costs in other areas of life.
Corroborating evidence comes from a study of keyboard vs mouse: the mouse was easy to use and was objectively faster, but, due to its low cerebral engagement, was rated poorly by users. On the other hand, the keyboard required remembering complex shortcuts, which took significant cognitive processing. But this time was ignored in subjective evaluations, resulting in users thinking that the keyboard was faster. User satisfaction would be optimized by keyboards. But user productivity would be optimized by mice. But, only in the short term; more recent studies suggest that, with experience, keyboard shortcuts are faster than the mouse. So the choice is best phrased as an investment decision: spend more time now for a better memory later, or walk away quickly and cut your losses.
Obviously, if the software will take several days to complete, it is pretty much impossible to remain engaged and you should always switch tasks. Similarly if it's below the threshold 0.1 seconds then maintaining flow is paramount. But in between, we enter a much more complex world than a simple progress indicator. Questions like: How should users spend their attention? Is frequent task-switching a good idea?
Model for why spinners reduce attention span:
- the animated spinning engages the user's attention
- the default-mode network is thus less active, fires less often, and so it feels as if not much time has passed
- the timing from the motor network fires more often to track the on-screen activity
A solution for semi-autonomous vehicles
Today, there are many discussions around self-driving cars and whether they can be trusted to take over from people. Although researchers are working hard to change this question into the reverse ("Why should humans drive when the computers do it so much better?"), there will (probably) always be a need for manual driving; for example, the car would have to be driven by hand to the repair shop when an important sensor breaks.
The problem, of course, is that if the car is doing most of the driving, then humans will be unprepared for the rare occurrence when it does not. The most fanciful depiction of this is probably the Disney movie WALL-E; the humans have retreated to self-driving floating armchairs, and barely even recall how to walk. As shown in that movie, though, the situation is unstable; if the systems stop working, which in WALL-E's case was as simple as a new robot bumping into one of the chairs, humans are adaptable enough to learn complex control systems on-the-fly and take back control.
But, of course, it is possible that humans could be injured or killed in this (re)learning process. For the most part, this has been worked around; e.g. car companies designed safety features such as seatbelts and airbags into their cars. But these are not sufficient; there are still many non-fatal injuries, and unlike with bumper cars, real cars cost a lot of money to fix when they crash into each other (exactly why this is so is up for debate).
So, I present the solution: video games; in particular, car racing games. Supposing that, in an autonomous car, the controls will be disconnected, this frees them up to be used for other purposes. By adding transparent LCD screens to all the windows and utilizing the already-present sound system and computer, a decent video game can be made even better through an immersive in-car experience. Furthermore, since it utilizes the existing car controls and view mechanisms, it ensures that the driver is well-acquainted with what to do in case of manual control.
Existing car games are already headed in this direction; dedicated vehicle gamers have a custom steering wheel, electronic pedals, and even a stick shift, for those who like manuals.
It seems simple enough; why drive your boring, slow routine route when instead you could be racing down the freeway, narrowly avoiding the flaming wrecks of other cars and dodging the oncoming fire of a police helicopter? Considering the level of skill required by these video games, transferring to manual control will be a piece of cake; for those who have things to do besides play racing games, a few minutes a day would likely be sufficient to maintain the necessary skill level.
As usual, I have no clue to why this hasn't happened; a similar system could easily be built for pilots, who already do very little manual flying. Instead, though, plane crashes continue to happen, primarily due to pilot error, while those pilots who actually do bother to play airplane simulator games, and then go on to use those skills to recover from unexpected events in their day-to-day flying, are lauded as heroes who went above and beyond their job description.
Now, I'm not saying these people don't deserve recognition; most video games include a leaderboard or a high score feature for that very reason. But, when they appear in the newspaper, rather than the video game forums, I think there's a bit of a problem. Video games can and do save lives; let's make them part of the job, rather than the main event.
The problem, of course, is that if the car is doing most of the driving, then humans will be unprepared for the rare occurrence when it does not. The most fanciful depiction of this is probably the Disney movie WALL-E; the humans have retreated to self-driving floating armchairs, and barely even recall how to walk. As shown in that movie, though, the situation is unstable; if the systems stop working, which in WALL-E's case was as simple as a new robot bumping into one of the chairs, humans are adaptable enough to learn complex control systems on-the-fly and take back control.
But, of course, it is possible that humans could be injured or killed in this (re)learning process. For the most part, this has been worked around; e.g. car companies designed safety features such as seatbelts and airbags into their cars. But these are not sufficient; there are still many non-fatal injuries, and unlike with bumper cars, real cars cost a lot of money to fix when they crash into each other (exactly why this is so is up for debate).
So, I present the solution: video games; in particular, car racing games. Supposing that, in an autonomous car, the controls will be disconnected, this frees them up to be used for other purposes. By adding transparent LCD screens to all the windows and utilizing the already-present sound system and computer, a decent video game can be made even better through an immersive in-car experience. Furthermore, since it utilizes the existing car controls and view mechanisms, it ensures that the driver is well-acquainted with what to do in case of manual control.
Existing car games are already headed in this direction; dedicated vehicle gamers have a custom steering wheel, electronic pedals, and even a stick shift, for those who like manuals.
It seems simple enough; why drive your boring, slow routine route when instead you could be racing down the freeway, narrowly avoiding the flaming wrecks of other cars and dodging the oncoming fire of a police helicopter? Considering the level of skill required by these video games, transferring to manual control will be a piece of cake; for those who have things to do besides play racing games, a few minutes a day would likely be sufficient to maintain the necessary skill level.
As usual, I have no clue to why this hasn't happened; a similar system could easily be built for pilots, who already do very little manual flying. Instead, though, plane crashes continue to happen, primarily due to pilot error, while those pilots who actually do bother to play airplane simulator games, and then go on to use those skills to recover from unexpected events in their day-to-day flying, are lauded as heroes who went above and beyond their job description.
Now, I'm not saying these people don't deserve recognition; most video games include a leaderboard or a high score feature for that very reason. But, when they appear in the newspaper, rather than the video game forums, I think there's a bit of a problem. Video games can and do save lives; let's make them part of the job, rather than the main event.
Data is abstract
Take a hard disk. Print it out on a sheet of paper. It's just a long string of bits. The processor does nothing but shuffle around these bits, using some of the bits to interpret the other bits.
DNA is the same; instructions to build proteins to build cells and build more DNA.
The interesting parts are the concrete details; what kind of machine gets built. And they're not really in there; looking at machine will tell you what kinds of instructions there are, but not how to interpret them.
DNA is the same; instructions to build proteins to build cells and build more DNA.
The interesting parts are the concrete details; what kind of machine gets built. And they're not really in there; looking at machine will tell you what kinds of instructions there are, but not how to interpret them.
Subscribe to:
Posts (Atom)