On a side note, the psychology of our design and the way we have permissions could address the too-much-shifting concern.
Some ideas: We could send a message when someone reduces their pledge level, "Remember that this is a social contract; you made a public statement to donate at this level. You are free to reduce your pledge, but your goal should be to determine a rate that you feel comfortable sustaining. Don't set a level that you then plan to change later. Of course, if you change your mind about which projects to prioritize, that is perfectly welcome." We need something more succinct, and another thought is that we could send such a message only if someone reduces their pledge a couple times or more within a time-frame. Another idea: Track how much someone changes their pledge and if they change it too often, give them a message/warning asking them to be more patient and to find a level they are comfortable sticking with. Then, if there are further issues, we actually change permissions. For example here's a possible rule: If you make a higher pledge to a project but then reduce it within 3 months of making it, your pledge will have a cap whatever lower level you actually donate at. (probably this cap would have a time period before being lifted) For example, someone pledges 10¢ per patron but then decides that's too much and reduces it to 4¢ and actually participates in a couple months of donations at that level. We then block them from increasing their pledge beyond 4¢ for at least another couple months. This is just one version of a bunch of ideas we could work out for effectively limiting the volatility. Essentially, if we build the prototype and it seems people are changing pledges in too volatile a manner, then we can make various rules about how often you can change or in what ways you can change or other limits to pledging if you show a pattern of pledging but not following through. The right design of the rules and messaging will make people feel comfortable experimenting initially so they understand the system (we certainly want to let people see exactly what a pledge will do before they are fully committed to it or have any real consequences), yet also push people to feel that they have made a commitment and shouldn't take it back. One thing to consider is the extent to which Kickstarter type sites allow people to cancel or change their pledge before a campaign ends. Anyway, I still don't see any of these issues as blockers to building a prototype and going from there. On 06/01/2015 03:47 PM, Aaron Wolf wrote: > > > On 06/01/2015 02:39 PM, mray wrote: >> >> >> On 01.06.2015 17:40, Aaron Wolf wrote: >>> Here's my feeling for now: First, that doesn't remove the ability >>> counteract the network effect, it just makes it more blunt, because >>> people could still change their levels, it would only be system-wide. >> >> You are right they, can use that option to counteract the network >> effect. But projects are in different stages of the network effect; >> either riding the wave of success – or not. So counter-regulating via >> one option alone over all projects seems ineffective if not impossible. >> >>> >>> I think the better solution to counteract the tendency of patrons >>> working to undermine the network effect is to just design things clearly >>> so they pledge with supporting the network in mind. The new simpler >>> pledge makes that much easier. >> >> We are on the same page here I think. People somehow need to feel good >> about giving away control AND money. My conclusion is just that having >> one pledge value is the needed *simplicity* and the *transparency* comes >> from the non-existing extra options. >> >>> >>> I propose: >>> >>> A. we have a one-click default pledge button >>> B. we offer the more in-depth pledge options >>> C. we present the pledges as "X per patron" and emphasize the value of >>> the network effect >>> D. we finish prototyping and designing and testing >>> >>> If it turns out that we see too much inclination toward counteracting >>> the network effect, we can change the options available in the advanced >>> pledge form. For example, we could set a maximum level. We could have a >>> small number of fixed options and not offer an "other" field. >>> >> >> How exactly should the button work now? >> My problem is that A. and B. don't make up a good prototype. Our >> expectations towards the pledge button require that it leaves close to >> no room for misunderstandings or missed options. >> We should not have a button that is variable in its behavior based on >> how it is configured in obscure pledge options. If there are options >> that make sense to use differently from project to project they need to >> be incorporated into the button. and pretty straight forward. >> > > I don't think this is confusing at all. Ignore for now the idea of > setting a different default pledge. The single "pledge" button in the > simpler interface = 0.1¢ per patron. End of story. It's very simple. > > Now, *offering* an advanced interface to pledge at higher levels isn't > confusing either. Instead of 0.1¢ per patron, you might pledge 0.2¢ or > 1.5¢ or something. Not at all confusing. You are pledging to donate this > much per patron. If there are X patrons, you donate X * your pledge. > > Thus, there is no incompatibility between A and B. And there is no room > for confusion. If you don't adjust things via the advanced options, your > pledge is 0.1¢. That's perfectly consistent and reliable. > > Now, I agree that if we offered *projects* the ability to set a > different minimum *that* would need to be specified by the simple > button. It would say, "the base pledge for this project is 0.5¢" and for > another project it would be 2¢ or something. I propose we do *not* have > that option in the initial prototype. > > The initial prototype should just be 0.1¢ pledge is the main simple > button, end of story. But the advanced features exist in order to be > more generous. That's not a problem. Anyone who chooses a higher pledge > simply chooses a higher pledge. They still donate pledge * patrons. > > Now, if there are projects that have many patrons at higher pledges, > then we get to advertise to new patrons: "if you join at the base-level > your donation total will be $3.48, but others will add $7.12!" or > something like that. > > For someone new to the system trying to understand, their one-button > pledge is the same cost to them whether or not anyone else has ever > pledged more. Others pledging more just means the new patron makes an > even bigger difference. > > I think the design will be that the overall project listing (the page of > many projects) should have one pledge button per project that just > enters a base-level pledge. The more detailed page for each project > should show the options for higher pledge levels. Users might go > straight to the individual project page and pledge at various levels > (where we should still have the base-level be the default) *or* they > might click the initial simpler button but then later visit the > individual page and choose to increase their pledge (or not). > > >>> The worst case scenario for people counteracting the network effect is >>> that it leads people to not bother pledging because they think their >>> pledge will result in others *reducing* their pledges. We need to be >>> wary about that. >> >> Absolutely. Transparency towards other donors options is a requirement >> for trust in our system. We need to be able to reasonably assure that >> others won't twitch. >> >> > > Trusting others' pledges is important, but it's not something we need a > guarantee about. This is where testing is important, we need to have > actual experience with things and tweak to get people feeling > comfortable. As long as people don't pledge really high levels, it won't > be an issue. Someone who pledges 1¢ instead of 0.1¢ will probably be > fine watching their pledge get into the dollars as a project gets > hundreds of patrons. If a project reaches thousands and that person > feels like they can't support their 1¢ pledge anymore, it does slightly > counteract the network effect, but it's okay to have a little stabilization. > > In the end, if people keep moving down toward more and more people just > at the base level, that's okay. > -- Aaron Wolf Snowdrift.coop <https://snowdrift.coop> _______________________________________________ Discuss mailing list [email protected] https://lists.snowdrift.coop/mailman/listinfo/discuss
