The Good NET Guide

Posts Tagged ‘yahoo’

Google may have hired Plaxo’s Chief Technology Officer Joseph Smarr late last year, but it’s Yahoo that’s finally adding the 8-year old idea of turning the address book model upside down and letting people subscribe to it rather than keep their own quickly outdated lists. They’ve launched a new feature called “Share my info” in Yahoo Contacts that is, like the old Plaxo product, a way to subscribe to contact information and have it automatically updated.

Instead of updating your friends’ contact information when it changes, your friends just do it for themselves and then everyone with permission to get that information automatically has their address book updated.

It saves a lot of hassle and it was brilliant when Plaxo launched it in 2002.

But it never really caught on with the masses and most people today are stuck with address books that are little better than they had a decade ago. Plaxo’s spamming problem probably didn’t help gain user trust, which was part of the problem. But Plaxo also lacked other features like email to make it a really useful place hold your address book.

Syncing products bring the promise of contacts Shangri La, but they never quite seem to work. I still maintain a desktop address book synced with Mobile Me as well as Google Contacts synced with my phone, and it’s a huge mess of duplicate contacts and outdated information.

There’s also a bunch of independent contact information for some of my friends over on Facebook. And in fact that’s often the most reliable data for older contacts because they keep it updated themselves. It’s very similar, in fact, to the Plaxo model. I’m “subscribed” to them via mutual friendship and it can be turned off at any time.

I hope Google starts doing this soon as well, simply because that’s the closest thing to a master contact list that I have in the cloud. And at some point someone has to solve the problem of syncing contact information and other data across company platforms. Yes, I know a ton of startups have tried this, but no one has quite gotten it dead simple and right.

Stealth startup Trada launched to the public today as an online marketplace allowing small and medium businesses and agencies to essentially crowdsource search engine optimization services. The startup has raised $2.2 million from the Foundry Group and angel investors Alan Warms, Carlos Cashman, Dan Murray, James Crouthamel, Stuart Larkins and Robert Wolfe.

As we all know, search advertising is necessary for businesses but SEO can be a time consuming, perplexing and tedious task. Many businesses overpay for common keywords or don’t use the right keywords to drive traffic. Trada comes into play here by crowdsourcing SEO experts to build and manage and advertiser or business’ paid search campaign across search engines. The service currently supports Google AdWords and Yahoo Search Marketing.

Essentially, Trada ends up being a middleman for coordinating SEO service. Advertisers use Trada to enter information about a campaign and experts, who must be AdWords or SEMPO certified and pass Trada certification, use the site to find interesting campaigns and submit keywords, ad copy and bid prices across the search engines and to track and optimize campaigns across the ad networks. Trada coordinates the payments and takes a small cut of each transaction between advertisers and SEO experts.

The benefit for the SEO experts is that they don’t have to deal with the administrative and management issues with clients. Experts earn money when they generate clicks or other actions for less than the advertiser’s target price. Advertisers get 25 qualified experts to work on their campaigns and according to Trada, those businesses who participated in the private beta of the service are seeing successful results.

Trada entered private beta in January 2009 and currently has 70 advertisers and 280 experts to date. Founded by entrepreneur Niel Robertson, Trada was born after Robertson grew frustrated managing his own $8,000-a-month paid search campaign. Realizing that paid search campaigns are best left to experts, he thought an online marketplace for PPC experts and businesses would be the best way to maximize SEO. The startup faces competition from Kenshoo, Conductor and many others.

For the past couple of years now, when talking about the Apple TV product, Apple likes to throw out the word “hobby.” It’s as if they’re ashamed of the device. And considering sales are anemic next to Macs, iPods, and iPhones, it’s no big surprise that they talk this way.

But there’s actually nothing to be ashamed of. The Apple TV is a good product. Apple just needs to put some proper time and energy into it, to expand it to its full potential. And news today about the so-called “Google TV” should do just the trick.

