Sorry I though the quote you  was a strawman, I didn't realise it was just 
paraphrasing other people. 

I would depute you point about the client, but I agree it was one of the 
main nails in the coffin. People failed to relate to the concept 
fundamentally, for the reasons I stated. 


I also disagree with those that say that Google didn't promote, or do 
enough advertising. If Google is guilty of anything it is not advising 
team, and figuring out how best to launch in a more a targeted way. More 
advertising wouldn't have done it, because the PR they did get was a 
lot bigger than many independent ventures could even hope for, and it 
didn't translate to usage. People may have liked the sound of it, but 
didn't immediately think how they were going to use it. 


Asking Google Wave users is not the complete picture, becuase all you find out 
is what they wanted to use it for (if anything other then curiosity), 
not why other people didn't use it. There wasn't a huge amount of 
interest anyway. 

Ok you can't know 
everything for sure, but there are commonalities with every venture and 
using existing paradigms on real users, is a tried and tested of 
approach of upgrading experience gently without blinding them with 
science. 


There is a world of difference between concept makers, with hypothetical users, 
and and existing user base, and use cases. 


Actually 'Wave' should be almost irrelevant to the end user. 




________________________________
From: Thomas Wrobel <darkfl...@gmail.com>
To: wave-dev@incubator.apache.org; Paul Thomas <dt01pqt...@yahoo.com>
Sent: Thursday, 27 October 2011, 16:55
Subject: Re: Walkaround -- Wave on App Engine

", it was nothing to do with advertising or just about the client."

My point was thats its relative success did have to do with that. I
wasn't representing your point at all, I was making my own.

I'm not even sure there has been any published surveys of user
experience problems with googles wave client, I think everyone is just
guessing.
In either case, its all irrelevant now.

What isnt though is that in order to get multiple clients targeting
different use-case's (which I think should be a priority), you need
both federation and a good client/server protocol. Walkaround, nor
Apache Wave, really have this yet.
And,yes, AC is needed for maximum flexibility.

-Thomas

~~~~~~
Reviews of anything, by anyone;
www.rateoholic.co.uk
Please try out my new site and give feedback :)



