For an end user, OAuth is generally speaking much friendlier for pretty much every application type, iPhone, desktop, or web. The only applications that might possibly have a usability barrier (and as I said before, a quite slight one if you just make your own workaround as I just suggested) are command line applications, and because it's only really feasible to use command line applications with a single user, the curl login for you method I mentioned should work just fine.
On Mon, Feb 9, 2009 at 3:30 PM, funkatron <[email protected]> wrote: > > 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. > > > > >
