[Snowdrift-design] new Snowdrift.coop forum, email lists closing

[Aaron Wolf]

Hi! This email list has been inactive for a long time, but that’s not
because work stopped on Snowdrift.coop — it’s because we’ve moved to our
new community forum at https://community.snowdrift.coop

Please join us there! It’s integrated with your main Snowdrift.coop
account, so no need to separately register.

Specifically, design discussion has moved to the "Design" subcategory
under "Clearing the Path" (our general area for working on Snowdrift.coop).
https://community.snowdrift.coop/c/clear-the-path/design

Note that we also have separate issue tracking with GitLab, e.g. the
issues section of https://git.snowdrift.coop/sd/design — but most
discussion should start and usually stay at the forum.

We're making progress (for example, a new homepage will be up soon with
this video: https://archive.org/details/snowdrift-dot-coop-intro ), but
there's still lots to do. To help, come say "hi" on the forum as a first
step and we'll discuss from there.

---

### Notes on moving from email list to forum

The email lists will be shut off soon (although archives will remain
available for reference, see https://lists.snowdrift.coop for links).

Forums and mailing lists each have pros and cons, but the flexibility of
the Discourse software we’re now using offers a great balance (while
being a robust 100% FLO project that we’d love to eventually help support).

With our mailing lists, you had to choose to get all emails or none from
a set of a few fixed lists.

Now, you can subscribe in whatever way fits best for you. You can just
check the site when convenient. You can watch or unwatch specific
categories, tags, or topics as best works for you. The forum has many
other features including private-messaging, editing of posts…

Discourse’s flexible flagging system lets us do better enforcement of
our Code of Conduct (which itself has been updated). When you flag a
problem post, it simply prompts the author to edit and repost, so we all
get to learn and practice healthy communication. That sort of thing is
much harder with traditional mailing lists.

The welcome section at the forum includes further notes to show you around.

One point to highlight: To respect users, we made the activity-digest
opt-in. That means you will only get notifications of things you
actively choose to watch. To get periodic updates about overall forum
activity, go to your profile settings and turn on the activity digest
(you can choose the digest frequency).

We have several other announcements and updates to share soon, and they
will be posted to the Announcements category in the forum with some
other updates as blog posts.

Cheers!

-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] [Snowdrift-dev] Preliminary Review of Dashboard Prototype

[Aaron Wolf]

On 08/05/2017 08:07 AM, Bryan Richter wrote:
> On Tue, Aug 01, 2017 at 07:37:59AM -0500, Jason Harrer wrote:
>> Not sure how the dev list got removed, but adding it back in at this point.
>>
>> It sounds like there was consensus on this overall limit (just not project
>> limits).  That being said, I'm going to open up a ticket on GitLab so we on
>> the Dev team can track adding that in.  This is a requirement before we can
>> get the Dashboard page finished.
> 
> Can you explain why it's a requirement?
> 
> As far as I understand it, the page simply has to say that a limit
> exists.
> 
> My point, that I'm making here and elsewhere, is that implementing an
> automatic cutoff is not a necessary step for alpha. The process can
> remain manual for the time being.
> 
> There are a lot of other manual things I'd rather automate first.
> 
> 

I agree with Bryan. The requirement is that the limit actually is
respected, not that it be in the code per se. Since we face little
real-world risk of hitting the limit during alpha and will know for sure
if we're approaching it, we're fine. No extra requirement needed for alpha.

For beta, it will matter more because people could then pledge to
multiple projects and thus approach their limit with fewer patrons in
the system.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] [Snowdrift-dev] Preliminary Review of Dashboard Prototype

[Aaron Wolf]

On 07/31/2017 06:16 AM, mray wrote:
> 
> 
> On 30.07.2017 20:24, Aaron Wolf wrote:
>> ... Because
>> it's user-adjustable, they could make per-project budgets or choose to
>> budget separate amounts for music, art, software, etc. as fits their
>> priorities.
>>
>> The key point is that there's nothing wrong with C.
> 
> The way I see this kind of "fitting their priorities" is in conflict
> with our goal to use consensus as a lever in crowdmatching. Limits on a
> per-project or per-category basis are in direct contradiction with the
> idea to let a consensus decide, as it decreases the power structure we
> set up in the first place. One _already_ has ultimate control over
> supporting a project or not – and can make use of _that_ tool inside our
> mechanism to reflect on personal priorities.
> 
> I imagine the most useful application to multiple limits would be this
> scenario: There is an inverted interest in projects compared to their
> current success. So there are 2 questions:
> 
>  1. How do I support the "big" one just a little?
> You don't! It obviously is bigger than you feel comfortable, you did
> stick with it long enough. Drop your pledge, your work is done.
>  2. How do I support the "small" one more?
> You don't! Projects grow by consensus, so talk to people and make
> them join. As long as _you_ stick to it your work is done.
> 
> In both cases the mechanism makes people spend *less than they would*
> but encourages willingness to keep sticking to projects, donating more
> overall.
> 
> Also per-category limits are problematic due to unclear assignment. It
> would start to give benefits to projects that "cover" more categories,
> raising the question who has the power to assign them – and by what
> metric. It also complicates things to have more levers in general.
> 
> But my key point remains:
> Priorities should be consensus.
> Support should be choice.
> 
> 
> -Robert
> 
> 

While I share the concerns and have expressed them myself in the past, I
simply think this doesn't directly counteract the core mechanism. It's
perfectly reasonable for people to say, "I'm only up for spending $5/mo
on entertainment, but I'll spend up to $20/mo on scientific research" in
the same way as saying "I only want to spend $10/mo at Snowdrift.coop".

Yes, this lets users potentially weight things along the lines of
"Between GIMP and Krita, if the community consensus goes more for GIMP,
I'm only in the crowd up to $2/mo, but if the consensus goes for Krita,
I'm good for up to $5/mo"

If someone doesn't want to support GIMP *that* much, they would drop
their pledge anyway manually.

But the point is that I agree with the main concern: We don't want
people to take the mindset of saying "yeah, I'll give $X to project A
and $Y to project B" in the way that feels liks non-consensual
non-matching traditional donating.

I don't support adding budget categories until after *full* launch
(post-beta even). I would like to delay discussing it too much until
then. I think it's okay to *consider* offering after we're established
enough for people to really get the whole crowdmatching concept. And in
light of all the feedback and experience we have after full operations,
we may decide that it makes sense to offer.

The only point that matters for now is that I've switched from going
*out of my way* to make *sure* nobody imagines a per-project budget to
simply saying that if some people have that mistaken idea at this time,
it's not worth worrying about too much. Any questions that come up, we
just can say, "for now and the foreseeable future, we only offer a
simple system-wide budget" and we can emphasize the consensus
crowdmatching points.

So, I think it's okay to say either "there's a budget limit" or "there's
a system-wide budget limit" and not worry that we *always* have to say
the latter. I'm comfortable enough with the idea that some
misunderstanding here doesn't fundamentally break the crowdmatching idea
in any way, even though we'd prefer no misunderstanding. I'd rather
emphasize the crowdmatching core concept and not worry too much about
the budget besides the assurance that there's a limit.

The rest should play out when we're actually successful enough for
people to hit budget limits. Then, we'll have real-world experience from
which to decide things going forward.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Preliminary Review of Dashboard Prototype

[Aaron Wolf]

I want to add one clarification (to the note I just sent):

The remaining concern from a communication standpoint is that people not
believe that they get to stick to a budget limit and bypass the matching
pledge. Either they are matching or they aren't donating at all.

But I no longer think there's any problem with system-wide vs
budget-category / per-project budgets. As long as users understand that
they are in or out of the crowdmatching, I have no other worries about
their perceptions.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] [Snowdrift-dev] Preliminary Review of Dashboard Prototype

[Aaron Wolf]

On 07/30/2017 09:07 AM, Stephen Michel wrote:> Here's what I remember
from the discussions a few months back:
>
> On Sun, Jul 30, 2017 at 1:32 AM, Jason Harrer 
> wrote:
>>
>> There are two major concerns with this part of the prototype:
>>
>> 1) This goes against the philosophies that Aaron has talked about
>> numerous times, all the way back to when I first started on the
>> project 3-4 years ago.  He was strongly against the concept of
>> applying a cap/limit at all.
>
> The objection was against a *per-project* limit, not a site-wide limit,
> which I think everyone agrees is necessary to make people comfortable
> with pledging (even if the "pledge amount explosion" scenario is not
> very likely).
>
>> 2) There is currently no back-end support for a limit of any dollar
>> amount.
>
> We knew this. Plan at the time being:
>
> - Adding a limit function in the backend is a priority
> - Until we make an official announcement, we expect pledge numbers to be
> low, so we should have plenty of time before we're getting enough money
> to actually do a crowdmatch event.
> - If for some reason we get to the point of doing a crowdmatch event
> before the limit is implemented, we will enforce the limit manually
> (just check to make sure nobody's being charged over $5.
>
I have a changed view on the limits and it's reflected in the simplified
video script actually.

I think a per-project limit isn't a fundamental problem or a
misunderstanding we need to worry about.

I see the limit plan like this:

A. express that we *have* a budget limit and set it at $5 in the backend
as a starting point

B. make the limit adjustable system-wide (not an alpha requirement, but
if someone decides to do this before the rest of alpha is complete, it's
welcome enough)

C. Long-term plan (in light of real-world alpha experience, and fine to
express publicly as a long-term consideration): offer budget-categories
that users can each define. Let users name a category and put any
selected projects in it. This is comparable to folders/directories such
as how a service like AuctionSniper lets users group a bunch of eBay
items into a folder where you stop once you've won a set number. Because
it's user-adjustable, they could make per-project budgets or choose to
budget separate amounts for music, art, software, etc. as fits their
priorities.

The key point is that there's nothing wrong with C. So, for now we are
FINE with just saying "there's a budget limit" and if someone says "oh,
I can set a budget for each project?" the answer is "for now, it's just
system-wide, but we hope to offer separate budgets like that
eventually". (People could set up multiple accounts to get a similar
effect anyway, but that would mean extra charge accounts, more charges
and fees, and all the hassle of maintaining multiple accounts).

In short: I've DROPPED my big worry about making sure people don't
imagine per-project budgeting.






signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Snowdrift-design] video process and feedback

[Aaron Wolf]

Hi everyone,

Johannes made a new draft of the video are out and some feedback with
the link to draft video posted to
https://git.snowdrift.coop/sd/design/issues/15

I might have posted here instead of that issue, but we're still figuring
out the best ways to organize the work. I just wanted to post this to
the list so that others who are interested in the progress and in maybe
giving their feedback are aware.

Cheers,
Aaron


-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new, short and plain intro video script

[Aaron Wolf]

On 05/02/2017 11:27 PM, Aaron Wolf wrote:
> Hi everyone,
> 
> Starting a new thread. This new script is a departure from the others.
> It just focuses more directly on the core concept with near-zero
> explanation of why it makes sense or is needed. It has no awkward
> transitions, it's plain and simple. It's so short that I was able to say
> it in minimal time while still speaking slowly.
> 
> Although there are reasons I want to communicate more concepts to
> visitors, I'm very happy with this in how well it communicates the
> minimal information.
> 
> There's room for tweaks and re-recording a better final audio, but this
> should truly be all that's needed for the video team to create a first
> complete visual.
> 
> SOME FEEDBACK ON EXISTING VIDEO DRAFT:
> 
> I'd really like to see more types of logos of project types including
> visual art / photos / videos even though the audio doesn't mention them.
> It could be in the mix later when showing general sharing. The audio is
> just some examples, and if there's more than 4 icon types it will be
> more clear that there's more than strictly those 4.
> 
> The icons bouncing around in a city is a good start, but could be improved.
> 
> The icons like GNU head etc. may be an issue for trademark permissions.
> 
> The graph stuff is good, but the timing and details will have to be
> adjusted to the new SCRIPT:
> 
> 1. Software, music, journalism, research… These things *should* be
>freely shared as public goods.
> 
> 2. But keeping exclusive control lets publishers charge for access or
>show ads.
> 
> 3. And without those restrictions, projects rarely get enough funding.
> 
> 4. We need ongoing and widespread cooperation to solve this dilemma.
> 
> 5. That's why we developed crowd*matching*,
> 
> 6. where you donate monthly based on the number of patrons giving with
>you.
> 
> 7. When a project has few patrons, you donate very little.
> 
> 8. As the crowd grows, everyone donates more.
> 
> 9. But you stay in the crowd only if it fits your budget.
> 
> 10. Join Snowdrift.coop today, and help clear the path to a free and
> open future!
> 
> Audio attached
> 
> 


By the way, there seems to be some confusion, so I want to clarify:

There were various old scripts and audio. Some visual work was done. The
visual team indicated a need to change the second half of the script. In
the process of reflecting on the whole goals and how much to fit in the
time, this new script above was written.

The new script addresses problems with the entire thing. I don't provide
it only to use the second half. Please adjust the timing and visuals for
the *entire* video to fit the new script and audio which has a much
simpler, cleaner flow overall.

I'm not okay with cutting the second half of this with any of the parts
from earlier scripts. This update is/was a departure (as stated in
original post) which does a better job as a complete unit.

I look forward to a new draft of visuals matched to just this new script
and audio, and we can discuss any feedback then so we can get toward
actually finalizing this.

Thanks,
Aaron



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new, short and plain intro video script

[Aaron Wolf]

On 05/26/2017 06:12 AM, mray wrote:
> That is great news!
> 
> Are you available for a small chat so I can give you an update of where
> we are?
> 
> 
> - Robert
> 
> 
> 
> On 25.05.2017 20:08, J.wuensch wrote:
>> Hi everyone,
>>
>> Just wanted to let you know that I'm almost completely free next week. So I 
>> plan to focus and work on the Snowdrift video. I hope I can manage to create 
>> a first complete visual during this time. I guess not with final graphics, 
>> but they can be replaced later on...
>>
>> Johannes
>>
>> Sent from [ProtonMail](https://protonmail.ch), encrypted email based in 
>> Switzerland.
>>
>>  Original Message 
>> Subject: [Snowdrift-design] new, short and plain intro video script
>> Local Time: May 3, 2017 8:27 AM
>> UTC Time: May 3, 2017 6:27 AM
>> From: aa...@snowdrift.coop
>> To: design@lists.snowdrift.coop 
>>
>> Hi everyone,
>>
>> Starting a new thread. This new script is a departure from the others.
>> It just focuses more directly on the core concept with near-zero
>> explanation of why it makes sense or is needed. It has no awkward
>> transitions, it's plain and simple. It's so short that I was able to say
>> it in minimal time while still speaking slowly.
>>
>> Although there are reasons I want to communicate more concepts to
>> visitors, I'm very happy with this in how well it communicates the
>> minimal information.
>>
>> There's room for tweaks and re-recording a better final audio, but this
>> should truly be all that's needed for the video team to create a first
>> complete visual.
>>
>> SOME FEEDBACK ON EXISTING VIDEO DRAFT:
>>
>> I'd really like to see more types of logos of project types including
>> visual art / photos / videos even though the audio doesn't mention them.
>> It could be in the mix later when showing general sharing. The audio is
>> just some examples, and if there's more than 4 icon types it will be
>> more clear that there's more than strictly those 4.
>>
>> The icons bouncing around in a city is a good start, but could be improved.
>>
>> The icons like GNU head etc. may be an issue for trademark permissions.
>>
>> The graph stuff is good, but the timing and details will have to be
>> adjusted to the new SCRIPT:
>>
>> 1. Software, music, journalism, research… These things *should* be
>> freely shared as public goods.
>>
>> 2. But keeping exclusive control lets publishers charge for access or
>> show ads.
>>
>> 3. And without those restrictions, projects rarely get enough funding.
>>
>> 4. We need ongoing and widespread cooperation to solve this dilemma.
>>
>> 5. That's why we developed crowd*matching*,
>>
>> 6. where you donate monthly based on the number of patrons giving with
>> you.
>>
>> 7. When a project has few patrons, you donate very little.
>>
>> 8. As the crowd grows, everyone donates more.
>>
>> 9. But you stay in the crowd only if it fits your budget.
>>
>> 10. Join Snowdrift.coop today, and help clear the path to a free and
>> open future!
>>
>> Audio attached
>>
>> --
>> Aaron Wolf
>> co-founder, Snowdrift.coop
>> ___
>> Design mailing list
>> Design@lists.snowdrift.coop
>> https://lists.snowdrift.coop/mailman/listinfo/design
>>
>>
>>
>> ___
>> Design mailing list
>> Design@lists.snowdrift.coop
>> https://lists.snowdrift.coop/mailman/listinfo/design
>>
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 

To quickly reiterate a point from meeting today:

If the timing of visuals happens to flow better a certain way, feel free
to play with cutting up the audio and/or time-stretching/squishing
sections of the audio in order to make for good visual timing. These
things can interact and find the right balance. When the final timing of
the visuals is set, I can record new audio to match it. So don't take
the timing too rigidly from the audio.

Looking forward to the new updates when ready, cheers



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Intro video script

[Aaron Wolf]

On 04/23/2017 02:01 PM, J.wuensch wrote:
> Sorry for no updates on my side! Last month was crazily busy. I work in
> a young start-up company and we had to prepare A LOT of stuff for a
> fair. So I had to pause working on the snowdrift video. I told Robert
> but I think it would have been better to communicate it here on the
> mailing list.
> Unfortunately there's an additional ongoing freelance job in my
> schedule. But I'm in the process of transferring it to someone else so
> that I'll have more time to work on projects that matter more to me like
> the snowdrift video. I'll definitively want to see this happen.
> 
> That said, the missing progress on my side has little to do with
> emphasize on finality but more with lack of time. Yes it's true, I did
> three versions of the first half of the movie instead of doing one draft
> for the whole. One simple reason is that I was unsure on how to
> illustrate the last part without being confusing. So my priority was to
> first find the overall animation style. Actually, iterating over
> Robert's feedback didn't take that long. And with limited time in mind I
> thought of doing part 2 after my stressful time.
> 
> As far as I'm concerned, feedback on the visuals of this third version
> (Animatic_v03.mp4) is already welcome. Maybe not on details as we can
> care about them later on when we have a full working version. But more
> the overall style.
> 
> Thanks Aron for the new script! As soon as I find some time I'll try to
> make a new version and we will see what I/we come up with to illustrate
> those sentences.
> 
> Btw: I'm totally fine with this kind of audio recording. It doesn't have
> to be a highly polished final version. I just need some audio to animate
> to. It can be finalized later when we see that the video and text is
> working well together. It shouldn't be a problem to adjust the timing of
> the animation to the final audio version later on.
> 
> That's it for now,
> Johannes
> 
> 

Thanks Johannes,

I agree with your points overall and glad to hear about the updates. I
agree that some iteration to get to "see that the video and text is
working well together" is what I want too. For whatever reasons that may
be partly miscommunication, I felt pressured to get something "just
right" before handing it over, which doesn't feel like the right approach.

FWIW, Stephen gave me some feedback on the latest script that may lead
to a new revision, but the recent one I posted is still the latest worth
working on visuals for.

I agree with you and Robert that avoiding the number-focused end stuff
is better. I'm happier with the direction now. I think some iterative
process back and forth between audio and visuals will get us to the best
final result.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] video asset update

[Aaron Wolf]

On 03/09/2017 05:29 AM, mray wrote:
> @Johannes:
> 
> Just wanted to ping about the assets in seafile being updated again:
>  * roads illustrations have more "flesh" at the bottom
>  * city is now more detailed (and layered for parallaxing)
>  * there are signs with license logos on them
>  * "Crowdmatching" flashy illustration (uses extra font "Bangers")
> 

If you're working on this level of detail rather than just rough
sketches, let me know when you want any feedback about these details.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] New, updated intro-video script and audio

[Aaron Wolf]

So, we discussed today that it would make sense to schedule another live
meeting where Robert, Johannes, I, and anyone else who cares to join us
discuss plans for the next steps in updating the script and video plans etc.

For reference for others reading this, some draft bits of animations:

https://snowdrift.sylphs.net/seafhttp/files/6effbf9d-f77a-4997-82b0-50bf81765512/Animatic_v02.mp4

https://snowdrift.sylphs.net/seafhttp/files/c83bf2d5-71f7-4d8e-811c-24aef7ce7ff3/x02_mechanism.mp4

So, Johannes, when works for you? Let's find a time that works for us
and then anyone else who joins us, great.

Cheers,
Aaron


On 02/17/2017 10:06 AM, J.wuensch wrote:
> Ok, lets meet under https://meet.jit.si/snowdrift_video then. I think my
> brother will join, too. See you in an hour!
> 
> Johannes
> 
> 
> Sent from ProtonMail , encrypted email based in
> Switzerland.
> 
> 
>>  Original Message 
>> Subject: Re: [Snowdrift-design] New, updated intro-video script and audio
>> Local Time: February 13, 2017 5:53 PM
>> UTC Time: February 13, 2017 4:53 PM
>> From: m...@mray.de
>> To: design@lists.snowdrift.coop
>>
>>
>> On 13.02.2017 13:04, J.wuensch wrote:
>> > Hey Robert!
>> > Sorry, I messed something up with an appointment I have as I thought
>> it would be on friday, but actually it's on thursday evening. So I
>> would suggest friday at 8 pm. Does that work for you, too?
>> >
>> > Johannes
>> >
>> >
>>
>>
>> Friday 17.2. 20:00 works for me! Lets meet then.
>>
>>
>> Robert
>>
>> ___
>> Design mailing list
>> Design@lists.snowdrift.coop
>> https://lists.snowdrift.coop/mailman/listinfo/design
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Snowdrift-design] New, updated intro-video script and audio

[Aaron Wolf]

Okay, after much delay (so sorry everyone!) I finally have major
progress here.

Several issues came up with the script when recording the audio. The
most stark was that jumping in with the budget line was totally
non-sequitur, had no connection to the rest of the script. A few other
words just flowed badly in terms of their sound (actual flow of
phonemes), and some bits lacked clarity.

The new script (which now has audio ready for storyboarding) has fewer
high-level words, so it's easier to understand, everything flows well.
No, it's not perfect, and there are a few variations of each line that
are equally good and just have different trade-offs. But this really
works finally.

Here's the script:

```
1. Things like software, music, journalism, and research *can* be public
goods, freely used and shared by *everyone*.

2. But most publishers keep exclusive control so they can show ads and
charge access fees.

3. And projects released under free and open terms don't get enough
funding.

4. To solve this dilemma, we developed a cooperative fundraising method
which we call crowd*matching*.

5. You support a project by pledging a monthly donation of 1 cent for
every 10 patrons who give with you.

6. So, a thousand patrons means a thousand dollars; and 5,000 patrons at
5 dollars each would bring a project's monthly income to 25,000 dollars.

7. With this pledge, you give up some individual control in order to
build consensus and grow the crowd.

8. But you still choose which projects stay active within your overall
budget for the system.

9. Join Snowdrift.coop today, and help clear the path to a free and open
future!
```


And here's 13 takes of audio with just some variation in delivery and
vocal style:

http://snowdrift.sylphs.net/d/841e82092d/

Note that I changed one word in the script after recording. The "and" in
line 6 was a "but" when I recorded the audio. This shouldn't affect the
storyboarding process and can be edited later or re-record the audio.

Yes, there's some room to tweak things, especially the audio delivery,
but I really want to go forward with using this and storyboarding and
get the video done. Between here and the final video, the audio itself
can be tweaked, a light ambient music background can be added, etc.
Nothing is set in stone. But this script finally passes all the
requirements I have, and I tried it with various people for feedback,
including those not really involved. It finally works well overall for
the limited time.

Please, video animation folks, get to work. I won't offer suggestions.
Make some good storyboards and then show the rest of us!

Cheers,
Aaron

-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] font roulette

[Aaron Wolf]

On 01/28/2017 12:03 PM, Dave Crossland wrote:
> Hi
> 
> I commissioned this. The bugs can be reported on
> github.com/Google/fonts/issues <http://github.com/Google/fonts/issues>


Great, Dave! Was it because you were aware of our troubles with lack of
italics in using Nunito? ;)

Regarding the "bug" point: is the different height for crossbar in A and
÷ a "bug" to report?

