This is really exciting.

---

note, I will want to update all the forms to match the new, simplified pattern. happy to work on that...

  --Ethan McCutchen.....2012-12-06 20:54:23 +0000

---

We need events for this too, but I think that should have it's own Ideas/Issue card, right?

  --Gerry Gleason.....2012-12-10 11:09:07 +0000

---

yes, I will bang on that.

  --Ethan McCutchen.....2012-12-10 16:21:34 +0000

---

I think that Invite and Signup are both POST :create, :id=>'*account', and Accept is like update_account, PUT :id=>'UserName', :account=>{:status=>'active'}

  --Gerry Gleason.....2012-12-12 03:50:26 +0000

---

1. invite and signup (in their current version), both have GET versions. what is design for those?

2. why would it be to create '*account'? There are actual cards getting created, and *account isn't one of them. Shouldn't the POST just have the details of the actual cards?

 

Suppose we're signing up "Barry". If we need to create Barry, Barry+*email, Barry+*account, then the question is just what the params look like, no?

 

  --Ethan McCutchen.....2012-12-12 04:42:01 +0000

---

it probably makes sense at this point to get very clear on how we really want the nested cards api to look. do we like the cards thing? also, do we like this notion of having all the POST details under card? eg card[name], card[type_id], etc

  --Ethan McCutchen.....2012-12-12 04:44:08 +0000

---

GET /*account+*invite and /*account+*signup, and they POST could post back there are to *account card

  --Gerry Gleason.....2012-12-12 19:23:52 +0000

---

the GET /*account can still work as it does currently

  --Gerry Gleason.....2012-12-12 19:25:16 +0000

---

I agree about nested cards. I think it should be thought of as POST/PUT with a payload that is multiple cards updated together. At some point we make these groupings significant for change notifications

  --Gerry Gleason.....2012-12-12 19:26:32 +0000

---

I will be converting existing rails views at this point. I think this is the solution outline for signup/invite.

 

The link (account_links): if Card[:account].ok?(:create, :trait=>:invite); :edit view of *account+*invite, but POST's to *account else Same view *account+signup

 

Then the forms are in cards.

  --Gerry Gleason.....2012-12-13 10:45:22 +0000

---

cool, I think we can do this with a simple branch off of develop, right?

 

please look into the #fieldset method in renderer. This will help make it so all fields look uniform throughout the site.

 

my impulse would be to do GET /:signup, GET /:signin, and GET /:invite for the forms (very simple API)

 

I'm still not clear about whether, in general, we want the root card variables to be (eg) card[name], name, model[name]? I kind of think we should standardize. My impulse is to break them up into param groups like model=>{}, event=>{}, and view=>{}. We don't necessarily have to implement all of that right away, but I think it's time to have a plan.

  --Ethan McCutchen.....2012-12-13 18:49:26 +0000

---

Yeah, signup/invite are simple and good ones to start with.

  --Gerry Gleason.....2012-12-13 20:07:29 +0000

---

Ok, so we jus t said that it isn't just GET, but a :new view (GET still, but different view)

---

I'm going to attempt an implementation: add codenames for :signup, :invite and :forgot_password and give them all :new views on a self-pattern. I'm not sure about accept yet, so I'll work on the others first.

---

I don't think we want codenames for those, do we?

---

Not yet, but I would be adding them. Or rather some do and some don't.

I've been playing around with what seems to work best, and the direction I'm going is to make at least the new account request, (invite and signup) just have the input form described by a structure rule on cardtype. I think that is better than custom views, but it also means that the cards codenamed :invite and :account_request would need to be type Cardtype so you can make the account_links view link to /new/AccountRequest and /new/*invite. Currently, both of these actions (create a request from either signup or invite links) create AccountRequest cards, so I think I would fix that up in an event for the invite case.

What I noticed just now is that results in the form having '+*account+*email' on the left in the form, which seems bad from a UI perspective, but I'm not sure we can override that now (or can we).

---

Account Request is already a cardtype. Invite should probably not be one.

 

This needs to be designed with a lot of top-down thinking. Folks are going to come in and want to choose how new users are created. Do you get how that works now? How *invite and *request and *signup currently hack a bunch of that together? It's really pretty awful, so now's the great opportunity to fix it.

 

Please don't implement until we agree on a card structure design. If this ticket is too broad, we can create a narrower one to discuss that. There's a whole rhythm of propose / hone / agree / implement that should generally happen when we're working on stuff that involves changes to user experience. We need to make sure all this stuff gets in +solution cards on tickets, not tucked away in discussions or skype chats.