Re: [Snowdrift-design] Discuss project page and dashboard

[Aaron Wolf]

On 05/19/2016 08:12 PM, Stephen Michel wrote:

> This email thread is about a design for the project and dashboard pages.
> Whether the limit is set on the dashboard page or the project page when
> pledging (or both) *is* an MVP decision. So is whether to include a
> wallet in addition to a monthly budget.
> 

When the limit is *first* set, it will be system-wide per-patron. That
is a done decision for initial launch, not something to discuss further.

Any per-project budget is only something to discuss only later if ever,
after we get real-world operating data with the system-wide approach.

Whether the UX has the user set it when making their first pledge or
separately is a UX design decision that isn't final.

Yes, the decision on effectively a "wallet" is also open (even if we
charge in arrears still, it would be one-time authorizing of a total
amount versus a monthly authorization).

>> 1. Patrons set an absolute limit, where we won't ever charge them
>> more than that, total. - I anticipate everyone agrees that this is
>> a bad option for us (or any ongoing system). If it turns out I'm
>> wrong, I'll elaborate then. 
>>
>> No, nobody thinks this is fundamentally wrong. This is just the
>> "wallet" approach, even if we actually charge in arrears. There's
>> NOTHING wrong with absolute limit. People *obviously* can *change*
>> their absolute limit by adding/authorizing more funds. This is the
>> approach where some people feel the most control. It's fine.
> 
> It may be the same technically, but I am thinking about this from a User
> Experience perspective -- which is the perspective that matters in this
> context. I need more information about the UX of arrears to make
> conclusions.
> 
> I'm a user. I go to snowdrift.coop, log in, go somewhere (I'd assume
> dashboard, but I'm trying not to assume), and click on a button to add
> funds to my account (current balance: $0). I specify $50 and click
> 'next'. Now what happens? I presume I'm prompted to log in to Stripe. Am
> I also prompted to authorize $50 for snowdrift, or does that come later,
> or for individual transactions, or...?
> 

If we charge in arrears (which is more of a legal decision than anything
else), then you will still never authorize each and every transaction.
That's not a possibility.

You would authorize either:

(for option 1) a $50 total and be told that we will make the first
charge when your total pledges hit $5 or more (or similar amount that
makes doing a charge worthwhile), and that we will only charge a total
of $50 over time unless you later authorize more

or (option 2) a $10 monthly max (which could roll-over so that it counts
as a $120 annual max but some months could go over $10, or we don't do
that sort of thing, just an idea) in which case you would be told that
we will charge only when your total pledge balance over time reaches $5
total, and that we will only charge a maximum of $10 per month.

For *both* cases, we could consider simply having your payment
credentials on file (however that works with the processor), and keep
the budget (one-time or monthly) only internally, and simply use it to
consider whether pledges are active or not and thus keep charges to your
limit. There's nothing about this particular question that requires us
to have the processor pre-authorize a credit-card charge. Whether or not
we do that is independent.

In other words: Stripe doesn't have to hold the info of "I authorized
$50". We just can hold it ourselves and make sure we never tell Stripe
to charge you more than $50 total.



> - #1 requires me to manually authorize funds, #2 does so automatically.

No, there's no auto-authorizing, there's just auto-renewing of
authorization. But I know what you mean.

> - #1 does not allow me to change my mind after I've deposited funds;

I don't know if changing your authorization later (as long as it still
covers all obligations you've already had) is out of the question,
although it certainly sounds like non-MVP.

> with #2 I can modify my limit at any time up until the monthly payout.
> - #1 as discussed a while ago requires me to maintain a 3 month minimum
> balance; #2 does not.

Yes, I agree about the 3-month balance being different, but you've
mistaken the details. We never proposed a 3-month balance being
*maintained*, we only proposed that a 3-month balance at current levels
be available to *place* a pledge initially.

> 
> That third point is the biggest difference. If a project gains huge
> popularity overnight and eats up all 3 months' funds in a single month,
> I'll feel betrayed by the system. With #2 this is not possible.
> Therefore #2 is the more effective safeguard.
> 

The "project gains huge popularity overnight" is a speculative thing
we'll be studying and not pre-optimizing for although we want to
consider it in our discussions. This is stuff the limits page describes.
We should certainly have notifications of huge pledge value changes.
There's no reason to 

Re: [Snowdrift-design] Discuss project page and dashboard

[Stephen Michel]

Aaron and I chatted and he asked me to include an apology for 
brain-dumping to the list (so he won't have to add another email to 
this thread).


