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

[Stephen Michel]

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.


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

Re: [Snowdrift-design] new video script draft

[Stephen Michel]

Snipping wildly to respond to one specific thing.

On Fri, Jan 13, 2017 at 4:53 AM, mray  wrote:

I expect to work on this inside the design circle and seek
acceptance/feedback when there are results to talk about.


For the record, there is no design *circle*, since circles are 
organized around a shared purpose, not a shared skill set. There's a 
website circle and an outreach circle. Each contains  a couple design 
roles.
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Snowdrift-design] Reference -- UX of charities

[Stephen Michel]

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
-- 
Sent from my phone; please excuse my brevity.
Email policy: http://smichel.me/email___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] new video script draft

[Stephen Michel]

PREFACE: I agree with nearly everything you said; If I didn't 
explicitly disagree, consider me agreed.


On Fri, Dec 23, 2016 at 4:38 PM, Aaron Wolf  
wrote:


```
NEW SCRIPT:

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.

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 a monthly limit for the system
overall.

Working together, we can have significant impact at little individual
cost. 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 clear the path to a free and open
future!
```

THOUGHTS/EXPLANATION:

First, this is a bit wordier and goes by a bit fast just to keep it
under 1 minute. I know this is stretching the acceptable length. Maybe
we can find ways to shorten it that are worth the benefit of being
shorter, but I want each decision to consider whether that's worth the
trade-off.

The overall idea is for people to actually grasp the system and have 
the

sense that this really isn't another copy of what they've seen before.


Additional thought: As we go through this, we need to think of what 
illustration we are going to pair with each segment.



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.


* I tried to fit in a statement about what your choices are when you 
hit

your budget, but there's just no way to fit it in unless we accepted a
longer video time. Otherwise, I find this wording very clear, even
though a pithy shorter version is possible.


What's the pithy shorter version?

 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.

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



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.


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.


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.


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.


I think it can and should still be improved a little, but is good 
enough that we can use it, if push comes to shove and we haven't found 
anything better yet.


Based on all that, here's my attempt. There's a couple places (noted 
below) where the wording is very much not final. That's fine.


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

For each project you wish to support, you pledge to 

Re: [Snowdrift-design] Intro video script

[Stephen Michel]

On Sat, Dec 3, 2016 at 2:16 PM, Michael Siepmann 
 wrote:


On 12/01/2016 07:52 AM, mray wrote:

 On 30.11.2016 07:30, Aaron Wolf wrote:
 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.


 Just "collaboration" does not capture what we are about. Like-minded
 people can collaborate without us. We offer a *NEW* way to do so.
 A short take that bridges to the following explanation:

 my tentative 4c.
   At Snowdrift.coop everybody collaborates in a new way;


I think "empowers" and "/you/ care about" are important. I don't like
"collaborate" because it sounds like something that would take /time/
that I cannot spare, vs. just a simple decision to share a small 
amount
of my money. Overall I think 4b is much too abstract and vague - 
"build

greater support for" is vague, as is the generic reference to  "public
goods". It sounds to me like something I might agree that some 
committee

somewhere ought to do, but that doesn't sound particularly exciting or
engaging to me personally.


I also like "empowers" and "you care about". If we want to make it less 
wordy, I think we can drop "Our innovative platform" and just say 
"Snowdrift.coop" or "Crowdmatching".


Aaron, can you say more about in what ways you're not happy with 4a?  
I
think tweaking 4a a bit is a much more promising direction than 
anything

like 4b.
 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…"


 Here is a new take:
 * being discrete
 * visualizing
 * working with contrast

 my tentative 5c.
   Patrons pledge *only one 10th of a cent*!!...
   – but – for *every* other patron of a project.

   A group of 10 agrees on paying *a cent each*!!...
   – but – A *crowd* of 1000 already agrees to pay a dollar each.

   When a crowd gets too big for you - step back any time.


I like the concreteness of $1 for every 1000 patrons, but I'm 
concerned

that it is easily misunderstood as meaning you donate zero until there
are 1000 patrons, then $1 until there are 2000 patrons, then $2, etc.
But I like that it's easier to relate to than a tenth of a cent. Maybe
"1 cent for every 10 patrons" would be a happy medium here? That's
arguably more accurate since of course we can't actually charge people
in tenths of a cent increments.


I actually had this same thought, when I was looking at the dashboard 
and thinking that it's kind of odd to display the pledge level as .5 
cents and the project income as 2.5 cents, when actually at that level 
no crowdmatch will happen.


It's off-topic for this discussion, but **IFF** it simplifies the code, 
we could consider making the mechanism actually function in discrete 1 
cent intervals.



Otherwise, 5a seems a bit wordy and complex, including the switch into
first person. Here's one possible revision, with the "For example"
sentence being optional, but helpful if it can fit I think:

tentative 5d. "First you set an overall monthly budget. Then, for 
each project you want to support, you pledge to donate 1 cent per 
month for every 10 patrons who support that same 

Re: [Snowdrift-design] Intro video script

[Stephen Michel]

On Fri, Nov 25, 2016 at 11:11 PM, Michael Siepmann 
 wrote:


I'm thinking that in this super-short intro, it would be better to 
omit

any reference to a snowdrift. It's just too confusing, not necessary
enough, and doesn't help to engage people right away. People can find
out why we're called Snowdrift.coop later, but here they just need to
know, understand, and feel positive about and interested in the core 
of

what Snowdrift.coop is about.

As to the "free" qualifier discussion, I think it's absolutely 
critical

to remember that the overwhelming majority of the world has not the
faintest idea that a phrase like "free music" ever means anything 
other

than "music you don't have to pay for".


Very +1. When I talk with people about snowdrift, my biggest challenge 
is usually breaking them out of this assumption that music or software 
MUST be copyrighted, or if it isn't, the artist/programmer must not be 
getting paid for it.


It's not relevant here, but the best tool I have found so far is to 
liken it to contract photography. I contract with a professional 
photographer to get my picture taken, they get paid up front and 
they're happy with that money for the work, and then I'm free to 
reproduce and share the photos however I want (sometimes photographers 
keep the copyright, but not all do, and it's enough that people 
understand this is a business model that works better).



Here's an idea omitting the Snowdrift reference. I've done quite a bit
of other editing which I can explain if that would be helpful.


I also like this script.


SUGGESTION/

When music, software, movies, news, research, and so on, are released 
as

public goods, everyone can enjoy them freely, without limitations.


Does "public goods" have enough recognition that people will know what 
we're talking about with just that?

What about "unrestricted public goods"? Pros: Clarity. Cons: Redundancy.
No strong opinion, just wanted to put it out there.


But who will pay for them to be created?

Snowdrift.coop's pioneering crowdmatching platform empowers you to 
join

with others to fund the public goods /you/ want created.

You pledge to donate a tiny amount each month for each patron who
supports a project with you, within a budget you control.

Your donation is matched by the rest of the community, building
consensus that directs support to the most promising projects.

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


Does "clearing the path" still make sense given that we don't mention a 
snowdrift any more?



/SUGGESTION


Both of these are nitpicks, make of them what you will.

Excitement building,
Stephen

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

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

[Stephen Michel]

When this video is complete, I'd like to make it into a series of gifs 
with text, to post on imgur (which, issues with the platform aside, has 
a large community that I think might be sympathetic to our cause) or 
elsewhere.


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

Re: [Snowdrift-design] Mockup of account history

[Stephen Michel]

On Wed, Aug 10, 2016 at 7:01 PM, Stephen Michel 
<stephen.mic...@tufts.edu> wrote:

Some great, intense, back and forth. I ask that Michael and mray pause
your discussion for a moment, because I have another perspective I 
want