On 27 October 2011 17:23, Paul Thomas <dt01pqt...@yahoo.com> wrote:
> You completely misrepresented what I said, it was nothing to do with 
> advertising or just about the client. It is also not just about criticism. To 
> a user the interface *is* the program, they won't criticise what they aren't 
> aware of. They may criticise it how they can understand, but the fact it it 
> was the apathy, and lack of interest that was more telling than the 
> criticism. This is part presentation and part functionality.
>
> Exactly, the protocol should do either, any general out of the box solution 
> should pick the expected behaviour, or at least make it simple to to 
> configure.
> AC has been on the back burner becuase it was assumed that it was least 
> concern, but the fact is the flexible AC is what is goign to make it useful, 
> and lack of flexible AC makes it less viable. The complexities of the AC 
> could be problem, that is why I suggested at the very least starting with the 
> common ways people are used to communicating.
>
> So much of AC is specific to use case. Not having this limits your audience 
> considerably.
>
>
>
> ________________________________
> From: Thomas Wrobel <darkfl...@gmail.com>
> To: wave-dev@incubator.apache.org; Paul Thomas <dt01pqt...@yahoo.com>
> Sent: Thursday, 27 October 2011, 15:32
> Subject: Re: Walkaround -- Wave on App Engine
>
> * Wave wasn't promoted or advertised and most peoples experience off
> if consisted of one client while it was buggy. Almost all criticism is
> off the client, in fact.
>
> These conversations are old hat.
>
> I needed a federated, open, realtime updating system that allows
> selective posting of information to different groups and allowing
> different people to update the same post*. I still need that.
> WFP is still the only thing that does that, and while a few other OT
> based systems have emerged, nothing gives that functionality.
> My use-case is on hold till that happens.
>
> -Thomas
>
> *(it really doesnt matter a defaults to editable or not - that should
> be upto the client softwares interface. As long as the protocol
> allowed both).
>
>
> ~~~~~~
> Reviews of anything, by anyone;
> www.rateoholic.co.uk
> Please try out my new site and give feedback :)
>
>
>
> On 27 October 2011 16:07, Paul Thomas <dt01pqt...@yahoo.com> wrote:
>> This sounds more up my street, I wasn't a huge fan of the Wave Model as is, 
>> I always saw the potential being beyond that.
>>
>>
>> There is a saying "not all good ideas are useful", that is to say the 
>> potential to be useful is not always met out in the wild. This is what 
>> happened with Google Wave.
>>
>>
>> Good friend of mine hit the nail on the head, when I was discussing the use 
>> of wave based technology in NGOs and Charities, which she a lot of 
>> experience in:
>>
>> "This is more of project by programmers for programmers"
>> "It suits those who know each other and  are already used to collaborating 
>> in this way, which is rarer than you think"
>> "When I invest time on something the last thing I want is people editing 
>> willy nilly".
>>
>> Yes it is really easy to think of countless think tank type scenarios where 
>> wave will be useful, but the proof in in the pudding. You and I may like the 
>> idea (and I really do trust me), but that doesn't mean it will work. It is 
>> not just about technology, and making it possible.
>>
>> Don't get me wrong I think it is still salvageable and the overall concept 
>> of federation and OT will have many unexpected uses. But a the same time, 
>> there needs to be some thought to towards use cases. Is very easy to fall 
>> into the trap  of thinking becuase it can be used for 'everything' there for 
>> it is useful for everything.
>>
>> That is why I think there should be a serious re-consideration of Access 
>> Control. One of the most important consideration in interface is the 
>> expected behaviour. I believe the default behaviour for blip is neither 
>> expected nor wanted en-masse. I think all participants editing blips should 
>> be still possible, but that isn't what is wanted most of the time. People 
>> need their space, even during collaboration.
>>
>>
>> You have to realise the Wikis and similar are a special cases. It is not 
>> something where you would loose you job over it, and if it was then you 
>> would be damn sure about how you use it. There is a difference between 
>> collaboration in everyday task, and this level of collaboration. There is 
>> some politics involved like it or not.
>>
>>
>> You can only speculate as to the fate of Google Wave. However certain thing 
>> are definitely true:
>>        * It wasn't targeted at anyone in particular, few associations were 
>> made
>>        * it wasn't distributed, a per use case, it was go to and try. 
>> Federation didn't happen when it mattered.
>>
>>        * Existing paradigms were not used to help people transition instead 
>> there was obscure cultural references. Email doesn't count becuase that 
>> analogy wasn't strictly accurate, it was confusing, and it wouldn't help 
>> anyway.
>>
>>        * It failed to take in to consideration that becuase there weren't 
>> many expected behaviours, people would struggle to make heads or tails of 
>> it.Apache Wave is a Techocracy, but I think they need more interface, and 
>> architecture consideration. When I mean interface I mean the entire needs of 
>> the users, not views.
>>
>> I think more flexible technology, like Walkaround based projects sound like, 
>> may overtake Apache Wave as is. The again I do like the out of the box, 
>> initiative. It is getting beyond that sort of proof of concept..
>>
>>
>>
>> ________________________________
>> From: Alex North <a...@alexn.id.au>
>> To: wave-dev@incubator.apache.org
>> Sent: Thursday, 27 October 2011, 13:14
>> Subject: Re: Walkaround -- Wave on App Engine
>>
>> Thanks so much guys. I'm glad you finally got it out there, and a little
>> regretful that I didn't do more to help you.
>>
>> 'grats on the launch.
>>
>> Alex
>>
>> On Thu, Oct 27, 2011 at 6:55 AM, Christian Ohler <oh...@google.com> wrote:
>>
>>> Fellow wavers,
>>>
>>> rather than making waves accessible in Google Docs, which takes too
>>> long, we are releasing our code in a form that will hopefully be
>>> useful in the short term.  You can find it at
>>> https://code.google.com/p/walkaround/ .
>>>
>>> >From the project description:
>>> Walkaround is a variant of Wave, based on the Apache Wave code base,
>>> that runs on App Engine.  Walkaround can import waves from
>>> wave.google.com to allow users to keep working with their data
>>> regardless of the future of wave.google.com.  (The import feature is
>>> still experimental.)
>>>
>>> Much of the walkaround code is not specific to Wave, but factored out
>>> as a separate, more general collaboration layer that manages shared
>>> live objects.  These objects can be modified by multiple clients at
>>> the same time, with changes made by any client immediately broadcast
>>> to all others.  The Wave application is built on top of this, but the
>>> live collaboration layer is flexible enough to support other
>>> applications.
>>>
>>> Walkaround supports live concurrent rich-text editing, in-line
>>> replies, user avatars, wave gadgets, attachments, and we are working
>>> on integrating App Engine's full text search service.  For now, it
>>> does not support Wave robots, federation, or private replies, but
>>> these features could be added.
>>> ---
>>>
>>> Some of you have been asking about Wave on App Engine; perhaps this is
>>> what you are looking for.
>>>
>>> The Wave application in walkaround depends very heavily on the Apache
>>> Wave code base, but the general collaboration layer is useful
>>> independently, so we put it into a separate repository for now.
>>>
>>> Happy hacking,
>>> Christian.
>>>

Reply via email to