Re: Use cases updated w/ glossary and roles

Though I didn't click into a versy busy NASCAR Problem discussion
thread a little over a month ago, I presume someone must have
commented that its a very common approach on complicated work/play
sites that key fields default to something for those who don't
understand or prefer not to deal with complex considerations. And yet
these defaults can be changed by the user though a Preferences page or
via some other simple procedure.

This is also what I have in mind for core payment attributes, such as
the value-in-exchange benchmark: let the user who leads the
transaction arrangements default to the usual W.M. Reuters Sport Rate,
since that's what most of the world relies on already, but let the
payee choose another, or more than one (as illustrated in the PayPal
screenshots). If it's more than one, the PayPal process still defaults
to one, but offers users "Other Conversion Options" which lets the
payer chose which they want.

Screenshots: http://www.w3.org/2013/10/payments/slides/session4_potvin.pdf

-- 
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

On Fri, Aug 1, 2014 at 10:04 AM, Adrian Hope-Bailie
<adrian@hopebailie.com> wrote:
> I would agree with that.
> To my mind the user needs to get as much choice as possible but the spec
> should allow for implementations to improve the user experience by
> remembering choices (within parameters and with an expiry).
>
> I think this needs to be the approach in general for most use cases.
> Consider the use case when a payer chooses to make a payment and authorise
> future payment requests to the same payee up to a set limit (Recurring pull
> payments).
>
>
> On 31 July 2014 17:38, Stuart Langridge <sil@kryogenix.org> wrote:
>>
>> On 31 July 2014 16:29, Tim Holborn <timothy.holborn@gmail.com> wrote:
>>>
>>> On 1 Aug 2014, at 1:27 am, Stuart Langridge <sil@kryogenix.org> wrote:
>>> > could someone summarise what the NASCAR problem is?
>>>
>>> http://indiewebcamp.com/NASCAR_problem
>>
>>
>> Thank you, Tim! That's what I thought it might mean. I therefore think
>> that the term is being overapplied in criticism of the use cases.
>> Specifically, when people complain about the NASCAR problem I think that
>> they mean that they get repeatedly presented with a million little icons all
>> the time and they're almost all irrelevant almost all the time. However, the
>> use case document seems to flag any solution as having a NASCAR problem if
>> you are ever presented with a list of choices, even once. Michael Williams
>> identifies that this is avoided by remembering the choice made, which seems
>> sensible, but it seems to me that if the web payments initiative is
>> specifically designed to allow me to choose between many ways to pay, then
>> actually giving me that choice is rather inherent to the process, isn't it?
>>
>> sil
>
>

Received on Friday, 1 August 2014 14:33:10 UTC