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

[mray]

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




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

[mray]

On 30.07.2017 07:32, Jason Harrer wrote:
> Hello, all -
> 
> Sending to both Design & Dev mailing lists, as the discussion applies to
> both teams, and being that I can't make the weekly meetings (and seldom
> have time to read the minutes), I figured it best to have the discussion
> via the mailing lists.
> 
> With the SASS work underway (thanks to fr33's diligent patching and iko's
> diligent updating), I began work this evening reviewing how to start
> getting the dashboard page moving forward.  In particular, I wanted to
> validate that all of the requested data that is on the prototype can in
> fact be obtained.  It turns out that we need to review a big elephant in
> the room once again.
> 
> For reference, the prototype for the Dashboard can be viewed at
> https://snowdrift.sylphs.net/prototypes/alpha/dashboard/  I know mray is
> working on some updates here and there, but I don't think his updates
> included any plans on changing the piece that is the topic of this e-mail.
> 
> Under the Matches tab is a big red box that says "Monthly Limit".  This is
> apparently to reflect a user's ability to limit how much money a user is
> willing to pay out per month at the most.
> 
> 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.
> Iko thinks there was a decision change somewhere along the way in meetings
> whereby there was an agreement to create a $5 limit for each user during
> the alpha stage.  Being that I haven't been involved in meetings since the
> date/time change (as it conflicts with a standing weekly meeting for my day
> job), I can't really comment on that either way.  I'd like to make sure
> that everyone is in agreement that this is indeed a function that we wish
> to have, though, as that decision impacts next steps on moving forward (as
> outlined below in the summary).
> 
> 2) There is currently no back-end support for a limit of any dollar
> amount.  There isn't even a data element for such a limit to be stored
> within the database at all (not that I can see, anyway).  Setting up such
> logic, to the best of my foresight, would most likely entail updates to
> both the website logic (allowing the user to set their limit, limiting the
> amount a user can pledge to projects, etc.) as well as crowdmatch logic
> (ensuring that the total amount we're trying to charge the user doesn't
> exceed their limit...  Which theoretically should never happen if the
> website logic works properly to ensure the total we attempt to charge
> doesn't exceed their limit, but it's always good to double check just in
> case there's a bug somwhere...).  Such Development work is outside of my
> comfort zone and would have to rely on another Haskeller to have time to
> make updates,.
> 
> 
> That being said, we need to discuss whether the Design team needs to remove
> the limit button/verbiage and adjust the meter to not reflect the limit
> from the prototype - OR - if the Development team needs to make the
> appropriate updates in order to support limit functionality.
> 
> Any questions, please ask away.
> 
> Thanks!!
> 
> - Jason (JazzyEagle)
> 
> 

I'm not well informed about the exact current status from the code side.
My latest info on that matter is: There would be a hard 5$ limit,
without any way to change that. Adding an adjustable limit would have to
be implemented later on.

In terms of design this means a button is grayed out, and there is some
text that explains why it isn't working yet.

If it turns out we don't have any limit whatsoever I expect a very bad
impact on our credibility due to the hypothetical case of a pledge
amount explosion.

You say there is no hard 5$ limit. How hard is it to implement that?



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

[mray]

That is great news!

Are you available for a small chat so I can give you an update of where
we are?


- Robert



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



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

[Snowdrift-design] project files in Inkscape 0.92

[mray]

Unfortunately the great new Inkscape release comes with a major
annoyance: It changed the default document resolution to 96dpi (opposed
to 90dpi in the past).

This creates a popup upon opening any svg file created with a version
prior to 0.92 asking on how to proceed:

  "Set 'viewbox'" – "Scale elements" – "Ignore"

In order to have a consistent set of files I ask everybody to
* upgrade to Inkscape 0.92 or later
* create backup files when opening "old" files
* chose "Scale elements" and rectify scale issues

That way there should soon only be files that are scaled correctly and
don't open nagging popups.





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

[mray]

On 28.01.2017 21:03, Dave Crossland wrote:
> Hi
> 
> I commissioned this. The bugs can be reported on
> github.com/Google/fonts/issues
> 

Thanks a lot, Dave! This is awesome.



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

[Snowdrift-design] font roulette

[mray]

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



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

[mray]

On 13.01.2017 23:11, Michael Siepmann wrote:
> On 01/13/2017 03:02 PM, Aaron Wolf wrote:
>> 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.
> 
> On a related note, the easier it is in future to make adjustments to the
> script and video in light of feedback from a larger audience, the
> better. But of course also, the better it is at the outset, the better.
> All I'm saying is that if there are options for how to make the video
> where one option is slightly better right now, but will make it MUCH
> more work to make changes in future, then it may be worth opting for a
> slightly less optimal option that leaves us more able to make
> incremental improvements in future.
> 
> 
> 

I think you mentioned this earlier.
Thanks for bringing it up again now.
I'll keep in mind that looking at the video from that angle may offer
new ways to proceed with it down the road.

Constantly updating a video has many downsides, but I can see - for
example - how having an AB test might be very valuable.

...if only we had the ressources to gather this kind of data.



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

[mray]

On 13.01.2017 22:48, 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 stepping up and clarifying your view.
(Especially if it is in my favor!!! ;) )

A heated debate isn't indicating fighting here though.
Aaron is a great discussion partner. Even if we tend to spend too much
time on discussing some subjects I greatly appreciate the constructive
outcomes.

That said, email is really a bad medium sometimes.








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

[mray]

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

So we agree. You probably just did not consider that what you proposed
can be recognized as a kind of a "first draft" of an actual video.

I plan to make the directions the video can evolve into dependent on
skills, preferences and time of people working on it. Ideally based on
face to face conversations. Reading about more concrete ideas in an
email from somebody outside the "design role"(?) seems to be a domain
conflict.

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

I appreciate you giving ideas but reject general directives about
concrete imagery. It is up to the video team to create images that
accompany the text you have the – literal – final word in.

Before we start you are free to give ideas.
After there is something to talk about (not the final video) you can
voice your judgement.
In the meantime I expect you to let "video people" do their thing
independently of what you would like to see included.



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

Re: [Snowdrift-design] intro video storyboarding

[mray]

On 10.01.2017 05:48, Aaron Wolf wrote:
> ...
> 
> These are all just thoughts and suggestions for the most part, looking
> forward to seeing others' ideas.
> 

Thoughts and suggestions are welcome. If some parts are more than that
we might have a conflict of circles. I sympathise with your curiosity
but don't expect this list to be the main channel of exchange of ideas
in this process.

Please try to record the audio soon.



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

[mray]

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.






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

[mray]

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.



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

[mray]

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

Re: [Snowdrift-design] new video script draft

[mray]

On 09.01.2017 18:41, 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.
> 
> 
> 
>


Hello Johannes,

good to hear from you and see you are following the latest development
closely! I'm looking forward to work with you from here on (creating
storyboards) once we have audio files.


Concerning your feedback:
I'm glad you bring this up as I had the exact same problem with "site-wide".

There is a trade-off between clarity and precision.
Adding the concept "site-wide vs. non-site-wide" is not required to
achieve what we want to achieve.

Many questions *will* get raised without doubt, but this video does not
need to answer them all or set things straight.
Being correct and concise trumps removing doubt at this scope.

It is *escpecially* problematic to raise that term when there is only
one site that is the very project promoting it.




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

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

[mray]

On 06.01.2017 13:21, Stephen Michel wrote:
> It's not completely relevant to what we're doing, and we already do many of 
> the things the article suggests, but it's a useful reference nonetheless. 
> 
> https://trackchanges.postlight.com/the-user-experience-of-giving-away-money-d087b986daa1#.n6ii3e37c
> 

a good read, thanks!



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

[Snowdrift-design] Font-Weight

[mray]

Looking at the web rendered font makes me believe that on our mainly
white background the lighter cut of Rubik makes more sense as a the
default font. The downside to me seems that we would have to up the font
size a bit - and with it the line height, which should serve as the base
for the grid.

Anybody has opinions on that?



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

[mray]

On 30.11.2016 07:30, Aaron Wolf wrote:
> tentative 4a. "Our innovative platform empowers you to join with others
> to fund the public goods /you/ care about."
> 
> tentative 4b. "At Snowdrift.coop, you collaborate with others to build
> greater support for public goods."
> 
> I'm not happy with either 4, but the meaning I want to say here is:
> Snowdrift.coop (or "out platform" or similar subject) is about getting
> everyone to collaborate to address question just asked (i.e. to fund
> public goods). It's nice to emphasize that the users get to choose, but
> not sure that needs to be in 4. The only core thing is THIS (our
> platform) is for collaborative funding of public goods. Still need best
> wording for that.
> 

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

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

