Articles Posted During March 2005

Fixing BBEdit's Prev/Next problem

BBEdit 8.1 is out, featuring Subversion integration. Unfortunately, this new release also makes a seemingly minor change to two of my most commonly-used commands:

The Next/Previous document commands now work in MRU (most recently used) order. When closing a document, you will be taken to the most recently used document (previously you were taken to the next document in the list in the Documents Drawer).

This provides a user experience identical to that with documents in separate windows (where window z-order provided the MRU-like behavior).

UI consistency is generally a good thing, but not this time. Because the document list is sorted alphabetically, these commands sometimes hop around the list erratically, basically rendering them useless. Once this behavior was explained to me by Bare Bones Support, I gave it a whirl in an existing window, which had seven open documents.

To my dismay, I had to issue seven commands just to move from the current document to the one directly preceding it in the list. (I actually selected the desired doc on the fifth keystroke, but missed it & had to back up one.)

When I explained this to the fine folks at Bare Bones, and requested they revert to the previous model, they replied with a quick & easy solution:

There is a preference option not currently presented in the UI which you can set to control this behavior. You can adjust this option by issuing the following command in the Terminal (all on one line):

defaults write com.barebones.bbedit
MultiDocumentWindows:SurfNextPreviousInDrawerOrder -bool YES

If you set it to "YES", the Previous/Next Document commands will use the display ordering of documents; if you set it to "NO", they will select documents in most-recently-used order as currently.

No word as to whether this will be the case for future releases, but I just thought I'd share, in case anybody else is frustrated by this little 'gotcha'.

2005-03-31 02:11:19

Cross-domain XMLHttpRequest via Greasemonkey

Jeremy Dunck points out that Aaron Boodman has posted a patch to the Greasemonkey mailing list which allows the XMLHttpRequest object to reach across domains. The sample script simply displays information from Technorati about the current URL, which isn't necessarily useful or interesting, but works well as a proof of concept.

Obviously, this raises serious security concerns regarding cross-site scripting, and rightfully so. Regarding user scripts in general, Aaron says:

I think people should be careful which userscripts they install on their computer. If they aren't javascript-literate, maybe they should hold off until there is a community rating system in place.

That pretty much sums up my feelings, and applies to favelets as well – especially those that insert SCRIPT elements into the current document, which is, after all, XSS in action. Adding server-side scripts to the mix certainly complicates matters, but I'm too excited about the cool things that might be possible to worry about all that security nonsense right now.

2005-03-28 15:03:13

Opening Safari's Current URL with Firefox

Firefox rocks. It honors most CSS, has great DOM support, and offers unrivaled development tools. For a guy in my line of work, it's indispensable.

Unfortunately, I just don't like it.

That's partly due to the fact that it disregards many of the Mac keyboard conventions I've been conditioned to use over many years. Some of it is the UI. But, the biggest issue is the fact that I just don't like the way it feels.

(Anybody who spends 60+ hours per week in front of a computer probably knows exactly what I mean, but others can hopefully come up with an appropriate metaphor involving an automobile or something.)

At the moment, my browser of choice is Safari. Now, don't get me wrong, I could draw up a list of its shortcomings as quickly as anybody, but, overall, I like it better than the alternatives. So, that's what I use to retrieve & view documents from the Web. However, I often have occassion to hop on over to Firefox to do something with a given document. That's a PITA, which goes something like this:

1. Tab to Safari's address bar.
2. Command-C to copy the current URL.
3. Command-Tab a few times to activate Firefox.
4. Tab to Firefox's address bar.
5. Command-T to open a new tab.
6. Command-V to paste the URL.
7. Enter.

Granted, that all takes me about five seconds1, but it gets old. Enough so that I've tried to force myself to just use Firefox. I gave it a week.

I poked around Google for a way to automatically open Safari's current URL in Firefox, but couldn't find anything. So, I put together an AppleScript to deal with it:

tell application "Safari"
    set thisPage to do JavaScript ¬
        "document.URL" in document 1
end tell
tell application "Firefox"
    activate
    Get URL thisPage
end tell

If you're running Safari, you can automatically load it in your Script Editor.

I've named mine 2f.scpt, simply to distinguish it somewhat, making it easier to launch with Quicksilver. Ideally, I'd be able to launch this with a single keystroke, but this works.

I fully expect there's a better way to do this, so feel free to tell me all about it.

1. Yes, I just timed myself.

2005-03-23 16:23:51

Obligatory SXSW Post

Here's where I mention that I'll be heading to SXSW in a few days, and wonder aloud if any of you will be there. That is all.

2005-03-08 23:20:16

XMLHttpRequest as a Usability Tool

There's been a lot of buzz (including the requisite buzzwords) lately about XMLHttpRequest, and its impact on web-based application development. Clearly, this is a Big Deal, and we'll undoubtedly see some really slick innovations in the coming months, but there's one aspect of this new paradigm that I've not seen discussed: its potential use in ongoing usability studies involving live applications.

I was chatting with Steve earlier, and he's reworking client-side form validation for new user signups at his company to use XMLHttpRequest, instead of serving up 16K of rules in a JavaScript file to every user. When I asked for a guesstimate as to how much data transfer that might save, he commented that they really have no idea how many errors get caught by the current system, so there's no way of knowing how much of that 16K gets used.

But it occurs to me that they'll be able to track that number pretty easily now, and analyzing that data might very well give some insight as to what their users are actually doing as they interact with the HTML forms. Needless to say, this information could be a huge benefit in streamlining their process, allowing them to see what real users are doing in their browsers, in real-time. No amount of focus groups or hallway testing can give us this level of understanding as to what actually happens "in the wild", and I think there could be some interesting, unexpected results from something like this.

2005-03-06 13:34:21