Apple and Google are on the verge of war. The formerly close allies are increasingly competing in key spaces for both, and the living room is likely to be a new battleground because it’s still very much up in air. As the New York Times reported yesterday, Google is working with partners including Intel, Sony, and Logitech to bring a Google TV experience into the living room. This is, of course, where the Apple TV resides. And Apple would be foolish to simply cede any ground it does have to its new favorite rival just because it’s focused on other things (*cough* iPad *cough*).

That’s a Microsoft move.

As Nick Bilton points out, this Google TV would be based around the Android platform. This means that the key idea is likely to have third-party developers work on it to make applications built for a television set. That’s easier said than done, but Android’s open nature should yield some interesting results rather quickly.

Apple, meanwhile, is of course anything but open with regard to their devices. In fact, the Apple TV is entirely closed right now, as only Apple is able to modify its software (without hacking it, of course). I suspect that will change, following this revelation.

The idea of running iPhone-style applications on the Apple TV has long been a sexy one. Hell, people have even ported apps over to a TV screen to show how well it could work. The main problem with developing iPhone apps for the Apple TV seems to be resolution. With the iPhone (and iPod touch), Apple offers only one screen size/resolution, ensuring developers have an easy time making great-looking apps — while at the same time, making sure end users have a great experience.

But the iPad has already changed everything. With their new device, Apple has kept things as simple as possible by making iPhone apps scale up two times to work on the bigger display, but it’s still shows a willingness to move beyond the one screen size. Unfortunately, with the Apple TV, it can be attached to a screen that could be a huge variety of sizes, so it would be hard to control that.

Google doesn’t care about that because Android already runs on dozens of phones with different screen sizes. But Apple clearly cares about how apps look on its devices (so much so that the iPad itself was likely designed at a strange ratio simply to make scaling apps look as good as possible). So does that mean they start offering an actual Apple TV (as in a screen)? Rumors of that have been around for a long time. Or maybe they black-box apps to a certain resolution — similar to what they’re doing on the iPad when an app isn’t scaled up?

Who knows. But what I do know is that upon hearing this Google TV news, the Apple TV became a little less of a “hobby” yesterday.

Aside from calling it a hobby, Steve Jobs has referred to the Apple TV as being a potential “fourth leg” of a chair Apple is building. Leg one is the Mac, leg two is the iPod, leg three is the iPhone, and Jobs had hoped the Apple TV would complete the chair one day. But it seems clear now that he thinks the iPad could be the fourth leg instead.

Screw that. I think it’s time for Apple to build a whole dining room set of furniture. We, as consumers, need a living room arms race between Apple and Google (and Microsoft, TiVo, Roku, Boxee, and the rest) to kick the cable companies’ shitty television user experience to the curb.

Ash Patel, a senior Yahoo exec and one of the company’s longest serving employees, will shortly be stepping down. His last day will be next Monday.

Patel was one of Yahoo’s first sixty employees, and joined shortly before the company went public in April 1996. There are just six current Yahoo employees who joined before Patel, the company says.

His first job at Yahoo was “technical Yahoo,” a title given to all engineers. He created the My Yahoo product and also built Yahoo’s first instant messenger client. He stopped coding for a living in 2002 and has since been in a series of product and engineering executive positions.

His current role is EVP Product Architecture & Strategy. He has also served as Chief Product Officer and has run the engineering group at Yahoo.

I met with Patel this morning for a little over an hour to talk about his time at the company the early days at Yahoo.

One of his favorite moments was summer 1996, he says, when cofounder David Filo would stay up all night watching the news and manually updating results from the Summer Olympics in Atlanta. Most updates to Yahoo’s website were manual in those days, he says, although there were a few partners sending in content in a variety of formats.

Patel also talked about how annoyed he would get trying to test Yahoo’s instant messenger client during the wee hours of the night when no one else was awake. He couldn’t test new features on his sleeping friends, so he added a feature where a user could add themselves as a friend. That feature is still part of Yahoo Messenger.

Says Filo, “Did you know that you can add yourself as a contact in Yahoo! Messenger? Well, you can. Why? Because Ash needed a way to test the code to see if it was actually working the way we wanted it to while Messenger was first in development. He couldn’t wait. He wanted that feedback immediately and he wanted that chance to get things right on the fly. That’s the kind of ingenuity Ash brought to Yahoo!. He helped us to move faster than we thought we could and to find new ways to look at our work from the user’s point of view.”

