Privacy Browser Android

Created this as a bug in error. Please change to a feature request.

I'm constantly going back and forth with them. It seems like when they're there, I often find them annoying, but when they aren't there, I tend to notice and miss the functionality. An option to enable/disable would be good here!

Maybe can there be a way to implement this as a gesture ? Like how sliding from left brings side pane and from right brings bookmarks, does the API that PB use have any sort of other gesture functionalities ?

Such as two finger swipe up to jump to the top, and vice versa for bottom?

I would be exceedingly reticent to implement this as a gesture, more so than as translucent overlay buttons.

The reason why is that it is almost certain that the gestures would be periodically misinterpreted.

Having a program that doesn't do what you want when you tell it to do it is very annoying. For example, if you swipe but the phone doesn't pick up on the swipe that is annoying.

However, telling a program to do something and it does something different is ten times more annoying. For example, if you try to scroll the screen and it misinterprets the gesture and thinks you want to jump to the top instead that is very frustrating.

I try to minimize any UX designs that have a high probability of periodically resulting in the system doing something other than what was intended. You can read more about this at https://www.stoutner.com/privacy-browser-design-guidelines/.

If I were to implement this I would probably use translucent floating action buttons with a setting that allows users to decide if they want them to be displayed or not. However, as I am generally reticent to create settings that modify the way the GUI works (both because such settings have a high maintenance load and because having too many clutters up the settings so that it becomes difficult for users to find what they are looking for) I would only consider implementing such a system if there were a large number of users who requested it.

Examples of GUI modifications that have reached the necessary level of interested users is the ability to move the app bar from the top of the screen to the bottom and the setting to enable full-screen browsing.

Yeh that'll be a big issue. A great thing about PB gesture you've kept "swipe to refresh" as an option, and not forcing it into the UX. I've had very bad experiences with other browsers that forced this into UX where I mistakenly refreshed a banking page zillions of times and lost the login session.

At least it is possible to implement this as traditional buttons in slide pane (under forward / back options would be preferable)

Along those lines, how much do you use a scroll to bottom feature as compared to a scroll to top? My sense is that scroll to top would be much more utilized, and it is easier to justify adding one entry to the navigation menu instead of two.

Maybe in the future, you can even revamp the whole app bar into 3 rows, one for just URL, 2nd for tabs and 3rd dedicated for such quick navigation gestures and other goodies. There's lot of scope, if implemented right :)

Do you think that would consume too much vertical real estate from many people's tastes?

Mostly jumping to top would be the priority. My justification is that...

I'm imagining a situation where I read many reddit comments, digging deep inside the subthreads, and then suddenly deciding to read main thread.

When there's a lot to scroll in an article, the website authors typically provide in-website arrows by themselves.

So I guess that scrolling to top is preferable, as you thought (if only one is to be implemented).

One thing that can be sensible to do, is to tuck in import/export into settings configuration, and implement both jumps.

ask low wrote in #note-16:

Soren Stoutner wrote in #note-14:

Do you think that would consume too much vertical real estate from many people's tastes?

I have a fairly long aspect ratioed device of 400 ish DPI. And this is how much space that's left...

That question was in regards to adding a third row to the app bar, which, unless the app bar was scrolled, would take away real estate from what is visible in the WebView. There have already been people who have complained about having a second row to display tabs, which I think ends up being an acceptable tradeoff. However, I would expect that adding a third row would be a negative tradeoff for most people.

That question was in regards to adding a third row to the app bar

Oh. That I don't have any issue with.

There have already been people who have complained about having a second row to display tabs, which I think ends up being an acceptable tradeoff.

I used to be the same guy who always tend to complain about minimalism. But ultimately, one has to decide between functionality, or minimalism. Caz both can't go well together.

In terms of landscape view, then yah. A 3rd row would anhilate the screen's vertical real estate (unless you plan to code a different UX for landscape mode). As for the smartphone, typically don't have any concern with a 3rd row.

You might not take issue with a third app bar row, but I think most other users would.

Yup they will lmao. It's probably a temporary idea to just implement page jumps in navigation pane then.

That would be the direction I would be most inclined to go. But first I would probably like to see at least a few more people interested in the feature.

I'm glad to read that this will be implemented soon.
Sometimes, I need to go straight at the bottom of the page to find some links (about, contacts, language, ...).
Sometimes, need to quickly jump down in web sites like Android Developer's because when Privacy Browser is blocking all third-party requests (option enabled by default in my configuration), there is a huge table of contents that I have to manually skip every time I'm going to sites with similar characteristics.

