Positive Feedback Loops in Local Reviews

While in Paris I made the mistake of using TripAdvisor for finding a good restaurant. The place I picked was ranked #5 in all of Paris but in reality it was just an average place — hardly better than what you could get at a random local cafe. The place was not a typical tourist trap, with neon lights on a busy street. It is a tiny inconspicuous place tucked away in a little side street.

I think what happened is that some American tourists randomly stumbled into this place. Due to an elixir of serendipitous discovery and hunger, and maybe a few glasses of wine, they had a great time and gave it an euphoric review on TripAdvisor. The high rating brought in more clueless tourists who did the same. Just like how a corral reef grows. I am pretty sure this is what happened, because everyone there was a tourist.

This is a symptom of not enough liquidity in TA’s paris restaurant reviews. In places where there is a lot of liquidity, subsequent reviews quickly correct these inaccuracies. Still, TripAdvisor could do a better job in computing rankings. For example, if all the reviews are from tourists vs locals, they should weigh less. Or if a few restaurants in a huge city like Paris are getting the bulk of reviews, it’s a good signal that something has gone loopy.

Unfortunately, Yelp is no better in this case (even though I constantly rely on them in the US). Apparently the best restaurant in Paris is a fallafel place.

It seems local ratings and reviews are still largely an unsolved problem except for a few narrow regions. Next time traveling in Europe, I will use the Michelin guides or ask a local.

Please leave me a comment with a good Paris restaurant recommendation, ideally $$ – $$$ and near Les Halles.



I have not been a Sprint customer in recent history, but I did use a Sprint phone for a few weeks. The following exchange with the Sprint Voicemail should illustrate why so many people are fleeing to other providers (each ‘-‘ represents a small mechanical pause between each computer utterance).

  • Sprint Voicemail: You have 4 new messages and 3 saved messages. To listen to your new messages, press 1.
  • Me: [ Press 1 ]
  • SV: First message, [ pause ] from caller 4-0-8-5-5-5-1-2-3-5, left on [pause ] December-11th at 4-20-A-M.
  • Message: “Hi Pasha… call me back” [ a 2 second message ]
  • SV: To replay to this message, press 7, to save, press 8, to erase, press 9, for all other options, press 0. (Note: you can’t press a key to interrupt the computer voice and jump to the next message, you have to listen to the entire explanation, every time).
  • Me: [ Press 9 ]
  • SV: Message erased. [pause] Next message from caller 4-0-8-5-5-5-1-2-3-5, left on [pause ] December-11th at 5-30-P-M.
  • Message: “Hey man… just calling to say hi”
  • SV: To replay to this message, press 7, to save, press 8, to erase, press 9, for all other options, press 0. (Note: this 15 second explanation repeats for each message and you can’t interrupt it).

And on and on… the point is that while checking voice mail, you spent 3 minutes listening to the computer voice and about 5 seconds to your messages. Now, I am sure there is some way to configure the voice mail system to be more terse, but it would probably take you a few hours to get to it. With this level of disregard for people’s time, I am not surprised they are losing customers.

Gmail + Safari = :(

I prefer to use Safari as my web browser on the Mac because it is so much faster than FireFox.  Unfortunately, Gmail does not work reliably in Safari.  For example, the address book auto-complete does not always work, or worse, hitting the send button sometimes hangs (this got me into trouble a couple of times where my email to say cancel a meeting never reached the other party).  I think the problem is with the way Safari handles simultaneous XHR requests.  The ‘send mail’ request gets queued up behind other in-flight XHR requests.  Perhaps Gmail should have different priorities for XHR requests and high priority ones should jump to the front of the queue or even preempt in progress requests.

Note to mozilla developers: speed should be #1 priority, just ask Google.

Also: does it make sense to call Safari and FireFox web browsers?  In this context, they are more like web application containers or runtimes.