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

[Michael Siepmann]

 
On 08/13/2016 08:13 PM, Stephen Michel wrote:
> 
>
> On August 13, 2016 12:18:48 PM EDT, Michael Siepmann 
>  wrote:
>> Great idea, incorporated into
>> http://snowdrift.sylphs.net/f/a87dd65116/?raw=1
>>
>> Not shown in the mockup is what it would say in the simpler case where
>> the full amount is paid off at once, for which I'd suggest:
>>
>> "Amount postponed from March-April 2016"
> Also, the parenthetical amount of money postponed is no longer necessary, and 
> the words explaining that it was postponed can be moved elsewhere. The $0.00 
> could also be removed (or replaced with "postponed"), though there's 
> arguments why we should keep it as well.

I think we should keep it as it is, for two reasons: (a) it's good to
consistently have the number at the bottom be both (i) the amount
actually charged and (ii) the sum of the numbers above it, and (b) when
there are multiple pledges the number in parentheses will show the sum
of them, so when in a later month you see either "Part of $2.80
postponed..." or "Amount postponed...  $2.80" you can easily match that
up to the ($2.80) it corresponds to.

 



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

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

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

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

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

or alternately:

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

Or something of that nature.

The features are:

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

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

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

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

Just ideas to consider



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

Re: [Snowdrift-design] Mockup of account history

[Michael Siepmann]

  On 08/12/2016 04:08 PM, Michael Siepmann wrote:

> On 08/12/2016 03:59 PM, Michael Siepmann wrote:
>> 
>
> Here's what I had in mind, from the "How the limit works" thread:
>
> On 08/03/2016 06:34 PM, Aaron Wolf wrote:
>> On 08/03/2016 05:19 PM, Aaron Wolf wrote:
>>> Whenever there needs to be a carry-over, we use the difference
>>> between a month's charges and any outstanding carry-over from
>>> previous to reach up to the max, and thus widdle-away the carry-over >
>> over multiple months if need be.
>>
>> Error in my wording: I meant "the difference between the max and the
>> current month's charges as the amount of any carry-over that is
>> available to be charged in a given month"
>>
>
> That's what I intended to depict, but I see that how June 2016 doesn't
> do that correctly and instead depicts a situation that shouldn't ever
> exist.  Thanks for catching it, Stephen.  The "widdle-away" approach
> means we *can* carry over to the next month to avoid exceeding the
> limit, but only from any amount carried over to this month from the
> previous month.  I'll update it to depict that scenario.

How about this?:

http://snowdrift.sylphs.net/f/83aacffd4f/?raw=1

I've tried new wording to try to make it clearer, and updated the
numbers to show a realistic "widdle-away" scenario for a couple of
months.  Fortunately most of the time this complex a scenario won't arise.


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

[Michael Siepmann]

On 08/12/2016 03:32 PM, Aaron Wolf wrote:
> On 08/12/2016 02:28 PM, Stephen Michel wrote:
>> On Fri, Aug 12, 2016 at 5:22 PM, Aaron Wolf  wrote:
>>> On 08/12/2016 01:58 PM, Michael Siepmann wrote:
  Here's a rough-around-the-edges modification of mray's mockup with the
  kind of information and structure I'm arguing for:

  http://snowdrift.sylphs.net/f/7949e02830/?raw=1

>>> My biggest concern is "carried over from last month" could give the
>>> impression that we *do* charge more than the limit for a month, like if
>>> the limit is $10 and the crowdmatching gets to $12, we carry over $2 to
>>> the next month. Of course, that's not what we're proposing. But I think
>>> it needs to be clear that the carry over is only from charges too small
>>> to be worth it given fees.
>>>
>>> I'm not sure how to make that clear, but the point is that the
>>> carry-over is only ever funds that could have been charged earlier but
>>> we delayed them to minimize fees.
>>>
>>> The "to next month" parts get this, but the first thing I saw was "from
>>> last month" and there it wasn't clear.
>> In June of the mockup, it shows a scenario where $pledge + $fees >
>> $limit. This would allow someone to accrue a running balance that will
>> never be paid off, and violates our "no more than $limit per month"
>> rule. I don't think that should ever happen; in that scenario the pledge
>> should become suspended.
>>
>> However, that is not related to how we present the information on this
>> page.
>>
> Absolutely, and Stephen's point aligns with mine. The only thing that
> should ever be carried over is charges that came from a month that was
> too low to be worth charging. We should never carry over fees. The total
> of pledges *plus* fee has to be under the limit for a given month to
> keep the pledge active.
>

I think something is getting lost here.  I'll try to find it in previous
emails but we have definitely discussed a scenario where we need to
carry over to the next month in order to gradually get rid of carry over
from previous months, which would initially have exceeded the limit. 
Let me see if I can find what I'm referring to...



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

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

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

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

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

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

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

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

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

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

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



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

