US federal sites, and intranet applications may soon be required to meet conditions under Section 508 of the Rehabilitation Act which may make it difficult for them to create sites which only work with one browser, although not completely preventing their exploiting features of specific browsers.
I'm much more likely to go for the plain text web site. In the case of the flashy one, I may well have backed out long before the graphics have loaded. If I get past that, I'm likely to get angry at the dead javascript: links. If I stick with the page after that, it is likely to be to try and find webmaster contact information (by which point I'm probably in view source mode), although the chances of webmaster bouncing are high and the chances of any response, let alone a response that acknowledges the problem, is low.
Kinda back to the #1 application on my wish list for *nix. A decent GUI HTML editor.
Have you looked at Amaya. It's open source, so you can contribute your own improvments. Some say it has a quirky user interface, and I tend to use it for proofing, and author directly in HTML.
One problem, though, with HTML, is that it is not a WYSIWYG language, and W....G editors tend to fool people into thinking that the page will look the same in all browsers (even screenreaders?!), and to select elements for their appearance, not their true meaining. Use PDF now, and SVG, in the future, if WYSIWYG is important to you.
a technical inability on the developers' part to create a site that was functional across multiple platforms.
What makes designers go browser dependent is aiming for appearance, and because they think they know better ways to implement user interface elements than the browser writers. Most sites could be functional on HTML 2.
Unlike PDF, HTML was not designed to control appearance, but commercial page developers pretend that it was.
I nearly always get frustrated by second line commercial web pages (most of them). Not only does their attempt to be clever usually break for me, but I'm sure that a lot of people have difficulty in working out their user interface conventions.
I should add, that whilst fourth root for range may not seem that bad, the number of candidates stars depends on the cube of the range, out to a few hundred light years, so the 100 million, or so, bandwidth discrepancy will result in about a million times less chance of detection for the same total signal duration and mean transmit power, compared with a CW beacon at the minimum useful bandwidth.
The limited in beam time may well further reduce the candidates by a factor of over a thousand.
NORAD's multiple radar installations give out enough narrow beam radio to be picked up as far as 50 light years away.
Military radars tend to be wideband. If they actually pointed in one direction in space, the range would go off as the fourth root of the bandwidth. They don't point in a constant direction, so the observation time will be limited. Once you exceed a time of about 1/(bandwidth) the range is proportional to the fourth root of the observation time if you tune the observation time to the in beam time, and the square root if you use a fixed observation time.
SETI@Home has a bandwidth that is 100s to 1000s of times too narrow to be optimum for such radar (square root penalty, I think) and uses a fixed observation time for the purposes of the above range formulae.
The power that one has to consider for such calculations is not the peak power, but the average power.
The one sort of radar that definitely does have the necessary characteristics for detection at well over 50 light years is CW Doppler radar used by Arecibo, Goldstone and others for measuring asteroid orbital paremeters. This has a relatively constant direction (they know where to point from optical observations). It's disadvantage, which it tends to share with other radars, is that it unlikely to produce more than one detection, which means that it can't be confirmed; I think some people suspect that we may already have detected such signals, but have to discount them as one off events.
All our attempts to send our own messges have used this sort of planetary radar transmitter.
Listening on 1.42GHz tends to favour intentional contact signals over leakage. Although the SETI@Home configuration can't achieve this, Arecibo ought to be able to detect its own radar transmissions across the galaxy.
There is a shared memory interface to a separate graphical display on the Unix version. I have a feeling that the specification for that interface has been published, but I can't find it at the moment.
Many of the graphical features are available using third party tools, using data in the state.sah file; it's basically only the real time spectrum and the real time amplitude profiles that require a special interface.
This project should do rough curve fitting first (ie do quick calculations on client computers, to find a general idea of the curve) and then select areas of interest to farm out more signifigant data to client computers.
I think you miss the point of the clients in SETI@Home. The purpose of the clients is to do the pre-filtering, so that Berkeley has a manageable number of candidates for subsequent processing.
The only real curves they have to work with are the curves of event rate against detection threshold, and they had good ideas of those already; these are used to set the reporting thresholds for the clients. They will consider themselves very lucky if they find even one confirmed ET, so they are not trying to construct maps of ET density.
The original concept did assume restricting the work units to ones from the plane of our galaxy, as those would give the highest proportion of Sun-like stars, but that was when they didn't think they would have enough clients to process all the data.
Unless and until we have detected several ETs (who may then tell us where to look for the others!) we have no means of calibrating any rules we use to select good candidates.
The much earlier one, from Arecibo, was somewhere around 2,250 MHz, although I cannot find a reference to positively confirm that just now.
These frequencies are chosen because they are the frequencies of existing planetary radar transmitters, and, in turn, might represent frequencies near military radar frequencies; they were not chosen because of any likely significance to ET.
Some of the signals have been sent to stars that are close (as stars go) and some to other galaxies.
The Arecibo message was sent to the (historic) position of a globular cluster (M13) in our own galaxy. The Encounter 2001 messges were sent to the (proper motion and light time corrected) locations of relatively close stars.
It's actually about 1,420MHz, not 1,450MHz. We are not transmitting at that frequency because of an international convention that preserves it for radio astronomy, because it is a frequency emitted by hydrogen clouds in interstellar space.
It's chosen for SETI@Home, because:
they only have the data-logging and work unit splitting capabilities for a single 2.5MHz at a time;
because we don't transmit on it, there is relatively little local interference;
because it is a key frequency for radio astronomy, it is assumed that an ET sending a
deliberate signal might be more likely to chose it than other frequencies.
There are conflicts in SETI@Home, in that they are looking at this frequency, which is a presumed beacon frequency, but, at the same time, searching a wide range of chirp values. One fairly reasonable assumption is that a beacon would have the chirp pre-cancelled in the direction of the target, resulting in all the signals only having the chirp predicatable from the
earth's motion.
Currently, there are political (risk of first strike and fear of promoting one particular ideology) and financial (high power transmitters are costly to run) problems with transmitting our own beacon.
success means that they have significantly reduced the uncertainty as to whether a signal exists. Although it would
be nice to have a result that positively confirms
existence, it is also a success if they can say that, in spite of machine errors, forgeries, etc., the probability that there is a signal above a certain level has been reduced by an
amount significantly larger than the error
margin of the process.
It is bad, but not quite as bad as indicated. The underlying problem here is that the W3C's validation tools is currently configured to default to XHTML when the document type is unspecified (it used to default to HTML 2, which is more correct). One still gets about 8 screenfuls of errors if one validates it against the HTML 4 DTD. I believe it has been mentioned as a broken site on the Lynx mailing list. To allow it to be validated properly, they need to add: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> before the <html>
The problem with Bobby is that usability can only be determined in the end by a human. The W3C usability ratings, mentioned elsewhere, acknowledge this, but I know of one site that flaunts a Bobby Approved status, but actually doesn't have a single Hn element on the page, even though the layout appears to have headings, and doesn't have a single LI, even though there are many lists in the menus.
On the other hand, those only paying lip service are likely to interpret guidelines in their own favour.
Slashdot Mirror
US federal sites, and intranet applications may soon be required to meet conditions under Section 508 of the Rehabilitation Act which may make it difficult for them to create sites which only work with one browser, although not completely preventing their exploiting features of specific browsers.
I'm much more likely to go for the plain text web site. In the case of the flashy one, I may well have backed out long before the graphics have loaded. If I get past that, I'm likely to get angry at the dead javascript: links. If I stick with the page after that, it is likely to be to try and find webmaster contact information (by which point I'm probably in view source mode), although the chances of webmaster bouncing are high and the chances of any response, let alone a response that acknowledges the problem, is low.
Have you looked at Amaya. It's open source, so you can contribute your own improvments. Some say it has a quirky user interface, and I tend to use it for proofing, and author directly in HTML.
One problem, though, with HTML, is that it is not a WYSIWYG language, and W....G editors tend to fool people into thinking that the page will look the same in all browsers (even screenreaders?!), and to select elements for their appearance, not their true meaining. Use PDF now, and SVG, in the future, if WYSIWYG is important to you.
What makes designers go browser dependent is aiming for appearance, and because they think they know better ways to implement user interface elements than the browser writers. Most sites could be functional on HTML 2.
Unlike PDF, HTML was not designed to control appearance, but commercial page developers pretend that it was.
I nearly always get frustrated by second line commercial web pages (most of them). Not only does their attempt to be clever usually break for me, but I'm sure that a lot of people have difficulty in working out their user interface conventions.
I should add, that whilst fourth root for range may not seem that bad, the number of candidates stars depends on the cube of the range, out to a few hundred light years, so the 100 million, or so, bandwidth discrepancy will result in about a million times less chance of detection for the same total signal duration and mean transmit power, compared with a CW beacon at the minimum useful bandwidth.
The limited in beam time may well further reduce the candidates by a factor of over a thousand.
Military radars tend to be wideband. If they actually pointed in one direction in space, the range would go off as the fourth root of the bandwidth. They don't point in a constant direction, so the observation time will be limited. Once you exceed a time of about 1/(bandwidth) the range is proportional to the fourth root of the observation time if you tune the observation time to the in beam time, and the square root if you use a fixed observation time.
SETI@Home has a bandwidth that is 100s to 1000s of times too narrow to be optimum for such radar (square root penalty, I think) and uses a fixed observation time for the purposes of the above range formulae.
The power that one has to consider for such calculations is not the peak power, but the average power.
The one sort of radar that definitely does have the necessary characteristics for detection at well over 50 light years is CW Doppler radar used by Arecibo, Goldstone and others for measuring asteroid orbital paremeters. This has a relatively constant direction (they know where to point from optical observations). It's disadvantage, which it tends to share with other radars, is that it unlikely to produce more than one detection, which means that it can't be confirmed; I think some people suspect that we may already have detected such signals, but have to discount them as one off events.
All our attempts to send our own messges have used this sort of planetary radar transmitter.
Listening on 1.42GHz tends to favour intentional contact signals over leakage. Although the SETI@Home configuration can't achieve this, Arecibo ought to be able to detect its own radar transmissions across the galaxy.
There is a shared memory interface to a separate graphical display on the Unix version. I have a feeling that the specification for that interface has been published, but I can't find it at the moment.
Many of the graphical features are available using third party tools, using data in the state.sah file; it's basically only the real time spectrum and the real time amplitude profiles that require a special interface.
I think you miss the point of the clients in SETI@Home. The purpose of the clients is to do the pre-filtering, so that Berkeley has a manageable number of candidates for subsequent processing.
The only real curves they have to work with are the curves of event rate against detection threshold, and they had good ideas of those already; these are used to set the reporting thresholds for the clients. They will consider themselves very lucky if they find even one confirmed ET, so they are not trying to construct maps of ET density.
The original concept did assume restricting the work units to ones from the plane of our galaxy, as those would give the highest proportion of Sun-like stars, but that was when they didn't think they would have enough clients to process all the data.
Unless and until we have detected several ETs (who may then tell us where to look for the others!) we have no means of calibrating any rules we use to select good candidates.
Except possibly for some, low power, illicit, transmissions, we've never transmitted on the hydrogen line.
I think you may be thinking of the Encounter 2001 transmissions (science URL given, not the commercial one). These used 5,010.024 Mhz.
The much earlier one, from Arecibo, was somewhere around 2,250 MHz, although I cannot find a reference to positively confirm that just now.
These frequencies are chosen because they are the frequencies of existing planetary radar transmitters, and, in turn, might represent frequencies near military radar frequencies; they were not chosen because of any likely significance to ET.
The Arecibo message was sent to the (historic) position of a globular cluster (M13) in our own galaxy. The Encounter 2001 messges were sent to the (proper motion and light time corrected) locations of relatively close stars.
It's actually about 1,420MHz, not 1,450MHz. We are not transmitting at that frequency because of an international convention that preserves it for radio astronomy, because it is a frequency emitted by hydrogen clouds in interstellar space.
It's chosen for SETI@Home, because:
There are conflicts in SETI@Home, in that they are looking at this frequency, which is a presumed beacon frequency, but, at the same time, searching a wide range of chirp values. One fairly reasonable assumption is that a beacon would have the chirp pre-cancelled in the direction of the target, resulting in all the signals only having the chirp predicatable from the earth's motion.
Currently, there are political (risk of first strike and fear of promoting one particular ideology) and financial (high power transmitters are costly to run) problems with transmitting our own beacon.
success means that they have significantly reduced the uncertainty as to whether a signal exists. Although it would be nice to have a result that positively confirms existence, it is also a success if they can say that, in spite of machine errors, forgeries, etc., the probability that there is a signal above a certain level has been reduced by an amount significantly larger than the error margin of the process.
It is bad, but not quite as bad as indicated. The underlying problem here is that the W3C's validation tools is currently configured to default to XHTML when the document type is unspecified (it used to default to HTML 2, which is more correct). One still gets about 8 screenfuls of errors if one validates it against the HTML 4 DTD. I believe it has been mentioned as a broken site on the Lynx mailing list. To allow it to be validated properly, they need to add: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> before the <html>
Jakob Nielsen has published a book Design Web Usability: The Practice of Simplicity.
This has apparently topped Amazon's best selling computing books since early January.
The problem with Bobby is that usability can only be determined in the end by a human. The W3C usability ratings, mentioned elsewhere, acknowledge this, but I know of one site that flaunts a Bobby Approved status, but actually doesn't have a single Hn element on the page, even though the layout appears to have headings, and doesn't have a single LI, even though there are many lists in the menus.
On the other hand, those only paying lip service are likely to interpret guidelines in their own favour.