Re: [Snowdrift-design] Mockup of account history
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
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 http://snowdrift.sylphs.ne
Re: [Snowdrift-design] Mockup of account history
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
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 d
Re: [Snowdrift-design] Mockup of account history
On Wed, Aug 10, 2016 at 4:52 PM, Aaron Wolf wrote: 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. I think it is less rare than you think. It happens often if someone's limit is not much higher than the minimum payment. Right now min-payment is ~$3.66. I plan on setting my max at $5, initially. So this will happen quite a bit if/when the pledge value is between $2.50 and $3.66. ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Snowdrift-design] Mockup of account history
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
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
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 to
Re: [Snowdrift-design] Mockup of account history
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
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
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
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
On Wed, Aug 10, 2016 at 8:59 AM, Bryan Richter wrote: I think this looks amazing. But I am easily wowed by nice graphics. For this reason, it is a best practice to use sketches or other things that are not so pretty at this stage of development. If that would get in the way of actually iterating, though, please continue to iterate instead. ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Snowdrift-design] Mockup of account history
On 08/10/2016 05:59 AM, Bryan Richter wrote: > On Wed, Aug 10, 2016 at 12:35:03PM +0200, Robert Martinez (mray) > wrote: >> >> >> On 08.08.2016 19:55, Michael Siepmann wrote: >>> Here's a revised mockup without the pledge subtotal and showing >>> both the "too low" and "too high" reasons for carryover. In this >>> example, the user increased their limit in July. There are other >>> changes also, such as noting what the limit was on the charge >>> line. I'm also atttaching the .ODS file. >>> >> >> >> I think there need to be two distinct representations of your >> activity on snowdrift. >> >> 1. A *complete* log of all activity, including details as date and >> time when any project pledge button was used to pledge/unpledge, >> date and time when your payment processor got set up correctly, when >> you money actually got transferred, ... just *lots* of details. >> >> 2. An overview of what just happened, reassuring that things are >> going as you expect them to go, and that you understood the >> crowdmatching mechanism and that YOU are in control. >> >> Assuming that both views are needed my approach is to visually >> support each accordingly. Your mockup seems closer to a >> representation as in "1." But I'd like to have a very simple and >> intuitive view in MVP that mainly addresses the understanding of the >> mechanism rather than controlling its accuracy. Of course we need >> both to live up to our proclaimed goals of transparency. My >> rationale to go for "2." is that we are on a journey to approach >> people and earn enough trust so that they give up control and hand >> it over to our mechanism. Having good intentions(tm) and having >> simple rules like: "Never over limit!" & "Always under 10% fees!" is >> a good start. But we also need to create an experience of being the >> driving force in that mechanism, and my impression is that >> representation "2." supports that better than "1." >> >> >> Michael, do you agree a distinction of "1." and "2." makes sense? >> >> >> My premise to a representation of "2." is: >> >>--- "What did I pay last months - and why?" --- >> >> This question needs to be answered as simple and clear as possible. >> Once we start explaining more we'll have a hard time to stay simple >> and justifying not to go into even more detail. >> >> >> So looking at your mockup this goes through my mind: >> * Why does paying $0 have to look as complex? >> * Why are numbers of patrons so prominent? >> * Why list projects that got no money from me? >> * Why is the day of the month of transaction important? >> >> >> My attached mockup addresses those issues by >> * simplifying $0-months and making the carry-over visually obvious >> * moving patrons away from where you probably do some quick math >> * removing suspended projects >> * removing the date >> >> I do agree though, that having the respective limit for each month >> is necessary, so I added that bit of information. >> > > I think this looks amazing. But I am easily wowed by nice graphics. > Looking forward to Michael's response. Robert, I'm also curious how > you think we should handle that stupid edge case of "This month + Last > month's carryover > Limit". I wish we could just abolish that edge > case somehow. Not sure it's possible though. > I'd like to not get distracted too much since the whole limits and edge cases here are post-immediate-launch, but: I suggest the design for the edge case just say "carry-over from February - April" for a case where several months go by before the total is worth charging, and then the over-limit edge-case can be displayed as "remaining February - April carry-over not charged last month" or similar. I don't think it's too hard to make this clear. 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
On Wed, Aug 10, 2016 at 12:35:03PM +0200, Robert Martinez (mray) wrote: > > > On 08.08.2016 19:55, Michael Siepmann wrote: > > Here's a revised mockup without the pledge subtotal and showing > > both the "too low" and "too high" reasons for carryover. In this > > example, the user increased their limit in July. There are other > > changes also, such as noting what the limit was on the charge > > line. I'm also atttaching the .ODS file. > > > > > I think there need to be two distinct representations of your > activity on snowdrift. > > 1. A *complete* log of all activity, including details as date and > time when any project pledge button was used to pledge/unpledge, > date and time when your payment processor got set up correctly, when > you money actually got transferred, ... just *lots* of details. > > 2. An overview of what just happened, reassuring that things are > going as you expect them to go, and that you understood the > crowdmatching mechanism and that YOU are in control. > > Assuming that both views are needed my approach is to visually > support each accordingly. Your mockup seems closer to a > representation as in "1." But I'd like to have a very simple and > intuitive view in MVP that mainly addresses the understanding of the > mechanism rather than controlling its accuracy. Of course we need > both to live up to our proclaimed goals of transparency. My > rationale to go for "2." is that we are on a journey to approach > people and earn enough trust so that they give up control and hand > it over to our mechanism. Having good intentions(tm) and having > simple rules like: "Never over limit!" & "Always under 10% fees!" is > a good start. But we also need to create an experience of being the > driving force in that mechanism, and my impression is that > representation "2." supports that better than "1." > > > Michael, do you agree a distinction of "1." and "2." makes sense? > > > My premise to a representation of "2." is: > >--- "What did I pay last months - and why?" --- > > This question needs to be answered as simple and clear as possible. > Once we start explaining more we'll have a hard time to stay simple > and justifying not to go into even more detail. > > > So looking at your mockup this goes through my mind: > * Why does paying $0 have to look as complex? > * Why are numbers of patrons so prominent? > * Why list projects that got no money from me? > * Why is the day of the month of transaction important? > > > My attached mockup addresses those issues by > * simplifying $0-months and making the carry-over visually obvious > * moving patrons away from where you probably do some quick math > * removing suspended projects > * removing the date > > I do agree though, that having the respective limit for each month > is necessary, so I added that bit of information. > I think this looks amazing. But I am easily wowed by nice graphics. Looking forward to Michael's response. Robert, I'm also curious how you think we should handle that stupid edge case of "This month + Last month's carryover > Limit". I wish we could just abolish that edge case somehow. Not sure it's possible though. signature.asc Description: Digital signature ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Snowdrift-design] Mockup of account history
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
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