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

[Bryan Richter]

On Tue, Aug 01, 2017 at 07:37:59AM -0500, Jason Harrer wrote:
> Not sure how the dev list got removed, but adding it back in at this point.
> 
> It sounds like there was consensus on this overall limit (just not project
> limits).  That being said, I'm going to open up a ticket on GitLab so we on
> the Dev team can track adding that in.  This is a requirement before we can
> get the Dashboard page finished.

Can you explain why it's a requirement?

As far as I understand it, the page simply has to say that a limit
exists.

My point, that I'm making here and elsewhere, is that implementing an
automatic cutoff is not a necessary step for alpha. The process can
remain manual for the time being.

There are a lot of other manual things I'd rather automate first.


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

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

[Bryan Richter]

On Sun, Jul 30, 2017 at 04:28:24PM +0200, Robert Martinez (mray) wrote:
> 
> 
> 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?
> 

It currently *is* implemented. It is part of the manual pledge
process. That pledge process goes like:

1. Check to see if the global donation amount (which is the same for
   everyone who is a patron) is over or under the limit.
2. If it is under, do the pledge.
3. If it is over, have a major effin' celebration, because that means
   Snowdrift has an income of $25,000 per month.



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

Re: [Snowdrift-design] Intro video script

[Bryan Richter]

I am snipping wildly to respond to one point Stephen made:

On Sat, Dec 03, 2016 at 03:17:38PM -0500, Stephen Michel wrote:
> On Sat, Dec 3, 2016 at 2:16 PM, Michael Siepmann wrote:
>>
>>On 12/01/2016 07:52 AM, mray wrote:
>>> On 30.11.2016 07:30, Aaron Wolf wrote:
>>>
>>> Here is a new take:
>>> * being discrete
>>> * visualizing
>>> * working with contrast
>>>
>>> my tentative 5c.
>>>   Patrons pledge *only one 10th of a cent*!!...
>>>   – but – for *every* other patron of a project.
>>>
>>>   A group of 10 agrees on paying *a cent each*!!...
>>>   – but – A *crowd* of 1000 already agrees to pay a dollar each.
>>>
>>>   When a crowd gets too big for you - step back any time.
>>
>> I like the concreteness of $1 for every 1000 patrons, but I'm
>> concerned that it is easily misunderstood as meaning you donate zero
>> until there are 1000 patrons, then $1 until there are 2000 patrons,
>> then $2, etc.  But I like that it's easier to relate to than a tenth
>> of a cent. Maybe "1 cent for every 10 patrons" would be a happy
>> medium here? That's arguably more accurate since of course we can't
>> actually charge people in tenths of a cent increments.
>
> I actually had this same thought, when I was looking at the dashboard
> and thinking that it's kind of odd to display the pledge level as .5
> cents and the project income as 2.5 cents, when actually at that level
> no crowdmatch will happen.

Actually, it does happen. After a crowdmatch at this level, you will
"owe" the project 0.5 cents.

You just won't be charged. In fact, you'll never be charged fractions
of a cent.

0.5 is a really depressing number, but note that this would also be
true for a crowdmatch of $4.128. Especially if the previous month was
$1.023. After those two months, you would owe 4.128 + 1.023 = $5.151,
and you would be charged $5.15 (plus fees).

In other words, you crowdmatch those fractions of a cent, and they carry
over.

Of course, we're talking about the difference between $5.14 and $5.15
(shock!), but I don't think we need to change how it works. This really
does match every last person.


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

Re: [Snowdrift-design] Intro video script

[Bryan Richter]

On Thu, Nov 24, 2016 at 08:10:47AM -0500, Stephen Michel wrote:
> 
> On November 24, 2016 4:52:08 AM EST, mray wrote:
> >
> >Unrelated to the above we may want to note that we are a non-profit
> >coop. It can be a short mention but it would adds a lot to the
> >credibility. - Maybe even set that straight right from the start so
> >it does suppress peoples thoughts about our "business model" behind
> >all this while they watch? Or put it in the end and together with
> >naming our name and slogan?
> 
> No opinion.

We can't do this, because we aren't a non-profit, nor are we a co-op.
Those are outstanding goals. And after talking to an expert at SeaGL,
I sort of get the feeling they require a lot of rework to become
achievable.


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

[Snowdrift-design] top-padding for

[Bryan Richter]

The default styling has 3 rem of bottom-padding for . I think it
needs top-padding, too. Otherwise it's pretty bunched up against a
preceding .

I'm not sure how to add some padding while preserving vertical rhythm.
Would someone like to play with it?


signature.asc
Description: 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

[Bryan Richter]

On Fri, Sep 02, 2016 at 12:25:56AM +0200, Robert Martinez (mray)
wrote:
> 
> On 01.09.2016 16:38, Michael Siepmann wrote:
> >  
> > On 08/31/2016 11:48 PM, Bryan Richter wrote:
> >>
> >> I agree with mray that we need a simple, clear, unambiguous
> >> description of payment history, and I agree with Msiep that such
> >> information is not sufficient for selling Snowdrift to the world
> >> at large — and the whole is greater than the sum of its parts.
> > 
> > Sounds good to me.
> 
> Sounds good to me, too. I'm just somewhat confused what this means
> in terms of a decision. If MVP is a vague term - what exactly needs
> mockups *now*?

Let's brainstorm some possible user stories that we want to make
available. Once we decide on a good batch, we can add them to Taiga to
track progress. I'll create a draft here. Let's just keep it in emails
until we feel like we have good ones. I am frustrated with dumping
things in Taiga first, where they become much harder to quickly modify
and iterate on than plain old text! So here are some pages and
stories:

PAGES

- Dashboard Page: control your pledges
- Stripe.js Page: add or modify payment info
- Project Page [Snowdrift]: learn about a project and its patrons
- Payment History Page: see where your money went

DASHBOARD PAGE

  (this page is only available to logged-in users)

  - A user has just finished verifying their account and is taken to
the Dashboard. They don't have any payment info registered yet,
and the page should make that clear.

  - A user wants to add their payment info. From the Dashboard there
