BOX_b - rented back . . .
BOX_1i - rented back . . .
BOX_1h - rented back . . .
BOX_1g - rented back . . .
BOX_1l - rented back . . .
BOX_1k - rented back . . .
BOX_1j - rented back . . .
BOX_1o - rented back . . .
BOX_1n - rented back . . .
BOX_1m - rented back . . .
BOX_1p - rented back . . .
BOX_1r - rented back . . .
BOX_1q - rented back . . .
BOX_1u - rented back . . .
BOX_1s - rented back . . .
BOX_21 - rented back . . .
BOX_1v - rented back . . .
BOX_22 - rented back . . .
BOX_26 - rented back . . .
We started with
Colayer one decade ago, in 99, on a journey, which had the same basic concepts as wave: to redefine web communication - and as we were at the peak of the Internet bubble when we started, we choose the provocative slogan
"eMail will be dead soon"!
I suffered myself the mess of email communication as a traveling business consultant: I was convinced, that this can not be the way we will communicate in future! This is fundamentally wrong! - I mean: the basic idea of SENDING information on the web is wrong! -
The web is a virtual space, where WE travel, not the information (see slides 8 and following - You GO TO and ARE ON facebook, twitter, yahoo - you don't 'download' it ...).
And information is organized along CONTEXT - And I was convinced, that this paradigm shift in online communication was about to happen.
: BUT who has the time for travelling to all that virtual places? Here email might have some advantage still. Email clients are good aggregators of information widely used in offices. SO if i have to travel to many places in order to get my information, time gets lost as well.
the aggregation is done by the TIMES page ...
BOX_2a - rented back . . .
BOX_29 - rented back . . .
See link for an example, how the times page works - the advantage is, that on the times page, all information is in context - hence much easyer to read than in email ...
BOX_2b - rented back . . .
BOX_2d - rented back . . .
Born in the .com bubble, we were way too optimistic about the time frame - and soon had to realize, that it would take longer for this paradigm shift to take place. Over the years, we always found people seeing our visions and excited working with our technology. We grew to 60 employee, but never got a broader adaption.
When Wave was announced in may 2009, a friend called me up with shaking voice: "Markus, Google has implemented Colayer!!" - the next 3 days I got more than 20 similar calls and messages from alumnis and partners.
When I looked at Wave, it struck me too, how similar the concepts were, and even the implementation had many close similarities. We were excited to see a product from a big player going in the same direction - excited to see, what approach google took to implement the new paradigm - But I also realized quickly, that this product in this stage would not be usable for 3 main reasons:
1) The Technical Architecture was too heavy and complex -
2) The Operability
3) The Notification
We struggled with pretty much the same issues in the beginning and came up with our own solutions: We had a very similar architecture in 2003, but dropped that approach as we saw, it wouldn't work for complexity reasons. The operability, we solved through our shuttle, a floating conversation toolbox. And the notification through our times (I may write more in a separate post later ...)
Speaking of shuttle ..
BOX_2f - rented back . . .
BOX_2g - rented back . . .
.. where is the WYSIWYG shuttle?
Mhe: right here ... doesnt work for you?
: it worked for me when I click here,| but I remembered the first shuttle which you and me started building. I like the new face of shuttle
: ---Anil Patil
BOX_2h - rented back . . .
BOX_2k - rented back . . .
BOX_2j - rented back . . .
I had the exact same response .. "this is too darn close to the layer". I always was a fan (still am) of the concept of Colayer. It was a fun year or so working with Markus.
- Himanshu
BOX_2l - rented back . . .
BOX_2n - rented back . . .
BOX_2m - rented back . . .
SELF_2i - rented back . . .
BOX_2q - rented back . . .
BOX_2p - rented back . . .
BOX_2o - rented back . . .
BOX_2r - rented back . . .
BOX_2t - rented back . . .
BOX_2s - rented back . . .
BOX_30 - rented back . . .
BOX_2v - rented back . . .
But Wave was at its very start, and we all at Colayer were very eager to see, which solutions Google would come up with! - And we believed that with their market power, Google would be able to initiate the paradigm shift in online communication and create a market - and of course hoped, Colayer would get more attention too in this process -
We were looking for a healthy competition with Wave in the following weeks & months. We observed Wave and the user feedback carefully to get feedback for our product too & our future development. And of course to get clues about how Wave would address the above 3 key problems.
BOX_32 - rented back . . .
BOX_34 - rented back . . .
BOX_33 - rented back . . .
Hi, In my humble opinion, the greatest strength of Wave is the open-source federation protocol it uses for servers' communications.
Just like anyone can create an E-mail server using SMTP and POP protocols, anyone can create a Wave serer that will be able to inter-operate (to federate) with other Wave server.
In a perfect world, I imagine myself using an Apache public Wave service, while being able to communicate with Friends that have preferred to create an account on a ProcessOne Wave service, or a Colayer Wave service... ;-)
Like e-mail users can send/receive e-mail regardless of the e-mail provider of their contacts, I think the new communication paradigm also needs to be "federated" to be widely adopted.
Have you considered using the Wave Protocol (basically it's based on XMPP communication protocol) for the Colayer servers' communications?
Yes, we planned for a Colayer / Federation protocol integration, in case it would have been successful ...
BOX_36 - rented back . . .
BOX_35 - rented back . . .
Personally, I doubted from the beginning, that the Federation protocol would succeed - I liked the idea behind, it is a great piece of technology - but my question was: Why would we need a new protocol, if we can do the same with HTTP streaming? -
I know - technically, there are a couple of arguments, why the federation protocol would be a better choice - but I guess more important is the argument, that so many people KNOW already HTTP, its very simple to understand, and it has thousands of tools to support it -
Still, we thought google, with all its marketing power may be able to succeed in setting a new standard protocol - hence, we were planning for an integration, but never carried it out -
By the way: may I know who you are? - are you on Twitter? FB?
: My name is Jeremy, I co-founded a Wave user community. You'll find a profile of mine linked from the comments of your Quora topic here : http://www.quora.com/How-is-Colayer-different-from-Google-Wave/
BOX_38 - rented back . . .
BOX_3a - rented back . . .
BOX_39 - rented back . . .
There was a time when even I thought, having Wave protocol compatibility would be a great choice.. but for Colayer HTTP is a great advantage. Most web developers are already familiar with the protocol and use it for OAuth services like Twitter etc.. It makes things simpler.. Running behind engineering and documentation of a whole new protocol and getting developers to work on it could slow down the popularity of a service
BOX_3c - rented back . . .
BOX_3b - rented back . . .
BOX_3d - rented back . . .
BOX_3e - rented back . . .
BOX_7 - rented back . . .
I see your point, but XMPP is not an obscure thing to developers either. It's a modern , full of features and Open Standard that's becoming more popular year after year. It's already deployed widely across the Internet and was used by over ten million people worldwide by 2003 (can't find a more recent stat, but it has surely been growing).
SELF_3u - rented back . . .
SELF_3a - rented back . . .
BOX_3f - rented back . . .
BOX_3h - rented back . . .
BOX_3g - rented back . . .
Reto Hartinger from Internet Briefing wrote
about Colayer and Google Wave, and did an
interview with me. We decided however, not to write too much about the 3 above points yet. We intended to stay in 'stealth mode' for some time, until the direction of Wave was more clear.
But after the Wave launch, it seemed that innovation stopped. Yes, there was development, improvements & many extensions. But the above 3 problems were not addressed. They couldn't be solved through improvements or extensions, but needed fundamental shifts in the product design - which never happened. And as many users seemed to loose patience too, Google pulled the plug for poor user adoption.
What went wrong? -
Gartner has a valid point: "Startup innovation" has simply no place in a large enterprise software company. Well, this is not exactly what Gartner writes, but this is essentially the meaning: Either you are in the business of breaking & paradigm shifting innovation (Startups), or you are serving a large base of enterprise customers - Both together is almost impossible, because there is no breaking innovation, without messing up with your customers. After Wave launched, the team could not just say to its 100'000 users: "you know, we just realized that the architecture has a fundamental problem - lets start it again ...!" - which we, in a small company did several times ...
BOX_3j - rented back . . .
BOX_3l - rented back . . .
BOX_3k - rented back . . .
Maybe the biggest mistake we did with building Colayer was, that we choose the wrong market. Partly, that may also be true for Google Wave. We thought, large enterprises would be the best place for the paradigm shift to start:
1) Email communication is especially painful, if used for many-to-many, and
2) adopting the new communication paradigm would generate most value in a large, professional organizations
Hence, we built Colayer as a business application for large enterprises - and never even had a public version!
BOX_3m - rented back . . .
BOX_3o - rented back . . .
BOX_3n - rented back . . .
BOX_bl - rented back . . .
BOX_82 - rented back . . .
But the paradigm shift happens elsewhere first: If you observe today's kids and young nerds, you can imagine, how the next generation of businesses will use online communication: Email for them is 'lame' and just used for communication with outsiders, older people and the 'conservative' business world. Why would you need email anyway in a world of Facebook & Foursquare?
After 10 years, we are still in the beginning of the massive paradigm shift of online communication. I am eager to see, who will try it next, and who will finally succeed!
BOX_3p - rented back . . .
BOX_3q - rented back . . .
BOX_5r - rented back . . .
BOX_6 - rented back . . .
BOX_3r - rented back . . .
BOX_3t - rented back . . .
BOX_3s - rented back . . .
BOX_3 - rented back . . .
BOX_bd - rented back . . .
BOX_40 - rented back . . .
BOX_3v - rented back . . .
BOX_3u - rented back . . .
BOX_b0 - rented back . . .
BOX_av - rented back . . .