The floating, fixed-position header bar (header bar always at the same place at top of the screen while other things scroll) causes a number of problems in the app, including:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=32917 - It's difficult to tap into the search box * https://bugzilla.wikimedia.org/show_bug.cgi?id=31524 - section links on file pages scroll too far down
My 'absolute' branch resolves this by removing the 'position: fixed' floating toolbar and letting it scroll off the page: https://github.com/brion/Wikipedia/commits/absolute
This lets us drop the event handlers that screw up the search field focusing, because we don't need them to work around the bug where click events went through to the background elements. It fixes the scrolling / reference / hashlink issue by getting the header out of the way, so going to a position in the document actually shows it at the top of the screen.
It also provides more screen space for reading, which is a big plus in portrait orientation where a toolbar eats proportionately more screen space.
The downside is that if you've scrolled down on the page, you have to scroll back up to get to the search field etc.
This is pretty much how the stock web browsers on iOS and Android work, however, so I don't think it's such an awful thing to do. Any objections? Preferences on making things sometimes auto-pop up?
-- brion
On Fri, Dec 23, 2011 at 20:29, Brion Vibber bvibber@wikimedia.org wrote:
The floating, fixed-position header bar (header bar always at the same place at top of the screen while other things scroll) causes a number of problems in the app, including:
- https://bugzilla.wikimedia.org/show_bug.cgi?id=32917 - It's difficult
to tap into the search box
- https://bugzilla.wikimedia.org/show_bug.cgi?id=31524 - section links on
file pages scroll too far down
My 'absolute' branch resolves this by removing the 'position: fixed' floating toolbar and letting it scroll off the page: https://github.com/brion/Wikipedia/commits/absolute
This lets us drop the event handlers that screw up the search field focusing, because we don't need them to work around the bug where click events went through to the background elements. It fixes the scrolling / reference / hashlink issue by getting the header out of the way, so going to a position in the document actually shows it at the top of the screen.
It also provides more screen space for reading, which is a big plus in portrait orientation where a toolbar eats proportionately more screen space.
The downside is that if you've scrolled down on the page, you have to scroll back up to get to the search field etc.
This is pretty much how the stock web browsers on iOS and Android work, however, so I don't think it's such an awful thing to do. Any objections? Preferences on making things sometimes auto-pop up?
thanks so much for removing this space waste and provide more area for the article. android phones usually have a (hardware) search button, most of the time a magnifier symbol. this is used for searching the phone book as well for browsers, etc. is there any thing why you do not want to use it?
rupert
On Fri, Dec 23, 2011 at 20:44, rupert THURNER rupert.thurner@gmail.comwrote:
On Fri, Dec 23, 2011 at 20:29, Brion Vibber bvibber@wikimedia.org wrote:
The floating, fixed-position header bar (header bar always at the same place at top of the screen while other things scroll) causes a number of problems in the app, including:
- https://bugzilla.wikimedia.org/show_bug.cgi?id=32917 - It's difficult
to tap into the search box
- https://bugzilla.wikimedia.org/show_bug.cgi?id=31524 - section links
on file pages scroll too far down
My 'absolute' branch resolves this by removing the 'position: fixed' floating toolbar and letting it scroll off the page: https://github.com/brion/Wikipedia/commits/absolute
This lets us drop the event handlers that screw up the search field focusing, because we don't need them to work around the bug where click events went through to the background elements. It fixes the scrolling / reference / hashlink issue by getting the header out of the way, so going to a position in the document actually shows it at the top of the screen.
It also provides more screen space for reading, which is a big plus in portrait orientation where a toolbar eats proportionately more screen space.
The downside is that if you've scrolled down on the page, you have to scroll back up to get to the search field etc.
This is pretty much how the stock web browsers on iOS and Android work, however, so I don't think it's such an awful thing to do. Any objections? Preferences on making things sometimes auto-pop up?
thanks so much for removing this space waste and provide more area for the article. android phones usually have a (hardware) search button, most of the time a magnifier symbol. this is used for searching the phone book as well for browsers, etc. is there any thing why you do not want to use it?
just as a reference for the ones not so familiar with android development: http://developer.android.com/guide/topics/search/search-dialog.html was the "android standard" way i was referring to.
rupert
On Fri, Dec 23, 2011 at 11:44 AM, rupert THURNER rupert.thurner@gmail.comwrote:
thanks so much for removing this space waste and provide more area for the article. android phones usually have a (hardware) search button, most of the time a magnifier symbol. this is used for searching the phone book as well for browsers, etc. is there any thing why you do not want to use it?
Within the app, hitting the hardware search button already is used: it sets focus to the search field (if we drop position:fixed header, then this would also scroll you to the top so it's in view).
Note that this search button has been dropped from the software replacement for the hardware toolbars in Android 3 (Honeycomb) and 4 (Ice Cream Sandwich).
It's also possible to provide a search hook so that the app can be searchable from the global search screen, which can be gotten to via the hardware search button on the Android home screen in Android 2.x, and from the 'Google search' field on the home screen in Android 3 and 4.
We haven't done this yet, but I stuck a note into our bug tracker as it might be a nice addition: https://bugzilla.wikimedia.org/show_bug.cgi?id=33356
-- brion
I like this better overall. Just the amount of screen real estate taken up by bars like it usually leads to me getting frustrated while reading even when occasionally useful. If it allows us to fix these bugs as well then I think it's more plus then minus.
I may have just missed something but I'm slightly confused about what you mean by occasional auto pop ups?
James
Sent from my iPhone
James Alexander Associate Community Officer Product Manager - Fundraising Wikimedia Foundation +1 415-839-6885 x6716
On Dec 23, 2011, at 11:29 AM, Brion Vibber bvibber@wikimedia.org wrote:
The floating, fixed-position header bar (header bar always at the same place at top of the screen while other things scroll) causes a number of problems in the app, including:
- https://bugzilla.wikimedia.org/show_bug.cgi?id=32917 - It's difficult to tap into the search box
- https://bugzilla.wikimedia.org/show_bug.cgi?id=31524 - section links on file pages scroll too far down
My 'absolute' branch resolves this by removing the 'position: fixed' floating toolbar and letting it scroll off the page: https://github.com/brion/Wikipedia/commits/absolute
This lets us drop the event handlers that screw up the search field focusing, because we don't need them to work around the bug where click events went through to the background elements. It fixes the scrolling / reference / hashlink issue by getting the header out of the way, so going to a position in the document actually shows it at the top of the screen.
It also provides more screen space for reading, which is a big plus in portrait orientation where a toolbar eats proportionately more screen space.
The downside is that if you've scrolled down on the page, you have to scroll back up to get to the search field etc.
This is pretty much how the stock web browsers on iOS and Android work, however, so I don't think it's such an awful thing to do. Any objections? Preferences on making things sometimes auto-pop up?
-- brion
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Fri, Dec 23, 2011 at 11:56 AM, James Alexander jalexander@wikimedia.orgwrote:
I like this better overall. Just the amount of screen real estate taken up by bars like it usually leads to me getting frustrated while reading even when occasionally useful. If it allows us to fix these bugs as well then I think it's more plus then minus.
I may have just missed something but I'm slightly confused about what you mean by occasional auto pop ups?
Some apps (like the Amazon Kindle iOS and Android apps) have floating toolbars which hide during normal reading, and pop back up when you activate menus or tap on an empty part of the screen.
These could then hide themselves again when you start scrolling or tap again outside the bar.
Can be handy for still getting at the toolbars, while keeping them out of the way most of the time.
-- brion
Did we/can we make a decision on this?
I'm +1 for removing position:fixed. Gives me more reading space on my tiny android screen :D
Please let's. Second Rupert's question about the Android search button.
Thanks,
A. On Jan 3, 2012 2:43 PM, "Yuvi Panda" yuvipanda@gmail.com wrote:
Did we/can we make a decision on this?
I'm +1 for removing position:fixed. Gives me more reading space on my tiny android screen :D
-- Yuvi Panda T http://yuvi.in/blog
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l