Page MenuHomePhabricator

Update UI for PhortuneAccount
ClosedPublic

Authored by chad on Mar 30 2017, 10:50 PM.
Tags
None
Referenced Files
F13142355: D17589.diff
Fri, May 3, 6:02 AM
Unknown Object (File)
Thu, Apr 25, 1:00 AM
Unknown Object (File)
Sat, Apr 20, 6:50 AM
Unknown Object (File)
Fri, Apr 19, 6:17 PM
Unknown Object (File)
Sat, Apr 6, 11:10 PM
Unknown Object (File)
Sat, Apr 6, 9:06 PM
Unknown Object (File)
Sat, Apr 6, 9:06 PM
Unknown Object (File)
Fri, Apr 5, 10:46 PM
Subscribers

Details

Summary

Primarily, this splits individual sections of the single account page into a more managable and robust sidenav for subscriptions, billing, and managers. The functionality on the subpages is light, but I expect to build on then in coming diffs. This also starts building out a more effective "status" area on the lead page.

Test Plan
  • Load up default account
  • Make some edits
  • Click on each of the new navigation items
  • Verify links to "see all" work
  • Test overdue and no payment states for status

Screen Shot 2017-03-30 at 3.51.39 PM.png (2×2 px, 396 KB)

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

  • Consider separating "Payment Methods" and "Billing History" into separate sections? I think it wouldn't be obvious to me that I need to go to "Billing" to change payment methods, except that the icon suggests it. But "Payment Methods" is probably something I'm often interested in interacting with (because my card expired or whatever).
  • "Edit Account" says "Members", curtain UI says "Managers".
  • Transaction history says "Members".
  • "Add Manager" isn't accessible via the UI? Maybe makes sense to put on the managers section? Oh, it looks like the code builds a button but doesn't use it? So I didn't test that bit.
src/applications/phortune/controller/account/PhortuneAccountManagerController.php
65–70

poor button 😿

src/applications/phortune/controller/account/PhortuneAccountViewController.php
243

srs bsns!

247–252

For now, I don't think we should warn about this.

I think it creates the implication that users should add a payment method without actually paying for anything, but there's currently no point to doing that, because we don't have a concept of payment methods that we'll automatically attempt to charge without further configuration.

Specifically, users may hit this:

See "no payment method" warning.
Add a payment method.
Warning vanishes.
Seems like they're all set.
At the end of the month, payment fails because the card isn't associated with the subscription.

This seems potentially more confusing than the current workflow.

There's also no obvious/direct way to actually add a payment method yet.

Instead, we could do one of these, which I think are better solutions:

  • Warn "You have a subscription with no associated payment method."; or
  • Add the idea of a "default" payment method, change subscriptions to have options "Never autopay; use default method; <use specific card>", warn "You have a subscription with no associated payment method, and have no default payment method."

I think adding "default payment method" is totally reasonable -- it didn't really make tons of sense before subscriptions, but now does.

This revision is now accepted and ready to land.Apr 11 2017, 12:14 PM

I think I want to land D17585 before this so I can wire up the Add Manager stuff, if that's ok.

chad marked 3 inline comments as done.
  • clean up UI
This revision was automatically updated to reflect the committed changes.