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

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 <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] 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" <aa...@snowdrift.coop
> <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
>> >> waiting is worth it.
>> >>
>> >> Concerning the next steps 

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

[Snowdrift-design] new video script draft

[Aaron Wolf]

y: "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] 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 

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 good about us, not by what is bad about others.
>>>
>&g

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 without saying it is a new metap

[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] 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]

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/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/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/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 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=on=on=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] 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 

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] 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 <aa...@snowdrift.coop> 
>>> 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 about who it r

[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] 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] 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] 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 <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
>> 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

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

[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

[Design] Snowdrift.coop meeting today in 80 minutes

[Aaron Wolf]

Hi everyone,

Whoever can make it (whether you've been active lately or not), we'd
love to see you at https://meet.jit.si/snowdrift 20:00 UTC today for our
first 2016 meeting! That's in 80 minutes from now

We'll be discussing a range of plans for getting the site going,
organizing, delegating tasks, prioritizing etc. in anticipation of SCALE
in 2.5 weeks

If you can't make it, you're still welcome to participate on these email
lists, on IRC, or otherwise; thanks!

P.S. bit of news: merchandise page is up now, check it out:
https://snowdrift.coop/merchandise
More news coming soon!

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

Re: [Design] 4 issues priority

[Aaron Wolf]

On 12/29/2015 02:03 AM, mray wrote:
> Hello List,
> 
> It has been some time that we concluded it would be good to have our
> main goals summarized in a few "issues" that are.
> 
> * FLO
> * network effect
> * sustainability
> * democracy
> 
> I think among those 4 issues the "network effect" needs to be the number
> one. We chose the FLO as #1 because it *is* the most important one for
> us. But concerning most materials we need to acknowledge that we need to
> care about what the materials goals are.
> 
> Whenever we try to explain snowdrift our ideology needs to step back for
> things that have more explanatory power. "Is this platform ethical?" Is
> just not an answer that people would *start* with.
> 
> I want to persuade with benefits regardless of ethics and only expand to
> that later. The network effect is a distinct and unique concept that
> catches attention and explains us way better than our deepest value due.
> 
> My suggestion is to switch FLO <-> network effect position in all materials.
> 
> 
> 
> What are your thoughts?
> 
> 
> Robert
> 
> 

As this is a good start to getting these things written, thanks for the
prompt. The way you're thinking about the intro isn't quite right though.

Without a doubt, the network effect is the most important part of the
site. Period. But it belongs second in the logical introduction. The
ordering has nothing to do with importance, only with the logic of the
introductory path by which someone understands the site.

We did *not* put FLO #1 because it is most important to us. That was
never the thinking at all, and the reason for the order has never been a
matter of ideology.

The point is that the particular challenges that FLO faces are the
primary reason we need a network effect. FLO is the problem question and
the network effect is the answer. The network effect is not the answer
to "how can I sell more widgets?" (or, comparably, "how can my
proprietary pay-for-access thing do better?" or "how can I get capital
for my proprietary startup?")

The FLO section of the how-it-works should not overemphasize ideology or
be about ideology much at all. The only extent it needs to cover as far
as ideology is to emphasize that FLO is good and have links to further
reading about our vision and values or something.

The entire point of the FLO section is to set the stage to say that FLO
works are public goods that lack a pay-for-access way to get funded, so
they face the snowdrift dilemma. We want to say that as clearly and
plainly as possible, and then immediately move to saying that therefore
the solution is the matching-pledge network effect.

If we start with the network effect, we miss the entire premise and also
cause confusion for many readers who will think about all sorts of
economic areas where things are already working and effectively think we
have a solution looking for a problem. I know from experience that most
people will immediately jump to imagining using this for any fundraising
they possibly want to any purpose (their local club or their proprietary
project or whatever), and then flipping it on them and saying second
that the site is restricted to FLO will invite push-back and accusations
of needlessly imposing an ideology.

The clearest and actually less ideological approach remains to keep FLO
first so that people understand the scope of the problem and the focus
of the site (again, not a political ethical manifesto about FLO, just an
emphasis on *what* it is and that it serves everyone, whether they
contribute or not).

In summary:

1. What's the issue? FLO is great public good for everyone but it faces
the snowdrift dilemma and struggles!

2. How do we solve it then? ***Our pledge!*** (which is indeed the key
important element)

3. Okay, that sounds neat, tell me more. It's sustainable and
accountable, unlike one-time campaigns

4. Cool, so this sounds like a neat product, what's the catch? How do
you profit? Are you really doing this for public benefit? Yes, we really
are, this is a non-profit co-op, and you can participate; this isn't a
few people working to gain power and profit off of you.

…now go check out the site and use and learn more and participate etc.

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

Re: [Design] /auth templates

[Aaron Wolf]

Some of the really code-specific discussion seems maybe appropriate for
the dev list, but since this is front-end related, I guess it's okay here.

On 12/28/2015 03:35 AM, mray wrote:
> templates/auth/create-account-form.hamlet seems to contain only part of
> the actual /create-account page.
> 
> I can't find the rest. The alert on the page and the submit button seem
> to come from nowhere.

Some of it is in-line in the Haskell stuff. Probably Bryan should look
at this and refactor it to be organized in the way he feels is best for
the new structure.

> 
> I also have issues when moving CSS to default-layout-new.cassius and
> start working off a new branch from master and loose the css.
> is there a way around this?
> 

You can potentially branch off a branch, in other words, you can do some
work in one place, make a branch off that, and make it clear that one
branch relies on the other. That's not ideal though.

I think the best option is when you realize something really belongs in
default-layout, you should make a branch *just* for that move off of
master, and then that is the sort of thing I or Bryan can merge
immediately so that it will be in master and then be available for all
your different work going forward from there.

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

Re: [Design] work on dashboard

[Aaron Wolf]

On 12/27/2015 07:37 AM, mray wrote:
> I'm not certain what issues exactly the widget and css nesting of tabbed
> pages (like project and dashboard pages) contains.
> 
> in order to not step on the toes of people taking care of this I decided
> to work on more harmless? pages like the login page.
> 
> I hope that is ok.
> 

Of course! Anything that progresses us toward completion is great. The
only issue is that we do want to get used to figuring out who's doing
what so that we are best prepared to tell volunteers what is open to do,
so just communicating what is being worked on is helpful.

We may move to tickets or Wekan more, still need to work that out
better, but notes at https://v.etherpad.org/p/snowdrift-alpha-sprint-1
about what's being worked on is at least something for now.

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

Re: [Design] T-Shirts and colors

[Aaron Wolf]

On 12/23/2015 04:17 AM, mray wrote:
> Aaron and I came to the conclusion that there are just too many factors
> that play into how we present colors on our shirts.
> 
> The angles in question are:
> * what ink/shirt combination work at all?
> * what combinations match the official snowdrift.coop style?
> * what combinations look great?
> * what combinations do we want to offer?
> * what combinations are available for which sex?
> * in how far do we let people make own choices
> 
> Our conclusion is to just go for a combination of snowdrift.coop colors
> now – and link to all respective avilable shirt colors. Once we have
> actual prints of alternate combinations, and we are convinced that they
> work great, we can put them next to the current shirts on the homepage
> with actual photos.
> 
> For now this is a trade-off in favor of our promotion goals and at the
> expense of the fashion aware approach and effort from everybody,
> especially Diana. I think this is just a save answer on how to proceed
> now, and I'm honestly looking forward to see what other combinations
> will get your approval.
> 
> This is how the page would look like now: https://imgur.com/a/PhOl1
> 
> What are your opinions?
> 
> 
> Greetings,
> Robert
> 
> 

I'm looking forward to hearing other people's thoughts, but my view:

I like the light gray (warmer looking), but it's men's only, same with
Warm Gray (dark, warm color). Maybe some women will prefer that and want
to order a men's shirt to get that color? Confusing though.
Unfortunately, most people getting shirts at this time are men, but we
don't want to reinforce that trend.

The one other shirt that is available for both is Heather Gray. There's
a real risk that the ink colors against Heather Gray will be unacceptable.

So, for the initial order, I plan to *definitely* order at least one
each of Light Gray, Warm Gray, and Heather Gray so that we at least see
how they turn out in reality. If Heather Gray is good, we have another
possible option that isn't different for men's and women's. If the other
men's ones are good, we can take photos of them and show that by the
options link with label, although it's still quite unfortunate that
there's no women's cut of those colors.

Obviously, anyone here who wants to choose a different color is welcome
to do so. Incidentally, we need to decide something about the extent of
offering shirts to volunteers who didn't donate financially at the shirt
level but who may like shirts and are putting in good volunteer time,
and whether we want to mention a shirt-for-volunteering option in some
public statement.

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] T-Shirts and colors

[Aaron Wolf]

On 12/23/2015 09:35 AM, Diana Connolly wrote:
> Warm grey is available in women's.
> 

Oh yeah! I guess the thing about that was that it was an alternate dark
color, and the cool blue was definitely a *good* option we want to
emphasize. I'd be fine with highlighting Warm Gray as an option with a
mock-up alongside the cool blue if people think that' preferable.

> 
> 
> On 12/23/2015 04:17 AM, mray wrote:
>> Aaron and I came to the conclusion that there are just too many factors
>> that play into how we present colors on our shirts.
>>
>> The angles in question are:
>> * what ink/shirt combination work at all?
>> * what combinations match the official snowdrift.coop
> <http://snowdrift.coop> style?
>> * what combinations look great?
>> * what combinations do we want to offer?
>> * what combinations are available for which sex?
>> * in how far do we let people make own choices
>>
>> Our conclusion is to just go for a combination of snowdrift.coop
> <http://snowdrift.coop> colors
>> now – and link to all respective avilable shirt colors. Once we have
>> actual prints of alternate combinations, and we are convinced that they
>> work great, we can put them next to the current shirts on the homepage
>> with actual photos.
>>
>> For now this is a trade-off in favor of our promotion goals and at the
>> expense of the fashion aware approach and effort from everybody,
>> especially Diana. I think this is just a save answer on how to proceed
>> now, and I'm honestly looking forward to see what other combinations
>> will get your approval.
>>
>> This is how the page would look like now: https://imgur.com/a/PhOl1
>>
>> What are your opinions?
>>
>>
>> Greetings,
>> Robert
>>
>>
> 
> I'm looking forward to hearing other people's thoughts, but my view:
> 
> I like the light gray (warmer looking), but it's men's only, same with
> Warm Gray (dark, warm color). Maybe some women will prefer that and want
> to order a men's shirt to get that color? Confusing though.
> Unfortunately, most people getting shirts at this time are men, but we
> don't want to reinforce that trend.
> 
> The one other shirt that is available for both is Heather Gray. There's
> a real risk that the ink colors against Heather Gray will be unacceptable.
> 
> So, for the initial order, I plan to *definitely* order at least one
> each of Light Gray, Warm Gray, and Heather Gray so that we at least see
> how they turn out in reality. If Heather Gray is good, we have another
> possible option that isn't different for men's and women's. If the other
> men's ones are good, we can take photos of them and show that by the
> options link with label, although it's still quite unfortunate that
> there's no women's cut of those colors.
> 
> Obviously, anyone here who wants to choose a different color is welcome
> to do so. Incidentally, we need to decide something about the extent of
> offering shirts to volunteers who didn't donate financially at the shirt
> level but who may like shirts and are putting in good volunteer time,
> and whether we want to mention a shirt-for-volunteering option in some
> public statement.
> 
> Cheers,
> Aaron
> 
> --
> 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] T-Shirts and colors

[Aaron Wolf]

On 12/23/2015 09:45 AM, Aaron Wolf wrote:
> 
> 
> On 12/23/2015 09:35 AM, Diana Connolly wrote:
>> Warm grey is available in women's.
>>
> 
> Oh yeah! I guess the thing about that was that it was an alternate dark
> color, and the cool blue was definitely a *good* option we want to
> emphasize. I'd be fine with highlighting Warm Gray as an option with a
> mock-up alongside the cool blue if people think that' preferable.
> 

To clarify: We have better dark shirts than light.

Cool blue fits our theme *and* is a nice color, so it makes sense as the
default for dark shirts.

Warm Gray looks likely to turn out good too as an option for those
wanting a warm darker color. Even though it doesn't fit the branding
well, I'd be okay with showing it as an option, but it can be ordered
regardless.

Note: the dark shirt is the snarky design though, so getting the nice
more mild design means going with a light shirt unless we make a new
design (easiest to avoid extra work would be a plain-logo shirt, boring
but okay).

For light shirts, the only clear option for both men's and women's is
white (unless Heather Gray turns out to be surprisingly light enough).
So, it seemed the most straightforward to just stick with white (does
match our branding anyway) while offering the option for people to
select their own alternate color choices. If we emphasized that Light
Gray seems nice, it would only be available for men's fit, and that
seems awkward to deal with presenting that.

So, do people really want to see the Warm Gray shown on the page as an
alternate dark color? Otherwise, is the mockup acceptable (white and
blue with "other options" links)?

Again, trying to fit all the values and make everyone happy and not
discriminate against women in our side of the decisions at least…
there's no way to avoid some compromises, perfectionism delays our
progress, and we have many other priorities.

Thanks everyone for helping us work through this!

>>
>>
>> On 12/23/2015 04:17 AM, mray wrote:
>>> Aaron and I came to the conclusion that there are just too many factors
>>> that play into how we present colors on our shirts.
>>>
>>> The angles in question are:
>>> * what ink/shirt combination work at all?
>>> * what combinations match the official snowdrift.coop
>> <http://snowdrift.coop> style?
>>> * what combinations look great?
>>> * what combinations do we want to offer?
>>> * what combinations are available for which sex?
>>> * in how far do we let people make own choices
>>>
>>> Our conclusion is to just go for a combination of snowdrift.coop
>> <http://snowdrift.coop> colors
>>> now – and link to all respective avilable shirt colors. Once we have
>>> actual prints of alternate combinations, and we are convinced that they
>>> work great, we can put them next to the current shirts on the homepage
>>> with actual photos.
>>>
>>> For now this is a trade-off in favor of our promotion goals and at the
>>> expense of the fashion aware approach and effort from everybody,
>>> especially Diana. I think this is just a save answer on how to proceed
>>> now, and I'm honestly looking forward to see what other combinations
>>> will get your approval.
>>>
>>> This is how the page would look like now: https://imgur.com/a/PhOl1
>>>
>>> What are your opinions?
>>>
>>>
>>> Greetings,
>>> Robert
>>>
>>>
>>
>> I'm looking forward to hearing other people's thoughts, but my view:
>>
>> I like the light gray (warmer looking), but it's men's only, same with
>> Warm Gray (dark, warm color). Maybe some women will prefer that and want
>> to order a men's shirt to get that color? Confusing though.
>> Unfortunately, most people getting shirts at this time are men, but we
>> don't want to reinforce that trend.
>>
>> The one other shirt that is available for both is Heather Gray. There's
>> a real risk that the ink colors against Heather Gray will be unacceptable.
>>
>> So, for the initial order, I plan to *definitely* order at least one
>> each of Light Gray, Warm Gray, and Heather Gray so that we at least see
>> how they turn out in reality. If Heather Gray is good, we have another
>> possible option that isn't different for men's and women's. If the other
>> men's ones are good, we can take photos of them and show that by the
>> options link with label, although it's still quite unfortunate that
>> there's no women's cut of those colors.
>>
>> Obviously, anyone here who wants to choose a different color is welcome
>> to do so. Incidentally, we need

[Design] Meeting 20:00 UTC tomorrow 12-21

[Aaron Wolf]

Reminder: Snowdrift.coop meeting tomorrow, Monday 21st, via
https://meet.jit.si/snowdrift (note that we are NOT using the beta site
now, the regular site supports screen-sharing in both Firefox and
Chromium now)

