Commented inline On Tue, Oct 14, 2014 at 12:15 PM, Kalle Korhonen <kalle.o.korho...@gmail.com > wrote:
> On Tue, Oct 14, 2014 at 8:18 AM, George Christman <gchrist...@cardaddy.com > > > wrote: > > > Geoff, I always try to follow you suggested pattern, but unfortunately I > > don't think it's always possible. I'd like to present a use case scenario > > and perhaps maybe you guys can break me out of my current design rut. > > *Use case 1* > > *Use case 2* > > I guess I'm just not sure how you can accomplish both use cases without > > running into an area where a component would not need to command it's > > container. > > I'm very interested in hearing your thoughts. I'm not opposed to changing > > my design to make everything work properly. > > > > My original response still stands and I know what you are trying to > accomplish but it gets tricky trying to get it all done asynchronously, and > in general I advice to just handle sign-in/sign-up via a full page refresh. > I really do like the smooth user experience async can provide to the end user, but I guess it might just be easier to do a full page refresh in most cases. There is one use case where the user fills in a form prior to login and I would like to keep the login async if possible. It helps prevent me from having to store the object into memory while they are being authenticated. There are multiple reasons for it: > - you are likely going to support full login page anyway, so the clever XHR > flow is not required > - the screen real estate get crowded once you add sign-up to the same flow > - if you add Oauth, it's best practice to do full page refreshes > - available security frameworks have better support for full page refreshes > - design for mobile - modal dialogs often have fixed sizes, makes sure all > your users see the necessary stuff without scrolling (especially sideways) > Mobile is always a top priority. I always create fluid designs, so fixed widths are never an issue and deff no sideways scroll :-p. - if you allow plain http for your site, async flow won't work when you > switch to https for authenticated users > Facebook requires the entire site to run in https while using canvas and I'm now finding google is encouraging site owners to switch to full https in exchange for a little bit better page rank. That being said I'll be going full https by the first of the year thus eliminating this issue. > > Just as an anecdotal evidence and totally IMHO, stackoverflow.com has one > of the best designs out there for sign-in/sign-up flows and they are doing > it as a separate page as well. > I plan to borrow a few ideas form them, they do a nice job. I just hate having to leave a page to come back to it. Just seems cumbersome. Does the security framework have the ability to redirect the user back to the original page they were on prior to clicking the login link rather than say account home? Example of desired behavior, I'm looking at my listing, but decide I want to edit the listing. I click the nav sign in link and it redirects me to the login page. Once I'm logged in, I'd like to be redirected back to the listing page rather than the account landing page. This was one of the reasons I liked the async approach. > Kalle > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
