I’m here at Facebook’s Developer Garage in Palo Alto, where the company is unveiling a roadmap for the platform and potentially some significant changes that could alter the way apps are spread through the social network. I’m live-blogging as we go so all of this is paraphrased. You can watch a live-stream I’ve embedded below.
As we wrote about earlier, some of these changes could include removing notifications altogether or tucking them into a sub-section and moving requests into part of the inbox. Facebook is also potentially pushing its developers to get user e-mail addresses directly instead of relying on the social network as a middleman.
Mark Zuckerberg: We feel very good about what we’re doing over the next months and years. This will help foster a lot of innovation and make so Facebook Platform and Connect sites can continue to grow.
When we’re thinking about how we enable this going forward. The first thing we start off with is building a very good team here to serve developers.
We expect to reach new levels of speed and efficiency in the types of APIs we’re building. On the product side, Bret Taylor — he joined Facebook a couple months ago when FriendFeed joined us. He’s now leading platform on the product side. A lot of cool new stuff will be coming out — some of which we’ll talk about today, and some of which we’re only starting to talk about.
We’re going to talk about a roadmap for the next few months. We want to commit to certain things so developers can build against what we’re doing.
Ethan Beard: Some of our biggest developers are here. All of you are totally kicking butt on platform today. The growth we’ve seen on platform has been incredible. Over 1 million developers are part of this community. There are over 350,000 applications. We have tens of thousands of Facebook Connect web sites are being built today. Three of the top 10 iPhone games are using Facebook Connect.
There’s been a lot of anxiety in the press and what we’re trying to do is reduce anxiety. The death of platform is greatly exaggerated. It is living. Seventy percent Facebook users are touching the applications you build.
Developers simply ask for predictability — you want to know what’s going on in Facebook. We’re trying to bring you a lot more of that predictability. We’re putting forth a roadmap so you can understand what’s happening with platform. We hear from developers that they’re trying to plan out their 12-month roadmap. In order to address that, we’ve taken an unprecedented step in looking at everything in Facebook and where we’re investing our resources.
This is very challenging. Facebook is a fast-moving company. It’s hard to nail down everybody in Facebook. We need to be able to tell developers there. The platform is exceptionally important for our strategy.
This is a six-month roadmap. This is not a product launch announcements. This are mock-ups. These are not final designs. This is the start of a conversations. The decisions have not been made. We are not here today to talk about product launches. We’re talking to you about the products we will be launching. This is the start of a conversation.
What is the best way for us to build a platform that will let you build great experiences?
Communications Channels – When we look at the communications channels, the first is from the users perspectives. Users actually struggle to understand where they should go to get the messages. There’s inboxes, messages. There’s five, six, seven different places they need to go. There’s too many messages. The other side of it is from the developer.
Developers use a number of channels — requests, notifications, proxied e-mail, the inbox, the stream.
(Ethan shows off his notifications box.) There are 99 messages here. There are many messages being pushed into different channels. The bad messages tend to drown out the good ones. So what we’ve done is try to take a step back. What are the messages you’re trying to get across? We think there are three different ways you should communicate.
The first is the stream — it has become a more and more powerful method. We believe the stream is the best location for broadcasting one-to-many types of applications. As the stream has become more and more important, you have figured out how to make it more and more important to you. The stream will be the primary place.
The next type of communications is user-to-user. Lots of types of communication is user-to-user — which takes place through the requests channel. Users don’t know where to go to find messages from their friends. We’re going to consolidate that into the inbox. Users need to understand where to get the messages from their friends. What we really mean by that is — we believe that when a user has a highly intentional message and they type that person’s name, that message should go into the main inbox. So for example, if I’m playing Bejeweled, I could send her a direct message. Similarly, if I wanted them to join a Cause, I could send them a direct message. Additionally, we know there are some types of communications which are quite powerful — which are one-to-some that use the multi-friend selector.
For example, if I want to send out a mass message looking for fellow Scrabble players, they could go into the inbox. Most importantly, we’re spending time in multi-friend selector. We’re looking for ways to filter the multi-friend selector. We’d rather it show all the friends who actually play Scrabble instead of just the first ones across the list.
We believe if we can raise the fidelity of the messages, users will be much more happy coming toward those messages. (They may go to a separate ‘Invites’ tab in the inbox.)
Regardless of all the communication channels we put in place, not all of them are guaranteed. There is no way for me to actually communicate with the user. And so, to be honest, it’s been tough to decide who owns this customer, We’re taking the unprecedented step of making available to developers, user e-mail addresses. What we will do is actually create a way for, or actually prompt a user, to share an e-mail address to you. You will always have a direct way to contact your users. We talked to Connect partners, we think this is going to light a fire under connect. There won’t be this question of who owns the user.
One-to-many will go in the stream. User-to-user to go into inbox. We want to make it clearer for users to understand where they need to go.
Discovery and engagement
We’re going to be moving the navigation from the bottom of the page to the left-side. We think it will be much more prominent. We’ve added in some new features. So frequently when we talk to developers — they’re looking for engagement, they’re looking for how to get back in touch with users. There’s a new feature called Counters to signal to users that they have an action or activity they need to take. We think applications will come up with interesting ways to use this.
Next up, we have dashboards for ‘Games’ and ‘Applications’. We’re launching a dashboard for games — some of our largest and most successful developers create games. Our users love games. The Games dashboard is a destination for a users’ entire gaming activity on the site. Users will no longer forget the game they’re playing.
We’re working on some changes to the top navigation to a ‘Canvas’ page to help users understand that it belongs to the users. We want you to build long-term successful business.
New Products and Programs
So first off, we’ve spent a lot of time investing in new products for developers. We’re launching an entirely new developers Web site. On this, we’ll be rewriting our documentation and how-to guides. We’re making it community-enabled. Everything that you see here today we’ll be publishing on a developer roadmap. We’re committed to updating our roadmap so you can understand what the future of platform is. Finally we’ll be launching a platform live status. We’ll hear from developers that if they see a problem in their application and they’re unsure whether it’s their problem or ours.
So what we’re doing on the platform live status — we want to show the live status, as well as a prioritized bug list.
Policies
When we ask developers about policies, no one knows what they actually are. So we’ve actually tried to create a set of principles which are easy to remember. We think they’re easy to remember. We think it’s important for developers to follow the spirit of these principles — (Examples: Be trustworthy).
We’ve taken our policies and reduced them down to three pages. In back of these policies will be a set of screenshots of best practices that we will continue to update as we see new best practices or violations. We think this is the best way to explain what you can and can’t do.
Finally, we’re looking specifically at enforcement. A lot of this is borne from our experience with verified applications. What we’ve noticed is that the quality of the applications that go through verification is significantly higher. We’re ending the verification program as a standalone program. Instead we’re going to be proactively checking apps that are above a certain size for policy violations. This is a significant expansion of the team. We think it’s extremely important.
Finally, there’s a new open graph API. It allows any page on the web to have the same features as a fan page inside Facebook.com. A user can fan that page, it can show up in their profile, in addition that page can post information into that user’s news feed. This is kind of a big shift for us. This is saying that the graph doesn’t have to exist on Facebook. What’s most exciting for everyone in this room. We’re actually opening this up. This is tremendous opportunity for developers to help users connect with them.
Abonner på:
Legg inn kommentarer (Atom)
Ingen kommentarer:
Legg inn en kommentar