Bcc

Whoa, automatic hand drawn maps like they should be.

Combine this with Maneesh's algorithm for scaling map distances, good speech synthesis and maybe MeLo-powered personal landmark detection and computers can really get into the business of giving people directions in ways that are useful and comfortable for them, but done in a way that's faster, more reliable and with less work than asking someone for help.

I used turn-by-turn directions for the first time during this wedding trip (thanks to my Google phone and an audio cable that plugged into the car stereo) and was really, really impressed. I had never really trusted those before, but it consistently worked well and seemed to be getting pretty good at telling me in a natural way (waiting until after I made a turn and then telling me how long I'd be on that road, for example).

Also, did you guys see that article about the Watson question-answering service from IBM? After all this time, are computers finally starting to work alongside people the way we've always wanted them to? We live in exciting times!

Sent to you via Google Reader

Napkin sketch view of online maps [kottke.org]

Bing Maps has a neat napkin sketch view.

Sent from my tablet

Have you guys read this Wired article on failure and science?

I thought it was really reminiscent of the constant failures we run into as programmers, and the particular challenge of being a software tester.

The main premise is that scientists get so comfortable with accepted theory and the status quo that they don't recognize that failures might be breakthroughs instead of just mistakes in their own equipment or experimental method. There's certainly some value there -- the author gives the example of sensitive radio telescope static finally being accepted as cosmic background radiation and not a problem with the dish, and cites some serious ethnographic research of scientists and how they make discoveries. But the article makes it sound like the solution is simply to be skeptical, to assume that every unexpected experimental result is a potential new discovery.

But anyone who's taken high school physics knows that this assumption that it must be your fault not the theory's fault isn't just some elitist fallacy, it's born of experience. Of the hundred times that the results of your high school physics experiment didn't match what theory predicts, how many times was it because the theory was wrong? Zero, of course; it's always a screw-up with your experimental set-up (at least it was in high school, and I bet the percentage doesn't change that much once you're a professional).

As programmers, we learn this lesson even more often. The first rule of programming, after all, is that it's always your fault. This isn't dogma, every one of us has learned it from this quintessential and eternally repeated experience where we write a piece of code, it doesn't work, we assume that it must be a problem with the operating system or the compiler or the other guy's code -- that the computer simply isn't doing what we told it to do -- until we realize the mundane truth when we actually look at our own code and the documentation and find that we'd just made another stupid mistake.

And that's the real trick of software testing: it can be tempting, particularly at first, to file a bug every time something doesn't work. Young confident software testers go to their dev several times a day saying "I found a bug" only to realize that they hadn't called the function with the correct parameters. But this lesson of experience quickly leads to the opposite problem: having become so accustomed to being the cause of our problems (like any programmer), we just fidget until we get the software to work, unconsciously working around bugs that we should be filing.

So I think the real answer, both to the scientific problem and the software-testing one, isn't mere undying skepticism, but in knowing which failures are probably your fault and which ones aren't. And a lot of the techniques that experimental scientists and software testers are the same: the first step for both is reproducing the failure. Lehrer's article also suggests talking to someone who isn't intimately familiar with the experiment, and I think we software testers often understand an unexpected result when we try to explain the bizarre situation to a tester from another team. "Encourage diversity" is also on his list, and I think the Test Apprentice Program at Microsoft was a darn good example of that in action -- being the only non-CS majors on our teams, we often found different bugs.

Maybe experimental science could even learn something from software testers. I thought one of the more valuable things we got from learning test-driven development was that a test wasn't good unless you'd seen it fail. If you've only ever seen a test pass, then how do you know that it really tests what you claim it tests? That must be harder for physicists (they can't briefly turn off a particular universal parameter to ensure that the experiment fails under those conditions), but the same sort of counterfactual thinking (rather than just writing a test and being happy when it turns green, or running an experiment and assuming that the result confirms the theory) seems important to me.

Do we get a lot of good software testers from experimental science backgrounds? Maybe that's where we should be hiring from. Anyway, I highly recommend the Wired article, if only for the comfort that programmers aren't alone in the universe for having their experiments fail constantly.

Hope you're all doing well -- grad school is great, but, as you can see, I still miss software testing from time to time,
Nick

I'd like to announce a talk and meeting that may be of interest to iSchoolers.