to throw into the mix that may change the discussion somewhat and I'd
like to avoid you wasting time, but it might take me an hour or few to
get that written.


Alright, here goes. In short, we should use mray's version for MVP. 
Shortly after, we should add *in addition* Michael's version, heavily 
revised.



Mray is right that we need to provide two distinct representations to 
serve different use cases. But it's not simple vs complex. It's two 
different sets of information, each of which should be as simple as 
possible while still showing everything that needs to be shown.


I didn't realize the use cases myself until Michael identified them, 
though he may not have realized it yet. They are:


1. A history of *charges* (flow of money)
2. A history of *pledges* (history on our site)


Longer:

1. Bob is dong his accounting. He checks his credit card / stripe 
history, and wants to know exactly what that charge is for. As far as 
Bob's credit card is concerned, May's pledge *doesn't* exist until July 
1st, when June's pledge is fixed (though during the month of June, Bob 
may be interested in his outstanding balance). Bob's credit card also 
doesn't care about suspended projects; they look just like projects 
he's not supporting.


2. Alice is thinking about what software she uses in her daily life and 
whether she wants to start supporting any new projects, drop any old 
projects, etc. She wants to know what projects she's been supporting 
and for how long, whether she's ever dropped them, whether her pledge 
is successful in raising more crowdmatching funds or whether the 
project has stagnated with few patrons, etc. Alice is very much 
concerned with the difference between a suspended pledge and a dropped 
pledge, etc. She doesn't have a care in the world for whether a payout 
happened in March



Mray is designing for Bob and Bob alone. That's all we need for MVP, as 
Bryan tried to get to heart of. The only changes I might suggest (some 
already discussed) are:


- [Important] Add the date of charge. Bob needs the date of charge so 
he can cross-reference with his credit card bill.
- [Important] Add what the monthly limit was at the time. Bob wants to 
verify that we didn't exceed his limit.
- [Optional] Remove the number of patrons. Bob doesn't care about them, 
he cares about how much he paid. The reason we might keep this number 
is that WE want Bob to think and care about how big of a crowd he is 
matching.
- Show this on the dashboard home page. By default, show only pending 
charges -- no history -- and the limit. At the bottom, have a "show 
more" or "show history" button to reveal previous months.


Michael is trying to design for both Bob and Alice. This would be the 
superior approach, if we were required to have only one view of the 
history. But we're not, so I think we should let mray's design serve 
Bob, and modify Michael's to serve only Alice.


- Remove any information about feeds, rollovers, and credit card 
charges. Alice doesn't care about those details. Basically, remove 
anything below "total pledge value this month" in your original mockup.

- Show this in its own tab.
- Include more visual styling to enable tracking a given project over 
time. Per-project coloration, a timeline view... things like that.



So far, there's been a lot of discussion about whether one set of goals 
are more important than another. I hope this email convinces you that 
both sets of goals are important and worth supporting (though only one 
is necessary for MVP), so you're now in alignment and can focus on the 
best way to support both Alice and Bob.


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

Re: [Snowdrift-design] Mockup of account history

[Stephen Michel]

Some great, intense, back and forth. I ask that Michael and mray pause 
your discussion for a moment, because I have another perspective I want 
to throw into the mix that may change the discussion somewhat and I'd 
like to avoid you wasting time, but it might take me an hour or few to 
get that written.


On Wed, Aug 10, 2016 at 5:58 PM, Bryan Richter  
wrote:

In terms of the bare minimum we need to let people support Snowdrift
through a crowdmatching mechanism, a payment or activity history is
not strictly necessary.

Consider there to be a more immediate milestone, the "shut up and take
my money" milestone. To complete such a milestone, I'm not even sure
we need both a dashboard *and* a project page. Which should we nail
down first? Given the simplicity of the goal, I think they might be
more or less identical at this embryonic stage.

Of course, as soon as we hit that milestone we will want to start
adding the other assurances and niceties.


Bryan is, as usual, right about this. For the "shut up and take my 
money" (suatmm) milestone, all that is needed is to show whether you 
are currently a patron and what the current pledge level is.


There are no limits on this milestone, so we don't need to worry about 
showing partial rollover. So all we need for history is a text receipt 
view as follows:


Apr 2016: $0.52
May 2016: $0.86
Jun 2016: $1.10
Jul 2016: $2.44
  Subtotal: $4.92
Stripe Fees: $0.34
Charged $5.26 on 2016-08-02
---
Aug 2016: $2.67

Package that in whatever graphics you want, that's all the info we 
need. We *could* add a "Running total" column to that. Could. Remember, 
this is just to get us through until we add an actual dashboard/history.


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

Re: [Snowdrift-design] Mockup of account history

[Stephen Michel]