We'd both like to hear more opinions, so I've re-arranged and quoted 
very selectively; hopefully this makes it easier for you to jump in 
(especially to reply to just one section). Some nuance is lost; you can 
get it from Aaron's full email if it's needed.


On Thu, May 19, 2016 at 5:38 PM, Aaron Wolf  
wrote:

On 05/19/2016 12:54 PM, Stephen Michel wrote:

 On Thu, May 19, 2016 at 12:08 PM, Michael Siepmann
  wrote:

 As discussed in a recent meeting (transcript in
 https://tree.taiga.io/project/snowdrift/task/323), wolftune, mray, 
me,

 and anyone else who wants to participate, need to discuss current
 status and next steps to get the project page design sufficient for
 MVP, and also the dashboard design
 (https://tree.taiga.io/project/snowdrift/us/67).

 mray: I think you have mockups of these which we could revisit as a
 starting point?  Anything else we should look at or think about 
before

 actually meeting?


 People's first question about the mechanism is ALWAYS "What 
prevents me

 from suddenly getting a huge bill if there's influx of patrons?" Of
 course there will be some safeguard in place to prevent this.

 "Some safeguard" is pretty vague. Let's fix that. I see 3 options:



Please stop "fixing" things that we already fixed.

We have a HUGE list of problems that have not been answered at all.
Please don't waste time reconsidering ones that are not in that list.



 3. Patrons set a monthly budget for each project.



This is something we already discussed in the discussion part of the
limits page. It's comparable to multiple accounts in order to create
separate budgets to buffer one project against another. It is screwy 
in
various ways. It's not terrible, but it works against consensus and 
the

idea of providing a budget overall.



Anyway: https://snowdrift.coop/p/snowdrift/w/en/limits/c/1998


In the Mechanism, Transactions, and Limits wiki pages and their 
discussions, the only relevant post I can find is the one you linked. 
It is short and does not respond to everything in this email. There are 
parts I disagree with. It has no replies.


Unless I'm missing something, I contend that this horse is neither 
bruised nor dead. 



["This isn't relevant"]


This email thread is about a design for the project and dashboard 
pages. Whether the limit is set on the dashboard page or the project 
page when pledging (or both) *is* an MVP decision. So is whether to 
include a wallet in addition to a monthly budget.


 1. Patrons set an absolute limit, where we won't ever charge them 
more

 than that, total.
   - I anticipate everyone agrees that this is a bad option for us 
(or

 any ongoing system). If it turns out I'm wrong, I'll elaborate then.


No, nobody thinks this is fundamentally wrong. This is just the 
"wallet"

approach, even if we actually charge in arrears. There's NOTHING wrong
with absolute limit. People *obviously* can *change* their absolute
limit by adding/authorizing more funds. This is the approach where 
some

people feel the most control. It's fine.


It may be the same technically, but I am thinking about this from a 
User Experience perspective -- which is the perspective that matters in 
this context. I need more information about the UX of arrears to make 
conclusions.


I'm a user. I go to snowdrift.coop, log in, go somewhere (I'd assume 
dashboard, but I'm trying not to assume), and click on a button to add 
funds to my account (current balance: $0). I specify $50 and click 
'next'. Now what happens? I presume I'm prompted to log in to Stripe. 
Am I also prompted to authorize $50 for snowdrift, or does that come 
later, or for individual transactions, or...?



 2. Patrons set a monthly budget for their account.


This is just a subtle difference from number 1, and it's fine too. We 
do
indeed need to pick the implementation of 1 or 2 here, and I'm okay 
with

offering BOTH. I think it would be good to offer both and get feedback
from there. It would not be that hard. People just choose to accept X 
as

a total to play with or set a monthly budget limit. Both are easy to
understand.


Well, *any* safeguard has to perform a certain duty, so only subtle 
differences are possible. If we use a scale of "barely different at 
all" to "a little different", I think #1 (wallet) and #2 (monthly 
limit) are quite dissimilar.


- #1 requires me to manually authorize funds, #2 does so automatically.
- #1 does not allow me to change my mind after I've deposited funds; 
with #2 I can modify my limit at any time up until the monthly payout.
- #1 as discussed a while ago requires me to maintain a 3 month minimum 
balance; #2 does not.


That third point is the biggest difference. If a project gains huge 
popularity overnight and eats up all 3 months' funds in a single month, 
I'll feel 

Re: [Snowdrift-design] Discuss project page and dashboard

[Aaron Wolf]

I want to clarify overall:

First, the short answer "oh, you have a budget for the system" is 99% of
the time completely satisfactory to the people who ask the "what if it
gets hugely popular and I have to pay so much?" question.

In other words, it is not accurate to present that question as "the
first question we get asked" implying that it's an outstanding concern.
It's not a concern at all. If we say "you have a budget for the system"
when we explain the system, then that question doesn't even get asked in
the first place.

now…

There are other questions that get asked that are more worth discussing.
Such as "what if a project gets really popular and eats up my budget,
leaving less for others?" and that's where we talk about how consensus
is *good* and we work against fragmentation but that we have ideas for
managing this in the long run if needed, such as the possibility of
categorical budgets or per-project budgets, etc. this is not as simple a
question.

The real question that was brought up here is "what about niche
projects? I may want to support some popular thing, but I *really* care
more about doing all I can for this niche project where fewer people
will join me. Can I set different pledge levels for different projects?"

And for that question, our current answer is: "We're concerned about
that, but our core design will probably work best for the most popular
projects, so we're aiming to make that successful first. However, we
have considered varying pledge levels, it's just that it adds complexity
that is harder to manage, explain, and more." And that's more what the
current discussion is about.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Discuss project page and dashboard

[Aaron Wolf]

On 05/19/2016 12:54 PM, Stephen Michel wrote:
> Thanks for getting the ball rolling on this conversation, Michael.
> 
> On Thu, May 19, 2016 at 12:08 PM, Michael Siepmann
>  wrote:
>> As discussed in a recent meeting (transcript in
>> https://tree.taiga.io/project/snowdrift/task/323), wolftune, mray, me,
>> and anyone else who wants to participate, need to discuss current
>> status and next steps to get the project page design sufficient for
>> MVP, and also the dashboard design
>> (https://tree.taiga.io/project/snowdrift/us/67).
>>
>> mray: I think you have mockups of these which we could revisit as a
>> starting point?  Anything else we should look at or think about before
>> actually meeting?
> 
> People's first question about the mechanism is ALWAYS "What prevents me
> from suddenly getting a huge bill if there's influx of patrons?" Of
> course there will be some safeguard in place to prevent this.
> 
> "Some safeguard" is pretty vague. Let's fix that. I see 3 options:
> 

Please stop "fixing" things that we already fixed. We're working on an
MVP here, not reconsidering everything over and over. We never ever ever
say "there will be some safeguard" we always give a concrete answer that
we already decided long ago: "you will set a budget for the system
overall, it's not like we just have your credit card and charge
whatever. If the pledge goes beyond your budget, you'll get a
notification and the be able to choose whether to drop the pledge or
adjust your budget."

The only thing that is "there may be SOME x" is the "project so popular
that many people can't afford to pledge" which has the answer of "we
will be a success already if we get to where that is our problem, but we
have ideas about the best ways to handle that. It's not a major problem
though — people dropping out due to high pledge value is a natural
self-correction to high pledge value. but read the limits wiki page for
more thoughts"

We have a HUGE list of problems that have not been answered at all.
Please don't waste time reconsidering ones that are not in that list.

> 1. Patrons set an absolute limit, where we won't ever charge them more
> than that, total.
>   - I anticipate everyone agrees that this is a bad option for us (or
> any ongoing system). If it turns out I'm wrong, I'll elaborate then.

No, nobody thinks this is fundamentally wrong. This is just the "wallet"
approach, even if we actually charge in arrears. There's NOTHING wrong
with absolute limit. People *obviously* can *change* their absolute
limit by adding/authorizing more funds. This is the approach where some
people feel the most control. It's fine.

> 2. Patrons set a monthly budget for their account.

This is just a subtle difference from number 1, and it's fine too. We do
indeed need to pick the implementation of 1 or 2 here, and I'm okay with
offering BOTH. I think it would be good to offer both and get feedback
from there. It would not be that hard. People just choose to accept X as
a total to play with or set a monthly budget limit. Both are easy to
understand.

> 3. Patrons set a monthly budget for each project.
> 

This is something we already discussed in the discussion part of the
limits page. It's comparable to multiple accounts in order to create
separate budgets to buffer one project against another. It is screwy in
various ways. It's not terrible, but it works against consensus and the
idea of providing a budget overall.

Number 3 here creates a huge extra variable for people to do something
quite different from just pledging-or-not. Instead, they are starting to
do all sorts of complex juggling of budget values for multiple projects.
It's complex, harder to track… I don't want us to consider this for MVP
or just-after MVP.

Effectively, this does revisit the whole concept of "shares" in that
it's part of trying to address the whole issue of wanting to really
support some important project big time but not caring as much about
some minor project etc. It's not crazy. But it's definitely complex.

For initial use, we don't have to create per-project budgeting or
per-category budgeting. People could just create two users and have them
each budget different amounts. This is a more serious issue: not wanting
people to game the system by creating many patrons accounts just to get
matched more. But a certain amount of this isn't fatal.

Anyway: https://snowdrift.coop/p/snowdrift/w/en/limits/c/1998

All that said, if we had the resources to research all these options and
implement them all, I'm not opposed. But I oppose the idea of choosing
number 3 alone and going with that first. It is definitely an
alternate-maybe-later option, not acceptable as the initial only option
(although for a one-project MVP it's the same)

> I think #3 is the best. Here's why:
> 
> ---
> 
> (A) It can be set at the time of pledging
> 
> This allows people to be more comfortable when pledging, potentially
> increasing participation.
> 

This is speculation 

Re: [Snowdrift-design] Discuss project page and dashboard

[Stephen Michel]

Thanks for getting the ball rolling on this conversation, Michael.

On Thu, May 19, 2016 at 12:08 PM, Michael Siepmann 
 wrote:
As discussed in a recent meeting (transcript in 
https://tree.taiga.io/project/snowdrift/task/323), wolftune, mray, 
me, and anyone else who wants to participate, need to discuss current 
status and next steps to get the project page design sufficient for 
MVP, and also the dashboard design 
(https://tree.taiga.io/project/snowdrift/us/67).


mray: I think you have mockups of these which we could revisit as a 
starting point?  Anything else we should look at or think about 
before actually meeting?


People's first question about the mechanism is ALWAYS "What prevents me 
from suddenly getting a huge bill if there's influx of patrons?" Of 
course there will be some safeguard in place to prevent this.


"Some safeguard" is pretty vague. Let's fix that. I see 3 options:

1. Patrons set an absolute limit, where we won't ever charge them more 
than that, total.
 - I anticipate everyone agrees that this is a bad option for us (or 
any ongoing system). If it turns out I'm wrong, I'll elaborate then.

2. Patrons set a monthly budget for their account.
3. Patrons set a monthly budget for each project.

I think #3 is the best. Here's why:

---

(A) It can be set at the time of pledging

This allows people to be more comfortable when pledging, potentially 
increasing participation.


---

(B) Post-MVP, it's a simpler decision (albeit one that's made more 
often)


When I run over my budget, I have to decide whether to increase it or 
drop a project. In the per-project case, I need to make that decision 
for one project only. For an account-wide budget, I need to make that 
decision for every project I'm supporting.


When I'm pledging to a new project, the account-wide case forces me to 
consider whether I'd rather put my budget towards projects I'm already 
supporting, since projects compete against each other for a share of my 
budget.


This disincentives to supporting multiple projects; that's NOT the type 
of "rule of the game" we want to be creating. It also puts the 'Pledge' 
action behind a complex decision. This will discourage people from 
pledging regardless of how the incentives align.


---

(C) It reinforces the idea of matching

For example, it would allow us to show a visualization of a project's 
current funding level and also the pool of money available for matching 
as others join a project.


We could also include a visualization that shows how increasing your 
budget cap bolsters that pool of available funds (and therefore 
provides a stronger incentive for others to pledge).


---

(D) It's more like normal budgeting

"I'm setting aside $X per month for this project (even if I may not 
actually give all of that this month)."


The closest comparison I can think of to an account-wide budget is a 
shopping budget, where you're buying the same stuff each time, and the 
prices for individual things might change but your budget won't. Unlike 
shopping, though, Snowdrift is a donation, not a transaction, so I'm 
not (or shouldn't be) concerned with getting the best deal ("sales") -- 
ie, only support projects when their pledge level drops; when they 
start losing patrons.
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Snowdrift-design] Discuss project page and dashboard

[Michael Siepmann]

As discussed in a recent meeting (transcript in
https://tree.taiga.io/project/snowdrift/task/323), wolftune, mray, me,
and anyone else who wants to participate, need to discuss current status
and next steps to get the project page design sufficient for MVP, and
also the dashboard design (https://tree.taiga.io/project/snowdrift/us/67).

mray: I think you have mockups of these which we could revisit as a
starting point?  Anything else we should look at or think about before
actually meeting?

Michael

-- 

Michael Siepmann, Ph.D.
*The Tech Design Psychologist*™
/Shaping technology to help people flourish/™
303-835-0501   TechDesignPsych.com
   OpenPGP: 6D65A4F7

 



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design