is a link to the Stripe.js Page. The link provides sufficient
explanation that the Stripe.js Page uses proprietary Javascript
whose use is governed by Stripe's ToS.

  - A user wants to modify or delete their payment info. (Very similar
to "add their payment info"; maybe just treat the same?)

  - A user HAS submitted their payment info and wants to pledge to
Snowdrift from the Dashboard. They have adequate funds and all
that. They click a button and are immediately added to the crowd.
The page reloads and shows their new status and new statistics.

  - A patron goes to the Dashboard to see the current state of their
pledges.

  - A patron wants to leave a project's crowd. The Dashboard shows
them they can click on the project to be taken to the Project
Page, where those controls exist.

  - A user has verified payment info recorded in the system. On the
Dashboard there is an friendly indicator that reminds them they
are a viable patron.

STRIPE.JS PAGE

  (this page is only available to logged-in users)

  - A user has no payment info recorded. There is a form on the
Stripe.js Page where they can put in their credit card info. They
put in valid info, it is sent directly to Stripe, and they are
redirected to the Dashboard with a happy alert.

  - A user wants to delete or modify their existing payment info. The
Stripe.js Page provides controls to do so.

PROJECT PAGE [SNOWDRIFT]

  - A site visitor (not logged in) follows a link to the Project Page
in order to satisfy their curiosity about the sorts of projects
that are supported on the Snowdrift Platform. They can see
information about the project, a sales pitch for why the project
deserves support, and crowdmatching numbers that highlight how the
visitor's own potential pledge would effect the mechanism.

  - A user (logged in, verified payment info, unpledged) follows a
link to the Project Page, for all the reasons listed above. As a
potential patron, however, they can choose to join the crowd by
clicking a button. The page reloads with updated numbers.

  - ...


...

Ok that's already a lot, enough for now. I'll leave the history pages
(and the rest of the Project Page) for later. I think the "take my
money" milestone potentially only needs the first two pages.


signature.asc
Description: 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

[Bryan Richter]

On Wed, Aug 31, 2016 at 09:32:12AM -0600, Michael Siepmann wrote:
>  
> On 08/31/2016 05:57 AM, Bryan Richter wrote:
> >
> > There are three classes of information:
> >
> > 1. Current pledge information
> > 2. Historic payment information
> > 3. Historic pledge information
> >
> > These forms of information should be made available as separate
> > pages, with the given ordering being used as implementation
> > priority.
>
> This approach sounds fine to me from a prioritization perspective.
> However, as soon as we're aiming to support more than a small number
> of "insider" users, I think we will need an effective explanation
> of *why* the historic payments were what they were, which means
> showing how historic payment information relates to historic pledge
> information, including edge case complexities where a month's payment
> was not the same as that month's pledge total.

To be clear, I am saying that we should use both Robert's and Michael's
visions, but on separate pages. Robert's "Where did my money go?" is
payment history. If we allow a page to be JUST payment history, that
page can be as simple as we please. It can skip months and provide
opaque totals. It does not need to carefully explain each month's
pledge/crowdmatch activity. It has just one purpose.

With that out of the way, we can provide a more robust pledge history,
which is Michael's "effective explanation of *why* history payments
were what they were". Pledge history will *include* payment history.
But the user won't be forced to parse payment history out of pledge
history. Payment history information will be separately available in
unambiguous simplicity. This will allow that information to FACILITATE
the explanation of pledge history, rather than be dependent on it.

I agree with mray that we need a simple, clear, unambiguous description
of payment history, and I agree with Msiep that such information is not
sufficient for selling Snowdrift to the world at large — and the whole
is greater than the sum of its parts.


signature.asc
Description: 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

[Bryan Richter]

On Wed, Aug 31, 2016 at 11:06:31AM +0200, Robert Martinez (mray)
wrote:
> 
> On 29.08.2016 22:35, Aaron Wolf wrote:
> > 
> > I think two pages for "payment history" and "pledge history"
> > should be considered. They each solve separate questions: (A)
> > "where did my money go?" and (B) "How does this crowdmatch thing
> > work in terms of my place in it and the projects I support?" (i.e.
> > understand the system via reviewing your history as a patron).
> > Both do seem relevant to MVP. Combining them may make it harder
> > than designing to separately answer each question…
> > 
> 
> I don't think (B) would be relevant for MVP. We currently have at
> least *some* information that can shed light on that. At least
> enough for MVP.
> 

There doesn't seem to be any hope of reconciling "payment history" and
"pledge history" pages. Nor does there need to be. I think it's time
for a decision.

There are three classes of information:

1. Current pledge information
2. Historic payment information
3. Historic pledge information

These forms of information should be made available as separate pages,
with the given ordering being used as implementation priority.

"Current pledge information" will be available on the dashboard[1],
along with the controls to modify pledge status.

"Historic pledge information" will doubtless include aspects of
history *payment* information. That's contributed to the current
challenge: one *could* include *all* payment information within
historic pledge information. But I am explicitly deciding to call out
payment history into its own page.

"Historic payment information" will, in fact, be hardly more than a
list of credit card charges. mray's vision will be captured here. This
page is too simple and useful to leave hanging. We can add a payment
history page now, and it will be hardly affected when we add extra
features. Whether or not we have features like limits, rollover, or
suspended pledges will hardly affect the display of historic payment
information. Payment history is a pleasingly stable form of history.
Creating this page frees us to show historic pledge information in a
way most suited to engaging and explaining the mechanism.

P.S. Whether or not such-and-such a page is "MVP" has always been a
vague notion. What does "MVP" mean anymore? We already have an MVP
that we are iterating upon. Deciding when and to whom to advertise our
existence is the real question.

Right now we are focusing on the people who want to support Snowdrift
at any cost. They don't need any history information whatsoever. Next
comes payment history, since it's so simple and static. Finally comes
pledge history, as part of the neverending task of engaging and
illuminating the mechanism.

[1]: Current pledge information will be available in other places as
well, of course.


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

Re: [Snowdrift-design] Mockup of account history

[Bryan Richter]

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

There has been a lot of good discussion, and we're kind of in the
middle of it, but I would like to suggest we put it on pause
nonetheless. If at all possible, it would be good to finalize the
design for the project page and the dashboard (something we also seem
to be right in the middle of).

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

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


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

