General link concept

14 aastat tagasi • uuendaja 8 aastat tagasi • 7

Develop a general concept for handling links in notes that uniformly covers outbound web links, links to tags, internal links to notes etc.

==== Rationale ====

Currently there are several suggestions regarding links. They could probably be handled smoother by a single uniform concept. (Not talking about implementation here, but really about usability and enabling smooth work flows.)

==== Initial Thoughts ====

For ex. there is the need to keep links contained in clipped or pasted HTML. As these links contain both, a link target and an anchor text, CN would have to support formatted links. The obvious follow-up feature is to let a user enter links manually in the editor [1].

Another request is to support note interlinking. While this reminds of wiki-style interlinking, and even if I prefer a workflow that does not force me get my hands off the keyboard when I'm typing, having to enter something like "[some very long note title]" may not be the perfect work flow for CN, especially if default titles are kept when clipping stuff from the browser [2]. An intellisense-style dropdown in the editor, or "copy note link" / "paste note link" commands (with keyboard shortcuts) may be more appropriate.

Once there, the same concept could be applied to tag links. (Both, a drop-down and a "copy tag link" / "paste tag link" seem appropriate.)

OK, nuff thoughts. :-)

==== Footnotes ====

[1] The question is, how would the user enter such links? IMO, the usual link dialog with two fields (title, url)... sucks. It is much more convenient to enter something in wiki style like [see foo|http://example.com/foo] than go through a dialog. But, seeing the raw form of the link in the note would such, too. (A note with many links would be practically unreadable.) Coming up with a smooth concept here won't be easy, but well worth the intellectual efforts.

[2] When clipping a note from the browser, CN presets the title with the browser window title. That, unfortunately, is not only pretty longish, it also often contains some characters that you can't type on the keyboard. Example: "WordPress › Akismet « WordPress Plugins - Mozilla Firefox". Note the cute little "›" and "«" characters? Go find them on the keyboard. ;-)

Hääl

Vastused 7
Vanemad enne
- Uuemad enne
- Vanemad enne

14 aastat tagasi

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?

Vasta
|

14 aastat tagasi

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.

Vasta
|

14 aastat tagasi

> 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.

Vasta
|

14 aastat tagasi

> 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?