Note usage through ~all apps

[sunjam]

Inspired by this tag request, I'd like the ability to add notes to absolutely any app in Nextcloud. Noticed this request on admin notes, but it can make sense to add notes on absolutely anything. Sure, we have markdown descriptions in some apps, but it makes sense to add notes about absolutely any particular element in any app, regardless of whether a task is required.

Other issues that could relate:

• Add tags to notes
• Integrated Text with Nextcloud Notes
• Workflow support in Nextcloud Notes as announced in Nextcloud 18 as Flow via this Pull Request
• Store and Edit Bookmark markdown Descriptions from Notes app
• Store Nextcloud Contact notes in Notes app

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/81382438-note-usage-through-all-apps?utm_campaign=plugin&utm_content=tracker%2F46751022&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F46751022&utm_medium=issues&utm_source=github).

[korelstar]

That's an interesting idea, I like it!

I wrote some thoughts down on how to implement this for contact's notes. I think the approaches would be similar for the general case:

use existing attribute field in contact

Currently, the notes app uses files in order to save notes. This has to be extended by another storage-backend for notes in a contact. Such notes could be shown in a special category (e.g. "Contacts"). Creating notes in that category from the notes app can't be possible due to the missing contact.

This approach requires some major changes in the notes app. Furthermore, the impact on the REST-API has to be evaluated.

link external note from contact

In this approach, the note is saved using existing means (I.e. a file in the file system). The notes app needs to provide an URI for creating and opening a new note (should be easy). But the contacts app has to manage the link from contact to the actual note. This could be done by saving the note's id in the contact's note field together with a special marker that indicates, that the note is saved externally.

Issues have to be solved for use-cases like deleting a contact (linked note should be deleted, too) and opening the linked contact from notes app. Furthermore, the note's content is not editable anymore from another contacts app (e.g. the contacts app on your smartphone).

edit in text-app instead

Another possibility would be to not connect contacts app and notes app, but open contact's notes in the new text editor. The notes app will also use that editor in the future, so you will have the same markdown editor across apps. This should be the easiest approach. However, you don't have your contacts' notes directly in the notes app.

Furthermore, when introducing notes for nearly everything, a separate database table as storage backend could be required in order to save data and track the link to the subject, since adding a note attribute to every other app wouldn't scale very well.

However, I think there are many details to be clarified. E.g. should there only be one note per subject, one per subject per user or multiple notes possible? Maybe "notes" is not the correct term for this, and it's more like a comment? (See comments feature in files app; maybe we should start there?)

[brainchild0]

I agree with @sunjam and @korelstar that this conversation is valuable, but I also emphasize the sense of the latter's remarks that the design can follow many potential pathways, and that a rigorous clarification of terms and concepts is necessary to avoid making poor decisions.

In this approach, the note is saved using existing means (I.e. a file in the file system). The notes app needs to provide an URI for creating and opening a new note (should be easy).

I agree with the technical feasibility of hooking other applications into the notes application, using entry points and asset identifiers, but per the below comments, I would encourage pursuing competing approaches for achieving the capabilities sought in the current discussion.

Another possibility would be to not connect contacts app and notes app, but open contact's notes in the new text editor.

The notes app will also use that editor in the future, so you will have the same markdown editor across apps.

Yes, I suggest that the preferred approach is to associate a contact with a text document, in cases where the user would wish to add text to the contact, but not necessarily to classify that text as a note, or to involve the note application. Employing the text application directly to edit the text, however, is obviously desirable.

Currently, the notes app uses files in order to save notes. This has to be extended by another storage-backend for notes in a contact.

Furthermore, when introducing notes for nearly everything, a separate database table as storage backend could be required in order to save data and track the link to the subject, since adding a note attribute to every other app wouldn't scale very well.

I had previously opened #293 to discuss this topic. I continue to believe that files in the file system ultimately fail to capture practically the needed abstraction for notes. However, while I consider this discussion important, I also believe, in light of other considerations I am presenting here, that this issue is distinct from the immediate one.

Maybe "notes" is not the correct term for this, and it's more like a comment?

Yes, I believe that this comment captures the needed insight to direct the discussion toward a fruitful course, and indeed I would have offered it myself if no one had done so already.

In https://github.com/nextcloud/text/issues/6#issuecomment-539936062, I began to elucidate some of the relevant observations, toward a general understanding of notes, that captures the desired functionality of the concept without restricting the cases where it may used. Briefly, I proposed that whereas the term note often is used to describe any brief text document, the association between a note and textual content is overly restrictive. Instead, the demands for an expanding number of use cases point toward the term note describing any asset, text or otherwise, that is organized in some fashion by a notes application. Indeed many notes, as well as files generally, would be textual, such as to demand a clean and robust means for the user to write them, the intention of the text application.

Expounding further, a view emerges that compared to the current terminology, it is necessary to seek a larger number of terms, but with each encapsulating a more narrow meaning,

Loosely, one might propose the following working definitions for ongoing discussions:

• Document: Any single asset, which might be a file, though the particular storage method is arbitrary, of a single media type, such as text, image, or audio.
• Text document: Any document consisting of text, in contrast to other media types.
• Contact: A set of values for the fields that describe one individual's personal information.
• Note: A document combined with additional metadata, for the purpose of facilitating storage and management of the document within a large collection, while imposing minimum burden on the user for administrative or organizational work.

While these definitions may appear peculiar given the common understanding of certain terms, they capture familiar functionality, while opening a higher level of generality and abstraction.

[brainchild0]

Further to the previous comments, I make the small note that expanding abstraction and flexibility incurs certain costs, particularly respecting interoperation with other software and platforms. If text is added to a contact, then how is that text synchronized with external applications? If a mobile notes application presumably includes a MarkDown viewer and editor, then what other media types does it support intrinsically?

[brainchild0]

@korelstar: I am wondering why you removed the discussion tag. If you believe that numerous details need to be clarified before any requested feature reasonably can be considered, then is not a discussion exactly the correct characterization of the topic?

[korelstar]

@brainchild0 Yes, removing the discussion label was by accident.