[Snowdrift-design] Pledging functionality first

[Bryan Richter]

On Wed, Aug 10, 2016 at 08:36:56AM -0700, Aaron Wolf wrote:
> On 08/10/2016 05:59 AM, Bryan Richter wrote:
> >>
> > 
> > Robert, I'm also curious how you think we should handle that
> > stupid edge case of "This month + Last month's carryover > Limit".
> > I wish we could just abolish that edge case somehow. Not sure it's
> > possible though.
> > 
> 
> I'd like to not get distracted too much since the whole limits and
> edge cases here are post-immediate-launch...

Oh, you're right. We *can* do away with the edge case. Somehow I
missed that connection.

But, we've only discussed that on the team@ list. For the edification
of everyone not on that list, here is what was proposed:

1. Don't let implementing spending limits get in the way of allowing
people to make donations.

In other words, prioritize the pledging functionality over the
spending limit functionality.


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

Re: [Snowdrift-design] Mockup of account history

[Bryan Richter]

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

I think this looks amazing. But I am easily wowed by nice graphics.
Looking forward to Michael's response. Robert, I'm also curious how
you think we should handle that stupid edge case of "This month + Last
month's carryover > Limit". I wish we could just abolish that edge
case somehow. Not sure it's possible though.


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

Re: [Snowdrift-design] Mockup of account history

[Bryan Richter]

On Tue, Aug 09, 2016 at 08:03:40PM -0400, Stephen Michel wrote:
> 
> Seems entirely reasonable. I propose not to worry about dropping
> pledges until post-launch.

I agree. I've added an issue so we track this for later:

https://tree.taiga.io/project/snowdrift/issue/460


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

Re: [Snowdrift-design] Mockup of account history

[Bryan Richter]

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

Truly, this question was discussed to death some time ago. :P Sadly I
don't recall what the outcome was.

Aaron, maybe you remember?


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

Re: [Snowdrift-design] Mockup of account history

[Bryan Richter]

On August 3, 2016 5:54:28 PM GMT+03:00, Aaron Wolf wrote:
>
> Yes, I'm just saying that post-MVP we want to make sure history
> emphasizes pride in being a long-term patron. The strict MVP could have
> no history. The nice-for-MVP history is just the minimum you describe
> that allows auditing ("okay you charged this and it went there, got
> it").

Yep, I accept Robert's position on this as well. So it really IS a story just 
about budgeting and where money has gone.

Someone should update the title and description of the US I created. :)
-- 
Sorry it's ugly, I sent it from my phone.
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Mockup of account history

[Bryan Richter]

On Wed, Aug 03, 2016 at 01:55:44AM +0200, Robert Martinez (mray) wrote:
> On 01.08.2016 23:30, Michael Siepmann wrote:
> > We discussed this in today's meeting.  Here's a revised mockup,
> > also attached in .ods format. This shows payment processing fees,
> > two successive months of carry-over, and an example where a pledge
> > was suspended:
> > 
> 
> Thanks for clarifying via the mockup. I think it can be simplified
> in several ways:
> 
> https://snowdrift.sylphs.net/prototypes/mray/#history_page
> 
> * a pledge value/month next to a total/month isn't necessary. It
> only matters what you actually paid that month. So I would only show
> one sum/month.

This is different from how all receipts and bills work, which show the
sum-of-goods subtotal, then any fees and taxes, then a final total. Do
we want to keep that just so it's more familiar?

> * items that did not contribute to a months spending can be omitted for
> clarity.

Hm. I guess we should ask, is the purpose of this page to show *just*
payment history? I don't think so. I think it is a history of
participation within the mechanism. In that case, omitting items that
don't contribute leads to a *lack* of clarity.

Also, our hope is that we will be able to sum up a patron's
contributions to all their projects, so they would only be hit by a
single payment charge. In that case, it is impossible to get charged
in April, but have other donations roll forward from April to May.
Either a patron contributes to *all* their projects in a month, or
they contribute to none of them.

So: whether there is one project, or many projects, there is only one
thing that matters: What do we show for a month where a patron is
pledged, and contributes, but is not charged?

> Suspended projects are not treated different as non-pledged and should
> not show up specially. Notifications can be used to communicate all details.

I think the same critique applies. If this page is to show a history
of participation, suspended projects need to show up.

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

+1.

FYI, I have created a US to track this story, and have pasted in the
mockups so far.

https://tree.taiga.io/project/snowdrift/us/454

I've named it according to my understanding that we are talking about
a history of participation rather than just a history of payments, but
please consider that point "open for discussion" still. :)


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

Re: [Snowdrift-design] [Snowdrift-discuss] Design framework meeting -- Wednesday 13 July, 18:00 UTC

[Bryan Richter]

On Mon, Jul 11, 2016 at 09:40:16PM +0300, Bryan Richter wrote:
> A few months ago, we were working on creating a usable framework for
> Haskellers and non-Haskellers alike to build the front end (html and
> css) for the website.
> 
> We're going to re-open that discussion this week. Feel free to join.

This meeting has moved to the following day (tomorrow).

New time and place:

July 14, 18:00 UTC, https://meet.jit.si/snowdrift

Sorry for posting this to two lists. It sounds like switching to
Discourse is going to make this sort of thing nicer in the near
future. :)


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

[Snowdrift-design] Design framework meeting -- Wednesday 13 July, 18:00 UTC

[Bryan Richter]

A few months ago, we were working on creating a usable framework for
Haskellers and non-Haskellers alike to build the front end (html and
css) for the website.

We're going to re-open that discussion this week. Feel free to join.


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

Re: [Snowdrift-design] "buffer"

[Bryan Richter]

On Fri, Jul 08, 2016 at 12:56:55AM +0200, Robert Martinez (mray) wrote:
> There has been lots of discussion around little details that indicate
> different kinds of "buffer".
> Aaron and I had a small video-chat session and agreed that for MVP we
> probably only need the most basic notifications. Extra information (e.g.
> color coding) might be beneficial to some people but are not relevant as
> a default feature in the near future.
> 
> more details here:
> https://tree.taiga.io/project/snowdrift/issue/394

