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. <snip> > - #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 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. > 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. <snip> >> 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. > Actually, even if everyone *did* try to game the system (which we can be sure won't happen), that doesn't change the cost of showing the end-game. The whole prisoner's dilemma / snowdrift-dilemma stuff is about how the most gaming-of-gamers trying to hack the system for their own goals change their behavior if the end-game is known. The fundamental issue is to *not* tell people when others are going to drop-out or not, Don't tell patrons what the budgets of the other patrons are set as (even in aggregate). It's actually not set anyway, since people change their minds based on seeing what others do. https://en.wikipedia.org/wiki/Prisoner's_dilemma#The_iterated_prisoners.27_dilemma >> 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 want all relevant notifications. People should be able to monitor what's happening and understand what the system is doing! <snip> > 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. 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. > 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. > Oh, I think there should be no connection between each pledge and budgeting. If you cancel a pledge *before* it is actually entered, maybe nothing should happen if it was all one process. But if you budget at the time of your first pledge and then remove it, well, you have no pledges, so there's no risk to having your budget still. I think it should be clear that setting your system budget and hitting pledge are two different things, just one is a pre-req for the other, and so we could include it in the first pledge process. (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). Thanks for all your work making things happen and graciousness in the discourse! Cheers, Aaron
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
