Re: [Snowdrift-design] Discuss project page and dashboard

[Stephen Michel]

I was planning on just making a good 'ol fashioned paper-and-pencil 
sketch to start. I've looked at Pencil in the past and while it does 
leave something to be desired, it is functional, and seems to be the 
best/most popular FLO mockup tool.


On Fri, May 20, 2016 at 6:38 PM, Michael Siepmann 
 wrote:
Somewhere in the recent emails between Stephen and Aaron (which I've 
looked through but not read every word of) Stephen referred to 
working on a mockup.  I think mockups are what we really need at this 
point, to ground this discussion and start focusing on how to make 
this look straightforward enough from the user's point of view.  They 
don't need to be complete page mockups and certainly not 
high-fidelity visually designed mockups.  They can be rough partial 
wireframes to start representing proposals for the basic information 
and controls the user will interact with.


Stephen: In what format are you making a mockup?  How soon do you 
think we could look at it?  I'm interested in trying Pencil 
(https://github.com/prikhi/pencil). Unfortunately the tool I have the 
most experience with currently is proprietary (Axure RP) and I'm 
eager to start exploring and learning how to use a FLO alternative.


(By the way, I unfortunately have a conflict on Monday and won't be 
able to be at our regular meeting.)


Best,

Michael

Michael Siepmann, Ph.D.
The Tech Design Psychologist™
Shaping technology to help people flourish™
303-835-0501   TechDesignPsych.com   OpenPGP: 6D65A4F7

On 05/20/2016 12:06 PM, Bryan Richter wrote:

I'm kinda... not reading too much of these right now, but there was a
question I could sorta answer:

On Thu, May 19, 2016 at 11:12:24PM -0400, Stephen Michel wrote:

I'm a user. I go to snowdrift.coop, log in, go somewhere (I'd assume
dashboard, but I'm trying not to assume), and click on a button to
add funds to my account (current balance: $0). I specify $50 and
click 'next'. Now what happens? I presume I'm prompted to log in to
Stripe. Am I also prompted to authorize $50 for snowdrift, or does
that come later, or for individual transactions, or...?

This is partially dependent on the API of the payment processor.
Stripe has two options, one of which is "managed accounts". With that
option, users won't have to have their own Stripe account. I'm not
certain what the workflow for getting their payment data is, but I'm
pretty sure it involves Stripe's UI. At any rate, we'll never
see it, and it will be pretty streamlined.

Right now there are two likely stories. They are:

1. The Admiral

- User pledges to a project, and damn the torpedoes.
- If they're not logged in, they can log in, and/or create an account
- If they don't already have a managed account, it is set up
- If they don't have any funding limits set, they are asked to 
specify

  what maximum amount of money they want to donate per month.
- The become pledged to the project.
- ...
- Monthly, their pledge(s) are processed, and they donate an amount 
up

  to the limit they set.

2. The Spy

- User holds their breath and creates an account
- User cautiously pokes around the dashboard and /how-it-works
- User feels more confident, and goes to the dashboard and chooses to
  make funds available
- They set up a managed account
- They specify a maximum amount of money to donate per month
- Finally, they poke around the available projects, and pledge to 
one.

- ...
- Monthly, their pledge(s) are processed, and they donate an amount 
up

  to the limit they set.

Note: both of these are "arrears" methods. I believe they are safer
and simpler than "pay upfront" methods. Even though I prefer the
latter for a few different reasons, I'd like to stick with "safer and
simpler" for now.


___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design


___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Discuss project page and dashboard

[Michael Siepmann]

Somewhere in the recent emails between Stephen and Aaron (which I've
looked through but not read every word of) Stephen referred to working
on a mockup.  I think mockups are what we really need at this point, to
ground this discussion and start focusing on how to make this look
straightforward enough from the user's point of view.  They don't need
to be complete page mockups and certainly not high-fidelity visually
designed mockups.  They can be rough partial wireframes to start
representing proposals for the basic information and controls the user
will interact with.

/Stephen:/ In what format are you making a mockup?  How soon do you
think we could look at it?  I'm interested in trying Pencil
(https://github.com/prikhi/pencil). Unfortunately the tool I have the
most experience with currently is proprietary (Axure RP) and I'm eager
to start exploring and learning how to use a FLO alternative.

(By the way, I unfortunately have a conflict on Monday and won't be able
to be at our regular meeting.)

Best,

Michael

Michael Siepmann, Ph.D.
*The Tech Design Psychologist*™
/Shaping technology to help people flourish/™
303-835-0501   TechDesignPsych.com
   OpenPGP: 6D65A4F7

 

On 05/20/2016 12:06 PM, Bryan Richter wrote:
> I'm kinda... not reading too much of these right now, but there was a
> question I could sorta answer:
>
> On Thu, May 19, 2016 at 11:12:24PM -0400, Stephen Michel wrote:
>> I'm a user. I go to snowdrift.coop, log in, go somewhere (I'd assume
>> dashboard, but I'm trying not to assume), and click on a button to
>> add funds to my account (current balance: $0). I specify $50 and
>> click 'next'. Now what happens? I presume I'm prompted to log in to
>> Stripe. Am I also prompted to authorize $50 for snowdrift, or does
>> that come later, or for individual transactions, or...?
> This is partially dependent on the API of the payment processor.
> Stripe has two options, one of which is "managed accounts". With that
> option, users won't have to have their own Stripe account. I'm not
> certain what the workflow for getting their payment data is, but I'm
> pretty sure it involves Stripe's UI. At any rate, we'll never
> see it, and it will be pretty streamlined.
>
> Right now there are two likely stories. They are:
>
> 1. The Admiral
>
> - User pledges to a project, and damn the torpedoes.
> - If they're not logged in, they can log in, and/or create an account
> - If they don't already have a managed account, it is set up
> - If they don't have any funding limits set, they are asked to specify
>   what maximum amount of money they want to donate per month.
> - The become pledged to the project.
> - ...
> - Monthly, their pledge(s) are processed, and they donate an amount up
>   to the limit they set.
>
> 2. The Spy
>
> - User holds their breath and creates an account
> - User cautiously pokes around the dashboard and /how-it-works
> - User feels more confident, and goes to the dashboard and chooses to
>   make funds available
> - They set up a managed account
> - They specify a maximum amount of money to donate per month
> - Finally, they poke around the available projects, and pledge to one.
> - ...
> - Monthly, their pledge(s) are processed, and they donate an amount up
>   to the limit they set.
>
> Note: both of these are "arrears" methods. I believe they are safer
> and simpler than "pay upfront" methods. Even though I prefer the
> latter for a few different reasons, I'd like to stick with "safer and
> simpler" for now.
>
>
> ___
> Design mailing list
> Design@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/design



signature.asc
Description: OpenPGP digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

[Snowdrift-design] [non MVP food for thought] Fwd: per-project budgets

[Stephen Michel]

This is an excerpt from the conversation Aaron & I had. It was separate 
initially because it's not MVP but this is now fairly short and has IMO 
the most interesting points.


--
Email Policy: http://stephenmichel.me/email

-- Forwarded message --

From: Aaron Wolf 
Subject: Re: Stuff I cut from the design list thread NNTR
Date: Fri, 20 May 2016 13:19:30 -0400
To: Stephen Michel 

On 05/20/2016 08:26 AM, Stephen Michel wrote:
 On Fri, May 20, 2016 at 9:46 AM, Aaron Wolf  
wrote:

 On 05/20/2016 06:02 AM, Stephen Michel wrote:

 If you always increase your budget as needed, you're not really
 budgeting, so that's trivially true. The point is that each time
 you hit your per-account budget, you need to decide which 
project
 you would drop if you decide not to increase --O(n) in the 
number
 of projects--, and then decide whether to increase or drop-- 
O(1).

 With per-project budgeting, you've essentially made the first
 decision once, in advance, so you don't need to make it over and
 over again: the one you would drop is the one that's currently
 hitting it's cap.

 The only reason there's a cap is because that's a fundamental need 
for

 people to feel comfortable trying the system. It would be totally
 unreasonable for us to charge people as though they didn't have
 budgets. We RESPECT that people have budgets. It's not something we
 want in terms of our mission though!!


 I think there's a second reason here, too: the reality is that some
 people are on strict budgets -- but they want to help out anyway.
 Budgeting is a necessity to enable their participation.



Yes, participation is a goal in and of itself, so that's valid. But it's
secondary to funding FLO, as in if funding FLO versus participation are
in *conflict*, Snowdrift.coop would aim for funding *if* no other values
were compromised. If two options were equal for funding and one was more
participation, we'd absolutely go with that.

This is why I *support* the option of adding budget categories (e.g.
"graphics software" vs "music" vs "research vs "Firefox") that provide
options for patrons to set up their own budgeting. It's just definitely
long past MVP (especially since nobody early on will be hitting budget
limits because that will only come after we get enough patrons anyway.

 As you point out that does come with a cost of making budgeting a 
bigger

 focus for the people who we don't want to budget. Maybe that's a cost
 we're not willing to pay, or maybe there's another solution that 
doesn't

 incur that cost.


I think the solution is to make budgeting an optional feature. But I
think this is something we can discuss once we are launched and have
data and research, and then Michael and Robert will have definite
insights here too.


 (feel free to summarize this aspect of our conversation (your
 misunderstanding if you accept that) in a summary post to the list
 clarifying the view you hold now after this)


 I'm going to reply there soon, just didn't have time at a computer 
when

 I woke this morning.

 If you hit your budget overall and refuse to increase, you 
can
 choose which projects to drop, which is the same effect in 
the

 end as per-project budget.

 It's actually an algorithms / efficiency / optimization problem,
 to reduce the number of individual decision points you need to
 make -- either way you're making the same decisions, it's a 
matter

 of how many times you need to repeat the action of making those
 decisions.

 That's stuff that needs post-launch real-world data.


 Data would be helpful, yes. I don't know I'd say it's *required* for 
the
 initial design. But I'm nitpicking; we'll have a chance to get data 
and

 iterate later.


Yeah, we can't require initial data, but that's why we have a design
already: the system-wide budget (whether one-time or recurring, still to
be decided there).




signature.asc
Description: PGP signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Discuss project page and dashboard

[Bryan Richter]

I'm kinda... not reading too much of these right now, but there was a
question I could sorta answer:

On Thu, May 19, 2016 at 11:12:24PM -0400, Stephen Michel wrote:
> 
> I'm a user. I go to snowdrift.coop, log in, go somewhere (I'd assume
> dashboard, but I'm trying not to assume), and click on a button to
> add funds to my account (current balance: $0). I specify $50 and
> click 'next'. Now what happens? I presume I'm prompted to log in to
> Stripe. Am I also prompted to authorize $50 for snowdrift, or does
> that come later, or for individual transactions, or...?

This is partially dependent on the API of the payment processor.
Stripe has two options, one of which is "managed accounts". With that
option, users won't have to have their own Stripe account. I'm not
certain what the workflow for getting their payment data is, but I'm
pretty sure it involves Stripe's UI. At any rate, we'll never
see it, and it will be pretty streamlined.

Right now there are two likely stories. They are:

1. The Admiral

- User pledges to a project, and damn the torpedoes.
- If they're not logged in, they can log in, and/or create an account
- If they don't already have a managed account, it is set up
- If they don't have any funding limits set, they are asked to specify
  what maximum amount of money they want to donate per month.
- The become pledged to the project.
- ...
- Monthly, their pledge(s) are processed, and they donate an amount up
  to the limit they set.

2. The Spy

- User holds their breath and creates an account
- User cautiously pokes around the dashboard and /how-it-works
- User feels more confident, and goes to the dashboard and chooses to
  make funds available
- They set up a managed account
- They specify a maximum amount of money to donate per month
- Finally, they poke around the available projects, and pledge to one.
- ...
- Monthly, their pledge(s) are processed, and they donate an amount up
  to the limit they set.

Note: both of these are "arrears" methods. I believe they are safer
and simpler than "pay upfront" methods. Even though I prefer the
latter for a few different reasons, I'd like to stick with "safer and
simpler" for now.


signature.asc
Description: Digital signature
___
Design mailing list
Design@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

Re: [Snowdrift-design] Discuss project page and dashboard

[Stephen Michel]

Linking the relevant Taiga pages again for visibility:

Dashboard: https://tree.taiga.io/project/snowdrift/us/67

Project Page: https://tree.taiga.io/project/snowdrift/us/321

There was a small amount of initial work done in those places, I've 
added another little bit to that.


On Fri, May 20, 2016 at 12:16 AM, Aaron Wolf  
wrote:

On 05/19/2016 08:12 PM, Stephen Michel wrote:

 This email thread is about a design for the project and dashboard 
pages.
 Whether the limit is set on the dashboard page or the project page 
when

 pledging (or both) *is* an MVP decision. So is whether to include a
 wallet in addition to a monthly budget.


When the limit is *first* set, it will be system-wide per-patron. That
is a done decision for initial launch, not something to discuss 
further.



Whether the UX has the user set it when making their first pledge or
separately is a UX design decision that isn't final.

Yes, the decision on effectively a "wallet" is also open (even if we
charge in arrears still, it would be one-time authorizing of a total
amount versus a monthly authorization).


Between this and our out-of-band conversation, I'm satisfied / 
convinced that a lot of what I brought up is post-mvp (more than just 
point B) and has been adequately discussed in the past, so I'll try to 
trim out even more of my own non-mvp nonsense.


or (option 2) a $10 monthly max (which could roll-over so that it 
counts

as a $120 annual max but some months could go over $10, or we don't do
that sort of thing, just an idea)


For MVP I'd leave out a rolling balance.

 with #2 I can modify my limit at any time up until the monthly 
payout.
 - #1 as discussed a while ago requires me to maintain a 3 month 
minimum

 balance; #2 does not.


Yes, I agree about the 3-month balance being different, but you've
mistaken the details. We never proposed a 3-month balance being
*maintained*, we only proposed that a 3-month balance at current 
levels

be available to *place* a pledge initially.


Thanks for the clarification, I didn't realize this. That makes a 
wallet a much more palatable option.



 That third point is the biggest difference. If a project gains huge
 popularity overnight and eats up all 3 months' funds in a single 
month,

 I'll feel betrayed by the system. With #2 this is not possible.
 Therefore #2 is the more effective safeguard.


The "project gains huge popularity overnight" is a speculative thing
we'll be studying and not pre-optimizing for although we want to
consider it in our discussions. This is stuff the limits page 
describes.

We should certainly have notifications of huge pledge value changes.
There's no reason to feel betrayed, I don't understand that expression
in this case. I suspect it comes from your misunderstanding of the
3-month thing, as I clarified above.


That is indeed where "betrayed" comes from. Specifically the feeling of 
"I thought I was keeping a balance for three months and now suddenly 
it's gone in just one?!?!"


You are, of course, correct that this is speculation. The problem is, 
it's a common thing that people speculate about, and so they end up 
concerned even though there is no need to be. So the important thing is 
not to *actually* prevent it from happening, but to *reassure* people 
that it will not happen (or that they'll have a chance to back out if 
it does) so that they'll be comfortable signing up.



 Yes, automation can make some people uncomfortable. This is better
 solved, for example, by requiring me to manually confirm my budget 
this
 month, and adding a setting to auto-confirm [1], than building two 
whole

 different workflows.


I wasn't proposing "whole different workflows". If we offer both
one-time and monthly, the workflow would be almost the ame, and you'd
just say X one-time vs Y monthly-recurring as two choices in the same
interface with nothing else different. The monthly-recurring
authorization would itself *count* as meeting the 3-month buffer for
new-pledges. The UX would be almost identical in both cases.


I think I see what you're envisioning, and I like it. It's easier 
communicated visually so I'm going do to that, and then perhaps 
continue this conversation on the relevant taiga user stories.



 The part of this that IS relevant to MVP is: at what stage of the
 process does it make most sense for me to set my budget? When I 
pledge,

 or when I authorize Snowdrift to charge my Stripe account?



what order does that happen in? I'm not sure. And yes, these are
important design decisions.

One smooth option: I already see the pledge button when just a 
visitor.

Clicking it prompts me that I need to register as a user first. Then
maybe I'm back at the button still needing to click it again? Or 
assume

upon registration that the button is clicked in this case? Not sure.
Then, prompt for Stripe credentials and set a budget right then, 
maybe.


Needing to click again is less smooth but probably easier to implement. 
I