Android Forums - View Single Post

xScope · February 3rd, 2010, 08:11 PM

Wow. This is long..........should I read through it? LOL. THANKS.
It's like a dissertation.
Please update to the latest version. It will not let the addressbar in partway but a little jerky.

There are basically three things up there:
1. the system status bar
2. the tabs
3. the address bar.

Apparently, the current approach is not very consistent yet. One thing I guess most of us will agree on handling appearing and disappearing of each one of them: swiping is the most intuitive way (although making status bar showing or disappearing with a swipe has not been implemented yet). Now the question becomes how? I certainly will incorporate all the ideas you have brought up and others (NeuroNY).
My plan is that eventually, I will have an update just for making all kinds of customizations so that users can choose the way they like how things should work.
Current stage is still like Can-do or Proof of concepts. So everything is kinda rough and fixed. But they can be changed by users eventually.

Quote:

Originally Posted by tbain98

I want to expand upon what NeuroNY began describing, since his comments seemed to pass unnoticed. The concept of dragging the address bar into and out of the screen is a great one, and X, congrats for thinking of it. However, I think that the actual implementation isn't as user-friendly as it could be, due largely to the fact that that the current implementation co-opts the existing use of the up-or-down swipe motion (i.e. scrolling of the content pane).

Currently, if the address bar is not visible and the user makes a downwards drag motion in the tab bar (if visible) or anywhere "near" the top of the content area (on my Droid, "near" appears to be within approximately 2x the height of the address bar), the content area will scroll and the address bar will simultaneously be displayed.

If the address bar is visible and the user makes an upwards drag motion anywhere "near" the top of the content area, the content area will scroll and the address bar will simultaneously be hidden. Dragging upwards in the tab bar (if visible) and the address bar has no effect. (Of special note: dragging upwards on the notification bar doesn't cause the notification bar to go away. I agree with what NeuroNY said: everything else aside, when I do an upwards drag on the address bar, it should be interpreted as a hide request.)

With this behavior, it's way too easy to accidentally display/hide the address bar, especially when the Droid is in landscape mode; in this mode, and with the Android Notification Bar, the tab bar, and the address bar all visible, only ~60% of the total screen area can be used for scrolling without displaying the address bar. In addition (but much less important), to me it's really annoying that the content scrolls when I'm trying to display the address bar. I want the content to scroll when I tell it to scroll, and the address bar to appear when I tell it to appear, and neither one to happen when I tell the other to occur.

To me, all of these problems ultimately stem from the fact that you're using the drag action on the content area to control something outside of the content. So I'd propose the following instead:
* When the tab bar is visible, downward drags on the tab bar (or the partially-displayed address bar) will display the address bar; all drags on the content area will apply only to the content area.
* When the tab bar is not visible, downward drags "near" the top of the content area (or on the partially-displayed address bar) will display the address bar (and I'd vote for not scrolling the content, unless there's some special case where this is required). If the address bar is partially displayed, the calculation of "near" would include the partially-displayed address bar, so a smaller and smaller portion of the content area would accept input towards the address bar as the address bar became more-completely displayed. "Near" should be narrowed to be only the height of the tab bar, to limit the likelihood of unintended displays of the address bar.
* Upward drags on the tab bar (if visible) or on the address bar will hide the address bar (and will not scroll the content). All upward drags on the content area will only scroll the content (regardless of whether the tab bar is visible).

With this alternate approach, we'll only show/hide the address bar in response to drags on the tab bar and/or the address bar, unless neither one is visible (and in that case, we'll limit the amount of content area that controls the address bar).

One final thought: is there actually value to smooth-scrolling the address bar? It looks pretty, but does anyone actually use it when it's halfway down? (I don't, but maybe someone else does...) Should the up/down drag just fully show/hide it rather than doing it partway? If it was an all-or-nothing situation, that would simplify some of the logic I proposed above (you wouldn't have to worry about downward drags on a partially-displayed location bar, and you wouldn't have to recompute how much of the content area was still "near" the top when the location bar was partially displayed). Just something to consider.

With all that said, I think this is a great browser, and I'm really impressed with the obvious amount of work that X has put into it and with his responsiveness to the comments and suggestions people make on this forum. It's very much appreciated...