Privacy Browser Android

Oh no! Would you please consider re-adding the feature that allowed long pressing bookmarks to open them in the background? (At least as an option, if you don't want it as the default.) I found that feature to be extremely useful for years -- as did several of my work colleagues (we're all devs) -- as it made it very efficient to store and (re)open many bookmarks at once, especially e.g. after a phone restart or app crash etc. Now in v3.12 it's quite tedious to restore bookmarks as the entire bookmarks drawer disappears after each long press.

Thanks so much for all your terrific work on this browser!

Can you explain to me what aspect of this feature request would not handle your use case well? In fact, it seems to me it would handle the use case even more efficiently than the older method, because one could open up a number of frequently used bookmarks with less taps than previously.

PS Or maybe you could do the reverse: Make the previous functionality (long press = background open + retain bookmarks drawer) the default and let the new functionality (long press = foreground open + close drawer) be a settings option? For years many of us have gotten very used to the much better usability/efficiency of the former method...Thanks for considering, hope you can do this!

I am generally opposed to settings that modify the way the GUI works. Not only do they make the code more difficult to maintain and test, but, more importantly, if you create a setting that modifies the GUI for every possible configuration that any user can request you end up with a mass of settings options that is so long that it becomes confusing to navigate.

There are a few exceptions that I have made to this general rule, like having a setting that moves the app bar to the bottom of the screen. However, I don't consider this issue to rise to the level where I would create a separate GUI code path.

Soren Stoutner wrote in #note-2:

Can you explain to me what aspect of this feature request would not handle your use case well? In fact, it seems to me it would handle the use case even more efficiently than the older method, because one could open up a number of frequently used bookmarks with less taps than previously.

Just to clarify....The reason the updated version is much less efficient is that the bookmarks drawer now closes immediately after every long press.... So it's no longer possible to restore many bookmarks in one shot...Whereas before we could keep the drawer open and long press many many bookmarks one after another very quickly, and with the added benefit of not leaving the current webpage (this was a big benefit, e.g. for continuity of reading etc)....Now, after restoring say 10 bookmarks, if we want to return to the webpage (tab) we were on before reopening the bookmarks, we must scroll the top tab bar and carefully look at the icons etc to find that webpage. Bottom line is, it's quite more tedious now to do this previously simple task...

To be clear, when this feature request we are discussing here is implemented (probably in Privacy Browser 3.13) it will be possible to open as many bookmarks as you want with one long-press simply by placing them all in a folder. The active tab will remain the one you started with, so that will not be an issue.

As far as I can tell, this design is superior to the previous one.

Ok thanks...I understand what you're saying but I'm referring only to the case where the bookmarks of interest are not within subfolders but rather simply under the parent bookmarks drawer. Maybe my request is more of a "reversion" request...

It seems to me that it wouldn't be that hard to put all of the bookmarks you like to open at one time in a subfolder. If you have some bookmarks you like to sometimes open individually and sometimes as a group, it would be really easy to have two copies of the bookmark, one in the subfolder and the other in the home folder.

As a point of reference, I specifically designed the prior GUI behavior around the exact use case you have of wanting to open a bunch of bookmarks all at once. So, I understand where you are coming from.

However, I think this design is so much better that, if I had thought of it originally, this is how I would have done it from the beginning.

Even though I have a strong preference towards not changing things just for the sake of change, I also have a strong preference for not letting a good design prevent you from switching to a better design. And the more I think about this, the more I am convinced that this is a better design for everyone.

Ok....I agree with your points for the use cases you're referring to. But that seems to implicitly assume we like to regularly open the same bookmarks, which is usually not the case for me and my colleagues. For example let's say I have 80 individual bookmarks in the home folder (and 10 subfolders). For the subfolders I agree your planned change would be very nice (ignoring the timws that we might not always want to open every bookmark within a subfolder). But requiring us to copy frequently opened bookmarks into their own subfolders seems, again, quite tedious because as I mention we don't always restore the same bookmarks each time....For example let's say of our 80 bookmarks in the home folder, on one day we want to open numbers 5,7,12,25,63,79 but another day (or later the same day etc) ee want to open only bookmarks 15,40,57,75. I hope you can see how impractical it would be to require us to move/copy our home folder bookmarks into new folders given this non-repeating usage...Also what if say we just want to stay on our active tab but arbitrarily open 5-6 bookmarks that are only in the home folder?
....Anyway maybe you're not seeing my point of view but I can tell you just from my my/our experience the last few days with v3.12, that the revised functionality of the bookmark long press is a major annoyance. I agree with this feature of subfolder long pressing thouGH -- I just really hope you'll consider reverting the long press to background for individual, home folder bookmarks...

