Signs of a broken UX: Dropbox API
Why did they do this?
Dropbox has several APIs, and the ones I am referring to are the Core API and the Chooser API. The Core API uses OAuth 2.0 to allow your app to get authorization from the user and the Chooser API creates a file picker for you, without requiring server-side. The catch is: they absolutely do not work together and have zero integration.
Did it not occur to the person in charge, that UI and server most of the time are synchronized? What if the app needs to download a file in the server based on the user’s choice? The point of integrating is that the user doesn’t have to download the file on their device first.
In hindsight, this might have been due to corporate policy: keep developers as much dependent on the Dropbox API and content as possible.
Decreased security
The fact no auth token is required for the Chooser, makes me feel wary. In fact, if someone put malicious Javascript in a page, they could get to show you the Chooser, in the same page, with the same appearance and get to download the files you selected from the temporary URLs returned by the API. This would be harder with an expiring user authentication token.
Decreased integration
I want my user to authorize my app once and then continue using the Dropbox integration for an indefinite amount of time. That is possible with Facebook, Twitter, Google Drive and others. But not with Dropbox. The UI component they made, Chooser, is not using the token stored in the server to access the files, so the user needs to be logged in in Dropbox to see her files. Also, you have to redo the authorization on the server, in order to download the file. What a waste.
This lack of integration forces the developer to 1) create a custom popup to get the token the first time and to 2) create a custom file picker with an associated controller to get the contents of the Dropbox folders. That is, if you want to have a consistent UX while having multiple integrations.
So, I think, this is broken.
