Matt Gemmell

TOLL is available now!

An action-thriller novel — book 2 in the KESTREL series.

★★★★★ — Amazon

Dealing with live URLs in editable text

interface 2 min read

As I mentioned earlier, I’ve been working on auto-detection and linking of various kinds of URLs in a textview, as you type. The implementation seems very robust at this stage, readily dealing with the vast bulk of the tests I’ve thrown at it, including a copy-paste of several hundred lines of my referrer logs for Irate Scotsman.

Now I come to the easier part: implementing proper URL-clicking behaviour (pointing-hand cursor, colour-changing, preservation of the previous selection and so forth; NSTextView already handles the actual launching of the URLs). The thing is, I’m in a bit of a UI quandry as to how the textview should actually behave.

I’m fairly certain, at least, that clicking a live URL should not alter the selection in the textview; i.e. it should not do what NSTextView does by default, and place the insertion-point into the URL where you clicked whilst it launches the URL in an appropriate application. I find that ugly. However, this begs the question: what if the user wants to click into the URL to edit it? Which in turn begs the question: should URLs in editable text be “live” (i.e. single-clickable to launch, without modifiers) at all?

Fiona feels that URLs should not be live until a modifier is present, such as the command key. This brings back memories of OS 9 for me, and seems clunky for OS X. All the same, I can certainly understand that it would be annoying to have to keep fending-off Safari windows or whatever whilst trying to fix a typo. God knows I’ve growled at it enough times whilst testing hURLer.

The thing is, testing the engine is a highly artificial situation - a real user will be typing (or pasting, or dragging) an URL or email address and moving on; they won’t be typing endless URLs all over the place, and tweaking them to perfection to catch all kinds of nasty edge-cases. Does the usefulness (and all-important enjoyment/empowerment factor) of being able to type URLs and have them automatically linked, then be able to just click them, outweigh the occasional inconvenience of having to keyboard-navigate into an URL to edit it? I think it does. And we can always let them use a modifier to prevent launching the URL when they click on it, and just place the insertion-point instead.

All the same, I’m very open to feedback. Should URLs in an editable textview be launchable via a single-click, or should a modifier be required? And please don’t say “make it an option”, because even then I have to decide on an initial default behaviour. I can see both sides. On the one hand, not being able to click into certain pieces of text to edit them is inconsistent, but live URLs are very familiar and are convenient and useful. On the other hand, making all text behave the same with respect to clicking into it (placing the insertion-point) is consistent and familiar, but requiring a modifier to launch URLs is as inconvenient as having to use a contextual menu. After all, if you’re typing something that includes an URL, aren’t you (at least reasonably often) going to want the ability to easily launch that URL, without a copy-paste or a trip to the Services menu?

As a side-note, I’ve been planning for a while to expand our contracting services to cover something I call “UI valeting”; basically the design, critique and refinement of software user interfaces for Mac OS X applications. As evidenced in posts such as this one, I really sweat over issues like this. Usability and consistency are so incredibly important, and attaining the Holy Grail of interface transparency is something that has always fascinated me. I’m an engineer at heart - no question - but I genuinely care a lot about UI.

After all, your software is crap by definition if no-one wants to use it.