On August 8, 2016 1:30:11 PM EDT, Michael Siepmann  
wrote:
>On 08/02/2016 05:55 PM, mray wrote:
>> * items that did not contribute to a months spending can be omitted
>for
>> clarity. Carried over pledges appear on the respective new month.
>> Suspended projects are not treated different as non-pledged and
>should
>> not show up specially. Notifications can be used to communicate all
>details.
>
>I strongly disagree with this. I think omitting this information
>creates
>lack of clarity.  I think we should assume that users will rarely look
>at the history, but that when they do, it's because they want to
>understand where their money went (or didn't) and why.  That includes
>knowing that it where it did *not* go that they might have expected it
>to go, e.g. to a suspended project, and knowing why they were *not*
>charged that month, i.e. because balance was carried over.

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. 

>> * I also like keeping the history tab consistent with the running
>months
>> matching tab.
>
>I do not think consistency with the main dashboard view should be a
>goal
>here.  They have very different purposes.  The purpose of the main
>dashboard view is to show your limit, your current pledges, your amount
>available to crowdmatch others, and especially the *relationship*
>between these.  This means it makes sense to use a lot of space to make
>the relationship clear.  In contrast, the purpose of the history is to
>clearly and concisely show and explain a historical record of
>transactions.  A familiar format like an account statement, that makes
>efficient use of space is much better here, in my view.

I think having the history be consistent with the main dashboard view is 
desirable but less important than a clear record of transactions.
-- 
Sent from my phone; please excuse my brevity.
Email policy: http://smichel.me/email
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Interaction design mockups

[Stephen Michel]

On Thu, Jun 2, 2016 at 5:25 AM, mray  wrote:

On 24.05.2016 19:42, 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.



Project page:

* A changing pledge level ($0,001) isn't MVP so we can ignore it for 
now


* "All your pledges" comes with a lot of data that isn't really tied 
to

the project page. To me this is an invitation to start comparing,
calculating and weighing things against each other. In fact we want to
avoid that and only raise awareness when problems do arise. We want
people to focus on their binary choice of support, not estimating how
cheap things are on average and "budget" along those thoughts. Things
will evolve, and we need to make people stay with us when projects
"explode".


+1 to both. In addition to pushing people in a direction we don't 
really want, I also found it odd that information about my account was 
showing up on the project page. I would expect a project page to show 
information about the project, and my status as a patron of it, but not 
general account info.



Dashboard:

* I'd like to address what seems to be fear #1 when it comes to the
financial part: the limit.


I do not really understand the purpose of showing a number that is 
twice the current limit. It seems pretty arbitrary.



* "Status" is only relevant if thinks are not ok, so unless there are
problems that shouldn't be there


+1

* "Action" could be integrated a bit more to make this feel less like 
a

dry listing of numbers


I actually like the dry numbers with separate action button more.


https://github.com/jdittrich/quickMockup


That's a cool tool! I'll convert my modifications[1] to Michael's 
mockups to that format / based off yours.


[1]:http://stephenmichel.me/mockups-dashboard/

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

Re: [Snowdrift-design] Interaction design mockups

[Stephen Michel]

I made some additions to Michael's mockups, specifically for choosing a 
payment source. You can see them here: 
http://stephenmichel.me/mockups-dashboard/


You can see my full thoughts in the Taiga user story here: 
https://tree.taiga.io/project/snowdrift/us/384


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

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

[Stephen Michel]

I was planning on just making a good 'ol fashioned paper-and-pencil 
sketch to start. I've looked at Pencil in the past and while it does 
leave something to be desired, it is functional, and seems to be the 
best/most popular FLO mockup tool.


On Fri, May 20, 2016 at 6:38 PM, Michael Siepmann 
<m...@techdesignpsych.com> wrote:
Somewhere in the recent emails between Stephen and Aaron (which I've 
looked through but not read every word of) Stephen referred to 
working on a mockup.  I think mockups are what we really need at this 
point, to ground this discussion and start focusing on how to make 
this look straightforward enough from the user's point of view.  They 
don't need to be complete page mockups and certainly not 
high-fidelity visually designed mockups.  They can be rough partial 
wireframes to start representing proposals for the basic information 
and controls the user will interact with.


Stephen: In what format are you making a mockup?  How soon do you 
think we could look at it?  I'm interested in trying Pencil 
(https://github.com/prikhi/pencil). Unfortunately the tool I have the 
most experience with currently is proprietary (Axure RP) and I'm 
eager to start exploring and learning how to use a FLO alternative.


(By the way, I unfortunately have a conflict on Monday and won't be 
able to be at our regular meeting.)


Best,

Michael

Michael Siepmann, Ph.D.
The Tech Design Psychologist™
Shaping technology to help people flourish™
303-835-0501   TechDesignPsych.com   OpenPGP: 6D65A4F7

On 05/20/2016 12:06 PM, Bryan Richter wrote:

I'm kinda... not reading too much of these right now, but there was a
question I could sorta answer:

On Thu, May 19, 2016 at 11:12:24PM -0400, Stephen Michel wrote:

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

This is partially dependent on the API of the payment processor.
Stripe has two options, one of which is "managed accounts". With that
option, users won't have to have their own Stripe account. I'm not
certain what the workflow for getting their payment data is, but I'm
pretty sure it involves Stripe's UI. At any rate, we'll never
see it, and it will be pretty streamlined.

Right now there are two likely stories. They are:

1. The Admiral

- User pledges to a project, and damn the torpedoes.
- If they're not logged in, they can log in, and/or create an account
- If they don't already have a managed account, it is set up
- If they don't have any funding limits set, they are asked to 
specify

  what maximum amount of money they want to donate per month.
- The become pledged to the project.
- ...
- Monthly, their pledge(s) are processed, and they donate an amount 
up

  to the limit they set.

2. The Spy

- User holds their breath and creates an account
- User cautiously pokes around the dashboard and /how-it-works
- User feels more confident, and goes to the dashboard and chooses to
  make funds available
- They set up a managed account
- They specify a maximum amount of money to donate per month
- Finally, they poke around the available projects, and pledge to 
one.

- ...
- Monthly, their pledge(s) are processed, and they donate an amount 
up

  to the limit they set.

Note: both of these are "arrears" methods. I believe they are safer
and simpler than "pay upfront" methods. Even though I prefer the
latter for a few different reasons, I'd like to stick with "safer and
simpler" for now.


___
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

[Snowdrift-design] [non MVP food for thought] Fwd: per-project budgets

[Stephen Michel]

This is an excerpt from the conversation Aaron & I had. It was separate 
initially because it's not MVP but this is now fairly short and has IMO 
the most interesting points.


--
Email Policy: http://stephenmichel.me/email

-- Forwarded message --

From: Aaron Wolf <aa...@snowdrift.coop>
Subject: Re: Stuff I cut from the design list thread NNTR
Date: Fri, 20 May 2016 13:19:30 -0400
To: Stephen Michel <stephen.mic...@tufts.edu>

On 05/20/2016 08:26 AM, Stephen Michel wrote:
 On Fri, May 20, 2016 at 9:46 AM, Aaron Wolf <aa...@snowdrift.coop> 
wrote:

 On 05/20/2016 06:02 AM, Stephen Michel wrote:

 If you always increase your budget as needed, you're not really
 budgeting, so that's trivially true. The point is that each time
 you hit your per-account budget, you need to decide which 
project
 you would drop if you decide not to increase --O(n) in the 
number
 of projects--, and then decide whether to increase or drop-- 
O(1).

 With per-project budgeting, you've essentially made the first
 decision once, in advance, so you don't need to make it over and
 over again: the one you would drop is the one that's currently
 hitting it's cap.

 The only reason there's a cap is because that's a fundamental need 
for

 people to feel comfortable trying the system. It would be totally
 unreasonable for us to charge people as though they didn't have
 budgets. We RESPECT that people have budgets. It's not something we
 want in terms of our mission though!!


 I think there's a second reason here, too: the reality is that some
 people are on strict budgets -- but they want to help out anyway.
 Budgeting is a necessity to enable their participation.



Yes, participation is a goal in and of itself, so that's valid. But it's
secondary to funding FLO, as in if funding FLO versus participation are
in *conflict*, Snowdrift.coop would aim for funding *if* no other values
were compromised. If two options were equal for funding and one was more
participation, we'd absolutely go with that.

This is why I *support* the option of adding budget categories (e.g.
"graphics software" vs "music" vs "research vs "Firefox") that provide
options for patrons to set up their own budgeting. It's just definitely
long past MVP (especially since nobody early on will be hitting budget
limits because that will only come after we get enough patrons anyway.

 As you point out that does come with a cost of making budgeting a 
bigger

 focus for the people who we don't want to budget. Maybe that's a cost
 we're not willing to pay, or maybe there's another solution that 
doesn't

 incur that cost.


I think the solution is to make budgeting an optional feature. But I
think this is something we can discuss once we are launched and have
data and research, and then Michael and Robert will have definite
insights here too.


 (feel free to summarize this aspect of our conversation (your
 misunderstanding if you accept that) in a summary post to the list
 clarifying the view you hold now after this)


 I'm going to reply there soon, just didn't have time at a computer 
when

 I woke this morning.

 If you hit your budget overall and refuse to increase, you 
can
 choose which projects to drop, which is the same effect in 
the

 end as per-project budget.

 It's actually an algorithms / efficiency / optimization problem,
 to reduce the number of individual decision points you need to
 make -- either way you're making the same decisions, it's a 
matter

 of how many times you need to repeat the action of making those
 decisions.

 That's stuff that needs post-launch real-world data.


 Data would be helpful, yes. I don't know I'd say it's *required* for 
the
 initial design. But I'm nitpicking; we'll have a chance to get data 
and

 iterate later.


Yeah, we can't require initial data, but that's why we have a design
already: the system-wide budget (whether one-time or recurring, still to
be decided there).




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

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

[Stephen Michel]

Linking the relevant Taiga pages again for visibility:

Dashboard: https://tree.taiga.io/project/snowdrift/us/67

Project Page: https://tree.taiga.io/project/snowdrift/us/321

There was a small amount of initial work done in those places, I've 
added another little bit to that.


On Fri, May 20, 2016 at 12:16 AM, Aaron Wolf <aa...@snowdrift.coop> 
wrote:

On 05/19/2016 08:12 PM, Stephen Michel wrote:

 This email thread is about a design for the project and dashboard 
pages.
 Whether the limit is set on the dashboard page or the project page 
when

 pledging (or both) *is* an MVP decision. So is whether to include a
 wallet in addition to a monthly budget.


When the limit is *first* set, it will be system-wide per-patron. That
is a done decision for initial launch, not something to discuss 
further.



Whether the UX has the user set it when making their first pledge or
separately is a UX design decision that isn't final.

Yes, the decision on effectively a "wallet" is also open (even if we
charge in arrears still, it would be one-time authorizing of a total
amount versus a monthly authorization).


Between this and our out-of-band conversation, I'm satisfied / 
convinced that a lot of what I brought up is post-mvp (more than just 
point B) and has been adequately discussed in the past, so I'll try to 
trim out even more of my own non-mvp nonsense.


or (option 2) a $10 monthly max (which could roll-over so that it 
counts

as a $120 annual max but some months could go over $10, or we don't do
that sort of thing, just an idea)


For MVP I'd leave out a rolling balance.

 with #2 I can modify my limit at any time up until the monthly 
payout.
 - #1 as discussed a while ago requires me to maintain a 3 month 
minimum

 balance; #2 does not.


Yes, I agree about the 3-month balance being different, but you've
mistaken the details. We never proposed a 3-month balance being
*maintained*, we only proposed that a 3-month balance at current 
levels

be available to *place* a pledge initially.


Thanks for the clarification, I didn't realize this. That makes a 
wallet a much more palatable option.



 That third point is the biggest difference. If a project gains huge
 popularity overnight and eats up all 3 months' funds in a single 
month,

 I'll feel betrayed by the system. With #2 this is not possible.
 Therefore #2 is the more effective safeguard.


The "project gains huge popularity overnight" is a speculative thing
we'll be studying and not pre-optimizing for although we want to
consider it in our discussions. This is stuff the limits page 
describes.

We should certainly have notifications of huge pledge value changes.
There's no reason to feel betrayed, I don't understand that expression
in this case. I suspect it comes from your misunderstanding of the
3-month thing, as I clarified above.


That is indeed where "betrayed" comes from. Specifically the feeling of 
"I thought I was keeping a balance for three months and now suddenly 
it's gone in just one?!?!"


You are, of course, correct that this is speculation. The problem is, 
it's a common thing that people speculate about, and so they end up 
concerned even though there is no need to be. So the important thing is 
not to *actually* prevent it from happening, but to *reassure* people 
that it will not happen (or that they'll have a chance to back out if 
it does) so that they'll be comfortable signing up.



 Yes, automation can make some people uncomfortable. This is better
 solved, for example, by requiring me to manually confirm my budget 
this
 month, and adding a setting to auto-confirm [1], than building two 
whole

 different workflows.


I wasn't proposing "whole different workflows". If we offer both
one-time and monthly, the workflow would be almost the ame, and you'd
just say X one-time vs Y monthly-recurring as two choices in the same
interface with nothing else different. The monthly-recurring
authorization would itself *count* as meeting the 3-month buffer for
new-pledges. The UX would be almost identical in both cases.


I think I see what you're envisioning, and I like it. It's easier 
communicated visually so I'm going do to that, and then perhaps 
continue this conversation on the relevant taiga user stories.



 The part of this that IS relevant to MVP is: at what stage of the
 process does it make most sense for me to set my budget? When I 
pledge,

 or when I authorize Snowdrift to charge my Stripe account?



what order does that happen in? I'm not sure. And yes, these are
important design decisions.

One smooth option: I already see the pledge button when just a 
visitor.

Clicking it prompts me that I need to register as a user first. Then
maybe I'm back at the button still needing to click it again? Or 
assume

upon registration that the button is clicked in this case? Not sure.
Then, prompt for Stripe credentials and set a budget right then, 
maybe.


Needing to click a

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

[Stephen Michel]

Aaron and I chatted and he asked me to include an apology for 
brain-dumping to the list (so he won't have to add another email to 
this thread).


We'd both like to hear more opinions, so I've re-arranged and quoted 
very selectively; hopefully this makes it easier for you to jump in 
(especially to reply to just one section). Some nuance is lost; you can 
get it from Aaron's full email if it's needed.


On Thu, May 19, 2016 at 5:38 PM, Aaron Wolf <aa...@snowdrift.coop> 
wrote:

On 05/19/2016 12:54 PM, Stephen Michel wrote:

 On Thu, May 19, 2016 at 12:08 PM, Michael Siepmann
 <m...@techdesignpsych.com> 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 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.



 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.



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


In the Mechanism, Transactions, and Limits wiki pages and their 
discussions, the only relevant post I can find is the one you linked. 
It is short and does not respond to everything in this email. There are 
parts I disagree with. It has no replies.


Unless I'm missing something, I contend that this horse is neither 
bruised nor dead. 



["This isn't relevant"]


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.


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



 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.


Well, *any* safeguard has to perform a certain duty, so only subtle 
differences are possible. If we use a scale of "barely different at 
all" to "a little different", I think #1 (wallet) and #2 (monthly 
limit) are quite dissimilar.


- #1 requires me to manually authorize funds, #2 does so automatically.
- #1 does not allow me to change my mind after I've deposited funds; 
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.


That third point is the biggest difference. If a project gains huge 

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

[Stephen Michel]

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:

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.

2. Patrons set a monthly budget for their account.
3. Patrons set a monthly budget for each project.

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.


---

(B) Post-MVP, it's a simpler decision (albeit one that's made more 
often)


When I run over my budget, I have to decide whether to increase it or 
drop a project. In the per-project case, I need to make that decision 
for one project only. For an account-wide budget, I need to make that 
decision for every project I'm supporting.


When I'm pledging to a new project, the account-wide case forces me to 
consider whether I'd rather put my budget towards projects I'm already 
supporting, since projects compete against each other for a share of my 
budget.


This disincentives to supporting multiple projects; that's NOT the type 
of "rule of the game" we want to be creating. It also puts the 'Pledge' 
action behind a complex decision. This will discourage people from 
pledging regardless of how the incentives align.


---

(C) It reinforces the idea of matching

For example, it would allow us to show a visualization of a project's 
current funding level and also the pool of money available for matching 
as others join a project.


We could also include a visualization that shows how increasing your 
budget cap bolsters that pool of available funds (and therefore 
provides a stronger incentive for others to pledge).


---

(D) It's more like normal budgeting

"I'm setting aside $X per month for this project (even if I may not 
actually give all of that this month)."


The closest comparison I can think of to an account-wide budget is a 
shopping budget, where you're buying the same stuff each time, and the 
prices for individual things might change but your budget won't. Unlike 
shopping, though, Snowdrift is a donation, not a transaction, so I'm 
not (or shouldn't be) concerned with getting the best deal ("sales") -- 
ie, only support projects when their pledge level drops; when they 
start losing patrons.
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] PSA: I assume you're also on the snowdrift discuss mailing list

[Stephen Michel]

To the discuss list and anyone reading this in the archive: this is 
cross-posted to the other lists.


On Sun, Mar 27, 2016 at 5:54 PM, Stephen Michel 
<stephen.mic...@tufts.edu> wrote:
On Sun, Mar 27, 2016 at 1:41 PM, Peter Harpending 
<pe...@harpending.org> wrote:

On Sat, Mar 26, 2016 at 06:48:58PM -0400, Stephen Michel wrote:
 Attached is a little diagram of how I think of the mailing list 
membership.


 I don't believe there's anything official about how they're set 
up, but
 you'll still possibly miss info if you're not on a higher-level 
mailing
 list. I'd also *like* to make that view of the mailing lists 
official, in

 the future.

 Cheers,
 Stephen


Most of the discuss list (recently, at least) is about stuff I don't
care about [...] [and] there have been 48 messages in March alone.

If you would like me (and I assume many of us) to subscribe to the
discuss list, it needs to be about things of general interest


I agree with all of this. Specifically:

1) The umbrella list should be low-traffic.
2) The umbrella list should be about things that are relevant to 
*everybody* who cares about snowdrift.coop.
3) The recent stuff about meetings and governance/operations needs 
its own list.


