Those are all technical issues. I'm talking about usability issues for non-technical users. However, none of what I'd have to say is different than what I've already said on the topic, and I'm sure things will work out fine in time.
-- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 9, 5:11 pm, Nicholas Moline <[email protected]> wrote: > Assuming Twitter keeps to a long/no expiration model for the OAuth tokens > (as I understand it, it currently is set to not expire in the beta), or > better yet, have a choice method for how long the token will last, for users > accessing a site that accesses twitter, have a short expiration (an hour or > a day), but have the option to create a token for client side applications > that don't expire, then there shouldn't be a problem. You have your client > program check to see if your token is valid, if it is not, spit out the url > to get a new token, then you just paste your token back into your app's > information and it's good for another 6 months or forever or whatever. > It should even be possible to have your script get the token for you, for > your own purposes if you store your login information, you can have your > script access the url, get the token, and save it. > > There should be no real reason to save end user's login information, they > should grant you access for the time periods that they access the site, it's > much more secure that way overall, and if Twitter keeps to a long expiration > model, saving those tokens to act for a period of time should be fine. > > On Mon, Feb 9, 2009 at 2:03 PM, funkatron <[email protected]> wrote: > > > I still maintain that this works fine for knowledgeable web dev folks > > (who seem to be the people who get excited about OAuth), but *will* > > confuse users who don't understand the tech involved, and/or aren't > > comfortable jumping between apps. In addition, the process becomes > > even more problematic with apps that don't run on a modern windowing > > platform (like CLIs, mobile devices, and the like). > > > If you have hard numbers from usability studies that prove my > > suspicions unfounded, that would be *great*. I'd love to be wrong. > > > -- > > Ed Finkler > >http://funkatron.com > > AIM: funka7ron > > ICQ: 3922133 > > Skype: funka7ron > > > On Feb 9, 4:12 pm, Blaine Cook <[email protected]> wrote: > > > OAuth was designed with explicit desktop application support in mind. > > > To see how it works in practice, try using a desktop Flickr Uploader > > > or iMovie's YouTube integration. > > > > Normally your app will open a browser window (all modern environments > > > do this seamlessly) and ask the user to authorize the application. > > > Once they've done that, they should be told to go back to the > > > application (close the browser window) and continue the setup process > > > (usually by just clicking "Continue" or OK so that the desktop app > > > knows that it's OK to exchange the request token for the access > > > token). > > > > b. > >
