Show the blue border around buttons when no actionbar color is set

[agrogers]

[agrogers]

I think @tuomas2 made implemented this at the same time I did. If so, this PR can be closed.

[agrogers]

Or again revereted the button color change this depends on??

[tuomas2]

Or again revereted the button color change this depends on??

Sorry, I indeed reverted and implemented the bold boundaries as discussed in #2468. You can keep this PR as is, if we decide to go with this solution, I can revert again and cherry-pick this commit. But what do you think? I find bold boundaries bit more robust and still clear and nice (though did not yet try with my devices), as I can imagine not all colors work as well and grey requires special treatment.

[agrogers]

I have run out of energy on this feature, Tuomas. I am fine with whatever you decide. I have my own build which I will include what I prefer.

I feel your question 'What do I think?' is not the right question. And it highlights a frustration I have had for a while. My first and most important point is that whatever system we have in place needs to be such that it ensures your continued involvement in the project. At the moment, without you, this project is dead. I definitely don't want that to happen. My next points are all subservient to this one.

The question I want answered is not what I (or you) think but what our users think. But this information seems almost impossible to get with the way PRs are handled at the moment. At present, for a change to be included in the beta it either has to be very simple or very complete and beautiful. I struggle to make simple contributions. And I am definitely not competent enough to make beautiful or complete additions. That doesn't mean they don't work. I have been using #2019 and #2061 in my build for over a year without issue. But with the few hours of programming I can do per week, I am not going to improve either my abilities or my code much.

If significant changes do not make it into the beta no one gets to use them and we don't get any feedback on whether they are useful. It took over a year to get the first bit of feedback on #2019 - feedback that was not needed if they could have actually used the feature. Apart from you, there is no feedback from other users

This leads to a number of disadvantages. First, it reduces my (and others?) motivation to contribute. When I started I was motivated first by the novelty, then by adding things i really wanted and last by benefiting other users. The novelty has long gone. And now I am motivated equally by making something I want and benefit to others. But when others don't benefit from stuff I do I struggle to get motivated.

Second, without feedback from real users I don't know if it is even worth trying to improve it. Maybe no one really wants the feature. Maybe I have gone about it the wrong way. How would I know?

Third, I have to rewrite things because my frist attempt was done so long ago that it is now broken. I am slow at coding - I dont code at all in my job and only have a little time on the weekend. So that hurts the motivation as well.

Last, there are features that could be added that I think users would really like... but they don't get any benefit from them.

So here is my suggestion. First, if the only way to ensure your enthusiastic support of this project is to include changes as we are doing, then so be it. Your involvement is by far the most important consideration. But if it is not the only way, then I think the following would be a better approach.

1. The beta version needs to get new feautures, especially big ones, more easily and quickly. My suggestion is that if a feature does not make the application unusable then it should probably be included. A case in point is this PR and the missing Pin icon PR from a few weeks back. The later was such a trival loss that I doubt most users would have even noticed it and certainly not justification for delaying its inclusion. This PR does make a noticeable change but is far from making the application unusable and under my proposal would be included.
2. Any feature that may cause complaints from users should be added as an option to the beta. The colouring of the buttons is an example, The search statisitics form is another. This option should be set to True by default to ensure beta users see it but be able to turn it off if it really annoys them.
3. When practical, these options should be coded so that the old code and the new code are completely separate. The colored buttons is a good example. It is very easy to have the old code and the new code accessible via the option. Yes, there would be a lot of duplicate code while it is in beta. But this allows keeping the existing functionality untouched and also allows continued changes to both old and new without hurting the other.
4. When a feature has been accepted or rejected, the relevant code and option can be removed.
5. Changes should stay in beta for at least weeks, probably months, before being removed or reverted. They need time for users to find them and complain or congratulate or propose improvements.
6. Some features might never get out of beta because they never make it to your standard. That would be fine with me - at least some people can/are benefiting from them.
7. This would have the added advantage that contributors like me who use a separate build would not need to do that. At present I can't easily contribute to bug testing because my build is so far behind the latest which has broken features I added ages ago. And I am lacking motivation to make them work with the latest develop code if people are unlikely to see them any time soon.
8. If new features are in the build that beta testers and other developers are using, there is a greater liklihood of other contributors doing something. For example, I would like to see what Improve reading plan UI #2095 looks like and maybe I could tweek some things. I know my code could be tweaked.
9. I am sure there is devil in the detail here. You will know what that devil is and maybe that would force me to rethink this. But my feeling is that our current system is unnecessarily 'pure' and its disadvantages outweigh the benefits I have described.