> 
> On Jan 28, 2017 11:54 AM, "Aaron Wolf"  <mailto:aa...@snowdrift.coop>> wrote:
> 
> On 01/28/2017 07:03 AM, mray wrote:
> > I'm not kidding: Maybe we go back to Nunito again after all!
> >
> > Turns out Jacques Le Bailly not only extended Adam Vernons "Nunito"
> > (Adam passed away 2016) to have proper italics and more weights, but
> > there is also "Nunito Sans" a new version of Nunito without rounded
> > terminals!
> >
> > https://fonts.google.com/specimen/Nunito
> <https://fonts.google.com/specimen/Nunito>
> > https://fonts.google.com/specimen/Nunito+Sans
> <https://fonts.google.com/specimen/Nunito+Sans>
> >
> > This is awesome and opens an even wider space of solutions while
> > sticking to our initial style!
> >
> > Looking forward to mess around with those fonts...
> >
> >
> 
> Very nice! I really have such weak preference here, it should barely be
> mentioned, but I did very much like Nunito except for the lack of
> italics and such. I am *fully* happy to return to using that if you
> choose to go that way. The updates look superb.
> 
> Nunito is a particularly balanced and readable font. The subtle
> difference of squared-off vs rounded for the regular vs sans variety is
> interesting. I notice strangely that the capital A and ÷ sign and some
> others have lower bars in Sans for some reason.
> 
> In the end, I'm happy enough with anything that's readable and has all
> the style variants.
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop <mailto:Design@lists.snowdrift.coop>
> https://lists.snowdrift.coop/mailman/listinfo/design
> <https://lists.snowdrift.coop/mailman/listinfo/design>
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] font roulette

[Aaron Wolf]

On 01/28/2017 07:03 AM, mray wrote:
> I'm not kidding: Maybe we go back to Nunito again after all!
> 
> Turns out Jacques Le Bailly not only extended Adam Vernons "Nunito"
> (Adam passed away 2016) to have proper italics and more weights, but
> there is also "Nunito Sans" a new version of Nunito without rounded
> terminals!
> 
> https://fonts.google.com/specimen/Nunito
> https://fonts.google.com/specimen/Nunito+Sans
> 
> This is awesome and opens an even wider space of solutions while
> sticking to our initial style!
> 
> Looking forward to mess around with those fonts...
> 
> 

Very nice! I really have such weak preference here, it should barely be
mentioned, but I did very much like Nunito except for the lack of
italics and such. I am *fully* happy to return to using that if you
choose to go that way. The updates look superb.

Nunito is a particularly balanced and readable font. The subtle
difference of squared-off vs rounded for the regular vs sans variety is
interesting. I notice strangely that the capital A and ÷ sign and some
others have lower bars in Sans for some reason.

In the end, I'm happy enough with anything that's readable and has all
the style variants.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

One extra thought about this process:

Although I'll aim to make audio that could stay as final, if the work on
the visuals somehow calls for minor tweaks in the script, it's not
absolutely set in stone. It's final now, and I hope to not change it,
but it's not literally impossible, of course.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

On 01/13/2017 01:48 PM, J.wuensch wrote:
> Guys, no need to start fighting here. The introduction video is a very
> important part of the snowdrift launch. We all know that, and I think we
> all agree, that Aron as a co-founder of the snowdrift project should
> have some influence on it.
> @ Aron. No need to worry. We will take your suggestions into account.
> The storyboarding notes that you have written to each section are a very
> good starting point. I think what mray is pointing out here is that we
> as artist just want to have a bit of creative freedom in the process of
> creating the video instead of getting constantly interrupted by endless
> discussions on the mailing list. Then, when we have something to show,
> we can discuss and review it together. We are used to critical reviews,
> so it's not the end of the world for us, if we have to change something.
> As far as I'm concerned I hadn't had the time till now to think about
> the visuals complementing the text. But this weekend and the next week I
> should find some time. If I have a complex idea that's a lot of work, I
> would of course first ask you, if it's suitable, so that we don't waste
> too much time on things that are not supposed to be in the video. But
> for small things I would prefer to just do them quickly and you can
> review and judge them later.
> And of course I'd be more happy to work with the audio instead the plain
> text... ;)
> 
> Cheers, Johannes
> 

Thanks for the thoughts Johannes! For reference, we just discussed this
on #snowdrift on freenode IRC a bit and came to the understanding that
this relates to the fact that I still haven't done my task of writing
out a clear communications policy, which I'll get to soon.

Please don't consider my suggestions just because they came from me.
Consider them only as far as they are useful as long as otherwise
following the general communications policy which I'll publish soon.

It's really important for this sort of community project that I am NOT a
benevolent dictator or otherwise deferred to just because I'm
co-founder. We're still getting comfortable with the Holacracy stuff
we're using to separate out accountabilities and roles.

Anyway, I'm going to prioritize the audio before I then get to the
communications policy.

After actually working on the video, if you *want* my input, you can
always ask. But Robert is the designer in charge of that process and
will work with you and others in the manner he prefers once he has what
he needs from me.

Cheers,
Aaron


> 
> Sent from ProtonMail <https://protonmail.ch>, encrypted email based in
> Switzerland.
> 
> 
>>  Original Message 
>> Subject: Re: [Snowdrift-design] new video script draft
>> Local Time: January 13, 2017 9:17 PM
>> UTC Time: January 13, 2017 8:17 PM
>> From: m...@mray.de
>> To: design@lists.snowdrift.coop
>>
>>
>>
>> On 13.01.2017 18:31, Aaron Wolf wrote:
>> > On 01/13/2017 01:53 AM, mray wrote:
>> >>
>> >>
>> >> On 11.01.2017 21:22, Aaron Wolf wrote:
>> >>> On 01/11/2017 11:57 AM, mray wrote:
>> >>>>
>> >>>>
>> >>>> On 11.01.2017 17:21, Aaron Wolf wrote:
>> >>>>>
>> >>>>> I already started a new thread to discuss the story-boarding. Do we
>> >>>>> really need the audio files before starting that storyboarding
>> process?
>> >>>>>
>> >>>>
>> >>>> Yes.
>> >>>>
>> >>>
>> >>> Please forgive my ignorance here. Can you explain why you need audio
>> >>> files instead of just the written text in order to do
>> storyboarding? It
>> >>> just makes no sense to me at all. I don't imagine that storyboards
>> >>> already need millisecond-to-millisecond timing notes or anything.
>> Don't
>> >>> we just start by drafting some images and ideas for what goes with the
>> >>> script?
>> >>>
>> >>> I can understand that having audio is nice, but a hard requirement
>> >>> before we start working on and discussing storyboarding. I really
>> don't
>> >>> get it.
>> >>>
>> >>
>> >> Imagine making a music-video with only having music sheets beforehand.
>> >> You *could* do it - but waiting for the recording is better.
>> >> I don't want to put pressure on you, but I guess recording a few takes
>> >> should be possible soon. Unless we have to wait very long I think
&

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

On 01/13/2017 01:53 AM, mray wrote:
> 
> 
> On 11.01.2017 21:22, Aaron Wolf wrote:
>> On 01/11/2017 11:57 AM, mray wrote:
>>>
>>>
>>> On 11.01.2017 17:21, Aaron Wolf wrote:
>>>>
>>>> I already started a new thread to discuss the story-boarding. Do we
>>>> really need the audio files before starting that storyboarding process?
>>>>
>>>
>>> Yes.
>>>
>>
>> Please forgive my ignorance here. Can you explain why you need audio
>> files instead of just the written text in order to do storyboarding? It
>> just makes no sense to me at all. I don't imagine that storyboards
>> already need millisecond-to-millisecond timing notes or anything. Don't
>> we just start by drafting some images and ideas for what goes with the
>> script?
>>
>> I can understand that having audio is nice, but a hard requirement
>> before we start working on and discussing storyboarding. I really don't
>> get it.
>>
> 
> Imagine making a music-video with only having music sheets beforehand.
> You *could* do it - but waiting for the recording is better.
> I don't want to put pressure on you, but I guess recording a few takes
> should be possible soon. Unless we have to wait very long I think
> waiting is worth it.
> 
> Concerning the next steps I don't plan to have a workflow that is
> remotely similar to the one of the script. I expect to work on this
> inside the design circle and seek acceptance/feedback when there are
> results to talk about.
> 


If I know the gist of some music, I could totally story-board, like make
plans for a music video just looking at lyrics. It would be no good to
actually make even the first draft of the actual video, but talking
about what types of scenes we'd have wouldn't require the recording of
the music. Generally sketching out a list of scenes in an order would
not be blocked.

But, yes, I'll get audio really soon.

And sure, it makes sense to work internally on things. But I have some
communication directives that I want included. The images that go with
the line about restrictions must include reference to *both* locks and
ads. The last line about clearing the path should hint at (i.e.
foreshadow) the snowdrift metaphor. And I want to emphasize the need for
reinforcing the general sense of cooperation and community.

In order to avoid domain conflicts, the best strategy is to run the
general ideas for what is being communicated by me, and then as long as
we're clear about the general messaging, it's your domain to determine
how to make the video express it best.







signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

On 01/12/2017 02:12 AM, J.wuensch wrote:
> @Aron
> I would prefer to work with the audio because I think I would rather go
> for an animatic than a classic storyboard. An animatic is a video where
> there are no final shots, but just rough animation together with the sound.
> 
> Btw, you said you already have started a new thread to discuss the
> story-boarding. Where can I find that thread? I think I didn't receive
> something through the mailing lists. And as far as I know snowdrift
> hasn't moved to Discourse yet. Is it on Taiga? Or is there something
> else I don't know of?
> 

I sent it to this very list we are chatting on. It's an email with the
subject "intro video storyboarding"

And in regards to audio etc. I want to proceed with discussing the basic
*ideas* about what will be in the story board in the mean time until I
get a chance to do a more final audio. We can discuss the basic concepts
and goals before starting to make actual storyboards.

Discourse is indeed not quite ready yet, getting close.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

On 01/11/2017 11:57 AM, mray wrote:
> 
> 
> On 11.01.2017 17:21, Aaron Wolf wrote:
>>
>> I already started a new thread to discuss the story-boarding. Do we
>> really need the audio files before starting that storyboarding process?
>>
> 
> Yes.
> 

Please forgive my ignorance here. Can you explain why you need audio
files instead of just the written text in order to do storyboarding? It
just makes no sense to me at all. I don't imagine that storyboards
already need millisecond-to-millisecond timing notes or anything. Don't
we just start by drafting some images and ideas for what goes with the
script?

I can understand that having audio is nice, but a hard requirement
before we start working on and discussing storyboarding. I really don't
get it.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

On 01/11/2017 03:34 AM, mray wrote:
> 
> On 11.01.2017 11:51, J.wuensch wrote:
>> Hello Mray,
>>
>> I'm also looking forward to work with you on the video soon. My twin 
>> brother, who worked on some VFX projects, too, would like to join the video 
>> team, if possible.
>> Would we then be three people? Or are there others interested in working on 
>> it, too?
>> Anyway, just let me know, when you have the audio files. Then we can meet on 
>> jitsi or irc and discuss the details and begin with storyboarding/animatic 
>> etc...
>>
>> Johannes
>>
>>
> 
> Awesome, I'll get in touch as soon as we have the files. Of course your
> brother can join! We are happy to welcome any helping hand. It looks
> like we would be the only ones with experience in producing video.
> Speaking of it – is there an easy way to get an impression of earlier work?
> 
> If I'm not mistaken you are in my timezone (UTC+1), this should simplify
> the meeting process somewhat :)
> 
> 
> -Robert

I already started a new thread to discuss the story-boarding. Do we
really need the audio files before starting that storyboarding process?




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] intro video storyboarding

[Aaron Wolf]

> 1. showing some symbols for music, code, writings getting copied rapidly
> and seen by tons of people (a la the end of Copying Is Not Theft)?
> 
> 2. I *really* want this line to show *both* some form of lock or paywall
> AND some obnoxious BUY NOW! type ad covering the music or writings. The
> key thing is to include ads, not only paywalls. It should be easy to
> just show a few things getting covered with some mix of locks and ads etc.
> 

To clarify this thought: it seems easy to show multiplying music, code,
and writings files spreading around and multiplying and then show the
same files getting slapped with locks and ads covering them, as if to
show the bountiful potential suddenly getting taken away and ruined. I
hope this text is enough to express the visual I have in my head (or
inspire a better visual in others' minds!)



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Snowdrift-design] intro video storyboarding

[Aaron Wolf]

We have a final script (at least to the point that we are treating it
final for moving to the next stage, but probably indeed final):


1. Things like software, music, journalism, and research *can* be public
goods, freely used and shared by *everyone*.

2. But instead, publishers typically add restrictions in order to secure
funding.

3. Meanwhile, projects releasing their work under free and open terms
struggle.

4. To build the widespread cooperation needed to solve this dilemma, we
developed a new fundraising method: crowdmatching.

5. You support a project by pledging to give a monthly donation of 1
cent for every 10 patrons who give with you.

6. In other words, a dollar per 1000 patrons. So, 5,000 patrons give 5
dollars each, bringing a project's monthly income to 25,000 dollars!

7. Pledges stay active as long as they fit within your overall budget
for the system.

8. Join Snowdrift.coop today, and help clear the path to a free and open
future!

---

And here's some preliminary thoughts to get the ball rolling on
storyboarding:

1. showing some symbols for music, code, writings getting copied rapidly
and seen by tons of people (a la the end of Copying Is Not Theft)?

2. I *really* want this line to show *both* some form of lock or paywall
AND some obnoxious BUY NOW! type ad covering the music or writings. The
key thing is to include ads, not only paywalls. It should be easy to
just show a few things getting covered with some mix of locks and ads etc.

3. Not sure…
4. not sure…
5. clearly some visual of penny per 10 patrons
6. show animation of quadratic growth, square with patrons increasing
horizontally, donation per patron increasing vertically
7. maybe Michael's idea of visualizing multiple projects fitting in a
box, could stay vague by not showing the over-budget scenario or hint at
the process by indicating a situation in which a project that grows
larger than the box turns greyed-out
8. Hinting at the snowdrift dilemma by showing a snowdrift blocking a
path and showing characters shoveling the snow with more and more
characters showing up with shovels to come help.

These are all just thoughts and suggestions for the most part, looking
forward to seeing others' ideas.

-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

On 01/09/2017 09:41 AM, J.wuensch wrote:
> Hey guys,
> All in all it's pretty good! But there is one thing I noticed when I
> read the text to other people. It's the "site-wide" budget in part 7
> that seems to be a bit confusing.
> 
> 7. And your pledges stay active as long as they fit within your
> site-wide budget.
> 
> I would replace "your site-wide budget" with "your defined monthly budget":
> 
> 7.  And your pledges stay active as long as they fit within your defined
> monthly budget.
> 
> Why: Firstly, I think no one will get, what you mean by a "site-wide
> budget". It's just to abstract. I read it to two people and they didn't
> get that part... How the mechanism of the budget is working should be
> easily clarified on the website later. I think for the video it's only
> important, that you know there is a budget limit that you can set
> yourself. If it's side-wite or not, is not important in the first
> place.  Secondly in this version it's more obvious that you can define
> the budget yourself. And thirdly, it's an additional hint, that
> snowdrift is about monthly payments. I know, there are already two, but
> as this is an important point I think it's ok to mention it again.
> 
> 

Thanks for the reply, but "your defined monthly budget" is absolutely
not going to work. It's FAR FAR better for people to say "site-wide
budget? How does that work?" than to have the WRONG idea "oh, I get to
set a cap for how much I give to each project".

We are NOT offering people to cap each project, we are giving them ONE
overall site-wide (or system-wide, there are other wordings for these
things) budget. If the total of *all* their pledges goes past their
limit, then the project that grew will be dropped until they decide to
drop others instead or to change their budget limit. We don't have time
to explain that, but we don't want anyone to have the wrong idea that
you can have a per-project budget.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

We're getting close!! We need to work on the last pre-sign-off line(s)
to solidify this thing.

I'm happy to suggest as a final draft for everything except the
second-to-last section.

SCRIPT:

1. Things like software, music, journalism, and research *can* be public
goods, freely used and shared by *everyone*.

2. But instead, publishers typically add restrictions in order to secure
funding.

3. Meanwhile, projects releasing their work under free and open terms
struggle.

4. To address this dilemma, we developed a new fundraising method we
call crowd**matching**.

5. Rather than donate alone, you pledge to make a monthly contribution
of 1 cent for every 10 patrons who give to the same project with you.

6. 1,000 patrons donating $1 is $1,000, but with 5,000 patrons at just
$5 each, a project would receive $25,000 a month!

7. ??? [see notes below; something mentioning budget (probably vague,
just giving idea that you can learn more reading the how-it-works page)
and emphasizing the positive qualities of the system as a whole]

8. Join Snowdrift.coop today, and help clear the path to a free and open
future!

---

Aaron's thoughts on 7:
* goal: an inspiring and informative vision of the system overall
* must mention budget
* avoid vague claims, buzzwords, marketing-speak in favor of factual
informative content
* the vision can emphasize any of:
* pledging to many projects
* only donating much to those that have buy-in from others /
those projects "people value most" (consensus, avoiding fragmentation /
a few successful projects is better than many failing ones)
* a budget where projects that get *too* popular get cut off
* no time here but ideal impression of how this mediates
runaway growth, and a popular project doesn't *directly* cause the drop
of another project
* you have control to stay on-board with a super popular project
by either (A) dropping others or (B) increasing your budget
* you can observe over time to favor those projects that make
the most impact (accountability)
* your pledges are part of inviting others to pledge
* providing sustainable, reliable salaries to project teams
* we only have time for some of these things
* "directs your budget to most-valued" ideas are misleading in that
it only applies *before* hitting your limit. At your limit, projects
that get popular will be dropped first.
*  To ensure people have a clear sense of budget or at least open
questions and not misunderstandings, these are the implications to avoid:
* wrong: you always give your whole budget
* wrong: you can always keep donating without passing your limit
(effectively reneging on the matching pledge)
* wrong: you can set a different budget for each project
* we have at most about 15 seconds for whatever best compromise of
these things we can achieve



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Reference -- UX of charities

[Aaron Wolf]

On 01/07/2017 05:17 AM, mray wrote:
>
>
> On 06.01.2017 13:21, Stephen Michel wrote:
> > It's not completely relevant to what we're doing, and we already do many of 
> > the things the article suggests, but it's a useful reference nonetheless.
> >
> > https://trackchanges.postlight.com/the-user-experience-of-giving-away-money-d087b986daa1#.n6ii3e37c
> >
>
> a good read, thanks!
>
I think we should probably add links like this to some sort of reference, maybe 
on the wiki…



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

I should clarify that the thing we now have that I like is the latest
update:

```
Things like software, music, movies, journalism, and research *can* be
public goods, freely used and shared by *everyone*.

But instead, publishers typically add restrictions in order to secure
funding. Meanwhile, projects releasing their work under free and open
terms struggle.

Our innovative crowd*matching* system provides a new way to generate
significant funding for public goods at little individual cost.

For each project you wish to support, you pledge to give a monthly
donation of 1 cent for every 10 patrons who donate with you.

And you control your budget by setting an overall limit for the system.

1,000 patrons donating $1 means $1,000, but with 5,000 patrons at just
$5 each, a project receives $25,000 a month!

*Matching* provides the necessary incentive to encourage more patrons to
join, and monthly donations hold projects accountable.

Join Snowdrift.coop today, and help clear the path to a free and open
future!
```

I don't love the 2nd-to-last line, but I like the meaning I was aiming
for better than the other messages we've had in the past.

Also, here's an attempt to synthesize some of the older and newer with
some additional new tweaks (not perfect, but I think from the ideas we
have now, we're close to a final version):


```
Things like software, music, movies, journalism, and research *can* be
public goods, freely used and shared by *everyone*.

But publishers typically add restrictions in order to secure funding.
Meanwhile, projects releasing their work under free and open terms struggle.

Our innovative crowd*matching* system provides a new way to bring people
together to fund public goods.

First, you set an overall monthly budget. Then, for each project you
wish to support, you pledge to donate a penny for every 10 patrons who
donate with you each month.

1,000 patrons donating $1 means $1,000, but with 5,000 patrons at just
$5 each, a project receives $25,000 a month!

*Matching* provides the mutual assurance to encourage more patrons to
join, while ongoing donations hold projects accountable.

Join Snowdrift.coop today, and help clear the path to a free and open
future!



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

On 12/26/2016 01:49 PM, mray wrote:
> I attach an older recording (2016-12-05) of the script.
> I'd like to not work on this the "e-mail" way if possible and hope there
> will be another meeting I can finally attend (sorry for missing the last
> ones!).
> 
> All in all I like the older one much better.
> 
> 

Thanks for sending that. Unfortunately, we still lost my other
intermediate version which never got captured in a live meeting, I don't
think.

Anyway, there are some aspects I like about the older script, but I
really prefer the new one in several respects. There are some aspects of
the old that are good and a synthesis of sorts is possible.

My schedule is pretty open at this point for further meetings in the
near future




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

On 12/24/2016 10:10 AM, Aaron Wolf wrote:

> Our innovative crowd*matching* system provides a new way to provide
> significant funding for public goods at little individual cost.

"provides a way to provide" ugh. I wrote too fast.

anyone else take a stab at wordsmithing this one line?



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Aaron Wolf]

On 12/23/2016 10:31 PM, Stephen Michel wrote:
> Additional thought: As we go through this, we need to think of what
> illustration we are going to pair with each segment.
> 

I'm not actually sure if we should do this coincidentally or
sequentially, but I see some arguments both ways. I did have some
thoughts as I mentioned.

>> PER-LINE NOTES (> is the script and * is commentary for line above):
>>
>> And you control your budget by setting a monthly limit for the
>> system overall. 
>>
> What's the pithy shorter version?
> 
One version:

First, you set an overall monthly budget limit. Then, [the stuff about
pledging]

Another:

Your donations are limited by your overall budget setting.

Another:

Your budget setting limits your overall monthly donations.

Another:

We only process pledges that stay within your monthly budget limit.

Overall, this sentence has *lots* of acceptable variations. I've not
come up with one I love and will bother really defending. But we *need*
some mention of budget limit and to clarify that it's overall and not
per-project. In my experience, about half of people do not assume
there's a cap and think we might just be crazy (and half assume there's
a cap and feel it doesn't need to be stated in a summary). We need it
included in some form. With the right illustration, it can be short and
pithy.

>> Join Snowdrift.coop today, and help clear the path to a free and
>> open future! 
>>
> I love this phrase. But I love it *because* I understand the snowdrift
> metaphor. This is someone's first exposure to snowdrift, and we haven't
> explained the metaphor yet; in this context, it's much less impactful.
> 

I agree it's not super impactful to those who don't know the metaphor,
but it hints at it. It provides an opening and continuity to reference
the snowdrift dilemma in later things. I.e. foreshadowing. I wrote and
like it knowing that it won't be immediately meaningful to everyone. The
vague idea of clearing obstacles / moving forward is still present.

> I'm concerned about the semantic flow of the middle, from an
> illustration perspective. We mention our crowdmatching system and its
> benefits (abstract), then give the specs, assuage fears with talk of a
> limit, more abstract benefits, and finally another example. I think if
> we combine the bits about "supporting public goods you care about" and
> "significant impact at little individual cost", and combine the parts
> with concrete numbers, we'll end up with something more concise and also
> easier to make visualizations for.
> 

If other people think it could work, I'm okay with removing most of the
"empowers…" sentence. Something really pithy like "Introducing our
innovative crowd*matching* system:"

There needs to be *some* transition from problem to solution. I agree
that having the sort of qualitative assertions on both sides of the
explanation is kinda split up and also longer than strictly necessary. I
would lean toward removing the "empowers… you care about" part if
necessary, although I kind of like it.

> I think that the part where we discuss setting a limit is ultimately
> unnecessary. We need the limit to make people feel comfortable pledging,
> not to sell the message of, "crowdmatching is the key reason that this
> is NEW and CAN actually do this! Believe!! Be inspired!" I think if the
> very next place someone looks on the site mentions the limit, that's
> sufficient.
> 
> Also, it's really hard to fit this sentence in without breaking the flow
> of those paragraphs.

I think it's not safe to have no limit mention, close to certain. But I
agree it doesn't lead well into the positive vision. Maybe the "First,
limit… pledge…" is the better order.

> NEW SCRIPT SHORT:
> 
> Things like software, music, movies, journalism, and research *can* be
> public goods, freely used and shared by *everyone*.
> 
> But instead, publishers typically add restrictions in order to secure
> funding. Meanwhile, projects releasing their work under free and open
> terms struggle.
> 
> Our innovative crowd*matching* system empowers you to join with
> others in supporting the public goods *you* care about, creating
> significant impact at little individual cost.
> 

Not bad, but the sentence is just too long.

> For each project you wish to support, you pledge to give a monthly
> donation of 1 cent for every 10 patrons who donate with you. 1,000
> patrons donating $1 means $1,000, but 5,000 patrons at just $5 each
> would give a project a $25,000 monthly income!
> 
> *Matching* provides the necessary incentive to encourage more patrons to
> join, and monthly donations hold projects accountable.
> 
> Join Snowdrift.coop today, and help fund public goods, together!
> ```

"help fund public goods, together" isn't very compelling and is
redundant. There's nothing *wrong* with the "clear the path" message
even if it's not something people immediately associate with the
snowdrift dilemma.

>> For each project you wish to support,

[Snowdrift-design] new video script draft

[Aaron Wolf]

efore. Instead of emphasizing how
neat the qualities of our system are, the point is to say: "we KNOW it's
always been true that tons of people could just donate, but they don't,
and we won't get into freeriding and explaining the dilemmas here but
there's a real reason why THIS is different and has hope to actually
achieve something where everything else is failing (i.e. MATCHING)".
Now, the "accountable" part is a little more superfluous compared to the
all-important matching emphasis, but I liked how it paired up. Anyway, I
imagine this could be a place to show a network-effect illustration
perhaps. I thought about repeating the term "crowdmatching" instead of
matching, but it didn't feel as good in context. I don't think we can
get it in, but the feeling I wish people would have is that this sort of
network-effect, crowdmatching, many-to-many matching really is a new
sense of things. If we used the network-effect illustration earlier,
another illustration here could be the button showing the idea of when
you pledge, everyone else gives more… but what matters really is the
message of "crowdmatching is the key reason that this is NEW and CAN
actually do this! Believe!! Be inspired!"

> Join Snowdrift.coop today, and help clear the path to a free and open
> future!

* This fit as a better place to mention the site again, and we can then
tie in the snowdrift dilemma with an illustration showing characters
coming to join together and shovel snow.

CONCLUSION: I'm happy with the semantic flow of everything and happy
enough with the wording of all of this. I always love when someone gives
feedback I see as even greater improvement. I wish this were a bit
shorter but also don't want to lose any element.

We could go back and compare this to other drafts, but this is the first
one that I feel is fully effective all the way through and as a complete
unit.

Cheers,
Aaron


-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] delete "/design/site-design" wiki page

