Request: Please can we have additional user fields to manage resourcesClosed

I find the current single MyTags field too limiting to manage the 1000+ resources I have in Logos4.

Please can we have a new set of user fields that we can use in any way we wish. With the ability to edit them in a maner like we can for the MyTags field, and to be able to use them in searches and Collection rules.

I already wish to manage the follow:

Purchase date
Package or special (March Madness, Pre-Pub etc)
Read status: read / finished / skimmed etc
Private "hide" status so I can exclude it from collections and searches, yet find it in an All Library search
Tag by language, content type, position on some issue and more besides.

Currently this is only possible by overloading the contents of what is added into the MyTags field, so the data item also attempts to include its type e.g. "Purchased_2010_05_01"

I suggest User0, User1, User2, User3 ... User9

While I do think it might allow users to address errors or personal choice in official metadata values on a resource, I wish Logos to see this as independant of that matter.

Comments Closed

Sort by:
1 - 4 of 41

    I suggest User0, User1, User2, User3 ... User9

    I would add that each field can be renamed and given a default value(s) from Logos' metadata fields.

    Dave
    ===

    Windows 11 & Android 13

    I would add that each field can be renamed and given a default value(s) from Logos' metadata fields.

    Yes, re-nameable fields would be good. I would love to have one named "Systemic Bias" and code it with things like Calvinist, Wesleyan, Covenant Theology, etc. [:)]

    No, let's not have Logos pre-load them. I fear that "ordinary users" would find this confusing. Maybe we could have the ability to copy from Logos meta-data fields to user fields.

    No, let's not have Logos pre-load them. I fear that "ordinary users" would find this confusing. Maybe we could have the ability to copy from Logos meta-data fields to user fields.

    Well, from my point of view, it would be great if we could urgently have blank and empty User0 ... User9 now. We could start to use them right away, and I'm hoping they would take little work to add the support for them.

    Better, maybe later, would be so we could have as many as we wanted, and named whatever we wanted - except for reserved names. And the field-creation UI could support some copy rules to preload the new field with the contents of any current other field. So, if you wanted to make one named "MyLanguage" and set so it takes a copy of a field already called "Language". The problem is, this is a whole extra level of design and UI coding for the developers. If we make it too hard, they wont do it, or not any time soon. So we get nothing. Simple and soon. Complex later is fine. Just my two cents.

    I've submitted your suggestion with a link to this thread.

    Thanks Melissa.

    (One day I'll work out timezones. You wrote the above at about 2:30 am here ...)

    Some of you certainly want to manage a lot of classifications![:S]    You provide some good ideas though. I would find it nice to have the package included as one separate fields filled in by Logos or by the installation process. When someone recommends a certain package, I don't know if I bought it years ago or not because I don't know what was in the package. Anyway I like the idea of the UserX fields that can be named by the user though I realize this can be accomplished using the current user tag field.

    Have a great day,
    jmac

    Please can we have a new set of user fields that we can use in any way we wish. With the ability to edit them in a maner like we can for the MyTags field, and to be able to use them in searches and Collection rules.

    Why can't you just assign multiple tags? You can have as many tags as you like, and there doesn't seem to be overlap on your requirements, so a book can carry "Purchased_2010_05_01; skimmed; MarchMadness; my_type" etc.

    Do you really need separate fields?

    We're just trying to keep the system from getting overly complicated, and intimidating newer users... I'm worried that adding 10 user-defined fields would make cataloging a lot scarier, for marginal benefit over just adding the tags you want.

    Do you really need separate fields?

    Hi Bob,

    Yes please - I really do want seperate fields.

    Its on account of a few reasons:

    1. Display and Sorting in the Library Panel. This is one that really fails with overloading "MyTags".
    2. Simple collection rules.
    3. Less typing to add the data. I would rather somehow select User4 or whatever, and type something that need to add a label as part of the data. Also, the data gets longer.
    4. I saw somewhere that we are discouraged from changing the "Short Title", so in some cases I have an alternative in the MyTags field

    Correctly documented as user-fields, it should be easy to discourage people that have no idea what its for and no idea why they need it, to leave them alone. (Actually - I'm not sure that works with software [:)])

    I understand the desire to keep it simple and clean and less intimidating. Thats why I think a set list such as User0...User9 might be a lot easier to code, document and support than unlimited and user-named ones.

    My concern is that the current single field is already maxed out and getting hard to use, to contain everything I want to mark in my resources. I have 1300 and growing, so I really want to be able to manage them well, and use them as I wish.

    Display and Sorting in the Library Panel. This is one that really fails with overloading "MyTags".

    In Library, if I click "My Tags" as the sort field, the new "Type" column is a complete list of every unique value. So all my different custom fields are mixed as one long list. It gets worse as I use MyTags more.

    Same basic issue when building Collections, and attempting to sort and select,

    I am not sure having user defined fields would benefit me as much as having the ability to create a drop down list, or maybe another pane (similar to the highlighting pane and the custom palette) I could select from when I click "add tag". This would eliminate having to retype the same thing when tagging resources.

    I have a number of resources that have multiple tags and if I search for a specific list of tagged resources (e.g. mytag:greek) it works fine, even if I have other tags associated with the same resources.

    I am not opposed to the suggestions above and may discover ways to use that feature if it was available.

    Do you really need separate fields?

    Hi Bob,

    Yes please - I really do want seperate fields.

    Its on account of a few reasons:

    1. Display and Sorting in the Library Panel. This is one that really fails with overloading "MyTags".
    2. Simple collection rules.
    3. Less typing to add the data. I would rather somehow select User4 or whatever, and type something that need to add a label as part of the data. Also, the data gets longer.
    4. I saw somewhere that we are discouraged from changing the "Short Title", so in some cases I have an alternative in the MyTags field

    Correctly documented as user-fields, it should be easy to discourage people that have no idea what its for and no idea why they need it, to leave them alone. (Actually - I'm not sure that works with software Smile)

    I understand the desire to keep it simple and clean and less intimidating. Thats why I think a set list such as User0...User9 might be a lot easier to code, document and support than unlimited and user-named ones.

    My concern is that the current single field is already maxed out and getting hard to use, to contain everything I want to mark in my resources. I have 1300 and growing, so I really want to be able to manage them well, and use them as I wish.


    More fields would absolutely be appreciated. I was thinking the same thing but never thought to ask. [Y][Y]
    Hopefully we will see them in the near future. [:D]

    Thanks for seriously considering this request Bob!

    ts on account of a few reasons:

    1. Display and Sorting in the Library Panel. This is one that really fails with overloading "MyTags".
    2. Simple collection rules.
    3. Less typing to add the data. I would rather somehow select User4 or whatever, and type something that need to add a label as part of the data. Also, the data gets longer.

    Sorry to be arguing so much...but I just can't think of anything uglier than 10 blank fields named "User0"..."User9" in every book preview. (And letting you rename the fields is worse -- lots of UI to keep your field name from overlapping with built-in field names -- in multiple languages -- and to handle collections built with one field name when you rename that field later, etc...

    So I'm fighting hard to make "MyTags" work.

    My Tags allow spaces in tag names, and semicolons separate multiple tags. Then when you sort or group by MyTags in the Library window, each tag gets its own heading. All those labels are then available, individually, though mytag:<tag>. Where does this fail, and isn't "mytag:skimmed" as useful as "User3:skimmed"?

    -- Bob

    I'm not in favour of custom fields, and in my view tags do work. But one thing that this does raise is that Logos could store more and better user data about our books:

    • A new field for 'read/unreading/reading' (with a date for start/finish) could be very useful, and link in the the Reading Plan.
    • Storing and exposing the date a resource was purchased ought to be easy and has been requested several times.
    • Likewise exposing the field which stores the actual unlock for that resource would allow users to create collections around purchases, which has also been requested several times.

    This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!

    I've considered going through my Library and slowly tagging my books with their Library of Congress call numbers. This would allow me to look at my library in a topical way and it's the way I organize my print library.

    However, if I were to do this then when I sort by the Mytag field the LoC numbers would be intermingled with all of the other tags I use. Because of the mess this would cause I am choosing not to tag my library in this fashion. Of course I would prefer that Logos do all this tagging for me, but I don't expect it [:)].

    While I can see the value in the type of system that Jim is suggesting I would rather see programing effort go toward other priorities. I will keep my tagging my library in a minimalistic way so I don't get a cluttered mess when I sort by Mytag in the Library view.

    Sorry to be arguing so much...but I just can't think of anything uglier than 10 blank fields named "User0"..."User9" in every book preview. (And letting you rename the fields is worse -- lots of UI to keep your field name from overlapping with built-in field names -- in multiple languages -- and to handle collections built with one field name when you rename that field later, etc...

    So I'm fighting hard to make "MyTags" work.

    My Tags allow spaces in tag names, and semicolons separate multiple tags. Then when you sort or group by MyTags in the Library window, each tag gets its own heading. All those labels are then available, individually, though mytag:<tag>. Where does this fail, and isn't "mytag:skimmed" as useful as "User3:skimmed"?

    -- Bob

     

    All right, after playing around with the tags, I don't want to be limited to 10 user tags, since I was able to add over 50 tags to one resource. I do not want to lose that ability, and I think Bob knows what he is talking about here.

    What I WOULD LIKE to be able to do is drag and drop to RE-ARRANGE them, so I can create some sort of ordering that I would like without having to reorder them by editing the fields, which I have done in the past.

    Thanks for your reasoning Bob!

    Do you really need separate fields?

    Personally, I don't need additional fields. I think the judicious use of mytags is sufficient but we do need a dropdown menu of the values we have used in the fields so that we tag consistently. While I understand why others want more fields, I share your concern with additional complexity that provides additional functionality that is used by only a few people. I want fewer unnecessary options that create additional branches to test so that testing can be more thorough and your staff resources can be spent on development and documentation rather than bug fixes.

    Orthodox Bishop Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."

    we do need a dropdown menu of the values we have used in the fields so that we tag consistently

     

    YES!  This would be a great addition.

    we do need a dropdown menu of the values we have used in the fields so that we tag consistently

     

    YES!  This would be a great addition.


     

    Agree! [Y]

    we do need a dropdown menu of the values we have used in the fields so that we tag consistently

    Yes - although autocomplete would make the UI cleaner.

    This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!

    Why can't you just assign multiple tags? You can have as many tags as you like, and there doesn't seem to be overlap on your requirements, so a book can carry "Purchased_2010_05_01; skimmed; MarchMadness; my_type" etc.

     

    Bob, maybe an obvious item, but I'll ask it anyways. Does L4 treat each individual entry in MyTags as separate entries during a search using MyTags? Per your example is the semi-colon the required separator (I ask as I haven't started using MyTags to what appears their full capability)? Is the L4 search using MyTags have sufficient intelligence not to return duplicates if I am doing a search for multiple parameters that some resources might include both?

    If each entry is considered separate from the others and the search aspect will eliminate dups, then I see no reason to add a slew of additional user-defined fields that would increase the database size, that - I would hazard to guess - only a small portion of users would benefit from that could be handled with the available capabilities with some minor re-thinking on the end-users part.

     

    In Christ,

    Ken

    Lenovo Yoga 7 15ITL5 Touch Screen; 11th Gen Intel i7 2.8Ghz; 12Gb RAM; 500Gb SDD;WIN 11

    http://wiki.logos.com/

This post has been closed.