Greasing Greasemonkey Scripts

Tweaking a Greasemonkey script is easy. It’s just a single file, so you download the file locally, edit it, and install it the same way you’d install any other script.

I did this because I needed a quick fix for the super-helpful XMLHttpRequest Debugging script. Sometimes the console has a little trouble with positioning – using it with Google Maps caused it to sit behind the upper portion of the page due to layering. So I made two quick fixes – increased the z-index in the embedded stylesheet so it would appear in front and also changed the default coordinates (I’d adjusted them with “about:config”, but somehow that wasn’t picked up.)

All in all, I was able to tweak the script, not knowing anything about the GM API, and have it running in my browser in about 10 minutes. Had it been a standard Firefox extension, I would have been out of luck. I’d presumably have to download the original source, set up a dev/testing environment, and be able to package it all up including meta-info. Furthermore, I’d have to restart Firefox to test it, unlike Greasemonkey which works straight away. I’ve never tried all that with extensions, but that’s my perception from a little looking around.

I’m nowhere near as bullish as some about Greasemonkey, at least in the medium-term, as some people, because I think the whole Firefox extension mechanism is way too complex for most end-users, let alone the idea that you have to install Greasemonkey scripts on top of one of those extensions. But in any event, once you have the Greasemonkey extenstion installed, it’s a cinch to remould a script you come across.

The Ajax Desktop

I know. “The Ajax Desktop” sounds like I’m taking things just a bit too far. But I wanted to point out that people are experimenting with things you’d associate more with the web.

To wit:

  • Protopage:I was triggered to write this after discovering an awesome new Ajaxian app: Protopage (via FloatingSun). It’s essentially a start page, similar to the portal efforts. However, it feels more like your desktop, with configurable background, colour schemes, and sticky notes. One really nice feature is an “Add to Protopage” link for website owners – an update of the old “Bookmark This Page!” (Does delicious have this?). Some patterns here include:
    • Lazy Registration Register all you want, but the homepage really comes down to a unique URL, which is established immediately.
    • Drag-And-Drop Another desktop-like feature.
    • Popup For configuration.
  • Ajaxian Screensaver: A post on creating an Ajaxian Screensaver. I made a comment in the Ajaxian Blog posting that linked to it about the possibility of a SETI webapp. Mostly tongue-in-cheek, but I can see it happening. It would be trivial to create (and critics might say it would be sufficiently slow to make a trivial contribution too).
  • JSCalc: A calculator bookmarklet.

How far can it go? All we need now is a web-based splash-screen. Oh, wait!

Full-Text for Widgets

The other day, I noted the Ajax Patterns widgets have been broken down into content, form, and page architecture. The patterns for those are now complete. Give me yellow! Yellow is the colour for full-text descriptions, and the bottom of the page is starting to look a nice shade of yellow.

There are full summaries for each pattern on the homepage too. So the upshot is there’s a description for each of these:

Content Widgets

  • Drilldown To let the user locate an item within a hierarchy, provide a dynamic drilldown.
  • Microcontent Compose the page of “Microcontent” blocks – small chunks of content that can be edited in-page.
  • Microlink Provide Microlinks that open up new content on the existing page rather than loading a new page.
  • Popup Support quick tasks and lookups with transient Popups, blocks of content that appear “in front of” the standard content.
  • Portlet Introduce “Portlets” – isolated blocks of content with independent conversational state.

Form Widgets

  • Live Command-Line In command-line interfaces, monitor the command being composed and dynamically modifying the interface to support the interaction.
  • Live Form Validate and modify a form throughout the entire interaction, instead of waiting for an explicit submission.
  • Live Search As the user refines their search query, continuously show all valid results.
  • Query-Report Table Report on some data in a table, and support common querying functions.
  • Slider Provide a Slider to let the user choose a value within a range.
  • Suggestion Suggest words or phrases which are likely to complete what the user’s typing.

Page Architecture

  • Drag-And-Drop Provide a drag-and-drop mechanism to let users directly rearrange elements around the page.
  • Sprite Augment the display with “sprites”: small, flexible, blocks of content.
  • Status Area Include a read-only status area to report on current and past activity.
  • Virtual Workspace Provide a browser-side view into a server-side workspace, allowing users to navigate the entire workspace as if it were held locally.

Ajax: From Tipping Point to Koolaid Point

Kathy Sierra explains a variation of the “Tipping Point”:

The Koolaid Point: A Threshold at which enough users become so passionate that others accuse them of “drinking the koolaid”. Often fueled by commercial success.

Kathy makes a great point: passion doesn’t mean happiness – people can be passionately opposed too.