[Aaron Wolf]

On 12/06/2016 05:33 AM, mray wrote:
> I'd like to delete this page:
> 
> https://wiki.snowdrift.coop/design/site-design
> * it is outdated
> * it contains self-evident and irrelevant information
> 
> Are there objections?
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 

Lets just move it to https://wiki.snowdrift.coop/archives/ so we don't
have to think about it much or deal with whether to retain any bits of
it at this time.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Font-Weight

[Aaron Wolf]

On 12/07/2016 06:34 AM, mray wrote:
> Looking at the web rendered font makes me believe that on our mainly
> white background the lighter cut of Rubik makes more sense as a the
> default font. The downside to me seems that we would have to up the font
> size a bit - and with it the line height, which should serve as the base
> for the grid.
> 
> Anybody has opinions on that?
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 
I'd have to actually see it, but increased font size and spacing might
be fine, no objections to the idea.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Intro video script

[Aaron Wolf]

After all the chat yesterday, we brainstormed a lot of things. I'm still
not satisfied with the final result, but much of it is done. My notes at
this point. Where I marked "FINAL", there shall be no further discussion
(unless changes to those lines are forced to happen because of changes
to the non-final lines). Note: I changed the numbers from those at
https://pad.riseup.net/p/Fo9LxmtDZcua in order to consolidate for this
email. I hope that's not too confusing. I'm basically rejecting anything
from the pad that isn't here.

FINAL 1. "Things like software, music, movies, journalism, and research
*can* be released as public goods."

FINAL 2. "Then, *everyone* may use and share them freely, without
limitations."

FINAL 3. "But who will fund their production?"

tentative 4a. "Our innovative platform empowers you to join with others
to fund the public goods /you/ care about."

tentative 4b. "At Snowdrift.coop, you collaborate with others to build
greater support for public goods."

I'm not happy with either 4, but the meaning I want to say here is:
Snowdrift.coop (or "out platform" or similar subject) is about getting
everyone to collaborate to address question just asked (i.e. to fund
public goods). It's nice to emphasize that the users get to choose, but
not sure that needs to be in 4. The only core thing is THIS (our
platform) is for collaborative funding of public goods. Still need best
wording for that.


tentative 5a. "You do this with a simple pledge to the projects you care
about: 'I'll donate $1 for every 1,000 patrons who pledge with me!' And
you control your overall pledges by setting a monthly budget limit for
the system."

tentative 5b. same as 5a but "a tenth of a cent for every patron…"
instead of the $1 / 1000 version

We had played with phrases like "donate a tiny amount for *each* patron
who supports the same projects" but I'm leaning toward just using
concrete example of the proposed actual pledge amount. That makes it far
easier for people to get the actual pledge instead of us hinting at
something while people wonder what it really is.

As for the budget part, similarly for being concrete, I'd rather go in
the *direction* of stating explicitly what happens. Something like "you
set a monthly budget limit, so a pledge that would go beyond your budget
gets automatically put on hold." Except that brings up all sorts of
questions, so we can't say all that. But I want to at least hint at the
clarity that you don't just hit a per-project budget and then stop
matching (because people who think that and then experience otherwise
will be annoyed with us more than if we give them the right idea from
the get-go).

One bit we had that I like for consideration still: "You choose projects
to support, and make a pledge…"

tentative 6a. "We call this "crowdmatching", and with this system, our
support grows together and is directed towards the most promising projects."

tentative 6b. "This process, which we call *crowdmatching*, builds
consensus and directs support to the most promising projects."

tentative 6c. This *crowdmatching* approach means that all the patrons
of a project reinforce each other, and it naturally builds consensus,
directing our support to the most promising projects."

6c is longer and wordier, but I like the feel and it really draws out
the feel and meaning the right way to me.

FINAL 7. Join us in clearing the path to a free and open future!

Note: We can *maybe* tweak the FINAL lines before the actual production
is done but I don't want to discuss them until all lines are in the same
candidate-for-final state.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Intro video script

[Aaron Wolf]

Quick note: glad to see everyone weighing in. I plan to think through
this soon and consolidate ideas.

In short: I don't like losing the snowdrift dilemma concept entirely,
but I think it's the right direction. We'll keep "clearing the path…"
which can be illustrated with snowdrift / road visuals. This is all
about hinting about ideas that will be explained more later.

We really need to embrace "public goods" without hesitation, and we'd
rather people say "what qualifies as public goods?" or even "what are
public goods?" than that they get confused with the wrong impressions.
I'd rather viewers leave the video with questions and motivation to find
answers than that they leave the video thinking they understand things
fully (since they won't actually). If it's too vague, viewers won't feel
respected or that they even have clear enough questions, but it's good
for them to think they got the *general* idea but have questions.

Again, I'll weigh in with some further thoughts and another script draft
soon.

Nobody needs to stop discussing and wait for me though, just wanted to
mention these thoughts briefly.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Intro video script

[Aaron Wolf]

On 11/25/2016 01:28 AM, J.wuensch wrote:
> "This public goods problem can also apply to music, software, movies,
> news, research, and so on…"
> 
> I'm with mray. I think it would be good to put "free" in there. Because
> that's what snowdrift.coop is all about. To support the people that
> create stuff which is freely available to everyone. Like the sentence is
> now, the "public" is clearly related to the "problem" and not
> necessarily to music, software and so on... Of course one can make that
> connection, but it's not said, that everyone will get it that quick. I 
> mean maybe they never had anything to do with this stuff and hear all
> that for the first time.
> I just think it's important to emphasize what we want to support. Yes,
> the word "free" can be a bit confusing, but as you already said, it gets
> further explained on the homepage, so I think it's ok to go here with
> "free".  Maybe even mention the support for the creators and the
> distribution on the supporters, because that's essentially what this
> platform is going to organize. I've done it with two questions that
> should help to make it not too abstract. We should keep in mind that
> none of the people out there has ever heard crowdmatching and thus it's
> kind of abstract. I remember when I first stumbled across snowdrift.coop
> there was that word crowdmatching and I didn't really get what it was
> about. I took me a while to get the concept.
> 
> So here is my suggestion. It's a bit longer but for me it's important
> and I think it's worth the extra seconds:
> 
> This public goods problem can also apply to freely available music,
> software, movies,
> news, research, and so on…  But how to support those creators in a
> sustainable way? And how do we fairly distribute the donations across
> the supporters?
> 
> That's why we developed
> 
> So that's my feedback. All in all I like it! Good Job Aron!
> 

I like the idea, but I still lean against putting in these qualifiers
into the script. I'm just not going to be happy with the partial,
inadequate clarification. And we're definitely going to go over the 45
second mark with those extra questions. I think that has to wait for a
longer video.

Maybe the visuals can help? We could put the text "free/libre/open" and
creative-commons logos and GNU logos and such in the video when we talk
about the categories of public goods… thoughts?

> cheers,
> Johannes
> 
> 
> Sent from ProtonMail <https://protonmail.ch>, encrypted email based in
> Switzerland.
> 
> 
>>  Original Message ----
>> Subject: Re: [Snowdrift-design] Intro video script
>> Local Time: November 24, 2016 10:20 PM
>> UTC Time: November 24, 2016 9:20 PM
>> From: aa...@snowdrift.coop
>> To: design@lists.snowdrift.coop
>>
>> n 11/24/2016 12:06 PM, mray wrote:
>> >
>> >
>> > On 24.11.2016 20:46, Aaron Wolf wrote:
>> >> SCRIPT2B/
>> >>
>> >> The snowdrift dilemma: Whether or not we help, we all benefit from
>> >> clearing the public road. So, who will do the work?
>> >
>> > We actually benefit from a clear road - not from its clearing.
>> >
>>
>> Okay, rewrote to:
>>
>> "The snowdrift dilemma: Regardless of who clears the snow, we all
>> benefit. So, who will do the work?"
>>
>> That's shorter and more precise too. More obvious that the snowdrift is
>> the thing to clear.
>>
>> >>
>> >> This public goods problem can also apply to music, software, movies,
>> >> news, research, and so on…
>> >
>> > You are juggling concepts here, in the midst of all this it is not clear
>> > at all that you are talking about "public music", "public software",
>> 
>> >
>> > Are you sure there is no time to throw in the word "free" ?
>> >
>>
>> I think "free" without "free/libre/open" is confusing, "free/libre/open"
>> is jargonny, and "free and open" emphasizes the misinterpretation of
>> "free" as "gratis".
>>
>> I think "public music" is true but not needed to be said in a sentence
>> that already references public goods. We're saying "it CAN apply" and
>> will say outside of the video that it applies only in the case of true
>> public music i.e. free/libre/open that is also of the caliber that it
>> requires serious investment. We can't get into it her

Re: [Snowdrift-design] Intro video script

[Aaron Wolf]

 n 11/24/2016 12:06 PM, mray wrote:
> 
> 
> On 24.11.2016 20:46, Aaron Wolf wrote:
>> SCRIPT2B/
>>
>> The snowdrift dilemma: Whether or not we help, we all benefit from
>> clearing the public road. So, who will do the work?
> 
> We actually benefit from a clear road - not from its clearing.
> 

Okay, rewrote to:

"The snowdrift dilemma: Regardless of who clears the snow, we all
benefit. So, who will do the work?"

That's shorter and more precise too. More obvious that the snowdrift is
the thing to clear.

>>
>> This public goods problem can also apply to music, software, movies,
>> news, research, and so on…
> 
> You are juggling concepts here, in the midst of all this it is not clear
> at all that you are talking about "public music", "public software", 
> 
> Are you sure there is no time to throw in the word "free" ?
> 

I think "free" without "free/libre/open" is confusing, "free/libre/open"
is jargonny, and "free and open" emphasizes the misinterpretation of
"free" as "gratis".

I think "public music" is true but not needed to be said in a sentence
that already references public goods. We're saying "it CAN apply" and
will say outside of the video that it applies only in the case of true
public music i.e. free/libre/open that is also of the caliber that it
requires serious investment. We can't get into it here. We're just
saying "this is about public goods, and keep in mind these categories of
works"

>>
>> That's why we developed crowdmatching!
>>
>> At Snowdrift.coop, you pledge to donate a little bit for each patron who
>> supports a project with you. We calculate donations monthly based on the
>> numbers of patrons and your budget limit.
>>
>> This way, each donation is matched by the rest of the community, and we
>> build consensus around the most promising projects.
>>
>> Come join us in clearing the path to a free and open future!
>>
>> /SCRIPT2B
> 
> 
> looks great. getting curious where and how you choose to emphasize the
> sentences :D
> 
> 

With the updated first line:

SCRIPT2C/

The snowdrift dilemma: Regardless of who clears the snow, we all
benefit. So, who will do the work?

This public goods problem can also apply to music, software, movies,
news, research, and so on…

That's why we developed crowdmatching!

At Snowdrift.coop, you pledge to donate a little bit for each patron who
supports a project with you. We calculate donations monthly based on the
numbers of patrons and your budget limit.

This way, each donation is matched by the rest of the community, and we
build consensus around the most promising projects.

Come join us in clearing the path to a free and open future!

/SCRIPT2C

We can see if others have further feedback, but I think we should
already start storyboarding with this.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Intro video script

[Aaron Wolf]

On 11/24/2016 11:47 AM, Bryan Richter wrote:
> On Thu, Nov 24, 2016 at 08:10:47AM -0500, Stephen Michel wrote:
>>
>> On November 24, 2016 4:52:08 AM EST, mray wrote:
>>>
>>> Unrelated to the above we may want to note that we are a non-profit
>>> coop. It can be a short mention but it would adds a lot to the
>>> credibility. - Maybe even set that straight right from the start so
>>> it does suppress peoples thoughts about our "business model" behind
>>> all this while they watch? Or put it in the end and together with
>>> naming our name and slogan?
>>
>> No opinion.
> 
> We can't do this, because we aren't a non-profit, nor are we a co-op.
> Those are outstanding goals. And after talking to an expert at SeaGL,
> I sort of get the feeling they require a lot of rework to become
> achievable.

I agree with the concern, but you seem to be misunderstanding the legal
status. We are incorporated as a non-profit in the state of Michigan
currently. Whether we reincorporate or otherwise deal with our situation
in other regards is a challenging issue. To some extent, we have OSI as
a fiscal sponsor, but that's complex.

But please be completely clear: 501(c)(3) is not the definition of
"non-profit". Non-profit is a STATE-level designation, and we did indeed
file Articles under that designation. But since we're still forming, our
status is in a legally uncomfortable situation to be clear. We need to
finalize our structure and get legal help on getting it all in place.

Are we a co-op? Well, we did file articles expressing our intention and
our name as a co-op. Do we operate as a co-op? Sorta not really in that
we don't have our bylaws in place. That doesn't make us a non-co-op in
that we are something other than a co-op. We are a co-op in progress, a
group of volunteers and contractors working on building a co-op.

The legally safe wording is stuff like "we're building a non-profit
co-op" as opposed to "we are a non-profit co-op".

There's no RE-work to achieve our legal goals, there's just WORK because
we didn't put in place anything bad that sets us up against these goals,
we are just lacking having the necessary things fully in place, period.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Intro video script

[Aaron Wolf]

Minor tweak (and cleaned up the long quotes)

SCRIPT2B/

The snowdrift dilemma: Whether or not we help, we all benefit from
clearing the public road. So, who will do the work?

This public goods problem can also apply to music, software, movies,
news, research, and so on…

That's why we developed crowdmatching!

At Snowdrift.coop, you pledge to donate a little bit for each patron who
supports a project with you. We calculate donations monthly based on the
numbers of patrons and your budget limit.

This way, each donation is matched by the rest of the community, and we
build consensus around the most promising projects.

Come join us in clearing the path to a free and open future!

/SCRIPT2B



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Intro video script

[Aaron Wolf]

On 11/24/2016 01:52 AM, mray wrote:
> 
> Thank you Aaron!
> I like the script.
> 
> 
>> The snowdrift dilemma asks: who will clear the public road when we all
>> get the results whether or not we help?
> 
> * "get the results" sounds very neutral. "benefit from it" would a
> positive connotation to what we are about.
> 

Agreed

> 
>> The same issue applies to funding public goods such as music, software,
>> movies, news, research, and so on…
> 
> * music only *can* be an example. I think we need to say that free
> music, free software... are examples of public goods.
> 

Right, that was in the longer scripts, but I figured out that I can use
a certain inflection in the audio to imply this somewhat. It's not
perfect, but thought about the middle ground of "public goods which can
include…"

I want to not take any time to clarify that roads, music, software MAY
be public goods but not necessarily. We just don't have time to clarify
any of that.

Here's my proposal now: "This public goods problem can also apply to
music, software, movies, news, research, and so on…"

> 
>> So, Snowdrift.coop helps coordinate everyone with our new crowdmatching
>> system!
> 
> * "So" is a place-filler and could be omitted.
> 

Nope, it's too jarring without a transition. It could be "But we have a
solution…" or "To address this," or that sort of thing, and "So," is the
shortest possible of that. There must be some transition from "problem!"
to "solution!" that indicates that we aren't still describing the
problem. Otherwise, listeners have to reevaluate the sentence part-way
through when they realize this is now talking about the solution. In
this context, "So," is not in any sense filler, just like the word
"like" is a meaningful word even though some people use it as filler. I
could try alternatives to "So," but they will all be longer.

> * "helps" suggests we only do part of the all, but since every
> participant is part of "us" that isn't true. We *DO* coordinate, we
> don't just help. Let's omit "help" therefore, too.

I'm okay removing "help" here, but for reference, the intent was to
avoid claiming that we necessarily succeed at full coordination of everyone.

> 
> * I feel awkward about calling it "our crowdmatching". We should
> fundamentally claim the term and only call it "crowdmatching".
> "Our" suggests there might be other crowdmatchings.
> 

I had to completely rewrite that section in order to not have that
element, but I agree with the concern.

> 
>> You just pledge to donate a little bit for each patron who supports a
>> project with you. We calculate donations monthly based on the numbers of
>> patrons and your budget limit.
> 
> * "just" in an explanation from a biased source almost never turns out
> to be true. "just click here" to "just compile the code" and other
> variations have conditioned me strongly. To me it is a promise but
> rarely delivers. Even when it fits it's still loaded. And this one is no
> exception :P
> 
> In this case it is a misleading combination of "just ... a little bit"
> when we actually describe a system that is designed to be a "controlled
> thermonuclear donation chain reaction". XD

agreed

> 
> Maybe start with introducing the limit first to not have to tip toe
> around the frightening money part?

I don't want to emphasize that because (A) we don't even have the limit
functioning yet! and (B) the limit isn't really the point, I just want
it included so people don't wonder if it exists.
> 
> 
>> This way, each donation is matched by the rest of the community, and we
>> build consensus around the most promising projects.
> 
> * Consensus is built indirectly, we shouldn't let people suggest
> somebody is directly involved in creating consensus. So a passive form
> like "consensus gets built" might fit better.
> 

I agree with the sentiment, but passive voice just sounds bad here to me.

> 
>> Come join us in clearing the path to a free and open future!
> 
> * I want to nit pick on every part so I have to write something here,
> too. Done.
> 
> 
> 
> I like it.
> 
> 
> Unrelated to the above we may want to note that we are a non-profit
> coop. It can be a short mention but it would adds a lot to the
> credibility. - Maybe even set that straight right from the start so it
> does suppress peoples thoughts about our "business model" behind all
> this while they watch? Or put it in the end and together with naming our
> name and slogan?
> 
> 

I wish we could do that, but our legal status isn't set in stone, so
it's best if we not try too hard at this. I do respect that emphasizing
that this is a FLO community project and not a VC-backed exploitation
system is a BIG deal though…

I thought about "Come join our non-profit co-op and us help clear the
path to a free and open future!" but it seems crammed in there still.

I think we'll have to signal our non-profit and community focus in other
places and not try to have it in the video besides the .coop domain.

So, here's where I'm a

[Snowdrift-design] Intro video script

[Aaron Wolf]

Okay, so we clarified a little while back that the first video to make
and to use for the home page should be a simple teaser that just says
"hi" and gives people the sense of the core idea and the topic of the
website. We can later make other videos that actually explain things.
Those other videos and/or illustrated pages / writings etc. will be
extremely important to get right, and I might push for those to follow
the gist of my original script when I thought the only video was to be a
1-2 minute full explanation.

For now, here's my draft of the under-45-second teaser intro. Please
give me feedback ASAP, and as soon as we're solid, we can start
storyboarding, and I'll record the audio.

SCRIPT:

The snowdrift dilemma asks: who will clear the public road when we all
get the results whether or not we help?

The same issue applies to funding public goods such as music, software,
movies, news, research, and so on…

So, Snowdrift.coop helps coordinate everyone with our new crowdmatching
system!

You just pledge to donate a little bit for each patron who supports a
projectwith you. We calculate donations monthly based on the numbers of
patrons and your budget limit.

This way, each donation is matched by the rest of the community, and we
build consensus around the most promising projects.

Come join us in clearing the path to a free and open future!


/SCRIPT


-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] joining the team

[Aaron Wolf]

On 11/11/2016 06:26 PM, Iko wrote:
> 
> On 11/11/16 04:49 PM, J.wuensch wrote:
>> Hello,
>> I'm Johannes from Germany. I used to work as a visual effects artist
>> and would be happy to join the design team in order to support the
>> whole snowdrift idea. I use open source where I can, that's why my
>> main tools which I'm using are Blender, Natron, Kdenlive and Krita.
>> I've never really done Character Animation or a cartoon like
>> animation, as I was more into the realistic stuff. So this would
>> probably be new for me, too, but I like challenges and perhaps I can
>> make a valuable contribution to the project. At least I can try.
>>
>> Happy to hearing from you,
>> Johannes
>>
>> Sent from ProtonMail , encrypted email based in
>> Switzerland.
>>
>>
> 
> Hello Johannes,
> 
> Thanks for your interest in the project!
> 
> There has been discussion recently about creating animated videos for
> the site's landing and how-it-works pages. We could probably use some
> help with the video production, if it's something you'd be interested in
> doing? Our design lead, mray, would be the best person to speak with for
> more details.
> 
> Here is the latest version of the narrator script for the landing page
> video:
> https://wiki.snowdrift.coop/governance/meetings/2016/2016-11-07-meeting#intro-video-script
> 
Just to clarify: I am tasked with writing a new script now that it was
made clear that the scope I had in mind originally should go on the
how-it-works page and the landing-page video will be something much more
brief that only hints at things and doesn't try to explain all the key
items.

I just got back from traveling and hope to get to the updated script ASAP.


> Let us know if you have any ideas or questions. Welcome!
> 



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

I think iterating on a video is not crazy. If we make a story-board as a
necessary step to a video, we definitely should iterate on that before
the video is made, but we need to be willing to make an acceptable video
with the knowledge we may reuse some of the ideas and assets in creating
a later updated video.

Anyway, with short time frame, I don't want to draw out debate here
forever. Perfect is enemy of good, etc. I want to move forward. I like
the script as is. I'm not going to refuse entirely to discuss, but I
want to get a sense from everyone involved that we all embrace and
accept the "perfect is enemy of good" concern and not nit-pick too much
(which does mean also that I shouldn't fight too damn hard to block an
edit that is okay and can let us go forward, but I will ask for some
deference here in my part of determining the messaging).

Attached is updated file with replies to the comments.


new-intro-video-script_shortened.odt
Description: application/vnd.oasis.opendocument.text


signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

NEW SCRIPT AND AUDIO:

http://snowdrift.sylphs.net/f/5619d755c8/?raw=1
http://snowdrift.sylphs.net/f/48e7fb3416/?raw=1

