I posted a rough "Find in page" patchset for Android at https://gerrit.wikimedia.org/r/#/c/139310/. Here's what it looks like.
1 of 2. Page menubar: https://drive.google.com/file/d/0BxJX28FKLm78TGlhOHNDSXJLbjg/edit?usp=sharin...
2 of 2. Find in page dialog: https://drive.google.com/file/d/0BxJX28FKLm78YUVLNDZQazh6Nlk/edit?usp=sharin...
It works on a 4.4 tablet and and 2.3 phone with forward (down) and backward (up) scrolling. It seems on the pre-Jellybean devices the term highlighting doesn't work even if the viewport scrolls to the correct place, but the highlighting seems to work just fine on Jellybean and later.
-Adam
On Tue, Jun 10, 2014 at 11:28 AM, Adam Baso abaso@wikimedia.org wrote:
Yuvi, after today there's a potential I could spend a little time on this, unless you and your Android powerhouse crew are already on it.
If you want me to take it, though, in which layout file would you recommend embedding the find control and where would you recommend wire up? I did a local version without creating the control using the existing wireup classes and it did highlighting just fine.
The async API supported on newer Android OSes supports what is essentially a result count and the ability to scroll /forward/ in the Find list. It's sort of unclear to me how to scroll backward without perhaps JavaScript injection or viewport-freeze followed by position calculation and iterated scroll forward followed by viewport unfreeze (bleh). The legacy Find on older Android OSes is a little different, but no matter. Anyway, highlight and scroll forward is probably sufficient if there isn't an easier solution to scroll backward, I should think.
Greg, to answer your question about natural language queries (which I really like!), I did a proof of concept on iOS ( https://gerrit.wikimedia.org/r/#/c/121562/) and I've posited it as a potential annual goal - I think Dan Garry will be weighing in on that for product direction for the apps. There were some performance things that would need to be worked out (see http://lists.wikimedia.org/pipermail/mobile-l/2014-April/006859.html for a little more context), but my gut says having a tappable finding glass icon (ideally on an embossed icon like most other search engines) to issue the fulltext Wikipedia article search in a fashion somewhat analogous to the web would probably be a way to avoid unnecessary load.
-Adam
On Mon, Jun 9, 2014 at 1:55 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Woah there excitement ... let's trim the size of those caps.
On Mon, Jun 9, 2014 at 1:55 PM, Dan Garry dgarry@wikimedia.org wrote:
CLEARLY MY COMPUTER IS ALSO EXCITED BY IN-PAGE SEARCH AS IT CHOSE TO
WRITE
THIS EMAIL IN CAPS.
DAN
On 9 June 2014 13:54, Dan Garry dgarry@wikimedia.org wrote:
GO FOR IT. IF IT'S SIMPLE TO IMPLEMENT THEN I'M FINE WITH DOING IT
FIRST.
DAN
On 9 June 2014 13:53, Tomasz Finc tfinc@wikimedia.org wrote:
Then i'd say rig a proof of concept for an hour or two and give it to the designers to play with. Up to Dan of course.
--tomasz
On Mon, Jun 9, 2014 at 1:51 PM, Yuvi Panda yuvipanda@gmail.com
wrote:
On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc tfinc@wikimedia.org wrote: >> Searching within articles. > > This falls into the same camp as tabs and browser features. Would
be a
> fun spike to explore relative difficulty.
Me and Adam actually explored this a while back, and it does not
seem
too hard at all. Only thing to figure out is where to put the 'find' bar, and the actual implementation doesn't seem too hard. -- Yuvi Panda T http://yuvi.in/blog
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
-- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l