On 11.08.2016 00:42, Michael Siepmann wrote: > On 08/10/2016 03:13 PM, mray wrote: >> <snip> >> 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.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. >> 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. > I disagree. We may set up a system that artificially generates a subset of projects that gets called "suspended" and do all sorts of things with that. like listing them in whatever places. But in terms of our "mechanism" there is no such thing as a third state of projects. We might as well create another subset like "favourites" and start to star projects that we like and think about supporting some time for example. But that kind of activity would be equally important to the flow of money. This again raises the question of whether the history page should only present the flow of money or represent different kinds of activity. Given my distinction between two types of history "1." being the detailed log and "2." being the simple trace of money are we still on the same page? I actually agree with many of your points given another premise on the pages intent. > >> >> 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. > I agree. This detailed bit of information about the *when* is needed for sure. It is just not relevant for a representation that yearns for simplicity in getting across the *how much* and *where*. > > 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 does not > however try to break down that carried over amount into "where it came > from" the way yours does. To me this seems much simpler and more > intuitive than making June hierarchically contain details about carried > over amounts from May (and perhaps April, March, February...) which may > not even be the ful amounts from those months if only part was carried > over to avoid exceeding the limit. > > In terms of "jumping around" I think mine strikes you as making you > "jump around" because your mental model is that anytime there's a charge > there should be a complete breakdown right there of where every portion > of carry over came from. You're not comfortable with having that > information be provided in the month it really happened, pledge-wise. > You want it to be all shown in the month of the charge. Since my > version just says "this much was carried over from last month - go look > at last month if you want the see why" you feel you have to "jump > around" to go see what happened in May. However, to me, your version > makes me "jump around" in the other direction, in a way I find > confusing, because when I look at May (or April or March) you won't tell > me anything about that month other than that I wasn't charged anything > and some unspecified amount was carried over to a future month. That > future month (which often won't even be displayed at all yet) is where I > have to "jump" to learn anything about May, April, or March other than > the bare minimum information your version gives me that "you weren't > charged anything because fees would have been too high". > > I guess I just don't count it "jumping around" when the month I come from is almost empty and just says "nothing to see here, please go along". Whereas given a set of months that are all equally "filled" with information that I have to parse It can be quite a surprise to find myself taking apart one month only to find out that it sends me elsewhere to finally make sense.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Design mailing list Design@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/design