This only has a minor negative note contrasting against threshold
campaigns and no reference to the deeper wonky stuff or to the awfulness
of club goods.

I spoke slower. I could do more takes with tons of different vocal
qualities or attitudes, but there's no time. This reasonably upbeat,
superficial intro is what we've got.

Let's make a video and iterate from here!

Feedback welcome, but I probably won't find time to really work on
updating this soon, and we need to push something workable out ASAP.

Cheers,
Aaron



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

On 10/19/2016 02:22 PM, mray wrote:
> 
> 
> On 19.10.2016 22:56, Aaron Wolf wrote:
>> On 10/19/2016 01:25 PM, mray wrote:
>>>
>>> You are partially misrepresenting my point here.
>>> I agree that time, money, attention are limited resources.
>>> I reject that they have to be spend either one *OR* the other way:
>>>
>>> One can pay for Photoshop but also donate to Gimp. An increased Adobe
>>> market share is bad for GIMP but a better funded GIMP poses a bigger
>>> threat to Adobes dominance. It cuts both ways DESPITE mutual influence.
>>> You can go both ways at the same time.
>>>
>>
>> I think the easiest way to clarify is: they are RIVALS, as in time,
>> money, attention are *rivalrous* resources. There is a competition for
>> these things and they *can* be in a state where giving them to one
>> project removes them from the others even though you're right it's not
>> *necessarily* at that point.
> 
> This is my whole point. The exclusiveness you attribute to the choice
> isn't realistic.
> 

I wasn't attributing exclusiveness, that wasn't my intent. I was
attributing rivalrousness, which is real. Unless you're rich, you have
some limit to your budget and everyone has limited attention. Most
people cannot afford to pay hundreds of dollars regularly for
proprietary software licenses *and* donate hundreds of dollars to FLO
software. There's some limit here, some competition.

Besides, every dollar that funds another bit of work on some proprietary
project helps it win market-share over FLO rivals. So, in the
competition for market-share (which is admittedly not always zero-sum if
the market itself grows), *depriving* the proprietary project is helpful
just as funding the FLO project is.

This rivalrousness is the point, and people do face this sort of dilemma
in that the cost of engaging with both options is a higher total cost.


>>
>> Similarly, projects at Snowdrift.coop are in some competition for these
>> same rivalrous resources of time, money, attention. As we've discussed
>> in the past, there is no *need* for some projects at Snowdrift.coop to
>> fail in order for others to succeed, but there *is* a rivalrousness here
>> where we *do* accept and even celebrate the way crowdmatching helps
>> allocate resources when they do reach the state of being in direct
>> competition.
>>
>> I want to express somewhere (not in the video) that there *is* a dilemma
>> of how to allocate these rivalrous resources where the public benefit
>> comes from maximizing the support of public goods where individual
>> benefit may come from paying tolls and attention to the well-funded club
>> goods (but doing so takes rivalrous resources that then leaves less
>> potential available for public goods)
> 
> As long as you keep the two dilemmas separate, nice and tidy there is no
> issue for me.
> 

I agree, there needs to be absolutely no room for confusion about what
"the snowdrift dilemma" is. The other club vs public option dilemma is a
related but distinct dilemma.

>>
>>>
>>>>
>>>> In the end, I still want to and *will* spread the message that club
>>>> goods are a tragedy, the toll-road choice itself means someone doesn't
>>>> freeride on the public road but *is* avoiding the public road and still
>>>> not helping. You cannot drive on both roads at once (or have one road be
>>>> in both states at once).
>>>
>>> You can drive on both roads at once. See above.
>>>
>>
>> No, you literally cannot drive on two roads at the same time. You can
>> use them both at different times, but you cannot drive on two roads at
>> once, that is just not possible.
> 
> Exactly. That is the point where I think the roads metaphor falls short
> when using it in both dilemmas.
> 

It doesn't fall apart. Like I said with movies: you only watch one movie
at a time. You only use one road at a time. It's as appropriate as a
metaphor can be, i.e. imperfect.

>>
>> Although it doesn't map perfectly to every situation, the two roads
>> dilemma does highlight the rivalrousness that is real. You do not watch
>> two movies at the same time. Or if you do, you have divided attention.
>> You have limited attention, and giving it to one movie at a particular
>> time means less available for a different movie. I can't imagine anyone
>> sincerely disagreeing with that assertion.
>>
>>>>
>>>
>>> I think A. is much better.
>>> 1. It is simple short and easy.
>>> 2. We convince with what is go

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

On 10/19/2016 01:25 PM, mray wrote:
> 
> You are partially misrepresenting my point here.
> I agree that time, money, attention are limited resources.
> I reject that they have to be spend either one *OR* the other way:
> 
> One can pay for Photoshop but also donate to Gimp. An increased Adobe
> market share is bad for GIMP but a better funded GIMP poses a bigger
> threat to Adobes dominance. It cuts both ways DESPITE mutual influence.
> You can go both ways at the same time.
> 

I think the easiest way to clarify is: they are RIVALS, as in time,
money, attention are *rivalrous* resources. There is a competition for
these things and they *can* be in a state where giving them to one
project removes them from the others even though you're right it's not
*necessarily* at that point.

Similarly, projects at Snowdrift.coop are in some competition for these
same rivalrous resources of time, money, attention. As we've discussed
in the past, there is no *need* for some projects at Snowdrift.coop to
fail in order for others to succeed, but there *is* a rivalrousness here
where we *do* accept and even celebrate the way crowdmatching helps
allocate resources when they do reach the state of being in direct
competition.

I want to express somewhere (not in the video) that there *is* a dilemma
of how to allocate these rivalrous resources where the public benefit
comes from maximizing the support of public goods where individual
benefit may come from paying tolls and attention to the well-funded club
goods (but doing so takes rivalrous resources that then leaves less
potential available for public goods)

> 
>>
>> In the end, I still want to and *will* spread the message that club
>> goods are a tragedy, the toll-road choice itself means someone doesn't
>> freeride on the public road but *is* avoiding the public road and still
>> not helping. You cannot drive on both roads at once (or have one road be
>> in both states at once).
> 
> You can drive on both roads at once. See above.
> 

No, you literally cannot drive on two roads at the same time. You can
use them both at different times, but you cannot drive on two roads at
once, that is just not possible.

Although it doesn't map perfectly to every situation, the two roads
dilemma does highlight the rivalrousness that is real. You do not watch
two movies at the same time. Or if you do, you have divided attention.
You have limited attention, and giving it to one movie at a particular
time means less available for a different movie. I can't imagine anyone
sincerely disagreeing with that assertion.

>>
> 
> I think A. is much better.
> 1. It is simple short and easy.
> 2. We convince with what is good about us, not by what is bad about others.
> 

This is the core issue. I'm pretty convinced that A is better for right
now and for this video. I'm 100% convinced that A is acceptable in any case.

I still want B to be available, I will describe B somewhere sometime in
some writing or such. I think B is more compelling in the fundamental
way that "I fucking hate those sleazy ads!" is compelling. But it is
divisive.

