Lots of exciting stuff! Sign up and register for these sessions, space is always limited.
Today, we can finally take the wraps off a partnership that we've forged with Rosetta Stone, who announced TOTALe, an online language-learning platform. With TOTALe, they've web-enabled their language courses and created an interactive, engaging learning community using the Adobe Flash Collaboration Service.
You can check out the video below to get a feeling of what it's like, but I had the opportunity to sit through several hours of the classroom environment (Rosetta Studio) as well as try their social gaming activities (Rosetta World), and was blown away with how rich a social medium an application in the browser could be. Students were whispering to help each other, one was clearly the "class clown" -- the classroom and social interactions between the students and teacher really shone through.
]]>It's our belief that the web experience is transforming from one that has largely been solo to one that is highly connected to others. And with AFCS, we want to be at the forefront of this shift towards the Social Web, and make it easier for everyone to add real-time social features into their rich Internet applications. Rosetta's new solution built-on AFCS is a great example of this.
See screenshots of Nigel and me dueling it out in a Rosetta World game ... One ... Two ... Three ...
If you want to learn more about AFCS and what it offers, we will be at MAX. Check out the sessions that we're planning and sign up!
]]>
Lots of exciting stuff! Sign up and register for these sessions, space is always limited.
For those of you who haven't completed the survey, please take the time to give us your feedback as it will directly impact the AFCS pricing model. For those who're interested in providing us feedback, here's the link to the survey.
While the biggest benefit in taking the survey is for you to influence AFCS pricing, we’ve added one additional perk -- you will have the option of participating in a drawing for a chance to win one of five $100 USD gift checks or one $500 USD gift check!
Lastly, I must confess, the survey is rather long and takes about 15 minutes to complete -- the statisticians insisted that for the demand curves to be robust we need to incorporate a series of scenarios =).
Thank you for taking the time -- the survey will be open through Friday, June 19th.
]]>As the team chugs along, we continue to receive questions on how the Adobe Flash Collaboration Service fits into Adobe’s overall collaboration strategy and existing offerings such as Flash Media Server, ConnectNow and Connect Pro. Well, Peter Ryce, Sr. Technology Evangelist here at Adobe, has created an awesome presentation explaining it all.
Take a look… and thanks, Peter!!!
We're announcing 2 programs to help us fill that need : AFCS Pilot/Commercial licensing and a partnership with ConnectSolutions.
AFCS Pilot/Commercial licensing is a program intended for small-to-medium-sized ISVs or developers, who want to be able to commercialize, but whose needs in terms of service resources and support are relatively small - "small" here still being a very generous number, which many many apps will fit within. The price to them? Free, until our paid service becomes available. Even once that happens, there will be a level of utilization that will always be free, even for commercial use. For companies/devs who are over that level, they will have the option to pay for the service, based on that utilization.
The Pilot/Commercial program will be a manually screened process - we can't open up the floodgates completely until we've built a self-service e-commerce system. A new license will need to be signed by the pilot participant. We recognize that there's a certain leap of faith here in terms of how long the service would be free, and what the costs will be once it's not. We're going to speak more on timelines and pricing publicly in the next couple of weeks, but for Pilot/Commercial customers, we plan on having an advisory council that will have much more detail about future plans. If you've got an idea that you think can make the coolness cut, feel free to mail us at afcs (at) adobe.com - please note, we can't accept every idea, so the more info you can provide as to your idea, the better your chances.
ﾠWe feel comfortable that we can fit many such developers in the Pilot/Commercial program, and we're working on e-commerce infrastructure to serve even more people, but there are some customers for whom we'd need more dedicated infrastructure to handle their business - in short, single-tenant hosting. In order to scale our infrastructure more quickly, and fulfill these larger projects' needs, we've entered into a partnership with ConnectSolutions.
ConnectSolutions have a huge amount of experience managing collaborative applications based around a similar technical stack to ours. What's almost more important, we knew that we could work very closely with them, having done so in the past. They'll be hosting the same AFCS we do, but aimed at very large projects, which need a custom SLA, dedicated hosting and more customized deployments. Due to the nature of these kinds of projects, the sales model is also very personalized, while our team is focused on more "self-serve" commercial use. This partnership allows us to explore both ends of this spectrum simultaneously, as well as explore more deployment possibilities for the technical stack. As time goes on, we expect to be able to take what we learn from both sides and offer a full spread of options to our customers.
It's an exciting time here on the AFCS team. If you have any questions about what this is all about, please visit us in our Forums (if you don't have a forums account, post on this blog, but it won't be as fun). Also, don't forget to check out the pricing discussion post of this week and take the survey to let us know how you'd like to see us charge for the service.
]]>Our overall approach to determining the AFCS pricing models is built on four key tenets:
* No Barriers To Adoption: There will be no upfront one-time fees to use AFCS and we will continue to provide free quotas to enable developers to quickly build AFCS-powered applications. Pricing will kick-in only when the free quotas are exhausted.
* Pay-Per-Use: The price you pay to Adobe will be determined a-posteriori; in other words, looking back at the billing period we will determine your total bill based on your usage of the service. We will not force you to commit to a certain number of users or amount of usage.
* Predictability And Control: You can set the maximum bill per billing period you'd like to receive from Adobe. In other word, you don't need to have sleepless nights worrying about a "runaway application" cranking the AFCS billing meters. One of the disadvantages of a-posteriori pricing is that you typically have little, if any, control over your final bill (E.g., monthly utility bill.) We are erasing this concern by introducing the notion of maximum bill per billing period.
* Options And Flexibility: To ensure that AFCS appeals to a broad cross-section of developers and use-cases, in the long term, we plan to offer more than one pricing model. Factors such as application type (Bandwidth intensive, Message intensive, Connection-time intensive, etc.) and entity type (Individual developer, ISV, Enterprise, etc.) can greatly influence pricing model preferences. The implication is that as a developer you'll have the opportunity to select the pricing model that best meets your needs. In fact our plan is to eventually allow you to attach different pricing models to your various applications.
So based on these four key tenets we have came up with three pricing models. Let's now review how each of these pricing models would work and their relative merits:
1. Resource Utilization: Today, through the public beta program, we impose restrictions on the number of concurrent users, bandwidth (in + out), connection time / cumulative user minutes, and number of published messages. In the Resource Utilization model we would remove limits on the number of concurrent users and charge along any two, or all three, dimensions of bandwidth, connection time, and messages. We expose application usage along these three dimensions through the Developer Portal and to some extent through the Developer Console. So today you can monitor and estimate usage - and at the time of AFCS commercial launch estimate expected price - by simply analyzing usage over a period of time. We think that the Resource Utilization model will appeal to individual developers and mid-size and smaller ISV's who plan to build new applications where it is hard to predict the success [users or usage] of your application. Predictability will be provided by allowing developers to set a "Max Monthly Bill" and developers can rest assured that they wouldn't end up paying more than what they had originally planned / budgeted for.
ﾠ
2. Peak Concurrent Users: Some developers may find it hard to estimate usage of their application, especially the AFCS-powered components such as chat and webcam video. For example, it may be tough to get answers to questions like how many users will engage in a text / audio / video chat session; how long (number of minutes) will sessions last; or how many chat messages will be exchanged between users. In addition, there is a segment of developers that plans to deploy applications to a known quantity of users such as an internal application targeted at full-time employees in a company. In such situations a developer can approximately estimate the number of users over time. In the peak concurrent users pricing model we align our pricing to the success of your application by allowing you to plan expenses and budgets based on peak user loads. Furthermore to ensure that we protect developers against sudden spikes we can charge based on - just as an example - 95% of peak concurrent users or allow developers to set a maximum number of peak concurrent users per application. Obviously, to ensure that we don't cause our service to come to a grinding halt we'll put some really large usage caps on peak concurrent user accounts that will protect us against runaway applications.
3. Subscription Tiers: Subscription Tiers pricing model offers about three subscription tiers, each of which correspond to specific quotas for bandwidth, connection time, and number of messages. This is still a pay-per-use pricing model as developers always start from the lowest subscription tier and if usage during the billing period crosses quotas of the existing tier by more than, as an example, 5% of allotment then we automatically bump you into the next tier. Higher tiers correspond to higher quotas but lower unit price per quota dimension. Once you are bumped into a higher tier you will be billed accordingly unless usage drops to lower tiers for two consecutive billing periods.
Caution: Please note that we are still working through the details and Adobe reserves all rights to launch any combination of these pricing models, including never launching some of these proposed pricing models. Our goal is to prioritize these options and make available only those that appeal the most to you. So here you go... Please take our quick, less than "60 second" survey and vote for your preferred pricing model. We welcome any additional comments in the survey. Click here to take survey. Note: If you are developing multiple applications and think that there is an application that will be better monetized via one type of pricing model and another through some other model then please complete the survey twice - once for each application.
Also, as a heads-up we'd like to let you know that next month we will follow up with a more robust survey on pricing [... to get a read on actual price points] so please keep an eye out on our blogs as we'd very much appreciate your participation. One thought I'd like to leave you with is that any pricing model Adobe implements needs to be competitive relative to comparable offerings in the marketplace and needs to reflect the value-add we provide with AFCS to the developer community.
* If you're a developer who's ready to launch a commercial offering in the next couple of months, please email us a brief description of your application, commercial launch timeline, and proposed monetization / pricing model for your application and we will contact you to discuss how we could potentially support your near-term commercialization plans*
Varun
]]>
Just a quick post to announce that we've launched a Showcase Gallery on Adobe Labs to highlight compelling applications powered by AFCS. We're starting off with a small list [... thanks to Nisse Bryngfors, Kaushik Datta, Hog Wild Poker Leagues, and Acecis for working with us and allowing us to showcase their cool apps!] This is just the beginning and our hope is that in the coming weeks we can rapidly expand the Showcase to include other community-developed apps. If you'd like your app to be included in the AFCS Showcase then please submit it here. We're really interested in adding apps that truly take advantage of In-Context Collaboration features provided by AFCS.
Varun
]]> A few words on process - Generally, this build is the result of feedback from the user forums. We take every post very seriously, and spend time considering whether and how we should update the SDK and service. The vast majority of the list below is the result of user feedback. Keep it coming!
What’s new for this release?
• A real, commercial name. Cocomo is now "Adobe Flash Collaboration Services" (AFCS).
• CustomUserField in UserManager is now fully supported.
• RoomManager has been augmented with 4 new settings :
• guestsNotAllowed: Allows OWNERs to disallow anyone not authenticated to their rooms.
• roomLocked: Allows OWNERs to prevent any further entry to a room.
• roomUserLimit: Allows OWNERs to set a user limit on their rooms.
• roomTimeOut: Allows OWNERs to set timeouts on their rooms (after which the room shuts down).
• Fixed ConnectSession.logout so that rooms can be re-logged in properly. ConnectSession.close() was added to completely clean up a session (doesn't allow re-login).
• Fixed: Developer Quotas being exceeded was not reported in the AFCS framework (now throws SessionEvents from ConnectSession, or an RTE if it's not being listened to).
• Management API :
• Server-side: getSessionSecret now returns the current session secret instead of creating a new one.
• Client-side: Added AccountManager.invalidateSession method to invalidate the current session secret
• UserDescriptor.RTMFP added to tell if a user has come in via RTMP.
• Fixed: P2P audio periodically dropping out.
• Fixed: P2P video freezing as it switches to hub and spoke.
• Fixed: Whiteboard not able to set backgroundColor/alpha via MXML.
• Added support for getting/setting nodeConfigurations on every collab and sharedModel component.
• New Examples:
• MultipleSessions - shows how multiple IConnectSessions can be used in one application.
• ZoomLayout – builds a custom webcam layout using WebCamSubscriber.
• PeerToPeerRtmfp - shows how to use P2P/RTMFP for A/V.
• Dev console additions to allow configuration of file and stream groups.
• Dev console additions for managing new RoomManager settings.
• Fixed: XML objects are properly serialized/deserialized went sent via MessageItems.
• Capacity and service performance improvements.
As we get closer to offering the service commercially, we knew it was time to adopt a corporate name. We believe the Platform as a Service we're making should be in the toolbox of any Flash/Flex developer, so we wanted "Flash" in the name. From there, it was a matter of describing what the offering is : Adobe Flash Collaboration Service.
Taking on a "real" name is the first in a series of steps toward commercial availability; there's still lots to be done. We wanted to give a look at the AFCS roadmap for the upcoming months, with a rough chronological order:
I also wanted to thank Nisse for his continued passion and evangelism - he's been helping by writing his experiences in the forum, and is helping me monitor the Twittersphere for people looking for Cocomo love. It's been really great watching community grow up around this project, and we thank all of you for your help!
]]>
Many thanks to Ryan for his time and advice - I think this article is a great complement to the getting started section of the Cocomo Developer Guide, and fits nicely with the content of the first MAX Session posted on Adobe TV. Anyone starting out with Cocomo should check out all 3, then head on down to the forums to get any nagging questions they might have answered.
]]>
Hi, my name is Varun Parmar and I recently joined the Cocomo team as a Product Manager. From the get-go I've been amazed by the opportunities Cocomo enables for developers and my goal is to leverage my blog postings to engage in regular discussions with you on the business aspects of Cocomo.
New and exciting Cocomo-powered applications are springing up daily and as we look at these applications we can't stop but ask ourselves the parochial question - What type of applications will truly benefit from the rich set of features that Cocomo offers? It's hard to wrap our arms around this question primarily because it is a bit early - given that public beta was launched less than two months ago (whew, it feels like eternity with all the activity on the user forums!) - but there are a few key characteristics of these applications:
* Context-sensitive: It is imperative for some type of applications to ensure that the context is always maintained for the users. For example, if I'm a financial securities trader then it is critical that the live market data feed be displayed to me at all times and any other application that I may interact with be in-context to the market data feed. In other words, other applications need to be embedded into the primary application in a way that users perceive other applications as native to the primary application
* Mode of Collaboration: What is the preferred way to enable collaboration for the specific use-case that the application intends to address for users? Is it text-based chat, VoIP, Webcam video, or all of these? Augmenting the primary application with only those collaboration components that best meet the use-case needs provides a superior user experience
* Multi-user / Social: Some applications become inherently more useful when more and more people use them. Such applications benefit from the phenomena called network externalities. Example of such applications include today's popular social networks like Facebook where the social network becomes more valuable to me as more of my friends and family join the social network
We're taking the liberty to coin the term "In-context Collaborative Applications" which in our view defines the category of applications that exhibit the aforementioned characteristics. Interestingly if we look around we realize that most of today's collaboration-centric technologies and applications are out-of-context (E.g., a separate application window opens up for most text-based chat apps and popular softphones.) And herein lies the untapped and colossal business opportunity for you to develop a new well-differentiated application and/or extend your existing application by leveraging Cocomo.
So unlock your creativity and flex your imagination to come up with the next Cocomo-powered "killer app." Are you looking for ideas? Here are some high-level examples of In-Context Collaborative Application categories:
* e-Commerce Support (E.g., Shopping cart assistance, Payment and billing support)
* Interactive Dashboards (E.g., Decision support systems, Reporting systems)
* e-Learning Enablement (E.g., Multi-user whiteboard, Learner polling / quizzes)
* Social Networks (E.g., Presence, Chat - voice, video, text)
* Virtual Worlds / Casual Online Games (E.g., Enable multi-user interactions)
* Specialized Applications (E.g., Telemedicine)
Go ahead and show us the way! ...And let us know how we can further help you succeed!
Varun
ﾠ
Real Time Collaboration Applications With Flex and Cocomo
The intro piece - this will show you what Cocomo is all about, as well as how to get up and running with it. You'll see code!
Cocomo Deep Dive : Building Social RIAs with Flex and Adobe Hosted Services
To me, this is the more interesting preso - shows you a reasonably difficult app, and some tips and techniques to building it.
Source Code for the Deep Dive Apps
Enjoy!
First up, umm.. a Lego Mindstorms Robot which uses a Wiimote and Cocomo to allow users to remote-control the robot across the Internets. Ummm... I have to say this was the least likely thing on my list of Cocomo use-cases, but I'm happy to be shocked!
Watch the video - Essentially, it starts with :
a) WiiMote talks to AIR App 1
b) AIR App 1 talks to Robot.
Then they kick it up to 11, and it's :
a) WiiMote talks to AIR App 2 (somewhere else on the Internet)
b) AIR App 2 talks via Cocomo across the Internet to AIR App 1
c) AIR App 1 talks to Robot
Also cool is that the webcam feed in the Flash Apps is used to allow the remote-controller to see what he's doing with the robot. There's a big "Sound" button there, but I dunno what it does...=)
Secondly, pour tous les francophones in the audience, Erick wrote 3 of the best, most comprehensive Cocomo tutorials I've yet seen online (yeah, it's been a month and a half since beta launch...), including a walkthrough of some of its core APIs, all hosted at Flashxpress. I know, the whole French thing might make it difficult for a few people to read.. Hopefully Erick and his team at La Fabrick feel generous enough to do a little translation for those less enlightened =)
Exciting times!
nigel
First up, I was doing some coding yesterday and wanted to call up the API reference for ConnectSessionContainer, one of the core classes I find myself using with Cocomo.. On a whim, entered "ConnectSessionContainer" in Firefox's search bar, et voila:
Yeah, ok, I might be one of the only people who finds this exciting, but others should at least find it useful.
More relevant for all those of you who've had account registration issues, do us a favor and try again today - we think we've found the issue, and have pushed the fix to production.
]]>