I do see where you are coming from. What it comes down to is that I need to design Privacy Browser in a way that works well for the majority of users. From time to time I receive requests from people for certain features that would be really beneficial to them but are not what is best for Privacy Browser as a whole. In this case, I think that this feature request combined with the already implemented https://redmine.stoutner.com/issues/912 is the best way forward.

Sure....But it seems 912 itself is a response to only 1 user?? :) Whereas I know for sure I'm not the only user who finds the prior-to-912 long press functionality much more useful. Plus, unless you survey your users I don't see how a response to just 1 user automatically means it's a feature the rest of us also find better...

I am also in favour of reverting the long-press behaviour to the way it was before.

It is true that only one user posts on 912. And his request wasn't even actually to do what I ended up implementing. Rather, he was describing a problem where Privacy Browser wasn't optimized for his workflow. Specifically, there were extra steps (closing the keyboard) necessary to open a bookmark in a new tab.

In thinking about his problem, I realized the following three things.

1. Opening a bookmark in a new tab is a common workflow for many users. It isn't one I use much myself, but I know from watching how other people use browsers that many people will use it.
2. There was currently no optimized way to do this in Privacy Browser.
3. I could change the long-press of bookmarks to do this. Because this use case is much more common than that of opening multiple bookmarks in new tabs, this should be the behavior.

It was after I had released 3.12 that I realized I could also address the much less common use case of wanting to open a whole bunch of bookmarks at once by being able to open all the bookmarks in a folder. In my experience watching people use browsers, usually when people want to open a whole bunch of bookmarks at once it is the same set of bookmarks each time. The current long-press behavior of folders is to edit the folder, which was simply the only thing I could think of at the time. Replacing that makes sense because 1) people rarely edit folders, and 2) there is already another way to do that in the Bookmarks Activity.

This planned feature adds the ability to open these set groups of bookmarks easily. It doesn't address your use case scenario of wanting to open an arbitrary set of bookmarks easily. However, I would consider that use case to be very uncommon . As such, Privacy Browser now handles the most common use case with the implementation of https://redmine.stoutner.com/issues/912. It will handle the second most common use case with the implementation of this feature request. And it does not elegantly handle the use case you desire, but it is still possible for you to do so by opening each bookmark one at at time.

My considerations are all made based on how common these use scenarios are. I feel that the direction I am going is the appropriate decision for the majority of users.

I have just asked three of my friends and we all also prefer the previous standalone bookmark longpress behaviour, same as the users above.

I understand that this is how you and your friends use Privacy Browser. I just feel that you represent a very small percentage of how all Privacy Browser's users operate. My responsibility as the developer is to balance everyone's needs.

I also prefer the previous "long press to open bookmark" feature, that has been changed in the recent version of the Android app. I switched back the the previous version after I realised this change.

I don't need the long-press bookmark folder to open all the bookmarks in it, but I'm not against it. It might be useful for others.

My bookmarks are highly structured, but not in a way, that a long-press on folder will give me a positive result. So the best option for me would be to revert to the previous behaviour.

BTW, if I read comment # 8 (https://redmine.stoutner.com/issues/912#note-8) of the initial "issue" right, "Sam Jones" is even using an old, single page version of privacy browser and asked for a change there?

Just like in this conversation, Sam Jones also asked for some things that would make other users very unhappy if I did them. One of the most important things that a developer can do is say "no" when someone wants a feature that is best for them but not best for everyone else. If I implemented every feature that everyone asked for, Privacy Browser would be so unusable that most people would probably not be interested in it at all.

However, seeing as how there are a number of people that are interesting in this subject, I am creating a separate feature request for creating a setting for users to restore the old long-press behavior. You are invited to leave any comments there. If enough people express interest I will revisit my decision to not create a setting that alters how the GUI works.

https://redmine.stoutner.com/issues/932

Soren you have done wonderful thing to create this Privacy Browser. But I too must join the growing list of users who much prefer the old long-press behaviour with individual bookmarks. Yet I also would be okay with this change (#926). So I wish you could do #926 combined with undoing #912. (I will add this comment to le new one #932)

This feature request will be implemented regardless of what ends up happening with #932 because doing so doesn't cost anything. The current long-press behavior of editing a folder was put in place because I felt that a long-press should do something and I couldn't think of anything better to do at the time (there is also another way to edit a folder in the Bookmarks Activity, and editing a folder is a low-frequency activity that doesn't need two methods of access). Now that a better idea has come along I can't think of any reason why it shouldn't switch.