MySpace Developer Team : communications

New Viral Channel for MySpace Apps

Test User — Tue, 07 Jul 2009 22:41:00 GMT

App Activities are now visible to all the friends of a user, regardless if they have the App installed. This means that App Activities are another channel by which your App can virally grow.

If you are already publishing App Activities, you technically do not need to make any changes, however we encourage you to think about how to best leverage App Activities as a user acquisition channel.

To ensure a quality user experience, we provide users the ability to block unwanted App Activities and other communications. If the user has the App installed, they will have the option to turn off receiving App Activities for the App or uninstalling the App. If the user does not have the App installed, they have the option to block all communications from the App.

As always, the user experience is of utmost concern to us. We'll be closely monitoring the use of this feature. Any developers that are found to be abusing this functionality to the detriment of the user or in violation of the Terms of Usage will be dealt with immediately.

The team has put in a lot of hard work into this feature and the required infrastructure to support it. We look forward to seeing the results of developers taking advantage of this new viral growth channel. Please send us your feedback and success stories.

More Information on requestShareApp / App Invites

Donny Mack (DM) — Mon, 07 Jul 2008 16:59:00 GMT

More Information on requestShareApp

This is a follow-up on Kyle’s post “quick update on ACC” with some implementation details.

http://developer.myspace.com/community/blogs/devteam/archive/2008/06/30/quick-update-on-acc.aspx

* As Kyle mentioned this feature is not yet in production, but will be soon. We wanted to get out the implementation details now so when we're ready to turn it on, you will be too.

Invoking requestShareApp

First let’s take a look at the signature:

opensocial.requestShareApp(recipients, reason, opt_callback);

· recipients: this is a person’s friend ID. We currently only support sending in one ID at a time

· reason: this is the message you want sent. I’ll go over the rules for this below

· opt_callback: a callback function

Reason

The reason is an opensocial.Message object that has the text you’d like to have displayed in the invite set as the opensocial.Message.Field.BODY (which you can also pass into the constructor).

There are a few rules for the text:

· The text is limited to 150 characters – the character count does not include your application name or the sender and/or recipient display name. More on this below

· You can not include any HTML markup. Adding your links to your application, recipient and sender will be done by us.

· We have supplied three place holders you can use to add your application name, sender name and recipient name within links:

o [sender] – this will be transformed to a hyperlink with the senders display name as the text. The link will go to their profile.

o [app] – this will be transformed to a hyperlink with your application name as the text. The link will go to the applications profile.

o [recipient] – this will be transformed to a hyperlink with the recipients display name as the text. The link will go to their profile.

· You do not have to use all the placeholders. Example below.

Example Code

The code is pretty simple.

message = opensocial.newMessage("[sender] would like you to intall this really super application [app].");

opensocial.requestShareApp(recipientUserId, message, function(){
    alert('sent application invite');
    }
   );

recipientUserId to be the userId of the recipent.

The stubs for requestShareApp are already in production so you can wire up your applications now. Since the call will fail you’ll want to hide the functionality until we turn things on.

There are two ways to check if SHARE_APP is enabled. One is to make the call to requestShareApp() and if it’s not enabled you’ll get an unsupported back. The second is to use getSupportedPostToTargets() to get a list of supported PostTo targets – this is not part of the OS spec, but because requestShareApp currently uses PostTo it’ll work.

quick update on ACC

Kyle — Mon, 30 Jun 2008 14:59:00 GMT

I mentioned in a previous post that we're working on a new App Communications Channel ("ACC"). As you probably guessed, we're not quite going to get it out in June as we were shooting for, but the good news is that we're very close, so I want to give you guys a quick preview.

A lot of your apps are already making good use of the communications tools we've made available so far: our "Post To" functionality enabling apps to initiate user messages, comments, bulletins and blog posts. The goal for ACC is to provide new types of messages that are unique to applications and that have app-specific functionality. The first of these new message types are App Invites. Here's how this new invite will look to a recipient:

Quite a few things to point out here. First, App Invites will appear in a new Mail Center folder called "Notifications". This new folder will also contain other important messages including Comment requests, and there will be specific indicators for all these messages in the Updates box on Users' Home Pages. Second, the App Invite will include your app picture and allows you to specify the custom text that recipients will see. We think this leads to a much clearer presentation than invites contained in standard messages. Finally, these new invites allow recipients to add your apps right from the invite itself rather than having to go to the app profile or canvas. Here's what recipients will see when they click "Add..."

This dialogue will appear as a "lightbox" overlay right from the Notifcations inbox, so we hope it makes adding your apps much easier for MySpace users.

So how will these new Invites get generated? As with Post To messages, your apps can initiate App Invites from the Canvas page, but using the OpenSocial requestShareApp method. We'll provide more details in next few days on the exact syntax to use so you can start preparing your code. Here's a view of what the sending user will see after initiating an invitation:

I want to emphasize that the same guidelines we've put in place for existing messages apply just as strongly to App Invites: no incentivizing invitations, no tricking users, no auto inviting, etc. The goal for App Invites and ACC generally is to make app communications clearer and easier for end-users. If that goal is achieved, your apps will spread naturally and effectively. On the other, if users perceive these new messages as "spam" we all lose. To prevent that, we are also limiting App Invites to one recipient at a time initially. Utlimately, though, it's really up to you guys to show that we can utilize these tools responsibly and in ways that bolster the ecosystem.

Finally, now that I've whetted your appetites, I'm sure you're wondering when this cool new stuff will be ready. Be assured your trusty MDP Team is working long hours to get this out, and we expect to have it live in the next couple of weeks. Also, as mentioned above, we'll be providing more implementation details and info in advance.

/Kyle

A message from Tom

Tom — Tue, 20 May 2008 20:04:00 GMT

Hello Everyone,

One of the things I've always loved about my job is interacting with users on a daily basis. Not only do I enjoy it personally, but it's been a key factor in our success. I can't think of another company where the customers have such a direct feedback loop to a senior executive. If I make a mistake, I hear about it. It takes all of about 10 minutes from the launch of a feature for me to know whether we did it right or whether we failed miserably. Almost everything we've created with MySpace came from users telling me what they wanted.

The MySpace Developer Platform has been something of an anomaly in that regard. Users were scared of it before it even arrived. Before the platform launched, users told me they didn't want to get spammed, and that they chose MySpace over other sites because they weren't getting poked, and nobody was throwing sheep at them. Every social network--from Bebo & Orkut, to Friendster & Facebook has "apps" now. Most of the feedback I received was that users were sick of it. As one forthright user put it: "apps suck!"

What these users' anxieties and concerns did not take into account is that MySpace has always been a platform. MySpace has always had "apps." From MySpace's inception, we've benefited from the creativity and resourcefulness of both our users and third-party companies. It's MySpace users creativity that led to profile customization and created the entire ecosystem now known as MySpace "layouts." It's YouTube that gave users the kind of video player they wanted on MySpace. It's Photobucket, Slide and RockYou that gave MySpace users the kind of tools they needed to share their photos. There were widgets similar to Honesty Box and Graffiti on MySpace before many other social networks even got started, but with a key difference: those widgets did not have the unchecked messaging capability that has made other platforms so painful.

It was by viewing the terrain from this broad perspective that we decided to move forward, for the first time, with something our users were not expressly asking for. We believed that customized profiles, widgets and applications provided real value to users. In the past, we'd just gotten out of the way and let it happen. With the plan for the MySpace Developer Platform, we set out to provide the tools that would ease this kind of development and facilitate better, more useful features for MySpace users. But we also knew we had to take a measured, cautious approach to app communication, or the platform wouldn't work.

Because MySpace was so open from the beginning, security and spam had always been a concern for us. We tried to allow users to do anything they wanted, while stopping them from getting "p0wned". We were forced to block companies and code at different times, and no one understood our reasons. We were not public about our "rules" and our actions, because we focused on the users, not the developers. That was clearly a mistake.

With the launch of MDP, we've tried to change that. We've been very public about what we are doing, when we are doing it and why. I've said very little about the platform until now, because, I simply don't like to do press, interviews, or write about our plans in this way. There are many people at the company far better at communicating with our partners than I am. But I thought speaking now was important because this blog post is meant to represent the voice of the users to the development community. What users want is something I've lived with daily for 5 years now, and I am best qualified to make these statements.

Balancing the needs of a community is never an easy job. There are many constituents, all with their own needs and desires. The needs of the few cannot outweigh the needs of the many. (I always wanted to quote Star Trek philosophy!)

With these concerns in mind, we launched MDP with deliberate restrictions around app communications. Most notably, apps were limited to sending one message at a time, and we gave users the ability to block messages from apps they didn't like. This approach worked -- users have not rejected the MDP or Apps overall. In fact, most of the fears around the notion of "apps" have disappeared into the ether. Apps like Picnik, Flixster, Shelfari and many others have added real value to MySpace without causing any user concerns at all. Still, we realized that some good, popular apps were causing alarm among the userbase, because of the way they incentivized user behavior. Left unchecked, these apps could create a negative experience for everyone, making it a chore to check your inbox each morning.

To prevent that from happening, as of today, we're instituting new rules for how apps can communicate with users on MySpace. You can read about these rules here and in the Application Guidelines, The main thrust of these changes is to limit app communications that are based on incentivizing or tricking users. To be clear, the purpose of these changes is to emphasize to developers that their focus should be on creating great apps that users will want to tell each other about. The best viral software is software you can't live without. Unfortunately, for some developers, the focus has been on how to come up with the best methods of viral distribution.

The outcome of these rule changes mean that some very popular apps--those which are games designed to give users points for spreading the game around, may cease to exist as before on MySpace. That said, I think its important to suggest what we were hoping for with the creation of this platform.

When we conceived of the MySpace Developer Platform we thought of the "apps" that were already so important to MySpace users--the YouTube's and Slide's of the world. We hoped developers would create software that had real utility and improved upon the MySpace community. We hoped they'd make features that we'd never have time to build ourselves. Or features that improved upon our own. We also realized that because users were only able to control their profiles, there had very little third-party development around other parts of MySpace. (Very little, but there had been some.) This is why we opened up app access to the user home page. We hoped developers would recognize the opportunity of creating value for the user on the users very own start page. Apps don't have to be about profile "bling" -- users could login to MySpace and enjoy homepage access to all sorts of useful features. Imagine reading email, looking at news, or using a web-based IM from MySpace start page, and you start to get the picture. The platform provides that flexibility, but so far I haven't seen an app that really takes advantage of it. Here's to hoping someone will!

Thanks for your time and your work!

Tom Anderson
President
MySpace.com

New App Guidelines - MUST READ!

Kyle — Tue, 20 May 2008 18:54:00 GMT

We've posted a new version of our Application Guidelines today. Please have a look - there are a number of important changes everyone should be aware of.

In particular I want to call out a new section relating to "Application Communications". A little more than a month ago we released our first set of APIs that allow your apps to initiate user-to-user messages, comments, and bulletins. A lot of you have already taken advantage of these capabilities to build more engaging and interactive applications.

The new rules we've posted today give you clearer guidance on what you can and can't do with the communications tools we enable. You should review these rules carefully in the Guidelines, but here's a quick summary of the most important changes:

No incentives may be given to a member for sending a message, bulletin, comment, or any other form of communication. This includes “points,” “bucks,” increased standing, or even features within the app.
It must be very clear to a member what they are sending, when they are sending communication. “Share with friends” is not sufficient messaging, the link must state “send comment,” “send bulletin,” and so on.
The “no popups” rule we have had in place since day one applies to messaging windows. This means no more popping up a messaging window the first time someone tries to use an app. No popping up messaging windows without a user clicking on a very clearly marked link.

To explain these changes Tom Anderson, president and co-founder of MySpace, has posted a special guest blog post here on the MDP site.

We’ve made some additional changes to the guidelines, most of which won’t be a surprise to you (ex: the
guidelines now clearly state iframing canvas pages is allowed).

Every single developer should take a look at the guidelines as soon as possible. We are enforcing these new
guidelines as of today for newly developed applications.

For those applications that are already live, you will all have two weeks from today – until 5pm PST on June
3rd – to make sure your applications are compliant with these standards. After that date we will be reviewing all applications and will take action on those that are not in compliance with the new guidelines.

If you have any questions regarding these changes, please join us in a new forum topic devoted to this subject where we’ll be around to answer your questions.

Finally, I'm pleased to give you all a heads-up that we will be enhancing our messaging APIs in June with the release of our Applications Communication Channel. "ACC" as we call it is a brand-new messaging service built specifically for apps that will enable custom app invites and notifications. More on that soon!

/Kyle