I want to expand upon what NeuroNY began describing, since his comments seemed to pass unnoticed. 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. 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). 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). All upward drags on the content area will only scroll the content (regardless of whether the tab bar is visible). * Upward drags on the tab bar (if visible) or on the address bar will hide the address bar (and will not scroll the content). "Near" should be narrowed to be only the height of the tab bar, to limit the likelihood of unintended displays of the address bar. 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. * 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). * 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. 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. 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. 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.
#XSCOPE BROWSER FOR ANDROID ANDROID#
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. 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.) (Of special note: dragging upwards on the notification bar doesn't cause the notification bar to go away. Dragging upwards in the tab bar (if visible) and the address bar has no effect.
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. scrolling of the content pane).Ĭurrently, 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. 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.
The concept of dragging the address bar into and out of the screen is a great one, and X, congrats for thinking of it. Click to expand.I want to expand upon what NeuroNY began describing, since his comments seemed to pass unnoticed.
0 kommentar(er)
