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: >>>> <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. >
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 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. >>>> * 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. > I was going after the position here more than anything else. being at the end of the list makes it even more important than the actual money values – from a position point of view. >>>> * 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. Both mockups do have a "link" mentioning the carryover and the actual entries. My point is that having "proper" entries inside a "$0-month is unintuitive. Not having to jump around months to make sense of the one payment that *did* happen seems more intuitive. > > 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. > 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. I think we had a discussion about that, and I think we need to do a good job about informing people when projects jump from one category from another, and maybe make it handy to undo certain actions - but that should NOT be in the history. If you really find yourself being reminded about a project that you *actually* wanted to keep supporting in the history – the notification system must have failed us 100%. It is not the job of the history to remind users of what they might have wanted but didn't do at some time in the past. >>>> * 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.) 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. >>>> 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. > > > > > > _______________________________________________ > Design mailing list > Design@lists.snowdrift.coop > https://lists.snowdrift.coop/mailman/listinfo/design > I really wonder how discourse changes the way how those gigantic email conversations happen...
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
