Re: [SPAM] Re: Joins on capabilities that have passed through different membranes

Presumably Google have more data than Microsoft on the usability of their 
prototypes (how widely used is Office 365 now? does it work this way?). 
Maybe that's the reason they stopped there and failed to see the 
alternatives that do work?

Of course I don't mean to say that measurement in UI research isn't useful 
-- just that it is easy to be overconfident of what is being measured, and 
to put too little emphasis on guesses about how people think.  It sounds 
like they made a good guess, but didn't follow through with that, perhaps 
because a traditional response to this sort of test is to throw away the 
experiment and move on to the next feature.  I suspect the bigger the 
dataset, the more tempting this is ("how could we be wrong?  we measured 
ten million users").


John

On Fri, 15 Jan 2016, Sandro Magi wrote:

> I'm skeptical of this UI claim. This behaviour is exactly what happens when 
> people open Word attachments directly from some e-mail clients. An additional 
> strip at the top says you're in read-only mode, and provides a button to 
> begin editing. This pattern has clearly existed for many years already, and 
> persists to this day, so it can't be so confusing as to be unusable.
>
> Sandro
>
> On 05/01/2016 2:46 PM, Mike Stay wrote:
>> On Tue, Jan 5, 2016 at 11:14 AM, Alan Karp <[email protected]> wrote:
>>> Marc Stiegler came up with a clever UI affordance to make all this clear.
>>> If Ihab views the document with Kenton's capability, Ihab sees a ro view.
>>> If Ihab opens it with his own, he sees a rw view.  In either case, he see
>>> the same document, which reduces any possible confusion.  Since Ihab does
>>> have write permission, his UI has an Edit button (actually a tab in
>>> Stiegler's UI).
>> Google's UI researchers claimed to us that people would get a
>> read-only view from somewhere and then be confused when they couldn't
>> edit it, even when there was an edit button.  People don't look for
>> controls they don't expect to need.
>
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>