Nice to see how universal this phenomenon is – Ajax isn’t listed, but the backlash has certainly begun. HTML Matters (presumably a joke on “AjaxMatters“) is doing a great job at becoming the poster-child for the counter-revolution. It’s not surprising. When the original Design Patterns book came out, people derided it on the basis that they’d already used those patterns, so there’s nothing new! Ajax is a pattern, and people either don’t see the point (perhaps because they’ve never seen Google Maps in action), feel that Javascript is such a scarce resource and – though it’s almost been around for a decade – we shouldn’t rely on browser support. And some are just resentful that latecomers are jumping aboard when they’ve been doing it all along (the same bizzare attitude of people who yearn for the days of pre-web internet).

Anyway, I’m pleased for Ajax Patterns to link to any of those sites, and it’s for that reason I included the “Ajax Achilles Heel” article when I first created that page. At one point, someone deleted it, with best intentions I presume, but I quickly restored it. It’s good to have sites like this to keep things in check. And, though I didn’t think about it that way before, it’s proof that Ajax has hit Koolaid Point.


Asides on the Koolaid Terminology:

  • Where I’m from, the Koolaid Point would be called the Tall Poppy Syndrome.
  • Some labels for the transition points of the traditional product life cycle:
    • Tipping Point: Introduction->Growth
    • Koolaid Point: Growth->Maturity
    • Jump-The-Shark Point: Maturity->Decline
  • The Creating Passionate Users blog is awesome. If and when a book comes out, its popularity will extend well beyond the software community.

Meta-Search with Ajax

I just discovered a new feed meta-search: TalkDigger (via Data Mining). It’s Ajax search all the way (buzzword overload!).

The site shows how ideal Ajax is for meta-search. Each time you enter a query, the browser fires off multiple queries – one for each engine it searches. That means the results all come back in parallel – no bottlenecks.

Back in the day, metacrawler and others were smart enough to start writing out the page straightaway, so users start seeing some results while others are still pending. The Ajax meta-search improves on the situation by directly morphing the result panels, so the page structure remains fixed even as all the results are populated. Each panel gets its own Progress Indicator.

This is an example of Multi-Stage Download – set up a few empty blocks and populate them with separate queries. When I initially created the pattern, it was pure speculation, but TalkDigger now makes the third real example I know of. I recently created a Multi-Stage Download Demo.

Another nice feature of TalkDigger, which fits well with meta-search, is the use of Microlinks: You can click on the results to immediately expand out a summary.

