HN user

ngrandy

74 karma
Posts6
Comments23
View on HN

This is an exciting concept that has been tackled by many teams, few of which have yet been able to reach significant scale. But I believe it will happen. Feastly (http://eatfeastly.com/) is a similar approach that is active in the US. (I'm an advisor) The restaurant industry is massive (in the US, it's three times the size of the accommodations industry) so winning even a small slice is a win.

carl sagan has a great section about this in 'the demon haunted world' - he describes / speculates how many modern stories of 'alien abduction' can be explained by sleep paralysis.

it's usually caused by disrupted sleep patterns. i get it pretty often if i take a nap - my trick to get out of it is to try to wiggle the fingertips first.

this is very cool, and the beginning of a trend, it seems to me. the whole semantic web depends on structured information, but it's a pain to structure information. it makes a lot of sense that the services to structure plain text will be made available as APIs - eg to extract geo information, date and time information, contact information, etc.

yes. a lot of airline and travel websites have awful, inexcusable user interfaces, and they could use a good kick in the pants. similar frustrations inspired us to build tripeedo.com, a better user experience for travel search.

while remaining dead simple to use, heroku is also becoming an increasingly sophisticated platform, capable of handling a wide variety of app requirements. eg - background workers and memcached support are available in beta. since i started using heroku for tripeedo.com, the traditional server hosts are looking a lot like dinosaurs.

for those who missed it, this comment refers to the hacking of this story. hacker news was briefly hacked, and this story was altered to link to a website (hosted at appjet) that let users edit the text of pg's profile. it was fixed within a half hour or so.

also, the interface is optimized for speed and convenience. you can type 'www.bestbuy.com' into your iphone, but given the choice, our feeling is that many people will prefer to use an app that minimizes typing and maximizes speed.

frankfurt/main is now the top match for 'frankfurt'. :)

the way to specify an airport if the top match is not right is just to keep typing. eg: london => london all airports (lon); london gatw => london, gatwick (lgw); lon hea => london, heathrow (lhr)

similarly: sa fr => san francisco; sa di => san diego

typing frankfurt/main didn't work because the slash was confusing the interpreter. i'm fixing that right now.

yeah, that's one option we're thinking about. we went with popups initially because 1) it's simpler and 2) it wasn't clear that loading up 10 windows in iframes would necessarily be a better user experience. it's something we're going to look at more closely. our approach to tripeedo has definitely been to try to keep things as simple as possible.

increasingly, travel sites are letting people do those kind of flexible dates search, which is a promising trend. you're right, for the time being tripeedo is primarily a different UI (though one we feel is more user-friendly), along with the benefit of only entering trip details once.

yeah, we need to fix or warn about that better. the reason that the airline searches don't work reliably is that most airlines only serve a few airports, and if you search for airports they don't serve, the result is not always handled gracefully. some airlines prompt for a known airport - some just give up and display an error. to counter this, we would need to maintain a list of all airports served by each airline, and only let users launch valid searches to the airline sites. i think that is good from a usability perspective, and it's definitely doable, but maintaining it is time-consuming. that's why we haven't done it yet. but, we may well get to it soon.

hey bootload, thanks for your detailed response. you raise a lot of good points. we've definitely spent a lot of time thinking about these issues.

first, you're right that just extracting info from twitter doesn't require username and password. our initial twitter interface is an update though, which does require authentication.

- we do use SSL for all usernames / passwords that are submitted, though we should make that clear, b/c right now we don't give an indication.

- because twitter does not offer token-based authentication, and because we do not currently want to store passwords, we are actually submitting to twitter via the web interface; that means we submit the u+p just once, and then we hold onto a cookie, but not the u+p. when we login to twitter on your behalf, it is via https.

- one goal in the near / mid term is to give users a choice about the combination of privacy / convenience that they want. right now we have opted on the side of privacy, since we're not storing usernames and passwords. but some users have told us they would like wundrbar to basically act as a password manager, so we'll be building in that option.

- i hope twitter (and other sites) implement open auth soon, because i know there are alot of users who will be more comfortable using wundrbar through that authentication mechanism.

what exactly do you mean - why does that lose you? because it's asking for personal information? for google calendar, wundrbar takes you to google for authentication, and then gets back a token from google and stores that. but not all services operate that way. if you want to use a personal account through wundrbar, though, it need to have some way of authenticating as you with that external service. the benefit is that you can access multiple personal accounts from one place, and that soon you will be able to access them by sending a text message, for example.

yes! we've built wundrbar to be intuitive, precisely because it's annoying to need a man page every time we use a new command. wundrbar aims to capture the power and simplicity of a traditional command line (including the ability script and pipe) and to throw in some magic dust so that you don't have to remember the exact command name or what order the parameters come in.

for example, imagine sending money with paypal from the traditional command line. there are two pieces of information, a number (amount of money) and an email. well, in a traditional command, you would have to enter those parameters in a fixed order, or add a flag so the command read 'paypal -to joe@example.com -amount 5'. but really, a number and an email look quite different, and the command should be able to figure out which is which, right? that's what wundrbar does. so 'paypal joe@example.com 5' or 'paypal 5 joe@example.com', both are good.

There are a ton of different ways to approach the problem of interpreting a command. if you're interested in a solid reference for computational linguistics, then i recommend either 'speech and language processing' by jurafsky et al or the 'oxford handbook of computational linguistics'. finally, the forthcoming information retrieval book (http://www-csli.stanford.edu/~hinrich/information-retrieval-...) is a fantastic resource.

however, keep in mind that a lot of the stuff in these books has been used more at the academic level than in commercial applications. we at wundrbar are being very careful not to bite off more than we can chew. many companies have tried and failed to tackle natural language processing, and we are NOT doing that; we feel like we can add a lot of value without trying to do anything too fancy. our commands right now are identified by keywords located at the start of the command - simple, intuitive, reliable.

Aneesh, if you install the wundrbar toolbar for firefox you can actually replace the location bar with wundrbar! It's a big leap, but it's there as an option. Or you can just use the toolbar, which automatically positions itself below the location bar.