Awesome, I'm glad this is getting squared away and tracked.


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

Re: [Snowdrift-design] Interaction design mockups

[Bryan Richter]

On Mon, Jun 27, 2016 at 01:48:30AM +0200, Robert Martinez (mray) wrote:
> These emails get very long, I wonder if discourse would handle that
> better...

On that note, I would like to point out that if you two don't
summarize these conversations, or designate someone else who should, I
don't think it will get done. :) Maybe on the wiki? Or straight into
Taiga?

Email: public discussion
Wiki: public summary of results
Taiga: public consolidation of projects, tasks, and activity

I've been reading along, but not hanging on every word. I won't
remember much of this discussion when it comes time to start
implementing your ideas.

Thanks!


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

Re: [Snowdrift-design] Interaction design mockups

[Bryan Richter]

On Tue, May 24, 2016 at 04:24:23PM -0600, Michael Siepmann wrote:
> On 05/24/2016 04:13 PM, Aaron Wolf wrote:
> > On 05/24/2016 02:47 PM, Michael Siepmann wrote:
> > 
> >
> >> I like "Please consider increasing your maximum".  On reflection, and
> >> after experimenting, I'm thinking perhaps that's all we need.  I've
> >> updated both versions of that dashboard with just that for now.
> >>
> > I realize now that we need to clarify another issue: what happens when
> > someone chooses *not* to increase their max but to drop a *different*
> > project than the one auto-suspended?
> >
> > Obviously, dropping the suspended one, everything just goes back to
> > normal. Also, if they increase their max, the suspended pledge is
> > auto-reinstated, right?
> >
> > If they drop  different project, then the suspended one would also be
> > reinstated once everything is below max, right? Assuming so, is this
> > obvious enough without explicitly clarifying? I think so. They can drop
> > a different project and the page will reload showing the new status, and
> > then they'll see nothing remains suspended.
>
> Yes, that all matches what I had in mind anyway.  I think and hope it
> will be obvious enough.  Of course if we find it's not obvious enough,
> we can address that in various ways, but I think starting with something
> simpler like this is better.

A note on process:

The behavior being discussed is an excellent basis for a user story. I
started trying to write one, but I realized I don't understand the
particulars well enough. Please review what I've written so far:
https://tree.taiga.io/project/snowdrift/us/384

The sooner we capture the particulars of stories like these in Taiga,
the more likely we are to avoid rehashing them in the future! :)


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

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

[Bryan Richter]

On Sat, May 21, 2016 at 03:46:25PM -0400, Stephen Michel wrote:
> On Sat, May 21, 2016 at 3:12 PM, cnnr_dh...@live.com wrote:
>
> >Count me in favor of budgeting so long as it's optional: if the
> >feature is sufficiently tucked away and not advertised (except
> >maybe a "what if I'm poor?" FAQ) it will only be used by those who
> >need it. And for everyone else, we should consider a passive
> >version of this, where you receive alerts rather than a hard cap -
> >so for example, you get an email like:
> >
> >"hey, you asked us to let you know when your monthly payment
> >increases by more than [some configurable amount], and this month
> >it will be $XX more. If that's cool with you, simply ignore this
> >email. Otherwise, log in now/click here to change your
> >contributions."
> >
> >You'd get this email a bit before the payment so you have plenty
> >of time to act, and that should certainly suffice to make many
> >people comfortable getting started, since we're used to this setup
> >with other things (subscription free trials, credit card payments,
> >etc). This is of course in addition to the option of a hard
> >budget. It might also help to add in a generated list of the
> >projects that caused much of the increase (in a positive light,
> >like "this +$5 will be used to match the increased support for
> >project xxx and xxx!").
> >
> >Speaking of hard caps, (and since I'm a fan of things continuing
> >to work when you haven't been online in a while,) the choosing of
> >projects to drop upon hitting a cap should be passive IMHO, not
> >active - rather than saying "hey you've hit a limit and we need
> >you to pick projects to drop now", imagine the live list of
> >supported projects being perpetually reorderable: as you go along
> >you always rearrange them such that when the limit is reached, the
> >projects at the bottom of the list get dropped (as needed) by
> >default and of course notifying the patron of what happened.
> >Again, this is so that things keep chugging along when the patron
> >is not around.
> 
> >Also: When the monthly payout goes *down*, it may prove rewarding
> >to encourage the patron with the budgeting option to sort of "roll
> >over" the difference towards future payouts.
> 
> Pretty much agreed with all of this. There are some implementation
> details to work out but we'll cross that bridge when we get past MVP
> :)

Yeah, lots of ideas to consider in here. Thanks! I'll make sure we
keep track of these suggestions.


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

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

[Bryan Richter]

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

On Thu, May 19, 2016 at 11:12:24PM -0400, Stephen Michel wrote:
> 
> I'm a user. I go to snowdrift.coop, log in, go somewhere (I'd assume
> dashboard, but I'm trying not to assume), and click on a button to
> add funds to my account (current balance: $0). I specify $50 and
> click 'next'. Now what happens? I presume I'm prompted to log in to
> Stripe. Am I also prompted to authorize $50 for snowdrift, or does
> that come later, or for individual transactions, or...?

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

Right now there are two likely stories. They are:

1. The Admiral

- User pledges to a project, and damn the torpedoes.
- If they're not logged in, they can log in, and/or create an account
- If they don't already have a managed account, it is set up
- If they don't have any funding limits set, they are asked to specify
  what maximum amount of money they want to donate per month.
- The become pledged to the project.
- ...
- Monthly, their pledge(s) are processed, and they donate an amount up
  to the limit they set.

2. The Spy

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

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


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

[Snowdrift-design] classes on container divs

[Bryan Richter]

As requested, if a page is under some heirarchy like how-it-works/flo,
they top level div will now have the following classes:



Of course, we don't have many heirarchical pages planned right now,
but...


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

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

[Bryan Richter]

On Tue, Feb 02, 2016 at 09:13:51AM -0800, Aaron Wolf wrote:
> 
> So, again, moving to Gitit would be ideal

FWIW I think we should try to avoid talking about implementation
details when deciding on design and vision questions. Tech is
important to design inasmuch as it sets the boundaries of possibility,
but actual tech decisions should only truly follow design decisions.



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

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

[Bryan Richter]

On Tue, Feb 02, 2016 at 02:36:19PM +, Michel, Stephen J. wrote:
> >- The top priority user story is someone coming to the site and
>   understanding what it is.
> >- Introductory material is still up for discussion -- making sure the
>   introduction is as effective as possible is (now and always) a very
>   high priority.
> 
> I'm currently working on *organizing* the material that's currently
> on the wiki. My work is currently local but if anyone's interested
> in helping out I can make it available online. I have some thoughts
> on how we should organize the material, but I'll wait on hashing
> them out; there are a couple unresolved questions on my mind.

This sounds great. Maybe to give yourself space to keep working, but
to not feel like you're keeping people "in the dark", want to plan to
give a report in X days? A week maybe?

> 
> Given some sources that suggest a wiki may actually discourage
> participation (because people feel they're not knowledgeable enough
> and are afraid to overwrite old content), I'm a fan of providing two
> ways to edit an informational page:
> 
> 1. Pull request to git.gnu.io, or wherever we end up permanently
>hosting our site code
> 2. A "suggest edits" button on each page which functions like a
>wiki-style edit button, but instead creates a pull request from
>their edits. That way even those unfamiliar with git can
>contribute and become involved.

I'll leave it to the design team for final decisions, but this sounds
pretty cool to me. I might suggest against creating literal pull
requests, though. That would require tossing all the html at the user.
In the short term, it might be better to let them have a textentry to
describe suggestions in free-form.



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

[Design] Some notes from today's meeting

[Bryan Richter]

While not technically the subject of the meeting, some discussion
about site design took place. Here's a summary:

- The top priority user story is someone coming to the site and
  understanding what it is.
- Introductory material is still up for discussion -- making sure the
  introduction is as effective as possible is (now and always) a very
  high priority.
- Should there be a wiki on the site?
- What form should that wiki take?
- mray's design opinion: we should not use wiki pages to display
  public info pages (for the general visitor community).
- yet, the wiki is primarily intended for stuff that's available to
  the general visitor community -- not as engaged as people who have
  created accounts, etc.


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

Re: [Design] seafile, our server, github

[Bryan Richter]

On Thu, Jan 28, 2016 at 12:18:32PM +0100, Robert Martinez (mray) wrote:
> We need to find a proper home for design related materials. Now.

Aha, I was not aware of the priority of this! Good to know.

> While software & maintenance are no problem bandwidth and storage
> persistence are.

Actually, the only real bottleneck is system administrator
person-hours. That doesn't affect your line of reasoning much,
however.

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

Personally, I am fine with this decision. *IF* we could find someone
to volunteer administrating an OwnCloud server, it would be a simple
task for me to set up access to an S3 bucket. Otherwise, you gotta do
what you gotta do.

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

We do have a few organizational accounts, but tbh I'm not sure what
they are, so I'll let this question stand.



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

Re: [Design] Getting intro messaging feedback at SCALE

[Bryan Richter]

This is great. I know it will make my time manning the booth more
enjoyable. :)

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





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



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

