March 19, 2005, 6:25 PM ET
Greasemonkey script: Google Suggest
I can't get enough of Greasemonkey, Aaron Boodman's Firefox extension that takes my All Music Guide extension idea to the next level by making it super simple to create and distribute scripts that alter Web pages.
Here's a Greasemonkey script I just cooked up: Google Suggest for Greasemonkey. It makes the dynamic drop-down from Google Suggest a bona fide part of Google, placing it on the Google home page and on search-result pages.
Installation directions for Greasemonkey novices:
- Run Mozilla Firefox.
- Install the Greasemonkey browser extension.
- Restart your browser.
- Go to my script's page, click "Tools | Install User Script...", and say OK to the prompts.
- Go to Google, type in search terms, and watch the suggested search terms appear.
Tech note: The cool thing about the script is that it leverages Google's well-abstracted autocompletion library by dynamically appending it to the page as a <script> element and running a single initialization function. The dynamic <script>-appending technique could be a handy way to do more powerful stuff with Greasemonkey in the future.
UPDATE, April 26: If you don't want to install Greasemonkey, just install this super-simple Firefox extension to get the same functionality:
March 18, 2005, 12:33 AM ET
Microformats could describe online news intelligently
A lot of the buzz at South by Southwest was about the concept of microformats, which are lightweight, informal standards for adding metadata to Web pages by using existing XHTML elements. Tantek Çelik and Eric Meyer both spoke enthusiastically about the idea, and I'm grateful I had a chance to speak with both personally.
A good example is XFN, a way of identifying human relationships within a Web page's code by putting a rel attribute on <a> tags. (I've written about XFN previously.) For instance, I'm friends with Simon Willison, so I put rel="friend" in the link to his Web site, and services such as rubhub do cool things with the aggregated data.
It works, because it's easy for humans to understand, easy to implement, uses existing infrastructure (XHTML) and solves a small, specific problem.
A few other microformats have been invented so far. Some examples:
- hCalendar -- A way to designate calendar information within a Web page
- hCard -- A way to designate contact information, as in a vCard
- VoteLinks -- A way to designate whether you agree or disagree with something you're linking to
Why spend the time adding that metadata to your Web pages? Because it makes it easy for automated tools to aggregate information, and it creates a bunch of interesting possibilities.
I love the idea of microformats, and, as I'm involved in the online-news industry, I'm naturally interested in their possible applications in a journalism context. Here are a few ideas I've been bouncing around; I'd love to see what people think.
Background-story relationships
News sites -- well, decent ones, anyway -- often link stories to previous coverage on the same issue. But there's no reliable way to automate the detection of previous coverage. I was thinking a rel="background-story" attribute for link tags could work.
A rel="background-story" could be used on internal or external links -- in the latter case, it'd be used if a newspaper is following up on the work of another news outlet.
I brought this up with Tantek at South by Southwest, and he suggested that <link rel="prev"> might be a better way of marking it up. The problem I see with that is that it implies a linear "previous" relationship, whereas a news story generally has more than one background story. It's true that some series of news stories are linear, but it's probably not a good idea to pigeonhole all news stories in this way. Journalism describes life, and life isn't linear.
(That said, <link rel="prev"> could, and probably should, be used for multi-part news stories, such as those in a series.)
Possible applications: Automated visualization tools that create news "trees;" much more intelligent news automation by aggregators such as Google News and Topix.net.
Story reaction relationships
It'd be beneficial to designate relationships between a news story and opinion pieces commenting on that news story. The news story itself could include <link rel="opinion-reaction"> in its link to the opinion page, and the opinion page could include <link rev="opinion-reaction"> in its link back to the facts. (The rev means "this describes the current page's relationship to the other page.")
Possible applications: If news aggregators used this, they'd be less likely to publish "opinion" content as news, which would solve a significant problem many journalists have with automated news sites such as Google News.
Reporter relationships
It's rather surprising to think about, but there's no good way to designate the reporter(s) of a news story in a machine-readable format. Yes, there's <meta name="Author">, but that could as easily be set to "Chicago Tribune" as to "Mike Royko." (In a newspaper, who's the "author"? The reporter? The publication? The editors/publishers?)
I propose a <rel="reporter">, which would be inserted on the link to the reporter's bio page -- on news sites that give their reporters bio pages, of course.
Possible applications: Web-wide aggregation of content reported by a particular author. More intelligent parsing of reporter information by news aggregators.
Factual relationships
This one gets a little abstract. It'd be fascinating to mark up every standalone "fact" in a news article and link it to a page of "proof" or "support." The link would have <rel="proof">, and automated agents could traverse the Web to build a gigantic "proof structure," tracing this fact back to an earlier fact, which would in turn be traced back to a previous fact. It's obvious this metadata would be incredibly expensive to maintain. But maybe news organizations should start thinking about creating infrastructure to gather this type of data.
March 16, 2005, 1:51 PM ET
It's tournament bracket time again
It's time once more for the NCAA basketball tournament, and that means two things:
- My site will get flooded with traffic because a two-year-old article on NCAA bracket interfaces is near the top of the Google search results for ncaa bracket.
- For the third year in a row, we at KUsports.com are offering customized, print-friendly PDF versions of brackets for free. Just fill out a bracket and click the button to get your PDF.
March 10, 2005, 5:10 PM ET
March travels
I'm headed to South by Southwest Interactive in Austin, Texas, this weekend, then to the Newspaper Association of America's NEXPO conference in Dallas, and finally to PyCon in Washington, D.C. Drop me a line if you'll be at any of the above and want to meet up.
March 8, 2005, 10:31 PM ET
Romenesko has RSS
The good folks at Poynter have made live (and official) the RSS feed I put together for Romenesko. Get the feed.
Post a comment:
Comments on this entry are closed.
Don't see any comments? That's because my Web hosting provider has made a server upgrade that broke the commenting feature on this site. I'm working to restore that; please check back later.
March 6, 2005, 11:22 PM ET
More on EmPRINT
In case you didn't notice, the future started today.
Yes, that's an advertisement that ran in The Columbia Missourian for EmPRINT, which I previously discussed.
March 2, 2005, 12:41 AM ET
Again, a newspaper PDF experiment is fatally flawed
My alma mater, the University of Missouri School of Journalism, has announced an experimental "new electronic newspaper format." Called EmPRINT, it is a weekly digital edition of the Columbia Missourian newspaper that is downloadable as a 5-10 megabyte file and is "intended as a digital publishing standard," with "magazine-size page forms that open in full-screen view to provide a visually rich, comfortable reading experience."
Basically, it's a glorified PDF file.
I started a long list detailing why I don't like EmPRINT, but I scrapped it. Instead of taking the easy way out by raising standard PDF criticisms -- no permalinks to articles, bad accessibility, nonstandard browsing, etc. -- I'll just say this: EmPRINT is fundamentally flawed because its presentation is fundamentally tied to print newspapers. That is, it's static. Flat. Rigid. It looks the same and acts the same no matter what you do to it.
It is no more interactive than a print publication. Just replace "flip the page" with "click a link."
Get the difference? A print-newspaper journalist tries to guess the dozen-or-so pieces of information that people might want to know, freezing the facts into a flat, unbendable package. (Meet EmPRINT.) But a Web-savvy journalist tries to anticipate the hundreds of ways people will want to slice, dice and use information, and creates the infrastructure that makes it happen.
It's the difference between a flat-text schedule of sporting events (like EmPRINT has) and a deep schedule/stats database that lets me click a team, get full stats and compare players' performances on the fly. It's the difference between a flat list of marriage licenses and a searchable database that lets me type in a person's name and corrects common misspellings.
That's what Web news is all about. A newspaperman deals in information dictation; a Web journalist deals in information discovery. EmPRINT lets me look at information, but it doesn't let me explore it.
UPDATE, March 7: Don't miss the EmPRINT print ad.
Post a comment:
Comments on this entry are closed.
Don't see any comments? That's because my Web hosting provider has made a server upgrade that broke the commenting feature on this site. I'm working to restore that; please check back later.