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: >>> <snip> >>> 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. >>> * Why is the day of the month of transaction important? So I can match it up easily to my credit card statement, etc. I think date of transaction is very basic and essential information and removing it creates vagueness, not simplicity. However, I think your visual design could present it much better - probably in the bottom line where you have "limit was $10"? Maybe put "Limit was $10" on the left and "Charged 06/30" where you currently have "limit was $10"? (I'd prefer "Your limit was $10" by the way, for clarity.) >>> 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 think my comments above address all of this. In summary, I think your visual treatment is excellent and I'd love to see a version that doesn't remove any of this information but just presents it better, as you've done with patron count, and that retains the treatment of carry-over shown in my mockup. >>> 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 think it's actually very simple, and illustrated in my mockup. Either there is carry over or there isn't. If there is, either it's because the amount would have been too low (making fees 10% or higher) or it's because the amount would have been too high (above limit). > 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. If we use the approach in my mockup, this issue just doesn't come up at all. Carry over is always just "to next month" and "from last month". You're never having to say "this part of the carry over is from one month ago and this part is from two months ago" etc.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