I will endeavor to post less frequently to the discuss list, until we 
have a better solution.


An update! We found an old, hidden mailing list that was no longer in 
use: t...@lists.snowdrift.coop. It has been re-purposed into an open 
but moderated list for operational discussions, including meetings, 
governance (Holacracy), and project management. This should cut down 
significantly on the amount of traffic on the discuss mailing list, and 
the traffic that remains should be more relevant to anyone interested 
in Snowdrift.coop -- for example, it's where we announced that we have 
moved our wiki [0], ticketing system [1], and git repo [2] to new 
locations.


I hope this makes the discuss list more appealing to be signed up for, 
which will in turn make it a more useful place to have universally 
relevant conversations.


Cheers,
Stephen

[0]: http://wiki.snowdrift.coop/
[1]: https://tree.taiga.io/project/snowdrift/
[2]: https://git.snowdrift.coop/groups/sd
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] PSA: I assume you're also on the snowdrift discuss mailing list

[Stephen Michel]

On Sun, Mar 27, 2016 at 1:41 PM, Peter Harpending 
<pe...@harpending.org> wrote:

On Sat, Mar 26, 2016 at 06:48:58PM -0400, Stephen Michel wrote:
 Attached is a little diagram of how I think of the mailing list 
membership.


 I don't believe there's anything official about how they're set up, 
