Project

General

Profile

Actions

Feature #144

closed

Add a navigation menu entry to scroll to the top of page.

Added by Brian Toole over 7 years ago. Updated 11 months ago.

Status:
Closed
Priority:
Next Release
Start date:
06/09/2017
Due date:
% Done:

0%

Estimated time:

Description

On long websites, some browsers have a floating shortcut to return to the top of the page, generally located on the lower right portion of the screen. This would be a welcome addition.


Files

Screenshot_20230623-001032.png (122 KB) Screenshot_20230623-001032.png ask low, 06/22/2023 11:41 AM
Screenshot_20230823-075947.png (231 KB) Screenshot_20230823-075947.png For instance, this is how fullscreen looks on ny device (Pixel 7) ask low, 08/22/2023 07:31 PM
pb.not-full-screen.png (236 KB) pb.not-full-screen.png v ..., 08/23/2023 06:07 AM
pb.full-screen.png (252 KB) pb.full-screen.png v ..., 08/23/2023 06:07 AM
Actions #1

Updated by Brian Toole over 7 years ago

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

Actions #2

Updated by Soren Stoutner over 7 years ago

  • Tracker changed from Bug to Feature
  • Assignee set to Soren Stoutner
  • Priority changed from 2 to 3

I personally find these types of floating buttons to be annoying because they layout on top of the website, but I am not opposed to adding the option as long as it is off by default so that only those who want it can turn it on.

Actions #3

Updated by Brian Toole over 7 years ago

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!

Actions #4

Updated by Soren Stoutner over 7 years ago

  • Priority changed from 3 to 2

I will plan to implement this in the second half of the 2.x series.

Actions #5

Updated by Soren Stoutner almost 6 years ago

  • Priority changed from 2 to 3.x

I am going to wait on this. I'm not completely against it, but I am not sure I will do it either.

One possibility would be to implement translucent FABs, one that scrolls to the top and the other to the bottom.

Actions #6

Updated by Soren Stoutner over 3 years ago

  • Status changed from New to Closed

I have decided not to implement this feature. I don't the idea of having a floating button covering up the website.

Actions #7

Updated by ask low over 1 year ago

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?

Actions #8

Updated by Soren Stoutner over 1 year ago

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/.

Actions #9

Updated by Soren Stoutner over 1 year ago

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.

Actions #10

Updated by ask low over 1 year ago

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)

Actions #11

Updated by Soren Stoutner over 1 year ago

  • Status changed from Closed to New

Putting these options in the navigation menu is an interesting idea that I hadn't considered before.

The only objection I would have to that is it would make the navigation menu longer and force some of the options off the screen on some devices. However, I am less opposed to that idea than to translucent floating action button that cover parts of the website itself.

I have reopened this feature request. If a number of people express interest in it I will consider implementing it.

Actions #12

Updated by Soren Stoutner over 1 year ago

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.

Actions #13

Updated by ask low over 1 year ago

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 :)

Actions #14

Updated by Soren Stoutner over 1 year ago

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

Actions #15

Updated by ask low over 1 year ago

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).

Actions #16

Updated by ask low over 1 year ago

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...

Actions #17

Updated by ask low over 1 year ago

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

Actions #18

Updated by Soren Stoutner over 1 year ago

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.

Actions #19

Updated by ask low over 1 year ago

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.

Actions #20

Updated by Soren Stoutner over 1 year ago

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

Actions #21

Updated by ask low over 1 year ago

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

Actions #22

Updated by Soren Stoutner over 1 year ago

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.

Actions #23

Updated by Soren Stoutner over 1 year ago

  • Subject changed from Shortcut to return to top of page to Add a navigation menu entry to scroll to the top of page.
  • Priority changed from 3.x to Next Release

Actually, thinking about it, I have had enough people express interest in this feature over the years that I am willing to implement it now that you have made the excellent suggestion to put it in the navigation drawer.

Actions #24

Updated by v ... about 1 year ago

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.

Actions #25

Updated by Soren Stoutner about 1 year ago

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?

Actions #26

Updated by v ... about 1 year ago

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)?

Actions #27

Updated by Soren Stoutner about 1 year ago

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.

Actions #28

Updated by Soren Stoutner about 1 year ago

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

Actions #29

Updated by ask low about 1 year ago

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.

Actions #30

Updated by ask low about 1 year ago

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.

Actions #31

Updated by Soren Stoutner about 1 year ago

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.

Actions #32

Updated by ask low about 1 year ago

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.

Actions #33

Updated by ask low about 1 year ago

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.

Actions #34

Updated by ask low about 1 year ago

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

Actions #35

Updated by Soren Stoutner about 1 year ago

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.

Actions #36

Updated by ask low about 1 year ago

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.

Actions #37

Updated by Soren Stoutner about 1 year ago

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.

Actions #38

Updated by ask low about 1 year ago

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.

Actions #39

Updated by ask low about 1 year ago

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)

Actions #40

Updated by Soren Stoutner about 1 year ago

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.

Actions #41

Updated by ask low about 1 year ago

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.

Actions #42

Updated by Soren Stoutner about 1 year ago

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.

Actions #43

Updated by ask low about 1 year ago

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.

Actions #44

Updated by Soren Stoutner about 1 year ago

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.

Actions #45

Updated by ask low about 1 year ago

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.

Actions #46

Updated by ask low about 1 year ago

For instance, this is how fullscreen looks on ny device (Pixel 7)

Updated by v ... about 1 year ago

I too see the status bar hiding only, with the inability to using this little space. However, you can see in the second screenshot that switching to the full screen mode is not only hiding my status bar, but it's also hiding the app bar (mine being located at the bottom). So, it's strange that the app is not doing the same in your case. You should rise an issue for that behaviour.

Actions #48

Updated by ask low about 1 year ago

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.

Actions #49

Updated by v ... about 1 year ago

OK, my bad.

Actions #51

Updated by Soren Stoutner about 1 year ago

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.

Actions #52

Updated by Soren Stoutner about 1 year ago

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.

Actions #53

Updated by stein chen about 1 year ago

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.

Actions #54

Updated by ask low about 1 year ago

@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.

Actions #55

Updated by Soren Stoutner about 1 year ago

@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.

Actions #56

Updated by ask low about 1 year ago

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...

Actions #57

Updated by stein chen about 1 year ago

@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.

Actions #58

Updated by Soren Stoutner about 1 year ago

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."

Actions #59

Updated by ask low about 1 year ago

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...

Actions #60

Updated by Soren Stoutner about 1 year ago

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.

Actions #61

Updated by ask low about 1 year ago

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.

Actions #62

Updated by Soren Stoutner about 1 year ago

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

Actions #63

Updated by ask low about 1 year ago

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.

Actions #64

Updated by Soren Stoutner about 1 year ago

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.

Actions #65

Updated by ask low about 1 year ago

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.

Actions #66

Updated by Soren Stoutner about 1 year ago

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.

Actions #67

Updated by ask low about 1 year ago

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.

Actions #68

Updated by v ... about 1 year ago

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)?

Actions #69

Updated by Soren Stoutner about 1 year ago

  • Status changed from New to In Progress
Actions #70

Updated by Soren Stoutner about 1 year ago

  • Status changed from In Progress to Feedback
Actions #71

Updated by Juan Manuel about 1 year ago

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.

Actions #72

Updated by ask low about 1 year ago

@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.

Actions #74

Updated by ask low 11 months ago

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.

Actions #75

Updated by Soren Stoutner 11 months ago

I think scroll sounds better in this case.

Actions

Also available in: Atom PDF