> 
> tentative 5a. "You do this with a simple pledge to the projects you care
> about: 'I'll donate $1 for every 1,000 patrons who pledge with me!' And
> you control your overall pledges by setting a monthly budget limit for
> the system."
> 
> tentative 5b. same as 5a but "a tenth of a cent for every patron…"
> instead of the $1 / 1000 version
> 
> We had played with phrases like "donate a tiny amount for *each* patron
> who supports the same projects" but I'm leaning toward just using
> concrete example of the proposed actual pledge amount. That makes it far
> easier for people to get the actual pledge instead of us hinting at
> something while people wonder what it really is.
> 
> As for the budget part, similarly for being concrete, I'd rather go in
> the *direction* of stating explicitly what happens. Something like "you
> set a monthly budget limit, so a pledge that would go beyond your budget
> gets automatically put on hold." Except that brings up all sorts of
> questions, so we can't say all that. But I want to at least hint at the
> clarity that you don't just hit a per-project budget and then stop
> matching (because people who think that and then experience otherwise
> will be annoyed with us more than if we give them the right idea from
> the get-go).
> 
> One bit we had that I like for consideration still: "You choose projects
> to support, and make a pledge…"
> 

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

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

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

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

> tentative 6a. "We call this "crowdmatching", and with this system, our
> support grows together and is directed towards the most promising projects."
> 
> tentative 6b. "This process, which we call *crowdmatching*, builds
> consensus and directs support to the most promising projects."
> 
> tentative 6c. This *crowdmatching* approach means that all the patrons
> of a project reinforce each other, and it naturally builds consensus,
> directing our support to the most promising projects."
> 
> 6c is longer and wordier, but I like the feel and it really draws out
> the feel and meaning the right way to me.


my tentative 6d.
  We call this "crowdmatching"; it is a network effect that reaches
  consensus on what we support.


> 
> FINAL 7. Join us in clearing the path to a free and open future!
> 
> Note: We can *maybe* tweak the FINAL lines before the actual production
> is done but I don't want to discuss them until all lines are in the same
> candidate-for-final state.
> 
> 


I think discussing this in the group was way more productive than I ever
can be alone. Hoping any of my takes help making a step forward...



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

[mray]

On 26.11.2016 05:11, Michael Siepmann wrote:
>  
> On 11/25/2016 10:17 AM, Aaron Wolf wrote:
>> 
 With the updated first line:

 SCRIPT2C/

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

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

 That's why we developed crowdmatching!

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

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

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

 /SCRIPT2C

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

> 
> I'm thinking that in this super-short intro, it would be better to omit
> any reference to a snowdrift. It's just too confusing, not necessary
> enough, and doesn't help to engage people right away. People can find
> out why we're called Snowdrift.coop later, but here they just need to
> know, understand, and feel positive about and interested in the core of
> what Snowdrift.coop is about.
> 
> As to the "free" qualifier discussion, I think it's absolutely critical
> to remember that the overwhelming majority of the world has not the
> faintest idea that a phrase like "free music" ever means anything other
> than "music you don't have to pay for".
> 
> Here's an idea omitting the Snowdrift reference. I've done quite a bit
> of other editing which I can explain if that would be helpful.
> 
> SUGGESTION/
> 
> When music, software, movies, news, research, and so on, are released as
> public goods, everyone can enjoy them freely, without limitations.
> 
> But who will pay for them to be created?
> 
> Snowdrift.coop's pioneering crowdmatching platform empowers you to join
> with others to fund the public goods /you/ want created.
> 
> You pledge to donate a tiny amount each month for each patron who
> supports a project with you, within a budget you control.
> 
> Your donation is matched by the rest of the community, building
> consensus that directs support to the most promising projects.
> 
> Join us in clearing the path to a free and open future!
> 
> /SUGGESTION
> 

I think this does work better for this very short format. Not losing
time in explaining a words heritage frees time to explain the core idea.
I think this enhances Aarons text in a concise way. Well done!

I like how this text fragment gets brushed and brushed like a raw
diamond. :)

I also like the idea of a more detailed video taking its time to address
the whole snowdrift dilemma explanation instead of brushing over it
really quick. It alone would justify to motivate people to watch more
videos.







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

[mray]

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.

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

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

> 
> Although it doesn't map perfectly to every situation, the two roads
> dilemma does highlight the rivalrousness that is real. You do not watch
> two movies at the same time. Or if you do, you have divided attention.
> You have limited attention, and giving it to one movie at a particular
> time means less available for a different movie. I can't imagine anyone
> sincerely disagreeing with that assertion.
> 
>>>
>>
>> I think A. is much better.
>> 1. It is simple short and easy.
>> 2. We convince with what is good about us, not by what is bad about others.
>>
> 
> This is the core issue. I'm pretty convinced that A is better for right
> now and for this video. I'm 100% convinced that A is acceptable in any case.
> 
> I still want B to be available, I will describe B somewhere sometime in
> some writing or such. I think B is more compelling in the fundamental
> way that "I fucking hate those sleazy ads!" is compelling. But it is
> divisive.
> 
> To use a different metaphor, A is like me saying "there's some nice
> aspects to co-ops, but here's some challenges and ideas that co-ops face
> (that don't apply to other businesses)". B is like me saying "co-ops are
> ethical and just, typical capitalist businesses where an owner dictates
> terms to the workers and clients have ethical problems X, Y, Z, and they
> shouldn't exist, we should only have co-ops."
> 
> To apply that to a strong example: A: "we built a co-op taxi service
> that uses a FLO app to increase efficiency and work in a more reliable
> way than traditional taxis!" versus B. "GPS and software organizing taxi
> service is superb, but Uber getting an effective monopoly with lock-in
> and dictated top-down terms is awful, That's why we built this co-op
> version of that sort of service; and we all should work to support this
> ethical vision and reject Uber!"
> 
> I see why there are good arguments for going with A, but people *should*
> recognize and experience the B argument, and it's a view I happen to hold.
>

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

[mray]

On 16.10.2016 02:19, Aaron Wolf wrote:
>> 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.

Our dilemma is fixed on a very specific setting and has a defined amount
of possible outcomes. A dilemma is nothing but a matrix of outcomes. The
toll-roads are not part of any such matrix. That makes them by
definition not part of our *Dilemma* even if we stick them inside our
*Metaphor*.

 Dilemma != Metaphor

I agree that you can invent a dilemma where toll-roads are part of a
matrix - but that clearly isn't ours. "How do we get a clear road (and
generally keep roads clear)?" is a question, not a dilemma. It may end
up in one, but to do so you'd have to narrow down its outcomes. You'd
have many possible answers to choose from:
 - shovel away the snow
 - heat up roads so they don't get covered by snow
 - control weather so it does not snow that much
 - build a roof over the roads
 - ...
 - ...you get the picture

You could only end up with a dilemma if you chose one path and map all
its possible outcomes to a matrix.

So, the toll-road is *disguised* as a new solution out of our dilemma,
when in fact it is not. It is ONLY part of a separate decision that may
lead to the dilemma. That decision had multiple outcomes that are not
mapped in any matrix/dilemma:
1. shovel snow (face the dilemma)
2. pay tolls
3. do both (support CC and use DRM)
4. climb over the snowdrift and walk (use only CC)
5. ...
6. ...

The word "dilemma" unfortunately is easily used for the whole Metaphor.
This makes it harder to understand that billboards, cameras and
toll-roads are no alternative "way out" of the dilemma. They are only a
metaphor for why you may agree to accept the challange to deal with a
dilemma.

I see a solution to all this by first pointing out that we agree that
free/sharable goods are something we all appreciate; Neither mentioning
"dilemma" in THAT context, nor stuffing it into the same metaphor as our
dilemma. Just setting a premise. Keeping it "snow free" so to speak.
After that we can go FULL DILEMMA and care about shovels and snow!


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

>>>
>>> Yes, the nuanced truth is that it's a continuum from no support to full
>>> potential, and we rarely are at either extreme. But that's too nuanced
>>> for the video, unless we take the time to express this further (like
>>> talking of some people who love shoveling snow).
>>>
>>
>> I can see how talking about "releveant projects" vs. "projects" can make
>> that difference already. As you said it does not have to transport all
>> nuances. It is enough if we somehow limit participation instead of
>> underlining our goal to be open for everything (which would be the
>> expected default I guess)
>>
> 
> Right, but for the video, I think "relevant" is implied. Why would we be
> talking about anything irrelevant?
> 

