tecosystems

Greasemonkey and Gmail, Revisited

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

My entry from Tuesday on the changes to Gmail that disabled a variety of Greasemonkey scripts and a Firefox extension has spawned a couple of interesting criticisms both here in the comments and abroad that I wanted to comment on. There are two basic attacks on my original post; first, that expecting service providers to show any consideration or responsibility for GM type extensions is absurd, and second that the technical foundation that Greasemonkey and like applications is built on is essentially groundless. Interesting points, both. A few clarifications and responses:

  • Responsibility of Service Providers:
    Dan Sholler’s got some interesting thoughts in this area, but I apparently failed to be clear as to what I expected from Google, given a few of the comments and Dare’s post here:

    I find this hilarious. Greasemonkey scripts work by effectively screen scrapping the website and inserting changes into the HTML. Stephen and others who are upset by Google’s change are basically saying that Google should never change the HTML or URL structure of the website ever again because it breaks their scripts. Yeah, right.

    Repeat after me, a web page is not an API or a platform.

    Given that this is not what I intended to say, I think it behooves me to clarify my original remarks. So let’s start with what I’m not saying, and for that I may as well just borrow Dare’s words. “Stephen and others who are upset by Google’s change are basically saying that Google should never change the HTML or URL structure of the website ever again because it breaks their scripts” – that’s exactly what I’m not saying. I tried to emphasize this in my original post with the following, “While it’s Google’s perogative to make changes to the service as necessary for maintenance or other reasons,” but apparently that didn’t come through. So let me state for the record that Google, and any other service provider for that matter, absolutely has the right to change their application as they see fit. Every day, every hour, every minute, if that’s their thing. What I am saying is that changes have consequences. Developers are actively extending the functionality of these services with Greasemonkey scripts and the like, and given the importance developers hold today, that relationship may be worth considering when making modifications. As I just said to one commenter, my expectation is not that Google takes responsibility for ensuring that each and every script continues functioning after they make changes, let alone that they never change the HTML or URL structure as Dare contends. No, that’s clearly not possible in any sustainable or ongoing fashion. But when there’s a major change such as the base URL, do I think it’s unreasonable to expect that Google might announce it ahead of time? Just to give the developers making Google’s service more valuable to me a heads up? Nope. Think of it this way; when you’re in a relationship with someone, there are things you don’t technically have to do to preserve that relationship, but will anyway because it’s a small thing and is likely to make the other party happy. Wouldn’t you want to do that? Or would you just sit back saying, that’s not my job so I won’t bother?

  • Technical Foundation:
    The other primary vein of comments on this thread, one I’ve heard previously when extolling the virtues of GM, is that the approach of Greasemonkey (DOM scraping) is hopelessly flawed. The always excellent Bill de hÓra takes this position here:

    Greasemonkey is a cool idea, but these scripts are so fragile it’s not funny; they make side-effected GETs look robust. The page DOM is not part of the API contract, which is the basis of Alex Bosworth’s argument. In programmer terms it’s like depending on the field names rather than the field values. You build on this stuff, you more or less commit to lockstepping with the server. It feels house of card-like.

    To Bill’s point, is Greasemonkey like a House of Cards? Yes, absolutely. That’s both its weakness and its strength. Because as quickly as the scripts in the Gmail example broke, they were updated and functional in most cases same day. A House of Cards, after all, is easily knocked over, but just as easy to put back together. Likewise, Greasemonkey scripts are easily updated, even without the help of fancy consultants or IT. Indeed, I find the notion that Greasemonkey is inherently flawed because of its simplistic nature perilously close to the thinking that PHP is of no account because it’s technically inelegant. Be that as it may, it works, its easy to use, and has a very low barrier to entry. So while I’m not contending that GM is the end all and be all of appliation customization, neither would I dismiss it just because its applying green screen era screen-scraping to web pages. It works, and that’s good enough for me.

Hopefully that clears a few things up, and erases some of the ambiguity of my earlier missive on the subject. As always, feedback’s appreciated – am I off base here?

Update: Here’s an example of one service provider (Feedlounge is an Ajaxed up Bloglines type client, from what I understand) encouraging downstream customization of their application. Alex, one of the folks behind FeedLounge who I’ll coincidentally be having lunch with tomorrow, even gets the ball rolling with a few GM scripts here. On the flip side, Christopher remains unconvinced (see the comments here for a more detailed debate). While we obviously disagree, he’s a sharp guy and makes some very good points.