Time: 20:00 UTC (that's 12:00 Pacific)

Lots of stuff happening, everyone is welcome to participate.

We'll be discussing our continued efforts to get the alpha site going
and prepare for SCALE.

Cheers

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

Re: [Design] Stickers

[Aaron Wolf]

On 12/18/2015 12:29 AM, mray wrote:
> 
> 
> On 18.12.2015 02:25, Aaron Wolf wrote:
>>
>>
>> On 12/17/2015 05:08 PM, mray wrote:
>>>
>>>
>>> On 17.12.2015 21:31, mray wrote:
>>>> During the last meeting we decided to go for 4 certain stickers
>>>>
>>>> 1. logo symbol only
>>>> 2. logo symbol & type
>>>> 3. eunice with shovel shovel over logo & type
>>>> 4. mimi & eunice shaking hands over logo & type
>>>>
>>>> At the time that particular versions of the stickers were not coherent
>>>> enough. So I worked on them some more
>>>>
>>>>
>>>> This is how I would send them to print:
>>>> https://github.com/mray/Snowdrift-Design/blob/master/sticker/stickers2.svg
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>
>>> I just noticed that having a white shovel only works on the sticker.
>>> The homepage needs to stick to the dark shovels which is why I updated
>>> the sticker accordingly.
>>>
>>
>> I was always fine with the homepage as is, I think the lighter shovel on
>> the sticker is nicer though. What about the t-shirt design?
>>
> 
> I'd like to stay consistency. Shovels need to look either one way or the
> other. Next to each other the lighter would even more look like a sign.
> 

I'm fine with the dark shovel in the sticker if you are.

-- 
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 12/15/2015 09:27 AM, Diana Connolly wrote:
> Hi Everyone, sorry for the delay, I've been dealing with a hideous cold. 
> 
> 1. The set up fees for shirt layouts are $25 each. We need three, one
> for the logo and two for the different cartoons, so that's 75 bucks.
> 
> 2. Shirt prices (each):
> */Style 3600 (men's)/*
> S-XL = $7.65
> 2XL = $8.65
>  
> */Style 3900 (ladies)/*
> S-XL = $7.45
> 2XL = $8.45
> 
> 3. If we an underlay is needed for a white ink on a darker color shirt,
> it's an additional ~70 cents per shirt. I'm waiting to hear back from
> April at BlueMill to see if we need that for the warm grey.
> 
> 4. There is extra charge for ink changes buy we get two free, so it
> doesn't affect us.
> 
> 4. The email chain is quite long and I haven't read it all. If there was
> someone wanting a darker(or medium) blue t-shirt with white ink, there
> would be no additional charge, because simply changing shirt color
> doesn't affect price, unless it needs an underlay. But I believe she
> told me that if the underlay is white and the ink is white, there is no
> underlay charge. Again, I'm waiting to hear back from April.
> 
> 5. Unfortunately, there is no light grey for women! There is heather
> grey. And about that color that everyone seems to like that is the
> default showing on the men's page? It is heather grey. So maybe we run
> with heather grey and warm grey? And possibly a darker blue with white ink?
> 
> 6. We can't really see sample shirts because in order to make a sample
> shirt, the shop incurs all of the setup costs plus has to order the
> shirts. They can do a digital mockup and then we gotta commit and run
> with it.
> 
> 7. They normally have a two week turn-around on orders, with 50% down.
> We need to know all details (shirt sizes, colors, designs, quantities)
> before we start.
> 
> 8. For future reorders, there is a $10 re-setup fee, and then the costs
> of the shirts.
> 
> That's all I can think of. Hope that clarifies everything you guys need
> to know. I'll send out another email when I hear from April about the
> underlay for white ink. I can facilitate ordering, but I'll be out of
> town from Dec. 18th - 29th. So I can do it either before or after that. :)
> 
> Diana
> 

Thanks for getting all those details. So, there's no quantity discount
issues, apparently? That makes it definitely reasonable to do a modest
order at first and regularly place new orders as we go, which is
certainly easier for cash-flow. Also, for the superb quality of these
shirts, those prices seems great.

Re: Heather Gray, can you just ask them for a subjective judgment of
whether it is on the lighter or darker side in terms of the two images
of it on the website, which seems more accurate to them?

My inclination is to offer Light Gray and Heather Gray both as options
or at least order some of each just so we see the results for future
reference. And I could see ordering some darker shirts. I'm not sure how
much we want to offer various options to people vs focus on a
recognizable set of colors consistently.

At any rate, $10 extra to order a smaller set and then a larger order
later, easy enough.

Let's make at least a close to final decision and then mock-up the
options we'll do perhaps with women's shirts shown also, and then I can
use that to get selection info from those people already expecting
shirts. And then we'll probably order something in the range of 100
shirts perhaps at first for general stuff and for SCALE (depending on
how much we can get new donations in conjunction with announcing the
final shirt designs).


> On Sun, Dec 13, 2015 at 10:26 AM, William Hale <s...@altsalt.net
> <mailto:s...@altsalt.net>> wrote:
> 
> I liked the left hand side of each of those drafts with a preference
> toward shirts-diana.
> 
> ___
> 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
> 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] Suggestion for presentation about partner orgs

[Aaron Wolf]

On 12/15/2015 02:16 PM, mray wrote:
> 
> 
> On 15.12.2015 22:39, Aaron Wolf wrote:
>> In the new design, there's logos and just links to other orgs, but
>> there's no clarity about what the partnership is, whether they just
>> endorse us or what or what we think about each etc.
>>
>> I suggest something like this: we have a partners page (can be a wiki
>> page for now possibly) in which we provide more details about each
>> partner org, discussing briefly in *our* words what each partner is and
>> why and what extent we are partnered.
>>
>> Then, we could link the entire partner footer to the more in-depth
>> partners page. Perhaps we could link each partner to an ID anchor within
>> the page.
>>
>> Overall, it's just weird to say "we're partnered with OSI" in the footer
>> and click to just see the OSI homepage, and there's no info or clarity
>> about the partnership, it just feels awkward and opaque to me and
>> missing the public-facing stuff talking about / celebrating the
>> partnerships.
>>
>> Sharing this idea so others can weigh in…
>>
>> Cheers,
>> Aaron
>>
> 
> This would be a nice feature, indeed. But it isn't important right now.
> Currently the main duty of those icons is underlining authenticity.
> 

Indeed, not priority per se (although we *could* easily change links so
that the OSI logo linked to an article about the partnership, for
example). I'd like to decide whether we mark this as a plan for the
medium/long term though.

-- 
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 12/10/2015 02:43 PM, Diana Connolly wrote:
> Hi guys, I've called the company and am waiting to hear back from them.
> I really think the shirt you mentioned looks great, it's a nice light
> weight 100% cotton and it comes in styles for both men and women. They
> don't have an oatmeal, but they have a heathered grey. There is also a
> completely awesome "heavy metal" color. And of course, white.
> When they call me back, I'll check to see about the cost of multiple
> shirt colors. One thing that would be nice to know, however, is what
> sizes? I realize that's a tough one, perhaps they can give some advice
> on that.
> 
> Here's a link for anyone who would like to see the colors of the shirts:
> 
> http://www.brandbookonline.com/cgi-bin/brand/site.w?location=olc/cobrand-product.w=3==3600=no=main=04=52092
> 
> Diana
> 

Well, for sizes, we can do some estimates for extras, but my plan has
been to reach out to people expecting shirts and find out what sizes
they want along with the design options depending on which we end up
offering.

As I said, I have the shirt that Eric mentioned from the conference he
ran, and it stands out as actually the best t-shirt I own at all.

Anyway, for colors, based on that site, I agree we shouldn't do plain
white. I could see the current dark-blue ink designs on: Warm Gray,
Sand, Light Gray, Heather Gray, Cream… I think my preference would be
Heather Gray.

I would like to avoid the work of making a dark-shirt design, but I
could see Indigo or Midnight Navy.

I'll await thoughts from other folks, and, Diana, happy to get your
thoughts. If it were up to me to just do something immediately, I think
I'd just go with the current designs with the dark blue images over
Heather Gray.

Robert? Thoughts? Other folks?


> On Wed, Dec 9, 2015 at 9:57 PM, Aaron Wolf <aa...@snowdrift.coop
> <mailto:aa...@snowdrift.coop>> wrote:
> 
> Hi Diana,
> 
> Thanks for the quick response!
> 
> If we lived in a world where everyone's favorite shirt color was white,
> then I think the designs we already have with a single print color of
> the dark blue would be just fine.
> 
> The main issue is the fact that many people would *not* prefer a pure
> white shirt color.
> 
> Now, some text and logo can work inverted, but the Mimi and Eunice
> characters do not look good as light color on dark background (but that
> may depend on the degree of contrast and exact colors). Probably, we
> either need an acceptable non-white shirt that is still light colored
> enough that the dark print color works and/or we change the design for a
> dark colored shirt.
> 
> So, maybe we'll offer two shirt colors, a light shirt (maybe still pure
> white?) and the current design and a different design for a dark-colored
> shirt. Or we pick just one of those. Perhaps we can use a second or
> third print color to adjust the design to make it acceptable on a dark
> shirt.
> 
> The basic issue right now is to select acceptable shirt options from
> real available shirts and then get an image to Robert (who I'm copying
> on this email) so that he can weigh in on how he feels about the design
> for the actual real shirts. My sense from Robert is that he basically
> feels nothing can go forward well right now until he knows what actual
> shirt colors we have to choose from.
> 
> Abstractly, I like the white shirts and one-color-printing designs we
> already have… except for the concern about white shirts.
> 
> Thanks again for the help, talk to you soon!
> 
> 
> On 12/09/2015 09:44 PM, Diana Connolly wrote:
> > Hi Aaron!
> > I've been thinking about colors today. I can talk to the shirt company
> > tomorrow.
> > One question - do you want to go with just a one color print? In that
> > case, I think your preview using the deep blue is good for a white
> > background. See below for links to color schemes.
> >
> > The first each series is shirt color, second primary ink color, third
> > accent, plus a couple optional accents.
> > A lot of these are straight out of your design guide.
> >
> > I'd like to see what your graphics guy thinks and I'll ask the shirt
> > company what the price difference would be for multiple colors, if you
> > want to go that way.
> >
> > White background:
> > https://coolors.co/app/ff-13628e-44a76b-f9ff68-7d7d7d
> >
> > Charcoal background:
> > https://coolors.co/app/696969-ffa700-13628e-b2-47cfec
> >
> > Talk to you tomorrow,
> > Diana
> >
> &g

Re: [Design] /Project page "ready"

[Aaron Wolf]

On 12/06/2015 03:33 PM, mray wrote:
> 
> 
> On 06.12.2015 22:12, Aaron Wolf wrote:
>>
>>
>> On 12/06/2015 02:24 AM, mray wrote:
>>
>>
>>> On 06.12.2015 04:29, Aaron Wolf wrote:
>>>> I don't quite understand why the sun is bouncing around. When it 
>>>> starts to overlap the other objects, it looks really glitchy. 
>>>> Video attached
>>>>
>>
>>> Thanks for the video. This is ... interesting. Actually this 
>>> animation just rotates a white div container with rounded borders, 
>>> and I don't get any glitch like that either on Firefox or
>>> Chromium. What browser are you using?
>>
>>
>> I'm using Firefox.
>>
>> To be clear, regardless of the glitch, when there's only a small
>> amount of the sun showing, the fact that it blends into the white of
>> the other div means that when it happens to be at a size like that,
>> it's not clearly a sun or anything and just seems very weird like "why
>> is there a little pulsing bump on the border??"
>>
>> My inclination is to remove the sun entirely from the project page.
>>
> 
> The sun gets removed, just only after the next breakpoint. Same is true
> for other background things. It does not really break the page to have
> it sitting there, I'm more concerned about eventually fixing the glitch.
> 
>>>> Overall, on my very standard resolution of 1366x768 screen (see 
>>>> https://en.wikipedia.org/wiki/List_of_common_resolutions — this 
>>>> is called "standardized HDTV 720p/1080i display… used in most 
>>>> cheaper notebooks", i.e. it is extremely common) things are
>>>> still substantially too big. The layout of stuff on the page is
>>>> just awkward in that it feels like I can't get a comfortable
>>>> amount of things on the screen at once.
>>
>>> Maybe scaling the whole page down a bit is an option (like we
>>> scale up on resolutions >2000px)? Change the font-size of the
>>>  element and let me know what values would work fine.
>>
>>
>> Well, I tried just zooming out, and by the time the amount that shows
>> height-wise is reasonable (note that I have task bar and tab and
>> address bar, that stuff further cuts down the height of a standard web
>> browser on this common screen size), the smallest fonts are really
>> uncomfortably small.
>>
>> That said, the more I look at this, the more convinced I am that the
>> smallest font-size (that used for "matching" and "project total" and
>> "Projects > Software > " etc.) is actually too small even at full
>> size. It's just *barely* readable as is. I actually think we should up
>> the size of that smallest font generally.
>>
>> As for the overall thing about being too tall, mainly the issue is the
>> size of the image/screenshot. Other things about the design are all
>> really a bit too vertical and tall. The space between the navbar and
>> the pledge button is taller than needed. I really think basically the
>> design needs to be adjusted to consider having a good comfortable
>> amount of stuff showing within the first about 525px below the navbar.
>> And this should not be done by shrinking everything, as the smallest
>> font is already too small, and the spacing width-wise is good and
>> should not be made any smaller at all. More padding on the sides isn't
>> desirable.
>>
>> On an important side note: I feel pretty strongly that we should not
>> have hard boxes for "software" or whatever other project categories. A
>> project shouldn't strictly live in a "software" box such that
>> "Projects > Software > Inkscape > Updates" should exist. Instead,
>> "software" should be a type of *tag* so that a project can have
>> multiple tags. And the project page should indicate, probably in the
>> top-right of the div that has the project title, what tags this
>> project has.
>>
>> A mild side-note: it seems semantically wrong to call the top section
>> of the project page an . The pledge button and stats and
>> screen shot are definitely not an article. That needs to be changed.
>> An  is like a blog post, it is specifically for actual
>> content that could be stripped out and printed as a piece of writing,
>> an article…
>>
> 
> I don't think this is neither the time to change the design, nor the
> time for any kind of side notes. The design does have issues in my eyes,
> too. Let us talk about those after there is an actual

Re: [Design] shirt colors

[Aaron Wolf]

options,
so a second one that is dark colored.


> Bottom line:
> I'm willing to help and I'm sure I can come up with some great options!
> There are companies in town with really quick turn around, and you could
> see samples before committing. I'm totally nuts about color and can
> steer you right.
> 

Thanks so much! And you're certainly welcome to provide feedback about
other design issues too as they come up, if you're so inclined. But
yeah, the shirt issue is the primary thing right now to deal with.

Cheers,
Aaron

P.S. If you're around and at all interested, we're having a social meet
up tomorrow: http://calagator.org/events/1250469385


> Diana
> 
> 
> 
> 
> On Fri, Dec 4, 2015 at 12:55 PM, Bryan Richter <b...@chreekat.net
> <mailto:b...@chreekat.net>> wrote:
> 
> On Fri, Dec 04, 2015 at 07:43:14PM +0100, mray wrote:
> >
> >
> > On 01.12.2015 21:53, Bryan Richter wrote:
> > > Well, after saying that, I *do* prefer white over some shades of
> gray.
> > >
> > > No terrible cultural reference intended.
> > >
> > > From my perspective, I'd like to offer at least two colors (maybe
> > > neutral and blue?), if not more.
> > >
> > > Robert, I suppose I'm not certain about your style guide. Is that
> > > *just* a guide for the web? E.g. would it be a bad idea to use a
> > > monochrome logo on top of a selection of colors better suited to
> > > humans that to websites?
> > >
> >
> > The guide has online use in mind and does not specifically treat other
> > media types. But even having the differences of printing and RGB
> display
> > in mind some things should remain as similar as possible. Namely the
> > colors. Introducing gray is not preferable if there is an option
> to use
> > our blue, but ultimately nothing is thought to be a law that cannot be
> > broken. it is just an order of preferences.
> >
> > I might prefer a clean grayscale shirt better to one where we
> would have
> > to use a strange blue that does not resemble our blue for example.
> 
> As mentioned in IRC, I've enlisted my mother (Diana Connolly) to help
> with colors. She's joined this list and should chime in momentarily.
> :)
> 
> ___
> 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
> 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] shirt colors

[Aaron Wolf]

Question was brought up about shirt color. Many people dislike truly
bright white shirts. We need to determine the options depending on what
vendor we end up with, but it seems a greyish light color could work
instead of white.

I think a lot of people don't really want to wear white t-shirts, I
think. Bryan says so for himself.

Besides off-white, should we consider a design with a dark color?

See the color scheme options at
https://snowdrift.coop/p/snowdrift/w/en/design-guide

So, thoughts?

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

Re: [Design] Mock-up to use in presentation?

[Aaron Wolf]

On 11/27/2015 04:54 AM, mray wrote:
> Hello Nico,
> 
> On 27.11.2015 00:26, Nico Rikken wrote:
>>
>> Can I use a crop of one of the new designs to highlight your work and
>> illustrate the funding concept?
>>
> 
> Bryan is right - you can use it to present the project of course.
> Apologies from my side since licence information *is* missing at the
> very moment.
>

Thanks Bryan and Robert for replying, and yes, of course, we're happy
for people to promote Snowdrift.coop etc.

I just want to mention and be completely clear about the licensing since
it relates to the files that Robert is referring to. As the site
references, there's a trademark policy:
https://snowdrift.coop/trademarks — so while most things are FLO, CC
BY-SA specifically, the logo stuff and thus any of the files that
directly integrate the logo should be considered per that trademark policy.

Now, 100% of the presentation use in this case fits within the trademark
policy anyway. I'm just mentioning this in terms of how we *should* be
marking the license stuff for the files.

Anyway, I don't think there's really any particular need to be picky
about licensing in this case. The use of logos for any trademark in
general is always fair when simply referencing the organization/product,
and the presentation being CC BY-SA doesn't change anything about the
logo. Just working to make sure everyone's clear here.

Nico, your presentation looks superb! I hope there will be a video…

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

Re: [Design] Elements needed for new homepage deployment

[Aaron Wolf]

On 11/17/2015 03:27 PM, Jason Harrer wrote:
> Hi, Aaron -
> 
> When I indicated we needed to talk about the revised home page, I was
> hoping more for of a meeting, where we can go over what we currently
> have, what we still need, what kind of verbiage needs to be changed to
> account for current Snowdrift lingo, where certain links need to be
> pointed to, what proposed links need to be removed, etc., so we can try
> and finish up the homepage and move on.
> 
> Any chance we can get a meeting on the books for that?
> 
> Thanks!!
> 
> - Jason (JazzyEagle)
> 

I'm okay with a meeting, but it also sounds like it's just stuff where I
should participate in the final design stuff too. It's gonna be a
process with discussion about each bit…

I'm flexible enough for a meeting, maybe Thursday or Friday would work?

> On Tue, Nov 17, 2015 at 4:12 PM, Aaron Wolf <aa...@snowdrift.coop
> <mailto:aa...@snowdrift.coop>> wrote:
> 
> So, I really want to see things pushed up to master sooner rather than
> later.
> 
> 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.
> 
> 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…
> 
> * 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.
> 
> * The "News and Activity" section needs to be addressed. We need to make
> sure people are aware of activity and make that prominent enough.
> 
> * 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.
> 
> Again, it's okay for things to be stubs and imperfect, but I'd like to
> see these issues at least figured out *enough* and to get things merged
> into master ASAP while we keep working.
> 
> Cheers,
> Aaron
> 
> --
> 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] Elements needed for new homepage deployment

[Aaron Wolf]

On 11/17/2015 04:33 PM, Stephen Michel wrote:
> 
> 
> On November 17, 2015 5:12:34 PM EST, Aaron Wolf <aa...@snowdrift.coop> 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?
> 

Well, there are pros and cons to wiki vs hardcoded right now. The point
in this case is that we're designing a more specific dedicated site page
that really isn't just part of the wiki. It will be primarily graphical,
less textual… I'm not sure it makes sense as a wiki page necessarily.
It's not absolutely out of the question though.

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

Well, although I want to see these things incorporated in the right way,
we're not discussing from scratch. Robert already has design work
largely done for many things, see
https://github.com/mray/Snowdrift-Design/blob/master/website-mockups/website_v39.svg

I think we just need to figure out in this where the activity/progress
stuff goes and where the volunteering stuff goes etc. and donate for
now. We're getting there.

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

[Design] Elements needed for new homepage deployment

[Aaron Wolf]

So, I really want to see things pushed up to master sooner rather than
later.

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.

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…

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

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

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

Again, it's okay for things to be stubs and imperfect, but I'd like to
see these issues at least figured out *enough* and to get things merged
into master ASAP while we keep working.

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] Design details

[Aaron Wolf]

On 11/02/2015 06:53 AM, Stephen Michel wrote:
> 
> 
> On Sun, Nov 1, 2015 at 9:32 PM, Aaron Wolf <aa...@snowdrift.coop> 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 agree that it works better on mobile in this case. There's something
about the way the further out trees look that doesn't work.

I like the idea of both the forest not being 100% covered in snow and of
the forest mostly being further off in the background, not crowding the
foreground. Sorta like these:

http://cdn.paulkirtley.co.uk/wp-content/uploads/2013/03/Snow-machine-drop-off.jpg

http://www.watercolour.tv/images/product/zoom_Paint_A_Snow_Scene_with_distant_forest___PART_1_1.jpg

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

That's not how human cognition works. The way to get comfortable talking
about the organization as "Snowdrift.coop" is to do it. Avoiding talking
about it is actually what mostly is reinforcing your discomfort. I have
experienced this myself on numerous times, I know what it's like to have
something in your mind just feel like a framing is wrong, like when I
first heard there was a programming concept called "a closure". It is
specifically by accepting the term and using it that you get
comfortable. The organizat

Re: [Design] comment/tickets next iteration

[Aaron Wolf]

On 10/24/2015 01:08 PM, mray wrote:
> 
> 
> On 24.10.2015 20:37, Aaron Wolf wrote:
>>
>>
>> On 10/24/2015 12:49 AM, mray wrote:
>>> no big changes, but still a step closer to what we need:
>>>
>>> https://img.bi/#/p9MIQuC!AQMlIV3Zgz2JhupM50I63gVbD1K3EKFqiJdnSBdH
>>>
>>
>> The claim view isn't great as there's unfortunately strange mix of the
>> same user listed three times, one in a claimed by message, one in a
>> message where marked as the claimer, and a reply that has no such
>> indication. I think this redundancy should be cleaned up.
> 
> 
> The main problem here is that there *isn't* a strange mix of users.
> I just stuck to one all over when actually there should be 18 random ones.
> 
> The idea is to have the claimant mentioned in the ticket head, but also
> highlight any post inside the ticket *FROM* the claimant.
> This should clarify the special context of all her posts.
> 
>>
>> Not a fan of "stub message" text.
> 
> you can regard *ALL* text here as place-holder. In this case this is
> whatever action info should go with the action buttons
> 
>> Note: the one-line rethread thing
>> won't have the drag stuff to resize the field, but that's just a picky
>> detail.
> 
> It is consistent to have a resizeable text entry field.
> Why would you want to remove it?
> 

It isn't consistent to have a resizeable text field. The resiezeable
field is for markdown fields that are marked that way in the code and
HTML. Other fields are not like that. For example, the comment field for
editing a wiki page is not resizeable and is plain text, not Markdown.
This can wait for discussion about implementation, but basically, the
question is: is this is a simple one-line plain text field or a full
markdown field that accepts multiple paragraphs etc. If it is a one-line
plain text field, it is different HTML, different in the database, there
is no such thing as multiple lines and paragraphs, and the field won't
be resizeable. We definitely have places in the site for both distinct
types of fields.


>>
>> I agree with Jason that retracted should have a different color / look
>> different.
>>
>> Overall, I think it makes sense to go ahead with implementation and not
>> make much more time with mockups. It's a good enough (great enough
>> really!) point already. Thanks!
>>
> 
> 
> 
> ___
> 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

Re: [Design] project page

[Aaron Wolf]

On 10/19/2015 12:57 PM, Stephen Michel wrote:
> 
> 
> On Mon, Oct 19, 2015 at 3:45 PM, Aaron Wolf <aa...@snowdrift.coop> wrote:
>> On 10/19/2015 12:30 PM, Stephen Michel wrote:
>>
>> On Mon, Oct 19, 2015 at 3:25 PM, Bryan Richter <b...@chreekat.net
>> <mailto:b...@chreekat.net>> wrote:
>>
>> On Sun, Oct 18, 2015 at 09:43:26PM +0200, mray wrote: On
>> 18.10.2015 21:18, Aaron Wolf wrote: > > 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. Then I think the message should be more clear.
>> First off, it's crucial that people realize "When I give the
>> project 6 bucks, it actually receives 15 since other people
>> match me." That is THE Snowdrift model. :) Matching-funds is
>> one of the crucial differentating features of Snowdrift, so if
>> people don't like it, they won't like Snowdrift. And if they
>> DO like it — which they should — we should highlight it so
>> they understand it's what we do. We should be proud of it.
>> 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. Isn't it two different things to
>> say, "Your funds will be matched by others," and, "Your
>> donation won't change over time?" We can easily say the first
>> one without making false claims about the second.
>> ___ Design mailing
>> list Design@lists.snowdrift.coop
>> <mailto:Design@lists.snowdrift.coop>
>> <mailto:Design@lists.snowdrift.coop>
>> https://lists.snowdrift.coop/mailman/listinfo/design 
>>
>> +1 to all of this. I'd like to highlight a different way of
>> pitching it: When you donate originally, your donation will be
>> matched by all current donors. When a new donor joins on, there's
>> now another person to match you, so your donation increases a
>> little bit (and is matched). 
>>
>> To be precise, if you're an average patron, then when you *first*
>> pledge, you are basically matched 1:1. But then every additional small
>> amount you put it after that is matched many times over, maybe
>> thousands-to-one! If you are the 5,000th patron and everyone's at the
>> base level, then your initial $5 is basically matched by $5 from
>> others. But when the *next* patron joins, your extra 0.1¢ is part of
>> an extra $10 — your extra is matched 10,000 to one!! 
> 
> I'm not sure this is the right way to think about it. If I'm the 5,000th
> patron, my initial $5 is matched 1:1. Now the next patron joins, and I
> add .1¢. Say I decide $5.001 is too much to pay, so I decide to drop
> out. The project loses my $5.0001, and $5 from the other patrons
> decreasing their pledge. Still 1:1.
> 
> I stick by this way of describing it: When I initially pledge, all ~5k
> patrons match .1¢ of my donation. When the next person joins, they match
> my additional .1¢.

Yes, when you drop out, it's a 1:1 loss, but it is literally true that
if you accept your $5 as a given, then your *acceptance* of giving
$5.001 *literally* means that your extra is indeed matched over and over
by every single other patron. It is factually true, not a weird spin,
that your agreement to donate more is matched by everyone else's
agreement to donate more, and so all patrons are getting matched many
times over for each *extra* they add beyond their initial level.

This is precisely true and how it works. You do *not* only get the
matching from the new patron, you *also* get matched by everyone else.

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

Re: [Design] project page

[Aaron Wolf]

On 10/18/2015 09:58 AM, Stephen Michel wrote:
> 
> 
> On Sun, Oct 18, 2015 at 12:57 PM, Jonathan Roberts
> <robertsthebr...@gmail.com> 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.
> 

Actually, it's X per patron, not "other patron"

The math is this simple: You pledge $1 per 1,000 patrons, so that means
if there's 340 patrons, you donate $0.34. If there's 3,400 patrons, you
donate $3.40.

There's no formula to explain. It's that simple. We used to have a more
complex formula for certain objectives, but the complexity was too
cumbersome.

There's nothing exponential here. The quadratic thing is simply this:
1,000 patrons * $1 = $1,000 but 5,000 patrons * $5 = $25,000. Basically,
it's quadratic because it's linear increase in patrons * linear increase
in per-patron donations. So the *total* is quadratic, but each patron's
donation increases linearly.

The key items are: "you pledge X per patron", "your pledge today will be
X * Y given Y patrons", "your matching from others will be Z", the total
from everyone is A"

>> On Sun, Oct 18, 2015 at 9:56 AM, Jonathan Roberts
>> <robertsthebr...@gmail.com <mailto:robertsthebr...@gmail.com>> 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 <aa...@snowdrift.coop
>> <mailto:aa...@snowdrift.coop>> 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 <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 <mailto: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

Re: [Design] Design Digest, Vol 7, Issue 10

[Aaron Wolf]

On 10/09/2015 11:42 PM, Stephen Michel wrote:
> Are we working directly with .pngs or are there .svg files somewhere?
> 

We are (and least speaking for myself) working with .svg in Inkscape.
The .png files are being linked to because SVG rendering of such complex
images in browsers isn't as simple, reliable, or appropriate as linking
to the .png files.

The stuff Robert has been doing is here:
https://www.github.com/mray/Snowdrift-Design/ in general.

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

Re: [Design] Let's Talk about Feedback & Landing Page Goal Discussion

[Aaron Wolf]

On 10/07/2015 03:08 PM, Jonathan Roberts wrote:
> I think the primary element that makes the old image effective is the
> timeline: it's showing you the finished project. The huge snowdrift
> beside the cleared road shows it, Mimi and Eunices faces show it, and
> the general vibe is that "The way has been cleared!" rather than
> "everything's still bleak and covered with snow." The surrounding
> atmosphere also confirms all of this; the friendly sun, the plane flying
> by, the vibrant trees. This world is alive and well on it's way to
> positive change, not still stuck in a pre-snowdrift.coop
> <http://pre-snowdrift.coop> malaise. A graphic where everything is still
> covered with snow is just not as exciting, hopeful, or effective in
> getting the metaphor across.
> 
> If our metaphor was something having to do with defeating villians,
> would we be showing a graphic with a bunch of villains towaring over the
> hero, or showing the hero just winding up his punch? No! We would be
> showing the villains flying in all directions from the hero's punches,
> or lying defeated in a pile with the hero standing over them!
> 
> So ya...to me all this discussion about whether there should or
> shouldn't be trees is like arguing about whether the hero should be
> wearing a cape or not. I think it's irrelevant, and I think the point in
> the timeline we're showing is the actual missing element.
> 

I think the feeling we want is one that says there's good promise, good
progress, but lots to do, and we need to work together to get it done,
*will we do it?*… i.e. a middle-ground in the time-line, partly cleared,
reason for both optimism and concern, much to do still.

Think of any other political movement like an environmentalist
organization. They wouldn't show *just* images of pollution and horror,
but neither would they just nice nature scenes.


> On Wed, Oct 7, 2015 at 1:48 PM, Aaron Wolf <aa...@snowdrift.coop
> <mailto:aa...@snowdrift.coop>> wrote:
> 
> 
> 
> On 10/07/2015 01:41 PM, Stephen Michel wrote:
> > Aside from my particular responses below, I'd really like to focus
> this
> > conversation on one question: What are our goals for the landing
> page? I
> > think once we're all 100% on the same page for that, it'll be much
> > easier to iterate on specifics.
> >
> > - In 1 second, get an arbitrary internet user emotionally invested in
> > Snowdrift.coop.
> >   - "Together, we can uncover this awesome thing that's currently
> being
> > suppressed."
> > - Encourage users to proceed deeper into the site
> >   - At the moment, this is by clicking the one big button on the
> front.
> > - Maintain visual consistency with the rest of the site.
> >
> > Thoughts?
> >
> > On Wed, Oct 7, 2015 at 4:01 PM, Aaron Wolf <aa...@snowdrift.coop
> <mailto:aa...@snowdrift.coop>> wrote:
> >> On 10/07/2015 12:29 PM, Stephen Michel wrote:
> >>
> >> In the context of our recent discussion
> >>   
>  
> <https://lists.snowdrift.coop/pipermail/design/2015-September/96.html>
> >> about the home page... Here's a pretty common thing that happens
> >> in communication between a user (Bob) and a designer (Alice).
> >> *Bob's Perspective:* Bob wants to give Alice some feedback about
> >> an email application he uses. Bob keeps hitting the delete button
> >> when he means to hit the save button. He wants to give good
> >> feedback, so he brainstorms a bit, and finally tells Alice
> that he
> >> thinks the application would be better if the save button were
> >> bigger. Alice replies, saying she won't make the save button any
> >> bigger. Bob is frustrated, and argues back with Alice. *Alice's
> >> Perspective:* Bob emailed Alice with a suggestion to make the
> save
> >> button bigger. However, if Alice did that, it would break the
> >> aesthetic of the application, and moreover, she's not sure if it
> >> would actually solve Bob's problem! Alice is frustrated, because
> >> she's arguing with Bob, and because Bob has an unsolved issue.
> >> *Analysis:* When Bob sends Alice only a suggestion, Alice is left
> >> with only two actionable options: implement (bad because Bob's
> >> suggestion introduces new problems) or not (she can also
> follow up
> >> with Bob, but Bob's still attached to his soluti

Re: [Design] Let's Talk about Feedback & Landing Page Goal Discussion

[Aaron Wolf]

On 10/07/2015 01:41 PM, Stephen Michel wrote:
> Aside from my particular responses below, I'd really like to focus this
> conversation on one question: What are our goals for the landing page? I
> think once we're all 100% on the same page for that, it'll be much
> easier to iterate on specifics.
> 
> - In 1 second, get an arbitrary internet user emotionally invested in
> Snowdrift.coop.
>   - "Together, we can uncover this awesome thing that's currently being
> suppressed."
> - Encourage users to proceed deeper into the site
>   - At the moment, this is by clicking the one big button on the front.
> - Maintain visual consistency with the rest of the site.
> 
> Thoughts?
> 
> On Wed, Oct 7, 2015 at 4:01 PM, Aaron Wolf <aa...@snowdrift.coop> wrote:
>> On 10/07/2015 12:29 PM, Stephen Michel wrote:
>>
>> In the context of our recent discussion
>> 
>> <https://lists.snowdrift.coop/pipermail/design/2015-September/96.html>
>> about the home page... Here's a pretty common thing that happens
>> in communication between a user (Bob) and a designer (Alice).
>> *Bob's Perspective:* Bob wants to give Alice some feedback about
>> an email application he uses. Bob keeps hitting the delete button
>> when he means to hit the save button. He wants to give good
>> feedback, so he brainstorms a bit, and finally tells Alice that he
>> thinks the application would be better if the save button were
>> bigger. Alice replies, saying she won't make the save button any
>> bigger. Bob is frustrated, and argues back with Alice. *Alice's
>> Perspective:* Bob emailed Alice with a suggestion to make the save
>> button bigger. However, if Alice did that, it would break the
>> aesthetic of the application, and moreover, she's not sure if it
>> would actually solve Bob's problem! Alice is frustrated, because
>> she's arguing with Bob, and because Bob has an unsolved issue.
>> *Analysis:* When Bob sends Alice only a suggestion, Alice is left
>> with only two actionable options: implement (bad because Bob's
>> suggestion introduces new problems) or not (she can also follow up
>> with Bob, but Bob's still attached to his solution and upset it
>> didn't happen). The problem is twofold: in his zeal to provide
>> good feedback, Bob is actually providing a suggestion --
>> essentially, doing design work -- rather than feedback. However,
>> he can't be expected to know what would be most helpful without
>> Alice letting him know what kind of feedback is helpful. As it is,
>> Alice is stuck trying to work backwards from Bob's suggestion to
>> exactly what his problem is. What should really happen, is a
>> discussion between Alice and Bob to figure out what Bob's issues
>> is (for example, the 'save' and 'delete' buttons are too close to
>> each other and have icons that are too similar). Then Alice has
>> the flexibility to design a solution that fixes Bob's problem
>> without introducing new issues. It's also worth mentioning that if
>> Bob provides only a suggestion, then even if Alice follows up
>> with, "I'm not going to implement that particular suggestion but
>> let's try to figure out a better one," Bob is still left with a
>> sour taste in his mouth because he has a tendency to become
>> attached to his solution. With that in mind, I'm going to try to
>> give a bunch of feedback such that we can have a discussion about
>> what should change, rather than arguing about whether the scene
>> needs more trees. More indented --> more specific suggestions -->
>> more change-able as long as the higher-level stuff doesn't change.
>> --- *I believe that our landing page should provide a 1-second
>> emotional explanation of why we care (or, why an arbitrary
>> internet user should care) about Snowdrift.coop.* /"Together, we
>> can uncover this awesome thing that's currently being
>> suppressed."/ - They'll get a longer explanation of why they
>> should care deeper into the site, but I think this is important as
>> a hook, to get them to be invested immediately and keep them
>> reading. *Thoughts on how to achieve this.* - I don't think a
>> sense of "path" is important. - I think a sense of "barren
>> wasteland" is important to *keep.* - HOWEVER, I also think there
>> needs to be a sense of "If we cleared away this snow, it'd be a
>> vibrant place!" I think this is the sense o

Re: [Design] Homepage illustration

[Aaron Wolf]

On 10/01/2015 01:58 PM, mray wrote:
> 
> 
> On 01.10.2015 20:00, Aaron Wolf wrote:
>>
>>
>> On 10/01/2015 10:12 AM, mray wrote:
>>>
>>>
>>> On 01.10.2015 17:29, Aaron Wolf wrote:
>>>> I agree that "works" as an entry is higher priority than vividness or
>>>> aesthetics, but these issues don't necessarily conflict.
>>>
>>> My point is that they do conflict in my eyes.
>>> You want more wood which isn't a topical thing but "completes" a picture
>>> in your head. To me the whole "snow" theme has a point, while "forest
>>> and trees" does not. It is about stylistic consistency and focus on the
>>> message. The "emptiness" you notice is the same you will experience on
>>> the other mainly white pages, I want to anticipate that and be able to
>>> reference the landing page in style and in feeling later on when pages
>>> are more boring.
>>
>> Marginalia stuff does not fundamentally necessarily distract.
> 
> In a snow-covered landscape they tend to do very quickly.
> 
>> Depth is good. It is not important that 100% of everything be on the most 
>> obvious
>> surface level. I'm not asking for trees and buildings to be surface
>> focus, I'm asking for the context to feel better. I'm not wanting
>> everything filled up either.
>>
> 
> I just see how additional things water down our message.
> 
>> I agree that we don't want the other pages to feel extremely sparse
>> compared to the landing page, but I really don't like the isolated
>> tundra feeling.
>>
>>>
>>>>
>>>> I think the barren wasteland feeling is actually negative. I might
>>>> dabble with updating things myself ever. I really insist that my two
>>>> other concerns be addressed: more buildings / destination in the
>>>> distance; more trees and landscape that makes this feel like familiar
>>>> and desireable place, not the tundra.
>>>
>>> When covered in snow everything is a "barren wasteland", and
>>> things that stick out *despite* the snow-cover steal focus instantly.
>>> Having more of everything makes it easier to have nice illustration but
>>> harder to get along a point (and harder to fit on different screen
>>> sizes, too).
>>
>> I'm not asking for "more of everything". I want very specific things, so
>> don't characterize my request as being insensitive to the value of
>> simplicity. I'm not suggesting just "more".
>>
>>> Let's not forget this isn't even about the snow - it is about *clearing
>>> the path*, destination and trees don't play a role.
>>
>> The idea of a path absolutely is connected to a sense of leading
>> somewhere.
> 
> I'm with you here, that is why there is a house.
> 
>> And trees that *frame* the path actually *increase* the
>> feeling of it being a path.
> 
> And here you lost me. My point is: trees are not part of the metaphor.
> You want to throw in lots of them right in the middle just so that we
> have a more path-ish path. If the path needs to be more distinct I'd try
> other things first.
> I think the signpost and the lane markings on the road are enough.
> 
>> These sorts of images push the center of
>> attention *super strongly* toward "path"
>> https://duckduckgo.com/?q=tree-lined+path=canonical=1=images
>>
>> I'm not asking specifically for that sort of image, but the flatness of
>> the path against the flat ground background actually is failing to draw
>> out the feeling of a path as effectively as it should. The current image
>> has the path and the non-path ground way too similar.
>>
>> Adding trees around the path and off in the distance *increases* the
>> framing on the path if we do it right. As is, the path looks pretty
>> arbitrary. We're on a flat wasteland and we could make a path anywhere
>> or just walk in any direction across the snow.
> 
> I don't think we have to rely on things that scream THIS IS AN IMPORTANT
> PATH! If the illustration is that bad in showing a road that needs
> clearing we better start from scratch.
> 
>>
>>> Having a more tangible destination makes things even harder, you don't
>>> know what others regard desirable. We also can't promise that the way we
>>> clear leads to a golden future for everybody.
>>
>> I didn't ask for a tangible destination. I want a *shadowy*, blurry,
>> vague destination. I said in my message about "leave it up to the
>> i

[Design] Homepage illustration

[Aaron Wolf]

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 the distance left to the
imagination

In comparison,
https://github.com/mray/Snowdrift-Design/blob/master/mray%20website%20mockups%20/export30/landing.png

Is clear, focused, tons of improvements. However, everything is a bit
flat now. It doesn't show a snowDRIFT, it just shows fallen snow. A
drift is when the snow piles up because the wind has made it all pile up
more. I miss the slight sense of piled up snow and more substantial
obstacle.

The landscape overall feels like barren wasteland. We're in the tundra,
in some desolate town in Siberia. This could be solved if we had more
shadowed distant buildings and such off in the far distance, a whole
potential destination that people can imagine getting to eventually. And
I want more trees, lots of trees, I want the sense that I'm in a
temperate area with trees, like where people actually live, not in the
tundra. It just needs distant forests, and bring back the twin pines.
It's very common to have trees along a street. Some sense of that will
actually *frame* the focus rather than distract from it.

Again:

* more trees in distance and throughout landscape, esp. the twin pines
on each side
* more fuzzy destination with more houses (not a couple who lives in the
tundra, but regular folks in a social setting)
* slightly improved sense of snow having piled up, lots to clear

I think these elements would really solidify the image.

Best,
Aaron

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

Re: [Design] Agree on a Slogan

[Aaron Wolf]

On 09/16/2015 03:54 AM, mray wrote:
> Hello everybody,
> 
> 
> It is time to have a fruitful discussion about our slogan, we don't have
> one - but we should. My current mock-ups just use "FUNDING A FREE
> CULTURE" but that isn't anything that has been decided at all.
> We are about to create promotional resources and eventually I'd like to
> make use of a slogan. We need to settle this soon.
> 
> The properties I seek in a slogan are:
> * brevity
> * concision
> * simplicity
> * clarity
> 
> Concerning what the slogan could convey have a look at our mission:
>   https://snowdrift.coop/p/snowdrift/w/en/mission
> or the slogan page:
>   https://snowdrift.coop/p/snowdrift/w/en/slogan
> 
> So here is my candidate:
> 
> 
> "WE FUND FREE CULTURE."
> 
> WE   indicates that it is about people (many!), maybe including you
> FUND covers our financial angle
> FREE is the best compressed version of Free/Libre/Open
> CULTURE  represents the scope of different content we support
> 
> 
> Thoughts? Comments? Alternatives?
> 

Obviously, it should be referenced that the current slogan on the site is:

"clearing the path to a Free/Libre/Open world"

The "clear the path" indicates our snowdrift metaphor (otherwise, with
no cue at all, it's far too easy for people to think 'snowball' and
think the snow metaphor is about how all the little donations add up,
instead of the desired metaphor of a blocked path). This version of the
slogan is predicated on a position that there exists no acceptable
truncation of "free/libre/open".

Why "free" even in "free culture" is a problem: Free is 95% of the time
associated with price, whether we like it or not. In fact, there's a
whole initiative in Portland, OR where I live to fight back against
"free culture" — that exact phrase. It's headed by musicians who are
trying to push back against the trend of people downloading music at no
charge (which we support, but we want artists funded) and *also*
(importantly) against the trend of bars getting live musicians to play
for zero pay just for "exposure" and such. In other words, to them "free
culture" is the whole trend of people thinking they can get everything
at no charge. Now, their whole initiative is misguided, but I mention it
for reference.

Obviously, "funding a free culture" makes it clear that we *aren't*
working against artists being paid. But still.

"culture" on its own definitely makes a lot of people thing this is
about art and not about science, software, or technology. Of course, we
have a strong software audience, so having a lot of software present, we
will be clearly about software, so emphasizing the cultural side in the
slogan does help offset that.

I think if there's one word to be the best truncation it's actually
"open" except that is a no-go because (A) tons of open-washing makes it
almost meaningless today, and (B) this would draw the ire of the FSF
folks who oppose the replacement of "free" with "open".

In various contexts, such as "clearing the path to a free world", the
term "free" sounds jingoistic, as "the free world" is used to mean
America / U.S. versus the Soviety Union etc.

Although "creative commons" is taken, various forms of statements around
the term "commons" or maybe "public goods" make sense. It is a totally
accurate way to describe us to say "we fund the digital commons" or
something of that ilk.

Please, others on this list, perspective is useful. Please share your
thoughts.

Best,
Aaron

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

Re: [Design] some notes on new mockups

[Aaron Wolf]

On 09/07/2015 04:44 AM, mray wrote:
> 
> 
> On 06.09.2015 00:59, Aaron Wolf wrote:
>> I see the value of that idea of visualizing lots of patrons. I'm ok with
>> that in general as long as we *also* include **right at the place of
>> pledging** the idea that all these patrons will add more to match you.
>> That's not present directly, only the idea that the existing patrons are
>> matching each other. I really want the call-to-action and the
>> visualization to indicate the idea that the project gets more from all
>> these patrons *if* you pledge. That idea isn't strong enough in the mock-up.
> 
> 
> What do you think about labeling the button to "pledge!" and "raise 684
> pledges" underneath it?
> 
> https://raw.githubusercontent.com/mray/Snowdrift-Design/master/mray%20website%20mockups%20/export27/project.png
> 
> Because actually visualizing it in this place really hard.
> 
> 

I think "pledge" is the right word, and I'm not certain about the
exclamation mark, but I lean toward supporting it.

"raise 684 pledges" is the right idea and better than nothing. It's nice
that it's so short, but it's unclear because "raise pledges" sounds a
little like "do the work of finding others to pledge" like "pledge to
get more pledges from others". And that's not right, obviously.

We *might* have to settle for imperfect and people will just get the idea.

My vision has been to have an actual stat available: the next pledge
will get $X extra matching from Y current patrons".

And we want to be able to express what the *current* cost of pledging
will be too. I think when people aren't sure what exactly their impact
or agreement is, they'll hesitate to click a pledge button.

I think we need to err on the side of clarity over brevity whenever they
conflict. We can work to get more concise over time but really cannot
afford to allow for any confusion or misunderstanding at this stage.


> 
>>
>>
>>>>
>>>> I *really* like the design otherwise!
>>>>
>>>> Last minor note for now: perhaps a clear watermark should be added to
>>>> these mockups to make it totally clear what they are?
>>>>
>>>
>>> As long as nothing indicates these are final I don't see a problem.
>>> Or what information exactly are you missing?
>>>
>>
>>
>> Well, for example, we don't yet have formal partnerships / affiliation
>> with all those organizations shown at the bottom of the mockups! We want
>> to and probably will get that, but I don't want to imply that we have
>> endorsements that we don't formally have yet…
>>
> 
> Is that watermark ok?
> 
>>
>>>
>>>> Thanks so much for all your work Robert! I'm excited to get things
>>>> implemented and get this thing going.
>>>>
>>>> Cheers,
>>>> Aaron
>>>>
>>>
>>>
>>>
>>> ___
>>> 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