Every time I pass a store I wonder “How do they stay in business? How do they make money?” With so many businesses so empty so often you just have to wonder how it all works out. What are their keys to profit? How do they make rent? How do they pay their people? How do they cover their bills? How do the owners take something home at the end of the day?
With the help of Edward Glaeser, a pioneering urban economist at Harvard, New York Magazine profiles a diverse range of New York businesses including a private school, a yoga studio, a drug dealer, a sex shop, a cab driver, a copy shop, a 4-star restaurant, and Goldman Sachs.
Best way to make money as a drug dealer: Sell to many users in small quantities. “It’s like taking a pound of coffee and selling one grain at a time,” says Nick. “If you sell by scoops, you’ll make a couple thousand dollars, but if you break it down into quarter grams and work for a few days, you’ll make tens of thousands.”
Most profitable fares for a cab driver: Low-traffic city trips: “Every time somebody gets out, someone gets in, and I get my $2.50.” Midday airport runs: “At 3 p.m., there’s no traffic, and so many planes are coming in that you get $90 plus tips.”
Most profitable for a copy shop: Restaurant flyers. Those annoying restaurant flyers fuel the photocopy industry. Local restaurants order 1,000 new flyers every three days.
Least profitable diner customers: The elderly. They have a tendency to return food.
It’s enlightening. [via kottke]
In Google Keeps Tweaking Its Search Engine, Amit Singhal, master of Google’s ranking algorithm, and other engineers reveal more than they ever have before in the news media about how their search system works.
Here’s a story of how a new formula gets added and why Singhal ignores complaints at first…
Each search match is assigned a numerical score based on more than 200 variables. But Google considers 10 diverse results better than the 10 highest scoring results…In 2005, Bill Brougher, a Google product manager, complained that typing the phrase “teak patio Palo Alto” didn’t return a local store called the Teak Patio.
So Mr. Singhal fired up one of Google’s prized and closely guarded internal programs, called Debug, which shows how its computers evaluate each query and each Web page. He discovered that Theteakpatio.com did not show up because Google’s formulas were not giving enough importance to links from other sites about Palo Alto.
It was also a clue to a bigger problem. Finding local businesses is important to users, but Google often has to rely on only a handful of sites for clues about which businesses are best. Within two months of Mr. Brougher’s complaint, Mr. Singhal’s group had written a new mathematical formula to handle queries for hometown shops.
But Mr. Singhal often doesn’t rush to fix everything he hears about, because each change can affect the rankings of many sites. “You can’t just react on the first complaint,” he says. “You let things simmer.”
The sites with the 10 highest scores win the coveted spots on the first search page, unless a final check shows that there is not enough “diversity” in the results. “If you have a lot of different perspectives on one page, often that is more helpful than if the page is dominated by one perspective,” Mr. Cutts says. “If someone types a product, for example, maybe you want a blog review of it, a manufacturer’s page, a place to buy it or a comparison shopping site.”
Google’s secret formula? No secret really — they just constantly grind away at it from all different angles…
“People still think that Google is the gold standard of search,” [John] Battelle says. “Their secret sauce is how these guys are doing it all in aggregate. There are 1,000 little tunings they do.”
It shows the max number of users that a show can have at a point in time , which advertisers will evolve to in buying time critical ads (movie buys on Thursdays before opening on Friday). If an advertiser for Shrek 19 or Saw XX needs to reach 10mm people online before their movies open the next day, knowing the maximum and average number of simultaneous viewers for the content you are buying gives you the proper constraints required to do the math on the buy.
The number of simultaneous viewers a site can support also tells you what happens to your ad if something unique happens. Its hurricane season. Lets say there is amazing footage from a hurricane or some other event, maybe a Paris Hilton prison break and one site has the capacity to handle 1mm simultaneous viewers, the other 100k. If your ad is on one, you might be ok. If its on the other, you might be out of luck. Your ad is delivered at a snails pace if at all, with users seeing more buffering then ad.
Then there is the issue of cheating. its easy to cheat on views. Youtubers game their views all the time, as they do on all video sites. To advertisers, each site defines a view differently. is it when an ad is viewed for 1 second, 10 seconds, to its entirety, to its entirety without buffering ?
If you buy an average of 1k simultaneous viewers, thats a much more difficult number to cheat. The advertiser can get a link into the serving of their ads and monitor how many people are watching at any point in time which is something they can learn from.
The number of simultaneous viewers also tells the "intensity" or heat of an ad or content. 1mm simultaneous viewers has a completely different impact than 100k per day for 10 days which is different from 1k per day for 1k days. Tracking the number of simultaneous viewers gives you the true feel of the viral nature of the content and it smooths out much of the cheating by video uploaders
This new iPhone ad is one of the best ads I’ve ever seen.
In 30 seconds you learn you can hold this thing in your hand, you control it by touching the screen, it flows, you can watch a movie on it, the screen pivots, it’s fast, you can type on it, it has maps, it knows your location, it makes useful decisions for you, and you can make calls. It’s all so obvious and comfortable and easy in 30 seconds without being rushed.
And you learn all of this in the context of a scenario, not in the context of an explanation. An anonymous hand can be yours, your mother’s, your father’s, your kid’s, your grandparent’s, anyone’s. A friendly voiceover represents your own internal voice. Easy music reinforces an easy product. This is the actual interface, not an interface that is enhanced or embellished so it looks better on TV.
A simple close-up focus on the product and the experience because both are so good. This recipe doesn’t need any additional seasoning. Which other cell phones are advertised on the quality of the experience and interface? When’s the last time you’ve seen any technology product advertised like this?
This is wonderful advertising.
CIPA (Camera & Imaging Products Association) has today published a draft of their new 'Specification Guideline for Digital Cameras', this document is designed to provide guidelines to manufacturers for the publication of specifications and features for digital cameras. It covers a wide range of details such as focal length, effective pixels, sensitivity, signal to noise ratio and even weight, dimensions and volume. One interesting inclusion is a distinction between mechanical image stabilization and digital blur reduction. CIPA members include Canon, Fujifilm, Panasonic, Nikon, Olympus, Pentax, Sigma and Sony. [Comments (0)] [link]
Building web apps can be a lot of fun - particularly if people like and use them. If you dig through your stats the chances are that people from all over the world are visiting you and they speak lots of different languages. By only serving your app or website in English you're assuming that everyone can speak it, or at least understand it well enough to get by. Just as learning to speak a new language can open the door to new cultures and ways of thinking, having a website that speaks multiple languages allows you to engage people who might otherwise have left looking for an alternative.
This was the situation we found ourselves in back in March just after we launched Diarised. We had people not only visiting us from all over the world but blogging about us in many different languages. We thought it would be a nice idea to get Diarised working in a few.
The process of getting your website ready for multiple languages is known as internationalisation. Internationalisation goes beyond getting the website working in other languages and covers aspects such as dates, times and currency. In this two part article we're going to look at how you go about preparing a website for internationalisation. Then we'll look at solutions to some of the real-world problems that can arise, such as dynamic data and plurals.
As a first stab at internationalisation we might try using associative arrays. We could store our translated text using the English text as the key, like so:
//set up our language arrays
$english["welcome to example.com"] = "welcome to example.com";
$english["have a nice day"] = "have a nice day";
$spanish["welcome to example.com"] = "Bienvenidos a example.com";
$spanish["have a nice day"] = "Ten un día bueno";
...
/*
* We'll set the locale based on a variable in the query string
*/
switch($_GET["lang"]){
case "es": //es turns the page into Spanish
$messages = $spanish;
break;
default: //everything else defaults back to English
$messages = $english;
break;
}
...
echo $messages["welcome to example.com"]
Adding new languages should then be a case of adding more arrays and updating the switch statement. Perfect! Well not quite. There are a few issues with this approach:
echo $messages["wlcome to example.com"] By missing off the "e" your translation will break and leave blank text.Clearly this method has issues. What we really want is a way to allow non-techies to translate our text for us and a way for us to simply "plug" the translation back into the website.
After ruling out associative arrays to do Diarised translation's we decided to use gettext. gettext is the GNU internationalization library and it provides an excellent way of separating code from content. If you're hosting on Linux there's a good chance it will already be installed on your server.
The official Gettext website gives a highly detailed and fairly confusing overview but the gist is:
Step 1 is just a case of the following:
<p>welcome to example.com</p>
becomes
<p><? echo gettext("welcome to example.com"); ?></p>
Marking up your code to use gettext is probably the most irritating step but fortunately you only have to do this once. It will then work for as many languages as you like. The next stage is to get this information into our translation file.
The first step is to set up the directory structure:
To create the PO file you'll need to use the command line but don't worry we're here to hold your hand. Fire up a terminal window, connect to your webserver and be brave.
The command we need is called xgettext, this will scan a script looking for calls to gettext then grab the text you're passing and put it into a PO file. For example:
# xgettext -o messages.po *.php
This will search every PHP page in the current working directory and stick the results in messages.po. Once this is done open the file with a plain text editor and make the following change:
"Content-Type: text/plain; charset=CHARSET\n"
becomes
"Content-Type: text/plain; charset=utf-8\n"
Now save it and send it to your translator
Although a PO file is a plain text file its contents aren't particularly friendly. Luckily there are a few pieces of software that make editing PO files a bit easier (especially for your translator). For Windows there's poedit, and for the Mac there's LocFactory Editor. Both are free and will make your translators lives much easier.
When your translator sends the PO file back stick it into the appropriate LC_MESSAGES folder created earlier and open a terminal window so we can compile it
In your command window go to the LC_MESSAGES folder with messages.po and issue the following:
# msgfmt messages.po
Assuming there were no errors this will churn out a file called messages.mo. This is the compiled file gettext will actually read, any changes to your PO file will require you to redo this step to make the changes live. Now all we need to do is tell gettext which language we want our text in.
This step can be done via a few lines of PHP near the start of your script:
$locale = $_GET["locale"];
putenv("LC_ALL=$locale");
setlocale(LC_ALL, $locale);
bindtextdomain("messages", "locale/"); //binds the messages domain to the locale folder
bind_textdomain_codeset("messages","UTF-8"); //ensures text returned is utf-8, quite often this is iso-8859-1 by default
textdomain("messages"); //sets the domain name, this means gettext will be looking for a file called messages.mo
$locale will need to be set to the locale that you want the website appear in. To begin with it's simplest to set this via the query string as shown above. One of the advantages of gettext is that if it can't find a folder for the locale you pick it will just go back to English, meaning when someone sticks locale=kl expecting a Klingon version they'll just get English.
That's it for part one. At this point you should be able to at least make a start on preparing your websites for internationalisation. In part two we're going to look at some of the real world issues you're likely to run into and tell you what we did to solve them on Diarised.
43 queries. 1.281 seconds