Not exactly sure how we ended up on Yahoo! Gallery, but pretty cool. Anyway, kudos to Yahoo! for providing the AS3 components, and oh – to Nigel for whipping up an ”Editors’ Pick” worthy application over a weekend in his spare time.
]]>Check out the updated API documentation and try it out!
Not exactly sure how we ended up on Yahoo! Gallery, but pretty cool. Anyway, kudos to Yahoo! for providing the AS3 components, and oh – to Nigel for whipping up an ”Editors’ Pick” worthy application over a weekend in his spare time.
]]>
Unfortunately, I had to clear all the old markers in the room :(. So get back in there, especially if you couldn't get in last time, and make your mark on the world!
There are a couple of issues left to fix, and a thousand ideas on how I could make this cooler, but my demo-coding-time runneth short right now. Also, note I'm only allowed 50000 tile-hits a day, so if tons of people show, it might die an unseemly death.
Let me know what you think :) I've got some more demos in the oven, stay tuned!
]]>We’re back from the holidays and ready to kick things back into high gear. As some of you know, the Cocomo private beta kicked off late last year and we’re off to a great start with good early activity and feedback from participants.
Hats off to the brave souls who’ve already dived in and exposed our oversights!
If you’ve applied, but have not yet received access -- don’t fret! We are opening the beta in phases -- mainly to make sure we can properly support participants and work out the kinks (see above reference) -- and will be letting in more folks in the comings weeks, and throughout the beta.
Lastly, I thought the survey results from the beta application were interesting and thought I’d share the below with you all so you can see the mix of fellow beta participants. Collaborative applications takes the cake, but that’s not a surprise… ;-)
~~~~~~~~~~~~~~~~
Update 10:17am PST -- The major storms here in NorCal have knocked out the power at the office. I've been sitting in the dark for the last hour and keeping it rolling... well, at least until my laptop runs out of juice.
We did take time to read through the reviews out there, of course. We've always kept our eye on Robin Good's input, as he's got as much experience analyzing and reviewing Collaborative apps as anyone out there. Check out his very detailed review :
One thing that caught my eye (besides "There is no other competitor in this marketplace that offers this much for this little", or "Brio is a breakthrough web conferencing solution") is his call-out of the whiteboard functionality. I'd love to hear more of his thoughts on this, and would suggest he apply for a Cocomo private beta account - the whiteboard is built for extensibility, so that any Flex developer should be able to make new tools for it. I would love for someone motivated to add tools to join up :)
Second item for today : Peldi took some time to go through the BRIO source code and come up with a few statistics. The 2 things he was interested in :
1) How much of BRIO are we shipping as part of the reusable Cocomo Flex SDK?
2) How much of BRIO was built on the server, and how much on the client?
Check out this pair of graphs for the results :
I have to admit, I was pleasantly surprised by just how far we've come. Consider that the server code in question will be the same services provided for every Cocomo app, and you get a sense of what we're trying to do here - Apps on the client (built on our Cocomo Flex SDK), Services on the server.
]]> 1) Be robust enough to handle all of the needs of a complex app like Breeze/Connect.
2) Be designed in such a way that an ENTIRE MEETING application could be written COMPLETELY on the client, using a generic set of "real-time collaboration" services on the backend.
Well, we're proud to announce that the goals have been met - the results are Cocomo (our client-server framework for real-time collaboration, which, go listen to me ramble here, if you want more details), and what we're unveiling today - codenamed BRIO.
(click to see this a little bigger)
BRIO is the beta codename next generation of Connect/Breeze. It's also FREE, for up to 3 people in a room at once.
The great thing from my perspective is that we've really taken the time to validate the framework here, and really executed on the concept - our Cocomo server framework is now deployed and public-facing, and will (soon, soon!) provide the same backend services for applications that any Flex developer can use in their own applications. You did know that there's a private beta for the Cocomo Flex components about to start, didn't you?
]]>As we continue to march toward our milestones, we want your feedback and help in making sure that we provide the best kick-ass web services platform for real-time collaboration and social media.
The Cocomo team is taking private beta applications starting today -- APPLY NOW!
I think I've got everything on the server (it's a very, very mini version of the service we're going to be hosting for everyone) sorted out now - I had a bunch of comments left in the previous post telling me there was nothing but gray for the app.
Others, like William Overington in England, took some cool snapshots - I liked the chaos here :
For all you debug-player enabled folks out there, if you spot RTEs, please copy paste them into the comments. You help is much appreciated.
Now, Go Draw!
]]>
Yeah, it's crazy-buggy, and it's not the prettiest it could be, but I didn't have time to make a decent stylesheet. Also of note is the fact that everyone on this alpha box is Swedish. No, I don't know why either, ask Peldi. Sorry about the screwed up blog formatting - hit permalink to see the full thing properly.
... In case you were curious, here's a snapshot of THE CODE FOR THE ENTIRE APP ....
- Drag and Drop upload multiple files to Share
- Public share any of your Share Files.
- Send Share file links directly to Pownce or Twitter. (With message)
- Create a tinyurl for a Share public link.
- Quickly get embed code for a shared file.
- Share links and direct file links.
Handout definitely takes advantage of the AIR APIs to provide an experience that can't be created solely by the browser. Queuing up multiple files for upload is very convenient. Just fire and forget... but don't worry because you'll be notified when all your files are complete through a neat desktop popup.
What is really cool is the way Handout mashes up Share with Pownce and Twitter. It adds a real-time, social networking aspect that currently does not exist in the official Share web application. This is what it's all about: bringing together different services to create something new, useful, even unexpected. This is where the innovation happens, when data and functionality can be accessed outside of the browser and outside of each individual web application. It's still early, but we're entering a new world of possibilities with web services.
So give Handout a try. And for you developers out there, let us know about the awesome new apps you come up with!
]]>Christoph has made the component and source available -- check it out on his blog:
]]>Wet And Miserable Cocomo Presentation
(BTW, am I the only one who gets shivers when they see the old Breeze logo? Yeah, I'm prolly feverish).
]]>First the long awaited AS3 library (Flex 3 Beta 2 required, which is currently available on Adobe Labs)... sorry it took us so long, but here it is in all its glory. The ZIP also includes the AIR project file which we demoed at our MAX sessions. Feel free to use, modify and fix any mistakes we may have made.
Furthermore, Hidyuki Kato has started a Ruby library for Share's REST APIs. Really cool stuff, and exciting to see the community embrace our services!
]]>..Which is a fine segue to what I really wanted to talk about here. Stefan is posing a very important question. It's great for us to get on stage and show a fancy demo of a disruptive technology, but I fully respect that what we're talking about here could affect the way people earn their livings. It's a serious topic. And this is one of the driving reasons I'm blogging rather than fixing bugs right now (which I should be doing, or Cocomo won't be disrupting anything any time soon).
So, why? What are we trying to do here? I'll put it in my words here (not Adobe's), and take a stab :
a) We're demonstrating Adobe's commitment to Hosted Services.
There's a lot of competition in this space right now, and it will benefit our developers to have Adobe focus on finding the right places to fit. Now. Connect is already a natural fit, and extending what we can offer with it is a natural progression.
b) We want to lower the barrier to entry in pushing Flash/Flex as an enabler in Real-Time Collaboration and Multi-User applications.
I think everyone can appreciate the capabilities we know are in this platform; but complexity and issues of the economy of scale make it really hard for your average developer to use them. I'd like more feedback on this front, but my sense is that it's just difficult and expensive to set yourself up as a Flash RTC specialist. This is great if you can get there yourself, as you get a captive audience; but making it more widely attainable seems like a way to prove the platform in more minds, and help fuel a market I think is waiting to take off. Which should lead to more work for more people.
c) On a more personal level, I've been working (as Stefan points out) in RTC/FMS apps and components for a bunch of years, and frankly, it's time there was a really concrete AS3 framework and methodology for writing these.
The fact that none have emerged, to my mind, speaks largely to point b). And I'm sick of writing the same base functionality over and over again. As someone who's had a very large amount of experience in both Flash Component frameworks and RTC, I feel like the timing and the stars are aligning on this front. Peldi and I (and a team of talented folks who can't be bothered with blogs) wrote this, and we're opening it early for people like Stefan and Brian Lesser to rip apart; it has a fair chance of being good. I've got some posts on the features of Cocomo, the client framework, queued up, so I'll have more on this subject in the next week.
Misconceptions and Ambiguities
I also wanted to take some time to address things I saw over on Stefan's page that seemed incorrect, or at least that I couldn't fully understand. I really regret that I was forced to leave my MAX session as the Q&A started (because another team had an emergency with one of my servers), so I didn't get a chance to chat with Jim Phelan. I wish I had, because I'm not sure if I understood some of his concerns. I hope he comes back here to read this, and I get a chance to hear them.
1) Cocomo is built on top of Adobe Connect (formerly Breeze).
This is upside down. The next version of Adobe Connect is built on top of Cocomo. You won't need to be a Connect user to use Cocomo. Your users certainly won't need to either. We want developers to come in and build apps that are full siblings to Connect. Or little mini-apps that you put inside your existing apps or sites. Yes, we'll have to figure out a way to recoup our investment and make some money from those applications eventually, but we're aiming here for a model that makes that money proportional to your app's success. If you're not using a ton of our backend resources, you're not going to be paying much, or potentially anything at all. It's also early enough that we're still looking for your feedback in how this can be a winning proposition for you as well. If it doesn't help developers, no one will use it, and how are we going to benefit?
2) Adobe will discourage you from buying and using FMS and wants you to use Cocomo.
Now, I'm not a financial wizard, but.. That doesn't seem like it's in our best interests. Cocomo is definitely great tech, but not everything will be possible. If you need a deep back-end integration with FMS, a Hosted Service isn't a good fit (yet). But I'm looking at a banner ad RIGHT NOW on Stefan's page that reads "Can't Afford FMS?". It seems like there may be a market out there
for what Cocomo does.
3) Cocomo is a "bunch of components" for "pseudo develop[ing]" your own flavo(u)r of Connect.
I think this underplays the value a fair bit. We will be offering bunches of components, but as a framework, I'd like to think it's much more robust than just that. The fact we were able to build Connect with *no* special server code (just the same framework and services we're offering you) suggests to me that you'll be able to build quite a lot of different apps with it. Hopefully, you'll be able to tell us soon. I'm still trying to figure out what "pseudo develop" means, as it might make me a "pseudo developer" :-).
4) Pacifica taking web conferencing, Cocomo collaborative apps, etc. Resources shifting away from FMS, couldn't FMS fulfill all this?
I'm going with disagreement on all these fronts. I'll write another post soon about FMS' role in Cocomo, and some of the stuff I think FMS doesn't fulfill, but that comes later.
5) We're trying to compete with developers. We're trying to outsource Connect Professional Services.
Emphatically, No. If anything, and I'm a developer who truly believes this, we're trying to give a more equal playing field to developers who feel Connect/Breeze was eating their lunch. We are doing it in a new way, with Hosted Services (see point a) above), so that might mean some change in methodology for some, but change can be ok sometimes. You tell us. I'm still not sure I understand the Prof. Services argument Jim makes. I hope I've somehow answered the concern, and/or he comes here to clarify.
Anyhow, If you've made it this far, thanks for sticking with it. For some reason, I can't turn off comment moderation, but rest assured I'll let anyone with an opinion speak here. Please do.
]]>