but
 you'll still possibly miss info if you're not on a higher-level 
mailing
 list. I'd also *like* to make that view of the mailing lists 
official, in

 the future.

 Cheers,
 Stephen


Hello,

I assuredly don't speak for everyone. However, I think I could provide
for a case study. I have no interest in design or law, so I'm not
subscribed to those lists.

Most of the discuss list (recently, at least) is about stuff I don't
care about, like governance, holacracy, meetings, events, etc. 
Moreover,

the messages occur very frequently, so it's difficult to ignore
them. There have been 48 messages in March alone. Hence, I don't
subscribe to the discuss list.

If you would like me (and I assume many of us) to subscribe to the
discuss list, it needs to be about things of general interest, that
concern the majority of the community. Stuff about governance, 
meetings,

project management, and what not should go in its own mailing list.

Peter Harpending


I agree with all of this. Specifically:

1) The umbrella list should be low-traffic.
2) The umbrella list should be about things that are relevant to 
*everybody* who cares about snowdrift.coop.
3) The recent stuff about meetings and governance/operations needs its 
own list.


At the same time, it's silly to have a discussion that pertains to 
everybody in 4 different places because there's no good way to reach 
everyone. So when something like that comes up, I just send it to 
discuss and hope for the best.


..which is why I sent this email in the first place -- because I know 
there are people like yourself who are not on discuss (for whatever 
reason) and thus missing out on that type of email (like: should we 
switch from the mailing lists to Discourse? I personally want to do 
this, and soon; I think it'll solve the issues we're talking about here 
-- but I also want to give a chance for everybody to chime in).


I will endeavor to post less frequently to the discuss list, until we 
have a better solution.


I re-attached the picture from the original email, since I didn't 
originally send it to this (discuss) list.
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Snowdrift-design] PSA: I assume you're also on the snowdrift discuss mailing list

[Stephen Michel]

Attached is a little diagram of how I think of the mailing list 
membership.


I don't believe there's anything official about how they're set up, but 
you'll still possibly miss info if you're not on a higher-level mailing 
list. I'd also *like* to make that view of the mailing lists official, 
in the future.


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

Re: [Snowdrift-design] MVP pages

[Stephen Michel]

On Fri, Mar 25, 2016 at 3:31 PM, mray  wrote:



On 24.03.2016 21:29, Michael Siepmann wrote:

 I'm also not clear on how the honor pledge fits in to MVP, given 
it's

 about editing wiki pages and posting discussion comments?


I should mention, we *do* have wiki pages, currently at 
snowiki.rel4tion.org, which is intended to be moved to 
wiki.snowdrift.coop in time for MVP. So there is some merit to having 
an honor pledge, I think. However, at least currently wiki accounts are 
separate from snowdrift.coop accounts. If it stays that way, we can 
keep honor as wiki pages and have people accept the honor pledge when 
they sign up for a wiki account.



You're right this needs to be removed.
I think it does not fit the MVP or the account creation in general.
We should embraces racist trolls as long as their only interaction 
with

us is to give money to projects that meet our standards.

We may want to have something in place as soon as we offer any other
kind of interaction or communication.


For MVP, this means "as long as their only interaction with us is to 
give us money." /nitpick
___
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

[Stephen Michel]

On February 2, 2016 12:48:18 PM EST, Aaron Wolf  wrote:
>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.

This is only a decision to make if we decide a wiki is the best form for this 
information. 

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

I agree, let's table the discussion for the moment. I also agree it seems 
reasonable that we would end up using Gitit in some form or another. We can 
figure out the details when we have a better idea of what we want from the 
system, from the user story work in OpenProject. 
___
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

[Stephen Michel]

On February 2, 2016 12:09:02 PM EST, 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?


I should be at a reasonable pause point today or tomorrow; I'll send out an 
email then.

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

If the backend is markdown, I think that would be ok to show the user.

The interface I would propose would be near-identical to how wikis work right 
now, except change the 'save' button to 'submit change request', etc. It allows 
people who don't yet understand git to submit change requests.

If needed, we could add a written note informing a user that if they don't know 
how to make the changes themselves they can simply write their suggestion in 
the comment field.___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] animation ideas for snowdrift dilemma etc

[Stephen Michel]

On January 29, 2016 5:14:14 AM EST, mray  wrote:
>
>
>On 29.01.2016 05:46, Aaron Wolf wrote:
>> 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 -snip-

I think this is a really good idea. Further, it would be really cool if we used 
it as an intro video for our home page. Much as you describe, then when the 
video reaches the end, it "rewinds" to where Mimi and Eunice are standing in 
front of the un-cleared road, zooms in and/or changes angle a bit, and boom, 
you've got our current home page.

There's more specific ideas I could write here on how we could modify your 
storyline to make it fit this use, but..

>This is not a priority to spend time on for now.

I have to agree that this is not a priority. The amount of resources a 
well-done animation would take puts it off the table of things I think we 
should attempt before we are launched and self-funded.
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] Elements needed for new homepage deployment

[Stephen Michel]

On November 17, 2015 5:12:34 PM EST, Aaron Wolf  wrote:
>So, I really want to see things pushed up to master sooner rather than
>later.

Agreed.

Proposal: Near-immediately deploy to live, even if things are broken, with the 
with the following change: Add a global header with whatever disclaimers are 
necessary. Much like many European sites do to deliver their mandatory cookies 
message, it should be above the normal header and dismiss-able with an X in the 
corner. Dismissing on one page should not persist across navigation or reloads.

>For example, we have a new design planned for the introduction, for
>example, and we'll end up making that a hardcoded page in the code
>rather than a wiki page… but for now, we can certainly put up a new
>homepage that links to the *current* intro page, and we can just change
>that link once we have the new intro page done. We should not delay the
>homepage just to finish the intro page.

Any reason why we shouldn't just make it a locked wiki page, once we add that 
functionality? Or even unlocked but only editable by Snowdrift.coop patrons?