18 comments

  1. I think they've got a point. It's not something reliable, it's still cool, but it's definitley not a reliable way to add functionality.

    I don't see that as an attack on Gresemonkey personally, that's just the way that it does its business.

    If Google was actually putting out a JS API for GMail and changing it without issuing notices, I could see people complaining. But as it is, a lot of Google built stuff is piggybacking and Google has absolutely zero legitimate reason to consider the consequences when it makes a change to one of its products.

    To conclude, Webpages will change, scripts will break, and then they will be fixed.

  2. "And then the site developers make a trival change to the website and hours worth of work are down the drain."

    i don't know that that's true. given the simplicity of what we're talking about – remaking webpages – i don't know that a trivial change is going to completely invalidate a script. as discussed previously, the Gmail update broke those scripts…which were fixed within hours.

    might there be situations were a script is rendered worthless? perhaps. but i think the trivial change on the site is far more likely to be repaired with a trivial fix.

    add to that the fact that many sites – particularly internal ones – tend to be static for months or even years, and i'd have no problem using scripts in my daily workflow.

  3. well, i just checked the Greasemonkey script repository for Google (http://dunck.us/collab/GreaseMonkeyUserScripts#head-2b681c0a24baff8899d7163cc7f805c75e1f44e4), and by my rough count i find 69 scripts aimed at Google pages, 3 of which strip Ads. so while i'll concede that Google's likely not all that fired up about things like Butler, i think the clear majority of scripts are extensions, not Ad strippers.

    beyond that, however, there are Firefox extensions such as Gmail Notifier which have no such stripping capabilities and are similarly unaffected. so we shouldn't assume that it's just GM scripts that are at issue here.

    on the note that they'd be "supporting" these scripts, i don't buy that. all they'd be doing is committing themselves to announcing major changes; i don't seeing that being too much of an issue. nobody's asking Google to support these 69 scripts or to guarantee that they'll work indefinitely; i'm simply trying to push for an approach that recognizes that there are small things that Google – or other service providers – can do that make the folks enhancing their platform happy.

    whether or not that's good for Google's business is a matter of debate, but i can't see how it's any less relevant to their economical model than the Summer of Code.

  4. Don't forget scripts which strip adsense like:
    http://blog.monstuff.com/archives/000235.html

    Maybe it is good for business. I honestly don't know, since I don't understand google's business that well, and leave it at that.

  5. i think we’ll just have agree to disagree here, but this bit “Google has absolutely zero legitimate reason to consider the consequences when it makes a change to one of its products” caught me up. you seriously believe that Google should pay zero attention to developers that build on and/or extend their services?

    while i agree that they have no contractual obligation to do so, i nonetheless completely disagree with that.

    if Google doesn’t, Yahoo or MSN will. and the services that are extended by external parties will be the most interesting and compelling. Google Maps is interesting, but blending it with craigslist or the Chicago Crime DB makes it far more so.

    so sure, Google can ignore folks that build on their stuff, but i think they risk losing a.) developers and b.) attention as a result.

    but maybe it’s just me.

  6. I totally agree with Danno.

    Google in no way can support all the changes developers *might* make with greasemonkey like tools. It is much more important for them to make the experience better for the vast majority of their users.

    If google wanted their service to be extended, then they would have provided an API to do it. In my opinon you shouldn’t base your usage patterns on greasemonkey. That’s just asking for expected results.

  7. it’s not a matter of “supporting” the changes that are made, as we’d both agree that’s clearly impossible. the point is whether or not you try to make it easier for developers to work with you or not.

    take the most recent change. what i’m proposing is *not* that Google doesn’t change their URL (they had to in order to comply with a trademark suit in Germany, according to one account), or test out each and every script itself, or even wait for developers to do so.

    instead what i’m proposing is that Google take the simple, harmless step of making an announcement that says: “hey, just a heads up, we’re changing the URL.” what does that cost them? nothing.

    what do they gain? some developer goodwill, if at least a portion of the GM and FF Extension developers out there have updated scripts before/or as the script goes live.

    it seems as if everyone wants to read into this an assertion on my part that service providers either a.) shouldn’t make necessary changes, or b.) should make the changes and support every last extension out there. i’m making no such case.

    i merely think there’s more that could have been done, but wasn’t.

  8. Sam Ruby really nailed something about the value of the Greasemonkey approach: “Sometimes I can whip out a GreaseMonkey script in hours where it would take literally months to “do it right” — if I were even able to do it at all. In economic terms, one refers to the Net Present Value of a stream of investments. And when you factor in the larer pool of talent that can be applied by decentralizing the innovation, sometimes you get a clear win.”

    That’s hard to argue against. On the balance most of the feedback I got has been pushback and most of it made sense. Maybe I’ve been in the enterprise too long 😉

  9. “Sometimes I can whip out a GreaseMonkey script in hours where it would take literally months to “do it right”

    And then the site developers make a trival change to the website and hours worth of work are down the drain.

    Cool toy? Maybe. Something I would depend on in my daily workflow? no way.

  10. GreaseMonkey is good from both ends, the website producer needs to do nothing to enable it, the author doesnt’ need a special API to ues it.

    What causes problems is that these APIs are often neglected in a downward spiral. “No one’s using the API, let’s not pay any attention to it”, “Their API sucks it’s totally neglected and crap, I can’t build anything interesting on it”.

    Even FireFox which is extension heaven, breaks mods with changes. There is no good solution to this, other than doing due diligence with respect to the developer community.

    My FireFox GMail notifier (waste space in my crowded system tray? no thx) broke, which annoyed me. I do feel like GMail could have developed a real published API that wouldn’t require the Gmail notifier guys to be hacky and brittle.

  11. I’m generally not in favor of this type of thing because it means installing something into the client, and hacking HTML in unsupported ways.

    I just don’t see HTML as a stable API, but if works for some people, more power to them, but I think it is pretty difficult to expect *any* sort of support for this type of thing, even domain name changes. A change is a change.

  12. “I just don’t see HTML as a stable API, but if works for some people, more power to them, but I think it is pretty difficult to expect *any* sort of support for this type of thing, even domain name changes. A change is a change.”

    i don’t follow here; what about posting a simple notice of a pending domain change is hard? why should your average script monkey expect that most basic communication?

  13. Maybe it would be good for Google’s business to post notice of their changes. I doubt it though, because a lot of grease monkey scripts strip ads. That’s bad for business.

    I can’t imagine a notice like:

    “Dear developers of unsupported third party tools,

    Please be aware that we are changing our DOM model next week, so your ad strippers will no longer work. Please consider updating your scripts.”

    Google never claimed to support any of this stuff. That’s the bottom line here. Now I would be pissed if they said they would support an API and one day, out of the blue, they changed it without notifying developers.

    Also as soon as Google starts posting notice about changes they are now “supporting” that functionality. They just bought into a lot of overhead. That’s not a decision to be taken lightly.

    ..So I’m having a really hard time finding fault with Google on this one.

  14. I'm just thinking, I mean, what if they decide that they need to totally rework gmail and how it handles things? Like, they REALLY need to rip its guts out and make some major changes.

    Is its Google's perogative to sit down with GreaseMonkey developers and talk about what they can do to make the effects minimal? Heck no. As for minor changes, they shouldn't have to make an update about how they tweaked a div here or there or made a small javascript function change. That's serious work to track all of those changes and make announcements and stuff.

    I dunno, I just don't think it should be Google's job to make sure that the various hacks people develop keep working.

    Heck, maybe it would be a good idea to add official APIs for all the different Google Branded Services.

    PS: I think "zero legitimate reason" came off a little harsh. I just meant in terms of, do they have an actual responsibility to do this.

  15. Bill: “That’s hard to argue against. On the balance most of the feedback I got has been pushback and most of it made sense. Maybe I’ve been in the enterprise too long ;)”

    i think not. your objections are well founded, and absolutely have merit. i think it’s more a case that, on balance, the benefits outweigh the costs – particularly when you have a service provider willing to meet you halfway.

    in short, it’s not that your objections are misguided. it’s that the benefits haven’t been made clear enough 😉

  16. “in short, it’s not that your objections are misguided. it’s that the benefits haven’t been made clear enough ;)”

    There are nearly 600 user scripts on the wiki. There were none in January, and about 80 in March.

    This far outstrips FF extension creation (admittedly in a confined niche). Most of those scripts still work. I’m pretty confident that the popular ones all work.

    APIs would be great. But solutions, today, are good too. 🙂

  17. All this stuff is only a problem currently because people assume that websites aren’t platforms. With microformats and REST taking off there’s no reason that XHTML can’t be a programming language.

Leave a Reply to sogrady Cancel reply

Your email address will not be published. Required fields are marked *