34 ms·

I have to disagree. First, I actually do have this warning in the README. Second, if the app breaks when it doesn't have enough permissions, that's really jus

by chadrs 15y ago

I have to disagree. First, I actually do have this warning in the README. Second, if the app breaks when it doesn't have enough permissions, that's really just the laziness of the app developer. Handle the error gracefully if you really need the permission, and prompt for it again, explaining what you need it for.

cheald 15y ago
The app "breaking" isn't necessarily as cut-and-dried as "Threw an unhandled exception". Functionality that fails to work as the user expected (because the user revoked a key permission enabling that functionality) is "broken", and results in bug reports, which results in developer time spent trying to reproduce an issue that was introduced because the user violated one of the basic assumptions in the app. You should still be checking your returns, but you can check a return, see that the value didn't come back as expected, handle it gracefully, and still deliver a "broken" user experience. I appreciate the idea and the impetus for it - a lot - but the end result for something like this is broken apps to one degree or another.
- bigiain 15y ago
  I see it as being very similar to something like noflash - if I choose to install and run noflash it "breaks" some websites. Sometimes that's exactly what I wanted it to do - sometimes it's collateral damage, and when/if I notice it I can go in and whitelist something I broke to make it work again. Unless you're worried that somehow this extension will get sneaky-loaded without the user understanding what it does, I find it hard to see your argument as anything but alarmism... (Having said that, I've never written a Facebook app, and have no personal experience with that demographic - I could be easily convinced that popular Facebook app developers do get the sort of customers who complain that their critical "RanchVille" app - which they got for free - is broken with a blank screen and needs fixing _immediately_, oh and BTW hurry up, it's getting cold in this blackout!)
  - cheald 15y ago
    Flashblock is a great example of the problem. Google Music wouldn't work on my wife's computer, causing a lot of frustration for her, until I noticed the flashblock icon. Google was using a hidden div with a flash player to play the music. When Flashblock shows a big placeholder rather than the Youtube video, you know what's happening. It's not always obvious, though, and it takes someone who knows that Flash players are often used for this sort of thing to solve the problem. If I wasn't home, my wife would have just assumed that the product didn't work on her computer and given up on it.
    - uxp 15y ago
      I agree with your point. Even I took a few seconds longer wondering why Google Music didn't run on my version of Chrome until I correctly guessed that there was a hidden flash player somewhere I couldn't see, and I'm a developer myself. But, I do think the other side of the argument still stands. If someone decides to use a 25 pound sledge hammer to frame a house, that person shouldn't get mad when on occasion his tools end up causing more frustration than the project he's working on. Whitelisting tools like Flashblock/Clicktoflash or NoScript are sledge hammers to the web. When it's just a few things littered here and there on a site that is widely non-flash based, it's not a problem to take everything out at once. Fine tuning at that point requires a bit more care and a lot more effort, but it's hardly the fault of the plugin developer when it doesn't work in every case. Toggle it on off and see if it works, and move on.
- danudey 15y ago
  Considering how non-difficult it is to check Facebook's reply and make sure you received authentication for the permissions you requested, there's no excuse for 'basic assumptions'. Whenever you're dealing with a third-party service, you can't afford to make any assumptions, or you're bound to end up with a broken app, broken interactions, or incorrect data.
  - cheald 15y ago
    That's fair. I don't think that it's right to say that you can't make any assumptions, but you should have code that is prepared to handle failure cases. Facebook users can revoke permissions (or revoke access wholesale) without going through your app, so you have to be prepared to handle failures. The question is how to handle them in a way that doesn't leave the user dissatisfied with your product. Here's the next question, though - if it's as simple as checking the authed permissions and forcing a re-auth if permissions you wanted weren't granted, what value does this extension provide? It's effectively the same as clicking the "Don't Allow" button. (This conversation has been very productive, though; it's made me think more about the "ask permission when needed" flow, rather than the "ask up front" model we currently use. The former effectively sidesteps the issue by never presuming that the permission is present.)

by chadrs 15y ago

cheald 15y ago

The app "breaking" isn't necessarily as cut-and-dried as "Threw an unhandled exception". Functionality that fails to work as the user expected (because the user revoked a key permission enabling that functionality) is "broken", and results in bug reports, which results in developer time spent trying to reproduce an issue that was introduced because the user violated one of the basic assumptions in the app. You should still be checking your returns, but you can check a return, see that the value didn't come back as expected, handle it gracefully, and still deliver a "broken" user experience. I appreciate the idea and the impetus for it - a lot - but the end result for something like this is broken apps to one degree or another.

bigiain 15y ago
I see it as being very similar to something like noflash - if I choose to install and run noflash it "breaks" some websites. Sometimes that's exactly what I wanted it to do - sometimes it's collateral damage, and when/if I notice it I can go in and whitelist something I broke to make it work again. Unless you're worried that somehow this extension will get sneaky-loaded without the user understanding what it does, I find it hard to see your argument as anything but alarmism... (Having said that, I've never written a Facebook app, and have no personal experience with that demographic - I could be easily convinced that popular Facebook app developers do get the sort of customers who complain that their critical "RanchVille" app - which they got for free - is broken with a blank screen and needs fixing _immediately_, oh and BTW hurry up, it's getting cold in this blackout!)
- cheald 15y ago
  Flashblock is a great example of the problem. Google Music wouldn't work on my wife's computer, causing a lot of frustration for her, until I noticed the flashblock icon. Google was using a hidden div with a flash player to play the music. When Flashblock shows a big placeholder rather than the Youtube video, you know what's happening. It's not always obvious, though, and it takes someone who knows that Flash players are often used for this sort of thing to solve the problem. If I wasn't home, my wife would have just assumed that the product didn't work on her computer and given up on it.
  - uxp 15y ago
    I agree with your point. Even I took a few seconds longer wondering why Google Music didn't run on my version of Chrome until I correctly guessed that there was a hidden flash player somewhere I couldn't see, and I'm a developer myself. But, I do think the other side of the argument still stands. If someone decides to use a 25 pound sledge hammer to frame a house, that person shouldn't get mad when on occasion his tools end up causing more frustration than the project he's working on. Whitelisting tools like Flashblock/Clicktoflash or NoScript are sledge hammers to the web. When it's just a few things littered here and there on a site that is widely non-flash based, it's not a problem to take everything out at once. Fine tuning at that point requires a bit more care and a lot more effort, but it's hardly the fault of the plugin developer when it doesn't work in every case. Toggle it on off and see if it works, and move on.
danudey 15y ago
Considering how non-difficult it is to check Facebook's reply and make sure you received authentication for the permissions you requested, there's no excuse for 'basic assumptions'. Whenever you're dealing with a third-party service, you can't afford to make any assumptions, or you're bound to end up with a broken app, broken interactions, or incorrect data.
- cheald 15y ago
  That's fair. I don't think that it's right to say that you can't make any assumptions, but you should have code that is prepared to handle failure cases. Facebook users can revoke permissions (or revoke access wholesale) without going through your app, so you have to be prepared to handle failures. The question is how to handle them in a way that doesn't leave the user dissatisfied with your product. Here's the next question, though - if it's as simple as checking the authed permissions and forcing a re-auth if permissions you wanted weren't granted, what value does this extension provide? It's effectively the same as clicking the "Don't Allow" button. (This conversation has been very productive, though; it's made me think more about the "ask permission when needed" flow, rather than the "ask up front" model we currently use. The former effectively sidesteps the issue by never presuming that the permission is present.)