Re: [Design] Test e-mail: Please ignore

[Bryan Richter]

Things were definitely broken, and they're fixed now. Some delayed
messages may still trickle in over the next day or so, due to other
mail servers responding to our outage by delaying sending.

btw, in the future, anybody can email me or Salt directly to learn if
there are mail problems! We can inspect the logs and have an answer
right away. :)

On Fri, Jan 08, 2016 at 10:20:53AM -0600, Jason Harrer wrote:
> This is a test e-mail to test that the distribution list is working, as
> MSiep indicated it wasn't working for him.  Please ignore.  Thank you.
> 
> - Jason Harrer



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

Re: [Design] Process toward full specs for project page

[Bryan Richter]

On Tue, Jan 05, 2016 at 06:27:52PM -0800, Aaron Wolf wrote:
> I've now drafted all the core items for the needs of the page for each
> project here:
> 
> http://flurry.snowdrift.coop:2040/shared/3G5iuOrbvc-mPUJvIUsV0fSYD9MGzoU_W44wSa6cYn0

This is great!

Reading through it, I think an emphasis on focus will help clarify
objectives and also help figure out priorities. So let's talk about
the *purpose* of the page. Here's a brainstorm (also added to the
etherpad; feel free to edit there).

1. Provide an interface for pledging with confidence.
2. Provide space for a project to describe itself (name, contacts, ...).
3. Provide space for a project to *sell* itself (updates, goals, ...).

Too much? Or have I missed any?

I think it's fine to say that the prototype for SCALE might be
markedly different from future versions of the page. Let's figure out
the goals and then find the bare-minimum way of meeting them.



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

Re: [Design] shirt colors

[Bryan Richter]

On Tue, Jan 05, 2016 at 12:02:52PM -0800, Diana Connolly wrote:
> Jeez, I'm realizing I referred to a "light blue" a couple of emails back,
> which should have been "cool blue". Sorry for the confusion.
> 
> So much for a *final* email. Heh.

Heh, ok. To put all the information in one place again:

Recommendations:

1. Heather Gray with blue ink
2. White with blue ink

3. Cool Blue with white ink
4. Warm Gray with white ink

Do not link to the other colors.

Note that Cool Blue for ladies requires a small amount of extra time
and money.


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

Re: [Design] shirt colors

[Bryan Richter]

There seems to have been a major foulup in communication about shirt
colors.

Diana chose shirt colors and got consensus on those colors. Some of
the colors she chose are on backorder for ladies's sizes, but they're
still available. Then, those colors were scrapped entirely and
different ones were added to the newly-created /merchandise page. That
page also unhelpfully links to the entire available palette, which is
also contrary to the original plan (paradox of choice, dilution of
brand).

There were a few emails in this thread that were, unfortunately, too
long and unfocused for me to have time to read. Was it one of those
that discussed these changes?

Are we all satisfied with the current state of affairs?

I basically didn't want to think about this anymore, except now I'm
choosing a shirt color for myself and don't feel comfortable choosing
something that very few other people will ever wear.

