My younger brother and sister (13, 17) don't seem to use email at all anymore. They got bored of it about a week after I showed them how to use it ages ago. Back then they were running Windows 95 with a single user account and were always arguing over whose account details get to stay in MSN Messenger.
Fortunately now they use Windows XP Home with separate user accounts, and leave both accounts logged in almost permanently. The arguments now are about whose desktop gets to stay visible and whose is relegated to being hidden away.
I'm already hypersensitive to grammar errors. I think it's something to do with how I read, but I am no psychologist.
As of late, there are comma splices everywhere. It's very frustrating. Even the packet of razors I just bought warns "Do not touch blades, it may reduce performance."
Q. I've tried reading the XML, SGML, XSL, XPATH, DSSSL or other specification, but it doesn't make any sense. There's too much jargon!
A. Specification authors deliberately obfuscate the text of ISO and W3C standards to ensure that normal people can't use the technology without assistance from the so-called "experts" who designed the specs.
Fortunately, there is a handy translation list you can use:
attribute
tag
attribute value
tag
character reference
tag
comment
tag
document type declaration
tag
element
tag
entity reference
tag
literal
tag
numeric character reference
tag
tag
command
With the help of this table, even Visual Basic programmers should have no trouble deciphering ISO prose.
(From the comp.text.sgml FAQ list; completely butchered thanks to slashdot's amazing lameness filter.)
There are a few ways around this problem. Here's one, as an example:
Menu items are still greyed out, but hovering the mouse pointer over them produces a help bubble with some text that the application set when it turned on the disabled flag. The bubble also appears if the user attempts to select the greyed-out menu item.
The bubble goes away as soon as the mouse moves away, the user gives focus to a different option, or the user clicks on the bubble.
Once you've seen the message and know why a given item is disabled, you never have to see the message again, and if you do inadvertantly trigger it, it's easy enough to get rid of it without any extra effort.
Both Windows and Mac OS X try to do this -- Windows makes the application's taskbar button blink -- but it's not completely reliable as there are API calls in both cases which can forcefully raise a window to the top that are not caught by this mechanism.
If an application creates a window (causing the flashing/bouncing) and then calls these functions it can bully its way to the foreground, as many web browsers tend to do when honouring the DOM focus() method. I've seen Firefox, IE and Safari all doing this, and Opera does it by default (within its own MDI interface) but at least provides an option to prevent it.
The NAT thingy I'm behind here (which, sadly, I did not get to choose because I'm living in someone else's house) claims to have special touches for SIP much like the special touches that most do for FTP, but it didn't actually seem to work in practice. Since it's a closed system I can't really get in there and see what it's doing.
I miss the days where my router was a Linux box. At least then when things didn't work I could actually see why. I got around the problem this time by installing Asterisk here (which I was going to do anyway, to be honest) and forwarding a suitable set of UDP ports to that. The SIP clients then proxy through Asterisk.
That's not really something that your average user can be expected to do, though. I'm not even convinced I've got it set up properly myself, since Asterisk is a powerful piece of software and with power comes complexity.
Re:Skype is only for kids anyway
on
Skype + Kazaa = ?
·
· Score: 4, Insightful
The proprietary technology always (since the Internet has become popular with non-geeks) wins. See Jabber vs. AIM/MSN Messenger.
Branding and prettiness always wins over technical superiority, especially in a world where most people are stuck behind awkward NAT gateways that they don't really understand. SIP might be open and friendly, but it's a royal pain in the ass to deploy for most home users, especially if you get two people behind the same NAT gateway wanting to use it.
Re:All those Startrek, Stargate and Galactica Geek
on
TV Piracy is Next
·
· Score: 1
Well, as far as I'm concerned the original series of Star Trek should be in the public domain by now. They've made more than enough money from their temporary artifical monopoly and now the work should be returned to the commons. I guess that's an argument for another day, though.
Re:All those Startrek, Stargate and Galactica Geek
on
TV Piracy is Next
·
· Score: 1
Actors get paid more when they are "reshown"? That's insane! It's not like they did any more work.
A flight sim is one thing which does work very well with multiple monitors; in a real plane, you are fixed in relation to your controls and the windows and you can look around you and see the world from your current POV at any angle your head can turn to so long as there is a window there. In this case, the monitors represent the windows of the plane.
In the FPS case, though, I suppose you could argue that looking at the left monitor is like turning your head to the left without changing your aim or body direction. A 360-degree display (or one of these sphere things) Is really needed here since in this kind of environment in the "real world" you'd have a full field of view; in a plane, you're restricted by where there are windows anyway. FPS with only three monitors would be like walking around with a big black partition attached to your back so you can't see outside a certain view angle, but I suppose that's no different to playing with only one monitor.
You'd still have to get used to rotating your "body" with the mouse when reacting to stimulus, though, and it would probably make lots of people motion-sick because their vision makes it look like the body is turning but the balance and so on suggest that the body is standing still. This isn't normally such an issue since without the ability to "move your head" you don't have to do the head attitude adjustment when you turn your body, and this automatic adjustment must require lots of feedback to keep you locked on to your target while turning, and the turning will generally be very fast, especially in quick-fire FPS games like Q3A and UT.
Having three monitors to give you "peripheral vision" in a first-person shooter doesn't really work, because when you are looking at the center monitor and you see something move in the left, your natural instinct is to move your head or eyes to look at that screen, not to move your mouse. When you do this, the centre monitor becomes peripheral, the left becomes main vision and the right becomes useless. A few weeks ago I saw a friend playing some game where it deliberately blurred the outer edges of the display to simulate peripheral vision, but it had no way to stop you looking at those parts of the screen with your central vision, and my friend said that it made his eyes hurt after a while.
The only way this would work is if the three monitors were strapped to your head and the game got feedback about your head movements, but lots of people seem to get motion sickness with such arrangements, and you've still got to find some way to handle the discrepency between the view angle and the weapon angle, since in most FPS games these are considered to be the same thing. You'd need some kind of gun-shaped wand to hold in your hand and have the computer detect where it is pointing, or something like that.
You missed the point. The clarifying statement is for the "computer" (really, the compiler), not for humans. It would be whatever construct is used to create a new construct in the language. Comments are for humans.
In a way, the languages of mathematics and music are natural languages. Someone didn't sit down one day and enumerate all of the rules for mathematical expressions, it evolved to suit the needs of mathematicians and has retained the flexibility that results from such evolution, much like "social" languages.
It's hard for programming languages to "evolve" in the same sense since they aren't "for humans, by humans", but we do try new language designs and find that some work better than others.
Some of the more "dynamic" languages go some way to enabling this kind of evolution. If I try to use an unusual construct in a mathematical expression, I'd probably follow it with a statement in English or mathematics explaining the meaning. If it was a useful construct, others will adopt it and slowly the explanation will become unnecessary. Likewise, in some languages we can define new constructs (within certain boundaries, of course) and tell the compiler what is meant by them in simpler terms, usually by writing some kind of function. Over time, popular constructs will be adopted as core features in newer languages. One example that springs to mind is the foreach construct, which does vary from language to language but arose because it was very common to want to visit each element in a list in turn and perform some operation on it. Modern languages have become a lot more expressive so this kind of evolution will probably become more common.
So unless there's a you method in package love, this will cause a runtime error. The following would be a little more consistant with the other examples, but less like English:
honk if $you->loves(perl);
...and if you want this to run with the strict pragma in effect, you'll have to quote the string "perl", or use a scalar variable $perl.
CSS Level 3 is not yet a W3C recommendation, which means putting it in a release browser is a risky business. Remember back to what happened when Microsoft half-implemented CSS Level 1 before it was a recommendation in Internet Explorer 3. There were at least three show-stopper bugs which held back the adoption of CSS for years.
Of course, the reason Mozilla currently has half-baked CSS3 support is that CSS2 has a few major shortcomings in the face of XML and other technologies that Mozilla makes use of. At least most of the bits they've implemented are candidate recommendations and are thus unlikely to change greatly before completion. Still, it would be much more prudent to disable it in release builds like Mozilla 1.0.
Indeed. I still use my paid-for copy of Opera 6.06. The new version has no new benefits that I appreciate and also manages to annoy me in several ways due to changes to things I've become accustomed to in version 6.
The only real drawback is that the 6.0 family is pretty buggy and unstable around certain types of image and around XML. If that instability managed to survive throughout the 5.0 and 6.0 families, though, I see no reason to trust that version 7 won't be full of similar annoyances.
It could also be argued that packing so many widgets in such a small space makes it harder to lock on to a given widget and manipulate it. This is why most programs have (by default) huge toolbars with big icons and lots of text: it gives the user a big target and therefore lots of margin for error as they throw the mouse pointer around the screen.
I tend to reconfigure my apps to have small toolbar buttons, so I'm perhaps more accustomed to this than most, but for an interface like in this program where achieving an exact value is probably quite difficult I wouldn't want to accidentally shift the wrong "knob".
I think a good alternative, which would take up a little more space, would be to have a text field with arrows to the left and right of it. Clicking once in the text field allows the user to type a value, and clicking the arrows allows fine adjustments to be made, or the user can click and drag left and right anywhere on the widget to increase and decrease the value just like the rotary knob, but with some extra on-screen affordance in the form of the arrows telling the user in which direction to move the mouse.
Best of all, the above described widget would be rectangular, so there would be enough room to throw in a readable text label above it to make it square.
It would have been better to use standard UI widgets for a lot of that stuff. When will people learn that rotary knobs do not work well in computer interfaces.
We use rotary knobs on physical devices because they are easy to manipulate by applying friction with our fingers. A far better alternative for a computer-based interface would be a slider combined with a text-entry widget to allow precise values to be entered, thus making the computer interface better than the real-life one, rather than reinventing all of the limitations of the physical interface with the extra pain of figuring out how to manipulate a turning control with a mouse pointer. They'd also have a bit more room to write a decent text label on the control, rather than the unreadable blurs they use now.
None of it goes together, either. If they'd just let the standard UI widgets render in the standard way it would have looked a lot more consistant across different parts of the application, and they'd only have had to implement special behavior for the more specialised widgets such as the waveform viewers and so forth. I suspect that as we reach higher and higher display resolutions that bitmap-based interface will end up tiny and unusable, too.
Slashdot Mirror
You forgot comma splices, they are very annoying. They seem to be everywhere recently.
My younger brother and sister (13, 17) don't seem to use email at all anymore. They got bored of it about a week after I showed them how to use it ages ago. Back then they were running Windows 95 with a single user account and were always arguing over whose account details get to stay in MSN Messenger.
Fortunately now they use Windows XP Home with separate user accounts, and leave both accounts logged in almost permanently. The arguments now are about whose desktop gets to stay visible and whose is relegated to being hidden away.
I (and they) live in England, incidentally.
I already read it! Good book. If only the people who make these errors would read it...
I'm already hypersensitive to grammar errors. I think it's something to do with how I read, but I am no psychologist.
As of late, there are comma splices everywhere. It's very frustrating. Even the packet of razors I just bought warns "Do not touch blades, it may reduce performance."
Q. I've tried reading the XML, SGML, XSL, XPATH, DSSSL or other specification, but it doesn't make any sense. There's too much jargon!
A. Specification authors deliberately obfuscate the text of ISO and W3C standards to ensure that normal people can't use the technology without assistance from the so-called "experts" who designed the specs.
Fortunately, there is a handy translation list you can use:
attribute tag attribute value tag character reference tag comment tag document type declaration tag element tag entity reference tag literal tag numeric character reference tag tag commandWith the help of this table, even Visual Basic programmers should have no trouble deciphering ISO prose.
(From the comp.text.sgml FAQ list; completely butchered thanks to slashdot's amazing lameness filter.)
There are a few ways around this problem. Here's one, as an example:
Menu items are still greyed out, but hovering the mouse pointer over them produces a help bubble with some text that the application set when it turned on the disabled flag. The bubble also appears if the user attempts to select the greyed-out menu item.
The bubble goes away as soon as the mouse moves away, the user gives focus to a different option, or the user clicks on the bubble.
Once you've seen the message and know why a given item is disabled, you never have to see the message again, and if you do inadvertantly trigger it, it's easy enough to get rid of it without any extra effort.
The ELEVENTH October in 2004? Wow! October has been busy this year.
Both Windows and Mac OS X try to do this -- Windows makes the application's taskbar button blink -- but it's not completely reliable as there are API calls in both cases which can forcefully raise a window to the top that are not caught by this mechanism.
If an application creates a window (causing the flashing/bouncing) and then calls these functions it can bully its way to the foreground, as many web browsers tend to do when honouring the DOM focus() method. I've seen Firefox, IE and Safari all doing this, and Opera does it by default (within its own MDI interface) but at least provides an option to prevent it.
The NAT thingy I'm behind here (which, sadly, I did not get to choose because I'm living in someone else's house) claims to have special touches for SIP much like the special touches that most do for FTP, but it didn't actually seem to work in practice. Since it's a closed system I can't really get in there and see what it's doing.
I miss the days where my router was a Linux box. At least then when things didn't work I could actually see why. I got around the problem this time by installing Asterisk here (which I was going to do anyway, to be honest) and forwarding a suitable set of UDP ports to that. The SIP clients then proxy through Asterisk.
That's not really something that your average user can be expected to do, though. I'm not even convinced I've got it set up properly myself, since Asterisk is a powerful piece of software and with power comes complexity.
The proprietary technology always (since the Internet has become popular with non-geeks) wins. See Jabber vs. AIM/MSN Messenger.
Branding and prettiness always wins over technical superiority, especially in a world where most people are stuck behind awkward NAT gateways that they don't really understand. SIP might be open and friendly, but it's a royal pain in the ass to deploy for most home users, especially if you get two people behind the same NAT gateway wanting to use it.
Well, as far as I'm concerned the original series of Star Trek should be in the public domain by now. They've made more than enough money from their temporary artifical monopoly and now the work should be returned to the commons. I guess that's an argument for another day, though.
Actors get paid more when they are "reshown"? That's insane! It's not like they did any more work.
A flight sim is one thing which does work very well with multiple monitors; in a real plane, you are fixed in relation to your controls and the windows and you can look around you and see the world from your current POV at any angle your head can turn to so long as there is a window there. In this case, the monitors represent the windows of the plane.
In the FPS case, though, I suppose you could argue that looking at the left monitor is like turning your head to the left without changing your aim or body direction. A 360-degree display (or one of these sphere things) Is really needed here since in this kind of environment in the "real world" you'd have a full field of view; in a plane, you're restricted by where there are windows anyway. FPS with only three monitors would be like walking around with a big black partition attached to your back so you can't see outside a certain view angle, but I suppose that's no different to playing with only one monitor.
You'd still have to get used to rotating your "body" with the mouse when reacting to stimulus, though, and it would probably make lots of people motion-sick because their vision makes it look like the body is turning but the balance and so on suggest that the body is standing still. This isn't normally such an issue since without the ability to "move your head" you don't have to do the head attitude adjustment when you turn your body, and this automatic adjustment must require lots of feedback to keep you locked on to your target while turning, and the turning will generally be very fast, especially in quick-fire FPS games like Q3A and UT.
Having three monitors to give you "peripheral vision" in a first-person shooter doesn't really work, because when you are looking at the center monitor and you see something move in the left, your natural instinct is to move your head or eyes to look at that screen, not to move your mouse. When you do this, the centre monitor becomes peripheral, the left becomes main vision and the right becomes useless. A few weeks ago I saw a friend playing some game where it deliberately blurred the outer edges of the display to simulate peripheral vision, but it had no way to stop you looking at those parts of the screen with your central vision, and my friend said that it made his eyes hurt after a while.
The only way this would work is if the three monitors were strapped to your head and the game got feedback about your head movements, but lots of people seem to get motion sickness with such arrangements, and you've still got to find some way to handle the discrepency between the view angle and the weapon angle, since in most FPS games these are considered to be the same thing. You'd need some kind of gun-shaped wand to hold in your hand and have the computer detect where it is pointing, or something like that.
I think you mean "Macrovision".
I wonder why no-one makes VCRs where you can disable the auto-gain and do it manually. I guess it's just something I don't know about video signals.
You missed the point. The clarifying statement is for the "computer" (really, the compiler), not for humans. It would be whatever construct is used to create a new construct in the language. Comments are for humans.
In a way, the languages of mathematics and music are natural languages. Someone didn't sit down one day and enumerate all of the rules for mathematical expressions, it evolved to suit the needs of mathematicians and has retained the flexibility that results from such evolution, much like "social" languages.
It's hard for programming languages to "evolve" in the same sense since they aren't "for humans, by humans", but we do try new language designs and find that some work better than others.
Some of the more "dynamic" languages go some way to enabling this kind of evolution. If I try to use an unusual construct in a mathematical expression, I'd probably follow it with a statement in English or mathematics explaining the meaning. If it was a useful construct, others will adopt it and slowly the explanation will become unnecessary. Likewise, in some languages we can define new constructs (within certain boundaries, of course) and tell the compiler what is meant by them in simpler terms, usually by writing some kind of function. Over time, popular constructs will be adopted as core features in newer languages. One example that springs to mind is the foreach construct, which does vary from language to language but arose because it was very common to want to visit each element in a list in turn and perform some operation on it. Modern languages have become a lot more expressive so this kind of evolution will probably become more common.
Of course, what this is really doing is:
So unless there's a you method in package love, this will cause a runtime error. The following would be a little more consistant with the other examples, but less like English:
...and if you want this to run with the strict pragma in effect, you'll have to quote the string "perl", or use a scalar variable $perl.
CSS Level 3 is not yet a W3C recommendation, which means putting it in a release browser is a risky business. Remember back to what happened when Microsoft half-implemented CSS Level 1 before it was a recommendation in Internet Explorer 3. There were at least three show-stopper bugs which held back the adoption of CSS for years.
Of course, the reason Mozilla currently has half-baked CSS3 support is that CSS2 has a few major shortcomings in the face of XML and other technologies that Mozilla makes use of. At least most of the bits they've implemented are candidate recommendations and are thus unlikely to change greatly before completion. Still, it would be much more prudent to disable it in release builds like Mozilla 1.0.
Indeed. I still use my paid-for copy of Opera 6.06. The new version has no new benefits that I appreciate and also manages to annoy me in several ways due to changes to things I've become accustomed to in version 6.
The only real drawback is that the 6.0 family is pretty buggy and unstable around certain types of image and around XML. If that instability managed to survive throughout the 5.0 and 6.0 families, though, I see no reason to trust that version 7 won't be full of similar annoyances.
It could also be argued that packing so many widgets in such a small space makes it harder to lock on to a given widget and manipulate it. This is why most programs have (by default) huge toolbars with big icons and lots of text: it gives the user a big target and therefore lots of margin for error as they throw the mouse pointer around the screen.
I tend to reconfigure my apps to have small toolbar buttons, so I'm perhaps more accustomed to this than most, but for an interface like in this program where achieving an exact value is probably quite difficult I wouldn't want to accidentally shift the wrong "knob".
I think a good alternative, which would take up a little more space, would be to have a text field with arrows to the left and right of it. Clicking once in the text field allows the user to type a value, and clicking the arrows allows fine adjustments to be made, or the user can click and drag left and right anywhere on the widget to increase and decrease the value just like the rotary knob, but with some extra on-screen affordance in the form of the arrows telling the user in which direction to move the mouse.
Best of all, the above described widget would be rectangular, so there would be enough room to throw in a readable text label above it to make it square.
It would have been better to use standard UI widgets for a lot of that stuff. When will people learn that rotary knobs do not work well in computer interfaces.
We use rotary knobs on physical devices because they are easy to manipulate by applying friction with our fingers. A far better alternative for a computer-based interface would be a slider combined with a text-entry widget to allow precise values to be entered, thus making the computer interface better than the real-life one, rather than reinventing all of the limitations of the physical interface with the extra pain of figuring out how to manipulate a turning control with a mouse pointer. They'd also have a bit more room to write a decent text label on the control, rather than the unreadable blurs they use now.
None of it goes together, either. If they'd just let the standard UI widgets render in the standard way it would have looked a lot more consistant across different parts of the application, and they'd only have had to implement special behavior for the more specialised widgets such as the waveform viewers and so forth. I suspect that as we reach higher and higher display resolutions that bitmap-based interface will end up tiny and unusable, too.
I really love the idea of telling someone, "I'll be with you in just a few megaseconds..."
Version 2.91 has the media library.