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 <[email protected]> wrote: > Thanks Adam. It'll be great to play with this. > > --tomasz > > On Fri, Jun 13, 2014 at 12:28 PM, Adam Baso <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>> >>>> Woah there excitement ... let's trim the size of those caps. >>>> >>>> On Mon, Jun 9, 2014 at 1:55 PM, Dan Garry <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> >>> wrote: >>>> >>> > On Mon, Jun 9, 2014 at 7:00 PM, Tomasz Finc <[email protected]> >>>> >>> > 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 >>>> [email protected] >>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> > > _______________________________________________ > Mobile-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/mobile-l -- Yuvi Panda T http://yuvi.in/blog _______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
