On 06/23/2016 08:38 PM, Michael Siepmann wrote: > This message pulls in mray's comments from several emails into one to > respond to, and snips out most of the what led up to the comment, which > is available if needed in mray's 6/20/2016 emails. > > On 06/20/2016 04:20 PM, mray wrote: >> On 06.06.2016 20:33, Michael Siepmann wrote: >>> >>> The good feeling is not just about being able to definitively pledge. >>> It's about knowing that your max can match plenty of new patrons. I'm >>> thinking about ideas for how to display it and word it. The key is to >>> orient people to keeping a healthy buffer between their current total >>> pledge value and their monthly max. >> I feel pushy about asking people to always raise their limit. >> Everybody has a limit and we should not make people feel bad when they >> reach it. We should also be fine with having a *HUGE* buffer at the >> beginning and with a *close enough* buffer towards the end. We can't >> assume where the hard limit of people purses resides. ...What is a >> "healthy buffer"? We should take precautions to avoid people >> permanently getting into some kind of "You promised to pledge at least >> 3 months, but it looks like that won't be possible, please fix >> that"-dilemma. > > I'm not wanting to ask people to always raise their limit, or make them > feel bad when they reach it. I just want people to understand that > crowdmatching needs some buffer between your current total pledge value > and your max. It needs to be clear that if you don't have an ample > buffer, you don't have to increase your max, but you do need to either > increase your max or unpledge to one or more projects. I agree we > shouldn't give any impression of making assumptions about the limit of > people's purses. > >>> >>> It might be that not displaying any scale would be better. I'm >>> thinking of having a simple 3-state icon type of indicator, >>> representing "plenty", "enough, but only just", and "not enough". >>> Then the actual amounts might be expressed numerically, but not on a >>> scale, e.g. in terms of % increase in patrons you could match. >> I like that idea as it removes unnecessary info. A 3-state icon might >> just miss the precision of conveying an the idea of scale. I'd be >> interested how things actually look like, at least in proportion. > > This is probably best discussed with mockups. For the moment I'm pretty > happy with a red / yellow / green indicator with one number, as in my > current mockups. I'm not sure that more precision than that is needed > or helpful here. > >>>> >>>> I guess my main issue is to have a hypothetical problem presented in >>>> detail when the solution is already reality: The limit takes care of >>>> things not going beyond it. Seeing some equations with crossed out >>>> numbers that contain prices higher than my limit makes me feel >>>> uneasy. "Total" an "Reduced Total" should not even exist as concepts >>>> as by definition the limit explicitly forbids the "Total" in that >>>> case. I feel much better with a system that just can't break instead >>>> of one that lets me choose how to repair it. Of course this is only >>>> about framing the problem. >>> I don't see how it's possible to make it so it "can't break" since >>> there's an inherent conflict between a monthly max and a set of >>> pledges that may exceed that max. In my view, part of the point of >>> the UI is to communicate that conflict when it exists and encourage >>> the user to resolve it. I think "Reduced total" is a valid concept >>> here because it represents what you're actually going to donate, >>> within the limit of your max, versus what you would donate if your >>> max was sufficient to fund all of your pledges. >> As I said it eventually all comes down to framing. Your approach seems >> to present two states at the same time: a "before" and an "after" >> while also inviting to twiddle around to observe the effect of your >> input. This feels to me like a thing is broken and you need to decide >> what the future of it should look like. I prefer to see this as having >> *one* bad apple in your basket. There is no before and no after, and >> you can deceide to just let it rot, replace it or throw it out. That >> way you have less pressure and less information to present and >> explain. This feels to me like just letting me know about how things >> are rolling right now. If I feel like it I can intervene. > > I think it's important to encourage patrons to be taking an interest in, > and consciously controlling, their pledges. From that point of view, an > automatically suspended pledge *is* a "broken" situation that calls for > attention from the user. What's "broken" about it is /not/ that the > patron "should" raise their limit. That's just one option for fixing the > situation. What's broken about it is simply that our algorithms have > had to make an assumption that may not match the user's wishes: We've > had to auto-suspend one of their pledges in order to respect their > maximum. One perfectly valid way for them to "fix" that situation is > for them to unpledge to that project. > >>>> Concerning the table format I share your view on its qualities to >>>> cope with much information that can still be displayed clearly, but >>>> my goal is to get a solution that does not require it in the first >>>> place. Depending on how simple we can stay I'd try to avoid tables. >>> I think our info for the dashboard naturally falls into a table >>> format. The mockup at http://codepen.io/anon/pen/WxbPwr is basically >>> a 3 row x 4 column table, just without headers. (Columns being >>> project name, # patrons, action, and current pledge value.) >> Technically it certainly *is* a table. I'm talking about the perceived >> order of information bits. If we can get away with just slicing well >> known and well understood slices of project page layout, and compiling >> a list out of them - I'd love to do that! Instead of creating a new >> table that gets fed from a common database. That way we can almost >> spare ourselves explaining the dashboard. People understand why and >> how projects ended up here, since they used each of the pledge buttons >> already. > > I'm not sure I fully understand your point here. The table in my > mockups seems reasonably straightforward to me, especially having been > simplified thanks to your prior comments (e.g. removing the 'Status' > column). Again this is probably best discussed through comparing > alternate mockups. >>>> One specific reason I don't think having button labels like "Pledge >>>> $3.99/month*" will work is that you're not actually pledging >>>> $3.99/month, you're pledging $0.001/patron/month. Having to consult >>>> the footnote that the asterisk points to is too complicated. That's >>>> why I prefer just "Pledge" or "Add" or some other simple action >>>> label that doesn't try to convey more information than can really >>>> fit in that context. >> Normally I'd share your concern. But in our case this irregularity is >> the heart of our mechanism. It is inconsistent to have a binary choice >> to pledge/unpledge but to have different values attached to that >> binary choice, depending on when you click it. At this point we just >> have to assume people understand that the value of pledging is in >> flux, and having a payout at the end of the month happens based on the >> respective value at *that* point. I'd rather let people consult the >> asterisk once or twice than explaing the mechanism constantly. I think >> it is also "safe" to assume another thing: Whenever you pledge you >> want to know what that pledge accumulates to if today was the end of >> the month. At this point every supporter should not only *know* that >> this value is changing, but *hope* it is rising. I said "safe" to >> assume because If that ISN'T the case we are letting people blindly >> steer their finances, which isn't really acceptable. > > I agree when you pledge you want to know what that pledge accumulates to > if today was the end of the month. However I disagree pretty strongly > with putting that value on the pledge button. I think that information > should be clear and obvious at the time of pledging, but I'd really like > to avoid making the UI in any way seem to suggest that *what* you're > pledging is that specific value. > > On 06/20/2016 04:49 PM, mray wrote: >> On 11.06.2016 01:39, Michael Siepmann wrote: >>> I've made adjustments to all three project mockups to account for >>> variable pledge-base-level, using the phrase "average pledge value >>> per patron" to indicate that the pledge value is not the same for >>> every patron. >> I'd prefer not to reflect this now (not MVP) neither later. Assuming >> we had the variable pledge level, I don't think that indicating the >> slight tendency of having a "1:1.x" instead of a "1:1" match matters >> enough to be underlined. It is the idea of matching itself that >> matters. Similarly I don't see how matching a project with 5800 >> patrons is a "bigger" motivation for compared to one with 5941 >> patrons. It is just not that much of a relevant difference when >> pledging. It is the *network effect* that matters, and the promise >> that it is really a crowd of people and not some huge entity next to a >> few "idiots". > > Re MVP, I think this is something we may need to design for now even if > it's not MVP, in order to have a design that can easily accommodate it > post-MVP. I agree that the idea of matching itself is what's most > important, but I think specific numbers can help at least some users > grasp that idea more vividly. > >>> I've also added something inspired by the above about encouraging >>> them to spread the word: >>> http://techdesignpsych.com/Temporary/snowdrift/project_sufficient.html In >>> thinking about that, I thought of a possible word to use >>> "crowdmatching" and wondered if Snowdrift has ever considered using >>> that? I searched to see if anyone else was using it and found >>> http://makinggoodthingshappen.org/about-crowdmatching-2/ using it in >>> a somewhat different way. For the moment, I've used the phrase >>> "mutual matching" in the "spread the word" part of the mockup. >> Crowdmatching. I do love that term. :D Let us use it full steam ahead! >> In comparison to "network effect" it is hip, focussing more on the >> social side, and makes sense even to those that are not researching >> the reasons how facebook became so big and its alternatives stand no >> chance. > > Great - I'm all for trying it and seeing how well it works. > > > On 06/20/2016 05:11 PM, mray wrote: >> On 11.06.2016 01:39, Michael Siepmann wrote: >>> >>> I've made adjustments to all three project mockups to account for >>> variable pledge-base-level, using the phrase "average pledge value >>> per patron" to indicate that the pledge value is not the same for >>> every patron. I've also added something inspired by the above about >>> encouraging them to spread the word: >>> http://techdesignpsych.com/Temporary/snowdrift/project_sufficient.html >> You mean this part right?: >> >> ================================================ >> Your pledge benefits Project X in three ways: >> >> You contribute directly (~ $6.54 currently) >> Other patrons match you (~ $7.13 currently) >> You match future patrons, increasing the incentive for others to pledge >> ================================================ >> >> >> >> Playing a bit of devils advocate this translates to: >> >> ================================================ >> You pledge once, but THREE! things happen: >> 1. you pledge >> 2. others honor their pledges >> 3. pledging will happen >> ================================================ >> >> >> ... this appears redundant and misses the temporal aspect of change. >> >> I really like the idea of taking care to remind people about how this is >> supposed to work though. Especially users that don't already have an >> account. >> > > Actually the part I was referring to about encouraging them to spread > the word was this: > > > Help Project X achieve critical mass > > Don't be one lonely patron! *Spread the word* to help Project X > achieve critical mass! Be sure to mention: > > 1. What you value about Project X > 2. How Snowdrift.coop makes supporting Project X more satisfying > and effective through crowdmatching > 3. That *you* are among the patrons who will match their pledge! > > > However, regarding your devil's advocacy, I'm not convinced. I think > the words "currently" and "future" help to convey the temporal aspect of > change, and I think my wording is significantly more specific and > informative, e.g. "Other patrons match you (~ $7.13 currently)" is a lot > more specific and informative than "others honor their pledges" which > sounds like it just means something more vague like "others make some > donation that they previously promised to make". > > > On 06/20/2016 05:18 PM, mray wrote: >> On 15.06.2016 04:00, Michael Siepmann wrote: >>> >>> I see the issue. I probably won't be able to spend more time on this >>> until next week, but will think about this. >> Just noting: Multi-pledge isn't MVP so maybe lets take care of that >> later. > > I agree that figuring out how to present the process of *changing* your > pledge level can be lower priority at MVP stage, if we're not actually > going to implement that option yet. > > > On 06/20/2016 05:46 PM, mray wrote: >> On 09.06.2016 22:21, Michael Siepmann wrote: >>> I've put some revised mockups at >>> http://techdesignpsych.com/Temporary/snowdrift/ based on recent >>> thoughts and conversations. Two new things they include are (a) a >>> red/yellow/green max status indicator on every page, and (b) the >>> project pages list three ways it makes a difference to the project >>> whether you're a patron or not. Looking forward to further >>> discussion. Best, Michael >> (a) red/yellow/green indicator A "healthy buffer" is hard to define as >> a meaningful measure. We should be happy with every amount as long as >> no problems occur. When they occur they shouldn't appear frequently. >> The indicator seems to make much more sense for actual problems >> needing indication; e.g. when the "limit" is lower than "pledges" + >> "buffer". (b) listing three ways a pledge makes a difference I agree >> we need to actively approach patrons and non-patrons about the ways >> snowdrift works. I also think we should try to rely on visuals not >> *only* on plain text in order to avoid having too much text. > > I agree about using effective visuals as far as possible. However, I > don't think a "healthy buffer" is that hard to define. It just means > that the number of patrons can increase by a reasonable margin before > our algorithms will have to auto-suspend one of your pledges. In other > words, it just means that your max, in relation to your pledges, is > sufficient to support crowdmatching, rather than just being sufficient > to meet your current total pledge value. I do *not* think we should be > happy with max-to-pledge-value ratios that don't support crowdmatching, > since crowdmatching is the whole point of Snowdrift.coop. But again, > this doesn't mean we're telling people they must increase their max, or > that they should feel bad if they can't. It just means we're letting > them know that in order to continue to participate in crowdmatching, > they need to *either* increase their max *or* unpledge to one or more of > their projects. > > >
FWIW, I agree with everything Michael wrote in his reply here. I also find that even right here in this discussion the term "crowdmatching" seems very effective at capturing the nuance. Michael was able to express it as "this is the activity you are doing: crowdmatching" and it's easy to jump to "therefore, you can't just set a fixed hard limit that you stick to (like that you match only the first 4,000 patrons and don't match beyond that) because that would not be fully crowdmatching, of course. I think if we explain all the reasoning, concepts etc. with the idea of "crowdmatching", everything will become clear and consistent. I'm not actually proposing this, but it occurs to me that an extension of the slogan could then be something like "crowdmatching to free the commons" or "free the commons with crowdmatching" or even just "crowdmatching for the commons" (I don't like that because it implies that you could crowdmatch for other purposes, and I want to insist that public goods are the *only* legitimate type of thing in which crowdmatching makes sense (even if that's debatable, I want us to take that position — that crowdmatching for proprietary stuff makes no sense). One more point: even though varying per-patron match levels may not strictly be the smallest possible way for us to get an operating system, it's at least arguable that including it may be necessary for the system to start out viable enough to successfully fund the Snowdrift.coop project. We don't want it to undo the network effect, but we certainly want the 1000 patrons we may get early on to total more than $1,000 per month if a portion of those patrons are wealthy and want to be at a more generous crowdmatching level. So, I'm not 100% sure that setting higher pledge base is not MVP. We need not only for the math and the system to work but for it to be a fundraising success enough that people don't write it off. My feeling is that having this as a factor to play with, maybe test, explore, A/B, research, etc. makes some sense.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
