Thanks to awesome work from Dmitry and Adam, the patch for 'Find in
page' has been merged, and should be out in an alpha release in a few
hours \o/

On Sat, Jun 14, 2014 at 1:14 AM, Tomasz Finc <tfinc@wikimedia.org> wrote:
> Thanks Adam. It'll be great to play with this.
>
> --tomasz
>
> On Fri, Jun 13, 2014 at 12:28 PM, Adam Baso <abaso@wikimedia.org> wrote:
>> 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=sharing
>>
>> 2 of 2. Find in page dialog:
>> https://drive.google.com/file/d/0BxJX28FKLm78YUVLNDZQazh6Nlk/edit?usp=sharing
>>
>> 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
>>>
>>>
>>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l



--
Yuvi Panda T
http://yuvi.in/blog

_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l