A well hidden and (as yet) underdeveloped feature. Thought I'd post my findings after some recent fiddling with MCs controversial "Notes" section.
Bugs- If you change the columns in the list view, they all become squished together such that you can't read the contents of any of the fields. Try adding lots of columns and then adding a new note.
- Changes to the notes view itself are not saved. If I add some panes at the top and then leave the view, I am prompted with the "Do you wish to save changes to the View Notes (6)?" I select yes, but when I return to the view, it's just the keywords pane again. Each time I am asked if I want to save the view, it adds another number (Notes (7), Notes (9) etc etc).
Comments- I am not a fan of mandating that the name field reflect the first few words of the note. Say I am creating notes for a movie database - why can't I have the [Name] field as the name of the movie and the note itself containing a synopsis? The behaviour here is also a bit unpredictable at the moment. If I have a word in the note and then rename [Name], it will also change the word in the note. If I have a paragraph of text in the note and then attempt to change [Name], nothing happens.
- I would have each note stored as a physical file on the hard drive, and treatable as any other file in the library (renaming, tagging etc). Why? I'll get to that later. It doesn't matter what the file format is - all of the information would be contained within the file itself.
- Perhaps add a separate [Media Type] to the database - "Note"
- Allow files from the library to be assigned to a note - there are a few ways this could be done (see quote below)
- Allow files assigned to a note to inherit metadata from that note
My Current UseageMy current use with notes is to use a [Type] field to specify what type of note I'm dealing with. Some example values for [Type] I've been toying around with include: Contact, Artist, Film, TV Show, Theatre Production, Opera, Book (naturally this list could be anything you want though).
The [Name] field specifes the name or title:
- [Type]=Contact , [Name]=Bob Smith
- [Type]=Film , [Name]=Avatar
- [Type]=Artist, [Name]=Enya
Doing this effectively allows you to create a database of anything you want.
Artists can be tagged with bios, nationality etc.
Films & TV shows with directors, actors, genres & whatnot.
Contacts with all your contact information like addresses and phone numbers.
Where I'd like to see this end up is a way to (a) maintain your own custom database of anything and (b) have the rest of your library draw on this information without the need to re-enter it each time I add a new file to the library.
Jim, oh how you laughed at our YARB thread (yes we have just passed the 1 year mark since our last
Annual Convention!) - but it's interesting how close we've come to what we proposed way back then:
1 (a). The user could create "entities" (to use hit_ny's terminology) in the database
or
(b). Entities could be automatically created as values are entered in specified fields (eg adding Abba as an artist will create Abba as a taggable entity also?)
2. These entities could be 'tagged' with fields as current files are now. There doesn't need to be any functional difference between fields used to tag entities and the current fields we use to tag files.
3. Values of these entities (eg. Abba) could be linked to similar values in other fields, such that if a file is tagged with Abba, it will automatically be linked to the "Abba" entity and inherit the associated entity metadata...
So, if users do not associate or tag any fields to an entity, then things will effectively work exactly the same way they do now.
If the user chooses to add "additional information" to an entity, they may do so.