Because all free work is relevant to most of us, as a concept, even the
"non-relevant" work.




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

[mray]

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 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!"


Our extension weakens the impact strongly, too. It makes everything more
complex and ambiguous.

The one snowdrift dilemma has to be able to map all outcomes with its
setting. Like: "We want *certain* free stuff to be *properly* funded by
*many* people in a volunatary manner.

THIS is way closer to merging everything in one dilemma where all other
known projects would fail, but not us.


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

I think brevity can be applied by exactly stating what we see as the
problem, and NOT telling what it is not.

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

I'm not sure I understand what you want to clarify. You seem to
underline that the snowdrift-dilemma only makes a general assumption
about human behaviour that can't be mapped to our case 1:1. And in order
to map correctly we have to explain lots of things before we draw the
right picture in peoples minds.

My suggestion would be to even start out – right from the beginning –
with a framed version of the snowdrift dilemma that fits our needs. So
we don't have to introduce the "vanilla flavour" first, to then define
ourselves through the differences to that "vanilla flavour".


> 
>> I think the unsolved problem is to organize financial project support in
>> *direct relation* to the scope of public relevance. – Which is where we
>> can often spot a shocking discrepancy: Relevance != $upport
>> Our goal is to leverage exactly and only at this point.
>>
> 
> Yes, the nuanced truth is that it's a continuum from no support to full
> potential, and we rarely are at either extreme. But that's too nuanced
> for the video, unless we take the time to express this further (like
> talking of some people who love shoveling snow).
> 

I can see how talking about "releveant projects" vs. "projects" can make
that difference already. As you said it does not have to transport all
nuances. It is enough if we somehow limit participation instead of
underlining our goal to be open for everything (which would be the
expected default I guess)

>> We need to some

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

[mray]

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

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


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

I think at this point we need to add this caveat:
 "... But then how could we fund their development in the first place?
And expect really professional quality and dedication"

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

I like that.

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

I think "hyped-up" is a really alien accusation that smells of prejudice
towards our best known "competitor". Lets not start mudslinging ;)


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