On Sun, Dec 20, 2015 at 11:18:21AM +, William Hale (Salt) wrote:
> Would someone start a new thread with mock-ups of the final options?
> 
> Thanks!
> 
> On Fri, 18 Dec 2015 11:20:33 -0800
> Diana Connolly  wrote:
> 
> > Quite simply, all we need now is the final graphics in a form I can
> > hand off to Bluemill, and a choice of sizes and colors for at least
> > 24 shirts. Remember, shirt color changes cost nothing.
> > 
> > If people would like to start sending me their choices, I will
> > compile a list.
> > 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design


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

Re: [Design] business-cards

[Bryan Richter]

On Tue, Jan 05, 2016 at 12:45:02PM +0100, Robert Martinez (mray) wrote:
> What do we need on our business cards?
> 
> 
> our logo (long)
> our slogan (free the commons)
> Name
> Position
> e-mail (do we have @snowdrift.coop mails?!)
> phone number (?)
> other info (?)

Other things we could add:

PGP fingerprint
IRC nickname

I don't want to put too much on. Less would be better. Here would be
my priorities (for discussion):

Logo (long)
Name
Slogan
PGP fingerprint
Email
Position
IRC nick
(no phone)

Three other thoughts:

1. I would like to suggest we keep one side blank so it can be
used to write situation-specific info.

2. I like the idea of having blank cards (no personal information) so
that the occasional volunteer has something they can put their name
on. I was passing out cards that said "Aaron Wolf" at previous events.
:P

3. Rather than using a PGP fingerprint, I would almost rather list a
Keybase ID: https://keybase.io/chreekat. But probably not.


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

Re: [Design] shirt colors

[Bryan Richter]

On Fri, Dec 18, 2015 at 12:07:15PM -0800, Bryan Richter wrote:
> On Fri, Dec 18, 2015 at 11:47:17AM -0800, Diana Connolly wrote:
> > And here's a wild idea -- the "kelly green" is very compatible
> > with your website colors too, and available for both men and
> > women. I would say that is a "cool" green, and I personally don't
> > like it, but it would look great with the white ink. :)
> 
> Might as well throw it in the list of options then, since it does
> look good and doesn't change any logistics.
> 

Actually, I take that back. Maybe let's just restrict to the top three
(light grey, warm grey, cool blue) in order to minimize the "paralysis
of choice" problem, not to mention the "brand dilution" problem.


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

Re: [Design] shirt colors

[Bryan Richter]

On Fri, Dec 18, 2015 at 11:47:17AM -0800, Diana Connolly wrote:
> And here's a wild idea -- the "kelly green" is very compatible with
> your website colors too, and available for both men and women. I
> would say that is a "cool" green, and I personally don't like it,
> but it would look great with the white ink. :)

Might as well throw it in the list of options then, since it does look
good and doesn't change any logistics.



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

Re: [Design] shirt colors

[Bryan Richter]

On Fri, Dec 18, 2015 at 10:53:22AM -0800, Diana Connolly wrote:
> Problem with that suggestion is that "light gray" is not available in
> women's shirts. I just realized myself that the women's shirt palette is
> quite different than the men's. So the closest thing is the "heather gray"
> for women, which in my humble opinion is just fine for the "cool" shirt.

Cool, good decision.



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

Re: [Design] shirt colors

[Bryan Richter]

On Fri, Dec 18, 2015 at 10:20:30AM -0800, Diana Connolly wrote:
> Just talked to April, she's emailing me some final prices, based on
> a minimum of 24 shirts. With that minimum, you get a free color
> change.
> 
> About the color that shows up when you click on the site for men's
> colors:

We chose not to use this color, after all. The core two colors we want
are in mray's mockup image entitled "shirts-diana.png", which are in
turn directly from your suggestions.

1. Light grey with dark blue ink (though I am unsure what "dark blue" is, 
precisely)
2. Warm grey with white ink

http://i.imgur.com/voPieR3.png

That is, heather gray is not used at all.

The third option, should we take it, would be a dark blue with white
ink. Whether the dark blue should be "cool blue" or "midnight navy"
seems like something worth discussing, but I think we should just go
for the first two shirts for now (leaving more discussion for a later
time).



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

Re: [Design] shirt colors

[Bryan Richter]

On Fri, Dec 11, 2015 at 07:46:34PM +0100, mray wrote:
>
> Leaving aesthetics apart – the warm colors don't feel snowdrift-ish
> enough for me.

Ahhh now we get to the root of the matter. :)

I have to wear warm colors. Cool colors do not suit me at all. My
original wish, which kicked off this hunt for colors, was to have at
least two types of shirt, one a cool palette and one a warm palette,
to suit the largest number of people. I understand the concern with
matching the website's theme, but I was hoping we could find a
complementary palette that suited another sort of skin tones.

> 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

I also like those ones. :)



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

Re: [Design] /Project page "ready"

[Bryan Richter]

On Sun, Dec 06, 2015 at 01:15:21AM +0100, 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

Cool. Until I finish my current work (hopefully today), we're blocked
on merging this.

For everyone's info, there's going to be a herculean amount of work in
the next couple days in order to launch the new design off the boat
ramp, but once it's in the water it should be a lot easier to move
around. If it feels like things are stuck right now, they are. Another
couple days is all it should take.


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

Re: [Design] /Project page "ready"

[Bryan Richter]

On Sun, Dec 06, 2015 at 06:36:23PM -0800, Aaron Wolf wrote:
>
> On 12/06/2015 03:33 PM, mray wrote:
>>
>> On 06.12.2015 22:12, Aaron Wolf wrote:
>>>
>>> A mild side-note: it seems semantically wrong to call the top section
>>> of the project page an . The pledge button and stats and
>>> screen shot are definitely not an article. That needs to be changed.
>>> An  is like a blog post, it is specifically for actual
>>> content that could be stripped out and printed as a piece of writing,
>>> an article…
>>>
>>
>> I don't think this is neither the time to change the design, nor the
>> time for any kind of side notes. The design does have issues in my eyes,
>> too. Let us talk about those after there is an actual page to talk about.
>>
>
> I'm not going to insist and will defer to some degree to others and
> their opinions about workflow, but I dislike the idea that we ignore
> apparent issues. The idea of fast iteration and agile development is,
> well, superior I think, to strict waterfall style work. Effectively, the
> idea that we absolutely complete a stage before it moves to the next
> stage where other sorts of issues can be addressed is, I think, an old
> fashioned and inefficient way to work.

