. Here's what it looks like.
1 of 2. Page menubar:
2 of 2. Find in page dialog:
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(a)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(a)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(a)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(a)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(a)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(a)gmail.com>
>>> wrote:
>>> > On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc
<tfinc(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l