Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/Suggestion: Option to move UI/Address bar to bottom of screen #7511

Closed
Brave-Matt opened this issue Mar 6, 2019 · 35 comments
Closed
Labels
feature/url-bar feature-request OS/Android Fixes related to Android browser functionality priority/P2 A bad problem. We might uplift this to the next planned release.

Comments

@Brave-Matt
Copy link

Description

This is an updated consolidated issue for the "Bottom address bar" feature commonly requested by mobile users (#54, #7356).

Reasoning: Users should be offered this option for several reasons - the main one being the high variability of device types and screen sizes that a user may be browsing on. Having the same uniform layout across all devices works, but is not practical from a UX standpoint.

Someone that downloads and uses a Samsung Galaxy Tab A to browse Brave inherits this burden by default based only on the device they're using - this is inflexible and furthermore, is something few other browsers offer as an option. Including this option reflects well on us as it's implementation is (almost entirely) user interest focused.

Alternative option: At the same time, space on-screen is limited and there's no way to comfortably include every option/UI element on screen at once. One solution to this issue would be to include an option/button that jumps focus to the address bar when pressed. This way, the address bar itself needn't be moved, but users can still easily access it without having to reach to the top of their device every time (like our friend with the Galaxy Tab A).

This solution still involves "adding" something to the UI which is still the core issue (screen real estate). To solve, I would propose the following solution:

Toggle between Search and New Tab button

  1. When browsing, Search button/icon is shown
  2. If the user wants to search, tapping "Search" moves focus into address bar (keyboard is displayed)
    • image
  3. When focus is given to address bar: "Search" icon flips to "New Tab" button:
    • image
  4. When on New Tab Page: "New Tab" button flips back to "Search" icon - if you're already on a new tab, its unlikely you're going to want to open another new tab.

Toggling this way increases users ease of access and overall experience without compromising screen space or moving any additional UI elements.

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@Brave-Matt
Copy link
Author

image

@srirambv
Copy link
Contributor

srirambv commented Mar 6, 2019

This is purely personal opinion and feedback

  1. Should have a new tab button on the bottom bar. Reasoning for this is in current implementation opening a new tab takes three click/taps. Kabob menu -> New Tab -> Tap on URL bar. It should be just one tap/click on the newtab button which should open a new tab and put focus on the URL bar (similar to iOS behaviour)
  2. Search button isn't required on bottom bar. Tapping on the URL bar makes the search option again. Even in one hand use its quite easy on smaller screen devices to just tap on the URL bar. Even on the bigger screen devices its quite easy if you are used to one hand use. Adding search button instead of New tab on iOS got us pretty bad feedback and was reverted again. Although different platform screen sizes(big) are pretty much same on both Android and iOS devices
  3. Home button - Should stay. Its used more often than thought. We've received some bad feedback when this was hidden/removed in some older builds which is why it was made as default. User still has the option to disable it

Suggestion on the bottom bar on how to satisfy both set of users who need search and new tab.

  • Default is to have new tab button on the bottom bar
  • Long press on new tab button brings up New Private tab and Switch to search
  • Switch to search removes new tab button and replaces it with Search button
  • Long press on Search button brings up Switch to New tab
  • Disable home button from settings puts both Search and New tab on the bottom bar

@LaurenWags
Copy link
Member

I’d like to second some of @srirambv suggestions and feedback above. Based on my personal browsing habits, his suggestions make the most sense to me and allow for satisfying a range of users. I know personally I'd get the most use out of a new tab button while I wouldn’t get much, if any, use from a search button. The long press idea is a good solution to keep both options.

Additionally, in regards to the home button, I don't think we should remove it. There were many negative reviews left when it was removed and we reverted. Having the ability to show/not show it in settings should be kept.

@Brave-Matt
Copy link
Author

@sriramv I had suggested the same thing to james when we were discussing it. Long press was my first choice this was an alternative - what do you think @jamesmudgett?

@Javi
Copy link

Javi commented Mar 8, 2019

Just wanted to chime in as I'd love to use Brave but this feature is a must have for me.
The current mobile browser UX leader for Android at the moment seems to be Opera, and their bottom bar is a large part of it (the other being text reflow to prevent sideways scrolling). Their button layout may be a good reference as a starting point as it is at least good enough for most cases. They have a back and forward button with history on long press, a home button that becomes a button to focus the address bar when on the home (to avoid straining fingers going to tap it at the top where it resides), a button to show your tab list that also works as a new tab button on long press, and a wildcard 'Opera' button that opens up a menu with options.

Hopefully that'll be of help as inspiration!

@srirambv
Copy link
Contributor

srirambv commented Mar 8, 2019

They have a back and forward button with history on long press,

Yes this is a missing feature on Brave IMO. We should think of having back and forward buttons on the bottom bar. That gets a huge +1 from my side. Also I've seen reports of Android trying to get rid of hardware backbuttons in future(just concept for now) so we will lose the actual back button so its a good idea to have them on the bottom bar

@bmalin92
Copy link

bmalin92 commented Mar 9, 2019

I'm glad to see this has been logged! I've loved my switch to Brave, but my small hands would greatly appreciate this feature.

@srirambv
Copy link
Contributor

+1 from @nejsimon for search button on bottoms bar via brave/browser-android-tabs#1331

+1 from @miladmaz12 for having both search and new tab button via brave/browser-android-tabs#1331

@jtbrown3
Copy link

Please provide an OPTION (in Settings->Basics ?) to enable/disable the new split top/bottom toolbar/navigation bar.

This is a significant usability departure from both prior versions and from the default Chrome mobile behavior. While I can understand that this new layout may be desirable for some users - other users like myself do not like it forced upon us.

IMHO, there should be an OPTION to turn this either ON or OFF.

@miladmaz12
Copy link

@jtbrown3 Post that as a new issue thread - it might get more attn.

@jtbrown3
Copy link

jtbrown3 commented Mar 15, 2019

@jtbrown3 Post that as a new issue thread - it might get more attn.

Thanks @miladmaz12, I did just as you suggested:

@ericdunbar
Copy link

ericdunbar commented Mar 16, 2019

Adding my two cents worth of opinion:

I HATE having the Home and the Bookmark buttons on the bottom tab. I NEVER use either button and dislike having to waste time on avoiding them.

Why not have an advanced setting where you can:

  1. Control what buttons appear on this navigation bar (i.e. the only useful ones are new tab and switch tab); and,
  2. Control where the navigation bar appears.

How hard can it possibly be to implement that? A few lines of code to display the switches in the Settings page and bind them to a preference storage variable and a few if statements to determine whether to display the buttons on the navigation bar when the screen is being laid out! None of this costs processing cycles or adds bloat.

@nejsimon
Copy link

I feel there's a lot of redundancy in the current design. In the default "duet" bottom bar from chrome there's som redundancy too but it's worse in brave.

You have the home button which is just another bookmark so you could access whatever home page you have by clicking the bookmarks button. And it'll open as well when you open a new tab. So now there are three quick ways of accessing the home page. Also I personally don't use the home page nor the bookmarks. It's pretty much always faster to just enter a few letters in the URL bar and let it autocomplete rather than going trough the bookmarks and I see no use of having a special bookmark always accessible with one click, there's no page I need that much.

Then there is the "show tabs" button. Clicking it makes a "new tab" button appear at the middle of the bottom bar. But there's now also a "new tab" directly at the bottom bar. So two quick ways of opening a new tab.

But of course there's no longer a way to actually enter a URL without stretching your thumb all across the screen. So even if you have two quick ways of opening a new tab you'd still have to do this maneuver making the UX inconvenient.

@xdgc
Copy link

xdgc commented Mar 17, 2019

Another thread directed me here. I can't tell what kind of opinion expression the team is looking for, but my preference is for the location bar and the home/new tab/ellipsis buttons all to remain at top. I really hate having them at bottom.since the update. Tempted to disable auto updates and revert until a decision is made.

@srirambv
Copy link
Contributor

@anthonypkeane @SergeyZhukovsky @jamesmudgett adding P2 label to prioritize the design.

@bjg222
Copy link

bjg222 commented Mar 17, 2019

I think that the top/bottom distinction should be a user selectable option. There are certainly people who like nav at the bottom, especially for large screens, but it is very controversial for others, who just feel like it is a waste of screen real estate. The currently implemented solution, having the address bar at the top and menu at the bottom, feels like the worst possible compromise, because you lose both top and bottom space. For those who want the bar at the bottom, let users select to move the whole bar to the bottom. No matter what the solution, it should absolutely be optional, because the best way to alienate users is to tell them they don't have any control over the way their apps look.

Additionally, the new bottom bar doesn't obey the coloring provided by websites like the top bar does. For instance, Ars Technica colors the address bar black to match their black page (or at least, the browser colors the bar to match the page). The bottom bar ignores this, remaining a stark white color, which is really incongruous and a bit of an eye sore. Please ensure that whatever the final solution, the coloring is consistent!

Screenshot_20190317-140926

@mikehewritesit
Copy link

mikehewritesit commented Mar 18, 2019

The new interface should be a user option, and it's not a good sign from the users' point of view that ithe change was rammed down our throats without that being the case.

I can't speak for others, but personally I'm giving Brave about two weeks to give us the option to return to the old style before I switch back to using Chrome. If I make that change, it won't only be on my phone, but also on my other devices, and you won't win me back any time soon.

@tclaybor
Copy link

Thanks for your hard work and open forum to listen to us here, devs. If you can make it an option that's great, if not, oh well that's fine too. I understand I'm in no position to make demands and if there's anything I can do to help, please let me know.

Cheers!

@srirambv srirambv transferred this issue from another repository Dec 23, 2019
@srirambv srirambv added OS/Android Fixes related to Android browser functionality feature-request feature/url-bar priority/P2 A bad problem. We might uplift this to the next planned release. labels Dec 23, 2019
@srirambv
Copy link
Contributor

+1 from @Morkowski via https://github.com/brave/browser-android-tabs/issues/2389

@Brave-Matt
Copy link
Author

Closing this, as this issue is old and the feature has already been implemented. 🎉

@rtcarey
Copy link

rtcarey commented Nov 15, 2021

I don't see that this feature has been implemented, unless you consider the search icon on the bottom a compromise.

@SolarDesalination
Copy link

Naver Whale, Vivaldi, Yandex, Kiwi all offer this feature. Would be real nice for us with short thumbs..

@theshatterstone
Copy link

Hello, @brave can we get some update on this? Are we ever going to get a bottom address bar on mobile (a simple way to do it would just be a toggle to flip the top and bottom bars, while keeping the ability to disable that other bar), or should I just stick with Vivaldi?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature/url-bar feature-request OS/Android Fixes related to Android browser functionality priority/P2 A bad problem. We might uplift this to the next planned release.
Projects
None yet
Development

No branches or pull requests