Aaron, it seems like you are arguing against yourself here. There are
indeed imperfect elements, but that's ok. We'll iterate and fix them
next time.

If we stop and hash out every detail about mray's html right now, that
would definitely not be agile.

Waterfall is slightly different; we wouldn't be waterfalling even if
we *did* hash out all the html questions. But still.

> Now, it's perfectly fine to say "okay, that concern is noted, but I
> think that particular concern should wait until X and Y are done before
> we tackle it". I'm not against focusing or having an order to things at
> all. I just think there's risk of a lot of excessive work being done if
> we close off mentioning various issues and concerns until some point.

The alternative risk is spending a lot of time getting every little
thing correct, only to realize it will all be thrown away. Being agile
is about going all the way through the process, shipping real code, on
short timescales. It is not about being flexible with requirements;
that follows naturally. It is not about getting every detail right up
front; that is anathema.

>> Concerning the breadcrumbs in particular: I don't think there is an
>> alternative to having one hierarchy - that is the nature of them.
>>
>
> Yes, there must be specifically a clear single-path tree-style hierarchy
> for the breadcrumbs. But the breadcrumbs should not include the project
> categories, because those should be tags and not part of the hierarchy.

I agree here. It seems like projects would basically be a top-level
item for breadcrumbs.


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

Re: [Design] shirt colors

[Bryan Richter]

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

As mentioned in IRC, I've enlisted my mother (Diana Connolly) to help
with colors. She's joined this list and should chime in momentarily.
:)


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

Re: [Design] shirt colors

[Bryan Richter]

Well, after saying that, I *do* prefer white over some shades of gray.

No terrible cultural reference intended.

From my perspective, I'd like to offer at least two colors (maybe
neutral and blue?), if not more.

Robert, I suppose I'm not certain about your style guide. Is that
*just* a guide for the web? E.g. would it be a bad idea to use a
monochrome logo on top of a selection of colors better suited to
humans that to websites?

On Tue, Dec 01, 2015 at 12:46:12PM -0800, Aaron Wolf wrote:
> Question was brought up about shirt color. Many people dislike truly
> bright white shirts. We need to determine the options depending on what
> vendor we end up with, but it seems a greyish light color could work
> instead of white.
> 
> I think a lot of people don't really want to wear white t-shirts, I
> think. Bryan says so for himself.
> 
> Besides off-white, should we consider a design with a dark color?
> 
> See the color scheme options at
> https://snowdrift.coop/p/snowdrift/w/en/design-guide
> 
> So, thoughts?
> 
> -- 
> Aaron Wolf Snowdrift.coop 
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design


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

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

[Bryan Richter]

Hi Nico,

On Fri, Nov 27, 2015 at 12:26:42AM +0100, Nico Rikken wrote:
> Hello Snowdrift Designers,
> 
> I've been lurking this mailinglist for a while now, and having seen this
> project become a reality, I'd like to hint it at my presentation this
> weekend. It'll be at T-Dose, a Dutch FOSS conference, in which I'll
> focus on next steps in open source ecosystem. Presentation is to be
> shared afterwards using CC BY-SA 4.0 license.
> 
> Can I use a crop of one of the new designs to highlight your work and
> illustrate the funding concept?

Yes! I may not technically be the right person to ask, but as it's a
busy holiday here in the US I want to make sure you get an answer
promptly. Since our stuff is also freely-licensed (of course) you
could have used it anyway, but it's nice to hear about where and how
you're using it.

It looks like a very interesting presentation!


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

Re: [Design] big logo sticker with small URL?

[Bryan Richter]

On Wed, Nov 18, 2015 at 05:17:54PM -0800, Aaron Wolf wrote:
> After reading about this and thinking about further, I was thinking
> that while I'd *never* want this on a website somewhere, it could be
> good to have a S logo with small snowdrift.coop, like I'm attaching
> here.

I wouldn't mind that, if it looks good to everyone else. I prefer
graphical stickers over textual stickers, but having the name
somewhere would probably be good.

> And along that line, I do think eventually (maybe not immediately)
> that a Eunice with shovel or something *could* be a great sticker.

I think that's a good possibility as well. :)



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

Re: [Design] What to call a snowdrift patron

[Bryan Richter]

On Thu, Nov 05, 2015 at 09:34:06PM +0100, mray wrote:
> 
> 
> I'm also not a fan of either "patron" or "co-patron". It seems to be
> "taken" from the other project a bit. My main remaining concern is
> the indication of the special nature of what we offer. I'm only
> aware of words that convey the idea of a one-way ticket. But giving
> clues about how being a snowdrift.coop user is different seems
> valuable.

'Patron' has wide recognition as an English word. There is no
confusion with Patreon in practice. Relatedly, people still use
"windows" to mean "windows" and there is no confusion. Patron is much
too generic to have any concerns about it "belonging" to Patreon. They
could wish!

I agree that Snowdrift patrons are doing something tangibly different
than patrons through other systems, but I don't think it's a
dealbreaker. In fact, I'd rather be a positive influence on changing
what it means to be a patron, by referring to Snowdrift patrons as
"patrons".

I prefer:

"I'm a patron on Snowdrift.coop, where we match each other's
donations."

over:

"I'm a [whatsit] on Snowdrift.coop, where [whatsits] are patrons
who match each other's donations."

Incidentally, I do like the term co-patrons when it is used to refer
to the other patrons that mutually support each other. "You and five
hundred co-patrons are raising 250 bucks a month for this project."
But I would not call one person a "co-patron".


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

Re: [Design] What to call a snowdrift patron

[Bryan Richter]

