1) Mechanical Music Digest: Ah, a publication about music. Does the monkey make music? Can we legally make copies of the monkey's songs? Is the monkey using DRM-enforcing mechanics? Additionally, this publication is about mechanics, and mechanics are cool (especially quantum mechanics, which the monkey probably uses.) 2) warning: bug in the Monkey can share your files with everyone on the net 3) automaton: Monkey Automaton vs. Grendel, dude. Bulldozer-like ramps beat pneumatic spikes 9 times out of 10. 4) Magic: Gandalf has magic. YOU SHALL NOT PASS! 5) hanging on your wall: like my 80-inch plasma TV, baby 6) 1879: 0x757 in hex, which is a palindrome. Both hex and palindromes rock. 7)... fill in your own reason why Fake Monkey Automatons 0wn j00 here.
I suppose that's true. Like a good little bot I was just regurgitating what had been fed to me before, but after I posted I got to thinking about it a little bit. Maybe the address book is supposed to be the analog of a paper-based address book, or even a digital address book.
The article was obviously not meant to be a full HIG document for all Mac applications. Don't take it to be such.
There is a separate guideline on the appearance of "device" applications. Apple's guideline is that any application that simulates or interacts with a hardware or "real life" device should have the aluminium look/feel, which can be applied to any application the developer in 10.2, from what I've read.
Go try out iTunes, QuickTime, etc to see how much Apple thinks "Grey is out" (the window background is non-standard, and grey). iTunes and Quicktime also have custom title bars, and custom resizing gadgets.
The article actually left out the guidelines on the aluminium look. This is actually a look that can be impressed on any Application in 10.2. They're not custom controls, it's just a "skin" for them.
Apple's guideline to developers is that the aluminum look should be used for applications that attempt to simulate a hardware or "real life" device. iTunes=stereo, QT=TV, etc.
However, they break even that guideline w/ the new address book app. Go figure.:)
It's not really the "tip" we're talking about, it's the molten metal stream that all armor piercing weapons (since the 40s) use to do the damage. This means the temperature of the stream has to be hot enough to melt armor, and AFAIK only other metals can get hot enough to melt metal.
Re:Fasteroids: take the pie menu challenge!
on
Pie-Menus in Mozilla
·
· Score: 2
Also, you might consider enforcing mouse centering to your test. For instance, force the use a webpage... each link on the page will pop up a single menu. Then the user must move to the next link to get the next menu. Measure the in-between-menu time spent as well as time-in-menu, and add it to your result set.
Why? In both the pie and linear menus, I found myself recentering my mouse on a point after every click. For neither menu was that a required behavior, but it was a learned one. A user doesn't just click around a webpage randomly when trying to do "save as" on links... they have objective motion directed by tasks.
I'm fairly confident if you added this you'd see decreased performance on pie menus. It's a fact that pie menus have an increased selection area (which is part of what Fitt's law is all about), but the selection area is not bounded on the outer edge... which means you can move an arbitrary distance out and it doesn't affect your success/failure rate (as long as you move far enough out)... but that also means you have to recover from that random-distance motion to move to the next task point. With vertical menus there is very little "randomness" to the motion... only the side-to-side slip allowed within the vertical menu, which is not as boundless as with pie menus.
Now... if you put an outer boundary on your pie menus that you could "throw" the cursor against, and had the mouse pointer recenter after a selection was made... I think you'd have something.:)
Re:Fasteroids: take the pie menu challenge!
on
Pie-Menus in Mozilla
·
· Score: 2
Ah! I ran the test a few more times just to be sure, and found the additional rounds. So you may ignore my points #1 and #2... you have addressed them quite well. I must have run into some funky random number generation the first time... my first time back I did as well. The 2nd run was limitless twice, and I did about 30 linear selections before stopping both times (vs. 10-15 pie). My results were as follows:
Pie Random 53 53 44993 848.92 0 0% Linear Random 14 14 11526 823.29 0 0% Pie Constant 24 24 15712 654.67 0 0% Linear Constant 26 25 18446 737.84 1 4%
My point #3 is still valid, however. In subsequent tests I noticed my performance on Linear Constant was directly proporational to which constant menu item I had to select. When it was in the top 3 items in the menu, my performance was identical to my random performance (linear slightly faster than pie.) When it was at the bottom, my performance was much worse than pie. But... only idiot designers like those at Microsoft think common right-click menu options like "Properties" being at the bottom somehow helps make them easier to select.:) With pies, performance is the same for all options, no matter how common. Unfortunately, to be accurate with a pie menu, you have to move farther from the center point than you do to get to the first few options in a linear menu. And my point still stands about perceived speed... I still feel quite speedy with pie menus, but I am not any faster with them in real-world situations according to your counters.
Re:Fasteroids: take the pie menu challenge!
on
Pie-Menus in Mozilla
·
· Score: 2
And now for objective evidence: here are my results from Fasteroids. I did the test 3 times. In 2 out of 3 test runs, I was faster with linear menus. In the first run I was faster by a slim margin with pie menus. I will discuss why below. The results from my final test:
Pie Random 10 10 8742 874.2 0 0% Linear Random 17 17 14060 827.06 0 0%
There are some problems with the Fasteroids test that I suggest you fix before you use the data for anything.
1) Make the number of iterations for pie and linear exactly the same. Right now it has you do ~10-15 pie selections, then a unlimited number of linear selections. This is problematic because the test never ends, and fatigue becomes a factor in the linear menu test portion, which is always last.
The fact the linear portion of the test never ends is also misleading to the user. In my very first Fasteroid run I found myself wondering when the test would end after I'd done at least twice the number of vertical selections as I had done pie selections... I looked down at the results while trying to make a selection and it contributed to me missing the next selection. After that selection, I stopped, but the damage had already been done to my linear test speed. Bad data. The same thing would have happened to my pie score speed had it been the last test and it had run on forever.
2) The order of the pie and linear testing portions should be randomly switched. Sometimes you should have to do pie first, and sometimes linear. This addresses physical fatigue that happens in the latter half of the test... your data is not representative of which menu is easier/faster if for one test you are tired and the other you aren't.
On every run of Fasteroids I did, when the pie menu test ended, and the linear test begain, I was surprised by it, and had to change movement patterns... which led to a slow initial linear selection. This is not the case with the pie test, because I knew it would start with a pie the first time I clicked the starfield (on my 2nd and 3rd runs of course.) Redordering the pie and linear test sequences randomly would also solve this problem.
3) This test is not applicable to real-world use of menus. Menu options do not appear in randomized order in a browser. Rather, pie menu options are arranged so that the selection you want to make is always in the same direction; linear menus are arranged so that the selection you want to make is always the same distance. To make the test more applicable, repeated selections of the same options should be encouraged. Additionally, well-designed vertical menus are often configured so that the most commonly-chosen options are at the top. Very rarely would I need to use the option that is a the very bottom of a vertical menu as often as I would the option at the top... your test forces me to select options that are presumably rare as often as I'd selection common ones.
I have no real suggestions for improving Fasteroids to address the issues of point #3. I do believe, however, that the Fasteroids test isn't any less subjective than my suggestion (and a well known one in the field of usability) that perceived speed is just as important as actual speed. And yes, I actually felt faster using Fasteroid's pie menus, although (no thanks to flaws in the test) it turns out I wasn't. And if perceived speed is all you're going for, than hurrah for pie menus!
Re:Keyboard accelerators, mouse ahead and rehersal
on
Pie-Menus in Mozilla
·
· Score: 2
It takes at least a second to move your hand between the mouse and keyboard and readjust, so it's important to provide keyboard equivalents for commands you'll be using while typing.
It's good that I have two hands, then, so I can keep one on the keyboard.:)
Something that would make pie menus substantially more useable, IMHO, is a trackpoint type device mounted on top of the mouse. Although flinging your mouse rapidly 3 different directions makes you feel like you're getting lots of work accomplished, I would much rather click to select the item, then finger the 3 directions with a trackpoint. It would allow me to maintain the position of the mouse, rather than throwing it around the screen randomly all for the sake of choosing some options.
You did not answer my main question yet: How do you select a link and create a bookmark of it using a keyboard shortcut? You left out the "select a link" part. Conveniently, I might add.
As I said before, you right click the link (that selects it... a mouse click is also required for most pie menus) and then push the F key (the F key is equivalent to moving the mouse down and clicking on the "Add to Favorites" option, except that you don't have to move the mouse or click.)
Accelerator, shortcut, they're the same thing. Your keyboard doesn't have shortcuts either... but your keyboard *does* allow you to accelerate/shortcut your tasks by not involving the mouse or reading of menu options on the screen.
I don't know. Vertical menus leverage muscle memory as well, except that the movement is in a fixed direction with variable distance, rather in variable directions with fixed distance. I don't feel there's much difference between the two options.
But: pie menu navigation is not a fixed distance motion. The motions are actually more complex. For menus with more options, the target area must be farther from the centerpoint... 3 given menus with different numbers of options require 3x the number of types of movements because of the varying distances off center. On a vertical menu, the movement to get to the "first" menu option is the same for any length menu... and this is very powerful when the first option is also the most commonly selected.
It's my personal belief that pie menus are more of a perceived advantage rather than a true advantage. The complexity of motion makes you feel more industrious... although you may not be getting work done any faster at all.
In IE, I right click it and push F. I would assume it is similar in Mozilla... if they have accelerators. Keyboard accelerator is the fancy word for "key you press rather than selecting the item on the menu with the mouse."
I personally don't consider it to be that useful. It doesn't do anything that keyboard accelerators don't do, unless you can't type a single key accurately.
My biggest beef with it is it forces your mouse to have to move away from the selected item. Keyboard shortcuts don't move the mouse pointer or the focus anywhere, so you are ready to move onto the next task without trying to find out where your pointer went when you were doing a "no look" command.
The "usual" explanation is that there are several Klingon races, perhaps living on different planets in the Klingon homeworld system. In TOS, it was just coincidental that the Enterprise crew happened to always be interacting with the "smooth head and chainmail" Klingons. This has never been directly stated in any episode or movie however... it's just something that Star Trek fans pass around.
Note though that more recently the Klingon look has been "humanified" for certain Klingons... General Chang in ST6 is a good example... this was done to make it easier to related to the character, but he could almost pass for one of the TOS-style Klingons. Other Klingons (in DS9 and Enterprise) have also had this look.
But no, I don't think "they'll" ever explain it.:)
How many months do you have to have worked with them to be considered old dog on the development team?
18? It's not like it just came out yesterday, the beta has been available for at least a year and a half. Wrox put out books on programming with the beta languages and the beta framework.
How well does a.NET UI run on a Solaris workstation?
Actually you answered your own question. It runs fine, if its an ASP.NET UI. Working on HTML/JavaScript based UI is nearly the same process as developing a client side UI in.NET, given the event-based programming model and similar UI classes for both. Granted, you can't yet run a pure Windows.Forms application on Solaris, but you didn't ask "how well does a.NET Windows Forms UI run on a Solaris workstation," did you?:)
If the speedlimit were 60, and someone in front of me were doing 40, well, they'd be going less than the legal and suggested speed for that road. In my state it would be legal for me to pass the person at any speed *up to* 60mph in a passing lane. And that is what I'd do, assuming there was a passing lane where I could pass this person safely, all while staying at 60. If I can't, well, then I guess I'll be stuck there. But not for long... state law requires that any person holding up 5 or more cars at a speed *under* the speed limit is required to pull off the road at the next safe location. If you are holding up 5 or more cars, but going the speed limit, you are not required to do anything about it (for the obvious reason that no one should be going any faster than you anyway if you're going the speedlimit.)
Now, in my state, it's also legal to go faster than the speed limit to complete the pass (perhaps 80 in this case) if a dangerous situation arises (like an alien ship drops a car in the other lane directly in front of you)... but if you initiate a pass that required you to begin the pass over the limit, that's a reckless driving fine. And 99.9% of the time, assholes, the oncoming car was *not* dropped by an alien ship, believe me... you just didn't have any business passing in the first place.
Now, if everyone obeyed these laws I just described, no one would be going over the speed limit, and there would be no speed differential, except in the case that someone was going *under* the limit (for mechanical or age reasons), in which case it's perfectly legal to pass at reasonable speed. And as I mentioned, the law also provides a mechanism to free "clogs" in the traffic flow.)
But because of a select few (or a large percentage, take your pick, depending on the area) of people who don't seem to be interested in obeying laws, we have this "danger" of speed differential. And thus my quote of the day (repeated from a previous day), "Slow the fuck down."
Now, according to that fine pink-backgrounded research paper you posted suggests, speed limits are based on the 85th percentile. The exact quote:
When a speed limit is to be posted, it should be the 85th-percentile speed of free-flowing traffic, rounded up to the nearest 10 km/h (5 mph) increment.
Interesting how it says "is to be posted." How many roads have you seen without speed limits? None. Initial speed limits are determined by engineers and by the road type and surroundings (75 national limit is used for Interstates, 65 is usually used for Interstates going though on/offramp areas, 55 is usually used for 2 lane highways, etc.) This is for *modification* of existing road speed limits. And if, as you say, "most" people are going 80mph in those areas where the speed limit is actually 60mph, any modification of the speed limit using these rules would only serve to increase the speed limit. Funny how that works isn't it?
My favorite part of that article, though, is this:
Two cars are driving at 205 MPH. WHOW!!!! 205!!!! Yep, 205. Car one hits car two.... what happens? Ricky Martin's spoiler gets bent and Jeff Gordon goes on to win the Daytona 500! These cars move at speeds over 150 MPH all the time... Yet, the fatality rate of race car drivers is MUCH lower than that for average drivers. Why?
It's funny how during races all the cars drive the same direction. On most highways and streets cars drive straight toward each other. It's also interesting how the cars they drive come with built-in rollcages, fire extinguishers, sophisticated body harnesses, etc.
Another good one:
In 1998, 43 percent of the intoxicated drivers (BAC = 0.10 or higher) involved in fatal crashes were speeding, compared with only 14 percent of the sober drivers (BAC = 0.00) involved in fatal crashes
It goes to to state that 86% were DRUNK!!! (in really big bold letters to make a point.) Uh, where did that 86% come from? There is no statistic here on the number of people that were drunk.
Before you spend money in court using all the skills you learned from Michael Stone Jr. and his pink-paper on avoiding tickets, I suggest you think this over one more time:
Well, for one thing, somebody driving 80mph hitting you from behind when you're going 60mph is going to do more damage than if they hit somebody doing 78mph (relative speeds -- the first is a collision at 20mph, the other is at 2mph. calculate your kinetic energy).
What would be really nice though is if that person driving 80mph was driving 60mph instead, so no one would be colliding at all. As you've pointed out, though, you have a fast car and are not interested in syncing your speed with the speed everyone's *supposed* to be going, and would rather set a bar for everyone else. Thanks for being so considerate... your attitude is what makes this country great.
There's a limit at which point the increase in kinetic energy doesn't matter anymore, because you're already going to be dead.
So, a 90% chance of dying this year vs. an 89% chance of dying this year doesn't matter to you? I'll take 89% thanks. Oh, and thanks for the picture of the car, especially for the ones of the plates. If I ever see you going 80, I'll put my cell phone to use... because hey, if you get enough tickets for speeding you'll have a 0% chance of killing me with that thing... and that's good odds. Slow the fuck down.
Slashdot Mirror
The .exe causes my Mac just a few more problems. Like... I can't run it.
1) Mechanical Music Digest: Ah, a publication about music. Does the monkey make music? Can we legally make copies of the monkey's songs? Is the monkey using DRM-enforcing mechanics? Additionally, this publication is about mechanics, and mechanics are cool (especially quantum mechanics, which the monkey probably uses.) ... fill in your own reason why Fake Monkey Automatons 0wn j00 here.
2) warning: bug in the Monkey can share your files with everyone on the net
3) automaton: Monkey Automaton vs. Grendel, dude. Bulldozer-like ramps beat pneumatic spikes 9 times out of 10.
4) Magic: Gandalf has magic. YOU SHALL NOT PASS!
5) hanging on your wall: like my 80-inch plasma TV, baby
6) 1879: 0x757 in hex, which is a palindrome. Both hex and palindromes rock.
7)
AddressBook: nothing.
... maybe they're building a ... nah!
:)
iCal: nothing
Actually, I have repented. Both these apps do have a respective digital lifestyle device: the PDA.
Wait...
Yeah....
I suppose that's true. Like a good little bot I was just regurgitating what had been fed to me before, but after I posted I got to thinking about it a little bit. Maybe the address book is supposed to be the analog of a paper-based address book, or even a digital address book.
The article was obviously not meant to be a full HIG document for all Mac applications. Don't take it to be such.
There is a separate guideline on the appearance of "device" applications. Apple's guideline is that any application that simulates or interacts with a hardware or "real life" device should have the aluminium look/feel, which can be applied to any application the developer in 10.2, from what I've read.
Go try out iTunes, QuickTime, etc to see how much Apple thinks "Grey is out" (the window background is non-standard, and grey). iTunes and Quicktime also have custom title bars, and custom resizing gadgets.
:)
The article actually left out the guidelines on the aluminium look. This is actually a look that can be impressed on any Application in 10.2. They're not custom controls, it's just a "skin" for them.
Apple's guideline to developers is that the aluminum look should be used for applications that attempt to simulate a hardware or "real life" device. iTunes=stereo, QT=TV, etc.
However, they break even that guideline w/ the new address book app. Go figure.
No, because it would be a DVD±RW drive.
It's not really the "tip" we're talking about, it's the molten metal stream that all armor piercing weapons (since the 40s) use to do the damage. This means the temperature of the stream has to be hot enough to melt armor, and AFAIK only other metals can get hot enough to melt metal.
Also, you might consider enforcing mouse centering to your test. For instance, force the use a webpage... each link on the page will pop up a single menu. Then the user must move to the next link to get the next menu. Measure the in-between-menu time spent as well as time-in-menu, and add it to your result set.
:)
Why? In both the pie and linear menus, I found myself recentering my mouse on a point after every click. For neither menu was that a required behavior, but it was a learned one. A user doesn't just click around a webpage randomly when trying to do "save as" on links... they have objective motion directed by tasks.
I'm fairly confident if you added this you'd see decreased performance on pie menus. It's a fact that pie menus have an increased selection area (which is part of what Fitt's law is all about), but the selection area is not bounded on the outer edge... which means you can move an arbitrary distance out and it doesn't affect your success/failure rate (as long as you move far enough out)... but that also means you have to recover from that random-distance motion to move to the next task point. With vertical menus there is very little "randomness" to the motion... only the side-to-side slip allowed within the vertical menu, which is not as boundless as with pie menus.
Now... if you put an outer boundary on your pie menus that you could "throw" the cursor against, and had the mouse pointer recenter after a selection was made... I think you'd have something.
Ah! I ran the test a few more times just to be sure, and found the additional rounds. So you may ignore my points #1 and #2... you have addressed them quite well. I must have run into some funky random number generation the first time... my first time back I did as well. The 2nd run was limitless twice, and I did about 30 linear selections before stopping both times (vs. 10-15 pie). My results were as follows:
:) With pies, performance is the same for all options, no matter how common. Unfortunately, to be accurate with a pie menu, you have to move farther from the center point than you do to get to the first few options in a linear menu. And my point still stands about perceived speed... I still feel quite speedy with pie menus, but I am not any faster with them in real-world situations according to your counters.
Pie Random 53 53 44993 848.92 0 0%
Linear Random 14 14 11526 823.29 0 0%
Pie Constant 24 24 15712 654.67 0 0%
Linear Constant 26 25 18446 737.84 1 4%
My point #3 is still valid, however. In subsequent tests I noticed my performance on Linear Constant was directly proporational to which constant menu item I had to select. When it was in the top 3 items in the menu, my performance was identical to my random performance (linear slightly faster than pie.) When it was at the bottom, my performance was much worse than pie. But... only idiot designers like those at Microsoft think common right-click menu options like "Properties" being at the bottom somehow helps make them easier to select.
And now for objective evidence: here are my results from Fasteroids. I did the test 3 times. In 2 out of 3 test runs, I was faster with linear menus. In the first run I was faster by a slim margin with pie menus. I will discuss why below. The results from my final test:
Pie Random 10 10 8742 874.2 0 0%
Linear Random 17 17 14060 827.06 0 0%
There are some problems with the Fasteroids test that I suggest you fix before you use the data for anything.
1) Make the number of iterations for pie and linear exactly the same. Right now it has you do ~10-15 pie selections, then a unlimited number of linear selections. This is problematic because the test never ends, and fatigue becomes a factor in the linear menu test portion, which is always last.
The fact the linear portion of the test never ends is also misleading to the user. In my very first Fasteroid run I found myself wondering when the test would end after I'd done at least twice the number of vertical selections as I had done pie selections... I looked down at the results while trying to make a selection and it contributed to me missing the next selection. After that selection, I stopped, but the damage had already been done to my linear test speed. Bad data. The same thing would have happened to my pie score speed had it been the last test and it had run on forever.
2) The order of the pie and linear testing portions should be randomly switched. Sometimes you should have to do pie first, and sometimes linear. This addresses physical fatigue that happens in the latter half of the test... your data is not representative of which menu is easier/faster if for one test you are tired and the other you aren't.
On every run of Fasteroids I did, when the pie menu test ended, and the linear test begain, I was surprised by it, and had to change movement patterns... which led to a slow initial linear selection. This is not the case with the pie test, because I knew it would start with a pie the first time I clicked the starfield (on my 2nd and 3rd runs of course.) Redordering the pie and linear test sequences randomly would also solve this problem.
3) This test is not applicable to real-world use of menus. Menu options do not appear in randomized order in a browser. Rather, pie menu options are arranged so that the selection you want to make is always in the same direction; linear menus are arranged so that the selection you want to make is always the same distance. To make the test more applicable, repeated selections of the same options should be encouraged. Additionally, well-designed vertical menus are often configured so that the most commonly-chosen options are at the top. Very rarely would I need to use the option that is a the very bottom of a vertical menu as often as I would the option at the top... your test forces me to select options that are presumably rare as often as I'd selection common ones.
I have no real suggestions for improving Fasteroids to address the issues of point #3. I do believe, however, that the Fasteroids test isn't any less subjective than my suggestion (and a well known one in the field of usability) that perceived speed is just as important as actual speed. And yes, I actually felt faster using Fasteroid's pie menus, although (no thanks to flaws in the test) it turns out I wasn't. And if perceived speed is all you're going for, than hurrah for pie menus!
It takes at least a second to move your hand between the mouse and keyboard and readjust, so it's important to provide keyboard equivalents for commands you'll be using while typing.
:)
It's good that I have two hands, then, so I can keep one on the keyboard.
Something that would make pie menus substantially more useable, IMHO, is a trackpoint type device mounted on top of the mouse. Although flinging your mouse rapidly 3 different directions makes you feel like you're getting lots of work accomplished, I would much rather click to select the item, then finger the 3 directions with a trackpoint. It would allow me to maintain the position of the mouse, rather than throwing it around the screen randomly all for the sake of choosing some options.
You did not answer my main question yet: How do you select a link and create a bookmark of it using a keyboard shortcut? You left out the "select a link" part. Conveniently, I might add.
As I said before, you right click the link (that selects it... a mouse click is also required for most pie menus) and then push the F key (the F key is equivalent to moving the mouse down and clicking on the "Add to Favorites" option, except that you don't have to move the mouse or click.)
Accelerator, shortcut, they're the same thing. Your keyboard doesn't have shortcuts either... but your keyboard *does* allow you to accelerate/shortcut your tasks by not involving the mouse or reading of menu options on the screen.
On my phone, of course, it would be:
Dear registered Democrat voter, Your support in the upcoming election is crucial. You can't let Jesse Helmes
Oooh. Neat. Delete.
It's even funnier that people willfully select SMS services knowing that this will happen.
I don't know. Vertical menus leverage muscle memory as well, except that the movement is in a fixed direction with variable distance, rather in variable directions with fixed distance. I don't feel there's much difference between the two options.
But: pie menu navigation is not a fixed distance motion. The motions are actually more complex. For menus with more options, the target area must be farther from the centerpoint... 3 given menus with different numbers of options require 3x the number of types of movements because of the varying distances off center. On a vertical menu, the movement to get to the "first" menu option is the same for any length menu... and this is very powerful when the first option is also the most commonly selected.
It's my personal belief that pie menus are more of a perceived advantage rather than a true advantage. The complexity of motion makes you feel more industrious... although you may not be getting work done any faster at all.
Unless they block blank referers, which will once again cause all their pictures are belong to them.
In IE, I right click it and push F. I would assume it is similar in Mozilla... if they have accelerators. Keyboard accelerator is the fancy word for "key you press rather than selecting the item on the menu with the mouse."
I personally don't consider it to be that useful. It doesn't do anything that keyboard accelerators don't do, unless you can't type a single key accurately.
My biggest beef with it is it forces your mouse to have to move away from the selected item. Keyboard shortcuts don't move the mouse pointer or the focus anywhere, so you are ready to move onto the next task without trying to find out where your pointer went when you were doing a "no look" command.
The "usual" explanation is that there are several Klingon races, perhaps living on different planets in the Klingon homeworld system. In TOS, it was just coincidental that the Enterprise crew happened to always be interacting with the "smooth head and chainmail" Klingons. This has never been directly stated in any episode or movie however... it's just something that Star Trek fans pass around.
:)
Note though that more recently the Klingon look has been "humanified" for certain Klingons... General Chang in ST6 is a good example... this was done to make it easier to related to the character, but he could almost pass for one of the TOS-style Klingons. Other Klingons (in DS9 and Enterprise) have also had this look.
But no, I don't think "they'll" ever explain it.
How many months do you have to have worked with them to be considered old dog on the development team?
18? It's not like it just came out yesterday, the beta has been available for at least a year and a half. Wrox put out books on programming with the beta languages and the beta framework.
How well does a .NET UI run on a Solaris workstation?
.NET, given the event-based programming model and similar UI classes for both. Granted, you can't yet run a pure Windows.Forms application on Solaris, but you didn't ask "how well does a .NET Windows Forms UI run on a Solaris workstation," did you? :)
Actually you answered your own question. It runs fine, if its an ASP.NET UI. Working on HTML/JavaScript based UI is nearly the same process as developing a client side UI in
If the speedlimit were 60, and someone in front of me were doing 40, well, they'd be going less than the legal and suggested speed for that road. In my state it would be legal for me to pass the person at any speed *up to* 60mph in a passing lane. And that is what I'd do, assuming there was a passing lane where I could pass this person safely, all while staying at 60. If I can't, well, then I guess I'll be stuck there. But not for long... state law requires that any person holding up 5 or more cars at a speed *under* the speed limit is required to pull off the road at the next safe location. If you are holding up 5 or more cars, but going the speed limit, you are not required to do anything about it (for the obvious reason that no one should be going any faster than you anyway if you're going the speedlimit.)
Now, in my state, it's also legal to go faster than the speed limit to complete the pass (perhaps 80 in this case) if a dangerous situation arises (like an alien ship drops a car in the other lane directly in front of you)... but if you initiate a pass that required you to begin the pass over the limit, that's a reckless driving fine. And 99.9% of the time, assholes, the oncoming car was *not* dropped by an alien ship, believe me... you just didn't have any business passing in the first place.
Now, if everyone obeyed these laws I just described, no one would be going over the speed limit, and there would be no speed differential, except in the case that someone was going *under* the limit (for mechanical or age reasons), in which case it's perfectly legal to pass at reasonable speed. And as I mentioned, the law also provides a mechanism to free "clogs" in the traffic flow.)
But because of a select few (or a large percentage, take your pick, depending on the area) of people who don't seem to be interested in obeying laws, we have this "danger" of speed differential. And thus my quote of the day (repeated from a previous day), "Slow the fuck down."
Now, according to that fine pink-backgrounded research paper you posted suggests, speed limits are based on the 85th percentile. The exact quote:
When a speed limit is to be posted, it should be the 85th-percentile speed of free-flowing traffic, rounded up to the nearest 10 km/h (5 mph) increment.
Interesting how it says "is to be posted." How many roads have you seen without speed limits? None. Initial speed limits are determined by engineers and by the road type and surroundings (75 national limit is used for Interstates, 65 is usually used for Interstates going though on/offramp areas, 55 is usually used for 2 lane highways, etc.) This is for *modification* of existing road speed limits. And if, as you say, "most" people are going 80mph in those areas where the speed limit is actually 60mph, any modification of the speed limit using these rules would only serve to increase the speed limit. Funny how that works isn't it?
My favorite part of that article, though, is this:
Two cars are driving at 205 MPH. WHOW!!!! 205!!!! Yep, 205. Car one hits car two.... what happens? Ricky Martin's spoiler gets bent and Jeff Gordon goes on to win the Daytona 500! These cars move at speeds over 150 MPH all the time... Yet, the fatality rate of race car drivers is MUCH lower than that for average drivers. Why?
It's funny how during races all the cars drive the same direction. On most highways and streets cars drive straight toward each other. It's also interesting how the cars they drive come with built-in rollcages, fire extinguishers, sophisticated body harnesses, etc.
Another good one:
In 1998, 43 percent of the intoxicated drivers (BAC = 0.10 or higher) involved in fatal crashes were speeding, compared with only 14 percent of the sober drivers (BAC = 0.00) involved in fatal crashes
It goes to to state that 86% were DRUNK!!! (in really big bold letters to make a point.) Uh, where did that 86% come from? There is no statistic here on the number of people that were drunk.
Before you spend money in court using all the skills you learned from Michael Stone Jr. and his pink-paper on avoiding tickets, I suggest you think this over one more time:
"Slow the fuck down."
Well, for one thing, somebody driving 80mph hitting you from behind when you're going 60mph is going to do more damage than if they hit somebody doing 78mph (relative speeds -- the first is a collision at 20mph, the other is at 2mph. calculate your kinetic energy).
What would be really nice though is if that person driving 80mph was driving 60mph instead, so no one would be colliding at all. As you've pointed out, though, you have a fast car and are not interested in syncing your speed with the speed everyone's *supposed* to be going, and would rather set a bar for everyone else. Thanks for being so considerate... your attitude is what makes this country great.
There's a limit at which point the increase in kinetic energy doesn't matter anymore, because you're already going to be dead.
So, a 90% chance of dying this year vs. an 89% chance of dying this year doesn't matter to you? I'll take 89% thanks. Oh, and thanks for the picture of the car, especially for the ones of the plates. If I ever see you going 80, I'll put my cell phone to use... because hey, if you get enough tickets for speeding you'll have a 0% chance of killing me with that thing... and that's good odds. Slow the fuck down.