In response to my item on media hacking the other day, this comment alerted me to a really sweet bookmarklet that adds a slider to a Flash movie. You don’t get timecodes but you do get start/pause/scrub which is a tremendous benefit.
When I tried it out, on both Firefox and IE, I was reminded again about the relative inaccessibility of bookmarklets in recent versions of IE. In Firefox it’s a drag-and-drop to the linkbar, and even that procedure eludes most people. In IE it’s a much more complicated dance which I illustrated in my Bookmarklets 101 screencast.
Because I now aim to improve digital literacy as broadly as I can, I’ll be focusing more than I have in the past on the browser that most people still use, which is IE. Here I’d like to toss out a couple of points for discussion and follow-up.
It’s understandable that bookmarklets, which are JavaScript snippets that run in the context of web pages, would be locked down in a browser that’s busily rehabilitating its security reputation. But typically they’re not really locked down, just inconveniently accessible. Suppose you want to encourage your people to use these kinds of productivity aids. What does the domain policy look like for doing that?
What’s the deal nowadays? At one time I heard about Trixie but not so much lately. I’ll revisit it myself, but I’m curious to hear reports on Trixie’s compatibility with Greasemonkey userscripts, its rate of adoption, and its security model.
IE would have to be a browser that people still use for primary web development for there to be a Greasemonkey, Web Developer Toolbar, or Firebug.
Jon, somewhat off topic, but it’s related, important, and maybe you can help.
You are probably aware of this, but there is a tremendous amount of bad will from the development community towards the IE browser and the IE team. The IE team is making an effort to reach out to the development community via the IE blog, but there’s still a lot of ill will because it seems that many times the IE blog addresses symptoms rather than underlying problems (I wrote a post with more depth on this if you’re interested: http://billhiggins.us/weblog/2007/01/04/ie-team-addressing-the-symptoms/ ).
Most every web developer I talk to wishes that IE’s badness would catch up with it and its marketshare would shrink to a degree that developers could stop supporting it. This, of course, is wishful thinking, but it demonstrates the bad will towards IE.
Anything you can do to help the IE team become more transparent about what they’re doing to address the serious technical issues and standards non-compliance issues that IE presents to developers would be very welcome.
“IE would have to be a browser that people still use for primary web development for there to be a Greasemonkey, Web Developer Toolbar, or Firebug.”
I agree with the latter two, but I do not regard Greasemonkey as a developer tool, I regard it as bookmarklets on steroids, a way to deliver enhanced web experiences.
The Greasemonkey version of LibraryLookup is a nice example of an enhanced experience. So far I’ve allowed it to languish because it’s really only for a subset (Greasemonkey users) of a subset (Firefox users). But I no longer wish to settle for those restrictions. If it’s a useful service in its own right, as well as a way I can raise awareness of the value of client-side page rewriting, then I owe it to myself and to others to broaden its appeal.
“Anything you can do to help the IE team become more transparent about what they’re doing to address the serious technical issues and standards non-compliance issues that IE presents to developers would be very welcome.”
I will absolutely be looking for ways to move that conversation forward. There are a number of bridges that need to be built, and I’m deadly serious about wanting to help build them.
“I will absolutely be looking for ways to move that conversation forward. There are a number of bridges that need to be built, and I’m deadly serious about wanting to help build them.”
Looking forward to this. I’ll be monitoring your blog for opportunities to provide constructive input and feedback.
I’m looking forward to any reports and insights about user scripting in IE.
Not specifically IE related, but Opera, to the best of my knowledge (I have a few friends in their development team, and visited on a job interview last year, when considering changing their directions on that front), still do not treat user scripting as an applications programming domain, but rather (as it was initially implemented to be) a client side kludge to fix web site brokenness. They give it UI convenience in direct proportion to that too. (A directory preference setting four menu actions deep, and manually dropping scripts in that directory to install or update them.)
Any inside efforts of yours at bending the IE team’s intentions for user scripting our way would be great achievements, and warmly welcome.
I would say user script land today is, in maturity and standardization, where bookmarklets multiplied with the pre-W3C web were in the late nineties. A messy at best programming domain with a lot of cross browser compatibility issues, awaiting standardizations efforts, as vendors each pull in their own random directions. (But doing something about that might be a bit out of scope, for now. Still charting the territory, after all.)
“What does the domain policy look like for doing that?”
I don’t know. What do you mean when you say ‘domain policy’ exactly?
Jon, a very late follow-up on the topic of transparency. Alex Russell, the project lead of the Dojo Ajax framework, wrote a thoughtful post on why he thinks the IE project needs to be more transparent w/r/t the future of the IE browser:
http://alex.dojotoolkit.org/?p=620