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 <aa...@snowdrift.coop>
wrote:
On 05/19/2016 12:54 PM, Stephen Michel wrote:
On Thu, May 19, 2016 at 12:08 PM, Michael Siepmann
<m...@techdesignpsych.com> 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. <Monty Python and the Holy Grail reference here>
["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 betrayed by the system. With #2 this is not possible.
Therefore #2 is the more effective safeguard.
Yes, automation can make some people uncomfortable. This is better
solved, for example, by requiring me to manually confirm my budget this
month, and adding a setting to auto-confirm [1], than building two
whole different workflows.
Arrears may change the second and third points in that list, in which
case the two options are more similar -- but also in that case there's
less reason to offer both of them.
(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 (that I think is also invalid). We have no basis
to
think that per-project budgeting will increase participation over
system-wide budget.
Well, yes. Until you can do user research, much of ux design is
speculating what it's like if you're in a user's shoes. I probably
should have phrased it more speculatively. Michael, Robert, what do you
think?
(B) Post-MVP
Post-MVP, therefore I shall omit it here.
(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.
That's an extra variable that is going to also be *quite* VARYING.
This
is potentially *counter-productive* because showing people the
end-game
in game theory dilemmas results in strategic anti-cooperative
thinking.
https://snowdrift.coop/p/snowdrift/w/en/mechanism#flexibility-with-practical-limits
This is a good point. It made me realize I was coming at this problem
with the assumption that everyone will try to game the system, so
there's no cost to showing the end-game -- so if showing the end game
makes the system less vulnerable to gaming, that's a good thing. But
this may be a false assumption, in which case there is a cost to
revealing the end game and my analysis does not hold.
We don't want to make people decide hard limits per project, we want
the
to give up some control to the cooperative process. They need to feel
like "okay, I have a system-wide budget, but I'm willing to work with
others to make a difference and see where things go".
What if it were a notification/alert, rather than a hard limit?
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).
Besides, studies of traditional matching in non-profit fundraising
show
little improvement when [...] telling people the details of how much
funds.
I didn't realize this. This indicates that the suggested visualization
is rather useless. I'll drop point C.
(D) It's more like normal budgeting
So, this topic isn't the core one that Michael was bringing up.
Alas, you are correct.
The part of this that IS relevant to MVP is: at what stage of the
process does it make most sense for me to set my budget? When I pledge,
or when I authorize Snowdrift to charge my Stripe account?
When I pledge for the first time it probably doesn't matter much since
they happen at the same time. But what if I pledge (and authorize
Stripe and set a budget), then unpledge, then pledge again? Am I
prompted to set a new budget or do I keep my budget from last time?
Personally I think I'd want to be prompted for my budget again.
~Stephen
[1]: This setting could be phrased a variety of ways; please try to see
past the phrasing and don't nitpick it. We're talking at a much higher
level here, I hope. Heck, "having a setting to fix this" is itself just
an example to show the point that there are other, more elegant,
options than simply giving the user everything and allowing them to
decide what to use.
All that said, if we had the resources to research all these options
and
implement them all, I'm not opposed.
In the (paraphrased) words of the wise chreekat, "I've found that
adding settings is often an excuse for not doing the [design] work to
figure out the way it should be." Offering whole different workflows is
a step up that ladder from offering a simple setting.
_______________________________________________
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design
