UI development in a dynamic world
It used to be that if you put out a software product, and particularly as you produced new versions of it, people might complain about things that were hard or different (change bad!) or broke their workflow, and you'd decide whether to add some configuration parameters or redesign it again or just tell them to suck it up. There wasn't much they could do within the scope of your software if you didn't give them hooks. (They could, of course, take their business elsewhere if your breaking change was important.)
Then, if what you were developing was a web site, you had to cope with some variations ("IE did what to our site?"), but you still had a lot of control. Well, until browser add-ons became a thing, and people could block your ads and trackers and make you use HTTPS and your site had better still work if you didn't want people to surf away.
Now, quite aside from the multitude of browser add-ons that might be relevant, we have tools like Greasemonkey and Stylish that empower users to rewrite your site to their heart's content. For some of us this lets us turn unusable sites into usable ones ("you chose what font? and assumed I had a 1500px-wide browser? feh!"). But it goes beyond that; Greasemonkey, by allowing JavaScript injection, lets us add, remove, and redefine functionality. I have several Greasemonkey scripts for Stack Exchange that make those sites easier for me to use and moderate, scripts that let me add shortcuts and override assumptions the designers made that don't quite fit my circumstances. I like SE's designers and, mostly, the designs of the sites I use, but some things just don't work so well for me out of the box. I'm not picking on SE; I think this happens with lots of sites.
All of this got me wondering: how do you develop web UIs in that kind of world? Are there some best practices that designers use to say "ok, if you're going to hook into the site and change things, we'll make it easy for you to hook in here and here to try to guide and contain you"? Is there some way of doing defensive design, so that if people do add scripting they can reduce the chances that that'll break something important? Or do they mostly just not worry about this, figuring that the Greasemonkey heads know how to use the browser console and will reverse-engineer their pages and, anyway, if you're going to mess with our site it's ok to say you're on your own? (I don't actually know enough to write those Greasemonkey scripts myself; I use scripts that others have written. So I don't have a good perspective coming from the developer-user side here.)
I'm curious about how the expansion of user-driven variation, on top of the browser-driven variation we already had, is affecting the field.
Then, if what you were developing was a web site, you had to cope with some variations ("IE did what to our site?"), but you still had a lot of control. Well, until browser add-ons became a thing, and people could block your ads and trackers and make you use HTTPS and your site had better still work if you didn't want people to surf away.
Now, quite aside from the multitude of browser add-ons that might be relevant, we have tools like Greasemonkey and Stylish that empower users to rewrite your site to their heart's content. For some of us this lets us turn unusable sites into usable ones ("you chose what font? and assumed I had a 1500px-wide browser? feh!"). But it goes beyond that; Greasemonkey, by allowing JavaScript injection, lets us add, remove, and redefine functionality. I have several Greasemonkey scripts for Stack Exchange that make those sites easier for me to use and moderate, scripts that let me add shortcuts and override assumptions the designers made that don't quite fit my circumstances. I like SE's designers and, mostly, the designs of the sites I use, but some things just don't work so well for me out of the box. I'm not picking on SE; I think this happens with lots of sites.
All of this got me wondering: how do you develop web UIs in that kind of world? Are there some best practices that designers use to say "ok, if you're going to hook into the site and change things, we'll make it easy for you to hook in here and here to try to guide and contain you"? Is there some way of doing defensive design, so that if people do add scripting they can reduce the chances that that'll break something important? Or do they mostly just not worry about this, figuring that the Greasemonkey heads know how to use the browser console and will reverse-engineer their pages and, anyway, if you're going to mess with our site it's ok to say you're on your own? (I don't actually know enough to write those Greasemonkey scripts myself; I use scripts that others have written. So I don't have a good perspective coming from the developer-user side here.)
I'm curious about how the expansion of user-driven variation, on top of the browser-driven variation we already had, is affecting the field.