Patel says Yahoo is in a transition period but is building the infrastructure it needs to compete in the future. Everyone is focused on social right now, he says, and so is Yahoo. But they have product plans for “what’s next after that” as well.

I asked Patel about Yahoo’s current troubles, saying that Yahoo sort of feels like England in 1940, surrounded by the Nazis (I’m not sure who the nazis are in my analogy, but we met very early this morning and it was the best I could come up with). His response – “Well, look who won the Battle of Britain…Things turned out ok.”

We also had a side discussion about whether Carol Bartz could play the part of Winston Churchill. But like I said, it was early.

What’s next for Patel? He says he’s going to take a few months off with his family and start to think about the future this summer. He advises a few startups, he says, although he doesn’t seem to be suggesting, yet at least, that a startup is in his future.

One thing is clear – Patel will be missed. He is a genuinely likable and intelligent guy who’s seen a lot over the last 14 years. It’s a loss for Yahoo that he’s leaving, but this guy clearly will continue to bleed purple.

Editor’s note: Big Data has been around for a long time between credit card transactions, phone call records and financial markets. Companies like AT&T, Visa, Bank of America, Ebay, Google, Amazon and more have massive databases they mine for competitive advantage. But lately, Big Data is finding its way to the smallest startups. The Web and cloud computing brings Big Data everywhere. But what exactly is pushing Big Data forward?

To answer that we brought in an expert, Bradford Cross. Bradford is the Co-Founder and Head of Research at FlightCaster. FlightCaster is backed by Y Combinator, Tandem Entrepreneurs and Sherpalo Ventures. The company analyzes large data sets to predict flight delays. Bradford is chair of the Dealing with Big Data track at Cloud Connect this week.

We are in a Renaissance for computer science, engineering, and learning from data right now. The scale of data and computations is an important issue, but the data age is less about the raw size of your data, and more about the cool stuff you can do with it. Now that there is so much data, it is time to unlock its value. Really neat things are happening already—like the way the people of the world can educate themselves on all manner of issues and topics, or the way data and computing serves as leverage in other scientific and technical endeavors. There will be lots of amazing stuff on the web, but innovation will come in other domains as well.

The recent big data trend is about the democratization of large data more than its growth. In articles like the Economist’s recent piece on the data deluge, we hear about big data everywhere. We hear about what big data and the cloud mean for the enterprise, but they have had big data for a long time. eBay manages petabytes in its Teradata and Greenplum data warehouses. Sophisticated startups extracting value from big data is also nothing new—it has been happening at least since the days of Yahoo! and Google, and they have done it without the data warehousing folks.

Now focused early stage startups can get up and running faster than ever. Less technical analysts at companies like Facebook and Twitter can access massive amounts of data easily. Even individuals can undertake cool projects with big data, such as Pete Skomoroch of Data Wrangling did with trending topics for Wikipedia.

Why Now?

We do not have to build all our own hardware and software infrastructure anymore.

Pioneers such as Amazon have given us the cloud, where we have the capability to run very large server clusters at a low startup cost. Pioneers like Google have paved the way for open source projects like Hadoop and HBase, that are backed by big company contributors like Facebook.

The combination has paved the way for a new class of data driven startup like Aardvark (just acquired by Google) and Factual, it has reduced both cost and time to market for these startups, as we showed with Flightcaster. And, it has allowed startups that were not necessarily data driven to become more analytical as they evolved, such as Facebook, LinkedIn, Twitter, and many others.

So we have big data, the cloud, and open source facilitating new data-driven startups. I like to break this trend down from the technical perspective into three chunks; storing data, processing data, and learning from data. I define “learning from data” to mean data mining, AI, machine learning, statistics, and so on.

Supersize my data. Oh wait, I’ll just have a Medium.

