Linking the relevant Taiga pages again for visibility:
Dashboard: https://tree.taiga.io/project/snowdrift/us/67
Project Page: https://tree.taiga.io/project/snowdrift/us/321
There was a small amount of initial work done in those places, I've
added another little bit to that.
On Fri, May 20, 2016 at 12:16 AM, Aaron Wolf <aa...@snowdrift.coop>
wrote:
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.
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).
Between this and our out-of-band conversation, I'm satisfied /
convinced that a lot of what I brought up is post-mvp (more than just
point B) and has been adequately discussed in the past, so I'll try to
trim out even more of my own non-mvp nonsense.
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)
For MVP I'd leave out a rolling balance.
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.
Thanks for the clarification, I didn't realize this. That makes a
wallet a much more palatable option.
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 feel betrayed, I don't understand that expression
in this case. I suspect it comes from your misunderstanding of the
3-month thing, as I clarified above.
That is indeed where "betrayed" comes from. Specifically the feeling of
"I thought I was keeping a balance for three months and now suddenly
it's gone in just one?!?!"
You are, of course, correct that this is speculation. The problem is,
it's a common thing that people speculate about, and so they end up
concerned even though there is no need to be. So the important thing is
not to *actually* prevent it from happening, but to *reassure* people
that it will not happen (or that they'll have a chance to back out if
it does) so that they'll be comfortable signing up.
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.
I wasn't proposing "whole different workflows". If we offer both
one-time and monthly, the workflow would be almost the ame, and you'd
just say X one-time vs Y monthly-recurring as two choices in the same
interface with nothing else different. The monthly-recurring
authorization would itself *count* as meeting the 3-month buffer for
new-pledges. The UX would be almost identical in both cases.
I think I see what you're envisioning, and I like it. It's easier
communicated visually so I'm going do to that, and then perhaps
continue this conversation on the relevant taiga user stories.
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?
what order does that happen in? I'm not sure. And yes, these are
important design decisions.
One smooth option: I already see the pledge button when just a
visitor.
Clicking it prompts me that I need to register as a user first. Then
maybe I'm back at the button still needing to click it again? Or
assume
upon registration that the button is clicked in this case? Not sure.
Then, prompt for Stripe credentials and set a budget right then,
maybe.
Needing to click again is less smooth but probably easier to implement.
I suspect this is what we'll do for MVP, then make incremental
improvements to make the UX smoother.
I think the optimal is to provide a way to set a budget *before*
pledging *and* direct people to that process as part of pledging if it
wasn't done in advance. Then do research on how many people pledge
first
and then budget versus the other way around.
I suspect some people will feel more comfortable pledging after
budgeting, and other people are fine just clicking the button and
seeing
what happens and then budgeting as part of that.
I'll discuss this further after I've made my mockup.
tl;dr As a result of this and our individual conversation, I no longer
think we need a budget for MVP -- only a notification if the pledge
exceeds a certain amount. But it'll make more sense with visuals, so
I'll hold off on further discussion until then.
(sorry for long reply again, trying to just be clear, I hope we can
pull
out of all this the key bits we actually should deal with and process
further).
This email wasn't quite as long, but more importantly, all the related
content was grouped together, so it was easy to pick and choose what to
quote.
Thanks for all your work making things happen and graciousness in the
discourse!
et tu
_______________________________________________
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design
