General link concept

Hackadelic, thanks for your message that raises very interesting questions. Yes, having a general concept for links would greatly enhance CN's usability.

[1] One thing is to keep in mind: I want to avoid at all costs splitting the note view into "viewing" and "editing" (Wiki-like syntax as I understand it requires this). There are two viable options: 1) requiring writing links explicitly or 2) providing a link editor (like in MS Word).

[2] Any suggestions here?

Hi Alex, glad you agree.

My main concern was to point out that even there are several request regarding different types of links, they should not be viewed as different features, but as one feature with different applications/facets.

As I see it, you already have separate "viewing" and "editing" modes, and there is nothing wrong with that. (I'm really happy with it, and I sure won't vote for in-place editing.) That does not mean though that you *have* to go with wiki syntax.

To my taste, Zim (http://zim-wiki.org/), combines both wiki-style and WYSIWYG input in a really impressive way. What they generally do is this: If you enter something in wiki syntax, like a star ('*') for bullet point, they automatically convert that to a bullet point *as you type*. But you only need to do that for the first bullet point. The editor adds bullet points upon enter just the way other WYSIWYG editors do. I think one can learn a lot about usability from Zim. (As I know there are WYSIWYG requests elsewhere, perhaps implementing them "the Zim way" would be great.)

However, when it comes to interlinking, CN does not lend itself well towards wiki-style. Different than wikis, in CN you won't go naming your notes like "SomeNote". Especially with the (really cool) clipping feature, I'd just keep the note title as it is, but it would be cumbersome to link to it that way.

I already mentioned two other ways of dealing with (internal) links: Copy/PasteLink, and auto-completion dropdown. Combining the latter with "the Zim way", the dropdown could show upon typing "[note:" or "[tag:", and auto-complete to "[note:<selected item>]" or "[tag:<selected item>]". A user setting could control whether the link text of internal links (say [note:foo]) is displayed as such, or automatically converted to just "foo" (possibly prefixed/suffixed with a cool little icon denoting the link type).

OK, that was just some quick brainstorming on this topic.

> you already have separate "viewing" and "editing" modes
I see it more as a "preview" and "read/edit" modes ;)

Thanks for the pointer to Zim, I'll definitely check it out. But I don't really see that there's real usability difference between converting asterisk-prefixed lines to list items and selecting all list items and pressing a shortcut like Ctrl+L. The latter is even more convenient if you really want to have a line that starts with an asterisk ;)

Auto-complete for [note: sounds interesting, but what it would look like? Just listing all note titles there is clearly not an option.

> I see it more as a "preview" and "read/edit" modes ;)
And what will be the difference there? Never mind. ;)

> But I don't really see that there's real usability difference between converting asterisk-prefixed lines to list items and selecting all list items and pressing a shortcut like Ctrl+L.

I understand that from a purely technical viewpoint there does not seem to be a big deal with either, but from a usability viewpoint there is a huge one. The first one (asterisk auto-converted to a bullet point) feels extremely natural. That's the way you would enter bullet points in pure text mode either. When you write on paper, you also enter a bullet point (or a dash) first, you don't write down all the lines and convert them later to bullet points. The "Zim way" (which BTW is also embraced by MS Word, OpenOffice and many others) preserves the natural flow of actions by interpreting and adapting to natural user input. Good user experience is created where the program adapts to the user, whereas your Ctrl+L alternative forces the user to adapt to the program and learn YET ANOTHER artificial shortcut. (How many shortcuts is a user able to memorize?)

The thing is, I can preach here whatever I want, usability can hardly be measured, or expressed in words, it must be experienced. You can come up with any logical argument about lines starting with '*' and whatnot, but user experience is not a matter of logic, but a matter of feeling. You can trust me on this.

BTW, lines starting with '*' are not a problem at all. Even if a human would want to start a sentence with '*' (other than intending a bullet point), he would just enter that in the most natural way:

* *some text

The program will, of course, only convert the *starting* asterisk to a bullet point.

Note also that - different than MS Word & co. - Zim adapts to user input immediately, not only after pressing ENTER. Immediate feedback also improves user experience (but only if it's unobtrusive).

You are right about the drop-down on "[note:" though. Just listing the note titles would probably be too little an information to choose from, because it would require carefully chosen titles, which not every note collection will have.

Let me also note that the drop-down content is not related to whether it is triggered by "[note:" or by hitting some keyboard shortcut. (In fact if you separate the trigger handling from the action you could flexibly implement both trigger policies. One trigger plugin for every taste, he :))

OK, I can probably imagine some good ways to accomplish the note selection for a link, but wouldn't sharing that make me at least a contributor of your project?