The first time I heard the “Medium Data” idea was from Christophe Bisciglia and Todd Lipcon at Cloudera. I think the concept is great. Companies do not have to be at Google scale to have data issues. Scalability issues occur with less than a terabyte of data. If a company works with relational databases and SQL, they can drown in complex data transformations and calculations that do not fit naturally into sequences of set operations. In that sense, the “big data” mantra is misguided at times. For instance, a GigaOm article about big data in the cloud states:

What is becoming increasingly clear is that Big Data is the future of IT. To that end, tackling Big Data will determine the winners and losers in the next wave of cloud computing innovation.

The big issue is not that everyone will suddenly operate at petabyte scale; a lot of folks do not have that much data.

The more important topics are the specifics of the storage and processing infrastructure and what approaches best suit each problem. How much data do you have and what are you trying to do with it? Do you need to do offline batch processing of huge amounts of data to compute statistics? Do you need all your data available online to back queries from a web application or a service API?

Once your data and its processing are large enough to require distributing the data and the work among machines across network boundaries, things get a lot harder. You have to deal with distributed computing and make tradeoffs like a real computer scientist.

Big Data & The Cloud: Viral Buzzwords 4.0!

The cloud, and hosted services, present very interesting opportunities. One of the greatest is that people can leverage the a la carte economics of elastic computing to do things that were prohibitively expensive due to the requirements of building and maintaining their own hardware infrastructure. The interesting parts about the current cloud are its lack of entrance friction and elastic cost efficiency, the speed with which new entrants can set up, and the elastic capability to run 100 machine clusters for 1 hour if that is what is needed.

We started Flightcaster almost a year ago, and it is a good example of how startups can leverage cloud compute and storage resources, mix some open source like Hadoop with some data mining, and create interesting new technologies with relatively low capital upfront.

The cloud is not cheaper in general. Once people scale to a certain point, they move off the cloud onto dedicated hardware—not the other way around. That may change, and better hosted services may play a role in the transition, but that will take a while. In the meantime, the interesting part of the cloud is the use of elastic resources and the ability to get up and going quickly. The interesting part is the freedom it gives startups to try things they would never otherwise do.

Another notable thing about the cloud is the new architectures emerging as a result of economic and resource tradeoffs.

Storage of large amounts of data in the cloud is much cheaper with blobstores like Amazon S3 than it is to maintain an always-up cluster for a distributed datastore. If you do mostly offline batch processing and you do not need bulk storage to be online, then it is an attractive setup.

Storage and NoSQL

Taking another glimpse from the future of big data in the cloud.

A Big Data stack…will also need to emerge before cloud computing will be broadly embraced by the enterprise. In many ways, this cloud stack has already been implemented, albeit in primitive form, at large-scale Internet data centers, which quickly encountered the scaling limitations of traditional SQL databases as the volume of data exploded. Instead, high-performance, scalable/distributed, object-orientated data stores are being developed internally and implemented at scale…large web properties have been building their own so-called “NoSQL” databases, also known as distributed, non-relational database systems (DNRDBMS).

There are several misguided points here. First, there is not going to be a big data or cloud stack. Distributed systems are about making trade offs and a move toward problem-specific solutions rather than one-size-fits-all stacks. Second, enterprises already have their solution—expensive data warehousing and consulting support. Will open source projects like Hadoop supported by people like Cloudera take a chunk of the business? Sure. But as I mentioned earlier, the most interesting part about big data and the cloud is not cheaper alternatives for the enterprise, it is the opportunities it facilitates for data-driven startups.

There is a lot of talk about the NoSQL movement. The big idea here is that distributed systems are hard, require tradeoffs, and sometimes we are better off with data storage and processing that are specific to what we are doing with the data. Sometimes even with a small amount of data on a single node, there are better alternatives to SQL queries and relational databases—time series data has long been a good example.

Processing and Hadoop: The Elephant In The Room

There is a broad range of needs for processing large amounts of data. These range from simple needs like calculations for log analysis that just need to occur at scale, to middle of the road needs like BI, to complex needs like scalable modern machine learning and retrieval systems.

