UI development in a dynamic world
Apr. 12th, 2015 09:40 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cellioIt 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.
(no subject)
Date: 2015-04-13 02:42 am (UTC)(no subject)
Date: 2015-04-13 08:06 am (UTC)People do of course put traditional Javascript-call APIs on their sites. It's an interesting question whether there are sites where it would be better architecture to do a programming framework like you're discussing with user code touching many of the elements directly.
My guess is that this "whole-DOM surface" type of framework would be even harder to do right -- meaning uphold usable commitments not to break users -- than an API where the surface is JS calls. Harder because it's essentially bringing in a third party, the browser. And as we know designing a traditional API platform to uphold commitments is plenty hard already.
So yeah, honestly I think Greasemonkey etc. has value *because* it's a different interaction than "API provider / API user". In that the site owner doesn't do any design work for it, and no testing coverage, and they make no commitments, and yet the user can still get some use out of it.