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:05:07 UTC