There are a different approaches one can use to service specific needs. Again, we see the pattern of moving away from one-size-fits-all stacks, and toward building for your needs. That said, there are very generic abstractions like Map-Reduce that work well for a lot of use cases. Distributed systems are hard to get right, so when something like Hadoop gets a lot of momentum, it retains that momentum until alternatives have the time to mature enough to solve the hard problems with fault tolerance, performance, and so forth. Not everyone is Leonardo da Vinci, so people should not attempt to create these systems on their own unless they really know what they are doing. In that sense, the cloud and big data are facilitators of open source.

An important aspect of processing at scale is abstraction. Writing complex or even simple computations in raw Map-Reduce is verbose for programmers and intimidating for others who might want to play with the data. Abstractions over Map-Reduce like Pig and Hive make simple things easy, and abstractions like Cascading make hard things possible. The Map-Reduce paradigm, and Hadoop in particular, have been a big success. That said, Map-Reduce is not the only important piece of compute infrastructure. Message queues serve as the backbone of a lot of compute architectures – implementations of AMQP, such as rabbitmq, are a prime example. You can accomplish a lot with producers, consumers, and a messaging system. Distributed storage and processing systems can also be very tricky to configure and deploy, requiring a pretty deep understanding of the system – hence the business case for folks like Cloudera.

Learning from Big Data

Hal Varian, Google’s Chief Economist, recently said,

The sexy job in the next ten years will be statisticians… The ability to take data—to be able to understand it, to process it, to extract value from it, to visualize it, to communicate it

Unfortunately for those of us working on these problems in real life, it is not so simple. The archetypal data-renaissance man is mathematician, statistician, computer scientist, machine learner, and engineer all rolled into one. There are opportunities where you can lack some of these skills and work with a team that supplements your weak points—a startup is not one of those.

Now that we can store so much data, it is attractive to do previously unimaginable things with it. We are sure to see cool applications in fields from the internet to biotechnology to nanotechnology and fundamental materials science research. Almost all advances in every field of science and technology are now heavily dependent upon data and computing. Machine learning is serving a fantastic role as a bridge between mathematical and statistical models and the worlds of AI, computer science, and software engineering. We are exploring applications in learning from text, social networks, data from scientific experiments, and any other data sources we can get our hands on.

The data renaissance does present some difficult issues. There are not many places one can recieve a good education on working on these problems at large scale. Scaling our modeling and optimization algorithms is hard. We need to figure out how to partition and parallelize, or sometimes trade speed and scale for approximately correct calculations. Another issue is that we are often using simplistic models, albeit with pretty good results in many cases. We would like to move toward a deeper approximation of real intelligence.

But the data renaissance is here. Be a part of it.

Having now written two books about my failures in work, life and love, I think I’m qualified to say that the only difference between a memoirist and a prostitute is timing.

A prostitute sells sex for money – that money being payable either immediately before or immediately after the act. A memoirist also receives money for having sex – but our payment comes via a publisher, months or years later, once we’ve recounted the amusing or titillating details in print. In the final analysis, really, we’re all whores.

And yet, in terms of public perception, the distinction of payment and timing is vital. Actual prostitutes are – generally speaking – looked down on by society: labels like ‘whore’ and ‘hooker’ being, almost without exception, used pejoratively. Memoirists, on the other hand, tend to be reasonably well regarded, not least by themselves. For that reason, accidentally calling a hooker a memoirist is unlikely to cause offense, but accidentally call a memoirist a hooker and… hoo boy…

This time last week, my friend Zoe Margolis – who writes as the Girl With A One Track Mind – was asked by the UK’s Independent on Sunday (IoS) newspaper to write a column about how she went from being an anonymous sex blogger to a widely-recognised advice columnist and memoirist. Zoe, I should emphasise, does not have sex for money. I know this for a fact: we shared a house at SXSW a couple of years ago and she stubbornly refused to sleep with me, despite the fact that I paid for all of our groceries at Whole Foods.

And yet, thanks to an astonishing but – I hope – innocent piece of lazy subediting, when the IoS published her column they did so under the unambiguously libellous headline “I was a hooker who became an agony aunt“.

Hoo boy.