All inn all this sounds good to me. If I would (but I don't want to) add
anything it would be to mention our Limit handling to take away fear of
explosion once people grasp that in fact we let them "steal money out of
each others pockets" ;)

If at any time you re-record this try to speak a *little bit* slower
than your first take. The images can't keep up with hasty speech.




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

[mray]

Intermission: We need a proper meeting for this, doing this the e-mail
style isn't going to work.



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

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

[mray]

On 29.08.2016 22:27, Michael Siepmann wrote:
> On 08/29/2016 01:45 PM, mray wrote:
> 
>> The last meeting made clear we need to settle on what we expect the page
>> to do for a user.
>>
>> My impression was always that MVP needs a page to satisfy the basic need
>> of people to see where there money goes in a system that is really "half
>> baked". There may be more need for many other visualizations, but for
>> this one it boils down to:
>>
>>  "Where did my money go?"
>>
>> (Aaron supposed to rename the tab to "Payment History" to somewhat
>> clarify its purpose.)
>>
>> @Michael:
>> What is your opinion on that matter? - What do you think the MVP page
>> should do for the user.
> 
> I think it includes "Where did my money go?" but also, importantly,
> "What's been happening with my pledges?".  People will pledge on
> Snowdrift.coop because they want to support projects, so it's important
> for the history page to show them what's happened each month with regard
> to their support for projects, whether or not any of their money went
> anywhere that month.

I don't know what you mean by "happening" in the question: "What's been
happening with my pledges?"

We don't decide what happens with money, but maybe you mean what your
current relation to projects you support/not support?
Giving money away is all there happens, the how & why should not be
explained via accounting. To me this feels like "Reverse engineering"
that might shed light on what our mechanism is. Having a dedicated page
to approach this issue seems a better solution.

I understand that the question "What's been happening with my pledges?"
can arise *nevertheless* and people may indeed find themselves trying to
understand it while looking at the payment history.
But if we accept the challenge to explain the mechanism there, it comes
at the cost of more complexity. This opposes our efforts to keep things
simple; the mechanism and its explanation.

> 
> I don't think it's OK in mid-May 2016, for example, as illustrated in
> the attached, to have the history tell them nothing about April and
> March other than that spending got carried over because the payment
> processing fee would make up more than 10%.

Agreed. This can be a problem. But all information is present
always – only in the "Matches" tab. Linking there would make sense in
the case of the last month being a carryover-month. Any other month can
not suffer that problem.

> 
>> I think any discussion about page mockups only makes sense in the
>> specific context of what needs to be solved by them.
>>
> 
> Agreed.
> 
> 



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

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

[mray]

The last meeting made clear we need to settle on what we expect the page
to do for a user.

My impression was always that MVP needs a page to satisfy the basic need
of people to see where there money goes in a system that is really "half
baked". There may be more need for many other visualizations, but for
this one it boils down to:

 "Where did my money go?"

(Aaron supposed to rename the tab to "Payment History" to somewhat
clarify its purpose.)

@Michael:
What is your opinion on that matter? - What do you think the MVP page
should do for the user.

I think any discussion about page mockups only makes sense in the
specific context of what needs to be solved by them.



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

[mray]

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


I completely agree that suspending has to happen as soon as the limit
gets reached. We even suspect monthly spendings to rise with time, so
this looks just like a temporary postponing a necessary raise of the
limit. Also it adds complexity.



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

[mray]

On 11.08.2016 00:42, Michael Siepmann wrote:
> On 08/10/2016 03:13 PM, mray wrote:
>> 
>> To me the simplest answer to "What did I pay last months - and why?" is:
>> "Nothing, because it got carried over." It is just not necessary to add
>> more information here in order to make sense in the type "2." (simple)
>> representation.
> 
> Lack of information does not equal simplicity.  You seem to me to be
> making a very specific assumption - that the user's interest in
> information about the month is completely dependent on whether they were
> charged or not.  If they weren't charged that month, you assume they
> have zero interest in knowing anything else about that month. 

True. But presence of information does also not equal clarity.


Yes, I assume a month that has no charge is ultimately *almost*
irrelevant to the mind that tries to understand where money goes. It can
at best explain where it does *not* go.

We are the ones that establish a system focussed on a monthly rhythm in
the first place. I feel like we should not put the burden on users when
our system starts to build up dependencies among months that need to be
resolved. It might be correct and clear, but probably comes with a
higher cognitive load.

> 
> 
>> concerning your two points:
>>
>> 1. I agree. The icon can be just omitted or repalced with something more
>> obvious or less misleading to solve this.
> 
> That will not solve the fact that you're saying "Until you're actually
> charged some money, I'm going to withhold all information about this
> month from you." The fundamental problem here is not the icon but that
> information about May should be provided under May, not June or July or
> however long it might be until the person is actually charged.

That information would of course be displayed in the currently running
months "matching" tab.

> 
>> 2. My mockup certainly does not eliminate the complexity that comes with
>> a carryover process. But it makes things appear where they happen. If
>> one month is surprisingly big (visually and financially) it is because
>> there are many things stuffed into it. What is mainly beneficial is the
>> simplicity of months that are "empty" and the ease of grasping the
>> mechanic of different months getting nested.
> 
> I don't agree that you're making things appear "where they happen" -
> quite the opposite in fact.  You're anchoring everything to the actual
> charge, with the result that you're showing what happened in May nested
> inside June.  The event of coming to owe a certain amount based on the
> number of patrons the project had at the end of May happened *in May*,
> not June.  The fact that the charge happened in June does not change that.
> 

It depends on what you focus. My premise was all along to focus on the
money that gets charged. So you may be right when you want to follow the
causes of the effect. I'm not interested in that as much as I'm
interested in the actual effects. And I don't count assumed future
behaviour of our mechanism as actual effect that has to leave its marks
in the history. You seem to regard it as integral part of our mechanism
and therefore ..."predicted facts?"

I'm not sure how to call that, but what I am after with the history page
is the quest of: "Where did my precious real money actually go?"

And if I didn't get charged but it only looks like I probably will, that
is almost as uncertain information as the next upcoming project
matching. Because I could quit Snowdrit.coop any second and go home with
that money.


> The "mechanic of different months getting nested" is in my view
> completely unnecessary and confusing.  It shouldn't exist in the first
> place so there should be no need for the user to grasp it.  It only
> arises because of the way you're wanting to anchor everything to the
> charge and treat what happens in a month with no charge as non-existent
> until the charge happens.  In my version there's no nesting, so no need
> to grasp any mechanic of nesting.
> 
> 
>>
>> Multiple months in a row with carryover would mean that there are many
>> "empty" smaller months and one with a big belly. This may take take up
>> more space but is certainly easier to parse. You just have to
>> "understand" one month instead of going back in history to make sense of
>> it all.
> 
> Again this is only true relative to your mental model that nothing
> really exists until an actual charge happens. 
> 
>> The reason I find it hard to mix your table layout with my approach is a
>> certain "rigidness". A table relies on a rhythm that is easily broken by
>> any

Re: [Snowdrift-design] Mockup of account history

[mray]

On 10.08.2016 19:01, Michael Siepmann wrote:
> On 08/10/2016 09:36 AM, Aaron Wolf wrote:
> 
>> On 08/10/2016 05:59 AM, Bryan Richter wrote:
>>> On Wed, Aug 10, 2016 at 12:35:03PM +0200, Robert Martinez (mray) wrote:
>>>> 
>>>> I think there need to be two distinct representations of your
>>>> activity on snowdrift.
>>>>
>>>> 1. A *complete* log of all activity, including details as date and
>>>> time when any project pledge button was used to pledge/unpledge,
>>>> date and time when your payment processor got set up correctly, when
>>>> you money actually got transferred, ... just *lots* of details.
>>>>
>>>> 2. An overview of what just happened, reassuring that things are
>>>> going as you expect them to go, and that you understood the
>>>> crowdmatching mechanism and that YOU are in control.
>>>>
>>>> Assuming that both views are needed my approach is to visually
>>>> support each accordingly. Your mockup seems closer to a
>>>> representation as in "1." But I'd like to have a very simple and
>>>> intuitive view in MVP that mainly addresses the understanding of the
>>>> mechanism rather than controlling its accuracy. Of course we need
>>>> both to live up to our proclaimed goals of transparency. My
>>>> rationale to go for "2." is that we are on a journey to approach
>>>> people and earn enough trust so that they give up control and hand
>>>> it over to our mechanism. Having good intentions(tm) and having
>>>> simple rules like: "Never over limit!" & "Always under 10% fees!" is
>>>> a good start. But we also need to create an experience of being the
>>>> driving force in that mechanism, and my impression is that
>>>> representation "2." supports that better than "1."
>>>>
>>>>
>>>> Michael, do you agree a distinction of "1." and "2." makes sense?
> 
> I agree that it may be helpful to have two available levels of detail
> for history, with things like exact pledge / unpledge dates and times
> and payment processor setup reserved for a "full detail" view.
> 
>>>> My premise to a representation of "2." is:
>>>>
>>>>--- "What did I pay last months - and why?" ---
>>>>
>>>> This question needs to be answered as simple and clear as possible.
>>>> Once we start explaining more we'll have a hard time to stay simple
>>>> and justifying not to go into even more detail.
>>>>
>>>>
>>>> So looking at your mockup this goes through my mind:
>>>>  * Why does paying $0 have to look as complex?
> 
> It should present the information of interest about that month in as
> simple a way as possible.  The fact that you're paying zero does not
> indicate that there's any less information of interest about that month
> than in other months.  It actually means there's *more* information to
> convey than usual, because there's still the information about your
> pledge values that month but there's also the information about (a) why
> you're paying zero and (b) what we're doing about it.
> 
> I think your mockup looks great visually, but I think the way you've
> moved information about May 2016 into June 2016 is problematic in two ways:
> 
> 1. When May 2016 is the most recent month (e.g. if today is June 15th)
> it has nothing to point up to.
> 
> 2. It makes the overall display more complex and confusing than if you
> kept the May details in May, as in my mockup.
> 

To me the simplest answer to "What did I pay last months - and why?" is:
"Nothing, because it got carried over." It is just not necessary to add
more information here in order to make sense in the type "2." (simple)
representation.

concerning your two points:

1. I agree. The icon can be just omitted or repalced with something more
obvious or less misleading to solve this.

2. My mockup certainly does not eliminate the complexity that comes with
a carryover process. But it makes things appear where they happen. If
one month is surprisingly big (visually and financially) it is because
there are many things stuffed into it. What is mainly beneficial is the
simplicity of months that are "empty" and the ease of grasping the
mechanic of different months getting nested.


> What I'd love to see is your visual treatment but keeping closer to my
> organization of information, including just referring to "carried over
> to/from next/previous m

Re: [Snowdrift-design] Mockup of account history

[mray]

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.



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

[mray]

On 08.08.2016 19:55, Michael Siepmann wrote:
> Here's a revised mockup without the pledge subtotal and showing both the "too 
> low" and "too high" reasons for carryover. In this example, the user 
> increased 
> their limit in July.  There are other changes also, such as noting what the 
> limit was on the charge line.  I'm also atttaching the .ODS file.
> 


I think there need to be two distinct representations of your activity
on snowdrift.

1. A *complete* log of all activity, including details as date and time
when any project pledge button was used to pledge/unpledge, date and
time when your payment processor got set up correctly, when you money
actually got transferred, ... just *lots* of details.

2. An overview of what just happened, reassuring that things are going
as you expect them to go, and that you understood the crowdmatching
mechanism and that YOU are in control.

Assuming that both views are needed my approach is to visually support
each accordingly. Your mockup seems closer to a representation as in
"1." But I'd like to have a very simple and intuitive view in MVP that
mainly addresses the understanding of the mechanism rather than
controlling its accuracy. Of course we need both to live up to our
proclaimed goals of transparency.
My rationale to go for "2." is that we are on a journey to approach
people and earn enough trust so that they give up control and hand it
over to our mechanism. Having good intentions(tm) and having simple
rules like: "Never over limit!" & "Always under 10% fees!" is a good
start. But we also need to create an experience of being the driving
force in that mechanism, and my impression is that representation "2."
supports that better than "1."


Michael, do you agree a distinction of "1." and "2." makes sense?


My premise to a representation of "2." is:

   --- "What did I pay last months - and why?" ---

This question needs to be answered as simple and clear as possible.
Once we start explaining more we'll have a hard time to stay simple and
justifying not to go into even more detail.


So looking at your mockup this goes through my mind:
 * Why does paying $0 have to look as complex?
 * Why are numbers of patrons so prominent?
 * Why list projects that got no money from me?
 * Why is the day of the month of transaction important?


My attached mockup addresses those issues by
 * simplifying $0-months and making the carry-over visually obvious
 * moving patrons away from where you probably do some quick math
 * removing suspended projects
 * removing the date

I do agree though, that having the respective limit for each month is
necessary, so I added that bit of information.


Michael, what are your views on having such a premise and approaching
things the way I do?




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

[mray]

On 03.08.2016 10:31, 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?

disclaimer: the actual numbers on the mockup can be considered random.

I regard familiarity to receipts and bills documents relatively
unimportant. Our mechanism is the driving force behind almost all
financial transactions - this does not compare to anything I know of.
We should focus on people understanding what the mechanism does, not how
it works "under the hood".
To be clear: I'm not promoting intransparency. There should be a gapless
log of transactions, but that isn't the history in my eyes.

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

I think this page should just show the payment history.
We may offer a complete log elsewhere.

@clearly indicating participation:
A simple list of projects can probably illustrate participation in any
given month most clearly. Since its almost only a log of binary choices.

@omitting
Example: *trying* to match many big projects without the necessary
backup isn't even participation. It is only intended and doesn't help to
clarify what actually happened.

The key concerns when giving up control are the questions:
"How much did they take?"
"Where did it go?"

The "why?" and "how?" are less interesting since you gave up control
already and handed it over to us.


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

You're right. My mockups content isn't for real and makes no sense on
that level.

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

A simple note:
"Your charge was just too low for the charging fee limit.
We carried it over to next month."

beneath that a big "0".
Because "0" is what happened.

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

My rationale is as above: The special thing about suspended projects is
their *lack* of participation. That is not to say the event can be
neglected, but in terms of displaying participation it does not make
sense to display "almost-paticipation".
It should be the job of the notification system to warn and the job of a
complete, gap-less log to document it.

The reason I think the history should not do all those jobs is that I
generally expect people not to care about gap-less documentation.
They should get an easy to digest history of what happened before with
their money.
At least that is what I would expect.

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

Re: [Snowdrift-design] Mockup of account history

[mray]

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.

* items that did not contribute to a months spending can be omitted for
clarity. Carried over pledges appear on the respective new month.
Suspended projects are not treated different as non-pledged and should
not show up specially. Notifications can be used to communicate all details.

* I also like keeping the history tab consistent with the running months
matching tab.



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

[mray]

On 27.06.2016 03:55, Aaron Wolf wrote:

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

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

> 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!"

That is the sugar coated version of:
"Hey you actually seem to like spending money with us. If you spend more
you'll probably like that more!  just a reminder "

To which I could reply:
"Yes of course, you set up a system that raises my participation at a
growing speed without me having control over it - no WONDER that I start
get closer to the limit and end up spending money. That is what the
limit is *for*."

I propose to not make a big fuss about approaching the limit at all.
Let's stay completely quiet until we hit it and *then* deal with
consequences. Not having to deal with constantly adjusting the limit to
projects (which you really want to see grow) is a better motivation than
pointing out how crowdmatching works, and that it *kind of* is expected
to behave a certain way (wich is always to give more) just to do the
right thing in general.



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

[mray]

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

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

> 
> I think if we explain all the reasoning, concepts etc. with the idea of
> "crowdmatching", everything will become clear and consistent.
> 
> I'm not actually proposing this, but it occurs to me that an extension
> of the slogan could then be something like "crowdmatching to free the
> commons" or "free the commons with crowdmatching" or even just
> "crowdmatching for the commons" (I don't like that because it implies
> that you could crowdmatch for other purposes, and I want to insist that
> public goods are the *only* legitimate type of thing in which
> crowdmatching makes sense (even if that's debatable, I want us to take
> that position — that crowdmatching for proprietary stuff makes no sense).
> 
> One more point: even though varying per-patron match levels may not
> strictly be the smallest possible way for us to get an operating system,
> it's at least arguable that including it may be necessary for the system
> to start out viable enough to successfully fund the Snowdrift.coop
> project. We don't want it to undo the network effect, but we certainly
> want the 1000 patrons we may get early on to total more than $1,000 per
> month if a portion of those patrons are wealthy and want to be at a more
> generous crowdmatching level. So, I'm not 100% sure that setting higher
> pledge base is not MVP. We need not only for the math and the system to
> work but for it to be a fundraising success enough that people don't
> write it off. My feeling is that having this as a factor to play with,
> maybe test, explore, A/B, research, etc. makes some sense.
>

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



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

[mray]

On 11.06.2016 01:39, 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.

I'd prefer not to reflect this now (not MVP) neither later.

Assuming we had the variable pledge level, I don't think that indicating
the slight tendency of having a "1:1.x" instead of a "1:1" match matters
enough to be underlined. It is the idea of matching itself that matters.
Similarly I don't see how matching a project with 5800 patrons is a
"bigger" motivation for compared to one with 5941 patrons. It is just
not that much of a relevant difference when pledging. It is the *network
effect* that matters, and the promise that it is really a crowd of
people and not some huge entity next to a few "idiots".

> 
> I've also added something inspired by the above about encouraging them
> to spread the word:
> 
> http://techdesignpsych.com/Temporary/snowdrift/project_sufficient.html
> 
> In thinking about that, I thought of a possible word to use
> "crowdmatching" and wondered if Snowdrift has ever considered using
> that?  I searched to see if anyone else was using it and found
> http://makinggoodthingshappen.org/about-crowdmatching-2/ using it in a
> somewhat different way.  For the moment, I've used the phrase "mutual
> matching" in the "spread the word" part of the mockup.
> 


Crowdmatching. I do love that term. :D
Let us use it full steam ahead! In comparison to "network effect" it is
hip, focussing more on the social side, and makes sense even to those
that are not researching the reasons how facebook became so big and its
alternatives stand no chance.



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

[mray]

On 06.06.2016 20:33, Michael Siepmann wrote:
> On 06/04/2016 03:18 AM, mray wrote:
>> On 04.06.2016 01:02, Michael Siepmann wrote:
>>> 
>>>
>>> Keeping project pages focused on project-specific info makes sense to
>>> me.  However, I think it would be good to have a green-yellow-red
>>> "account health" type of indicator that's on all pages when you're
>>> logged in, perhaps as part of the header, linking to the dashboard. When
>>> it's yellow or red, we want to draw people's attention to that even if
>>> they're on a project page.  When it's green, it provides a nice "feel
>>> good" cue and context to whatever you're doing on the site.
>>>
>> I share your view on the good feeling. I just guess I'm already ok with
>> being assured that a non-grayed out pledge button means I can
>> definitively pledge.
>> The buffer plays into that but isn't defined yet. I wonder how to
>> integrate that visually or just have it running in the background checks.
> 
> The good feeling is not just about being able to definitively pledge. 
> It's about knowing that your max can match plenty of new patrons.  I'm
> thinking about ideas for how to display it and word it.  The key is to
> orient people to keeping a healthy buffer between their current total
> pledge value and their monthly max.

I feel pushy about asking people to always raise their limit. Everybody
has a limit and we should not make people feel bad when they reach it.
We should also be fine with having a *HUGE* buffer at the beginning and
with a *close enough* buffer towards the end.
We can't assume where the hard limit of people purses resides.
...What is a "healthy buffer"?

We should take precautions to avoid people permanently getting into some
kind of "You promised to pledge at least 3 months, but it looks like
that won't be possible, please fix that"-dilemma.

> 
>>>>> Dashboard:
>>>>>
>>>>> * I'd like to address what seems to be fear #1 when it comes to the
>>>>> financial part: the limit.
>>>> I do not really understand the purpose of showing a number that is
>>>> twice the current limit. It seems pretty arbitrary.
>>>>
>>> I agree. However, showing the current max on a scale with red, yellow,
>>> and green zones could be helpful I think - kind of like a fuel tank
>>> gauge or something like that.
>>>
>> Actually the scale was an arbitrary choice. The reason I do this is
>> because you need to have some space upwards. If your current limit is
>> the maximum of the scale it isn't obvious that you can/shoukd move it
>> up. So it might be 3x the current value or always be either $10 $100 or
>> $1000 depending on your limit.
> It might be that not displaying any scale would be better.  I'm thinking
> of having a simple 3-state icon type of indicator, representing
> "plenty", "enough, but only just", and "not enough".  Then the actual
> amounts might be expressed numerically, but not on a scale, e.g. in
> terms of % increase in patrons you could match.
> 

I like that idea as it removes unnecessary info. A 3-state icon might
just miss the precision of conveying an the idea of scale. I'd be
interested how things actually look like, at least in proportion.

>>
>>>>> * "Status" is only relevant if thinks are not ok, so unless there are
>>>>> problems that shouldn't be there
>>>> +1
>>> Good point. However, I'd like to explore ways to do this without
>>> throwing out the table format in my mockups, which I think is helpful,
>>> both because it provides a simple clean layout and because it enables
>>> "Total" and "Reduced total" rows that show that information in clear
>>> visual relationship to the numbers that make up the total and reduced
>>> total.  One simple way would be to put the "Suspended" text after the
>>> project name, so that column would get wider in this case rather than
>>> having a "Status" column that, as mray points out, isn't really relevant
>>> when everything is OK.
>> I guess my main issue is to have a hypothetical problem presented in
>> detail when the solution is already reality: The limit takes care of
>> things not going beyond it. Seeing some equations with crossed out
>> numbers that contain prices higher than my limit makes me feel uneasy.
>> "Total" an "Reduced Total" should not even exist as concepts as by
>> definition the limit explicitly forbids the "Total" in that case.
>> 

Re: [Snowdrift-design] Interaction design mockups

[mray]

On 04.06.2016 01:02, Michael Siepmann wrote:
> On 06/02/2016 10:28 AM, Stephen Michel wrote:
>> On Thu, Jun 2, 2016 at 5:25 AM, mray <m...@mray.de> wrote:
>>> On 24.05.2016 19:42, Michael Siepmann wrote:
>>>>  I've put slightly revised versions of the interaction design mockups
>>>>  some of us looked at via Jitsi Meet yesterday in both the design
>>>> Seafile
>>>>  server (snowdrift.sylphs.net) and in browsable form at:
>>>>
>>>>  http://techdesignpsych.com/Temporary/snowdrift/
>>>>
>>>>  There may be a better way to share them in future, perhaps via git,
>>>> but
>>>>  for now I just wanted to make them available for discussion etc.
>>
>>> Project page:
>>>
>>> * A changing pledge level ($0,001) isn't MVP so we can ignore it for now
>>>
>>> * "All your pledges" comes with a lot of data that isn't really tied to
>>> the project page. To me this is an invitation to start comparing,
>>> calculating and weighing things against each other. In fact we want to
>>> avoid that and only raise awareness when problems do arise. We want
>>> people to focus on their binary choice of support, not estimating how
>>> cheap things are on average and "budget" along those thoughts. Things
>>> will evolve, and we need to make people stay with us when projects
>>> "explode".
>>
>> +1 to both. In addition to pushing people in a direction we don't
>> really want, I also found it odd that information about my account was
>> showing up on the project page. I would expect a project page to show
>> information about the project, and my status as a patron of it, but
>> not general account info.
> 
> Agree re MVP.
> 
> Keeping project pages focused on project-specific info makes sense to
> me.  However, I think it would be good to have a green-yellow-red
> "account health" type of indicator that's on all pages when you're
> logged in, perhaps as part of the header, linking to the dashboard. When
> it's yellow or red, we want to draw people's attention to that even if
> they're on a project page.  When it's green, it provides a nice "feel
> good" cue and context to whatever you're doing on the site.
> 

I share your view on the good feeling. I just guess I'm already ok with
being assured that a non-grayed out pledge button means I can
definitively pledge.
The buffer plays into that but isn't defined yet. I wonder how to
integrate that visually or just have it running in the background checks.


>>
>>> Dashboard:
>>>
>>> * I'd like to address what seems to be fear #1 when it comes to the
>>> financial part: the limit.
>>
>> I do not really understand the purpose of showing a number that is
>> twice the current limit. It seems pretty arbitrary.
>>
> I agree. However, showing the current max on a scale with red, yellow,
> and green zones could be helpful I think - kind of like a fuel tank
> gauge or something like that.
> 

Actually the scale was an arbitrary choice. The reason I do this is
because you need to have some space upwards. If your current limit is
the maximum of the scale it isn't obvious that you can/shoukd move it
up. So it might be 3x the current value or always be either $10 $100 or
$1000 depending on your limit.

>>> * "Status" is only relevant if thinks are not ok, so unless there are
>>> problems that shouldn't be there
>>
>> +1
> Good point. However, I'd like to explore ways to do this without
> throwing out the table format in my mockups, which I think is helpful,
> both because it provides a simple clean layout and because it enables
> "Total" and "Reduced total" rows that show that information in clear
> visual relationship to the numbers that make up the total and reduced
> total.  One simple way would be to put the "Suspended" text after the
> project name, so that column would get wider in this case rather than
> having a "Status" column that, as mray points out, isn't really relevant
> when everything is OK.

I guess my main issue is to have a hypothetical problem presented in
detail when the solution is already reality: The limit takes care of
things not going beyond it. Seeing some equations with crossed out
numbers that contain prices higher than my limit makes me feel uneasy.
"Total" an "Reduced Total" should not even exist as concepts as by
definition the limit explicitly forbids the "Total" in that case.
I feel much better with a system that just can't break instead of one
that lets me choose how to repair it. Of cou

[Snowdrift-design] Ethereum

[mray]

Hello there,

I'd like to get feedback from people who know this kind of stuff:
a blockchain based platform that sounds interesting -
https://www.ethereum.org

It looks like with it you can create your own Bitcoin-like system that
is as decentralized as Bitcoin but allows to add more rules. I was
wondering if snowdrift.coop could be an "democratic autonomous
organization" harnessing that technique.

It might be only a hip buzzword trophy - or maybe not so bad at all. Is
it crappy to think about doing our pledging that way?


mray



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

Re: [Snowdrift-design] MVP pages

[mray]

On 24.03.2016 21:29, Michael Siepmann wrote:
> Generally yes.  I think some of the info in some of the excluded pages
> (e.g. the sub-pages of /how-it-works/ and /about/ ) might need to be
> incorporated into the higher-level pages (e.g., /how-it-works ), perhaps
> partly via in-page tooltip-like things, but in general I'm in favor of
> reducing the number of pages for MVP.
> 
> Two of them are in both lists and I'm not clear on what the "replaced.."
> parts mean?
> 
> /honor-pledge (replaced with wiki link)
> /js-licenses (replaced by link to license text file in gitlab repo)
> 

Those will only be available as Links to other places and cease to have
their own page on snowdrift.coop for now


> I'm also not clear on how the honor pledge fits in to MVP, given it's
> about editing wiki pages and posting discussion comments?
> 

You're right this needs to be removed.
I think it does not fit the MVP or the account creation in general.
We should embraces racist trolls as long as their only interaction with
us is to give money to projects that meet our standards.

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


>  
> On 03/24/2016 04:52 AM and 03/24/2016 04:53 AM (merged by MSiep) mray wrote:
>> During the last meeting with iko and chreekat we compiled the list of
>> pages that seem to be needed for MVP:
>>
>> @Michael: does this look like a sensible set of pages in your eyes, too?
>>
>>
>> welcome
>> /about (the project organization for newcomers: team, contact info, etc)
>> /dashboard (overview and status of pledges and balance)
>> /login
>> /logout
>> /create-account
>> /change-passphrase
>> /reset-passphrase
>> /set-passphrase
>> /terms
>> /privacy
>> /trademarks
>> /how-it-works
>> /sponsors
>> /p
>> /p/snowdrift
>> /honor-pledge (replaced with wiki link)
>> /js-licenses (replaced by link to license text file in gitlab repo)
>>
>>
>> we also concluded that those pages would *not* be needed for MVP:
>>
>> /u
>> /u/#user
>> /about/contact
>> /about/team
>> /about/press
>> /transactions
>> /pledges
>> /how-it-works/sustainable-funding
>> /how-it-works/co-op
>> /how-it-works/network-effect
>> /how-it-works/flo
>> /donate
>> /honor-pledge (replaced with wiki link)
>> /merchandise
>> /search
>> /js-licenses (replaced by link to license text file in gitlab repo)
>>
> 
> 
> 
> ___
> 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] MVP pages

[mray]

On 24.03.2016 11:52, mray wrote:
> During the last meeting with iko and chreekat we compiled the list of
> pages that seem to be needed for MVP:
> 
> @Michael:
> 

I forgot to actually ask: does this look like a sensible set of pages in
your eyes, too?



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

[Snowdrift-design] MVP pages

[mray]

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)
/dashboard (overview and status of pledges and balance)
/login
/logout
/create-account
/change-passphrase
/reset-passphrase
/set-passphrase
/terms
/privacy
/trademarks
/how-it-works
/sponsors
/p
/p/snowdrift
/honor-pledge (replaced with wiki link)
/js-licenses (replaced by link to license text file in gitlab repo)