To use a different metaphor, A is like me saying "there's some nice
aspects to co-ops, but here's some challenges and ideas that co-ops face
(that don't apply to other businesses)". B is like me saying "co-ops are
ethical and just, typical capitalist businesses where an owner dictates
terms to the workers and clients have ethical problems X, Y, Z, and they
shouldn't exist, we should only have co-ops."

To apply that to a strong example: A: "we built a co-op taxi service
that uses a FLO app to increase efficiency and work in a more reliable
way than traditional taxis!" versus B. "GPS and software organizing taxi
service is superb, but Uber getting an effective monopoly with lock-in
and dictated top-down terms is awful, That's why we built this co-op
version of that sort of service; and we all should work to support this
ethical vision and reject Uber!"

I see why there are good arguments for going with A, but people *should*
recognize and experience the B argument, and it's a view I happen to hold.

At any rate, I insist that we accept and welcome B for at least
something to have available in our arsenal and for whenever we get
questions that are best answered by B. It's the stronger way to insist
that what we're doing *really* matters (because club goods are NOT
OKAY). But for the video, we need to stick with A. A is also safer
because it is less divisive (and it's simpler).




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

Okay, the reply below is the unedited reply for now. I hope it's clear
enough. I haven't had time to write the clear new thread I want to get
to soon.


> That seems like an effective concise way to refer to the snowdrift. I
> think it also needs to point out the problem of whether the work will
> get done at all, though. Also, a problem I see with saying "Other public
> goods include music, software..." is that in our current world these
> things are typically /not /public goods because of how they're
> licensed.  I'm wondering if, for the sake of clarity, albeit at the
> expense of simplicity, we should specify "free and open music,
> software..." or something like that?  For example:
> 

Yes, that exact concern is the heart of the whole presentation challenge.

Put simply (this is largely what I intend(ed) to post separate thread on):

Club goods are a tragedy. The messaging is easiest if we ignore club
goods and specify that we're only focused on public goods. But if we do
mention club goods (which may actually be the most compelling and
important thing to get people concerned about), do we say "within
non-rivalrous goods, there's club goods and public goods, and the
snowdrift dilemma only applies to public goods" OR do we say
"non-rivalrous goods are *naturally* public goods and so face the
snowdrift dilemma, and because of the dilemma we get stuck with the
tragedy of mainly club goods"?

Effectively:

A. within broad scope of works to fund at all, we show how we're
narrowed down to public goods (*FLO* music and software) and *that*
scope brings up snowdrift dilemma, plain and simple. Elsewhere, we can
describe why it *matters* to support public goods over club goods.

or

B. treat club goods as non-existent in terms of natural states of
resources, assume all non-rivalrous stuff faces snowdrift dilemma and
describe the negatives of club goods as an abortion from the failure to
solve the snowdrift dilemma (which, though simplistic, has basis in
reality).

B is what I had been doing. It gets stronger at the assertion that club
goods are themselves a tragic problem. I also want to assert that all
support of club goods undermines the promotion of public goods and thus
we have a second type of dilemma: Use your limited resources to pay
tolls or donate to public goods, and there's a logical matrix for that
dilemma.

In that approach with B, I'm saying that, indeed the dilemma users at
Snowdrift.coop face isn't just to donate or not to FLO public goods,
it's whether to reject proprietary stuff so as to not help it keep
out-competing the FLO public goods.

I think the legitimate part of Robert's complaints is that B means
presenting two related dilemmas instead of a single clear snowdrift dilemma.

The reason I prefer B is because it gives no inherent legitimacy to club
goods at all. If we do A and just acknowledge that club goods and public
goods are the two categories of non-rivalrous goods and that the
snowdrift dilemma and snowdrift.coop are just about the public goods…
well, that's simple and clear but implies that club goods are a
legitimate category that inherently exists.

Practically speaking, many people will respond in ways we want to the
assertion that all club goods *should* become public goods, the club
goods category deserves no legitimacy. But there are certainly lots of
people who currently believe without question that both categories are
legitimate and don't think the decision to celebrate and support public
goods needs to go along with any rejection of club goods. Those latter
people we want first and foremost to be patrons still, even though I'd
like to convince them to change their views on club goods.

In arguments Robert and I had, we identified two views we do agree
about: I assert that support for club goods (e.g. for proprietary
software) undermines the goal of public (FLO) goods. The fact of
competition for attention and resources and the network effects from
people sharing and utilizing the same resources means that there is a
choice between supporting and using proprietary stuff versus supporting
and using FLO stuff. Robert insisted that no such choice exists. Anyone
can use and support both, there's no inherent conflict. He didn't at all
accept my assertion that time, money, attention are limited resources
and giving them to proprietary stuff reduces the available amount for
potential FLO support.

In the end, I still want to and *will* spread the message that club
goods are a tragedy, the toll-road choice itself means someone doesn't
freeride on the public road but *is* avoiding the public road and still
not helping. You cannot drive on both roads at once (or have one road be
in both states at once).

I want to have people consider this perspective while still
understanding that "the snowdrift dilemma" at its core is just about the
public goods and doesn't directly talk about what happens when we fail.
I.e. "because we fail to solve the snowdrift dilemma, we end up with
toll ro

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

On 10/18/2016 07:55 AM, Michael Siepmann wrote:
>  
>> The problem I have with the story is that anything a little too
>> far-fetched is hard to accept. People don't have the experience of
>> living in a town that has no tax-funded public services. Perhaps if the
>> story were described as a rural road out of town where there's no mayor
>> or such, then it's just the individuals in the houses in the
>> neighborhood dealing with the challenge of cooperation without an
>> existing government structure for support.
> 
> True, but doesn't the same apply to the whole snowdrift / tolls & ads
> idea in our cartoon illustrations? 
> 

No, I've even heard from real people who are like "yeah, I have that
exact snowdrift dilemma in my neighborhood with people clearing the
sidewalks" and such.

Everyone has experienced toll-roads and billboards.

These are not far-fetched ideas at all. The whole "some town off
somewhere" etc. gives an othering feeling of a story happening to
someone else.

Psychologically, the more concrete details you give, the more the
observer feels they are watching someone else and the more vague and
general it is, the more they can readily see it as their situation and
fill in the details with those that they know from their own experience.


> I'm leaning toward the view that Bryan brought up in the meeting
> yesterday (before you joined, Aaron) that we may be better off not
> trying to use any reference to snowdrifts and instead changing our name
> to crowdmatch.coop.  I think trying to start with a snowdrift makes it
> much harder than it otherwise would be to create a clear quick and
> engaging introductory explanation.
> 

While I understand the impetus to consider a name-change, I don't think
it makes sense, and I don't think we'll be more successful by dropping
the core principle explaining the challenge of public goods.

For the video, we can omit the whole toll-road aspect as long as we
frame it correctly. If the point is to just skip the meaningful context
and get down to what we do (which has some merit), we can skip the large
story and just say "With a snowdrift we all need cleared, everyone gets
the results whether or not they helped do the work! That's the dilemma
facing public goods. Other public include music, software…"

In that script, the reason to reference the snowdrift is (A) to just
have a clear simply thing to visualize briefly and (B) to tie into the
name and the whole concept that we *will* discuss in many contexts
later, just not in this first version of a video.

I'm not saying that I prefer the video to gloss over the snowdrift idea
so quickly, but I'm willing to accept that approach in order to just get
a quick first functional-enough video.

A longer video explaining the ideas well, ideally both accurate-enough
to impart the gist of the academic ideas but also feel story-like
enough, would be a great thing to have eventually.

I hope today to find time to write out the concerns I see and the
communication policy that is to be followed for communicating these ideas.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

While I really appreciate the insights and perspective from the story
approach Michael presented, it feels far too contrived to me. I'd like
to see if we can capture some feel of the story-style narrative without
pushing the limits too hard.

The problem I have with the story is that anything a little too
far-fetched is hard to accept. People don't have the experience of
living in a town that has no tax-funded public services. Perhaps if the
story were described as a rural road out of town where there's no mayor
or such, then it's just the individuals in the houses in the
neighborhood dealing with the challenge of cooperation without an
existing government structure for support.

At any rate, the big issue is that Robert (alone among everyone in this
regard, I think) feels that (A) we need to be able to talk to people
about "solving the snowdrift dilemma" and the idea that e.g. Patreon
doesn't "solve the snowdrift dilemma" etc.  so have a core thing we get
people to understand as "the snowdrift dilemma" which itself is the core
cooperation dilemma, and so (B) any reference to toll-roads etc.
shouldn't be a factor that people come to associate with "the snowdrift
dilemma" because it brings up different dilemmas.

I still do not agree with Robert's view, but I do think there's an
important question about where the toll-road issue comes in when
explaining things. So, I'm going to start a new thread on the discussion
list about this question.

One last point about Michael's story: I don't like the wordings that say
"The same way it was hard for the townspeople to cooperate to clear the
snowdrift, it's hard for people to cooperate to fund creation of 'public
goods' that benefit us all." That and related wordings really push the
idea that it's just a metaphor. I would rather say "the same dilemma
applies to other public goods…" because that expresses that the
snowdrift dilemma is an example, not just a metaphor.

If we say "the snowdrift dilemma is an example of a public goods
problem" that's just true completely and not a metaphor. When we say
"software funding faces the snowdrift dilemma", it becomes a metaphor.

Anyway, if we *directly* apply crowdmatching to the snowdrift problem,
it's not a matching of volunteer time (although that's possible, it's
not what we're doing). Instead, it's just crowdmatched funding to pay
for the snow-plow.

The accurate version of the story accepting a mayor and government is
either (A) "so we passed a new tax to fund snow-clearing in the future"
(that's it) or (B) "we tried to pass a new tax, but the people were
opposed to new taxes, so came up with the best voluntary alternative: we
set up a crowdmatching pledge where each of us agreed to pay a little
bit times the number of donors to our snow-clearing fund, and thus we
built up an adequate fund and were able to hire a snow-plow on our own
terms, which meant no toll gates and billboards!"

Anyway, will post to discuss list my bigger thought.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

On 10/15/2016 03:25 PM, mray wrote:
> 
> 
> On 15.10.2016 18:12, Aaron Wolf wrote:
>> On 10/15/2016 04:04 AM, mray wrote:
>>>
>>>
>>> On 15.10.2016 04:35, Aaron Wolf wrote:
>>>> With a road blocked by a snowdrift, everyone wants it cleared, but
>>>> nobody wants to do it all themselves. Of course, nothing gets done if
>>>> each of us waits for others to do the work.
>>>>
>>>> That's an example of the PUBLIC GOODS PROBLEM where we fail to cooperate
>>>> enough to support resources that benefit everyone.
>>>>
>>>
>>> Not convinced of that last sentence. The public goods problem exist, but
>>> so do public goods. Clearly this does not match the snowdrift problem
>>> you refere to in the sentence before. It covers the road and does not
>>> allow passage *at all*. We *do* have public goods of the kind we want to
>>> support, though. To make the snowdrift analogy work there needs to be a
>>> problem that stands for the pile of snow: an _unsolved_ problem.
>>>
>>
>> I can tweak those words, but we have to assert that there *do* exist
>> un-shoveled piles of snow, effectively. We have to say that the problem
>> remains unsolved. The truth, that the original text covered, is that
>> there are two solutions already: taxes and toll-roads, and so
>> acknowledging that while rejecting those as inadequate or incomplete
>> solutions is necessary for complete clarity.
>>
> 
> My point is that using a metaphor means accepting its boundaries.
> We can't only lean on the snowdrift dilemma as long as it fits, only to
> quickly borrow from an entirely new, fabricated metaphor that has
> NOTHING to do with it but fits our need.
> 

I really fundamentally disagree. The metaphor of the snowdrift dilemma
is the exact same metaphor as the one with the toll-road (with
snowdrifts cleared because of the toll funding). Whether we discuss
further angles of the metaphor or not is a question of how much time and
what context.

I have discussed this issue with hundreds of people, and you are the
only one who ever indicated even the slightest concern about the
toll-road not being completely obviously the same metaphor.

I will assert that if we present the Snowdrift dilemma as "a road
blocked by a snowdrift" and then describe "the ways we get roads cleared
generally could be with taxes, or we could have toll roads", we could
survey 1,000 people and my prediction is that zero or near-zero of them
will have *any* concern that the toll-road idea is a different metaphor.

Basically: I see you making the claim that this confuses things by
making people think about broader contexts (not just "how do we clear
the snow? i.e. fund this project?" but extended to "aren't there
existing answers without crowdmatching? How do we usually get clear
roads in reality? Taxes and toll-roads. And toll-roads as a solution to
the snowdrift dilemma is like proprietary restrictions as a solution to
funding creative works". You seem to be saying "we need to focus just on
the core dilemma at all, and then present our solution and not get
sidetracked by talking about how we compare to other solutions".

If what I just wrote captures your perspective, I disagree completely.
It is of utmost importance that we acknowledge and discuss the issues
with alternative solutions. Why isn't Kickstarter good enough? Why
aren't proprietary restrictions a good answer? How about taxes? Those
are all real-world answers to the snowdrift dilemma, and we need to
assert that they are inferior to crowdmatching.

> I see what each part is supposed to do here, and why it matters. I have
> an issue with us not being able to stick to ONE metaphor. It seems like
> we owe it to our name that we can get along with only the snowdrift
> dilemma. The "extension" of cameras, tolls and ads kind of "fits"
> thematically but is IN FACT outside of the realm of what is known as the
> snowdrift dilemma.
> 
> It is like saying: "we could all work together or – fly over the
> snowdrift with our private helicopters, but patrol is too expensive and
> little timmy lost the helicopter keys!"
> 

No, because the one and only snowdrift dilemma is "how do we get a clear
road (and generally keep roads clear)?" We have not deviated from that
by saying that taxes or toll-roads are ways to get clear roads. Your
helicopter example suggests alternative ways around the entire issue of
transportation.

Besides, even in your helicopter example, there is still only one
metaphor. So, if you want to express what is wrong with inventing
additional angles like helicopters, you'll need to explain your
objection wi

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

On 10/15/2016 03:34 AM, William Hale wrote:
> On Fri, 14 Oct 2016 19:35:21 -0700
> Aaron Wolf  wrote:
> 
>> ```
>> With a road blocked by a snowdrift, everyone wants it cleared, but
>> nobody wants to do it all themselves. Of course, nothing gets done if
>> each of us waits for others to do the work.
> 
> I think explaining the road imagery is important and should be
> included. I mean we need to answer the "why" this stuff needs to be
> fund somehow and that has always been a good hook.
> 

I think we have to accept that my longer initial explanation is the good
thorough one that answers all the common questions and clarifies like a
great, clear lecture. We just won't have time to make it right now for
the launch, so we'll go with the shorter one.

>>
>> That's an example of the PUBLIC GOODS PROBLEM where we fail to
>> cooperate enough to support resources that benefit everyone.
> 
> Only need to reference / keyword once.
> 
>>
>> Public goods can also be things like music, software, movies, news,
>> research…  We'd all love to get these things for free with no
>> limitations. But then how could we fund their development in the first
>> place?
> 
> I'm not sure that "free from limitations" gets the point across.
> 
>>
>> At Snowdrift.coop, we've created a new crowdmatching system to fund
>> these types of projects while keeping them as free and open public
>> goods.
> 
> Free and open needs to be used only once and explained in a near by
> sentence.
> 

I really like it in the earlier sentence, so if we don't want the term
twice, can you suggest a fully adequate substitute wording for one or
the other case that still carries the meaning? I think if not, we accept
there's some good about reinforcing it anyway.

>>
>> When supporting projects here, you don't risk volunteering alone, and
>> there's no hyped-up, all-or-nothing, one-time campaigns. You just
>> make a pledge that says, "l'll chip in a little more for each person
>> who joins me!" And because we calculate our crowdmatching donations
>> monthly, our system combines mutual assurance with sustainable
>> funding and accountability.
> 
> I would focus on two of the three or comma separate. This is the real
> meat, maybe cut the cat around it? Don't reuse keywords and get it to
> to like 30-45 seconds.
> 

Could you give specific example of what you're suggesting here?

> Otherwise, I liked the one you sent initially. It is pretty solid but
> will take a fair amount of animation to make it look good before
> attention wavers.
> 
> That being said, if this launch is really targetting
> the people who have been watching us for years, then this audio clip
> may make a better impression.
> 
> Thoughts?
> 
>>
>> Working together, we can clear the path to a free and open future for
>> everyone!
>> ```
>>
> 
> Use the tagline here, "Crowdfunding for Public Goods".
> 
> 
> I really do like the longer version and think it might hit home with
> the long-term supporters.
> 
> Mray, what do you think could be done to illustrate it?
> 
> Wolftune and chreekat, be safe if the weather kicks up!
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

On 10/15/2016 04:04 AM, mray wrote:
> 
> 
> On 15.10.2016 04:35, Aaron Wolf wrote:
>> With a road blocked by a snowdrift, everyone wants it cleared, but
>> nobody wants to do it all themselves. Of course, nothing gets done if
>> each of us waits for others to do the work.
>>
>> That's an example of the PUBLIC GOODS PROBLEM where we fail to cooperate
>> enough to support resources that benefit everyone.
>>
> 
> Not convinced of that last sentence. The public goods problem exist, but
> so do public goods. Clearly this does not match the snowdrift problem
> you refere to in the sentence before. It covers the road and does not
> allow passage *at all*. We *do* have public goods of the kind we want to
> support, though. To make the snowdrift analogy work there needs to be a
> problem that stands for the pile of snow: an _unsolved_ problem.
> 

I can tweak those words, but we have to assert that there *do* exist
un-shoveled piles of snow, effectively. We have to say that the problem
remains unsolved. The truth, that the original text covered, is that
there are two solutions already: taxes and toll-roads, and so
acknowledging that while rejecting those as inadequate or incomplete
solutions is necessary for complete clarity.

If we accept brevity, then it's just beyond the video to say "sure, it's
solved in some cases, but this dilemma describes the challenge and why
it *often* goes unsolved".

Let me clarify: the statement I am making is that the problem describes
why it is hard to get people to cooperate and implies that it MAY and
DOES happen that *often* we do fail to get there. I'm not trying to
imply that it *always* happens that way. The Snowdrift Dilemma and
Public Goods Problem in general does not say that cooperation is
impossible, it just explains why we OFTEN fail.


> I think the unsolved problem is to organize financial project support in
> *direct relation* to the scope of public relevance. – Which is where we
> can often spot a shocking discrepancy: Relevance != $upport
> Our goal is to leverage exactly and only at this point.
> 

Yes, the nuanced truth is that it's a continuum from no support to full
potential, and we rarely are at either extreme. But that's too nuanced
for the video, unless we take the time to express this further (like
talking of some people who love shoveling snow).

> We need to somehow say that being a public good that benefits everyone
> isn't good enough for us. Sweeping demand of a project isn't just
> desired, to some degree it is the only thing we truly care about.
> Because everything else can stick with the status quo and have the same
> results as what we can offer them in our system (few demand = few
> donations).
> 

This video is simply not going to cover the issue that Snowdrift.coop is
best fit to the projects that have on-going needs and reach more than a
very small niche audience. Those things will have to live elsewhere or
be in later videos or pages or whatever. This is the video describing
the core concept, not getting into nuances about which projects are the
best-fit for our solution.

> 
>> Public goods can also be things like music, software, movies, news,
>> research…  We'd all love to get these things for free with no
>> limitations. But then how could we fund their development in the first
>> place?
>>
> 
> I think at this point we need to add this caveat:
>  "... But then how could we fund their development in the first place?
> And expect really professional quality and dedication"
> 

That's implied well-enough. If people think, "musicians and movie-makers
can just get by on super tiny budgets", we're already dealing with a
different sort of conversation. Most people don't actually think that a
movie we'd care about or journalism we want can manage with tiny
budgets. As far as we're concerned, the things we'd all wish to freely
share are quality things, not shitty ones.

>> At Snowdrift.coop, we've created a new crowdmatching system to fund
>> these types of projects while keeping them as free and open public goods.
>>
> 
> I like that.
> 
>> When supporting projects here, you don't risk volunteering alone, and
>> there's no hyped-up, all-or-nothing, one-time campaigns. You just make a
>> pledge that says, "l'll chip in a little more for each person who joins
>> me!" And because we calculate our crowdmatching donations monthly, our
>> system combines mutual assurance with sustainable funding and
>> accountability.
>>
> 
> I think "hyped-up" is a really alien accusation that smells of prejudice
> towards our best known "competitor". Lets not start mudslinging 

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

Okay, after a great long chat with Robert, I've written a new script.
I'll record audio for it if I don't get feedback about it otherwise
really soon. It accommodates a lot of concerns Robert has but ends up as
the sort of wording I want overall:


```
With a road blocked by a snowdrift, everyone wants it cleared, but
nobody wants to do it all themselves. Of course, nothing gets done if
each of us waits for others to do the work.

That's an example of the PUBLIC GOODS PROBLEM where we fail to cooperate
enough to support resources that benefit everyone.

Public goods can also be things like music, software, movies, news,
research…  We'd all love to get these things for free with no
limitations. But then how could we fund their development in the first
place?

At Snowdrift.coop, we've created a new crowdmatching system to fund
these types of projects while keeping them as free and open public goods.

When supporting projects here, you don't risk volunteering alone, and
there's no hyped-up, all-or-nothing, one-time campaigns. You just make a
pledge that says, "l'll chip in a little more for each person who joins
me!" And because we calculate our crowdmatching donations monthly, our
system combines mutual assurance with sustainable funding and
accountability.

Working together, we can clear the path to a free and open future for
everyone!
```



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

On 10/14/2016 12:05 PM, mray wrote:
> 
> 
> On 14.10.2016 07:22, Aaron Wolf wrote:
>> It's not perfect, but I think this is usable. I worked hard to capture
>> every aspect that would cover all the important elements, avoid
>> misunderstanding from people who might have the wrong guesses if things
>> weren't quite clear, and achieves the basic idea of a compelling
>> introduction from which people should jump to learning the details
>> and/or signing up.
>>
>> Audio here: http://snowdrift.sylphs.net/f/a3591afcb5/?raw=1
>>
>> That's a direct download to a FLAC file
>>
>> Here's the script: http://snowdrift.sylphs.net/f/9894866a59/?raw=1
>>
>> Both are available to the design group in Seafile as well.
>>
>> The fundamental images I insist on having in the video are the ones that
>> show the road blocked by snowdrift (it should be blocked enough to be
>> clearly a problem, not just sorta snowy), the toll-road with cameras and
>> billboards, and the vision we want: a nice clear road with trees and no
>> billboards, no obstacles.
>>
>> I can easily imagine other illustrations or text shown in the video to
>> accompany the narration, but the core thing is the road images and then
>> just whatever else will fill out a functional video.
>>
>> We can always iterate or make updated versions later, but right now we
>> need a first version that's good enough to actually put live and then
>> start getting feedback on and be usable for our initial launch.
>>
>> Cheers,
>> Aaron
>>
>>
> 
> 
> Thanks Aaron!
> 
> As expected this is quite a bit long which is why I take the freedom to
> use only parts of the snippet. For now my plan is to us this:
> 

As the person in charge of communications, it does step on my toes to
freely edit the snippet. I want to discuss and clarify (and perhaps
redo) in regards to feedback.

The recording is under 2 minutes, and I included every element for a
good reason. I understand that concision is a value, but I am going to
insist that we not favor concision when it hurts the communication too much.

> 
> Snowdtrift.coop has a new solution to help everyone cooperate in solving
> the snowdrift dilemma.
> 
> In our crowdmatching system, you don't risk volunteering while everyone
> else freerides. Instead, you say, "I'll help, but I'm not doing it all
> myself. I'll chip in a little more for each person who joins me!"
> 
> And instead of one-time, hyped-up, all-or-nothing campaigns, we
> calculate our crowdmatching donations monthly, combining mutual
> assurance with sustainable funding and accountability.
> 
> Snowdrift.coop will support any projects developing true public goods
> under free/libre/open licenses with no extra gates, tolls, or
> limitations. Join us in clearing the path to a better, free and open future!
> 
>
> 
> The snippet is easier to digest and covers a more realistic amount of
> time/work for having something up in time. Any thoughts on this?
> 

I agree that this is the conclusion, but it loses the entire premise. It
loses the one most important element which is the image of a public road
versus a toll road.

I'd rather have a video that only had the premise, that just talked
about the snowdrift dilemma and the roads and then have plain images and
text somewhere to read about the Snowdrift.coop solution.

I don't actually want either cut, of course. I think that these are all
completely essential in the long-run:

* "public goods" are infinitely sharable
* examples for people to understand concretely (music, movies, software…)
* toll-roads suck (and some image or sense of why this dilemma exists)
* crowdmatching is the solution, sustainable, accountable

In the immediate "what the hell is Snowdrift.coop, and why is it funding
itself and not any other projects yet?" situation, the most concise we
can go with is:

"If we can't all cooperate to clear the roads we all share, we'll be
stuck with just toll roads!" and the images to accompany that.

So, here's my suggestion (I can make new recording once finalized):

```
If we can't all cooperate to maintain the roads we all share, we'll only
have toll roads!

To fund public goods, Snowdrift.coop introduces a new crowdmatching
system where you don't risk volunteering while everyone else freerides.
Instead, you say, "I'll help, but I'm not doing it all myself. I'll chip
in a little more for each person who joins me!"

And instead of one-time, hyped-up, al

[Snowdrift-design] Audio for intro-to-snowdrift video

[Aaron Wolf]

It's not perfect, but I think this is usable. I worked hard to capture
every aspect that would cover all the important elements, avoid
misunderstanding from people who might have the wrong guesses if things
weren't quite clear, and achieves the basic idea of a compelling
introduction from which people should jump to learning the details
and/or signing up.

Audio here: http://snowdrift.sylphs.net/f/a3591afcb5/?raw=1

That's a direct download to a FLAC file

Here's the script: http://snowdrift.sylphs.net/f/9894866a59/?raw=1

Both are available to the design group in Seafile as well.

The fundamental images I insist on having in the video are the ones that
show the road blocked by snowdrift (it should be blocked enough to be
clearly a problem, not just sorta snowy), the toll-road with cameras and
billboards, and the vision we want: a nice clear road with trees and no
billboards, no obstacles.

I can easily imagine other illustrations or text shown in the video to
accompany the narration, but the core thing is the road images and then
just whatever else will fill out a functional video.

We can always iterate or make updated versions later, but right now we
need a first version that's good enough to actually put live and then
start getting feedback on and be usable for our initial launch.

Cheers,
Aaron
-- 
Aaron Wolf
co-founder, Snowdrift.coop



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] top-padding for

[Aaron Wolf]

On 09/06/2016 12:40 PM, mray wrote:
> 
> 
> On 05.09.2016 13:14, Bryan Richter wrote:
>> The default styling has 3 rem of bottom-padding for . I think it
>> needs top-padding, too. Otherwise it's pretty bunched up against a
>> preceding .
>>
> 
> padding: 3rem 0;
> 
> Sounds like a fine solution.

I really think ikomi's MR switching things to margins is right here. For
these things, margins are the way to go because they overlap, so you
always get the space desired around objects but don't get awkward extra
space when two objects are next to one another. Some small padding
wouldn't be crazy though.

I'm not the designer, but my understanding is this is textbook example
of where to use margins rather than padding.

> 
> 
>> I'm not sure how to add some padding while preserving vertical rhythm.
>> Would someone like to play with it?
>>
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] "History" or "Payment History" page content

[Aaron Wolf]

On 08/29/2016 01:27 PM, Michael Siepmann wrote:
> On 08/29/2016 01:45 PM, mray wrote:
> 
>> The last meeting made clear we need to settle on what we expect the page
>> to do for a user.
>>
>> My impression was always that MVP needs a page to satisfy the basic need
>> of people to see where there money goes in a system that is really "half
>> baked". There may be more need for many other visualizations, but for
>> this one it boils down to:
>>
>>  "Where did my money go?"
>>
>> (Aaron supposed to rename the tab to "Payment History" to somewhat
>> clarify its purpose.)
>>
>> @Michael:
>> What is your opinion on that matter? - What do you think the MVP page
>> should do for the user.
> 
> I think it includes "Where did my money go?" but also, importantly,
> "What's been happening with my pledges?".  People will pledge on
> Snowdrift.coop because they want to support projects, so it's important
> for the history page to show them what's happened each month with regard
> to their support for projects, whether or not any of their money went
> anywhere that month.
> 
> I don't think it's OK in mid-May 2016, for example, as illustrated in
> the attached, to have the history tell them nothing about April and
> March other than that spending got carried over because the payment
> processing fee would make up more than 10%.
> 
>> I think any discussion about page mockups only makes sense in the
>> specific context of what needs to be solved by them.
>>
> 
> Agreed.
> 
> 

I think two pages for "payment history" and "pledge history" should be
considered. They each solve separate questions: (A) "where did my money
go?" and (B) "How does this crowdmatch thing work in terms of my place
in it and the projects I support?" (i.e. understand the system via
reviewing your history as a patron). Both do seem relevant to MVP.
Combining them may make it harder than designing to separately answer
each question…




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/12/2016 09:57 PM, Michael Siepmann wrote:
> On 08/12/2016 09:37 PM, Aaron Wolf wrote:
>> On 08/12/2016 08:04 PM, Michael Siepmann wrote:
>>> 
>> Let me try to make my view clearer. I think that it is more
>> understandable to think this:
>>
>> "Oh, when things were really low, no charges happened, it just added up
>> and carried over into the first real charge, although it may take a
>> couple months in rare cases getting close to budget limit"
>>
>> Than this:
>>
>> "This is the carry-over from last month even though last month had a
>> charge of my budget limit. So, the carry-over must have been from before
>> because they wouldn't actually bill me more than the monthly budget, right?"
>>
>> To put it another way: I want people to keep in mind that carry-overs
>> all just happen from the early low-level first period. I don't want them
>> to get the impression that carry-overs are a normal occurrence and
>> should be expected to recur often. So, I prefer that people associate
>> the carry-over with the early low-level period. I don't want it to be
>> associated with the most recent month necessarily.
>>
>> Let's say 5 months go by at low level and finally get to a point worth
>> charging. I don't want to present the charge as a one-month carry-over.
>> I want to present it as "we finally have enough for the past 5 months to
>> put in a charge without excessive fees".
>>
>> The common scenario could be:
>>
>> Jan $0.12
>> Feb $0.34
>> Mar $1.66
>> Apr $3.18
>>
>> So, then we charge in April, and I *like* the idea of saying "this is
>> all the donations for 4 months in one charge." That seems clear and
>> understandable. Having to chain back the carry-overs seems harder to
>> follow or at least risks people misunderstanding what is going on.
>>
>> I hope my concern is more clear now. I'm not sure what the solution is.
>>
>> But I will add that this could be put off for the immediate time-being,
>> so I don't want us to get too distracted perfecting this right now.
> 
> Your concern makes sense to me.  I think if we can get an adequate
> solution to this now, it will be very helpful to have this tricky aspect
> worked out.  The following version seems to me to get quite a bit
> closer.  I look forward to further feedback:
> 
> http://snowdrift.sylphs.net/f/48fba86882/?raw=1
> 
> 
> 

Yes! This is much more clear to me. There was a funny postponed time,
and I see how it is getting included in later months to avoid fees.
Makes sense, glad Snowdrift.coop thought this out so well!

That's my impression of the new version. Happy to see others' feedback,
but this one seems much better than all previous mockups!




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/12/2016 08:04 PM, Michael Siepmann wrote:
> On 08/12/2016 08:02 PM, Aaron Wolf wrote:
>> On 08/12/2016 06:58 PM, Stephen Michel wrote:
>>> 
>>>
>>>
>>> I think that this scenario is really hard to parse. It could also result in 
>>> a display where you have a carryover from may and a carryover from June 
>>> displayed in July, and that gets really busy really quickly (especially if 
>>> one or more are also carried over to august).
>>>
>>> I suggest that we aggregate all carryover charges. The small loss in detail 
>>> is totally worth the simplicity, imo.
>>>
>> Absolutely! Describing the carry-over from several months with separate
>> list of carry-overs would be crazy. But the aggregated sum can be
>> described as month-month e.g. "March-July carry-over". Effectively, most
>> carry-overs will only happen at the early stage of projects and patrons,
>> when they first start on the system. A new project with some new patrons
>> may have a period of carry-overs, and then no more of that going
>> forward. So, it's just this contiguous set of months that will have
>> carry-overs in almost all cases.
>>
>> To cover all possible scenarios, we could just say "carry-over from
>> earlier months with charges too low to be worth charging" effectively.
>>
>> In any case, it should be one sum number.
> 
> That's already what I intended: At most one carry over from the previous
> month and one carry over to the next month.  I don't even think we
> should try to describe what multiple months it may originally come from
> (e.g. no attempt at "March-July carry-over" etc) because that will just
> get too complicated, particularly in the "widdle-away" scenario when
> part of a carry over is paid off in one month but part is carried over
> to the next month.
> 
> It would probably be clearer to go back to referring to "next month" and
> "previous month" as I'd done previously, rather than naming the specific
> last and previous months as I tried in this latest version.
> 

Let me try to make my view clearer. I think that it is more
understandable to think this:

"Oh, when things were really low, no charges happened, it just added up
and carried over into the first real charge, although it may take a
couple months in rare cases getting close to budget limit"

Than this:

"This is the carry-over from last month even though last month had a
charge of my budget limit. So, the carry-over must have been from before
because they wouldn't actually bill me more than the monthly budget, right?"

To put it another way: I want people to keep in mind that carry-overs
all just happen from the early low-level first period. I don't want them
to get the impression that carry-overs are a normal occurrence and
should be expected to recur often. So, I prefer that people associate
the carry-over with the early low-level period. I don't want it to be
associated with the most recent month necessarily.

Let's say 5 months go by at low level and finally get to a point worth
charging. I don't want to present the charge as a one-month carry-over.
I want to present it as "we finally have enough for the past 5 months to
put in a charge without excessive fees".

The common scenario could be:

Jan $0.12
Feb $0.34
Mar $1.66
Apr $3.18

So, then we charge in April, and I *like* the idea of saying "this is
all the donations for 4 months in one charge." That seems clear and
understandable. Having to chain back the carry-overs seems harder to
follow or at least risks people misunderstanding what is going on.

I hope my concern is more clear now. I'm not sure what the solution is.

But I will add that this could be put off for the immediate time-being,
so I don't want us to get too distracted perfecting this right now.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/12/2016 06:58 PM, Stephen Michel wrote:
> 
> 
> On August 12, 2016 6:54:28 PM EDT, Michael Siepmann 
>  wrote:
>>  On 08/12/2016 04:08 PM, Michael Siepmann wrote:
>>
>>> On 08/12/2016 03:59 PM, Michael Siepmann wrote:
>>>> 
>>>
>>> Here's what I had in mind, from the "How the limit works" thread:
>>>
>>> On 08/03/2016 06:34 PM, Aaron Wolf wrote:
>>>> On 08/03/2016 05:19 PM, Aaron Wolf wrote:
>>>>> Whenever there needs to be a carry-over, we use the difference
>>>>> between a month's charges and any outstanding carry-over from
>>>>> previous to reach up to the max, and thus widdle-away the
>> carry-over >
>>>> over multiple months if need be.
>>>>
>>>> Error in my wording: I meant "the difference between the max and the
>>>> current month's charges as the amount of any carry-over that is
>>>> available to be charged in a given month"
>>>>
>>>
>>> That's what I intended to depict, but I see that how June 2016
>> doesn't
>>> do that correctly and instead depicts a situation that shouldn't ever
>>> exist.  Thanks for catching it, Stephen.  The "widdle-away" approach
>>> means we *can* carry over to the next month to avoid exceeding the
>>> limit, but only from any amount carried over to this month from the
>>> previous month.  I'll update it to depict that scenario.
>>
>> How about this?:
>>
>> http://snowdrift.sylphs.net/f/83aacffd4f/?raw=1
>>
>> I've tried new wording to try to make it clearer, and updated the
>> numbers to show a realistic "widdle-away" scenario for a couple of
>> months.  Fortunately most of the time this complex a scenario won't
>> arise.
> 
> I think that this scenario is really hard to parse. It could also result in a 
> display where you have a carryover from may and a carryover from June 
> displayed in July, and that gets really busy really quickly (especially if 
> one or more are also carried over to august).
> 
> I suggest that we aggregate all carryover charges. The small loss in detail 
> is totally worth the simplicity, imo.
> 

Absolutely! Describing the carry-over from several months with separate
list of carry-overs would be crazy. But the aggregated sum can be
described as month-month e.g. "March-July carry-over". Effectively, most
carry-overs will only happen at the early stage of projects and patrons,
when they first start on the system. A new project with some new patrons
may have a period of carry-overs, and then no more of that going
forward. So, it's just this contiguous set of months that will have
carry-overs in almost all cases.

To cover all possible scenarios, we could just say "carry-over from
earlier months with charges too low to be worth charging" effectively.

In any case, it should be one sum number.

> Any charges that will roll over (the negatives) will always be the bottom 
> item in the list, so it's fairly easy to eyeball the rest of the list and 
> verify that it is below the limit. I'm tempted to put charges from a previous 
> month below fees for that reason, as well, but that feels odd to me. 
> 




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/12/2016 03:54 PM, Michael Siepmann wrote:
>   On 08/12/2016 04:08 PM, Michael Siepmann wrote:
> 
>> On 08/12/2016 03:59 PM, Michael Siepmann wrote:
>>> 
>>
>> Here's what I had in mind, from the "How the limit works" thread:
>>
>> On 08/03/2016 06:34 PM, Aaron Wolf wrote:
>>> On 08/03/2016 05:19 PM, Aaron Wolf wrote:
>>>> Whenever there needs to be a carry-over, we use the difference
>>>> between a month's charges and any outstanding carry-over from
>>>> previous to reach up to the max, and thus widdle-away the carry-over >
>>> over multiple months if need be.
>>>
>>> Error in my wording: I meant "the difference between the max and the
>>> current month's charges as the amount of any carry-over that is
>>> available to be charged in a given month"
>>>
>>
>> That's what I intended to depict, but I see that how June 2016 doesn't
>> do that correctly and instead depicts a situation that shouldn't ever
>> exist.  Thanks for catching it, Stephen.  The "widdle-away" approach
>> means we *can* carry over to the next month to avoid exceeding the
>> limit, but only from any amount carried over to this month from the
>> previous month.  I'll update it to depict that scenario.
> 
> How about this?:
> 
> http://snowdrift.sylphs.net/f/83aacffd4f/?raw=1
> 
> I've tried new wording to try to make it clearer, and updated the
> numbers to show a realistic "widdle-away" scenario for a couple of
> months.  Fortunately most of the time this complex a scenario won't arise.
> 

How about putting the edge case of "carry over from … to …" *after* the
charge so it makes more math sense? As in:

Snowdrift.coop $9.39
Carryover from May $1.39
Payment processing fee $0.57
___
Charge $10 (at limit)
Carryover from May carried over to June $1.35

or alternately:

New charges:
Snowdrift.coop $9.39
Payment processing fee $0.57
June total: $9.96
$0.04 of May carry-over included in total charge of $10.00

Or something of that nature.

The features are:

* Show this month's total as a single clear thing to understand first
what happened this month

* Display the partial carry-over as an extra "hey, we had some room
before max to cover part of the carry-over from when we delayed charge
to avoid fees"

It could then say "X is remaining from earlier carry-overs to still be
charged in future months".

Thankfully, this scenario is unlikely edge-case as I've said before. But
I could see segregating carry-overs this way even when it's charging all
the carry-over…

Just ideas to consider



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/12/2016 02:28 PM, Stephen Michel wrote:
> On Fri, Aug 12, 2016 at 5:22 PM, Aaron Wolf  wrote:
>> On 08/12/2016 01:58 PM, Michael Siepmann wrote:
>>>  Here's a rough-around-the-edges modification of mray's mockup with the
>>>  kind of information and structure I'm arguing for:
>>>
>>>  http://snowdrift.sylphs.net/f/7949e02830/?raw=1
>>>
>>
>> My biggest concern is "carried over from last month" could give the
>> impression that we *do* charge more than the limit for a month, like if
>> the limit is $10 and the crowdmatching gets to $12, we carry over $2 to
>> the next month. Of course, that's not what we're proposing. But I think
>> it needs to be clear that the carry over is only from charges too small
>> to be worth it given fees.
>>
>> I'm not sure how to make that clear, but the point is that the
>> carry-over is only ever funds that could have been charged earlier but
>> we delayed them to minimize fees.
>>
>> The "to next month" parts get this, but the first thing I saw was "from
>> last month" and there it wasn't clear.
> 
> In June of the mockup, it shows a scenario where $pledge + $fees >
> $limit. This would allow someone to accrue a running balance that will
> never be paid off, and violates our "no more than $limit per month"
> rule. I don't think that should ever happen; in that scenario the pledge
> should become suspended.
> 
> However, that is not related to how we present the information on this
> page.
> 

Absolutely, and Stephen's point aligns with mine. The only thing that
should ever be carried over is charges that came from a month that was
too low to be worth charging. We should never carry over fees. The total
of pledges *plus* fee has to be under the limit for a given month to
keep the pledge active.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/12/2016 01:58 PM, Michael Siepmann wrote:
> Here's a rough-around-the-edges modification of mray's mockup with the
> kind of information and structure I'm arguing for:
> 
> http://snowdrift.sylphs.net/f/7949e02830/?raw=1
> 

My biggest concern is "carried over from last month" could give the
impression that we *do* charge more than the limit for a month, like if
the limit is $10 and the crowdmatching gets to $12, we carry over $2 to
the next month. Of course, that's not what we're proposing. But I think
it needs to be clear that the carry over is only from charges too small
to be worth it given fees.

I'm not sure how to make that clear, but the point is that the
carry-over is only ever funds that could have been charged earlier but
we delayed them to minimize fees.

The "to next month" parts get this, but the first thing I saw was "from
last month" and there it wasn't clear.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/11/2016 08:42 AM, Aaron Wolf wrote:
> I like Stephen's acknowledgement of two issues, but I don't want them to
> be all that distinct. Hstory is history. People want to review the whole
> system and understand the interactions. Most of the time, people will be
> wanting to generally review what happened why and how the system works.
> They will not be doing accounting.
> 
>> "Where did my precious real money actually go?"
> 
> I think that is the wrong question most of the time. The vast majority
> of patrons will actually never feel that $5 was precious at all. I think
> Robert is imagining a very particular sort of sensitive user who is in
> the minority.
> 
> Here's one anecdata point: Of people we've gotten around to sending
> stickers to for their donations, many have basically said "oh yeah! I
> forgot whether I'd donated or not, although I remember seeing the
> campaign. Well, great, thanks for the sticker and good luck!"
> 
> We're talking very small amounts of money, and once we include a budget
> limit, it's possibly that nearly every patron will have no interest in
> careful accounting. If they see that every charge on their account is a
> range from zero to their budget limit with either zero charges or one
> charge per month, they will be satisfied. End of story. I think they
> will almost never have any interest in just knowing precisely about the
> charge details without the context of thinking about other patrons and
> crowdmatching and the overall Snowdrift.coop system.
> 
> I'm suggesting it's possible or likely that the vast majority of the
> time anyone is interested in history, it's because they want to
> understand the crowdmatching system, their place in it, etc. They review
> history as a way to reinforce their understanding of the system. They
> basically never think "my precious money, what happened to it?". They
> are thinking "so, I was charged X. How does that relate to how the
> projects are doing and what other patrons are putting in?"
> 
> So, I think overall that I agree with Michael's points in this
> conversation. His approach is much more aligned with helping people
> understand what the mechanism is doing. Charges are included in that
> understanding, as they should be.
> 
> The factor that's missing in the history and may be the very most
> important is showing the total the projects got. The main thing a
> history viewer wants to see is "I put in X, but that's part of all these
> patrons, so crowdmatching got my chosen projects Y total funds! Yay!"
> And to be able to review what is happening with the crowdmatching over
> time. Because carry-over charges are related to any particular patron's
> combined pledges and budget limit, it's not appropriate to show the
> total crowdmatching for projects only around charges, it needs to be
> focused on when the donation level was set, regardless of when the funds
> actually get charged.
> 
> For budgeting and auditing purposes, it's easy enough to just show a
> charge history and to itemize what that charge covers (including what of
> it is a fee and what is carry-over). That view should exist. But to
> presume that it is the view of most important interest to most people
> is, I predict, not going to be a supported hypothesis in the end.
> 

To give a summary point: I assert that by far the most important factor
is that any time a charge or donation is mentioned, our goal is to
remind people that they aren't alone and the point is that they are part
of crowdmatching.

Whatever reason people first view history, we want them leaving
thinking, "yeah, because I put in this little bit, it got the projects
that much more from others!"

Also, we're in position to direct the focus people have. We want to
*discourage* "my precious money!" calculated thinking and emphasize
social thinking. The psychology here is clear and well-researched.
https://wiki.snowdrift.coop/about/psychology




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

I like Stephen's acknowledgement of two issues, but I don't want them to
be all that distinct. Hstory is history. People want to review the whole
system and understand the interactions. Most of the time, people will be
wanting to generally review what happened why and how the system works.
They will not be doing accounting.

> "Where did my precious real money actually go?"

I think that is the wrong question most of the time. The vast majority
of patrons will actually never feel that $5 was precious at all. I think
Robert is imagining a very particular sort of sensitive user who is in
the minority.

Here's one anecdata point: Of people we've gotten around to sending
stickers to for their donations, many have basically said "oh yeah! I
forgot whether I'd donated or not, although I remember seeing the
campaign. Well, great, thanks for the sticker and good luck!"

We're talking very small amounts of money, and once we include a budget
limit, it's possibly that nearly every patron will have no interest in
careful accounting. If they see that every charge on their account is a
range from zero to their budget limit with either zero charges or one
charge per month, they will be satisfied. End of story. I think they
will almost never have any interest in just knowing precisely about the
charge details without the context of thinking about other patrons and
crowdmatching and the overall Snowdrift.coop system.

I'm suggesting it's possible or likely that the vast majority of the
time anyone is interested in history, it's because they want to
understand the crowdmatching system, their place in it, etc. They review
history as a way to reinforce their understanding of the system. They
basically never think "my precious money, what happened to it?". They
are thinking "so, I was charged X. How does that relate to how the
projects are doing and what other patrons are putting in?"

So, I think overall that I agree with Michael's points in this
conversation. His approach is much more aligned with helping people
understand what the mechanism is doing. Charges are included in that
understanding, as they should be.

The factor that's missing in the history and may be the very most
important is showing the total the projects got. The main thing a
history viewer wants to see is "I put in X, but that's part of all these
patrons, so crowdmatching got my chosen projects Y total funds! Yay!"
And to be able to review what is happening with the crowdmatching over
time. Because carry-over charges are related to any particular patron's
combined pledges and budget limit, it's not appropriate to show the
total crowdmatching for projects only around charges, it needs to be
focused on when the donation level was set, regardless of when the funds
actually get charged.

For budgeting and auditing purposes, it's easy enough to just show a
charge history and to itemize what that charge covers (including what of
it is a fee and what is carry-over). That view should exist. But to
presume that it is the view of most important interest to most people
is, I predict, not going to be a supported hypothesis in the end.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

Lots of snip…

> My point is that having "proper" entries inside a "$0-month is
> unintuitive.

I don't find entries that add up to 0 unintiutive at all.

> Not having to jump around months to make sense of the one
> payment that *did* happen seems more intuitive.

That I agree is intuitive.

We may want to eventually have separate views for "payment history"
versus "patronage history" or something, but I feel this discussion is
getting too far off down the line into speculative future.

The ideal thing that I would expect as a user is to be able to look at
any one month, see the exact status of everything as it was at that
month and also have a different running view where I can see when some
event happened and be able to quickly skip (i.e. it would not show) any
months of no activity.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/10/2016 12:31 PM, mray wrote:
> 
> 
> On 10.08.2016 14:59, Bryan Richter wrote:
>> On Wed, Aug 10, 2016 at 12:35:03PM +0200, Robert Martinez (mray)
>>
>> I think this looks amazing. But I am easily wowed by nice graphics.
>> Looking forward to Michael's response. Robert, I'm also curious how
>> you think we should handle that stupid edge case of "This month + Last
>> month's carryover > Limit". I wish we could just abolish that edge
>> case somehow. Not sure it's possible though.
>>
> 
> 
> My intuition would always to be to prioritize "old debts" and make sure
> that carryover gets paid asap. If anything gets into that way it gets
> auto-UN-matched just like anything else that breaks the limit.
> 
> Promises you made in the past has to trump promises you would like to
> make for the future.
> 
> 

The edge case may never even arise. It only happens when the difference
from one month to the next goes all the way from too-small-to-charge to
almost-limit. And for that edge case spreading out the carry-over over a
few months is perfectly reasonable. Having the carry-over cause
suspensions would be a worse experience for a range of reasons. But
again, very rare edge case.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/10/2016 05:59 AM, Bryan Richter wrote:
> On Wed, Aug 10, 2016 at 12:35:03PM +0200, Robert Martinez (mray)
> wrote:
>>
>>
>> On 08.08.2016 19:55, Michael Siepmann wrote:
>>> Here's a revised mockup without the pledge subtotal and showing
>>> both the "too low" and "too high" reasons for carryover. In this
>>> example, the user increased their limit in July.  There are other
>>> changes also, such as noting what the limit was on the charge
>>> line.  I'm also atttaching the .ODS file.
>>>
>>
>>
>> I think there need to be two distinct representations of your
>> activity on snowdrift.
>>
>> 1. A *complete* log of all activity, including details as date and
>> time when any project pledge button was used to pledge/unpledge,
>> date and time when your payment processor got set up correctly, when
>> you money actually got transferred, ... just *lots* of details.
>>
>> 2. An overview of what just happened, reassuring that things are
>> going as you expect them to go, and that you understood the
>> crowdmatching mechanism and that YOU are in control.
>>
>> Assuming that both views are needed my approach is to visually
>> support each accordingly. Your mockup seems closer to a
>> representation as in "1." But I'd like to have a very simple and
>> intuitive view in MVP that mainly addresses the understanding of the
>> mechanism rather than controlling its accuracy. Of course we need
>> both to live up to our proclaimed goals of transparency. My
>> rationale to go for "2." is that we are on a journey to approach
>> people and earn enough trust so that they give up control and hand
>> it over to our mechanism. Having good intentions(tm) and having
>> simple rules like: "Never over limit!" & "Always under 10% fees!" is
>> a good start. But we also need to create an experience of being the
>> driving force in that mechanism, and my impression is that
>> representation "2." supports that better than "1."
>>
>>
>> Michael, do you agree a distinction of "1." and "2." makes sense?
>>
>>
>> My premise to a representation of "2." is:
>>
>>--- "What did I pay last months - and why?" ---
>>
>> This question needs to be answered as simple and clear as possible.
>> Once we start explaining more we'll have a hard time to stay simple
>> and justifying not to go into even more detail.
>>
>>
>> So looking at your mockup this goes through my mind:
>>  * Why does paying $0 have to look as complex?
>>  * Why are numbers of patrons so prominent?
>>  * Why list projects that got no money from me?
>>  * Why is the day of the month of transaction important?
>>
>>
>> My attached mockup addresses those issues by
>>  * simplifying $0-months and making the carry-over visually obvious
>>  * moving patrons away from where you probably do some quick math
>>  * removing suspended projects
>>  * removing the date
>>
>> I do agree though, that having the respective limit for each month
>> is necessary, so I added that bit of information.
>>
> 
> I think this looks amazing. But I am easily wowed by nice graphics.
> Looking forward to Michael's response. Robert, I'm also curious how
> you think we should handle that stupid edge case of "This month + Last
> month's carryover > Limit". I wish we could just abolish that edge
> case somehow. Not sure it's possible though.
> 

I'd like to not get distracted too much since the whole limits and edge
cases here are post-immediate-launch, but: I suggest the design for the
edge case just say "carry-over from February - April" for a case where
several months go by before the total is worth charging, and then the
over-limit edge-case can be displayed as "remaining February - April
carry-over not charged last month" or similar. I don't think it's too
hard to make this clear.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/09/2016 10:42 AM, Bryan Richter wrote:
> On Tue, Aug 09, 2016 at 10:09:47AM -0600, Michael Siepmann wrote:
>> On 08/09/2016 07:23 AM, Stephen Michel wrote:
>>
>>> 
>>> I agree with Michael here, but there is a limit. Imagine a user
>>> who pledges to many projects which are then suspended as they
>>> grow, but who is also lazy  and leaves the pledges suspended
>>> rather than dropping them. Their history could become bloated with
>>> (imo) useless information as the months run by.
>>>
>>> I think the proper place to tackle this is: if a user has not
>>> reinstated a suspended pledge within 3 (?) months, it should be
>>> automatically dropped. Apologies if we've already had this
>>> conversation; I do remember talking about it but not this
>>> particular facet, and mobile makes it hard to go back and check.
>>
>> This seems like a good idea to me.  I think we should notify them
>> with some reasonable notice, e.g. a brief email 2 weeks before it
>> will be dropped.  Also they'll of course have been notified when it
>> was initially auto-suspended.  (In both cases they might be able to
>> opt out of these notifications, but I certainly think the default
>> should be to be notified of these situations.)
> 
> Truly, this question was discussed to death some time ago. :P Sadly I
> don't recall what the outcome was.
> 
> Aaron, maybe you remember?
> 
> 

We never discussed anything about the situation of suspended pledges
getting eventually fully dropped.

For notifications about suspensions, we decided that notification of
suspension itself is adequate along with a regular status-update
notification (regardless of suspension) so that people are aware of
progress overall. Mostly the decision was to have the absolutely
necessary notifications first, later add optional extra notifications,
basically iterate…




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/03/2016 04:24 AM, mray wrote:
> 
> 
> On 03.08.2016 12:52, Aaron Wolf wrote:
>> On 08/03/2016 01:31 AM, Bryan Richter wrote:
>>> On Wed, Aug 03, 2016 at 01:55:44AM +0200, Robert Martinez (mray) wrote:
>>>> On 01.08.2016 23:30, Michael Siepmann wrote:
>>>>> We discussed this in today's meeting.  Here's a revised mockup,
>>>>> also attached in .ods format. This shows payment processing fees,
>>>>> two successive months of carry-over, and an example where a pledge
>>>>> was suspended:
>>>>>
>>>>
>>>> Thanks for clarifying via the mockup. I think it can be simplified
>>>> in several ways:
>>>>
>>>> https://snowdrift.sylphs.net/prototypes/mray/#history_page
>>>>
>>>> * a pledge value/month next to a total/month isn't necessary. It
>>>> only matters what you actually paid that month. So I would only show
>>>> one sum/month.
>>>
>>> This is different from how all receipts and bills work, which show the
>>> sum-of-goods subtotal, then any fees and taxes, then a final total. Do
>>> we want to keep that just so it's more familiar?
>>>
>>>> * items that did not contribute to a months spending can be omitted for
>>>> clarity.
>>>
>>> Hm. I guess we should ask, is the purpose of this page to show *just*
>>> payment history? I don't think so. I think it is a history of
>>> participation within the mechanism. In that case, omitting items that
>>> don't contribute leads to a *lack* of clarity.
>>>
>>> Also, our hope is that we will be able to sum up a patron's
>>> contributions to all their projects, so they would only be hit by a
>>> single payment charge. In that case, it is impossible to get charged
>>> in April, but have other donations roll forward from April to May.
>>> Either a patron contributes to *all* their projects in a month, or
>>> they contribute to none of them.
>>>
>>> So: whether there is one project, or many projects, there is only one
>>> thing that matters: What do we show for a month where a patron is
>>> pledged, and contributes, but is not charged?
>>>
>>>> Suspended projects are not treated different as non-pledged and should
>>>> not show up specially. Notifications can be used to communicate all 
>>>> details.
>>>
>>> I think the same critique applies. If this page is to show a history
>>> of participation, suspended projects need to show up.
>>>
>>>> * I also like keeping the history tab consistent with the running months
>>>> matching tab.
>>>
>>> +1.
>>>
>>> FYI, I have created a US to track this story, and have pasted in the
>>> mockups so far.
>>>
>>> https://tree.taiga.io/project/snowdrift/us/454
>>>
>>> I've named it according to my understanding that we are talking about
>>> a history of participation rather than just a history of payments, but
>>> please consider that point "open for discussion" still. :)
>>>
>>
>> Just to note: I agree with everything Bryan posted. The numbers should
>> be done in a way that's relatively standard. The purpose of the history
>> page is not just to focus on charges but to emphasize the amount of
>> support and the history of the matching.
> 
> What is the difference of "charges", "history of matching" and
> "emphasize the amount of support" in that context?
> To me they easily translate all to the same.
> 
> You seem to want some extra info that wouldn't be MVP.
> 

Yes, I'm just saying that post-MVP we want to make sure history
emphasizes pride in being a long-term patron. The strict MVP could have
no history. The nice-for-MVP history is just the minimum you describe
that allows auditing ("okay you charged this and it went there, got it").

>>
>> Many projects that accept donations have a leader-board of sorts
>> honoring the folks who've donated the most to the project. I would like
>> to see that sort of thing post-MVP. It should especially honor at the
>> top those patrons who have supported for the longest time and emphasize
>> their time-length of support as the main item.
>>
>>



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/03/2016 01:31 AM, Bryan Richter wrote:
> On Wed, Aug 03, 2016 at 01:55:44AM +0200, Robert Martinez (mray) wrote:
>> On 01.08.2016 23:30, Michael Siepmann wrote:
>>> We discussed this in today's meeting.  Here's a revised mockup,
>>> also attached in .ods format. This shows payment processing fees,
>>> two successive months of carry-over, and an example where a pledge
>>> was suspended:
>>>
>>
>> Thanks for clarifying via the mockup. I think it can be simplified
>> in several ways:
>>
>> https://snowdrift.sylphs.net/prototypes/mray/#history_page
>>
>> * a pledge value/month next to a total/month isn't necessary. It
>> only matters what you actually paid that month. So I would only show
>> one sum/month.
> 
> This is different from how all receipts and bills work, which show the
> sum-of-goods subtotal, then any fees and taxes, then a final total. Do
> we want to keep that just so it's more familiar?
> 
>> * items that did not contribute to a months spending can be omitted for
>> clarity.
> 
> Hm. I guess we should ask, is the purpose of this page to show *just*
> payment history? I don't think so. I think it is a history of
> participation within the mechanism. In that case, omitting items that
> don't contribute leads to a *lack* of clarity.
> 
> Also, our hope is that we will be able to sum up a patron's
> contributions to all their projects, so they would only be hit by a
> single payment charge. In that case, it is impossible to get charged
> in April, but have other donations roll forward from April to May.
> Either a patron contributes to *all* their projects in a month, or
> they contribute to none of them.
> 
> So: whether there is one project, or many projects, there is only one
> thing that matters: What do we show for a month where a patron is
> pledged, and contributes, but is not charged?
> 
>> Suspended projects are not treated different as non-pledged and should
>> not show up specially. Notifications can be used to communicate all details.
> 
> I think the same critique applies. If this page is to show a history
> of participation, suspended projects need to show up.
> 
>> * I also like keeping the history tab consistent with the running months
>> matching tab.
> 
> +1.
> 
> FYI, I have created a US to track this story, and have pasted in the
> mockups so far.
> 
> https://tree.taiga.io/project/snowdrift/us/454
> 
> I've named it according to my understanding that we are talking about
> a history of participation rather than just a history of payments, but
> please consider that point "open for discussion" still. :)
> 

Just to note: I agree with everything Bryan posted. The numbers should
be done in a way that's relatively standard. The purpose of the history
page is not just to focus on charges but to emphasize the amount of
support and the history of the matching.

Many projects that accept donations have a leader-board of sorts
honoring the folks who've donated the most to the project. I would like
to see that sort of thing post-MVP. It should especially honor at the
top those patrons who have supported for the longest time and emphasize
their time-length of support as the main item.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/01/2016 02:30 PM, Michael Siepmann wrote:
> We discussed this in today's meeting.  Here's a revised mockup, also
> attached in .ods format. This shows payment processing fees, two
> successive months of carry-over, and an example where a pledge was
> suspended:
> 
>  

In my view, this is good enough to be a candidate for implementation.
Great work!




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Interaction design mockups

[Aaron Wolf]

On 06/27/2016 04:14 AM, mray wrote:
> 

> The way I understand the proposal of notification would be: "Hey! $10 a
> month seems to be ok with you, and you're currently only using $5 a
> month, but as we want to ensure that projects get funded in the
> future when even more people join maybe you can up that limit to $15
> already, because you know crowmatching works that way that things grow
> kind of. After all you're just spending $5, but your limit of $10 should
> better be higher."
> 

I didn't think there was any such proposal at all. And, to be frank,
that example you give is so obviously bad that it should be clear nobody
would ever support that, so it's a straw-man. I.e. this isn't addressing
something anyone is actually wanting. I think it's more effective to
clarify a proposal by aiming to express it so he proposer will say "yes!
that's it!", and then you can critique the issues you may see with it.

I think the proposal was only that you get regular general status
updates overall, like a notification every couple weeks or every month
showing the change in your pledge values and otherwise you can see your
status on your dashboard page.

And in those general status updates, there would be *some* level (which
would definitely be nothing like using only $5 of $10 limit) that would
indicate getting-close-to-limit. In other words, there would be
absolutely NO request for a limit change, but there would just be a
yellow color around the stat that shows something like "current total
pledge value: $9.23 of $10 budget maximum". It shouldn't ask anyone to
do anything, it just indicates that the current situation is likely to
hit the limit (and thus auto-suspend some pledge) if a decent number of
new patrons join soon.

The only "please consider increasing your budget" message is part of
addressing the situation once the limit is actually hit.

But it is *not* good to provide no indication at all before hitting the
limit. Giving people the information that they are approaching their
limit just helps them see what's happening and keep tabs on it (and
adjust in advance if they feel like doing that, but no pressure).






signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Interaction design mockups

[Aaron Wolf]

On 06/26/2016 05:20 PM, mray wrote:
> 
> 

hope to reply separately to some of the other points in previous email


> On 24.06.2016 11:22, Aaron Wolf wrote:
>>
>> ...
>>
>> 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.
> 
> A valid pledge is valid crowdmatching, always.
> Even if it isn't with one more patron. It then might cease to be
> crowdmatching *then*, but it also isn't a valid pledge *then* anymore
> either.

What I meant is that a pledge of the sort that some people *think* about
but that is *not* a valid pledge in *our* system is not crowdmatching.
In other words, sometimes people say "oh, instead of a $10 budget, how
about I just say 'I'll match the first 2,000 people?'" So, they are
suggesting something where the pledge continues to be marked as active
with 2500 patrons, but they are only matching 2,000 instead of matching
everyone. I was saying that *that* is not valid crowdmatching —
basically this is a nice clean way to quickly explain why our system
*doesn't* work that way. In our system, either you *are* matching the
whole crowd or you're not. There's no option to match part of the crowd.

So, I wasn't proposing a change or anything about alternative approaches
within our system, I was just saying this wording helps clarify what is
or isn't the way Snowdrift.coop works.

> It is just how reaching your limit naturally looks like. The experience
> of reaching a limit should make you proud since you literally went to
> your limits, and it generally means you lifted the stone high enough to
> let stronger people overtake - but also remain ready to help out when
> they may be gone one day. Lets not add stigma to reaching the limit.
> 

I agree reaching a limit should have no stigma. Reaching a limit should
be cause for celebration that the crowdmatching is working!

> We simply can't *know* when people set a $10 limit because they are
> dull, lazy, cowards or just broke.
> 

I think the *vast* majority of pledges will set their limit for none of
those reasons. They will set their limit to be conservative and know
that they system will ask them for permission to go any further.

If people are really broke, we want them to feel minimal obligation to
pledge at all and lots of gratitude for *any* participation.

For most patrons, The initial $10 limit works as "okay, I accept right
now that up to $10 may just happen, but if things go beyond that, I want
to be notified and have a chance to accept or reject the idea of going
beyond $10." Nearly all of them will be able to possibly spend $12 or
$15 or $20 just as easily as they spent $10, but they won't be okay
trying this new system with a high commitment level.

So, we don't want to shame them for not raising their limit, but we *do*
want to say:

"We hope you feel your part of this crowdmatching success was worth it
and the projects you support have shown good progress and good use of
their funds. So, if you're now comfortable with this pledge being worth
it, please consider raising your budget, if you can afford to, and
continue participating as the crowdmatching grows further and makes even
that much more impact!"



> For *our* purposes it should suffice to just globally raise the $0.001
> when people don't reach a critical mass.
> 

Yeah, good point. I agree. It's just a guess minimum anyway, and maybe
it will be the right guess, and we can adjust it globally as needed. I
do think still there are some people who will want to be really generous
at higher levels than average though, but I can accept not having that
considered MVP if that's how everyone else sees it.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Interaction design mockups

[Aaron Wolf]

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 

Re: [Snowdrift-design] Interaction design mockups

[Aaron Wolf]

On 06/13/2016 07:37 PM, Michael Siepmann wrote:
> On 06/10/2016 09:19 PM, Aaron Wolf wrote:
>> On 06/10/2016 04:39 PM, Michael Siepmann wrote:
>>> On 06/09/2016 06:36 PM, Aaron Wolf wrote:
>>>> On 06/09/2016 01:21 PM, 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.
>>>>>
>>>> Thanks, Michael! I like this direction in various ways.
>>>>
>>>> Main item: if we're keeping the global setting for pledge-base-level,
>>>> then there are ramifications of that that need to play out in the rest
>>>> of the mockups.
>>>>
>>>> For example, the amount of cost for a given patron *and* the amount of
>>>> matching in dollars will vary based on this pledge-base variable. A
>>>> generous pledge base will get less than 1:1 matching and the presence of
>>>> generous pledge bases from others will result in a minimal patron
>>>> getting greater than 1:1 matching.
>>>>
>>>> It would be ideal if the interface successfully communicates that this
>>>> is happening and makes the understanding of it clear and
>>>> self-explanatory… The current mockups all have numbers that are when all
>>>> patrons are at a minimum. So what happens in other cases? And is it
>>>> clear enough to people?
>>>>
>>>> Otherwise, I like the 3-benefits informative bit.
>>>>
>>>> Here's an aspect I've wanted that we had in earliest mockups: In the
>>>> place where people can change their pledge-base, a message could say
>>>> "remember, the *best* way to donate more is to promote the project to
>>>> others and gain new patrons (who you will match)" or something to that
>>>> effect. It's nice to note that larger pledge-base could itself provide
>>>> more incentive to others though. My concern here overall is how the
>>>> interface can successfully justify the variable pledge-base and help
>>>> people use it effectively and not counter-productively.
>>> 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.
>>>
>> Nice. Maybe we should have a mockup of what happens if you hit "change"
>> for the pledge level in the dashboard.
> Try the "Change" links for pledge level and monthly max at
> http://techdesignpsych.com/Temporary/snowdrift/dashboard_sufficient.html
> . The "Suggest" button also works, suggesting in this case 20x whatever
> you put in the pledge level multiple field.  The "Change" button doesn't
> actually make the changes, but the idea is you'd return to the regular
> dashboard view with the changes in place.  (If the change you made
> resulted in one or more pledges being suspended, then the dashboard
> would should that of course, but the idea of the "Suggest" button and
> associated messaging is to prevent that from happening for the most part.)
> 

I don't know why I didn't try clicking.

What about using 0.1¢ instead of $0.001 ?

I think some degree of guidance in this case makes sense. I don't find
the "suggest" button transparent though, like why this is the suggestion.

So, there's this concern about thwarting the matching effect by just
adjusting pledge base to unreasonably high base. I could imagine more
clear guidance indicating that 0.1¢ is considered the standard minimum
default. We could make it more clear that 0.2¢ is a "double pledge" or
something like that. We could indicate that the *reason* for a higher
base as an option is for wealthier folks to offer more, or alternately
stated: because the world is full of wealth inequality so we can't
pretend that it makes sense for everyone to be at the same level.

*Ideally* we'd be able to tell people who are millionaires that their
pledge base should be at least 10¢ or something. Basically, some
guidance for levels.

My preference would be an interface with several clear radio options and
an "other" fiel

Re: [Snowdrift-design] Interaction design mockups

[Aaron Wolf]

On 06/10/2016 04:39 PM, Michael Siepmann wrote:
> On 06/09/2016 06:36 PM, Aaron Wolf wrote:
>> On 06/09/2016 01:21 PM, 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.
>>>
>> Thanks, Michael! I like this direction in various ways.
>>
>> Main item: if we're keeping the global setting for pledge-base-level,
>> then there are ramifications of that that need to play out in the rest
>> of the mockups.
>>
>> For example, the amount of cost for a given patron *and* the amount of
>> matching in dollars will vary based on this pledge-base variable. A
>> generous pledge base will get less than 1:1 matching and the presence of
>> generous pledge bases from others will result in a minimal patron
>> getting greater than 1:1 matching.
>>
>> It would be ideal if the interface successfully communicates that this
>> is happening and makes the understanding of it clear and
>> self-explanatory… The current mockups all have numbers that are when all
>> patrons are at a minimum. So what happens in other cases? And is it
>> clear enough to people?
>>
>> Otherwise, I like the 3-benefits informative bit.
>>
>> Here's an aspect I've wanted that we had in earliest mockups: In the
>> place where people can change their pledge-base, a message could say
>> "remember, the *best* way to donate more is to promote the project to
>> others and gain new patrons (who you will match)" or something to that
>> effect. It's nice to note that larger pledge-base could itself provide
>> more incentive to others though. My concern here overall is how the
>> interface can successfully justify the variable pledge-base and help
>> people use it effectively and not counter-productively.
> 
> 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.
> 

Nice. Maybe we should have a mockup of what happens if you hit "change"
for the pledge level in the dashboard.

> I've also added something inspired by the above about encouraging them
> to spread the word:
> 
> http://techdesignpsych.com/Temporary/snowdrift/project_sufficient.html
> 

Whether or not it's best, I imagined the "spread the word" message to
show only right upon confirmation of a pledge, like an alert and wasn't
necessarily wanting it to be a permanent fixture on a page of a pledged
project, just for perspective. Maybe more permanent could be good.

> 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.
> 

I like the term "crowdmatching", don't *love* it. If we tried it out and
had success using it to explain things, it could be good.





signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Interaction design mockups

[Aaron Wolf]

On 06/09/2016 01:21 PM, 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.
> 

Thanks, Michael! I like this direction in various ways.

Main item: if we're keeping the global setting for pledge-base-level,
then there are ramifications of that that need to play out in the rest
of the mockups.

For example, the amount of cost for a given patron *and* the amount of
matching in dollars will vary based on this pledge-base variable. A
generous pledge base will get less than 1:1 matching and the presence of
generous pledge bases from others will result in a minimal patron
getting greater than 1:1 matching.

It would be ideal if the interface successfully communicates that this
is happening and makes the understanding of it clear and
self-explanatory… The current mockups all have numbers that are when all
patrons are at a minimum. So what happens in other cases? And is it
clear enough to people?

Otherwise, I like the 3-benefits informative bit.

Here's an aspect I've wanted that we had in earliest mockups: In the
place where people can change their pledge-base, a message could say
"remember, the *best* way to donate more is to promote the project to
others and gain new patrons (who you will match)" or something to that
effect. It's nice to note that larger pledge-base could itself provide
more incentive to others though. My concern here overall is how the
interface can successfully justify the variable pledge-base and help
people use it effectively and not counter-productively.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Interaction design mockups

[Aaron Wolf]

On 05/24/2016 02:47 PM, Michael Siepmann wrote:


> I like "Please consider increasing your maximum".  On reflection, and
> after experimenting, I'm thinking perhaps that's all we need.  I've
> updated both versions of that dashboard with just that for now.
> 

I realize now that we need to clarify another issue: what happens when
someone chooses *not* to increase their max but to drop a *different*
project than the one auto-suspended?

Obviously, dropping the suspended one, everything just goes back to
normal. Also, if they increase their max, the suspended pledge is
auto-reinstated, right?

If they drop  different project, then the suspended one would also be
reinstated once everything is below max, right? Assuming so, is this
obvious enough without explicitly clarifying? I think so. They can drop
a different project and the page will reload showing the new status, and
then they'll see nothing remains suspended.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Interaction design mockups

[Aaron Wolf]

On 05/24/2016 12:32 PM, Michael Siepmann wrote:
> I've added a pair of dashboards along those lines:
> 
> http://techdesignpsych.com/Temporary/snowdrift/ 
> 

Looks good, looking forward to feedback from others or more nice design
variations from the visual design folks.

One thought: "reflect your wishes" is a little too generous. Someone
might wish for things that go beyond the controls we're offering (for
example, "I wish I could keep donating $2 to that project and not have
to match anyone any further", which we would respond to as "the matching
agreement from everyone is what makes this work, without that, or with a
simple per-project cap, we can't get the widespread cooperation we
need…" At any rate, getting people to think about their wishes is less
desired compared to getting them to think about specifically tweaking
within the "rules of the game" that we've set up.

My inclination for the wording is: "Please consider increasing your
maximum to reinstate all pledges. Alternatively, you may remove pledges
or adjust pledge level as desired."

Something like that. In this case, the only max change that will help is
an increase, so we can say "increase" instead of "change", and I like
encouraging people to think of that as the suggested action.

> 
> On 05/24/2016 12:27 PM, Aaron Wolf wrote:
>> I like this overall, as I said yesterday.
>>
>> I'd like to see the system-wide approach. The "$0.001 per patron,
>> monthly" should be *above* the table shown as a "your pledge level"
>> (probably with the option to change it).
>>
>> Then, the "your pledge" column from the table can be removed.
>>
>> Maybe change "Donation if charged now" to "current pledge value" and
>> then change "Total pledged" to "Total if charged now"
>>
>> And then remove the "Maximum monthly donation" row and instead just put
>> the sentence "your monthly maximum…" below the table instead of above,
>> and have the change button there.
>>
>> So, total is:
>>
>> "pledge level: X per patron (change)"
>> TABLE w/ name, patron-count, current-value, status, remove button
>> "maximum monthly of Y sufficient to match additional Z pledges (change)"
>>
>> How does that sound? I could fiddle with the HTML to update this myself,
>> but rushing around right now. I'd appreciate if someone could make this
>> variant of the mockup for me.
>>
>> Thanks!
>>
>>
>>
>>
>> On 05/24/2016 10:42 AM, Michael Siepmann wrote:
>>> I've put slightly revised versions of the interaction design mockups
>>> some of us looked at via Jitsi Meet yesterday in both the design Seafile
>>> server (snowdrift.sylphs.net) and in browsable form at:
>>>
>>> http://techdesignpsych.com/Temporary/snowdrift/
>>>
>>> There may be a better way to share them in future, perhaps via git, but
>>> for now I just wanted to make them available for discussion etc.
>>>
>>> Best,
>>>
>>> Michael
>>>
>>> -- 
>>>
>>> Michael Siepmann, Ph.D.
>>> *The Tech Design Psychologist*™
>>> /Shaping technology to help people flourish/™
>>> 303-835-0501   TechDesignPsych.com
>>> <http://www.TechDesignPsych.com?id=esig>   OpenPGP: 6D65A4F7
>>> <http://pool.sks-keyservers.net/pks/lookup?search=0x6D65A4F7&fingerprint=on&hash=on&op=vindex>
>>>  
>>>
>>>
>>>
>>> ___
>>> Design mailing list
>>> Design@lists.snowdrift.coop
>>> https://lists.snowdrift.coop/mailman/listinfo/design
>>>
>>
>>
>>
>> ___
>> Design mailing list
>> Design@lists.snowdrift.coop
>> https://lists.snowdrift.coop/mailman/listinfo/design
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Interaction design mockups

[Aaron Wolf]

I like this overall, as I said yesterday.

I'd like to see the system-wide approach. The "$0.001 per patron,
monthly" should be *above* the table shown as a "your pledge level"
(probably with the option to change it).

Then, the "your pledge" column from the table can be removed.

Maybe change "Donation if charged now" to "current pledge value" and
then change "Total pledged" to "Total if charged now"

And then remove the "Maximum monthly donation" row and instead just put
the sentence "your monthly maximum…" below the table instead of above,
and have the change button there.

So, total is:

"pledge level: X per patron (change)"
TABLE w/ name, patron-count, current-value, status, remove button
"maximum monthly of Y sufficient to match additional Z pledges (change)"

How does that sound? I could fiddle with the HTML to update this myself,
but rushing around right now. I'd appreciate if someone could make this
variant of the mockup for me.

Thanks!




On 05/24/2016 10:42 AM, Michael Siepmann wrote:
> I've put slightly revised versions of the interaction design mockups
> some of us looked at via Jitsi Meet yesterday in both the design Seafile
> server (snowdrift.sylphs.net) and in browsable form at:
> 
> http://techdesignpsych.com/Temporary/snowdrift/
> 
> There may be a better way to share them in future, perhaps via git, but
> for now I just wanted to make them available for discussion etc.
> 
> Best,
> 
> Michael
> 
> -- 
> 
> Michael Siepmann, Ph.D.
> *The Tech Design Psychologist*™
> /Shaping technology to help people flourish/™
> 303-835-0501   TechDesignPsych.com
>    OpenPGP: 6D65A4F7
> 
>  
> 
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Discuss project page and dashboard

[Aaron Wolf]

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.



> - #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 

Re: [Snowdrift-design] Discuss project page and dashboard

[Aaron Wolf]

I want to clarify overall:

First, the short answer "oh, you have a budget for the system" is 99% of
the time completely satisfactory to the people who ask the "what if it
gets hugely popular and I have to pay so much?" question.

In other words, it is not accurate to present that question as "the
first question we get asked" implying that it's an outstanding concern.
It's not a concern at all. If we say "you have a budget for the system"
when we explain the system, then that question doesn't even get asked in
the first place.

now…

There are other questions that get asked that are more worth discussing.
Such as "what if a project gets really popular and eats up my budget,
leaving less for others?" and that's where we talk about how consensus
is *good* and we work against fragmentation but that we have ideas for
managing this in the long run if needed, such as the possibility of
categorical budgets or per-project budgets, etc. this is not as simple a
question.

The real question that was brought up here is "what about niche
projects? I may want to support some popular thing, but I *really* care
more about doing all I can for this niche project where fewer people
will join me. Can I set different pledge levels for different projects?"

And for that question, our current answer is: "We're concerned about
that, but our core design will probably work best for the most popular
projects, so we're aiming to make that successful first. However, we
have considered varying pledge levels, it's just that it adds complexity
that is harder to manage, explain, and more." And that's more what the
current discussion is about.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Discuss project page and dashboard

[Aaron Wolf]

On 05/19/2016 12:54 PM, Stephen Michel wrote:
> Thanks for getting the ball rolling on this conversation, Michael.
> 
> On Thu, May 19, 2016 at 12:08 PM, Michael Siepmann
>  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're working on an
MVP here, not reconsidering everything over and over. We never ever ever
say "there will be some safeguard" we always give a concrete answer that
we already decided long ago: "you will set a budget for the system
overall, it's not like we just have your credit card and charge
whatever. If the pledge goes beyond your budget, you'll get a
notification and the be able to choose whether to drop the pledge or
adjust your budget."

The only thing that is "there may be SOME x" is the "project so popular
that many people can't afford to pledge" which has the answer of "we
will be a success already if we get to where that is our problem, but we
have ideas about the best ways to handle that. It's not a major problem
though — people dropping out due to high pledge value is a natural
self-correction to high pledge value. but read the limits wiki page for
more thoughts"

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.

> 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.

> 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.

> 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.

Number 3 here creates a huge extra variable for people to do something
quite different from just pledging-or-not. Instead, they are starting to
do all sorts of complex juggling of budget values for multiple projects.
It's complex, harder to track… I don't want us to consider this for MVP
or just-after MVP.

Effectively, this does revisit the whole concept of "shares" in that
it's part of trying to address the whole issue of wanting to really
support some important project big time but not caring as much about
some minor project etc. It's not crazy. But it's definitely complex.

For initial use, we don't have to create per-project budgeting or
per-category budgeting. People could just create two users and have them
each budget different amounts. This is a more serious issue: not wanting
people to game the system by creating many patrons accounts just to get
matched more. But a certain amount of this isn't fatal.

Anyway: https://snowdrift.coop/p/snowdrift/w/en/limits/c/1998

All that said, if we had the resources to research all these options and
implement them all, I'm not opposed. But I oppose the idea of choosing
number 3 alone and going with that first. It is definitely an
alternate-maybe-later option, not acceptable as the initial only option
(although for a one-project MVP it's the same)

> I think #3 is the best. Here's why:
> 
> ---
> 
> (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 inval

Re: [Snowdrift-design] Ethereum

[Aaron Wolf]

On 05/09/2016 01:41 PM, mray wrote:
> Hello there,
> 
> I'd like to get feedback from people who know this kind of stuff:
> a blockchain based platform that sounds interesting -
> https://www.ethereum.org
> 
> It looks like with it you can create your own Bitcoin-like system that
> is as decentralized as Bitcoin but allows to add more rules. I was
> wondering if snowdrift.coop could be an "democratic autonomous
> organization" harnessing that technique.
> 
> It might be only a hip buzzword trophy - or maybe not so bad at all. Is
> it crappy to think about doing our pledging that way?
> 
> 
> mray
> 
> 

My feeling is that this stuff is untested largely in the real world and
is more speculative than Snowdrift.coop. Bitcoin itself may have gotten
some weird attention from a surprisingly large number of people, but it
is actually a tiny fraction of even the already-limited set of people
who already understand free/libre/open issues who have actually got into
Bitcoin and related.

So, even if Bitcoin and Ethereum were perfectly sensible technologies,
the vast majority of the audience we're aiming for has little connection
or awareness or interest in those things.

Besides that, I am a Bitcoin skeptic and think the claims people make
about its significance and potential are overblown. The amount of mere
electricity used to run Bitcoin stuff if it actually reached widespread
adoption seems completely unworkable from my lay-person view. I think it
will never become truly mainstream.

If I'm wrong, and these technologies become significant, we can use them
then. It's an implementation detail, not a major design factor. There's
no realistic path to getting running as a more decentralized blockchain
implementation. I don't think that direction makes much sense as the
core foundation for anything. It's just something we can support as a
side aspect if and when it actually seems worthwhile.




signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] MVP pages

[Aaron Wolf]

On 03/24/2016 03:52 AM, mray wrote:
> During the last meeting with iko and chreekat we compiled the list of
> pages that seem to be needed for MVP:
> 
> @Michael:
> 
> 
> welcome
> /about (the project organization for newcomers: team, contact info, etc)

as long as the about page links to all appropriate stuff so that people
can get from there to wherever we have important content…

> /dashboard (overview and status of pledges and balance)

sure

> /login
> /logout
> /create-account
> /change-passphrase
> /reset-passphrase
> /set-passphrase

I thought we would have an "auth" subsite, and so just to clarify, I
don't have any real opinion, and it's not my area, but did we want the
login and passphrase stuff to be all under /auth/ ? Or is that more just
a backend aspect that won't be presented in terms of the url?

> /terms
> /privacy
> /trademarks
> /how-it-works
> /sponsors
> /p
> /p/snowdrift


> /honor-pledge (replaced with wiki link)

The honor pledge is a separate interaction-design issue. I don't insist
but do like the idea of it being included. Linking to wiki is not the
same as an interactive acceptance of the pledge. However, the point of
the pledge is largely in relation to communication and so relates to
wherever we have communication tools… there is a real tension with all
this in that we don't have clarity right now about how we will manage
moderation in our communication areas during MVP etc. I very much miss
having the actual integration that we'd built with our discussion system.

I don't want to see the value of the design we had be disregarded here.
So, I'm really only okay with pushing it to a side etc. if we make it
clear that it's a compromise for now in order to focus on MVP and that
we keep it presented clearly that we still prioritize this and will work
to figure out our eventual integration.

The Code of Conduct *may* be as or more important than the honor-pledge
in terms of making things clear. This topic in general needs more
discussion.

> /js-licenses (replaced by link to license text file in gitlab repo)
> 

The point of js-licenses is not just to be human-readable but to be
recognized by LibreJS. It's only okay to change this into some sort of
link if LibreJS still works.

> 
> we also concluded that those pages would *not* be needed for MVP:
> 
> /u
> /u/#user
> /about/contact
> /about/team
> /about/press

These about pages are only okay to remove from MVP if there are at least
links to the info or it is at /about at the top level. I'm not convinced
that removing the separate pages is helpful in any way. I definitely
think people will expect to see things like a standard link for
"contact" and that we need to have such a link, whether it goes to just
/about or /about#contact vs /contact or /about/contact (my personal
preference would be /contact actually)

> /transactions
> /pledges
> /how-it-works/sustainable-funding
> /how-it-works/co-op
> /how-it-works/network-effect
> /how-it-works/flo

we can avoid these internal how-it-works pages only if the main
/how-it-works page includes links for more reading that goes to the wiki
or something.

> /donate

I'm only okay with leaving out the /donate page for the full MVP where
we are accepting actual funds and have that all clear. Also, to be
blunt, it creates substantial extra tension on the way toward MVP to not
have financial support right now. I haven't emphasized this as much as I
should, but our struggling financial situation right now is a real issue
that shouldn't be downplayed. So, we will need to balance these things.
We don't want to encourage donation separately when people can instead
pledge, but if someone wants to give us a large grant (different from a
modest donation), I want to do all we can to encourage that. These
things could be make-or-break significance potentially.

> /honor-pledge (replaced with wiki link)

you just said above that /honor-pledge *would* be in the MVP (i.e. you
listed it in both sections)

> /merchandise

Hesitant to lose this, not sure removing it is positive, but I'm okay at
least putting off the decision. Merchandise is rivalrous so not
competing directly as a concept versus the regular pledge

> /search
> /js-licenses (replaced by link to license text file in gitlab repo)
> 

like honor-pledge, js-licenses was listed above already (in both keep
and remove), and as I said above, the purpose is to be LibreJS
compatible. The MVP should stay LibreJS compatible. It's not that much
work. Don't deprecate that unless there's some reason to do so.



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting

[Aaron Wolf]

On 02/02/2016 09:37 AM, Bryan Richter wrote:
> On Tue, Feb 02, 2016 at 09:13:51AM -0800, Aaron Wolf wrote:
>>
>> So, again, moving to Gitit would be ideal
> 
> FWIW I think we should try to avoid talking about implementation
> details when deciding on design and vision questions. Tech is
> important to design inasmuch as it sets the boundaries of possibility,
> but actual tech decisions should only truly follow design decisions.
> 

Okay, the design proposal I'm asking for here is that we indeed have a
Git-backed wiki as integrated in the site as we can.

My concern in this case is that I think to avoid extra formalities, and
the practical existence of the Gitit codebase, I'm pushing toward
actually accepting the pros/cons/limitations of Gitit for now. In other
words, I want the decision to be that we work with what's available
realistically and go with that and adapt it.

So, let's not discuss further here, the issue is to make decisions via
the new process of user stories and sorting priorities in OpenProject.
That said, I think sometimes there's value in saying, "let's not spend
time designing our optimal process, let's use Gitit as an existing base
and just make the most of it." because sometimes we need to accept a
path that works and go forward rather than deliberate on every case. And
this is one where I'm proposing a specific path because it seems
practical enough and adaptable to the overall design vision, even if
that's not totally finalized. Still, I know that even that path will go
better when we understand the priorities more clearly.

___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] Introductary Materials and the WIki WAS: Some notes from today's meeting

[Aaron Wolf]

On 02/02/2016 09:09 AM, Bryan Richter wrote:
> On Tue, Feb 02, 2016 at 02:36:19PM +, Michel, Stephen J. wrote:
>>> - The top priority user story is someone coming to the site and
>>   understanding what it is.
>>> - Introductory material is still up for discussion -- making sure the
>>   introduction is as effective as possible is (now and always) a very
>>   high priority.
>>
>> I'm currently working on *organizing* the material that's currently
>> on the wiki. My work is currently local but if anyone's interested
>> in helping out I can make it available online. I have some thoughts
>> on how we should organize the material, but I'll wait on hashing
>> them out; there are a couple unresolved questions on my mind.
> 
> This sounds great. Maybe to give yourself space to keep working, but
> to not feel like you're keeping people "in the dark", want to plan to
> give a report in X days? A week maybe?
> 
>> 
>> Given some sources that suggest a wiki may actually discourage
>> participation (because people feel they're not knowledgeable enough
>> and are afraid to overwrite old content), I'm a fan of providing two
>> ways to edit an informational page:
>>
>> 1. Pull request to git.gnu.io, or wherever we end up permanently
>>hosting our site code
>> 2. A "suggest edits" button on each page which functions like a
>>wiki-style edit button, but instead creates a pull request from
>>their edits. That way even those unfamiliar with git can
>>contribute and become involved.
> 
> I'll leave it to the design team for final decisions, but this sounds
> pretty cool to me. I might suggest against creating literal pull
> requests, though. That would require tossing all the html at the user.
> In the short term, it might be better to let them have a textentry to
> describe suggestions in free-form.
> 

I hope to review all this more soon, but the idea of "suggest change"
and Git-based changes to pages for participation seem ideal, see this
thread:

https://snowdrift.coop/p/snow-wiki/w/en/wiki/c/3491

So, again, moving to Gitit would be ideal because it's a wiki backed by
Git that uses the same Haskell and Pandoc base as the rest of the site,
and we could then have controls about how the wiki edits worked and
otherwise have Git control over the content without making this live in
the level of compiled hamlet code or something.


___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] homepage text

[Aaron Wolf]

On 02/01/2016 01:09 PM, Michael Siepmann wrote:
> On 02/01/2016 01:19 PM, Michael Siepmann wrote:
>>
>> On 01/29/2016 07:35 AM, Stephen Michel wrote:
>>
>>> On January 28, 2016 11:02:18 PM EST, Aaron Wolf  
>>> wrote:
>>>> In the midst of all the SCaLE stuff, this thread got lost. Following up
>>>> finally.
>>>>
>>>> On 01/08/2016 08:04 AM, Michael Siepmann wrote:
>>>>
>>>> 
>>>>> here are a few variations that occur to me:
>>>>>
>>>>>   * Catalyze the commons.
>>>>>   * The commons catalyst.
>>>>>   * Catalyst for the commons.
>>>>>   * Catalyzing creation of public goods.
>>>>>   * Nourish the commons.
>>>>>   * Grow the commons.
>>>>>   * Nurturing a thriving commons.
>>>> Although I appreciate all these thoughts, I prefer "free the commons"
>>>> as
>>>> far clearer. I understand these are just suggestions for prompting
>>>> discussion. My feeling about "free the commons" is that there are
>>>> things
>>>> that have *fundamental* nature as commons / public and they are *in
>>>> jail* in some sense. The feeling is: there's technology and science and
>>>> knowledge that by nature are public commons and some actors have
>>>> actively restricted them, so we are out to free them.
>>>>
>>>> Yes, we are focused on helping the things that are already free but
>>>> need
>>>> support. However, the mission is to *take away* the funding from Adobe
>>>> Photoshop and give it to GIMP *or* convince Photoshop to become FLO
>>>> commons. We don't *just* want GIMP to be better, we want to see the end
>>>> to the proprietization of the otherwise-commons. And even if we shy
>>>> away from being that bold in much of the messaging, that general call in 
>>>> that
>>>> direction is good.
>>> I don't think "Free the Commons" is the absolute best slogan we could have, 
>>> but given that we have already had this conversation and could not find a 
>>> better alternative, I think at the least we should not have this 
>>> conversation again until the alpha sprint is over.
>> That works for me.  Re Aaron's comments above, I can see how "Free the
>> Commons" makes sense once fully explained.  I just think it's far from
>> self-explanatory or quick to grasp for a newcomer.  One solution
>> might, however, be to keep the slogan as "Free the Commons" but make
>> sure all the other introductory material quickly gets newcomers to a
>> point where "Free the Commons" makes sense to them.
>>
>>>
>>>> 
>>>> I really like your suggestion:
>>>>
>>>> "We help people cooperate to sustainably fund projects that create
>>>> shareable, freely-licensed public goods that benefit everyone."
>>>>
>>>> I almost went ahead and just updated the homepage. However, I kinda
>>>> feel this has too many qualifiers still. Instead of an active word
>>>> "cooperate" the main verb is "help" and it's "projects that create"
>>>> instead of just goods themselves. And "shareable, freely-licensed" is a
>>>> bit like extraneous definitions.
>>>>
>>>> But I'm not sure enough about my concerns to conclude much. So I want
>>>> others to weigh in.
>>>>
>>>> The simplest, shortest wording would be:
>>>>
>>>> "We cooperate to sustainably fund public goods. Join us!"
>>>>
>>>> I'm not sure enough about that to propose it as the final solution, but
>>>> if everyone likes it…
>>> This is what's currently on the site:
>>>
>>> "Like roads we all share, freely-licensed works are public goods that 
>>> benefit everyone. So, we need to cooperate to sustainably fund them"
>>>
>>> I think the first sentence is very good at setting the tone and explaining 
>>> succinctly. The second, not so much. Perhaps just "We cooperate to 
>>> sustainably fund them."
>> Although I agree the first sentence is generally very good, I find
>> "Like roads we all share" a bit wordy and awkward to read. How about
>> "Like public roads"?  For the second sentence, I think "we" has
>> problematic ambiguity

[Design] Snowdrift.coop weekly meeting today

[Aaron Wolf]

Hi everyone,

We have a new project management tool we'll use for meetings going
forward. Please consider registering a user:

http://shovel.snowdrift.coop/meetings/2

Meeting is 20:00 UTC (12 noon pacific) today (soon) at
https://meet.jit.si/snowdrift

Cheers

-- 
Aaron Wolf
co-founder, Snowdrift.coop
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Design] animation ideas for snowdrift dilemma etc

[Aaron Wolf]

FLO *does* have a remarkable amount of volunteers given the situation,
but we're still struggling greatly.

I'd like to see an animated video that explains the dilemma like this:

There's a couple roads completely covered in snow.

At first, the public road has a few people coming to shovel. They have
small shovels and are not very efficient. They come and go, sometimes
there are more, sometimes less. The look like they are making some
progress, but it's slow, lots to do.

Somewhere in the midst of this, two or three huge snow-plows come up to
the other road, start clearing it much more effectively, and they
construct toll booths with cameras and billboard ads.

Then, we see a status quo like the recent poster we've done.

Effectively, the status-quo of the public road isn't totally covered in
snow, it's getting usable, but it's not there yet. Tons of time and
effort has been put in, but it still doesn't compare at all to the power
of the snow plows. If only we had either or both (A) more volunteers (B)
funds to hire our own snow plows but on our terms without the other
bullshit.

The point is to acknowledge the work that is done by highlight how
pathetic it is in *some* ways compared to the resources the proprietary
stuff has. We're not saying FLO status quo is hopeless, we're just
saying it's really rough still and struggles to compete despite being
more honorable.

The later part of the same video or a second video in a series would
show the FLO folks making the Snowdrift.coop pledge and gathering
cooperative support and funding to hire snow-plows for the public road.
And thus explain in that animation how the Snowdrift.coop pledge works.

We can clarify that this isn't really for *roads* per se, because we
have *taxes* to fund public roads already. But we don't have taxes to
fund FLO software enough or FLO journalism or art or education etc. Our
pledge is the best way to fill the gap in the absence of taxes, *and*
it's voluntary, democratic, and flexible in ways that traditional tax
systems are not.

We could put this idea on a wiki or track it somewhere, or people who
feel up for it could start story-boarding or working on it or whatever,
if there's support for the idea.

-- 
Aaron Wolf
co-founder, Snowdrift.coop
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Design] homepage text

[Aaron Wolf]

In the midst of all the SCaLE stuff, this thread got lost. Following up
finally.

On 01/08/2016 08:04 AM, Michael Siepmann wrote:


> First, re "Free the Commons" you may well be right that it's the best
> possible option, and I know I'm missing the context of all the work all
> of you did to come up with it.  I also agree that, when considered in
> light of additional explanation as you provided above, it makes sense. 
> However, I would still keep the door open for the possibility that
> feedback or ideas from outsiders may lead to an even better
> possibility.  Just as ideas that may or may not have come up in previous
> discussions, and /not/ to argue for changing the tagline right now, here
> are a few variations that occur to me:
> 
>   * Catalyze the commons.
>   * The commons catalyst.
>   * Catalyst for the commons.
>   * Catalyzing creation of public goods.
>   * Nourish the commons.
>   * Grow the commons.
>   * Nurturing a thriving commons.
> 

Although I appreciate all these thoughts, I prefer "free the commons" as
far clearer. I understand these are just suggestions for prompting
discussion. My feeling about "free the commons" is that there are things
that have *fundamental* nature as commons / public and they are *in
jail* in some sense. The feeling is: there's technology and science and
knowledge that by nature are public commons and some actors have
actively restricted them, so we are out to free them.

Yes, we are focused on helping the things that are already free but need
support. However, the mission is to *take away* the funding from Adobe
Photoshop and give it to GIMP *or* convince Photoshop to become FLO
commons. We don't *just* want GIMP to be better, we want to see the end
to the proprietization of the otherwise-commons. And even if we shy away
from being that bold in much of the messaging, that general call in that
direction is good.


> Second, re changing wording on the home page before getting feedback at
> SCALE, all of your three bullet points above seem good to me.  Here's a
> suggested rewrite of the text below the "How it Works" button,
> incorporating your three proposals above and also changing "We
> sustainably fund" which I think gives the wrong impression that
> Snowdrift.coop actually provides the funding (like a grant-making
> foundation) and "and we cooperate to help them" which seems a bit
> unclear to me:
> 
> We help people cooperate to sustainably fund projects that create
> sharable, freely-licensed public goods that benefit everyone.
> 
> Join us! 
> 

I really like your suggestion:

"We help people cooperate to sustainably fund projects that create
shareable, freely-licensed public goods that benefit everyone."

I almost went ahead and just updated the homepage. However, I kinda feel
this has too many qualifiers still. Instead of an active word
"cooperate" the main verb is "help" and it's "projects that create"
instead of just goods themselves. And "shareable, freely-licensed" is a
bit like extraneous definitions.

But I'm not sure enough about my concerns to conclude much. So I want
others to weigh in.

The simplest, shortest wording would be:

"We cooperate to sustainably fund public goods. Join us!"

I'm not sure enough about that to propose it as the final solution, but
if everyone likes it…

Cheers,
Aaron

___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Design] initial SCaLE follow-up snowdrift meeting in an hour

[Aaron Wolf]

Last minute reminder, video chat meeting 20:00 UTC (1 hour from now):
https://meet.jit.si/snowdrift

First of a lot of discussions we'll have about going forward given
valuable perspectives and connections following our booth at the
Southern California Linux Expo.

Cheers!

-- 
Aaron Wolf
co-founder, Snowdrift.coop
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Design] Snowdrift meeting in 2 hours, final pre-SCALE

[Aaron Wolf]

Hi everyone,

We've been juggling a lot of things, won't go into details right now.

In 2 hours, 20:00 UTC (12 noon pacific), we'll have the final weekly meeting 
before SCALE this weekend.

Come join us at https://meet.jit.si/snowdrift

Cheers,
Aaron
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Design] project page specs

[Aaron Wolf]

Okay, I took the initial brainstorm after our discussion and finished a
draft of the actual specs for the project landing page:

http://flurry.snowdrift.coop:2040/shared/ahH1vsFBjbhHRsLW-5n-6uMjPLTwnd9x7LSec-eH_Iw

We should probably move this to the wiki where we can have a more
permanent and better formatted spec page and associated discussion page
separately.

This should for right now be adequate to implement aside from discussing
the questions I added to a questions section.

The brainstorm part below is the rough sketch and notes / discussion
that led to where we are now.

FWIW, the implementation really should focus on getting the stuff Robert
already mocked up and figuring out how to get that into an updated
branch we can build off of. However, we do not want to put on the live
site the junk test-data stuff, we want to have this working with a real
project: us for now. So, we should make sure all the pieces are in place
that are alpha important (marked with an A on the spec)

None of this is set in stone, thanks everyone for helping push this forward.

Cheers


-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Design] meeting Monday 20:00UTC

[Aaron Wolf]

Hi all,

Meeting soon: 12:00 Pacific, 20:00 UTC https://meet.jit.si/snowdrift

This is the penultimate pre-SCALE meeting.

Topics we'll focus on:

Finalizing plans for priorities for a working project page by SCALE, see:
http://flurry.snowdrift.coop:2040/shared/POPQtPUKoA32H-emf5M3tGkan7nUfA358-57NCBF0j9

Finalizing print issues for banners, business cards, etc. for SCALE

other promotional and organizational things (such as blog posts,
community issues both pre-SCALE and for how to best engage and benefit
from connections at SCALE)

If anyone new joins us, we will happily welcome them and any topics they
want to bring up or otherwise be happy to have them just present or
participating to whatever extent they feel comfortable.

Thanks everyone!

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] Getting intro messaging feedback at SCALE

[Aaron Wolf]

Thanks Michael!

I think your wording is improved, but maybe "…one of us at the booth"
just for clarity?

Otherwise, I think it's good to go, but just needs to update the screen
shots to match whatever we have at the time we print in about two weeks.

On 01/06/2016 03:50 PM, Michael Siepmann wrote:
> On 01/05/2016 02:09 PM, Aaron Wolf wrote:
>> 
>> Looking over the screen-shots already, and in light of discussion about
>> metaphors, I propose we clean up the wording (which wasn't carefully
>> thought through yet) first.
>>
>> * how about "Join us!" instead of "Join us in setting…" ?
>> * maybe for now we drop the "Let's clear the path…" line? (although I
>> like the clear-the-path for the metaphor, I don't like the rest of that
>> line)
>> * I was emphasizing this more before, but I'm going to push for it a
>> little more strongly now: I think we should use the term "public goods"
>> in our introductory context (and thus the term will be there for people
>> to provide feedback about). It's the best, most accurate term, and the
>> question is whether it comes across clearly, hence feedback forms like this…
> I agree about "public goods".  (I think this discussion fits better in
> the other thread ("4 issues priority") so I'll reply there soon.)
>> 
>> Two minor notes:
>>
>> * I don't really like the title case on the tent
> I've changed it to sentence case.
>> * The "Now please discuss" sounds a bit too strongly imperative, like it
>> isn't optional, you must now do this, even with the please. Not sure how
>> to improve, maybe just put underneath the "optional" heading or have
>> another "optional" marker?
> I see your point but I don't want it under "Optional".  It's really
> supposed to be an integral part of the feedback process whenever
> possible, though I certainly don't want people to feel pressured to stay
> and chat if they don't want to.  How about this?:
> 
> *Thank you!* Now please give this to one of us. If possible, we'd
> love to discuss it with you to make sure we fully understand your
> feedback and answer all your questions.
> 
>> 
> I'll get the fonts installed on my computer.
> 
>> Overall, I think this will be really helpful, great work, thanks! 
> Glad you think so - you're welcome!
> 
> Best,
> 
> Michael
> 
> 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Design] Process toward full specs for project page

[Aaron Wolf]

I've now drafted all the core items for the needs of the page for each
project here:

http://flurry.snowdrift.coop:2040/shared/3G5iuOrbvc-mPUJvIUsV0fSYD9MGzoU_W44wSa6cYn0

The current mockup from Robert serves some but not all the issues I
brought up, there are some questions, and there are concerns about the
tab-navigation design in the mockup, and various other issues.

Lets discuss from here and

1. come to consensus about the full final spec

2. figure out which parts of the spec to aim for by SCALE

3. among the MVP, SCALE items, prioritize

4. assign / claim tasks

So we're at step 1 still despite having some good stuff to start with
there. Everyone, please help us finalize that step ASAP.

We can use the *chat* part of the etherpad, some posting on this email
list is acceptable, and we can do IRC and video chats wherever appropriate.

Cheers,
Aaron

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] Getting intro messaging feedback at SCALE

[Aaron Wolf]

Nice!

On 01/05/2016 12:42 PM, Michael Siepmann wrote:
> On 12/30/2015 09:17 PM, Michael Siepmann wrote:
>> On 12/30/2015 03:45 PM, Aaron Wolf wrote:
>>> On 12/30/2015 12:47 PM, Michael Siepmann wrote:
>>>> Good to meet several of you via Jitsi Meet on Monday.  Here is an
>>>> initial draft idea for a way to get feedback on introductory messaging
>>>> from people who visit the Snowdrift.coop booth at SCALE. 
>>>>  
>>>> 
>>  
> 
> Here are drafts of feedback response sheets for booth guests and a
> tent-style sign to put on the table next to the stapled response
> sheets.  I tried printing the response sheets double-sided in
> monochrome, and I think it will work OK that way.  Printing in color
> would be somewhat preferable for the screenshots but is not essential.
> 

Looking over the screen-shots already, and in light of discussion about
metaphors, I propose we clean up the wording (which wasn't carefully
thought through yet) first.

* how about "Join us!" instead of "Join us in setting…" ?
* maybe for now we drop the "Let's clear the path…" line? (although I
like the clear-the-path for the metaphor, I don't like the rest of that
line)
* I was emphasizing this more before, but I'm going to push for it a
little more strongly now: I think we should use the term "public goods"
in our introductory context (and thus the term will be there for people
to provide feedback about). It's the best, most accurate term, and the
question is whether it comes across clearly, hence feedback forms like this…


> For those of you who will be hosting the booth, it's probably worth
> printing it out too for purposes of reviewing this draft in the form it
> will be used.
> 

Yes, once we think it's a final "release candidate" so to speak, and I
think it's very close.

Two minor notes:

* I don't really like the title case on the tent

* The "Now please discuss" sounds a bit too strongly imperative, like it
isn't optional, you must now do this, even with the please. Not sure how
to improve, maybe just put underneath the "optional" heading or have
another "optional" marker?

> I also plan to draft a short guide for hosts / interviewers.
> 

Great!


> (The .odt files use fonts I have in Ubuntu 15.10.  In case you don't
> have the same fonts I'm attaching as .pdf too.)
> 

For future reference, we have fonts connected with the design which
should be at least considered for things like this (although they are
focused as being web fonts over print I think). See
https://snowdrift.coop/p/snowdrift/w/en/design-guide#fonts

Note that the fonts files are included in the snowdrift codebase
already, so you can get them there rather than hassle with downloading
otherwise.


> Best,
> 
> Michael
> 
> 

Overall, I think this will be really helpful, great work, thanks!

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] shirt colors

[Aaron Wolf]

On 01/05/2016 11:41 AM, Diana Connolly wrote:
> Yes, Mock up the warm grey. 
> 
> 

Okay, I 'll try to add that immediately. Should we also remove the "more
choices" links or keep them? (I can still order some tests of other
colors like Heather to see how they turn out)

> 
> On Tue, Jan 5, 2016 at 11:40 AM, Aaron Wolf  <mailto:aa...@snowdrift.coop>> wrote:
> 
> 
> 
> On 01/05/2016 11:26 AM, Bryan Richter wrote:
> > There seems to have been a major foulup in communication about shirt
> > colors.
> >
> > Diana chose shirt colors and got consensus on those colors. Some of
> > the colors she chose are on backorder for ladies's sizes, but they're
> > still available. Then, those colors were scrapped entirely and
> > different ones were added to the newly-created /merchandise page. That
> > page also unhelpfully links to the entire available palette, which is
> > also contrary to the original plan (paradox of choice, dilution of
> > brand).
> >
> 
> You're somewhat mistaken. Only the cool blue women's is back-ordered.
> 
> Diana's light-color (Light Gray) does not EXIST in women's.
> The both-sex light colors are white and *maybe* heather-gray if that
> works enough, but we need to print and see if it turns out light enough.
> 
> Diana said she thought that Cool Blue was GOOD and we should use it
> because it's nice *and* matches the site.
> 
> The whole summary is: there are TWO good dark shirts Diana suggested;
> but the light shirt situation is tough (reasons… …), and yet that's the
> more conservative basic design :P
> 
> So, Robert made his mockup with that situation, and we asked about
> whether Warm Gray should be added to the mockup, but nobody replied
> on that.
> 
> I don't like the "more choices" per se, and that's why it was asked
> about on the list, and I asked Diana also, but she didn't object or
> directly address that (but did tell me that *she* would like Warm Gray).
> 
> > There were a few emails in this thread that were, unfortunately, too
> > long and unfocused for me to have time to read. Was it one of those
> > that discussed these changes?
> >
> 
> Okay, sorry about the length.
> 
> > Are we all satisfied with the current state of affairs?
> >
> 
> Well, Diana told me she doesn't mind the situation, but I don't know if
> she would think that showing Warm Gray would be better or worse. I'd
> like that answered potentially.
> 
> > I basically didn't want to think about this anymore, except now I'm
> > choosing a shirt color for myself and don't feel comfortable choosing
> > something that very few other people will ever wear.
> >
> 
> I don't think Warm Gray is too weird, and I was going to get an extra
> for myself in that color. This is a test run sort of, and we can
> re-order later.
> 
> I'd like a decision from Diana about whether we should emphasize /
> mockup the Warm Gray.
> 
> > On Sun, Dec 20, 2015 at 11:18:21AM +, William Hale (Salt) wrote:
> >> Would someone start a new thread with mock-ups of the final options?
> >>
> >> Thanks!
> >>
> >> On Fri, 18 Dec 2015 11:20:33 -0800
> >> Diana Connolly  <mailto:diana.conno...@gmail.com>> wrote:
> >>
> >>> Quite simply, all we need now is the final graphics in a form I can
> >>> hand off to Bluemill, and a choice of sizes and colors for at least
> >>> 24 shirts. Remember, shirt color changes cost nothing.
> >>>
> >>> If people would like to start sending me their choices, I will
> >>> compile a list.
> >>>
> >> _______
> >> Design mailing list
> >> Design@lists.snowdrift.coop <mailto:Design@lists.snowdrift.coop>
> >> https://lists.snowdrift.coop/mailman/listinfo/design
> >>
> >>
> >> ___
> >> Design mailing list
> >> Design@lists.snowdrift.coop <mailto:Design@lists.snowdrift.coop>
> >> https://lists.snowdrift.coop/mailman/listinfo/design
> 
> --
> Aaron Wolf
> co-founder, Snowdrift.coop
> music teacher, wolftune.com <http://wolftune.com>
> 
> --
> Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
> ___
> Design mailing list
> Design@lists.snowdrift.coop <mailto:Design@lists.snowdrift.coop>
> https://lists.snowdrift.coop/mailman/listinfo/design
> 
> 

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] shirt colors

[Aaron Wolf]

Hi Stephen,

Your proposal makes chooses Cool Blue and Warm Gray, and actually, those
two would probably be the best colors, but I don't think Warm Gray will
work with the light design… Basically, everything is better with dark
shirts.

There's actually no need per se for light shirt to be light, it's just
that the cleaner conservative design with the shovel image works best on
a light shirt.

I agree this is too much time and is frustrating. It would take a couple
more paragraphs for me to even discuss the options now.

QUESTION: Should we add the Warm Gray to the mockups specifically? Try
it with the light design?

On 01/05/2016 11:35 AM, Michel, Stephen J. wrote:
> Proposal:
> 
> 1. Pick two colors, and two colors only.
> 2. Both colors must be available in both Mens and Womens.
> 3. One must be warm, and one must be cool.
> 4. One must be dark, one must be light.
> 
> In short, offer Cool Blue and Warm Grey colors (if I haven't gotten all the 
> constraints mixed up -- can someone confirm that these two colors fit my 4 
> above constraints?), and be done with it. We've spent far too much effort on 
> this already, IMO.
> 
> From: Design [design-boun...@lists.snowdrift.coop] on behalf of Bryan Richter 
> [b...@chreekat.net]
> Sent: Tuesday, January 05, 2016 14:26
> To: design@lists.snowdrift.coop
> Subject: Re: [Design] shirt colors
> 
> There seems to have been a major foulup in communication about shirt
> colors.
> 
> Diana chose shirt colors and got consensus on those colors. Some of
> the colors she chose are on backorder for ladies's sizes, but they're
> still available. Then, those colors were scrapped entirely and
> different ones were added to the newly-created /merchandise page. That
> page also unhelpfully links to the entire available palette, which is
> also contrary to the original plan (paradox of choice, dilution of
> brand).
> 
> There were a few emails in this thread that were, unfortunately, too
> long and unfocused for me to have time to read. Was it one of those
> that discussed these changes?
> 
> Are we all satisfied with the current state of affairs?
> 
> I basically didn't want to think about this anymore, except now I'm
> choosing a shirt color for myself and don't feel comfortable choosing
> something that very few other people will ever wear.
> 
> On Sun, Dec 20, 2015 at 11:18:21AM +, William Hale (Salt) wrote:
>> Would someone start a new thread with mock-ups of the final options?
>>
>> Thanks!
>>
>> On Fri, 18 Dec 2015 11:20:33 -0800
>> Diana Connolly  wrote:
>>
>>> Quite simply, all we need now is the final graphics in a form I can
>>> hand off to Bluemill, and a choice of sizes and colors for at least
>>> 24 shirts. Remember, shirt color changes cost nothing.
>>>
>>> If people would like to start sending me their choices, I will
>>> compile a list.
>>>
>> ___
>> Design mailing list
>> Design@lists.snowdrift.coop
>> https://lists.snowdrift.coop/mailman/listinfo/design
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
> 

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design