I was only planning to add a scroll to top option, which is usually what is requested. Based on your comment, it sounds like you think a scroll to bottom option would be worth the screen real estate as well. Do you think people would complain about how long the Navigation menu is becoming?

I think they could complain. Even I find that it could be too much having two additional, and non-essential (compared to all the other options), options in the navigation drawer.

What do you think about having a single option, but naming it "v Bottom" when we are at the very top of a page, and in all the other cases naming it "^ Top" (with the appropriate behaviours)?

That might work. Sometimes the browser is not able to tell what the scroll position is (usually because JavaScript is lying about the scroll position). In those cases, this option probably wouldn't do anything anyway. But I think it might add extra confusion to have the command change functionality. I would much rather have it be ghosted if the app thinks it is currently at the top of the screen.

Before implementing this I will probably ask for some feedback on Mastodon. Sometimes hearing from a lot of voices makes things clearer.

There are components in navigation drawer, such as Import/Export & Webview DevTools, which should be inside settings. You can free up the drawer this way.

You technically don't need to quick access those 2 options. There would not exist who imports / exports or accesses webview tools too frequently like 25 to 50 times a day, which deserves to exist right inside navigation drawer.

There is an argument to be made for that, but I think it is best to have both of those in the Navigation drawer.

Import/Export has to do with more than settings, like bookmarks. As such, it is more of an app level feature, so it makes more sense to me that it be here instead of inside of settings. That will become even more apparent when features like Feature #91: Import and export of bookmarks to HTML file are implemented.

WebView DevTools launches an external app (WebView) to edit the settings there. Any changes made inside of WebView DevTools affects all apps on the device, not just Privacy Browser. It is already difficult enough to communicate that to users. Placing it directly inside Privacy Browser's settings would make that even less clear.

What's interesting is, importing / exporting actually do set the browser, which is why they should be in the settings. I'm not sure about Webview Tools, it's okay for it to be in nav panel.

For instance, you can have Import/Export in the settings, right on the top, above Privacy section, for quicker access.

Also, about the bookmarks import/export, you can create an another floating button inside bookmarks panel for that. Currently there are 4. It'll be 5, which won't feel cluttered.

Or even a better place of imp/exp, would be in the top right header section of the settings.

I really feel that Import/Export is in the correct place. I personally dislike it when apps put things like Import/Export in Settings when they aren't actually settings (options that you can set that are preserved across app restarts), but rather functions.

In addition, the current Import/Export imports and exports Settings, Domain Settings, and Bookmarks in a combined SQLite database format. The addition of HTML format for Bookmarks makes a lot of sense in this activity. Splitting the import/export of Bookmarks into two places doesn't make a lot of sense to me.

Well, Importing / Exporting function is technically a setting. What you refer to the options that persist across restarts, should actually be called "Preferences" or "Configuration" in Linux terms.

Exporting / Importing bookmarks to / from html will be a great addon btw. But that's be another issue tracker.

I'm not sure implementing Top / Bottom page navigation shouldn't be a lot of hazzle. I guess UI/UX does matter, but not more than the functionality itself.

I would recommend you read over https://www.stoutner.com/privacy-browser-design-guidelines/. It contains a lot of useful information about the design philosophy that drives Privacy Browser's development.

After reading the guidelines, I can conclude that this top / bottom page navigation feature, is not feasible at all.
This feature must should be implemented as the overlay buttons in the webpage section, which is why it dissatisfies your guidelines.
If it is somehow implemented as a separate function inside drawer, that would also require two taps, which is very inconvenient as per the guidelines.
If it is somehow implemented as some form of gesture, that would interrupt user's workflow.
I think the best way, is to implement it as a gesture, then disable it by default. This way, the users who need top / bottom navigations, will decide themselves whether they really need it or not, meanwhile it also doesn't effect those users who don't prefer these functions as gestures that might come in their workflow.

The most probable implementation I can think of, is to divide the webpage area into 3 sections. Double tap:

- the top section to jump to top
- the bottom section to jump to bottom
- the mid section to toggle fullscreen (as per the current existing fullscreen gesture)

In this implementation, I guess those 3 gestures, should be a toggle inside settings.
Naming this as Gestures section instead of Fullscreen. Then give the user 2 options as below:

Gestures

- Fullscreen browsing mode (toggle)
( double tap to toggle fullscreen browsing mode )

- Hide the app bar (subtoggle of the above)
(hide the appbar that contains the url)

- Jump to top & bottom of the pages (toggle)
(double tap top / bottom section to jump)

As this is a low-use feature, I think a two tap implementation (in the Navigation drawer) is acceptable.

All the other possible implementation have drawbacks that are so significant that I do not see them as viable options.

A low-use in the sense according to you.

But whoever's going to use it, will be going to use it frequently because they need to. And whoever's not going to, they have no issues (like me).
In my experience, I rarely even open nav drawer to check history, or go forward, etc.

The only ones I remember using were Domains & settings couple of times. I think the same is going to happen with this. It'll just be a filler function in the drawer that exists like a function useful as page navigation, but outside of the page experience.

The gesture implementation might has only one drawback, which is the implementation of code itself. Might take a lot of time to rewrite the existing fullscreen gesture.

Usually people only think about how they use the app. However, I have to think about how everyone uses the app. Sometimes something that makes the system better for one user makes it worse for others. My experience is that most people have a very hard time understanding how other people use a program, and an even more difficult anticipating it.

Regarding gestures, they are almost never the correct implementation. This is for two reasons, the second being the most significant.

1. Gestures are often difficult to discover, meaning that it is often not intuitive that the app has a particular gesture unless it is a standard Android gesture that is used system-wide. Ease of discoverability is an important aspect of good UX design.

2. Gestures have a very high rate if misinterpretation, meaning that the system often things that you are initiating the gesture when you don't intend to, and, conversely, often thinks you are not initiating the gesture when you do intend to. As I explained in the design guidelines linked to earlier, the very worst form of a user interface is one that accidentally does something different than what you told it to do.

As such, a gesture is not something I would consider for this feature. In fact, generally, I will probably never add any future gestures to Privacy Browser beyond the double-tap to enter/exit full-screen browsing (which requires a gesture to exit because there are no other GUI elements visible in full-screen browsing), and those that are inherited from the standard Android OS, like swiping to scroll and pinching to zoom.

Well tbh, if that is the way you intend to go with UX design philosophy, even the double tap to fullscreen shouldn't exist in the first place (even though it comes off bydefault). Could've been a simple toggle inside settings.

I've came up with the gesture implementation idea for this top/down navigation, only for the reason being one form of gesture already existed.

When I first tried dt2f, I usually did not like it at all. And went back disabling it, with appbars being visible all the time.

As I said, those who really need a feature, will use it frequently. And those who don't find any use of it, they won't dabble into it in the first place. Hence I find pushing this feature inside nav drawer inconvenient for the users who need to use it frequently.

However, I do respect your decision whichever it is, because I'm not the one who actually in need of this feature.

It is appropriate for full screen browsing to use a gesture, because in some of the modes, when it is enabled, it is not possible to access any of the other GUI menus or settings. So, if there wasn't a way to exit with a gesture there would be no way to exit at all.

Beyond that, some of us are old enough to remember when many text display apps had a full screen browsing mode, and double tapping was the standard way of entering and exiting it. The number of text display apps that support full screen browsing is diminishing, mostly because phone screen sizes are getting so large that few people use it, but the fact that this was a common gesture helped with the discoverability problem.

In that regard, full screen browsing is unique. As I mentioned above, I do not anticipate ever adding any other gestures to Privacy Browser Android that are not standard OS gestures that the app inherits. Beyond those mentioned above, another example of a standard OS gesture (which works in Privacy Browser without me having to do anything to make it happen) is drawer peaking as explained in Guide > Interface inside the app.

I believe that even fullscreen does not need to be a gesture.
The benefit of fullscreen in Android app, is that it hides the status bar & navigation bar. Then it hides the appbar when scrolled down & reappears when scrolled up. This behavior is very normal in many applications I've found of.

The reason I didn't like the fullscreen implementation of pb, is because that isn't how it is implemented. Currently the Android versions above 10, does not hide status bar under fullscreen if you noticed it. The main reason is the Overscan API being completely removed. From that day, I haven't used fullscreen implementations of any apps whatsoever. Because they do hide status bar, but leave a blank line instead of pulling the app in it's place.

As for the top/down navigation, whether it has to be a gesture or a nav drawer function, I have no objections, as it's upto you and the requests you get from users anyways.

v ... wrote in #note-47:

it's strange that the app is not doing the same in your case. You should rise an issue for that behaviour.

The appbar didn't hide in mine because I didn't enable the sub toggle Hide the appbar url. So not an issue.

Anyways, the actual issue we should open, is the lack of utilization of the status bar area under fullscreen.

OK, my bad.

Feature #1073: Add an option to display under camera cutouts in full screen browsing mode

For clarification, this doesn't have anything to do with the status bar. It has to do with newer versions of Android, by default, dodging camera cutouts in full screen browsing.

Regarding the hiding of the app bar in full screen browsing mode, if the app bar is set to not scroll and and to be hidden in full screen browsing, there is no way to display it in full screen browsing. Hence, the need for a gesture to exit full screen browsing.

Well however this will be implemented: Please don't remove well established settings from the navigation drawer, at least not the import/export function, because at least i use it as a way to have different profiles (e.g. for multiple domain settings of the same domain) and some of my friends are using it as a quick way to change between NSFW bookmarks in one profile to family-friendly only bookmarks in another.

@stein chen He's not going to. And also I would advice you that's not the way to have different profiles. Android has a dedicated app duplication mechanisms, such as parallels.

@stein chen It is interesting you are using Import/Export that way. Although I hadn't ever though it would be used for that purpose, I certainly consider it an acceptable use case. One of the interesting things about developing software is that people use what you have built in ways you don't expect to solve the problems they have. I try not to break any of those workflows unless it is necessary to fix a bigger problem that affects a larger number of users.

@ask low It is true there are various other methods of maintianing different app settings. The only official one I know of that is built into AOSP is by setting up separate OS users (I believe up to four plus one guest are currently supported). I use this with my kids, but it does take a bit of time to switch between profiles and there are some restrictions on what can be done on a non-primary profile.

Oh I forgot about multi user profiles. They're great option too. But yah, you gotta setup your workflow again from scratch, just for multiple profiles of a single app...

@everyone Thank you for your suggestions, but i already considered different approaches beforehand and using multiple settings-backups has proved to be the most efficient way for me, since restarting Privacy Browser with a different backup|profile (i've named them by what i want to do: e.g. "research.pb", a heavilly restricted profile where most websites are pure html [yes, i am also aware of lynx and other textbrowsers available via termux, but sometimes i still like to be able to swipe-scroll trough content instead of lynx's archaic way of keycombos] to avoid distractions , etc.) even on my snailphone only takes a second or two, and isolating multiple instances of the browser via multi-user apps [e.g. insular] wasn't my goal to begin with. Perhaps i should've been clearer in my last post, but it was way past bedtime when i composed it, so i apologise for causing any confusion.

I kind of like the idea of using the Import/Export system to maintain different profiles in Privacy Browser. This is basically what the entire Domain Settings system is setup to do, but there can be situations where you have needs that move beyond that. For example, consider a human rights worker under a repressive regime. They can create one profile that contains bookmarks and domain settings for the work that they are doing, which could be encrypted and saved in a file name with an extension that looks like it is a different type of document. Then they could have another profile that looks innocuous, which is what is normally loaded. If the police capture them, all they will see is the innocuous profile. Cursory searches of the phone will not reveal any sensitive information. Deep searches of the phone will reveal a document with Privacy Browser's settings that is encrypted, but it just looks like a corrupted .jpg or .odt. This provides plausible deniability, even under torture, as the person can say, "I don't know why that file won't open in LibreOffice. It used to. It probably just got corrupted somehow."

I think using import/system as profile system is useless. Caz it only deals with settings/Domains/Bookmarks. No cookies involved, as it'll be prone to cookie theft.

This doesn't effect anything related to top/down page navigation. I wonder where this discussion is flowing...

By default, all cookies are deleted every time Clear and Exit is run, which happens every time the last tab is closed. So, I would not expect that anyone using Import/Export to change profiles for security reasons would end up with dangling cookies hanging around. You can read more about how Clear and Exit works in Guide > Local Storage inside the app.

@ask low you were the one who recommended moving Import/Export from the Navigation Drawer to a location that was less easy to reach. As such, it was appropriate for @stein chen to explain why that would be detrimental to him and other users. When you suggested that his use case was invalid, it was appropriate for him and me to explain why that use case is valid and why Import/Export should maintain its place as an easy to reach feature.

Neither I promote cookie exports, nor I insist changing any UI/UX.
I addressed a situation whether if one had issue scrolling through the navigation drawer to access these functions, in this case, moving some functions into the settings could've been a direction that exists. But as you said that it's not feasible and breaks your guidelines, we already opted out of this discussion. Same for the gesture implementation.
The only option right now, is to place top/down functions in the nav drawer without any other interface changes.

Regarding the cookies, I bought that up because that practice is very insecure & could be prone to theft.

And regarding the importing of multiple backups as a sort of profiles, didn't make sense to me. Because importing/exporting multiple times, maintaining those backups, as well as encryption keys is very tedious task. I would rather request a profile feature into pb for that.

At this point, my plan for implementing this feature is to add one item to the Navigation Drawer, which will be Scroll to Top. I currently don't think I will add a second Scroll to Bottom option, because I think it would be used too rarely to justify the screen real estate. I might go the route already discussed about having the entry switch between Scroll to Top and Scroll to Bottom, but I would have to try it first and see how well it works. It also requires deciding what it should do if the page is in the middle. Probably Scroll to Top. In any case, my intention is to post a poll on Mastodon before implementing the feature asking users for any insights that have not already been discussed.

https://fosstodon.org/@privacybrowser

Is there a way to have 2 split buttons in one row ? That would make sense, because we aren't using enough horizontal space in the nav drawer.

Not with Android's standard Navigation Drawer.

https://m2.material.io/components/navigation-drawer/android#using-navigation-drawers

Implementing a custom navigation drawer isn't something I am likely to do for just this feature. However, if for some reason there was a different feature that required me to implement a custom navigation drawer, then splitting the Scroll to Top and Scroll to Bottom controls in half horizontally could be an excellent idea.

Regarding the decision while in the middle of the page, I would suggest you to refer to the current position of the page.

pseudocode:
if (current_pos > page_length / 2)
then
entry = scrollToTop
elif (current_pos <= page_length / 2)
entry = scrollToBottom
else
entry = blank
fi


I just know beginner level coding btw.

I'm not sure that would end up being the desired behavior. For example, you gave this scenario earlier:

I'm imagining a situation where I read many reddit comments, digging deep inside the subthreads, and then suddenly deciding to read main thread.

It would not be uncommon to be deep inside a subthread and still be in the top of half of the page.

I think that, with this command, people will almost always want to go back to the top of the page. Very rarely do I think people will want to go to the bottom of the page. If that is correct, it would make the most sense for the command to always take them back to the top unless they were already at the top, in which case the only useful thing the command could do would be take them to the bottom of the page.

Understood that made sense. But bottoming can also be beneficial. Sometimes you have to read site footnotes such as Privacy Policies, about section, etc.
At least have Scroll to Bottom, only when you're at the top of the page. This way, we can have both functionalities, without any unusual experience.
This might be necessary because ScrollToTop function becomes unusable when you're already at the top. So, having ScrollToBottom when you're on top would make sense.

I've made the same suggestion earlier in this topic. We should keep the logic simple, so it'll be simple to implement and maintain.

v ... wrote in #note-24:

[...]
Sometimes, I need to go straight at the bottom of the page to find some links (about, contacts, language, ...).
Sometimes, need to quickly jump down in web sites like Android Developer's because when Privacy Browser is blocking all third-party requests (option enabled by default in my configuration), there is a huge table of contents that I have to manually skip every time I'm going to sites with similar characteristics.

v ... wrote in #note-26:

[...]
What do you think about having a single option, but naming it "v Bottom" when we are at the very top of a page, and in all the other cases naming it "^ Top" (with the appropriate behaviours)?

After reading the discussion, I would appreciate having either the two options or only one that changes depending on whether the user is on top or middle/bottom of the page. I'm on the same use cases as @v ....

The only problem I can think of about having only one item that changes its behaviour is that a new user wouldn't know about how this work. It may be worth mentioning that in the interface tab of the user guide.

As a side note, I've just discovered the Navigation Drawer thanks to this thread, especially the Forward option :D. Previously I had thought of it as just the "Settings" Drawer and never realized there was a Forward button. For Backwards I personally use the Android back button (the system wide button) and really missed a forward action sometimes. No more!

Regarding how long the Drawer would become, it wouldn't affect me (and users with small screen) because I already don't see all items, only ten of them. And it makes sense considering it's called Navigation Drawer that the most prominent items are those regarding navigation, which seems to me that are the first eight options, until Downloads.

If we would like to make room, we may get rid of Clear and Exit, as the very same action is performed by the Close sign or swiping app gesture if there were more than one tab open (if I didn't got it wrong); and maybe the Backwards button as well. But I personally think it is not necessary to remove those options. There are enough room.

@Juan Manuel I don't think removing any existing functions from Nav drawer help implementing Top/Bottom Scrolling. Although it's okay to have more functions, as you said in your case they're already crossed the screen real estate threshold. I don't know why it would be an issue.
@Soren Stoutner I don't think implementing both functions separately would be an issue at all, other than filling up the Nav Drawer with 2 more functions. I was the one who gave you the idea of implementing this in Nav Drawer. I hope you don't torture your brain just for this feature lmao.

We'll think about Nav Drawer cleanup until unless someone brags about it's function list being too many.

As @Juan stated that if you implement only one button with two functions, it might complicate and confuse users, and you might need to write more user guide documentation.

Isn't it better to be named Jump to Top/Bottom, instead of Scroll ?
Scrolling is a user executed task, whereas Jump word correlates to the browser function.

I think scroll sounds better in this case.