On Tue, Nov 03, 2015 at 10:08:07AM +0100, mray wrote:
> 
> On 02.11.2015 03:32, Aaron Wolf wrote:
> > 
> > [Do] you have a real problem with the word "patron"? We went
> > around discussing this a long while back and felt that term was
> > the clearest, despite no term being perfect.
> 
> No, I don' hold a specific grudge about that word. I do have my
> issues with finding a name for what we need to describe. I also
> think we lack catchy terminology in general. Like "flattr a thing"
> can easily be used in any context. Would be gread if we had a
> "snowdrift a project" equivalent that made sense and was catchy.
> 
> Similarly Donor, Patron and Supporter all fall short of what we
> need. First: we need something that can be used consistently in any
> context. Second: all those terms suggest roles that totally miss our
> network effect angle, and in general any tie to our system
> specifically.

To summarize, patron is the best we have, but something else might be
better. Patron can certainly be used in any context; whatever else a
"snowdrifter" is, they will always be a patron, too. But it might be
an added bonus to make up a word to fit the description, "a patron who
matches the contributions of all other patrons, and who is matched by
them".

(A web and spiders comes to mind, though I doubt that's what we want.)

I think we should either stick with patron and use it consistently, or
hash out a better word now.



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

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

[Bryan Richter]

On Mon, Nov 02, 2015 at 10:09:09AM +0100, mray wrote:
> 
> On 02.11.2015 03:07, Stephen Michel wrote:
> 
> > On mobile, it's not clear what I'd click to sign IN (not up).
> > 
> 
> My assumtion is that maybe we can make that button depend on whether
> the user has logged in from that device already. But I see how this
> is problematic for first time users - I really want to keep the
> number of buttons low. Maybe we should combine both processes into
> one screen and call it "SignUP /SignIN"?
> 
> Any thoughts?

That seems like a common and usable pattern.

Overall I'm super impressed and excited with this redesign!


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

Re: [Design] project page

[Bryan Richter]

On Sun, Oct 18, 2015 at 09:43:26PM +0200, mray wrote:
> 
> On 18.10.2015 21:18, Aaron Wolf wrote:
> > 
> > We want people to think is "I get the project $15 more dollars, and I
> > only had to chip in $6! Thanks everyone, all you 2,470 others! I'm so
> > glad we're all working together to support this!"
> 
> I don't think we want that at all. This makes it sound as if this is a
> big bragain.

Then I think the message should be more clear.

First off, it's crucial that people realize "When I give the project 6
bucks, it actually receives 15 since other people match me." That is
THE Snowdrift model. :) Matching-funds is one of the crucial
differentating features of Snowdrift, so if people don't like it, they
won't like Snowdrift. And if they DO like it — which they should — we
should highlight it so they understand it's what we do. We should be
proud of it.

> This fallacious good feeling is entirely based on the naive
> idea that you will never be asked to give more yourself - maybe way
> beyond $15 dollar.

Isn't it two different things to say, "Your funds will be matched by
others," and, "Your donation won't change over time?" We can easily
say the first one without making false claims about the second.


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

Re: [Design] discussion/ticket system mockups v2

[Bryan Richter]

On Sun, Oct 18, 2015 at 10:54:42PM +0200, mray wrote:
> Hello everybody,
> 
> Here is the latest update containing almost all usecases.
> If you spot an important one that is missing please yell.
> 
> https://img.bi/#/EmlGj9w!lqKWarmnbDsBk2-GzCKqtQs2fNuUuY6jNIr6AZlP
> 
> Feedback is greatly appreciated again

Hi! One thing that would help me a lot is a much stronger visual cue
that a ticket is in a state other than 'open'. Or wait, is #37 open or
closed? I can't tell. :P


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

Re: [Design] discussion/ticket system mockups

[Bryan Richter]

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

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

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

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.


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

Re: [Design] Homepage illustration

[Bryan Richter]

It's been very hard for me to follow this thread because of poor
quoting technique. Email takes work, I know, but it benefits all of us
to make the effort.

I've been able to catch the gist that some people want *more*
illustration on the front page, and other people do not. I lean
towards less illustration. More illustration means less flexibility
for different screen sizes. It becomes less consistent with other
pages, which presumably won't have the same illustration over and over
again. The top of the page should be more like a letterhead.


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

Re: [Design] Illustrations - What is it we want?

[Bryan Richter]

On Sat, Sep 05, 2015 at 05:23:49PM -0700, Aaron Wolf wrote:
> 
> On 09/05/2015 10:12 AM, mray wrote:
> > Illustrations are fine and Ikos sketches look great, but we need to have
> > a better focus on what illustrations convey. The current "Intro"
> > as seen here https://snowdrift.coop/p/snowdrift/w/en/intro isn't an
> > intro to snowdrift.coop, it is more a vision mixed with explanations of
> > principles. And it is too long.
> >
> For reference, we discussed this substantially on IRC and basically all
> involved agree with Robert's views here and will move forward with that.
> Here's an excerpt of chat for those curious: http://paste.rel4tion.org/50
> 
> The mockup for new intro is:
> https://raw.githubusercontent.com/mray/Snowdrift-Design/master/mray%20website%20mockups%20/export26/7-intro.png

I have no particular comments, but I like where this is going!


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

Re: [Design] photo from Aaron's presentation at OSBridge

[Bryan Richter]

On Fri, Jul 10, 2015 at 11:57:53AM +0200, mray wrote:
> Oh, and one reason for the version I settled is because the
> self-similarity of the S remains completely intact.
> 
> Otherwise I also think it is among the combinations that work best.
> 

It took me a while to figure out what you guys were talking about,
"hard edged" vs. "organic". :)

I like mray's latest. +1.


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

[Design] photo from Aaron's presentation at OSBridge

[Bryan Richter]

http://i.imgur.com/8mLK9hJ.jpg

I wanted to say that seeing this logo up on a screen in front of
people totally sold me. I love it. I don't know why. It just looks
great.

Aaron, sorry you're in shadow, but it was very bright outside. :P


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

Re: [Design] Logo issues, a first impression report

[Bryan Richter]

> I am ready to agree on my part to consensus around the newest logo. I
> just want a blog post and outreach to others so we get wider
> perspectives before we go ahead with finalizing.

After listening in on this conversation, I am also much happier with
the latest logo. Let's take those next steps to determine consensus.


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