Re: [Snowdrift-design] Mockup of account history

[Stephen Michel]

On Wed, Aug 10, 2016 at 7:01 PM, Stephen Michel 
 wrote:

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

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


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



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


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


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


Longer:

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


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



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


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


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


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

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



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


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

Re: [Snowdrift-design] Mockup of account history

[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 attempt to use layout. Using it in the form you do is a clear
>> commitment to solve problems on a typographical layer and relies heavily
>> on having to closely read all text.
> 
> I don't think what I'm advocating has any dependence on a table layout. 
> I would like to make a version of yours to illustrate what I mean.  Can
> you point me to the source file?
> 

It is under 

Re: [Snowdrift-design] Mockup of account history

[Stephen Michel]

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


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

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

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

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


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


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


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

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


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

Re: [Snowdrift-design] Mockup of account history

[Michael Siepmann]

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. 


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

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

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 attempt to use layout. Using it in the form you do is a clear
> commitment to solve problems on a typographical layer and relies heavily
> on having to closely read all text.

I don't think what I'm advocating has any dependence on a table layout. 
I would like to make a version of yours to illustrate what I mean.  Can
you point me to the source file?

> I don't even like the idea of having "suspended" projects as the choice
> of support is binary and all projects are either supported or not.

It's not binary. There are three states: Not supported, Suspended, and
Supported.  You may prefer to treat "suspended" as the same as "not
supported", but I, and I'm sure many other users, find the distinction
meaningful and important, and would appreciate having their history
respect the distinction.


>
> Breaking it down to the purpose of that information this would be a
> clear candidate for the more detailed view of things. Nothing – in terms
> of understanding the mechanism and how it did work – requires you to
> know the exact date of when we accessed your account.

Again I think we need to allow for a wider range of what different users
may be interested in.  I for one would find it very odd to be told I was
charged a certain amount in that month but not told on what date I was
charged it.


Now, to avoid two separate emails, I'll include a response to Aaron's
response:


On 08/10/2016 03:21 PM, Aaron Wolf wrote:
> Lots of snip…
>
>> My point is that having "proper" entries inside a "$0-month is
>> unintuitive.
> I don't find entries that add up to 0 unintiutive at all.
>
>> Not having to jump around months to make sense of the one
>> payment that *did* happen seems more intuitive.
> That I agree is intuitive.

It depends what you mean by "make sense" and what kind of jumping around
you're thinking about.  In the organization I proposed, you can "make
sense" of a given payment in the simple sense that you know how much, if
any, came from carry over from the previous month.  My version 

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

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

Lots of snip…

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

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

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

That I agree is intuitive.

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

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



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

Re: [Snowdrift-design] Mockup of account history

[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 month" messaging which keeps the carry over
> simpler.  It's going to get super complex if you end up having to
> represent carry over from multiple months in one month.  It will also
> make problem #1 above even worse where you could have, for example,
> three successive months in which all you're told on the history is that
> your spending got carried over - i.e. three panels like your May 2016
> one and nothing else.
> 

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.

The reason I find it hard 

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

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

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




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

Re: [Snowdrift-design] Mockup of account history

[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

[Michael Siepmann]

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.

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 month" messaging which keeps the carry over
simpler.  It's going to get super complex if you end up having to
represent carry over from multiple months in one month.  It will also
make problem #1 above even worse where you could have, for example,
three successive months in which all you're told on the history is that
your spending got carried over - i.e. three panels like your May 2016
one and nothing else.

>>>  * Why are numbers of patrons so prominent?

I think number of patrons is essential information but I really like how
you've represented it with the "people" icon.  As long as it has ALT
text and a tooltip on the patrons icon, I think it's great.

>>>  * Why list projects that got no money from me?

In the case of projects that were non suspended, you are listing them
too.  You've just moved them into June.  We're both showing what the
pledge value was in a month where no charge was made, but you're making
the user wait until the charge has happened to see that information and
displaying it in the month of the charge, whereas I'm displaying it in
the month it originates from.  For the two reasons I list above, I think
it's much simpler and better to do it the way I did it - though your
visual treatment and simplification of things like the patron count,
limit message, etc, is a vast improvement on my simple spreadsheet mockup.

In the case of suspended projects, I still think it's important to
include that information here.  It's an important part of "why" in "What
did I pay last months - and why?" - especially when looking back perhaps
several months where you might forget that one of your projects
temporarily got suspended.

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

[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

[Aaron Wolf]

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

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

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




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

Re: [Snowdrift-design] Mockup of account history

[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

[Michael Siepmann]

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





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

[Stephen Michel]

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

I agree with Michael here, but there is a limit. Imagine a user who pledges to 
many projects which are then suspended as they grow, but who is also lazy  and 
leaves the pledges suspended rather than dropping them. Their history could 
become bloated with (imo) useless information as the months run by.

I think the proper place to tackle this is: if a user has not reinstated a 
suspended pledge within 3 (?) months, it should be automatically dropped. 
Apologies if we've already had this conversation; I do remember talking about 
it but not this particular facet, and mobile makes it hard to go back and 
check. 

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

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

Re: [Snowdrift-design] Mockup of account history

[Michael Siepmann]

On 08/02/2016 05:55 PM, 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.

I think the pledge total was necessary when we were planning to have the
max/limit apply to that before payment processor fees and carry-overs,
but with the new approach discussed in the "How the limit works" thread,
I agree this subtotal is not necessary.

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

I strongly disagree with this. I think omitting this information creates
lack of clarity.  I think we should assume that users will rarely look
at the history, but that when they do, it's because they want to
understand where their money went (or didn't) and why.  That includes
knowing that it where it did *not* go that they might have expected it
to go, e.g. to a suspended project, and knowing why they were *not*
charged that month, i.e. because balance was carried over.

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

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



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

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

On 08/03/2016 04:24 AM, mray wrote:
> 
> 
> On 03.08.2016 12:52, Aaron Wolf wrote:
>> On 08/03/2016 01:31 AM, Bryan Richter wrote:
>>> On Wed, Aug 03, 2016 at 01:55:44AM +0200, Robert Martinez (mray) wrote:
 On 01.08.2016 23:30, Michael Siepmann wrote:
> We discussed this in today's meeting.  Here's a revised mockup,
> also attached in .ods format. This shows payment processing fees,
> two successive months of carry-over, and an example where a pledge
> was suspended:
>

 Thanks for clarifying via the mockup. I think it can be simplified
 in several ways:

 https://snowdrift.sylphs.net/prototypes/mray/#history_page

 * a pledge value/month next to a total/month isn't necessary. It
 only matters what you actually paid that month. So I would only show
 one sum/month.
>>>
>>> This is different from how all receipts and bills work, which show the
>>> sum-of-goods subtotal, then any fees and taxes, then a final total. Do
>>> we want to keep that just so it's more familiar?
>>>
 * items that did not contribute to a months spending can be omitted for
 clarity.
>>>
>>> Hm. I guess we should ask, is the purpose of this page to show *just*
>>> payment history? I don't think so. I think it is a history of
>>> participation within the mechanism. In that case, omitting items that
>>> don't contribute leads to a *lack* of clarity.
>>>
>>> Also, our hope is that we will be able to sum up a patron's
>>> contributions to all their projects, so they would only be hit by a
>>> single payment charge. In that case, it is impossible to get charged
>>> in April, but have other donations roll forward from April to May.
>>> Either a patron contributes to *all* their projects in a month, or
>>> they contribute to none of them.
>>>
>>> So: whether there is one project, or many projects, there is only one
>>> thing that matters: What do we show for a month where a patron is
>>> pledged, and contributes, but is not charged?
>>>
 Suspended projects are not treated different as non-pledged and should
 not show up specially. Notifications can be used to communicate all 
 details.
>>>
>>> I think the same critique applies. If this page is to show a history
>>> of participation, suspended projects need to show up.
>>>
 * I also like keeping the history tab consistent with the running months
 matching tab.
>>>
>>> +1.
>>>
>>> FYI, I have created a US to track this story, and have pasted in the
>>> mockups so far.
>>>
>>> https://tree.taiga.io/project/snowdrift/us/454
>>>
>>> I've named it according to my understanding that we are talking about
>>> a history of participation rather than just a history of payments, but
>>> please consider that point "open for discussion" still. :)
>>>
>>
>> Just to note: I agree with everything Bryan posted. The numbers should
>> be done in a way that's relatively standard. The purpose of the history
>> page is not just to focus on charges but to emphasize the amount of
>> support and the history of the matching.
> 
> What is the difference of "charges", "history of matching" and
> "emphasize the amount of support" in that context?
> To me they easily translate all to the same.
> 
> You seem to want some extra info that wouldn't be MVP.
> 

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

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



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

Re: [Snowdrift-design] Mockup of account history

[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. :)
> 
> 
> 
> ___
> 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

Re: [Snowdrift-design] Mockup of account history

[Aaron Wolf]

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

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

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




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

Re: [Snowdrift-design] Mockup of account history

[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] Mockup of account history

[Aaron Wolf]

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

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




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

Re: [Snowdrift-design] Mockup of account history

[Michael Siepmann]

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:

 



History mockup 2.ods
Description: application/vnd.oasis.opendocument.spreadsheet


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