MobileSheets Forums

Full Version: deleting unused field values
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
So far, I'm finding tiresome the process of having to delete manually field values that have become unused due to my having corrected them (which, per your design, can only be done by entering a new field entry for a song and then deleting the incorrect old one from the song--if I'm wrong on this part, please correct me). THEN, I notice that the "deleted" old one still exists in the list of available pre-used entries even though no song uses it. I then have to "delete" it from the list of available entries. This makes 2 deletion processes and a new entry process for one simple correction. Furthermore, unless I'm missing an easier process, when I do the final deletion, I'm looking at the old and the corrected in a list, with no indication of which no longer has a song assigned to it; ergo, unless the nature of the correction makes it obvious which is the old and which is the corrected, I have to double-check by clicking on each field value to see if any songs open.

I fully understand how some users might wish to retain unused field values (especially if there's a way to pre-load possible field values for later selection) and therefore NOT want their unused values automatically deleted, it sure would be nice to be prompted after an "edit" with something like "Hey, I see you just added a new field value to this song or collection of songs very similar to an existing one in the same field. Would you like to substitute all 'Alred Neumann' with 'Alfred E. Neumann' in all songs and delete 'Alred Neumann'?" I have seen that technique used in other non-music database apps, but only when the field entry is allowed to be edited directly, which MSP doesn't allow; in that case, the only open question is whether the user wants all items containing that field value to be changed to the new version, since it's obvious that the present record is intended to be a substitution.

I'm agnostic as to how this edit/delete process should function, but it should not be so cumbersome to correct a simple typo and have the correction apply to all songs that use that value AND not burden the database with old, incorrect values that might accidentally become assigned in the future to new songs instead of the corrected version. I encounter this most often when I add information to a composer, like birth name or city/country of origin, or death date, or middle name or a/k/a, which I'd obviously want to have replace the previous form of that composer's field value. 

PERHAPS, allowing the user to right-click the existing field value and open up an editing dialog that would automatically delete the old version and substitute the new value for all instances of the old (with a prompt for permission, because, e.g., replacing "2015" with "2014" in the Years field shouldn't assume that all 2015 entries are supposed to be 2014). Another possibility would be to allow this form of editing only when listing all values under a particular tab (rather than inside one song).

Another possibility (inelegant) is to have a separate process available for deleting dead field values or a user option that dead field values are to be automatically deleted. This would be very useful to folks like me who generally do all their editing externally and then re-import and therefore don't need a pre-loaded list of available field values and don't want the old ones hanging around for any reason.
You can delete the unused entries from the tabs those entries belong to. So if you have composers you don't need, go to the composers tab, filter on unassigned, and you can delete them all in one go. I'm assuming you probably realized this based on your question in the other thread you created.

The fields in the song editor already support auto-completion. If the user ignores the auto-completion and picks a new value, it's on them to realize what they've done. I'm not going to guess at what users might be thinking, as this could get really annoying for users that are intentionally creating values that happen to be close to existing values. You can edit existing entries though, so I'm not sure I understand your point about editing fields directly. Just go to the tab containing the entry and you can rename it.

It doesn't seem too cumbersome to me to go to the tab containing the entry type, long press or right-click the entry and tap "Rename" to change the name. If users disagree, I'm always open to suggestions for improvements. If users want to be able to rename through the fields tab of the song editor, I can look into supporting that, as it would just be added alongside the remove/delete options that existin when an entry is long pressed or right-clicked.

My bug tracker does have an entry in it for adding utilities to clean up the database/library, such as removing groups that have no songs in them. I'll add this when I have more time.

Mike
(04-05-2020, 09:45 AM)Zubersoft Wrote: [ -> ]You can delete the unused entries from the tabs those entries belong to. So if you have composers you don't need, go to the composers tab, filter on unassigned, and you can delete them all in one go. I'm assuming you probably realized this based on your question in the other thread you created.

The fields in the song editor already support auto-completion. If the user ignores the auto-completion and picks a new value, it's on them to realize what they've done. I'm not going to guess at what users might be thinking, as this could get really annoying for users that are intentionally creating values that happen to be close to existing values. You can edit existing entries though, so I'm not sure I understand your point about editing fields directly. Just go to the tab containing the entry and you can rename it.

It doesn't seem too cumbersome to me to go to the tab containing the entry type, long press or right-click the entry and tap "Rename" to change the name. If users disagree, I'm always open to suggestions for improvements. If users want to be able to rename through the fields tab of the song editor, I can look into supporting that, as it would just be added alongside the remove/delete options that existin when an entry is long pressed or right-clicked.

My bug tracker does have an entry in it for adding utilities to clean up the database/library, such as removing groups that have no songs in them. I'll add this when I have more time.

Mike

Thanks, Mike. I think I was missing the "rename" dialog for one entry in a particular tab. I guess I was thinking the situation where you're already in the field editing for a song and you encounter a lengthy value that you realize should be slightly edited. It would be nice not to have to back out to a different Tab in the Library, find that to-be-edited value, right-click, rename, and finally be able to correct the typo.

What I'm suggesting (I realize now) is that when I'm in the Fields dialogue for a particular song and I see the typo in, e.g., Composers, I'd like to be able right then and there to right-click on the value containing the typo, bring up the Rename dialog (saving me the trouble of re-typing the entire corrected value from scratch as a new value and then deleting the old), make the correction, and then be prompted for whether I'd like my correction to apply to all instances of that pre-corrected value remaining.

Going one step farther, for those who use a separate Custom Groups for lyricists, one correction (re-naming) of a name in the Composers field of one song would ideally be able to be substituted for the pre-corrected name anywhere it appears in the database (i.e. whether in Composers or in Custom Groups or wherever).

If you take my example of noticing a typo in a field value in one song while you happen to be in the song edit screen and think through the workflow that you'd really want to have for correcting it on the fly (so you can quickly get back to what you were doing), I think you'll see my point. It's not that the app isn't ABLE to make all necessary corrections, it's that it's not able to do it quickly at the point the need becomes apparent.

FWIW, I've seen this functionality in a database for genealogy, where one notices a particular event has a place listed as Wymoing. A simple typo correction there leads to a prompt "Would you like to replace all instances of "Wymoing" with "Wyoming?" Very handy and tightens up the database as well. Indeed, in that very same database program, I COULD stop what I'm doing and open up the Places list, find "Wymoing" and correct it (leading to the same prompt), and then find my way back to what I was doing when I noticed the problem. But why need to bother?
I can write up a feature request to add renaming to the right-click menu as I mentioned. I'm not sure about renaming one field and having it propogate to matching values in other fields. In theory, this can be done, but it means that when renaming one group, I have to query 10+ database tables to see if there is a matching name in any of those tables for the original group name. In smaller databases, that's not going to take very long as I have a full text index on the names in the database. For users with 10000+ songs with tons of names in every group, that might create a longer delay. I would have to do this processing in a background thread and have a progress dialog shown (which is tedious on Android, but not so bad on Windows). If I did implement this capability, I would prefer to have the app check the renamed group to see if any other groups have a matching value, and if so, then ask the user if they want to rename those groups as well. The alternative would be to have a checkbox on the rename dialog that says something like, "Rename matching groups in all fields". This would be simpler to implement as I wouldn't have to add the extra checks and prompt. I welcome thoughts on this.

Thanks,
Mike
(04-07-2020, 03:29 AM)Zubersoft Wrote: [ -> ]I can write up a feature request to add renaming to the right-click menu as I mentioned. I'm not sure about renaming one field and having it propogate to matching values in other fields. In theory, this can be done, but it means that when renaming one group, I have to query 10+ database tables to see if there is a matching name in any of those tables for the original group name. In smaller databases, that's not going to take very long as I have a full text index on the names in the database. For users with 10000+ songs with tons of names in every group, that might create a longer delay. I would have to do this processing in a background thread and have a progress dialog shown (which is tedious on Android, but not so bad on Windows). If I did implement this capability, I would prefer to have the app check the renamed group to see if any other groups have a matching value, and if so, then ask the user if they want to rename those groups as well. The alternative would be to have a checkbox on the rename dialog that says something like, "Rename matching groups in all fields". This would be simpler to implement as I wouldn't have to add the extra checks and prompt. I welcome thoughts on this.

Thanks,
Mike
All those ideas sound good to me. I think a user would tolerate it taking some time if they chose to have it done; imagine how long it would take the user to accomplish the same thing manually! Is there a reason you must refer to a field value as a "matching groups?" Even having used the app for a while, I'd have no idea what that meant. It's not a "group!" It's ONE value (e.g., "Joe Blow")--I'd never dream that renaming "Joe Blow" to "Jo Blow" would constitute "renaming matching groups." There's nothing plural about it. I find this kind of terminology lengthens the learning curve on MSP generally--along with the absence of tool tips that Windows users are addicted to in software they're trying to learn.

Maybe it's a generational thing, but I'm very reluctant to click on a icon with no clue as to what it does (or to drop everything and read a manual, which I did ONCE from beginning to end before buying the app). One perfect example (which may well be part of some standard in Android apps or the like that I'd have no idea about) is the 2 icons at bottom right of the library screen sometimes, one of which (a box with a check IN it) means (I think--too scared to try it) UNcheck everything, while the box with NOTHING in it means CHECK ALL BOXES. This is exactly the opposite of what this one user would have expected those buttons to do. Just one man's opinion, who wants this product supported and improved forever--I hope you're way younger than I, Mike!
When I say matching groups, I'm referring to any other group type that has a value (i.e. name) that matches the new name assigned to the group being renamed. If you can think of a more concise way to correctly describe that, please let me know. Just realize that anything I enter has to be translated into 13 other languages, and some languages like German usually result in much longer phrases. 

I don't think it's a bad thing you don't want to click on icons if you don't know what they do, but there aren't too many icons you can click that would change something that you can't undo by just clicking the icon again. Obviously clicking a trash can icon or an X is probably going to delete something if it's in a list, but otherwise you are pretty safe to click any icon. I do realize that tooltips are needed - like I said, I'm going to add them as soon as I can. That's the only downside of being a one-man team - development is going to take longer than if I had a full team of developers working. 

As far as icons, I generally use Google's material design icons: https://material.io/resources/icons/?style=baseline

That's where the "select_all" icon came from. They didn't have a clear selection icon, so I altered their select all icon. If you can think of a more intuitive icon for deselecting everything, let me know. Google has an entire team dedicated to creating intuitive icons, so that's why I'm using a lot of their icons.

You don't have to worry about me going anywhere - I'm supporting MobileSheetsPro for a long time to come (I can't imagine ever giving up on it unless all of my users stopped using the app). I'm in my thirties, so I'm not retiring anytime soon Smile

Mike