On Wednesday, September 9th, local blogger Dave Winer, one of the originators of the RSS syndication format, will talk about a new proposal called rssCloud, which allows for Twitter-like instantaneous distribution of short messages in a decentralized way, based on existing RSS technology.

After an overview of that proposal, developers can share their own work in the area and there will be an open discussion.

So if you're interested in an alternative to Twitter that isn't controlled by a single company or want to see how a new standard is designed or implemented in practice, please join us Wednesday at 7 PM in 110 South Hall.

Thanks,
Nick

Hello all,

I had just a couple of my own comments to follow up on CDT's last call privacy comments and the "intended usage notification" thread that lingered and languished on this list a few months ago.

First of all, I'd like to second CDT's request to hear from other members of this list as to whether implementors of the API or users of the API that don't fulfill all the normative requirements in "Privacy considerations for implementors of the Geolocation API" and "Privacy considerations for recipients of location information" will be officially non-conformant with the API.

For example, Flickr's mobile website provides a "Photos taken nearby" feature which makes use of the draft Geolocation API. But Flickr apparently doesn't clearly and conspicuously disclose how long location data is retained, how location data is secured or whether location data is shared -- the "Your Privacy" link doesn't describe any uses or practices around location data. I might conclude from following another link that the "Yahoo! Privacy Policy" covers my location information, but it's never described explicitly and I couldn't definitively determine if my location information was stored or shared.

What does the WG intend by requiring recipients to "clearly and conspicuously disclose"? Is disclosure within a long Privacy Policy sufficient? Or do we expect location information to be addressed explicitly and before location information is requested? Also, will the W3C have any power to enforce or judge implementations or (ab)uses of the API?

Second (and I bring this up specifically because it might address ambiguities with the normative privacy considerations), I wasn't sure we ever came to a satisfactory conclusion on whether to allow requesters of location information to specify in their request how location information will be used, how long it will be kept or whether location information will be transmitted to 3rd parties. While Doug, Greg, Andrei and Ian proposed that allowing websites to present information about their usage would let them deceive users, Martin, Henning, Max and I thought that some additional context about how location information will be used would be valuable for user privacy.

Could we find some middle ground where requesters can't place arbitrary text which could deceive, but can fill in a timestamp for how long data will be kept and a flag for whether it will be shared? If not in V1, can we open an Issue to reconsider this question in V2? Again, this could help clarify ambiguities around "conspicuous disclosure", address concerns about privacy protection or even provide an easier step towards associating Geopriv-style permissions with location data.

Thanks,
Nick Doty
UC Berkeley School of Information

Hi Dave,

Re my sarcastic tweet:

More seriously though, I think you're right on, but that really you're identifying problems with blogging, not with microblogging.

If it were just as easy to communicate with a blog post as it is with Twitter, plus you could express longer thoughts with a blog post, then there'd be no reason to complain about Twitter's character counts. Twitter would simply be a joke, an inferior product completely dominated (that is, in all dimensions) by blogging software.

But it isn't just as easy. Part of it, as many have pointed out, is the small messages -- it's easy to write and easy to read because neither takes that much commitment. But I think there are other issues too, advantages of Twitter that we wish we had with blog posts.

• Replying on Twitter is way easier and more effective than replying with a blog post. Trackbacks are confusing, full of spam and much harder to use than a single character in front of a name.
• People are harder to find at arbitrary addresses than they are with a single username after "twitter.com/". (Like @chrismessina and others, I wish this weren't the case, but currently, I believe it is.)
• It's easier to be part of a trend just by typing a # and a word than tagging your blog post and hoping technorati picks it up.
• Republishing content is a trivially easy and widely-accepted practice. (I think this is why single-click re-blogging on tumblr is so popular too and why Google Reader's "share" feature is so compelling.) You can also push content to particular people with @mentions.
• Syndication and reading is handled in the same place as writing -- as soon as you sign up for one, you've signed up for the other. Even though Twitter syndication is inferior to RSS (Twitter is a single unreliable service; there's no tracking of what's read and unread across devices), I suspect more regular people use Twitter to keep track of all their friends than use an RSS aggregator.

I think it's not so much a problem that Twitter has a character limit as it is that blogging platforms don't have all these other advantages. Conversations happen easily and naturally on Twitter, despite the severe limitation of character counts. I'd love to see those same advantages in the blogging platforms we use every day -- something you know about first hand!

Anyway, thanks for starting the conversation, and for using both Twitter and your blog to do it.

Nick