When using the new "Resource-specific notes file" option, resources with very long names messes up the Visual Filter menu:
So, the design flaw could be in how Logos names "resource-specific" files or it could be in that the visual filter menu should truncate names after so many characters. Or both?
I think it would be better to keep the long names in the document name, but truncate it in the menu. If you truncated the document name you could end up with difficulties with resources like this both ending up with the same name
I think it would be better to keep the long names in the document name, but truncate it in the menu.
+1... although I think you should be able to hover for the long name.
Mark - How has this been implemented? Does L6 auto generate the name? Can you change it?
It does that in the Documents menu, so the behaviour should be consistent.
Mark - How has this been implemented? Does L6 auto generate the name?
L6 autogenerates the name, the same as it does for Palette-specific documents.
If you rename the document (or indeed, if you rename the resource), then Logos will create a new document with an identical name to the resource.
And, if you already have a document for highlighting for a specific resource, you can rename it to be the exact name for the resource and Logos will use that document for highlighting.
Has anyone checked to see what happens when two books have identical names?
Just tried it—they use the same document for highlighting, which is what I expected it to do.
I've made a case for this.
Can you make a case for the other as well? Resource specific note files must be RESOURCE specific, irregardless of the book's title.
This is a known issue that probably won't be fixed in this release. You can work around it by renaming the resource to have a unique title (e.g., add the author's name in parentheses).
This is a known issue that probably won't be fixed in this release.
Ok, but when? Do you have a plan? I don't want to spend hours migrating highlights to discover that 1) they get lost because of a bad migration or 2) I am stuck with cross contaminated note file.
In 6.4, notes documents will be linked to resources by their titles. (If a Notes Document has the exact same title as a resource, it will be the "resource-specific notes file".)
I don't want to spend hours migrating highlights to discover that 1) they get lost because of a bad migration or 2) I am stuck with cross contaminated note file.
How were you thinking of migrating? The way that I migrated my highlighting files was by copying the name from the resource info window and renaming my note-file for a resource with that name. If another note-file already has the same name, it will add (2) after it, so I don't think you could get a cross-contaminated note file by migrating in this way.
Above, you wrote that two books with the same name would share a note document. Did I misunderstand?
I would have expected something similar to the resource id qualifier (or author or original publication date or ...)
Correct, if you let Logos auto-create the notes by highlighting text for the first time in a resource.
However, if you migrate your OLD highlighting notes-file in the way I described, it is impossible to have two identically named note-files because you Logos will add (2) after the name of the second note-file.
It's two different situations.
Again, how were you thinking of migrating your old highlighting note-files to the new system?
I see what you are saying, and it helps ease my fears over ONE problem, but not the other... which is really what I am getting at. For clarification:
This implementation was very poorly thought out.
Right, and in that case, when you see the (2), that will be an indicator that you need to manually rename that resource as a workaround.
I can see why they chose to use titles—it makes it so that you can look through the document list and recognize them easily (as opposed to the resource id). It would be nice if the author's name was attached, e.g., "Piper-Desiring God"
For MANY years now I have laid out some of the things that need to be done... One is that these "resource specific" files need to be a special category. They should be shown only when the user wants to see them.
One is that these "resource specific" files need to be a special category. They should be shown only when the user wants to see them.
I agree with you on that...absolutely. That would be the ideal.
However, this is what we got now, and I am pleased with the progress.
Don't get me wrong, I am thrilled that we are <starting> to see it too... but I hate the lack of foresight.
Come on - this is beta 1 ... we should expect incomplete thought and coding.
i am not upset because of the status in beta 1... I just want to make sure they understand the problem fully.
Come on - MJ - read what Bradley wrote! i am NOT upset because of the status in beta 1... I am upset because this is what they plan to release!
Come on - MJ - read what Bradley wrote!
i am NOT upset because of the status in beta 1... I am upset because this is what they plan to release!
Bradley accurately reflected the state of the plan according to his awareness of it at that moment. At the same time, plans can and often do change, often in response to beta feedback.
When using the new "Resource-specific notes file" option, resources with very long names messes up the Visual Filter menu: I've made a case for this.
This should be fixed in 6.4 Beta 4.
For clarification: The "fix" was to set a max length for the visual filter menu, right? I don't see the full name on hover. Was that intended or no?
Also, I know this thread got sidetracked a bit... sorry. Did I ever create a new thread about ensuring "resource specific" note files are indeed "resource specific" (i.e. two resources with the same name don't get mixed up)? Was a case created? (I know Eli knows about the issue). I can create a new thread if needed.
At this point I don't plan to migrate to the new system until that issue is addressed, nor would I recommend the feature be shipped to stable channel either. It would not be good for users to either waste time migrating note documents nor for them to lose or have mixed up data.
Did I ever create a new thread about ensuring "resource specific" note files are indeed "resource specific" (i.e. two resources with the same name don't get mixed up)? Was a case created? (I know Eli knows about the issue). I can create a new thread if needed.
I don't recall if you created a new thread, but we're aware that "resource-specific notes files" are matched by title, not by resource ID.
It would not be good for users to either waste time migrating note documents
I'm not sure what you mean by "migrating". Is it anything more than renaming an existing notes document so that its title matches the resource?
nor for them to lose
I'm not aware of any way in which users can lose data with this approach. Is there something we should know?
or have mixed up data
IIRC, this feature is not on by default. The documentation could make it clear that the link is done by resource title and that to avoid having "mixed up data" you should use the resource renaming feature. (A lot of people already like to do that--often adding the author's name or series title--to avoid having ambiguously-named tabs and hyperlinks in the software.)
When using the new "Resource-specific notes file" option, resources with very long names messes up the Visual Filter menu: I've made a case for this. This should be fixed in 6.4 Beta 4.
Ok. Truncated but full title available on hover
The documentation could make it clear that the link is done by resource title and that to avoid having "mixed up data" you should use the resource renaming feature.
... but you shouldn't put that onus on the user. Customer service begins with good design. You should be thinking about now AND the future. Related to this: Resource specific note documents will proliferate the number of note documents, making it more difficult to find other note documents. Personally, I believe that many users will love "resource specific" note documents, and that they could care less to see them most of the time. They want to highlight, and to have those highlights stored away out of sight. It would be best to create a method to hide/toggle these note documents. One method could be to access these note files only through the resources info panel. If you use that idea, I want a camelback water bottle. [:)]
Last Question: How hard would it be to add a syntax command to find duplicate resources? I know this issue has come up before with Vyrso to Logos edition resources (which also could create problems for users with the current method!)
If you are seeing "full title on hover" on windows, then there is a bug on Mac:
