Project

General

Profile

Actions

Feature #932

closed

Add the ability to pin the bookmarks drawer

Added by Soren Stoutner over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Next Release
Start date:
11/22/2022
Due date:
% Done:

0%

Estimated time:

Description

There are a number of users who don't like the change in https://redmine.stoutner.com/issues/912 and whose needs are not met with https://redmine.stoutner.com/issues/926. I am generally not in favor of creating options that modify the way the GUI functions, but I am creating this feature request so that those who would like to use the old long-press behavior (open the bookmark in a background tab while leaving the bookmarks drawer open) have a place to express their interest.

I am not sure what the threshold is, but if enough people express interest I will consider adding such an option.


Files

Actions #1

Updated by Soren Stoutner over 1 year ago

  • Status changed from New to Feedback
Actions #2

Updated by Alain Sachs over 1 year ago

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 change #926. So I wish you could do #926 combined with undoing #912. (I have also posted this comment on https://redmine.stoutner.com/issues/926). Thanks very much.

Actions #3

Updated by Soren Stoutner over 1 year ago

#926 will be implemented regardless of what happens with this feature request. The only hesitation with implementing a setting that changes the long-press behavior is that I generally do not like having settings that modify the GUI (most settings modify how the backend works). Settings that create a separate code path in the GUI tend to add a significant maintenance burden because all of those code paths must be tested in combination anytime any part of the GUI is modified, and because they tend to break with future versions of Android more than other types of settings do. Even more importantly, I have received dozens of requests for GUI modifications that a small number of users would find helpful but most users would not. If I implemented them all the settings screen would become a mess of difficult-to-understand options. I personally dislike trying to navigate apps with tons of confusing settings like that and I am not inclined to impose that experience on Privacy Browser's users.

I have made a few exceptions to this general policy in the past. For example, there is an option to move the app bar to the bottom of the screen and there are controls for day and night mode. In both of these cases there are a significant percentage of users that take advantage of these options, so that user base justifies the effort. There are other examples with less users, like the options to display additional app bar icons and enable full-screen browsing mode. In both of these cases, I feel that the number of users who take advantage of these is still orders of magnitude larger than those who would open a bunch of individual bookmarks at once from the bookmarks drawer.

Therefore, my default inclination is to not implement this feature request. However, there has been enough interest expressed that I have created it so that those who are interested have a dedicated space to express their desires. If there is enough interest, or if someone can point out some aspect of this that hasn't already been discussed, I am open to changing my mind.

Actions #4

Updated by Andi - over 1 year ago

Thanks Soren, for considering this option. For me, the long-press is key for usability and removing this feature via issue 912 was a big surprise.

There might be other simple ways to open individual bookmarks w/o closing the bookmark drawer (e.g., allow to pin the drawer). This way, you wouldn't have to introduce an option regarding user interface behaviour. The user simply could:
- open the bookmark drawer
- pin the drawer (e.g., pin icon top right)
- open multiple bookmarks
- unpin the drawer again

Actions #5

Updated by Andi - over 1 year ago

Now, if I close the drawer with the "<-" arrow icon and reopen the drawer again, I would love to see the pin active again (remember last state). And voila, we (nearly) have the old behaviour back (and we don't need an additional setting for it) :o)

Actions #6

Updated by Peter B over 1 year ago

....Or instead of all this, could just do the simplest thing: revert change 912 and restore the prior longpress behavior :) Given all the other users who share this preference it seems there's no compelling reason to keep that change...

Actions #7

Updated by Soren Stoutner over 1 year ago

Pinning the bookmark drawer is an interesting idea. I would need to think about the details of the implementation, but I could see myself going with that.

As I have already explained more than once, #912 is not going to be reverted because it is in the best interests of the majority of users. Please do not request it again unless you have some information to add that has not already been thoroughly discussed.

Actions #8

Updated by Soren Stoutner over 1 year ago

Thinking through the desired behavior of a pinned drawer, I would assume that tapping a bookmark should open that bookmark in the current tab and close the drawer, but long-pressing a bookmark should open it in a new background tab while keeping the drawer open. The drawer could be closed at any time by tapping in the background space, swiping the drawer closed, or tapping the back arrow. The drawer would stay pinned when reopened, but would revert to being unpinned when the app restarts.

Does anyone recommend a different behavior?

Actions #9

Updated by Andi - over 1 year ago

I have a slightly different idea about the operation with a pinned bookmark drawer:

if pinned:
  • tapping a bookmark: open the bookmark in a front tab, and keeps the drawer open/pinned (otherwise there wouldn't be any difference to the not pinned drawer) (front tab is the opposite of a background tab)
  • long-pressing a bookmark: open the bookmark in a background tab, and keep the drawer open/pinned (old behaviour)
closing the drawer by:
  • swipe the drawer back/closed
  • use the arrow on top (if we are in the bookmark root and not in a subfolder)
  • use Android's back key (well, I'd love to see the old back-key behaviour to navigate the subfolders ;o)
  • unpin the drawer
pin state:
  • if possible, persist the pin status even after the app restarts (but I don't know about the effort)
Actions #10

Updated by Soren Stoutner over 1 year ago

  • Subject changed from Consider adding an option to change the bookmark long-press behavior to Add the ability to pin the bookmarks drawer

Andi - wrote in #note-9:

if pinned:
  • tapping a bookmark: open the bookmark in a front tab, and keeps the drawer open/pinned (otherwise there wouldn't be any difference to the not pinned drawer) (front tab is the opposite of a background tab)

This is an interesting workflow. Perhaps someone wants to open a bookmark in the current tab and then open other bookmarks in background tabs. I can see this being the correct behavior when the drawer is pinned.

closing the drawer by:
  • use the arrow on top (if we are in the bookmark root and not in a subfolder)

Yes, I forgot to mention that before, but the intended behavior would be that the arrow only closes the bookmarks drawer if at the home folder. For subfolders it would navigate up. Also, if the bookmark drawer was closed while in a subfolder it will reopen in the same subfolder (remembers currently selected folder and scroll position), which makes it easier to open other bookmarks later that are also in that folder.

  • use Android's back key (well, I'd love to see the old back-key behaviour to navigate the subfolders ;o)

I think the system back key should always close the drawer. Navigating folders is what the back arrow in the drawer is for (above item.

  • unpin the drawer

Having the drawer automatically close when unpinned would be different behavior than the way things usually work when pinned. More conventional would be that the drawer simply goes back to the unpinned behavior.

pin state:
  • if possible, persist the pin status even after the app restarts (but I don't know about the effort)

This would require creating a setting in the main Settings screen that controls the default pinned status of the bookmarks drawer. I am opposed to this for some of the same reasons as listed above. However, the most important reason of creating a bunch of confusing settings isn't quite as strong as it is fairly easy to create a setting with the description of "Default bookmarks drawer pinned status" and have most people understand what it describes. It is much more difficult to describe a setting that "makes long-pressing bookmarks in the bookmarks drawer open in background tabs without closing the drawer" and have people understand what that is going to do. I have learned this the hard way with the number of times I have had to rewrite the Incognito Mode description. Every one of them have been well written and descriptive (at least I though so at the time), but I can't even count the number of emails and bug report I have receive from people that have misunderstood what it does. Sometimes I feel like I should add "YOU DON'T WANT THIS OPTION" or "PLEASE DON'T SEND ME A BUG REPORT IF YOU ENABLE THIS OPTION" just to get the point across. Which gets to the point that people often have difficulty understanding what changing settings will do, and as a matter of good design philosophy I want to minimize the number of such confusions.

From a bigger perspective, I like this pinned-drawer solution a lot (which I don't know if I ever would have thought up on my own, so thanks for suggesting it) because it is very intuitive. The first time a user opens the bookmarks drawer they will probably know what the pinned button does, and the workflow of enabling and disabling it feels fairly natural.

Actions #11

Updated by stein chen over 1 year ago

My current workaround to the not-being-able-to-open-bookmarks-in-the-background-anymore is that i've copied all my bookmarks to a file and opening said file with a file manager app where it's then opened with PrivacyBrowser, because opening links in the background is still possible. Since this is a particular clumsy and inefficient way of handling bookmarks i would like to ask if there is a way to make PrivacyBrowser open that file as the homepage. (Opening via file://path/to/file doesn't seem to work) This is not meant as a feature request, i am just still fairly new to the whole android system, so i'm just curious if it's possible in general to open local files directly in the browser.

Actions #12

Updated by Soren Stoutner over 1 year ago

Privacy Browser cannot access public files using file:// URIs due to restrictions in Android's Storage Access Framework. You can read a bit about this at https://www.stoutner.com/privacy-browser-3-7/.

If you place your .html file somewhere on the internet and access it via an https:// link that will work. Also, if you have another app on your phone host the file and provide it to Privacy Browser via a content:// URI that will work as well. Note that in this case you need the content:// URI to be persistent. Some apps provide a content:// URI that expires when the app or the device is restarted. Others provide a persistent content:// URI that works in perpetuity. An example of an app that does this is Nextcloud. The file browser you are already using might also produce a persistent content:// URI. If such is the case, you could just make that URI your homepage.

Actions #13

Updated by Andi - over 1 year ago

Soren Stoutner wrote in #note-10:

pin state:
  • if possible, persist the pin status even after the app restarts (but I don't know about the effort)

This would require creating a setting in the main Settings screen that controls the default pinned status of the bookmarks drawer. I am opposed to this for some of the same reasons as listed above.

I'm not sure, there is the need for a "Preserve pin state for bookmark drawer" setting in the settings screen. It's a UI setting, (hopefully) self-explanatory and the user sets it explicitly already in the bookmark drawer. But it's your software and you should follow your own guidelines.

Actions #14

Updated by Soren Stoutner over 1 year ago

There are two ways to preserve settings across an app restart. The first is to use Android's Preferences system (this is what populates the Settings screen), which saves the settings in an XML file managed by the OS. The second is to use a custom SQLite database (this is what Privacy Browser uses to store bookmarks and domain settings).

Using the Settings system requires less work on the part of the developer. SQLite databases require a lot more plumbing of code. If I were to try to save this setting I would probably just add it to the Settings screen. However, I am more inclined to just make it an ephemeral UI that resets on each app start.

Actions #15

Updated by Peter B over 1 year ago

Soren Stoutner wrote in #note-8:

Thinking through the desired behavior of a pinned drawer, I would assume that tapping a bookmark should open that bookmark in the current tab and close the drawer, but long-pressing a bookmark should open it in a new background tab while keeping the drawer open. The drawer could be closed at any time by tapping in the background space, swiping the drawer closed, or tapping the back arrow. The drawer would stay pinned when reopened, but would revert to being unpinned when the app restarts.

Does anyone recommend a different behavior?

I'll gladly accept this resurrection of the old long press behavior -- not as straightforward as before but much better than the current setup. (The disappearance of the drawer after every single long press is extremely frustrating!) I suspect it would also be acceptable to most if not all commenters on #926 who shared my views. So it would be great to have this on one of the upcoming updates.

I too thank Andi for this excellent suggestion!

Actions #16

Updated by Andi - over 1 year ago

Soren Stoutner wrote in #note-14:

There are two ways to preserve settings across an app restart. The first is to use Android's Preferences system (this is what populates the Settings screen), which saves the settings in an XML file managed by the OS. The second is to use a custom SQLite database (this is what Privacy Browser uses to store bookmarks and domain settings).

Using the Settings system requires less work on the part of the developer. SQLite databases require a lot more plumbing of code. If I were to try to save this setting I would probably just add it to the Settings screen. However, I am more inclined to just make it an ephemeral UI that resets on each app start.

Thanks for the explanation. I still would love to see the pin state persisted (but I have to trust you with the implementation) :o)

In the end, it's a big step towards the previous behaviour and just one additional click for me. Thanks for considering this improvement.

Actions #17

Updated by Soren Stoutner over 1 year ago

  • Status changed from Feedback to New
  • Priority changed from 3.x to Next Release
Actions #18

Updated by Soren Stoutner over 1 year ago

The implementation of this works in the following way.

1. When the drawer is pinned it does not automatically close when a bookmark or folder is tapped or long-pressed.
2. The drawer can be closed in all the usual ways: tapping on the space the open drawer does not cover (probably the easiest), swiping the drawer closed, tapping the back arrow if in the root folder, tapping the system back button (or using the system back gesture depending on the OS interface).
3. The pin remembers its status when the drawer is reopened and across restarts (like changing from day to night theme) but is not preserved when the app is closed.

I have attached a screenshot that shows what it looks like when it is pinned.

Implemented in commit: https://gitweb.stoutner.com/?p=PrivacyBrowserAndroid.git;a=commitdiff;h=6f8247bfc1b2c231e99302568a7b962b24174580

Actions #19

Updated by Andi - over 1 year ago

Great, looking forward to testing it!

Thanks again, Andi

Actions

Also available in: Atom PDF