we also concluded that those pages would *not* be needed for MVP:

/u
/u/#user
/about/contact
/about/team
/about/press
/transactions
/pledges
/how-it-works/sustainable-funding
/how-it-works/co-op
/how-it-works/network-effect
/how-it-works/flo
/donate
/honor-pledge (replaced with wiki link)
/merchandise
/search
/js-licenses (replaced by link to license text file in gitlab repo)





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

Re: [Snowdrift-design] [Design] Getting intro messaging feedback at SCALE

[mray]

On 12.03.2016 19:05, Michael Siepmann wrote:
> I'm attaching a report on the intro messaging feedback from SCaLE 14x. 
> I'd be happy to discuss it in Monday's meeting if there's room in the
> agenda.  Comments, questions, or discussion via email are welcome too,
> of course.
> 
> By the way, I would not normally need anywhere near this long between
> getting data and reporting on it.  Unfortunately multiple factors
> conspired to cause a long delay in this case.
> 
> Best regards,
> 
> Michael
> 


Wow, thank you Michael!

These are insightful usable results, presented practically.
I could get used to get such high quality feedback served on a silver
plate. This is food for thought, start for discussions and raising tasks
to address directly.



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

Re: [Design] animation ideas for snowdrift dilemma etc

[mray]

On 29.01.2016 05:46, Aaron Wolf wrote:
> FLO *does* have a remarkable amount of volunteers given the situation,
> but we're still struggling greatly.
> 
> I'd like to see an animated video that explains the dilemma 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.
> 