The IoS reaslised its mistake (for want of a better word for “misquoting one of our writers as calling herself a whore”) within an hour of the paper going to press and quickly changed the headline in print and online. But of course the damage was already done. Although, according to the paper, only a couple of thousand hard copies had been dispatched to news stands, the web version had already been syndicated to dozens of other sites – including Yahoo! – and such far-flung newspaper websites as the Times of India. Worse still, it took several more hours – and increasingly vocal complaints by Zoe – before the IoS changed the story’s URL which still contained the full wording of the original headline.

An embarrassing screw up for the Independent – but one that other papers can learn from, right?

Not so much.

A few days later, another UK paper – The Daily Mail – ran a story headlined “I posed as a girl of 14 on Facebook. What followed will sicken you …” The story was indeed sickening; written by a former police detective, it revealed how after signing up to Facebook as a young girl, he was immediately contacted by middle-aged men looking for sex. There was just one problem with the story: it wasn’t true.

For a start the story was ghost-written by a Mail journalist, loosely based on a phone interview with the detective. More importantly, the detective had made clear – repeatedly – that the social network in question wasn’t Facebook. In fact he’d actually praised Facebook for having put in place measures to protect young users against ‘grooming’ by adults. Unfortunately, the Mail seems to have a beef with Facebook – they previously accused the site of causing cancer – and so decided to name and shame it both in the article, and in the headline and – yup – in the URL. As with Zoe’s story, the headline was changed after a few hours (having already been widely syndicated) but the libellous URL remained uncorrected for more than a day.

In both cases, the result was the same – the Independent and the Mail each issued apologies and corrections in the next day’s paper and online but both Zoe and Facebook say they intend to take legal action both for the initial error but also for the further harm done by the time the papers took to correct their libellous URLs.

We’ll have to wait and see what comes of the proposed lawsuits, but in the meantime both cases illustrate a huge problem with the blurring of the line between old and new media. In the old days, editors understood how their papers worked. If a libellous story was printed, they would stop the presses (if it wasn’t already too late) and they would issue an apology the next day. Most readers would see the apology and all would be well. Yes, there might still be a libel action, but at least the publication could show that they’d halted the presses and issued the apology, thus mitigating some of the damage done.

Today, that’s no longer the case. The simple fact is that many editors have absolutely no idea how their papers work any more. According to the Guardian, when Charles Garside, assistant editor of the Daily Mail, was asked about the fact that the libellous URL was unchanged for more than 24 hours, he described it as “a technical matter”, adding: “We are removing elements of that”.

“A technical matter” – which of course is code for “I have absolutely no idea how the Internet works. We have geeks to do that kind of thing, and they were at home – probably masturbating or watching Battlestar Galactica – or both – when the story went up”

With those three words – “a technical matter” – Garside lays bare the problem newspapers face in moving online. Editors understand stories and they understand headlines, but today they also need to understand URLs and automatic syndication and all of the other “technical matters” that are just as much a part of the modern newspaper as standfirsts and pullquotes. This is a lesson I learned the hard way back in 2005 when I was hit with an enormous libel claim (and the possibility of imprisonment for contempt of court) when the publication I edited linked to a libellous story (published in France) about a certain English Premiership football player. Although we were careful not to name the player in our story, we were still held responsible for identifying him because the URL we published contained his surname. The fact that we’d used our in-house link-shortener to mask the true URL was no defence as the shortener was hosted on our own server and resolved to the correct address before the reader left our site. Since that day, I’ve understood that a URL can get you in just as much legal hot water as an ill-judged headline.

Unfortunately that seems to be a lesson that editors at certain major national newspapers are yet to learn. If I were the owner of the Independent, or the Mail, or any other newspaper I’d insist that my editors spend a few hours of their time learning how their papers work in the digital age. That means understanding not just how to stop presses and issue apologies but also how to get under the hood and change URLs; how automatic syndication works and how to ensure any subsequent apology is amended to every online version, and not just the one hosted on their main site.

Finally, the way that apologies and clarifications are published needs to be seriously re-thought. Publishing a correction in the next day’s paper, or as a separate item on the publication’s website, is a ridiculous anachronism. People no longer read the same paper every day: the fact that they stumbled across a story in the Independent or the Daily Mail once through Google News doesn’t mean they’ll ever read a story in that paper again. It certainly doesn’t mean they’ll see a correction published 24 hours later.

