Thank you everyone for your feedback and kind words. You definitely make working on MobileSheets a pleasure.
You make some valid points StuartV, and I certainly understand the appeal of having a song page order field when dealing with multiple image files. I agree that it might be a little more intuitive to have one field that specifies what pages to use from a PDF, and a second field that is the overall song page ordering that can be used with any types of files. As it stands now, there is already a fair amount of complexity when it comes to figuring out what each page of a song maps to, because the logic basically has to do this:
song page x -> file page y -> custom page ordering index y -> actual PDF page z
If I change it to a song ordering instead of a per file ordering, it becomes:
song page x -> custom song ordering index x -> file page y -> custom page ordering index y -> actual PDF page z
That assumes I still support some concept of specifying individual pages to use from a PDF in any order (whether I call it page order or something else). Without doing some analysis, I'm not sure how big of an impact it would be to add that additional layer. I do know that things could get a little crazy if a song ordering is specified but the user then changes the page ordering for a particular PDF which causes the song page ordering to become invalid. The same thing is true if a user removes one of the files in use. I think a lot of error handling would need to be added for this to always ensure the song ordering is valid.
I think it may be a little late in the game to make significant changes to the way the page ordering works unless it provides a great benefit to users and reduces the complexity of the application. I may revisit this after I tackle some of the other bigger, more frequent requests. I do appreciate the feedback you've provided, and if this issue keeps popping up with other users, I'll consider making changes sooner. I believe I could make those changes in a way that would not impact existing users, but the level of effort needed to update the current architecture, UI design and database would not be trivial.
You make some valid points StuartV, and I certainly understand the appeal of having a song page order field when dealing with multiple image files. I agree that it might be a little more intuitive to have one field that specifies what pages to use from a PDF, and a second field that is the overall song page ordering that can be used with any types of files. As it stands now, there is already a fair amount of complexity when it comes to figuring out what each page of a song maps to, because the logic basically has to do this:
song page x -> file page y -> custom page ordering index y -> actual PDF page z
If I change it to a song ordering instead of a per file ordering, it becomes:
song page x -> custom song ordering index x -> file page y -> custom page ordering index y -> actual PDF page z
That assumes I still support some concept of specifying individual pages to use from a PDF in any order (whether I call it page order or something else). Without doing some analysis, I'm not sure how big of an impact it would be to add that additional layer. I do know that things could get a little crazy if a song ordering is specified but the user then changes the page ordering for a particular PDF which causes the song page ordering to become invalid. The same thing is true if a user removes one of the files in use. I think a lot of error handling would need to be added for this to always ensure the song ordering is valid.
I think it may be a little late in the game to make significant changes to the way the page ordering works unless it provides a great benefit to users and reduces the complexity of the application. I may revisit this after I tackle some of the other bigger, more frequent requests. I do appreciate the feedback you've provided, and if this issue keeps popping up with other users, I'll consider making changes sooner. I believe I could make those changes in a way that would not impact existing users, but the level of effort needed to update the current architecture, UI design and database would not be trivial.