(Archived) Thoughts on Links vs URI

[lanceweber 0]

Recent premium subscriber, hacker, GTDer, first time caller...

I set out this morning to figure out how to do some deep URI type linking between EN and my other tools and quickly found all the threads clamoring for note level URI's and the intrinsic difficulties this poses in EN's architecture. I'd like to braindump my thinking on this so I can get it out of my head and move on

Power users are asking for several things:

1) The ability to create EN specific URL's, ala http://joeuser.evernote.com/mynotebook/note?=1234

2) OS level integration of EN as a local URL application launcher, ala evernote://mynotebook/note?=1234

3) The ability to combine 1 & 2

EN's response, if I understand it correctly, is that while either 1 or 2 are do-able, creating a seamless, consumer friendly implementation of 1, 2 and 3 is extremely problematic.

Assuming (yeah, I know) the above conclusions are mostly accurate, I have a couple of brainstorming ideas, apologies if this has already be well trampled:

Implementation of a local application launcher URL for EN can (ie, should) be considered separately from the implementation of URI's for notes. Why? Because then you can incrementally add features that are URL based that don't rely on URI's. For example, if EN had local app URL support and then implemented search by URL, I'd be a pretty happy camper compared to what's available today:

evernote://search?notebook=mynotebook?match=any?tags=gtd

Globally unique note URL's could be considered as an optional EN attribute that have no relation to the note's GUID. Additionally, they could be considered a user level feature, not a systemically managed feature. With this implementation, if you wanted your note to have a fixed URL, you would have to specifically create/enable the URL by editing the note's attributes, just like you do with tags, title. If the note was only stored locally, then you'd get a 404 from anywhere else you tried to access it. I think this would solve the backwards compatibility, global sync and link management issues EN has described.

Anyway, my .02 - thanks for listening!

Lance Weber

[gclabbe 0]

Well said, Lance.

I'm in the same boat ... pulled the trigger on premium for EN 'cause it's awesome ...

Here's what I want to do (and this could apply to lots of other GTD or project management systems):

• 
  Use OmniFocus to track a shell for a project that I'm working on
  Schedule my tasks in this project in OF when they are in a reasonable time scope of needing to be done
  Take notes attached to the project to cover scope, overview, rough schedule, task queue
  Take notes attached to the work and completion of tasks
  

I will then create a bucket in EN that relates to this project. And create all of the above notes, schedules, etc as items in EN.

Linking these created items back to OF (which can handle links now) would be incredibly powerful.

It's really important that the workflow for my task management requires as little multi-application os-location overhead as possible. So without URI linking at least, I'll have to look for alternate solutions to capture the "stream of consciousness" elements that occur as I review projects, work on projects, work on tasks, etc.

Chris

[Don Reba 32]

Globally unique note URL's could be considered as an optional EN attribute that have no relation to the note's GUID. Additionally, they could be considered a user level feature, not a systemically managed feature. With this implementation, if you wanted your note to have a fixed URL, you would have to specifically create/enable the URL by editing the note's attributes, just like you do with tags, title. If the note was only stored locally, then you'd get a 404 from anywhere else you tried to access it. I think this would solve the backwards compatibility, global sync and link management issues EN has described.

What is the problem with using note GUIDs? OS-level integration sounds like something I could easily implement in my own client in a day or two.

[lanceweber 0]

Per http://forum.evernote.com/phpbb/viewtopic.php?f=30&t=12465&p=65019&hilit=uri#p55835

Notes don't have GUIDs before they are synchronized to the service, and we don't want to have a UI that mysteriously prevents you from copying a link before synchronizing.

Local notes don't have GUIDs, same thing.

If you move a note from a synchronized notebook to a Local notebook and then back to a Synchronized notebook, the service will see it as a new note, with a new GUID. But you (as the user of that machine) would expect that the link to that note would continue to work.

So we need something more robust so that your links work across synchronizations and whatnot for years.

[Don Reba 32]

Ok, that makes sense. Your solution seems like the obvious way to do it, having none of the compatibility or sync problems Dave listed.