I don't know why they say that text-based games are dying. Muds are still very popular...
The "article" in question is pretty lightweight, but judging from the examples given (all Infocom titles), Kevin Bowen likely equates "text adventure" with "traditional interactive fiction" ca. 1984.
Sad to say, but by making the conceptual leap from "text adventure" to "text-based games" and then onto MUDs (MOOs, MUSHes, etc.), you seem to have put more thought into the subject than the GameSpy author himself.:p
There are better obsfucators available. [link omitted]
The pitch for YASS (Yet Another Silly Script) aside, that solution isn't exactly 'better':
The original email address is still nicely present in a foo@bar.baz format as a single string entity - how is this any more difficult to parse?
Denying an email address to those who've disabled JavaScript seems a bit arbitrary.
Adding about 0.5 KB to a document just to hide a multi*byte* email address seems less than optimal from an efficiency standpoint.
Of course, two of three of those problems can be overcome through inclusion of the script as an external resource (rather than an inline element) with some tweaking of the code presentation.
But the 'solution' arbitrarily excludes a (likely small) population of users from actually accessing your email address.
If the whole point is to hide the actual email address, push it to the server-side (peddling a client-side JavaScripted solution is sub-par) and use a contact form. If the point is to present the actual email address (in cases where hiding behind a contact form sends the wrong message to your audience), I'm not certain turning to JavaScript offers all that much protection over plain markup obfuscation. Logically, it might, but at what additional cost?
I remain skeptical that HTML character encodings are enough, but perhaps it is so (still) given the CDT finding. One might combine it with the table-split solution offered up-thread. Turning to JavaScript doesn't offer enough demonstrable benefit to warrant usage.
Now, if one would conduct a nice controlled study of the differing techniques...
I have multiple domain names and I know for certain that much of my spam originated from either scanning the whois database, or someone selling the e-mail addresses from there.
This is true for me, as well. Along with spam targeted to generic accounts (info@... is a favorite for domain-related services spam). Unfortunately, this class of unasked-for email falls outside the scope of the posted CDT study.
Web Sites received the most e-mails when an address was placed visibly on a public Web site. Spammers use software harvesting programs such as "robots" or "spiders" to record e-mail addresses... E-mail addresses posted to Web sites using these conventions [Replacing characters in an e-mail address with HTML equivalents.] did not receive any spam.
The above CDT finding is mildly surprising to me. Is there a reason people haven't built 'smarter' Web scrapers that filter and convert character encodings of things like the '@' sign in email addys? Doesn't seem too difficult, but if the report is to be taken at face value, it seems a simple precaution to take (still). I had always considered it a low-tech defense easily overwhelemed. Guess I was wrong?
I'm down with modern-day new-fangled design strategies, but sometimes a table does exactly what I need, with a minimum of effort. Am I evil?
No, but if you're going to use them (on say... your/. link) you should probably make certain they don't explode at font-sizes other than the one on your development platform (for example, on say... your/. link).:p
Millions of little plastic boxes eating up electricity in millions of homes is bound to be less efficient than voice messaging at a central server.
From a big-picture perspective, probably. However, voice mail is always(?) an added-value service for which the phone co. will charge on a monthly basis (at least that is my experience). From the vantage of the cheapskate user, it makes more fiscal sense to purchase a simple answering machine once than pay for voice mail service each and every month.
If it's that important to reach someone, people will call back.
Remember that Amazon OWNS IMDb, which is why you see Amazon links and ads all over the site. Yet IMDb is vastly superior to the information contained within Amazon itself.
The above is mostly true, but the one thing that has always bothered me about the Amazon-IMDb connection is the selection of representative images on IMDb associated with a given film. Far too often, original poster art is tossed for the Amazon scan of the latest DVD release, which pictures a studio's latest imagining of what marketable cover art should be. Other times, the two seem unable to keep in synch, with IMDb lacking an image readily available on Amazon.
Incredibly trivial, but trivia is what draws people to IMDb in part, so it irritates like that one grain of sand in a shoe after having walked the beach. Whomever works that side of things for Amazon/IMDb should be pulled aside and given a stern talking-to about the fine line between cross-selling and degrading value.
(Yes, IMDb will link out to filmsite.org or some retailer for additional poster art, but it's a shameless hack when the image primarily associated with a flick is the DVD du jour.)
Why put into an application that which should be part of the OS?
Of course, another way to run with this observation would be to provide standard, OS-level (sub-)partitioning of windowed applications through tabs: tabbed Internet Explorer, tabbed Microsoft Word, tabbed Notepad, tabbed Minesweeper...
With the hypothetical of fifteen or thirty browser views open simultaneously, I'd have to taskbar switch through all those and whatever other applications may be running. With tabs, one has to switch through only the views once focused on the browser application itself. There ought to be an elegant way to handle application-to-view cross-over to permit fluid context switching, such that one can grossly cycle through open apps then 'fine tune' his or her way through particular views for each without breaking stride or having to cycle through all views for all apps on the sole metaphorical level of the taskbar (or whatever).
I haven't toyed with the collapsed/grouped taskbar mechanism of Windows XP a whole lot, but was that feature meant to offer something akin to the above scheme of context-switching?
One way around this is to load the 'print view', if the web developer had enough insight to include one.
Though well-meaning, that's a terrible option to exercise and a pattern of behavior that shouldn't be forced on Web readers (though likely has been through a number of sites).
Including a 'print view' is usually less a matter of designer insight and more an expression that existing site layout and design runs counter to efficient reading of Web content. There may be occasion to reach for it for certain materials (e.g. extended essays or subdivisions of a book-length work reproduced on the Web), but the the 'print view' mechanism broadly attaches itself to severely disjointed presentation of content.
Anyway, one can only hope that in a year or two (at the glacial rate of standards uptake) use of CSS-defined print presentation wears away at this method of content stitching.:p
MOO3 is what we in open source would call a "Release Candidate". I am amazed that Infogrames actually let this one out of the door at this stage.
The reverse cover of the first Civ III manual reads: "Master of Orion III - You've conquered the Earth, now master the galaxy. First contact begins Q1 2002 for the PC and Macintosh platforms."
Yhe release found its own way out after the hinges on the door had rusted away.
Why not get one of these [miniITX systems] and run this [VICE emulator]?
In three words: no cartridge port.
There's a sublime physical value to plugging in a game cartridge instead of simply loading a ROM image. Then again, there were far more diskette or cassette based games for the C64, so I might as well shut up.
The first result to that query [...] does appear to be up...
You're posting two plus days, one more email to support (see thread), and a direct removal request (see thread) by me later... they did finally kill the errant entry. One year after it was removed from the 'Net, but still it's gone.
I hadn't really thought about it til I read your replies, but I hardly ever click the top result.
Sounds like a variant of "banner blindness"... Google Goggles?
As to indexing dead links, since the alternative of finding a dead page in Google's cache is useful [...]
Ah, but the cited example doesn't offer a cached version. So much for that.
Google cache is only beneficial in cases where the page no longer exists or cannot be accessed. Neat and all, but of use to only a small portion of users, I would think. For sites which update frequently (given the general lag in Google indexing), a cached version is detrimental, since the content would not accurately reflect the "true" site.
The benefit in other cases is broadly questionable, as "dead" sites are (usually) pruned from Google's index, along with cached contents.
Apart from Slashdotted servers where Google already indexed the content (not likely for new documents), the window of utility is limited -- assuming that people can keep their servers up. I would suggest that archive.org serves the same purpose nicely, but that collection has its own troubles.
Perhaps Google should INDICATE known dead links.
Perhaps Google shouldn't index dead links at all. There's geek chic in placing document copies in cache, but that's about it. Google only caches the document, not the images or other embedded content, or referenced stylesheets or script elements. For many, many sites (unfortunately) much is lost in retrieving only the base document. This again reduces utility.
Favoring inclusion of "dead" documents will quickly lead to an immense repository of this and that, some live and some not. Sounds an awful lot like archive.org and I don't really understand why Google would even bother. Indexing dead pages (cache or no cache) only clutters up results and confuses what one is actually searching.
Flagging the dead from the living isn't a whole solution, but it's a start. Although, were Google to team up with archive.org to permit cross-linking and separation of duties (live Web / dead Web) that might make a bit more sense (to me). I doubt that will happen, given the ties of archive.org to another search technology.
Your job, as a webmaster, is to produce a user friendly, useful, maybe informative website.
Google's job, as a search engine, is to find the sites most likely to be of interest to a user, based on their search terms.
And somewhere in the middle, the two concerns meet. There are a *lot* of unintentionally odd entries in Google that should be cleared out as misleading. Three examples: (1) Redirection URLs from one site but content from the targeted site; (2) Past versions of multi-version documents such as Wiki revision URLs; and (3) Static redirection documents from relocated sites.
All should probably be combatted by site maintainers through application of robot exclusion rules and a little redirection know-how. However, given the frequency with which I've encounted these awkward entries, I'm guessing that attention to such detail has gone by the wayside.
But the next few pages are full of good hits. So is your point that people never check anything but the first result, or that google is not allowed to have 1 page out of several dozen be a bad hit?
My point is that Google decidedly indexes and top ranks "dead" sites. Check that. *Long* dead sites. I can accept a dead entry for a recently pulled site. I might even be tempted to accept a dead entry for a site pulled several months ago should it be ranked deep within a given set of results. But to top rank a site gone for twelve months or more points to exceedingly flaky behind-the-scenes behavior on the part of Google. Whether results [2.. n] are valid has no bearing on my position.
As to whether people only check the first result: Judging from traffic to my sites through Google and the corresponding ranking of them over time, it would seem that people do frequent top-most entries more than bottom-most. That's common sense. Regardless, I would hazard the guess that leaving a "first" entry broken for so long collectively wastes many people's time. It certainly doesn't put a best foot forward in quelling concerns about the relevance of Google search results, does it?
I got a helluva lot of dead links and blank pages.
Definitely so - check the first result. This is nothing new. For the referenced query, the faulty top-ranking has existed for a long time, though the site in question hasn't existed for over a year. I've even written support a number of times (blatant errors such as these are shameful). Google is far from perfect.
We who are editors at dmoz hold a lot of power right now.
I fear that is all too true. I have encountered Google entries ranked "top five" in result sets of greater than 10,000 members where: (a) the search term(s) are not present in the document; (b) no other Google-indexed document links to the one in question; (c) sole use of the search term(s) is in a DMOZ listing of the document.
It would seem that getting listed on DMOZ can really affect Google "placement" -- I cannot determine whether this is the result of simply weighting DMOZ or due to a "multiplier effect" as Google indexes all those many, many sites who utilize the RDF generated by the Open Directory Project.
Then again, Google top-ranks a Web site that hasn't been on the Web in over a year for one query I run with frequency. I don't think I can point the finger at the ODP for that one.
At Google, go to the "Directory" tab, or go to DMOZ.org (Open Directory) itself. DMOZ is bigger, better organized, has fewer broken links, no ads, and is built by hand by people who know their categories and are interested in keeping them linking only to sites with meaningful content.
First, I would suggest going directly to the categories at dmoz.org rather than the Google relistings. Google picks up revised RDF dumps from DMOZ whenever they please, but the lag in the cycle is pretty long. If you are looking for the "fresher" data, go directly to the source.
Second, DMOZ can become what you say it is only with proper editing. The project itself may list 50000+ editors, but they're volunteers and there is a lot of ground to cover. A large number of edits are made by those "high up" in the directory structure to "lower"/"deeper" categories less well understood. Certain branches of the project are neglected; others eat editors for breakfast with the amount of work that needs to be done. Volunteer and help out.
Slashdot Mirror
The "article" in question is pretty lightweight, but judging from the examples given (all Infocom titles), Kevin Bowen likely equates "text adventure" with "traditional interactive fiction" ca. 1984.
Sad to say, but by making the conceptual leap from "text adventure" to "text-based games" and then onto MUDs (MOOs, MUSHes, etc.), you seem to have put more thought into the subject than the GameSpy author himself. :p
The pitch for YASS (Yet Another Silly Script) aside, that solution isn't exactly 'better':
Of course, two of three of those problems can be overcome through inclusion of the script as an external resource (rather than an inline element) with some tweaking of the code presentation. But the 'solution' arbitrarily excludes a (likely small) population of users from actually accessing your email address.
If the whole point is to hide the actual email address, push it to the server-side (peddling a client-side JavaScripted solution is sub-par) and use a contact form. If the point is to present the actual email address (in cases where hiding behind a contact form sends the wrong message to your audience), I'm not certain turning to JavaScript offers all that much protection over plain markup obfuscation. Logically, it might, but at what additional cost?
I remain skeptical that HTML character encodings are enough, but perhaps it is so (still) given the CDT finding. One might combine it with the table-split solution offered up-thread. Turning to JavaScript doesn't offer enough demonstrable benefit to warrant usage.
Now, if one would conduct a nice controlled study of the differing techniques...
This is true for me, as well. Along with spam targeted to generic accounts (info@... is a favorite for domain-related services spam). Unfortunately, this class of unasked-for email falls outside the scope of the posted CDT study.
The above CDT finding is mildly surprising to me. Is there a reason people haven't built 'smarter' Web scrapers that filter and convert character encodings of things like the '@' sign in email addys? Doesn't seem too difficult, but if the report is to be taken at face value, it seems a simple precaution to take (still). I had always considered it a low-tech defense easily overwhelemed. Guess I was wrong?
To save some the effort: Marlen Cowpland
No, but if you're going to use them (on say ... your /. link) you should probably make certain they don't explode at font-sizes other than the one on your development platform (for example, on say ... your /. link). :p
From a big-picture perspective, probably. However, voice mail is always(?) an added-value service for which the phone co. will charge on a monthly basis (at least that is my experience). From the vantage of the cheapskate user, it makes more fiscal sense to purchase a simple answering machine once than pay for voice mail service each and every month.
If it's that important to reach someone, people will call back.
The above is mostly true, but the one thing that has always bothered me about the Amazon-IMDb connection is the selection of representative images on IMDb associated with a given film. Far too often, original poster art is tossed for the Amazon scan of the latest DVD release, which pictures a studio's latest imagining of what marketable cover art should be. Other times, the two seem unable to keep in synch, with IMDb lacking an image readily available on Amazon.
Incredibly trivial, but trivia is what draws people to IMDb in part, so it irritates like that one grain of sand in a shoe after having walked the beach. Whomever works that side of things for Amazon/IMDb should be pulled aside and given a stern talking-to about the fine line between cross-selling and degrading value.
(Yes, IMDb will link out to filmsite.org or some retailer for additional poster art, but it's a shameless hack when the image primarily associated with a flick is the DVD du jour.)
Of course, another way to run with this observation would be to provide standard, OS-level (sub-)partitioning of windowed applications through tabs: tabbed Internet Explorer, tabbed Microsoft Word, tabbed Notepad, tabbed Minesweeper...
With the hypothetical of fifteen or thirty browser views open simultaneously, I'd have to taskbar switch through all those and whatever other applications may be running. With tabs, one has to switch through only the views once focused on the browser application itself. There ought to be an elegant way to handle application-to-view cross-over to permit fluid context switching, such that one can grossly cycle through open apps then 'fine tune' his or her way through particular views for each without breaking stride or having to cycle through all views for all apps on the sole metaphorical level of the taskbar (or whatever).
I haven't toyed with the collapsed/grouped taskbar mechanism of Windows XP a whole lot, but was that feature meant to offer something akin to the above scheme of context-switching?
Though well-meaning, that's a terrible option to exercise and a pattern of behavior that shouldn't be forced on Web readers (though likely has been through a number of sites).
Including a 'print view' is usually less a matter of designer insight and more an expression that existing site layout and design runs counter to efficient reading of Web content. There may be occasion to reach for it for certain materials (e.g. extended essays or subdivisions of a book-length work reproduced on the Web), but the the 'print view' mechanism broadly attaches itself to severely disjointed presentation of content.
Anyway, one can only hope that in a year or two (at the glacial rate of standards uptake) use of CSS-defined print presentation wears away at this method of content stitching. :p
The reverse cover of the first Civ III manual reads: "Master of Orion III - You've conquered the Earth, now master the galaxy. First contact begins Q1 2002 for the PC and Macintosh platforms."
Yhe release found its own way out after the hinges on the door had rusted away.
Fahrenheit.
What's wrong: the average /.'er was probably born in an era dominated by compact rather than vinyl discs. Or likely isn't familiar with Mr. Armstrong.
In other words: *WHOOSH!*
(I had thought it was Satchmo.)
Working on it: nethack-el, currently alpha state software.
In three words: no cartridge port.
There's a sublime physical value to plugging in a game cartridge instead of simply loading a ROM image. Then again, there were far more diskette or cassette based games for the C64, so I might as well shut up.
Chalk up another two moderators who brazenly demonstrate an inability to spot the Funny Troll, I guess.
How ever did any particular last name become common at all, then?
The first result to that query [...] does appear to be up...
You're posting two plus days, one more email to support (see thread), and a direct removal request (see thread) by me later ... they did finally kill the errant entry. One year after it was removed from the 'Net, but still it's gone.
One small step for...
I hadn't really thought about it til I read your replies, but I hardly ever click the top result.
Sounds like a variant of "banner blindness" ... Google Goggles?
As to indexing dead links, since the alternative of finding a dead page in Google's cache is useful [...]
Ah, but the cited example doesn't offer a cached version. So much for that.
Google cache is only beneficial in cases where the page no longer exists or cannot be accessed. Neat and all, but of use to only a small portion of users, I would think. For sites which update frequently (given the general lag in Google indexing), a cached version is detrimental, since the content would not accurately reflect the "true" site. The benefit in other cases is broadly questionable, as "dead" sites are (usually) pruned from Google's index, along with cached contents.
Apart from Slashdotted servers where Google already indexed the content (not likely for new documents), the window of utility is limited -- assuming that people can keep their servers up. I would suggest that archive.org serves the same purpose nicely, but that collection has its own troubles.
Perhaps Google should INDICATE known dead links.
Perhaps Google shouldn't index dead links at all. There's geek chic in placing document copies in cache, but that's about it. Google only caches the document, not the images or other embedded content, or referenced stylesheets or script elements. For many, many sites (unfortunately) much is lost in retrieving only the base document. This again reduces utility.
Favoring inclusion of "dead" documents will quickly lead to an immense repository of this and that, some live and some not. Sounds an awful lot like archive.org and I don't really understand why Google would even bother. Indexing dead pages (cache or no cache) only clutters up results and confuses what one is actually searching.
Flagging the dead from the living isn't a whole solution, but it's a start. Although, were Google to team up with archive.org to permit cross-linking and separation of duties (live Web / dead Web) that might make a bit more sense (to me). I doubt that will happen, given the ties of archive.org to another search technology.
Your job, as a webmaster, is to produce a user friendly, useful, maybe informative website.
Google's job, as a search engine, is to find the sites most likely to be of interest to a user, based on their search terms.
And somewhere in the middle, the two concerns meet. There are a *lot* of unintentionally odd entries in Google that should be cleared out as misleading. Three examples: (1) Redirection URLs from one site but content from the targeted site; (2) Past versions of multi-version documents such as Wiki revision URLs; and (3) Static redirection documents from relocated sites.
All should probably be combatted by site maintainers through application of robot exclusion rules and a little redirection know-how. However, given the frequency with which I've encounted these awkward entries, I'm guessing that attention to such detail has gone by the wayside.
But the next few pages are full of good hits. So is your point that people never check anything but the first result, or that google is not allowed to have 1 page out of several dozen be a bad hit?
My point is that Google decidedly indexes and top ranks "dead" sites. Check that. *Long* dead sites. I can accept a dead entry for a recently pulled site. I might even be tempted to accept a dead entry for a site pulled several months ago should it be ranked deep within a given set of results. But to top rank a site gone for twelve months or more points to exceedingly flaky behind-the-scenes behavior on the part of Google. Whether results [2 .. n] are valid has no bearing on my position.
As to whether people only check the first result: Judging from traffic to my sites through Google and the corresponding ranking of them over time, it would seem that people do frequent top-most entries more than bottom-most. That's common sense. Regardless, I would hazard the guess that leaving a "first" entry broken for so long collectively wastes many people's time. It certainly doesn't put a best foot forward in quelling concerns about the relevance of Google search results, does it?
I got a helluva lot of dead links and blank pages.
Definitely so - check the first result. This is nothing new. For the referenced query, the faulty top-ranking has existed for a long time, though the site in question hasn't existed for over a year. I've even written support a number of times (blatant errors such as these are shameful). Google is far from perfect.
We who are editors at dmoz hold a lot of power right now.
I fear that is all too true. I have encountered Google entries ranked "top five" in result sets of greater than 10,000 members where: (a) the search term(s) are not present in the document; (b) no other Google-indexed document links to the one in question; (c) sole use of the search term(s) is in a DMOZ listing of the document.
It would seem that getting listed on DMOZ can really affect Google "placement" -- I cannot determine whether this is the result of simply weighting DMOZ or due to a "multiplier effect" as Google indexes all those many, many sites who utilize the RDF generated by the Open Directory Project.
Then again, Google top-ranks a Web site that hasn't been on the Web in over a year for one query I run with frequency. I don't think I can point the finger at the ODP for that one.
At Google, go to the "Directory" tab, or go to DMOZ.org (Open Directory) itself. DMOZ is bigger, better organized, has fewer broken links, no ads, and is built by hand by people who know their categories and are interested in keeping them linking only to sites with meaningful content.
First, I would suggest going directly to the categories at dmoz.org rather than the Google relistings. Google picks up revised RDF dumps from DMOZ whenever they please, but the lag in the cycle is pretty long. If you are looking for the "fresher" data, go directly to the source.
Second, DMOZ can become what you say it is only with proper editing. The project itself may list 50000+ editors, but they're volunteers and there is a lot of ground to cover. A large number of edits are made by those "high up" in the directory structure to "lower"/"deeper" categories less well understood. Certain branches of the project are neglected; others eat editors for breakfast with the amount of work that needs to be done. Volunteer and help out.
You may also want to investigate ChefMoz and MusicMoz, too.
Przewalski's Horse [okstate.edu] is pretty interesting. Something like 150 of these equids survive. All in zoos.
Just to be clear, that count is for North America only -- at least, according to the referenced Web document.