A video certainly is a great tool. But I'd propose you provide a rough
description of what you need  first:

* intended message (purpose)
* length
* target audience
* where it will be seen

This would look much more like a constructive conversation starting
point to me. But then again I can't imagine to take care of a video
production right now. I also would like to wait until we have created
other materials first. This is not a priority to spend time on for us now.



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

[Design] seafile, our server, github

[mray]

We need to find a proper home for design related materials. Now.

While software & maintenance are no problem bandwidth and storage
persistence are. My inital hope to get a seafile server running for us
on a reliable machine seems unrealistic. Our server is overburdened
already and gnu.io offered to host code, not art ;)
So my suggestion is to use Github as our workhorse to take care of the
heavy file lifting.

The plan is to create an Github "organization" to manage access rights
and flood it with binary commits via sparkleshare.

Any thoughts?

@ikomi @hanitles:
What changes to the current file structure would you suggest?
I fired up my repo on github without collaboration in mind.


@Aaron: even though "open source" projects pay 0$ we still need to
provide an organizational email account - would it be ok to point to
i...@snowdrift.coop?



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

[Design] 4 issues priority

[mray]

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



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

[Design] /auth templates

[mray]

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.

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?



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

[Design] work on dashboard

[mray]

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.



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

Re: [Design] Stickers

