Re: [Snowdrift-design] Mockup of account history
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 It's rough-around-the-edges because I have very little experience with Inkscape and could not easily figure out how to do certain things like adjust the length of the ellipses, enlarge the main white background, etc. However, hopefully it will still help facilitate our discussion. Now I'll also respond to some items from mray's and my converation about this mockup - selectively since I have quite limited bandwidth at the moment.. On 08/10/2016 06:30 PM, mray wrote: > > True. But presence of information does also not equal clarity. Very true! :-) > >> >> 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. The main dashboard view could, and probably should, show how much carryover from previous months this month has. However, it won't (or anyway shouldn't, in my view) try to show more details than that. It should really be focused on what your pledges are and how they relate to your limit. > > It is under http://snowdrift.sylphs.net/f/8abb7d5227/ but you can open > the seafile folder: > /mray/Website mockups/MVP/website_mvp_dashboard_history.svg > on your local machine to get the header and footer files right. Thanks! 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 Fri, Aug 12, 2016 at 4: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 It's rough-around-the-edges because I have very little experience with Inkscape and could not easily figure out how to do certain things like adjust the length of the ellipses, enlarge the main white background, etc. However, hopefully it will still help facilitate our discussion. In this view, the information in the most recent month seems to be identical to the information on the main dashboard page. If we end up using this view, I suggest that it need not be in a separate history tab. Add a "show more" button near the bottom of the page. If the user has JS enabled, we can dynamically load more months. If not, we still can have the same experience; it'll just require an additional page load. ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Snowdrift-design] Mockup of account history
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. 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 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. ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
Re: [Snowdrift-design] Mockup of account history
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. 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/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
On 08/12/2016 03:59 PM, Michael Siepmann wrote: > 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... 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. 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/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
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
On August 12, 2016 6:54:28 PM EDT, 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. I think that this scenario is really hard to parse. It could also result in a display where you have a carryover from may and a carryover from June displayed in July, and that gets really busy really quickly (especially if one or more are also carried over to august). I suggest that we aggregate all carryover charges. The small loss in detail is totally worth the simplicity, imo. Any charges that will roll over (the negatives) will always be the bottom item in the list, so it's fairly easy to eyeball the rest of the list and verify that it is below the limit. I'm tempted to put charges from a previous month below fees for that reason, as well, but that feels odd to me. -- 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
On 08/12/2016 06:58 PM, Stephen Michel wrote: > > > On August 12, 2016 6:54:28 PM EDT, 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. > > I think that this scenario is really hard to parse. It could also result in a > display where you have a carryover from may and a carryover from June > displayed in July, and that gets really busy really quickly (especially if > one or more are also carried over to august). > > I suggest that we aggregate all carryover charges. The small loss in detail > is totally worth the simplicity, imo. > Absolutely! Describing the carry-over from several months with separate list of carry-overs would be crazy. But the aggregated sum can be described as month-month e.g. "March-July carry-over". Effectively, most carry-overs will only happen at the early stage of projects and patrons, when they first start on the system. A new project with some new patrons may have a period of carry-overs, and then no more of that going forward. So, it's just this contiguous set of months that will have carry-overs in almost all cases. To cover all possible scenarios, we could just say "carry-over from earlier months with charges too low to be worth charging" effectively. In any case, it should be one sum number. > Any charges that will roll over (the negatives) will always be the bottom > item in the list, so it's fairly easy to eyeball the rest of the list and > verify that it is below the limit. I'm tempted to put charges from a previous > month below fees for that reason, as well, but that feels odd to me. > 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/12/2016 08:02 PM, Aaron Wolf wrote: > On 08/12/2016 06:58 PM, Stephen Michel wrote: >> >> >> >> I think that this scenario is really hard to parse. It could also result in >> a display where you have a carryover from may and a carryover from June >> displayed in July, and that gets really busy really quickly (especially if >> one or more are also carried over to august). >> >> I suggest that we aggregate all carryover charges. The small loss in detail >> is totally worth the simplicity, imo. >> > Absolutely! Describing the carry-over from several months with separate > list of carry-overs would be crazy. But the aggregated sum can be > described as month-month e.g. "March-July carry-over". Effectively, most > carry-overs will only happen at the early stage of projects and patrons, > when they first start on the system. A new project with some new patrons > may have a period of carry-overs, and then no more of that going > forward. So, it's just this contiguous set of months that will have > carry-overs in almost all cases. > > To cover all possible scenarios, we could just say "carry-over from > earlier months with charges too low to be worth charging" effectively. > > In any case, it should be one sum number. That's already what I intended: At most one carry over from the previous month and one carry over to the next month. I don't even think we should try to describe what multiple months it may originally come from (e.g. no attempt at "March-July carry-over" etc) because that will just get too complicated, particularly in the "widdle-away" scenario when part of a carry over is paid off in one month but part is carried over to the next month. It would probably be clearer to go back to referring to "next month" and "previous month" as I'd done previously, rather than naming the specific last and previous months as I tried in this latest version. 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/12/2016 08:04 PM, Michael Siepmann wrote: > On 08/12/2016 08:02 PM, Aaron Wolf wrote: >> On 08/12/2016 06:58 PM, Stephen Michel wrote: >>> >>> >>> >>> I think that this scenario is really hard to parse. It could also result in >>> a display where you have a carryover from may and a carryover from June >>> displayed in July, and that gets really busy really quickly (especially if >>> one or more are also carried over to august). >>> >>> I suggest that we aggregate all carryover charges. The small loss in detail >>> is totally worth the simplicity, imo. >>> >> Absolutely! Describing the carry-over from several months with separate >> list of carry-overs would be crazy. But the aggregated sum can be >> described as month-month e.g. "March-July carry-over". Effectively, most >> carry-overs will only happen at the early stage of projects and patrons, >> when they first start on the system. A new project with some new patrons >> may have a period of carry-overs, and then no more of that going >> forward. So, it's just this contiguous set of months that will have >> carry-overs in almost all cases. >> >> To cover all possible scenarios, we could just say "carry-over from >> earlier months with charges too low to be worth charging" effectively. >> >> In any case, it should be one sum number. > > That's already what I intended: At most one carry over from the previous > month and one carry over to the next month. I don't even think we > should try to describe what multiple months it may originally come from > (e.g. no attempt at "March-July carry-over" etc) because that will just > get too complicated, particularly in the "widdle-away" scenario when > part of a carry over is paid off in one month but part is carried over > to the next month. > > It would probably be clearer to go back to referring to "next month" and > "previous month" as I'd done previously, rather than naming the specific > last and previous months as I tried in this latest version. > Let me try to make my view clearer. I think that it is more understandable to think this: "Oh, when things were really low, no charges happened, it just added up and carried over into the first real charge, although it may take a couple months in rare cases getting close to budget limit" Than this: "This is the carry-over from last month even though last month had a charge of my budget limit. So, the carry-over must have been from before because they wouldn't actually bill me more than the monthly budget, right?" To put it another way: I want people to keep in mind that carry-overs all just happen from the early low-level first period. I don't want them to get the impression that carry-overs are a normal occurrence and should be expected to recur often. So, I prefer that people associate the carry-over with the early low-level period. I don't want it to be associated with the most recent month necessarily. Let's say 5 months go by at low level and finally get to a point worth charging. I don't want to present the charge as a one-month carry-over. I want to present it as "we finally have enough for the past 5 months to put in a charge without excessive fees". The common scenario could be: Jan $0.12 Feb $0.34 Mar $1.66 Apr $3.18 So, then we charge in April, and I *like* the idea of saying "this is all the donations for 4 months in one charge." That seems clear and understandable. Having to chain back the carry-overs seems harder to follow or at least risks people misunderstanding what is going on. I hope my concern is more clear now. I'm not sure what the solution is. But I will add that this could be put off for the immediate time-being, so I don't want us to get too distracted perfecting this right now. 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/12/2016 09:37 PM, Aaron Wolf wrote: > On 08/12/2016 08:04 PM, Michael Siepmann wrote: >> > Let me try to make my view clearer. I think that it is more > understandable to think this: > > "Oh, when things were really low, no charges happened, it just added up > and carried over into the first real charge, although it may take a > couple months in rare cases getting close to budget limit" > > Than this: > > "This is the carry-over from last month even though last month had a > charge of my budget limit. So, the carry-over must have been from before > because they wouldn't actually bill me more than the monthly budget, right?" > > To put it another way: I want people to keep in mind that carry-overs > all just happen from the early low-level first period. I don't want them > to get the impression that carry-overs are a normal occurrence and > should be expected to recur often. So, I prefer that people associate > the carry-over with the early low-level period. I don't want it to be > associated with the most recent month necessarily. > > Let's say 5 months go by at low level and finally get to a point worth > charging. I don't want to present the charge as a one-month carry-over. > I want to present it as "we finally have enough for the past 5 months to > put in a charge without excessive fees". > > The common scenario could be: > > Jan $0.12 > Feb $0.34 > Mar $1.66 > Apr $3.18 > > So, then we charge in April, and I *like* the idea of saying "this is > all the donations for 4 months in one charge." That seems clear and > understandable. Having to chain back the carry-overs seems harder to > follow or at least risks people misunderstanding what is going on. > > I hope my concern is more clear now. I'm not sure what the solution is. > > But I will add that this could be put off for the immediate time-being, > so I don't want us to get too distracted perfecting this right now. Your concern makes sense to me. I think if we can get an adequate solution to this now, it will be very helpful to have this tricky aspect worked out. The following version seems to me to get quite a bit closer. I look forward to further feedback: http://snowdrift.sylphs.net/f/48fba86882/?raw=1 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/12/2016 09:57 PM, Michael Siepmann wrote: > On 08/12/2016 09:37 PM, Aaron Wolf wrote: >> On 08/12/2016 08:04 PM, Michael Siepmann wrote: >>> >> Let me try to make my view clearer. I think that it is more >> understandable to think this: >> >> "Oh, when things were really low, no charges happened, it just added up >> and carried over into the first real charge, although it may take a >> couple months in rare cases getting close to budget limit" >> >> Than this: >> >> "This is the carry-over from last month even though last month had a >> charge of my budget limit. So, the carry-over must have been from before >> because they wouldn't actually bill me more than the monthly budget, right?" >> >> To put it another way: I want people to keep in mind that carry-overs >> all just happen from the early low-level first period. I don't want them >> to get the impression that carry-overs are a normal occurrence and >> should be expected to recur often. So, I prefer that people associate >> the carry-over with the early low-level period. I don't want it to be >> associated with the most recent month necessarily. >> >> Let's say 5 months go by at low level and finally get to a point worth >> charging. I don't want to present the charge as a one-month carry-over. >> I want to present it as "we finally have enough for the past 5 months to >> put in a charge without excessive fees". >> >> The common scenario could be: >> >> Jan $0.12 >> Feb $0.34 >> Mar $1.66 >> Apr $3.18 >> >> So, then we charge in April, and I *like* the idea of saying "this is >> all the donations for 4 months in one charge." That seems clear and >> understandable. Having to chain back the carry-overs seems harder to >> follow or at least risks people misunderstanding what is going on. >> >> I hope my concern is more clear now. I'm not sure what the solution is. >> >> But I will add that this could be put off for the immediate time-being, >> so I don't want us to get too distracted perfecting this right now. > > Your concern makes sense to me. I think if we can get an adequate > solution to this now, it will be very helpful to have this tricky aspect > worked out. The following version seems to me to get quite a bit > closer. I look forward to further feedback: > > http://snowdrift.sylphs.net/f/48fba86882/?raw=1 > > > Yes! This is much more clear to me. There was a funny postponed time, and I see how it is getting included in later months to avoid fees. Makes sense, glad Snowdrift.coop thought this out so well! That's my impression of the new version. Happy to see others' feedback, but this one seems much better than all previous mockups! signature.asc Description: OpenPGP digital signature ___ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