OK, that's it for me. I wont be back coding for a week or so. I need to go back to Australia for a bit as well. I have a wife now and a baby on the way, so my time is disappearing before my eyes.

PS: I have added Devotionals into my build now. Nancy and I read our Bible together each evening and sometimes we use https://odb.org/AU/2023/02/11/an-undeserved-gift. I am happy with how it integrates and it is faster for me to get to this from AndBible than through a browser. This is one big change I wanted.

[tuomas2]

Just saying that a reply is on the way. Probably needing some time still to get it here (but not more than 1 week I think).

I would like to already now congratulate you for getting married and also for the upcoming baby! That is wonderful news and I'm happy to hear that! God has blessed you plentifully! Big blessings & greetings to your wife Nancy!

[tuomas2]

First of all, in my opinion you were the 2nd key person of the project in making version 4.0 what it is. Your contributions were high quality and very much appreciated, when you provided me ideas, drawings, and improvements to (mainly JS side) UI/UX and making the videos. Although I was mostly making the actual code, AB definitely would not be what it is without your contributions. 

About getting user feedback.

We are not yet in Beta phase (though I believe we will be within a couple of months). Features are only in Github alpha builds. Only a handful of users are seeing anything that has been developed thus far, that is not included in stable build (4.0). Google Play’s Beta channel is still deserved for pre-testing production builds for now, which is important because I am not using production builds myself any more (but still include fixes etc).

User feedback is not something that we can easily get fast from big quantity of users. I’m not getting it either. I also do not think that it is that essential to get it very early. If I have feedback from a handful of people that have some insight to UI/UX design, it’s often enough. You have been one such valued feedback giver.

About merging unfinished / poor code quality PRs

I have no problem with pull requests that are made by professionals, that can be merged almost as-is with only minor remarks. They are rather easy and fast to review and merge - especially when the trust is already built in the contributors skills.

You have made cool PRs when it comes to features that they provide, that can’t be denied. But my opinion is that the code is still often not acceptable without major rewriting (except some smaller and simpler changes). Yes, you have tested the code in practice and found that it works for you. It’s cool that you can benefit yourself from the work of your hands. It is also possible it would work for others too - at least as long as there is no other people touching that code. But I’m working with the code “everywhere” all the time and it’s important that I understand the code and that it is well structured, so that I’m not messing it up and making it non-functional in my changes. This is especially important as we are lacking behind automated testing…

So, I feel it is essential that I am keeping the minimum standard for code quality (for me and for contributors), similar to what I’m used to in my professional career. I know that if I did otherwise, it would have the following drawbacks:

• Code would become difficult to maintain. Further additions and modifications would be difficult. That would have a harmful impact on my motivation.
• There would be more bugs. Code that is not well structured and difficult to read/follow (and also is not covered by tests), contains easily hidden bugs.
• Code would be less attractive to other (professional) developers. I must say that I would not have been interested in contributing if I didn’t see from the code that it is written in a professional manner by Martin.

[timbze]

@tuomas2 Completely agree with everything you wrote.

About merging unfinished / poor code quality PRs

Exactly correct. It would become unmaintainable. For Andrew it would be great if someone would fix all the code, but that also takes motivation and a lot of time from someone else. It's a bit difficult for someone here to be doing that while also trying to work on the things that he himself is interested in.

I only say this in my observation and experience. I also am extremely grateful for the input Andrew has in making things better for users.

[tuomas2]

Closing this (won't merge)