Whereas once a libel court could be satisfied that the publication of a printed apology would mitigate libel damages, that’s unlikely to hold much weight in any legal action concerning the stories about Zoe Margolis or Facebook. Both Zoe and Facebook made their reputation online and it’s online rather than in print that they have the most to lose.

As a Facebook spokesperson told the Guardian, a traditional correction can’t undo the ‘brand damage that has been done’. Perhaps, then, the Mail and the Independent should take a lesson in damage control from Zoe. Moments after the Independent published their apology, she tweeted out a link to it and asked her followers to ‘please retweet’. Many (including me) did, and still others republished it on their blogs. Not only did that spread the word that Zoe isn’t – and has never been – a hooker, but it also helped ensure that most of the Google results for “Zoe Margolis +hooker” point to the correction and not to the original libel.

Had the editors at the Mail and the Independent been quicker to update their libellous URLs, and had they used Twitter and other social networks to push out their apologies then perhaps they could have avoided what will quite possibly be some very costly legal action.

But then again that would require them to understand the first thing about the Internet and other “technical matters”. And if they’ve proved anything recently, it’s that they really – really – don’t.

During his keynote at SXSW this afternoon (live blog here), Twitter CEO Evan Williams just announced a new “At Anywhere” platform, which allows websites to more deeply integrate the service into their sites. The idea is to offer a more seamless experience to Twitter users navigating third party sites like the Huffington Post and the New York Times, giving them Twitter content without forcing them to jump off the page they’re currently viewing. The details on the new platform are still scant, but this is Twitter’s answer to Facebook Connect, which we reported on back in January.

Among the features:

• When you browse a site that uses @anywhere, people and brands that have Twitter accounts will be highlighted with a hyperlink. Mousing over that hyperlink will show a small box (a “hovercard”) containing their Twitter information, including their most recent tweet (in effect it means you don’t have to click over to Twitter’s homepage to see their Twitter profile)
• Publishers will be able to more deeply integrate their own Twitter profiles, making them easier for their readers to ‘follow’ them
• Sites will be able to implement @anywhere with a few lines of Javascript.
• The new platform is launching with a number of major sites and services, including the New York Times, Huffington Post, Meebo, Amazon, Yahoo, Bing, and eBay.

It looks like the platform may eventually be hosted at Twitter.com/anywhere, which currently features a placeholder Twitter account that tweeted “Stay Tuned”. Update This may actually be a Twitter account related to the platform — it just tweeted “If you’re a javascript guru and want to help us build @anywhere and work with publishers @jointheflock”.

From the Twitter blog:

We’ve developed a new set of frameworks for adding this Twitter experience anywhere on the web. Soon, sites many of us visit every day will be able to recreate these open, engaging interactions providing a new layer of value for visitors without sending them to Twitter.com. Our open technology platform is well known and Twitter APIs are already widely implemented but this is a different approach because we’ve created something incredibly simple. Rather than implementing APIs, site owners need only drop in a few lines of javascript. This new set of frameworks is called @anywhere.

When we’re ready to launch, initial participating sites will include Amazon, AdAge, Bing, Citysearch, Digg, eBay, The Huffington Post, Meebo, MSNBC.com, The New York Times, Salesforce.com, Yahoo!, and YouTube. Imagine being able to follow a New York Times journalist directly from her byline, tweet about a video without leaving YouTube, and discover new Twitter accounts while visiting the Yahoo! home page—and that’s just the beginning. Twitter has proven to be compelling in a variety of ways. With @anywhere, web site owners and operators will be able to offer visitors more value with less heavy lifting.

During the Behind the Scenes of Gmail panel today at the SXSW festival in Austin, Texas, team member Jonathan Perlow made a revelation that will be a huge relief to power Gmail users: things will soon get a lot faster.

When addressing the question, “why is Gmail slow?,” Perlow asked the audience to raise their hands if they thought Gmail was too slow. A solid number of people raised their hands. Perlow said that the reason everyone didn’t is because slowness is really only an issue for power users of the service — those with hundreds of thousands or even millions of messages. As someone approaching 100% usage of my Gmail inbox, I know this problem well.

