On Wed, Aug 10, 2016 at 7:01 PM, Stephen Michel
<stephen.mic...@tufts.edu> 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