>Items I want to see included still and not lost during this transition:
>
>* Clear indication that this is a prototype, not handling money yet,
>such as the "work in progress — public ALPHA" not currently
>
>* I think the stuff currently in the About section of the homepage can
>be all moved either to the new footer or to the wiki intro page for
>now.
>The wiki page already links to the longer about essay. I'm not sure
>about the FAQ, "who we are", and press links, but I think they could
>all
>be linked at the intro wiki page for now…

Agreed. That would make for a better flow for newcomers. Although eventually 
I'd like to look at this flow. First and foremost it's important that there's a 
clear progression for newcomers, which we currently do okay at in terms of 
natural discovery through links, I think. We also do a good job for power users 
who know about the wiki index page. However, users who have read stuff before 
but have not stumbled on the index page yet, it is hard to find a page you are 
looking for. I think the best short term fix is to add a link to the index page 
in the new footer.

>* I'm not sure about the fund-drive video… ideally we deprecate it in
>favor of a new video, but we don't have that right now. Maybe the video
>and reference to the fund-drive can be moved to the donate page; but we
>still need some prominent enough link to the donate page itself.

I like videos. I think at some point it would be worth making an updated intro 
video. Another day, though. 

>* The "News and Activity" section needs to be addressed. We need to
>make
>sure people are aware of activity and make that prominent enough.

Agreed. It'd be cool to have commits and wiki changes listed on the 
snowdrift.coop site.

>* The volunteer and get-listed stuff… well, we can have stub pages and
>appropriate links, but I want to make sure the new homepage and overall
>design keeps in mind how to keep call for volunteering really
>prominent…
>I'm not sure it does that right now.

Proposed Front Page:
Paragraph Intro or Video
Link to Learn More
Link to Volunteering Page
Link to Progress Page
Possible Progress Feed

Thoughts?

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

Re: [Design] Design details (was: Re: responsive / mobile first (mockup update))

[Stephen Michel]

On Sun, Nov 1, 2015 at 9:32 PM, Aaron Wolf  wrote:



On 11/01/2015 05:54 PM, mray wrote:

 Hello Everybody,

 based on the discussions in IRC about responsive/mobile-first
 implementation of snowdrift.coop there are some new mockups!
 I also updated the landing page and the project pledge button area a
 bit. Please open a new thread for comments on that.
 Only reply for the responsive parts in this thread please.

 
https://github.com/mray/Snowdrift-Design/tree/master/mray%20website%20mockups%20/current


 (v37)

 (I renamed "Discover" to "Browse" since Discover and Search are too 
close.)


 What did I miss?
 What is not going to work?
 What can be done better - and how?

 Looking forward to feedback,


 Robert



This is a new thread for the design details notes.

Some items: progress is neat looking overall. I like the better image 
of

crowd of characters instead of the grid that looked too much like a
statistical graph of some sort.


Agreed, this is more human.


Regarding the more forest look and the city in the distance, it's got
some good elements. I think the trees are a bit too stylized to figure
out what's going on, what they are. They don't have enough tree-like
features. I wish I could express this more clearly, but I like the
direction and yet it just needs something different to make it easier 
to

immediately recognize what we're seeing.

I still would like to have more of a bank of snow on the side of the
road, maybe both sides, just a better sense of dimension where one can
get the idea of the snowdrift more clearly, like how my drawing on the
current live intro has a sense that there's some high snow right up
close. What you have is already better though vs before.


I somewhat see where you're coming from. I think it only applies to the 
further out trees, though. I think the mobile design captures a sense 
of path very well, better than the full desktop site. What if we 
removed the trees on the edges from the desktop site, too?




I think "Join us in setting the world free!" mostly detracts from the
slogan since it is the same sort of message but just more wordy and
different. I also think the "Let's clear the path" text is redundant 
to