The good news is that not only is Google well aware of the problem, they are have a solution. While he didn’t elaborate on the backend changes that will be the solution, Perlow was confident enough to say, “we are fixing it.”

Gmail currently has hundreds of millions of users (Google wouldn’t give the exact number), and it ranks as the number three email service in the world (behind Yahoo Mail and Microsoft’s Hotmail, both of which have been around longer than Gmail).

This afternoon at SXSW, a panel of Gmail and Google Buzz team members took part in a panel where they discussed what goes on behind the scenes at Gmail. The panel covered a smattering of topics, covering everything from Gmail stickers to site speed, but eventually the discussion turned to the elephant in the room: Google Buzz’s privacy shortcomings when it launched last month.

Google Product Manager Todd Jackson said that Google had learned a lot from the incident, acknowledging that Google was in error when it made the assumption that users wanted to move their email and chat contacts over to their Buzz social graph, and auto-followed them.  To make sure that kind of blunder doesn’t happen again, he revealed that Google may start pre-releasing new Buzz features to small subsets of users.

So why exactly did Google Buzz launch with some key social features missing? Jackson said that while Google employees were testing out the product internally, they never had much desire to mute any of their coworkers, and that their email contact list closely matched the people they wanted to follow on Buzz. Obviously, that wasn’t true for most people once the product was released outside of the Googleplex. Which is why Google is considering pre-releasing new Buzz features to a few thousand opt-in users long before they’re rolled out to the public.

That would stand in contrast to what Google does for many of its major product launches, as Jackson says that the company doesn’t like to preannounce things (it frustrates users when they can’t try the new release out for themselves). But in the case of Buzz, where changes can have a major impact with respect to user privacy, it sounds like Google may be making an exception. Jackson also noted that he had actually asked SXSW speaker danah boyd to give her keynote talk on privacy and publicity at Google headquarters.

Today at the Gmail Behind The Scenes panel at the SXSW festival in Austin, Texas, key team members of the Gmail team revealed the true secret of the service: Shit umbrellas.

Product manager Todd Jackson made the humorous revelation when explaining how the Gmail team works as a group of about 100 people, the vast majority of which are engineers. “You can either be a shit funnel or a shit umbrella,” Jackson says.

What he means by that is that as a product with hundreds of millions of users (and a company with thousands of employees) there’s a lot of stuff constantly being hurled at the team — as a shit umbrella, the product managers protect the engineers from getting distracted. It’s not enough to be a “shit funnel” where they would pass some of the junk down to engineers, they need to fully protect the engineers.

This sentiment was echoed by Edward Ho, who is known as “Mr. Buzz,” as he’s the one who built up the Google Buzz team (a sub-unit of the Gmail team). Ho noted his hatred for unnecessary meetings, and has made sure that when the Buzz team needs to have them, they are based around demos, not talking about things. “It’s all about what you’ve done,” Ho says.

Some other interesting notes about Gmail:

• The original invites system wasn’t a marketing ploy, it was simply an engineering decision to make sure they could scale
• There’s a 30-1 engineers to products managers ratio in the Gmail team — it’s certainly one of the biggest ratios at Google
• The Gmail team is spread over a few offices around the world (including Zurich), it used to be more, but they consolidated to help the product.
• There are “hundreds of million of users” — the third-largest email provider
• In India, Gmail is the number one email provider
• Gmail is growing fasters internationally than in the U.S.
• Gmail is available in 53 languages
• Internally, the Google Buzz team was known as “Team Taco Town” after an SNL skit
• Google uses Gmail internally (obviously), switched over from Microsoft Outlook at launch (about 6 years ago)
• Gmail is slow for some users mainly because they have a ton of emails saved. A fix for that is coming soon
• Most of gmail is written in Java, JavaScript, C++
• There are several hundred thousands lines of javascript in Gmail – one of the biggest in the world
• No new feature can launch for Gmail that adds latency to the product

[photo: flickr/atomicjeep]