Matt Gemmell

TOLL is available now!

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

★★★★★ — Amazon

Conclusions about live URLs in editable text

interface 5 min read

I previously asked for opinions on how to handle live URLs in editable text, and received a lot of great feedback via email, iChat and comments here on the blog. I’ve thus decided on default behaviour, and also want to respond to a few of the suggestions made.

Edit, don't launch

The overwhelming consensus was that URLs in editable text should not be single-clickable. Consistency of behaviour and pervasive editability indicate that URLs should be treated as any other text, at least when clicking into one during an editing session. Indeed Eric Blair and others positively disliked apps where you have to click outside an URL and then keyboard-navigate into it for editing. My good friend Jimmy “the” Bisset agreed that some kind of modifier should be necessary to launch URLs.

Eric also pointed out an interesting fact about how Mailsmith 2 handles this situation: when editing text, the URLs are highlighted (coloured blue; since Mailsmith’s default message font is Monaco 9, it doesn’t underline URLs since the antialiased underline looks rather ugly on that font), but they are not single-clickable - instead, you must command-click, Internet Config-style, to launch them. When viewing non-editable text, however (such as a received or sent message), URLs are single-clickable to launch.

What really interested me is that I didn’t know that! I’ve been playing with Mailsmith 2 since it was released, and until Eric pointed it out, I never once realised that those blue URLs in editable text weren’t live. You may argue that having URLs single-clickable in one context, and not in another, isn’t consistent - but clearly my expectations were never violated by Mailsmith’s behaviour. I find that very interesting indeed. Either I never re-edit URLs in text, or when I’m editing text and I click into an URL, I absolutely do not expect it to be launched.

Contextual menu

Steven Canfield suggested that it should be possible to control-click an URL to launch it (this is actually built-in behaviour for an NSTextView, which is handy), or perhaps to edit it in a “floating” field-editor. I dislike the idea of requiring a separate editing context for some of the text in a document, so my assumption is that Steven was suggesting this as a way to edit the actual URL itself, rather than whatever text is linked to that URL. This is a separate issue, and a good idea to consider for implementation. I like the concept of popping up a floating field-editor to edit an URL for some linked text, rather than just using the ubiquitous sheet. Width of the field is a potential UI issue, but we’ll leave that until another time.

Dual-state behaviour

Someone called “Argh128” agreed with the idea of using a contextual menu to launch an URL, but also suggested the alternative of showing a clickable “launch button” graphic of some kind when rolling-over the URL. Interesting idea, which could be useful in certain types of applications. What struck me even more, however, was his/her third point:

One other idea, is have a switch you can toggle once the data is finished being entered. (Maybe specified when the file is saved.. kind of like read only) In a standard document you first start writing out and organizing your URLs, and then eventually you would probably want to click on URLs more then editing them. So if you have a toolbar icon to specify the behaviour you can easily toggle back and forth between modes. This is also probably a bad idea. To many toolbar icons and its not very consistent.

Respectfully, you’re too modest! That’s actual a very good idea. Lots of applications have the ability to toggle state in this way, and indeed specifically from “locked” to “unlocked”. Page-layout apps are the classic example, but even TextEdit and the venerable BBEdit allow you to toggle editability. And, as previously mentioned, Mailsmith’s rather intuitive dual-behaviour follows this model. Editable text requires a modifier to launch URLs, whereas URLs are live in text which isn’t editable.


Now we come to a UI convention which is very dear to many of you, and which is derived from web browsers: the ability to click and hold for a few moments in order to automatically trigger a certain behaviour - commonly a contextual menu acting on the clicked URL or page. Eric Wang has been giving some thought to this whole issue lately too, and one of his ideas is to only launch clicked URLs after a requisite delay during which the mouse button must be held down. The one issue I have with that is that it introduces a sense of hurry to the user; I often click somewhere and just hold there for a moment, deciding what to do. I wouldn’t like to feel that I have to keep my hand away from the mouse until I’ve decided what to do, so I don’t accidentally launch an URL. You could certainly take the idea to its Steve Jobs-style extreme, and start a little semi-transparent visual countdown timer beside your pointer whenever you click and hold, but we’ll leave that as an exercise for the reader.

Click-hold to pop a contextual menu, however, is well-established - and missed by many in Safari, including Alexis Drogoul. Alexis advocates using a click-hold approach to allow launching of URLs, probably via a contextual menu. The question is, do you only allow click-hold popping of menus when you’re over an URL, or everywhere? That’s another question entirely, but it would seem to me that you’d really have to allow it everywhere, for the sake of consistency.


A few people, including Alexis and Jon, suggested using double-clicking to launch URLs, with single-clicking behaving as normal (Alexis mentions that Eudora does takes this approach). I’d say that this is my second-favourite method so far, after the idea of command-clicking. The reason that I’m slightly wary about double-clicking is that it’s already an established way of selecting a whole word, and with the addition of a third click it allows selecting of the current line. I wouldn’t want to override this potentially-common shortcut without at least giving the option for the user to reclaim it.

Alexis also points out that requiring a double-click to launch URLs could become confusing if you’re constantly switching back and forth between your editor and a browser; this is a fair point, but since all browsers I know of will forgive double-clicking, it’s not a big concern. Pierre Igot isn’t quite so forgiving, talking of the “global fight” against people who double-click URLs, but even he concedes that it’s a valid approach!


Thanks to everyone for all their thoughts and suggestions; every contribution is very much appreciated. Hopefully I’m giving something back to the community by continuing to post on issues like this, offering my own thoughts, and consolidating everyone’s opinions for future reference. Here’s my own interpretation of what’s been said, and how I’m going to proceed when implementing hURLer within larger applications.

Default behaviour

  • When text is editable, URLs require command-click to launch. URLs can also be launched by choosing the Open Link option from a contextual menu.
  • When text is not editable, URLs can be launched by single-clicking. Command-clicking will also still launch URLs, for consistency.

Configurable options

  • A choice of one of the following (mutually exclusive, radio-button) options:
    • Launch URLs when clicked
    • Launch URLs when double-clicked
    • Launch URLs when command-clicked (default)
  • An optional (checkbox) choice: Make URLs single-clickable when text is not editable. This would be disabled if launching URLs on single-click was chosen.

Possible additional cosmetic options would likely include the colour of URLs, whether or not they should be underlined, and perhaps whether to apply this styling when text is editable (it would presumably always be applied otherwise).

So there you have it. Any further comments are always welcome, and thanks once again for all the feedback so far. Now, about those metal windows…