There’s some more features I’m hoping to see:

  • The results page definitely needs work – it’s nice seeing a brief summary of all results and having them expandable, but it’s difficult to get an overall feel. An “Expand All” would help, or showing at least one posting for each search engine.
  • The results are broken up by an ad. To me, that’s counter-productive as they look like two separate panels. I think most users will mentally filter out the ad anyway and just see the results as broken into two.
  • [Sortable columns](http://ajaxpatterns.org/Query-Report Table] – so I could sort by engine name or feed count.
  • Unique URLs Unique URLs are critical for a search engine. Unique URL Demo. Jon Udell mentioned the issue recently, regarding MSN Virtual Earth, Google Maps, and others’ lack thereof. This demo, based on Mike Stenhouse’s ideas shows it’s actually fairly straightforward to emulate standard URLs.

Ajax Frameworks – JS, Server-Side, or Both

Jason Salas is a blogger-podcaster who’s been writing a lot of good stuff about Ajax lately. He notes the new ComfortASP .Net abstracts away the DHTML/JS so you can do everything server-side. The new Ajax JSP Taglib does that too. The idea’s been used previously with libraries like the struts validation module. Custom libraries are also useful – in the past I’ve hand-coded JSP taglibs to provide better user feedback in the browser, but prevent Java programmers from having to deal with the JS.

So of the Ajax Frameworks out there, there’s a fairly common theme: either libraries let you code everything in Java/.Net/etc, or they are pure DHTML/JS or sometimes both.

Two reactions:

  • In aggressive dotcom markets, the pure abstraction libraries won’t work. In mainstream intranet apps, they will be a big thing. There are already a lot of smart JS developers and many more coming on. Where Ruby is riding the Rails train, JS is surfing the Ajax wave (I know JS and Ajax are essentially the same technology, but it sounded cool. More accurately, JS is benefiting from the Ajax branding.) So you have the new JSAN project, all the stuff coming out of Scriptaculous and DOJO and Rico. And then you have talented guys like Jon Tiersen applying their Java/Agile expertise to improve JS tooling. So overall, you will be able to do a lot more with JS than pure abstraction. Market forces dictate that public dotcoms will be forced to work directly on the browser-side in order to keep their edge. However, in the other world of internal projects, where satisficing – doing enough to just get by – is the logical mode of development, these libraries will be superb. For typical intranet apps, the incremental benefit of hand-coding JS often isn’t there – there’s not enough users and it’s often more cost-effective to train users to work around problems. Very different story from dotcoms.
  • I’d like to see these pure server-side libraries offer some pluggable behaviour, to let users customise lots of browser-side appearance and behaviour if they want to. Provide sensible defaults so users can write pure server-side code, but let them tweak it later on. So, in the browser-side, you should be able to plug in new appearances, new event handlers, maybe even event interceptors. I understand Naked Objects is headed in that direction – it will autogenerate all GUI code from the domain model, but you can then hand-code a particular object’s look-and-feel if so desired. To me, that’s the key to a good framework: strong flexibility (but only where it matters), combined with sensible defaults.

Ajax Patterns: Widgets broken down

For a long time, the Ajax Patterns had a big section of widgets, about 15 in all. This week, I’ve been working on full-text versions and they’ll be finished on the weekend. Writing the low-level details helped crystallise some of the relationships for me, and I’ve been able to break those widgets into three groups, which makes a bit more sense now.

So now the structure is this:

  • Content Widgets
  • Form Widgets
  • Page Architecture, which will be renamed, it sounds too grandiose and overarching at the moment, whereas it’s really just more patterns at the same level as above.

Here’s what they contain – see the ajaxpatterns homepage for up-to-date info. (Excuse the cut-and-paste job).

Content Widgets

  • Drilldown See http://betfair.com sidebar.
  • Microcontent Compose the page of “Microcontent” blocks – small chunks of content that can be edited in-page.
  • MicrolinkProvide Microlinks that open up new content on the existing page rather than loading a new page.
  • Popup Support quick tasks and lookups with transient Popups, blocks of content that appear “in front of” the standard content.
  • Portlet Introduce “Portlets” – isolated blocks of content with independent conversational state.
[]

Form Widgets

[]

Page Architecture

Spying on Users With XMLHttpRequest

Earl Castledine points out the allegedly dark side of XMLHttpRequest: spying on users (thanks Ajaxian). It seems that this capability will cause it to “likely fall from grace”! (I mentioned the issue a little while ago regarding the Heartbeat pattern).

Two examples are given in the new article:

you write an e-mail to Apple support that says: “I just bought a brand new iPod. I dropped it down a set of stairs. It stopped working.” You then decide to delete the second sentence to help your cause. TOO LATE! If the site uses AJAX, your response may already have been zapped to the complaint desk in the sky!

I agree this could actually happen. The live chat/wiki demo, for example, is based on a Fat Client model, where the browser essentially runs a full app and periodically synchronises with the server, during which time intermediate info is logged. HOWEVER, even if the Apple support guy had access to the data, and felt like poring through every partial text at 5-second intervals, and the user was unlucky enough to have submitted the guilty message, I doubt it would hold up because you can sync all you like, but the user can’t be held responsible for what they wrote until they’ve acknowledged the message is done. This legal motivation is one reason why you’ll always see Explicit Submission in some Ajax apps, even though Submission Throttling renders it unnecessary from a technical perspective.

The second example:

Or — a little more malevolently — consider this: most people have one or two username/password combinations that they use for all of their “unimportant” sites such as news sites, blogs, and forums. They probably also have a few reserved for use on more sensitive sites — banking, Web mail and work accounts. It’s a very common and easy mistake to begin typing incorrect login details for a given page. Force of habit is responsible, but people usually realize what they’ve done before hitting the submit button.

I suppose it’s possible once again, but since there’s a concrete example to go by, I’m going to take this one literally too. The problem here could just as easily occur in a traditional app – I’m sure users frequently submit the wrong user/password too. That would actually be more dangerous than just periodically capturing what the user’s typing, because how do you know when they’re finished. Even when someone does capture such information, they still have to start guessing where it applies. Also, if users only have one or two combinations, they’re pretty likely to type in the same password anyway, ne? So what’s the devious webmaster getting at that they couldn’t get at before?

The thing is, you could have captured all this information before. Here’s how you do it the new way, with XMLHttpRequest:

  • Every few seconds, post the current browser state to the server.

Here’s how you do it with standard forms:

  • Every few seconds, push the state onto an array.
  • When the user eventually submits a form, upload a string representation the array. Note both of the examples above involve submitting a form eventually, and note that even an external hyperlink can easily be scripted to force a form submission. It’s a little more work, but it was always feasible.

Admittedly, one difference is that XMLHttpRequest provides some cover for malicious activity, because periodic submission is standard practice, whereas periodically submitting history is just a little suspect.

While this sort of stuff is mostly FUD, Ajax does bring out the common tension between usability, security, and privacy. The Heartbeat pattern, for instance, involves monitoring page events to see if the user’s active. Definite security benefit, definite benefit for resource conservation, but also a definite increase of personal monitoring.

In any event, users need to be aware the security model of the web is that whatever basic actions they perform on the page are open to the operator of that site. XMLHttpRequest may play a small part, but it won’t be falling from grace anytime soon.