[mray]

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.



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

Re: [Design] Stickers

[mray]

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.



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

Re: [Design] shirt colors

[mray]

On 11.12.2015 02:59, Aaron Wolf wrote:
> 
> 
> On 12/10/2015 05:23 PM, mray wrote:
>>
>>
>> On 11.12.2015 00:20, Diana Connolly wrote:
>>> Ok, I just talked to April at mill and I'm sending her more information via
>>> email so she can put together an idea of cost.
>>> As far as colors go, the shirt color doesn't matter at all. We could have
>>> one of every color and it wouldn't change the cost.
>>> There is a set up fee of $25 for one color, and you get one color change
>>> free.
>>> So we could do two shirt colors with different inks with no additional cost.
>>>
>>> Things that affect the costs are screens, ink changes, ink underlays if
>>> needed and shirts. Currently we have three designs to screen - logo and two
>>> cartoons. I'll let you know when I get more information.
>>>
>>> The next question is mostly for Robert - Do you envision any multi-color
>>> design at all?
>>>
>>
>>
>> Thanks Diana for your input and research!
>>
>> I think that printing just one color is the safest and cheapest way to
>> go. Given that a second color would only be used to add shading I don't
>> see the need for it. I'd only consider it for no extra cost.
>>
>> As a quick reference I threw together some shirt-ink combinations that
>> made sense to look.
>>
>> I think your palette opens a space for more exciting shirts but I also
>> think we should remain as close to a Snowdrift-ish look as possible.
>>
>> Having different cartoons on light/dark shirts is a result of the shovel
>> being impractical on extra background, but then again I like the idea of
>> having "light" and "dark" in more than one sense. I actually like that
>> subtle restriction.
>>
>> Spacing and size isn't final, just this together before going to bed.
>> All in all I think the combinations with most contrast are winners, gray
>> interestingly turns out to be even more problematic than I anticipated.
>>
>> Does anybody miss a combination?
>> What are your favorites?
>>
>>
> 
> Nice work mocking this up. I think the low-contrast bolder-blue shirt
> doesn't work and the medium-gray with white printing doesn't work, just
> not enough contrast.
> 
> I like the first in each row best initially, but then I also kinda like
> the top right if it just had a little more contrast, either or both
> slightly darker blue or larger size for the items on the back. It's a
> little harder to read, but the color combination is nice aesthetically.
> 
> I think the two shirts with the dark being the angrier one and the light
> being the shovel one, that's nice enough, even though it doesn't give
> people the option of preferring a dark shirt and the more mild design.
> 
> Otherwise, I'm not loving the light blue as the light shirt. So, I made
> some mockups quickly with the other shirts, the Cream, Sand, and Light
> Gray. I'm not sure what the back-image was from the site, looks like a
> light version of the Heather Gray. Anyway, I'd like to hear from others,
> but I think I prefer the Light Gray overall as the light shirt, and I
> like the Cream and Sand options too. See my attached file.
> 
> Aaron
>

Leaving aesthetics apart – the warm colors don't feel snowdrift-ish
enough for me.
Ironically the best gray (the one from the back shot) does not seem to
be available as an option, which is why I put in the closest thing in my
mockup.

My favorites are the same as Jonathans:

* Aarons top right (if available!)
* my bottom middle


Robert



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

Re: [Design] /Project page "ready"

[mray]

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?

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

> 
> I don't know if @media queries can consider height, but I would use the
> breakpoints in such a way that anything within the 1300 to 1399 width
> size should be assumed to be widescreen, i.e. to be relatively short
> height. I think that all taller screen dimensions are more like 1200
> pixels wide or less or get into higher-res screens.
> 
> Other than those two issues, it's looking largely good, although I see
> various things I might want tweaked, but can wait until we hack out a
> more operational prototype.
> 
> Cheers!
> 
> 
> 
> On 12/05/2015 04:15 PM, mray wrote:
>> I just want to let you know that my current branch at
>>
>>   https://git.gnu.io/mray/snowdrift/commits/new-project-page
>>
>> contains /project HTML and CSS that "could go live" from my part.
>> It is not super polished and may still have bigger issues, but nothing
>> that jumps to my eye.
>>
>> Note that I also changed other files and moved css into default-layout
>>
>> Cheers,
>> Robert
>>
>>
>>
>> ___
>> 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: [Design] Mock-up to use in presentation?

[mray]

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.



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

Re: [Design] comment/tickets next iteration

[mray]

On 25.10.2015 04:42, Aaron Wolf wrote:
> 
> 
> 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.
> 

In that case I agree.
It raises the question though why some posts are of a different nature.
Even posting a comment on why and where a thread was rethreaded is part
of a discourse that should be treated consistently, and that includes
being able to use all tools.
I imagnine for example, that you could want to emphasize things in your
rethread message.

I appreciate to resize the text entry field according to the expected
use. So having it small by default in this case vs. a normal comment.

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



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

Re: [Design] comment/tickets next iteration

[mray]

On 24.10.2015 15:34, Jason Harrer wrote:
> I'm really liking the new ideas in here!!  A couple of comments:
> 
> 1) The pink for flagging...  My only concern about the pink is that I'm not
> sure it totally fits a Snowdrift theme.  I'm thinking more red, but not for
> the most obvious reason:  When I think of a Snowdrift, I think of winter.
> When I think of winter, I think of Christmas.  I know a more solid red
> would go for an alert/flagging in general (which was the obvious reason I
> stated above), but it also is more of a Christmas-y color (along with green
> and gold, which you already have in the pre-defined palette), so I think it
> would work into the overall color scheme better.  I'm not completely
> opposed to the pink, and I can see how it blends with the lighter colors on
> the page and not being too harsh.  It was just an alternate consideration
> to ponder.
> 

The new colors are not set in stone, I'll adjust them depending on how
they fit in the end. I don't have a big issue with pink though. Red is
pretty strong and certainly does not indicate "de-escalation"

Do you have another possible alternative in mind?

> 2) About four comments down, you have a comment that is surrounded by a
> box, though I can't figure out why (maybe you just forgot to remove it from
> a prior iteration?).

The box indicates that the post is your post.
The avatar also reflects this.
Is that what you referred to?

>  Taking a look later on, it looks like retractions
> will look close to this as well.  I'm concerned that they'll look too
> similar and be mixed up.  I'm thinking there should be a separate color for
> retractions, so that is more easily recognized as a retraction and less
> confused with something else.

This is my fault.
Again this is a retraction from *your* post.
Dark Blue borders are supposed to highlight your own stuff.
I probably need to add an example of how retracted posts look like from
other persons. I wasn't sure whether others would see them, but now I
know they do.

> 
> Overall, I really like where this is going!!!  Thanks for working on this!!
> 
> - Jason
> 
> On Sat, Oct 24, 2015 at 1:49 AM, mray <m...@mray.de> wrote:
> 
>> no big changes, but still a step closer to what we need:
>>
>> https://img.bi/#/p9MIQuC!AQMlIV3Zgz2JhupM50I63gVbD1K3EKFqiJdnSBdH
>>
>>
>> ___
>> 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: [Design] comment/tickets next iteration

[mray]

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?

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



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

Re: [Design] discussion/comments/tickets/issues/flag/reply/forum thing v3

[mray]

On 20.10.2015 17:18, Aaron Wolf wrote:
> 
> 
> On 10/20/2015 02:56 AM, mray wrote:
>> Hello List,
>>
>> I need some feedback again. What did I not address good enough? - What
>> is missing? - What does not work? (Remember this is a quick rough mockup
>> - things like spacing are subject to change.)
>>
>> https://img.bi/#/zNcjcjE!fimjbJnZLC8O-5rxbKjZaA-1M_cRSQSFJB4lgh7j
>>
>> If this works good enough I'd like to move on to other stuff again.
>>
> 
> I'm not seeing the "claim" action for tickets. And also the indication
> of claim status for tickets already claimed.
> 

