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.

[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

[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