the button text (and I like 'Let's clear…' better).


Agreed. I DO think this is worth discussing at this stage since the 
existence of a text block or not changes the design. Not worth 
discussing particular wording (in general) though.



I think we should reconsider the existence and details about the big
landing page button. I've never really liked a wordy button that says
"how we clear the path". And the "how it works" thing is prominent
enough now in the navbar.


Second. I admit I'm not familiar with research in this area but my 
intuition is that more people will read the contents of the front page 
than click a link, no matter how prominent it is. Therefore, I'd rather 
see us put a very brief description with a prominent 'learn more' or 
'continue reading' link.


This also opens us up to adding, at some later point in time, more 
different sections with different 'learn more' buttons if Snowdrift 
ends up doing more than fundraising.


Aside: I still can't get used to calling us, the organization, 
"Snowdrift.coop." So I call the organization Snowdrift and if I need to 
talk about the software, I specify that I am doing so.



The thing I think I'd like to see is some sort of indication about the
metaphor that gets at "what is the snowdrift dilemma?" or something 
like
that, where the "how it works" part describes our solution, and the 
key

item we otherwise are pointing people to is about getting them to
recognize the problem in the first place.


Agreed but I'm also not sure it needs to be on the front page. I think 
the front page needs an emotional appeal (done) and the shortest 
reasonable summary we can give.


Anyway, the "Inkscape recieves" numbers don't make any sense to me, 
but

we'll have accurate numbers when we have the live site working.


Agreed this is weird. The way it's currently arranged, I expected those 
numbers to mean, "If you pledge, Inkscape will receive $467.86 more. Of 
that, 84 cents is directly from you and .12 cents is matched by 
others." Obviously that's not what it is, I just wanted to explain what 
positions I expected what numbers to be in.


I do think there is value to showing inscape's current income stream, 
and also how much total your pledge will add to that.



Mostly, looking great!


--
Aaron Wolf 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

Re: [Design] responsive / mobile first (mockup update)

[Stephen Michel]

On Sun, Nov 1, 2015 at 8:54 PM, mray  wrote:

Hello Everybody,

based on the discussions in IRC about responsive/mobile-first
implementation of snowdrift.coop there are some new mockups!
I also updated the landing page and the project pledge button area a
bit. Please open a new thread for comments on that.
Only reply for the responsive parts in this thread please.

https://github.com/mray/Snowdrift-Design/tree/master/mray%20website%20mockups%20/current

(v37)

(I renamed "Discover" to "Browse" since Discover and Search are too 
close.)


What did I miss?


Links at the bottom of both still say Discover.

On mobile, it's not clear what I'd click to sign IN (not up).


What is not going to work?
What can be done better - and how?


Honestly, I think your thought towards making the desktop design 
minimalistic has done us wonders here and I think that mobile site 
design works almost as-is. Especially since all we need now is MVP and 
we can iterate later.


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

Re: [Design] project page

[Stephen Michel]

For everybody else it will always turn out to be: What you give gets 
doubled by the community


So, this isn't quite true.
For people who pledge at the minimum level, your pledge will be just 
over doubled by the community.
For people who pledge at above the minimum level, their pledge will be 
less-than-doubled by the community.


This got me thinking, and the end result was this:

https://lists.snowdrift.coop/pipermail/discuss/2015-October/000121.html

I sent it to the discuss list because it concerns more than just 
design, but it is VERY relevant to this discussion.


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

Re: [Design] project page

[Stephen Michel]

On Sun, Oct 18, 2015 at 4:45 PM, Jonathan Roberts 
<robertsthebr...@gmail.com> wrote:
Thanks Stephen. This is extremely helpful. How do I access a site map 
so I don't have to keep asking these kinds of questions? The only way 
I know to find these pages right now is to stumble through a chain of 
clickable terms starting at the home page till I get to the relevant 
page.


It's not everything, but the wiki directory covers a lot:
https://snowdrift.coop/p/snowdrift/w
On Sun, Oct 18, 2015 at 1:40 PM, Stephen Michel 
<stephen.mic...@tufts.edu> wrote:



On Sun, Oct 18, 2015 at 4:38 PM, Jonathan Roberts 
<robertsthebr...@gmail.com> wrote:
Mray, I hear your concern; you don't want people to be "tricked" 
into buying into this system or to do it because it's a fun 
gimmick. However, I don't think this representation crosses that 
line. I think it is a blunt presentation of why this system is so 
effective. Yes, some people will feel things about it that aren't 
as idealistic as we want people to feel. So it goes.


https://snowdrift.coop/p/snowdrift/w/en/limits is super helpful and 
contains really well thought out possibilities


Again...I know this is a new question and maybe it deserves a new 
thread, but is there any discussion about paying for a high volume 
of transfers of very small amounts of money?


https://snowdrift.coop/p/snowdrift/w/en/transactions


On Sun, Oct 18, 2015 at 12:43 PM, mray <m...@mray.de> wrote:



On 18.10.2015 21:18, Aaron Wolf wrote:
>
>
> On 10/18/2015 12:09 PM, mray wrote:
>>
>> On 18.10.2015 09:47, Jacob Chapman wrote:
>>> 
https://img.bi/#/RCmUlLW!XJcF_0gW1TKIEhMR59pFJQwpVPv_6YwlrJSRHI8n

>>>
>>> We really need to emphasize the matching aspect of pledges to 
encourage

>>> patrons to pledge.
>>>
>>
>> The problem with the match factor is that it is always the 
same, so
>> there is no real benefit in constantly reminding a user what it 
is.
>> It also is just an invitation to start calculating in the head 
- which

>> I'd like to avoid at all costs.
>>
>
> To be clear: despite your wishes for simplicity, we have not 
come to a
> consensus about the idea of removing the ability to pledge lower 
or
> higher levels. I recognize that the complexity of people 
pledging at
> levels above the minimum is an issue, but I still feel that 
there are a
> wide range of levels of wealth and it just does *not* make sense 
to
> ignore that and force everyone to only have a single pledge 
level. All
> other patronage models that people will compare to have 
different levels

> of donation for wealthier or less wealthy patrons.
>
> If we accept, as I still feel we should, that the pledge is X 
per patron
> rather than everyone at the identical minimum pledge, then the 
amount of
> matching *isn't* absolutely fixed. Wealthier pledges mean more 
matching

> for new patrons.

My point is that even with a changing match factor your interaction
remains binary: either you pledge (your amount X) or you don't.

>
>>   We should not make people calculate.
>>
>> They should see what is happening and what the results of their 
possible
>> action would be, and formulas don't really lend themselves 
neither to

>> emphasize nor to encourage (at least the vast majority).
>>
>
> I agree that we should have no formulas and calculation factors. 
We
> should just show that you pledging means $Y more for the project 
and
> costs you $X. In other words, it's a *big* deal to actually 
learn that
> at this lower cost, you are effectively getting this *specific* 
higher

> amount of funds to the project.

I don't see a particular benefit from this. there is just not 
enough
variation. The information starts being relevant only in cases 
where
people substantially diverge from the average. For everybody else 
it
will always turn out to be: What you give gets doubled by the 
community.


>
> We want people to think is "I get the project $15 more dollars, 
and I
> only had to chip in $6! Thanks everyone, all you 2,470 others! 
I'm so

> glad we're all working together to support this!"

I don't think we want that at all. This makes it sound as if this 
is a
big bragain. This fallacious good feeling is entirely based on the 
naive

idea that you will never be asked to give more yourself - maybe way
beyond $15 dollar.
We should never even play with the idea to appear as if there are 
some
interesting bargains! At the contrary: we need to make clear that 
people
should feel great to be able to pay more for their project since 
it is
guaranteed to be part of a true difference, rather than a nice 
gesture.


>
> None of that includes doing calculations, it's merely: "I'm 
chipping in,
> others are chipping in *because* they're happy I'm included, an

Re: [Design] project page

[Stephen Michel]

On Sun, Oct 18, 2015 at 12:57 PM, Jonathan Roberts 
 wrote:
How does the math work by the way? I assumed it was exponential until 
now...


https://snowdrift.coop/p/snowdrift/w/en/mechanism

You pledge X per other patron.

On Sun, Oct 18, 2015 at 9:56 AM, Jonathan Roberts 
 wrote:
The math is unclear to me as well. I think it needs to be clear to 
the average viewer.


I think Aaron's suggestion would be more clear as well. You could 
have a link on the page that goes to a page that explains the 
equation thoroughly for those who want it.


Related question. How are we handling transfer fees for such small 
amounts of money?


On Sun, Oct 18, 2015 at 12:55 AM, Aaron Wolf  
wrote:



On 10/18/2015 12:47 AM, Jacob Chapman wrote:
> https://img.bi/#/RCmUlLW!XJcF_0gW1TKIEhMR59pFJQwpVPv_6YwlrJSRHI8n
>
> We really need to emphasize the matching aspect of pledges to 
encourage

> patrons to pledge.
>

I agree, but I think the best presentation says basically, "at this
time, you will add X, and the project will get Y more from everyone 
else
in matching" or something to that effect, emphasizing the cost to 
you
and the amount of matching more than just the total, although the 
total

is worth showing too.

I think the squared symbol is a bit confusing, we don't want to 
present
it that way, and it's not how it works either. The matching is 
quadratic

not exponential.


> Also I suggest we use /mo rather than /mth.
>

Agreed, the site itself uses "mo" currently, although the design 
mockup

is different.

> Thanks,
> Jacob
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design
>

--
Aaron Wolf 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

Re: [Design] discussion/ticket system mockups

[Stephen Michel]

On October 17, 2015 5:04:55 AM EDT, mray <m...@mray.de> wrote:
>
>
>On 16.10.2015 23:41, Stephen Michel wrote:
>> 
>> 
>> On Fri, Oct 16, 2015 at 2:06 PM, mray <m...@mray.de> wrote:
>>>
>>>
>>> On 16.10.2015 04:57, Stephen Michel wrote:
>>>>
>>>>  On Thu, Oct 15, 2015 at 6:29 PM, mray <m...@mray.de> wrote:
>>>>>  After some discussions with wolftune it dawned on me that we
>probably
>>>>>  have to stick to our discussion/ticket system.
>>>>
>>>>  Stick to our discussion/ticket system as opposed to...?
>>>
>>> ... something that can be considered a finished product.
>>>
>>>>
>>>>>  I thought we might as well make it more usable then. Here is
>where we
>>>>>  currently are:
>>>>>
>>>>>  https://img.bi/#/tMpXHzF!jefIs_vKO6A8a2S4CFDwDg6TK4Qw9JNMzHkb99u5
>>>>>
>>>>>
>>>>>  Any feedback?
>>>>
>>>>  The border around the inner shaded posts is not dark enough for me
>to
>>>>  clearly distinguish the border. Making all the inner borders the
>same
>>>>  darkness makes a world of difference, though it's a small change:
>>>>
>>>>  https://img.bi/#/q1mhu9l!A8SXKRNJ6v3l9RTgHGn1KgyWq8kxDnUxc0OV1fO-
>>>>
>>>>  ~Stephen
>>>>
>>>
>>> It is ok not to be able to distinguish the border.
>>> The border has the sole purpose of highlighting the change of
>background
>>> color. And even that does not have to be something that needs to be
>>> distinguished clearly.
>>>
>>> The main goal is to make it easy to read the connection of posts in
>>> terms of partents and children so that you don't get confused.
>>> indentation is probably the biggest mechanism that cares about that,
>>> background and borders are just supposed to help.
>>>
>>> The really dark border at the very left is just to indicate that
>this is
>>> the topmost post and you're not missing any context.
>> 
>> I think I may have been unclear. Here's your original image, with
>> borders and posts identified.
>> 
>> https://img.bi/#/bZHUWcV!bS6MpE0KIso8MSg8f3vDKgXjvYNBVP4rF6i3RKD-
>> 
>> Border 1 is very dark.
>> Border 2 is dark.
>> Border 3 and 4 are light. So light that it is difficult for me to
>pick
>> out the borders of post A and B.
>> This makes posts A and B run together for me.
>> 
>> I propose changing borders 3 and 4 to be the same darkness as border
>2
>> (maybe it's just a rendering issue, but borders 3 and 4 are lighter
>in
>> the image. In my earlier image, I changed the top and left borders of
>> post A to be in the style of border 2. That's all I'm proposing.
>> 
>
>I agree. This is my fault, I should have noted that these mockups
>aren't
>really "clean" in any sense. Just have a look at the horrible spacing
>differences. This subtle amount of difference is due to me using
>transparency to quickly adapt the predefined color-swatches in
>intensity.

No worries! 

>>>
>>>
>>> Robert
>>>
>>> ___
>>> Design mailing list
>>> Design@lists.snowdrift.coop
>>> https://lists.snowdrift.coop/mailman/listinfo/design
>> 
>> ~Stephen
>> 
>> 
>> 
>> ___
>> 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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Design] discussion/ticket system mockups

[Stephen Michel]

On Fri, Oct 16, 2015 at 2:06 PM, mray <m...@mray.de> wrote:



On 16.10.2015 04:57, Stephen Michel wrote:


 On Thu, Oct 15, 2015 at 6:29 PM, mray <m...@mray.de> wrote:
 After some discussions with wolftune it dawned on me that we 
probably

 have to stick to our discussion/ticket system.


 Stick to our discussion/ticket system as opposed to...?


... something that can be considered a finished product.



 I thought we might as well make it more usable then. Here is where 
we

 currently are:

 https://img.bi/#/tMpXHzF!jefIs_vKO6A8a2S4CFDwDg6TK4Qw9JNMzHkb99u5


 Any feedback?


 The border around the inner shaded posts is not dark enough for me 
to
 clearly distinguish the border. Making all the inner borders the 
same

 darkness makes a world of difference, though it's a small change:

 https://img.bi/#/q1mhu9l!A8SXKRNJ6v3l9RTgHGn1KgyWq8kxDnUxc0OV1fO-

 ~Stephen



It is ok not to be able to distinguish the border.
The border has the sole purpose of highlighting the change of 
background

color. And even that does not have to be something that needs to be
distinguished clearly.

The main goal is to make it easy to read the connection of posts in
terms of partents and children so that you don't get confused.
indentation is probably the biggest mechanism that cares about that,
background and borders are just supposed to help.

The really dark border at the very left is just to indicate that this 
is

the topmost post and you're not missing any context.


I think I may have been unclear. Here's your original image, with 
borders and posts identified.


https://img.bi/#/bZHUWcV!bS6MpE0KIso8MSg8f3vDKgXjvYNBVP4rF6i3RKD-

Border 1 is very dark.
Border 2 is dark.
Border 3 and 4 are light. So light that it is difficult for me to pick 
out the borders of post A and B.

This makes posts A and B run together for me.

I propose changing borders 3 and 4 to be the same darkness as border 2 
(maybe it's just a rendering issue, but borders 3 and 4 are lighter in 
the image. In my earlier image, I changed the top and left borders of 
post A to be in the style of border 2. That's all I'm proposing.





Robert

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


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

Re: [Design] Homepage illustration

[Stephen Michel]

I think there's a very, very delicate balance that we want to strike.

I agree that the home page is too stark for my liking. There's a 
disconnect between "Join us in setting the world free!" and the looks 
on the faces of Mimi and Eunice. I agree there's not much sense of a 
snow *drift* and that the latest draft fails to convey a sense of 
"There's all this snow, but if we can move it aside we've got this 
awesome neighborhood."


At the same time, I think the draft Aaron linked is not 
"professional-feeling" enough. This is a crowdfunding site. If we come 
across looking like somebody's hobby project, people will not put any 
money into their accounts. The most recent version is much better on 
this front. I think, in both versions, the header font is to our 
significant detriment (particularly the search bar). I would prefer 
something a little cleaner. While there's often very little inherent 
value in following the industry, and due to our nature I think it may 
be beneficial to stand out a little bit, I also think in this 
particular area we could take some queues from other crowdfunding 
sites, which almost exclusively feature a clean sans font for their 
headers. I'm not sure if it would look better if we got rid of the bold.


I think there's a balance to be found between the new and the old. I 
definitely want to bring back the feeling of "there's life, under the 
snow."


~Stephen

On Wed, Sep 30, 2015 at 5:59 PM, Jonathan Roberts 
 wrote:
One more thought. I do like what's being communicated in the new 
summary...just wish it was in that more dynamic format. I also like 
that the dynamic format explains why this is different in the 
"before" sentence.


"Before, publicly funded creative projects have been primarily 
proprietary: owned and controlled by an individual, despite being 
made possible by the public. Now, the community is taking over, 
funding sustainable, freely licensed projects that continue to serve 
and be shared by us all."


Ya...I really like alliteration. The more I have of it, the more I 
want.


On Wed, Sep 30, 2015 at 2:45 PM, Jonathan Roberts 
 wrote:

Four thoughts from a previously silent watcher...

First, have there been more thoughts about the catchphrase at the 
top? How about "Funding a cooperative culture" - I like the 
alliteration, and I like the sort of subtle subversive suggestion 
that the current culture is somehow not cooperative...


Second, I agree about the graphics; the first one is so exciting! 
And I don't think it's too confusing. I think it just needs some 
playing with colors; the snowdrift can appear to be a mountain in 
the background, rather than a drift in the foreground, which makes 
the shadow on the ground seem like a sloppy editing mistake or 
something. I think some slight tweaking of colors or perspective 
would clear it up though.


Third, I prefer the summary under "a matching patronage system 
funding a free culture"  to the new one. The reason is similar to 
the graphic; this explanation is dynamic and dramatic, where as the 
new one is relatively static. I like that the new one is concise, 
but it just isn't very fun to read...which is, like it or not, going 
to be important to getting people to engage with this. I would 
change the "with snowdrift.coop" to simply "Now," which I think 
makes it really exciting; Beforebut NOW! The rest of the 
language could be cleaned up, but I really like that language, 
rather than the relatively pedantic "here's who we are and here's 
what we do" of the new one.


Fourth, (and this is the least strong reaction of these four), I 
like that the pic of the "network effect" is just right there on the 
home page; the reason is that the first thought I had upon hearing 
this idea was "how is this different than kickstarter?" The most 
immediate, obvious and relevant reason is the network effect. The 
deeper and more important reasons are hard to explain with a simple 
info graphic, but this one sort of gives the viewer an immediate 
"here's why you should stay on this site and check out more rather 
than just heading over to kickstarter.


-Jon

On Wed, Sep 30, 2015 at 1:33 PM, Aaron Wolf  
wrote:
I don't want to get too distracted from the core focus on 
implementing a

functional site, but I just wanted to share my thoughts briefly.

In
https://github.com/mray/Snowdrift-Design/blob/master/mray%20website%20mockups%20/older%20exports/export.png

There's just so much LIFE, sense of engagement that the current 
final
draft is missing. That first draft is too hard to tell what is 
going on
with the paths that go side to side and back into the picture. But 
there

are three elements I really like:

* the more high piled snow that makes it seem a little more 
substantial
* the twin pines that are both aesthetically nice, engaging, and 
nice

metaphor of the classic co-op twin pines
* the vague shadowed sense of stuff off in