Can tickets be owned by multiple people?
If so - what is is a sensible maximum to assume?

> I really think the "optional:…" notice for the flagging view needs to be
> *above* the text field.

I'd like to consistently stick messages that go with input fields under
the form where they don't get in the way so much.

> 
> The view once flagged maybe doesn't need to be perfect in this mockup,
> but… it *should* indicate which violations were checked, and it should
> *not* show anything about the comment besides the text. It shouldn't
> show who flagged you, it should have no reply or other actions or
> anything. You don't tag or watch or anything the flag comment. It
> shouldn't look like a thread or reply at all. It *needs* to have a
> message (not looking like a comment post):
> 
> "A user flagged this comment as a violation of the Code of Conduct due
> to [checked reasons]. [show the feedback comment in a new paragraph].
> You probably didn't anticipate this interpretation when posting, but
> it's not a big deal. Please just edit your comment to address these
> concerns and repost."
> 

note: I think the text omits crucial information about how the flag
hides the text unless corrected and unflagged.

> And the flagged comment view will really only be seen by moderators and
> the original poster, so we can assume for the design that it's the
> original poster viewing. So, it should *already* have the comment in a
> text field ready to edit.
> 
> At some level, this stuff is already how it works, so when we implement,
> we'll keep it, but if you want the mockup to be more clear, it should
> address these things.
> 
> Finally, there should be a link for "get moderator help" or something.
> 
> I think we should *probably* indicate in the original flagging interface
> that the comment will be sent anonymously so people don't feel worried
> or unclear about that.
> 
> I still think the comment for rethreading can remain a single line field
> instead of a larger field.
> 
> Overall, I don't know if it matters that the design mockup is that much
> more perfect. It's good as a guide, and we can deal with nitty-gritty
> questions during implementation.
> 
> Thanks for all the great work
> 
> 
> 



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

Re: [Design] discussion/comments/tickets/issues/flag/reply/forumthingv3

[mray]

On 21.10.2015 02:48, Stephen Michel wrote:
> I meant the child ticket bubble itself. What're the use cases? I wrote
> this just by typing my thoughts. I was trying to think, if I come to a
> ticket, in what situations would it be useful for me to have more
> information, and which information?
> 
> Another way I could have said it: I have no personal or professional
> experience with this kind of system and I'm curious about your thought
> process behind the design.


I'm not used to such a system either, but there is the idea that nested
tickets build up a dependency where the parent ticket cannot/should not
be closed unless al children are closed, too. Since tickets can get
shown "out of context" via a permalink it is important to know about the
heritage. And since any tickets can be collapsed it would be useful to
see if some sub-tickets hare hidden within.



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

Re: [Design] project page

[mray]

On 18.10.2015 09:47, Jacob Chapman wrote:
> https://img.bi/#/RCmUlLW!XJcF_0gW1TKIEhMR59pFJQwpVPv_6YwlrJSRHI8n
> 
> We really need to emphasize the matching aspect of pledges to encourage
> patrons to pledge.
> 

The problem with the match factor is that it is always the same, so
there is no real benefit in constantly reminding a user what it is.
It also is just an invitation to start calculating in the head - which
I'd like to avoid at all costs.

  We should not make people calculate.

They should see what is happening and what the results of their possible
action would be, and formulas don't really lend themselves neither to
emphasize nor to encourage (at least the vast majority).

I do share your concern that the current illustration isn't good enough.
Displaying each donor via an icon does not clarify each one matches the
other.
I'm going to try alternatives.

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

Ok. It didn't occur to me that there was an inconsistency.

> 
> Thanks,
> Jacob
> ___
> 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: [Design] discussion/ticket system mockups

[mray]

On 16.10.2015 01:08, Bryan Richter wrote:
> On Fri, Oct 16, 2015 at 12:29:36AM +0200, mray wrote:
>> After some discussions with wolftune it dawned on me that we probably
>> have to stick to our discussion/ticket system.
>>
>> I thought we might as well make it more usable then. Here is where we
>> currently are:
>>
>> https://img.bi/#/tMpXHzF!jefIs_vKO6A8a2S4CFDwDg6TK4Qw9JNMzHkb99u5
>>
>>
>> Any feedback?
> 
> Looks great! As I said in IRC, I like the avatar integration and it
> seems like the links around the text-entry box are not too cluttered.
> [These were two points discussed after an earlier iteration.]
> 
> I have two specific questions and one unrelated question:
> 
> 1. I find it hard to recognize the dash (-) as something to click on
> to hide a thread. That might be because the dash is *inside* the block
> it ostensibly closes. Maybe better like this?
> 
> https://img.bi/#/abqkwvI!pka8hJ924A1YWjwi6W58pwO_uQpg3758Yn13YVV6

You're moving the dash outside the box right?
I think a box and its functionality should remain contained in itself.
The dash was [-] before and is also positioned like on
https://www.reddit.com/r/science/comments/2ypaa7/enceladus_saturns_6th_largest_moon_has_a_warm/
for example.
I might play with alternatives like triangles like fr33domlover
suggested on IRC tough.
The reason I stuck with typographical elements is that they are
minimalistic and fit to the rest. If possible I want to avoid attention
in the header part, it is already too loud up there imho.

> 
> (Sorry for poor quality and everything else — I lack the tools and
> such.)

Looks way better than my haskell code!

> 
> 2. I don't like the phrase "remember to follow the Code of Conduct".
> How do people feel about "The Code of Conduct matters!"

I don't have hard feelings about that one, design wise it only mattered
where to position and whether to have a whole sentence.
At this point I even think we could have a set of sentences that
randomly changes to grab peoples attention in a subtle way until they
realize "we mean it". What do you think?

> 
> 3. [unrelated] Robert, are you comfortable using web fonts? I've heard
> they're a no-no in terms of page-load speeds. I don't have a strong
> opinion, but I'm curious to hear yours.

This is related. The new design is 90% webfont! I regard it almost as an
impertaive to use non-standard fonts in cases where design is of any
interest. The dark ages of verdana and arial are way past us now
(FORTUNATELY!). HTML is robust enough to switch to fallbacks and if you
don't pick multiple large fonts with huge charactersets and weight you
end up having a decent impact on page loading.
So am I comfortable? - It is a *relief* to finally be able to use fonts.




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

Re: [Design] Homepage illustration

[mray]

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.

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

My conclusion is that what you ask for tries to do too much and achieve
too little. I prefer boiling it down to what matters and have *that* work.

>>
>> I addressed your desire to add more snow to the road though:
>> http://ur1.ca/nw6cf
>>
> 
> I'm not sure that particular touch-up is good, it doesn't get the "pile
> of snow" feeling as well as either the earlier mockups or the
> https://snowdrift.coop/static/img/intro/snowdrift.png illustration. It's
> hard to pin down why, but that illustration I made (which was based on a
> photograph incidentally) achieves a stronger sense of substantial
> obstacle, although I also like the sense that the Mimi & Eunice
> illustrations have that there's snow to clear for a good long ways down
> the road, not just this singular snowdrift to clear.
> 
> Anyway, the new update doesn't quite have the clarity about the
> snowdrift that would be ideal.

but is it better than the version before?

> 
> I also think Jon and Stephen have some good points, although I don't
> agree with Stephen that we need a "professional" font, I think the new
> font choice is fine. I also think we should go ahead with mocking things
> up with the new "Free the Commons" slogan candidate.






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

Re: [Design] Homepage illustration

[mray]

On 30.09.2015 23:45, Jonathan Roberts wrote:
> Four thoughts from a previously silent watcher...
> 
> First, have there been more thoughts about the catchphrase at the top? How
> about "Funding a cooperative culture" - I like the alliteration, and I like
> the sort of subtle subversive suggestion that the current culture is
> somehow not cooperative...
> 

We have pretty much settled with "free the commons" by now. If you are
interested catch up the "Agree on a Slogan" thread.

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

The first one is also the older one. Development since then wasn't just
a search for alternatives, but is the result of many iterations of
feedback. If you miss a particular quality in the new that the old does
have please try to describe it more clearly. I don't follow exactly what
your suggestion is.


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

Textual changes might better be discussed separately. I changed the text
on my own behalf and want to stress they are not official or final.

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

I agree that putting it on the first page makes it more prominent.
Unfortunately it also degrades the importance to have it below the
actual landing part and having to let people scroll by the "big action"
button to see it.
Currently it will appear right after the first click on the most
prominent button on the page, which is good enough I think.



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

Re: [Design] some notes on new mockups

[mray]

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




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