
How we implemented find-on-page with infinite scroll - OmarIsmail
http://blog.streak.com/2013/04/search-find-in-pipeline-now-possible.html
======
bryanh
This is very clever, I just tried it and was impressed.

Streak, thanks for sharing all your clever technical hacks, I always enjoy
reading them.

------
slinkyavenger
I'm confused as to whether this webapp implements its own search box, or if it
is somehow intercepting input into the browser's search box. Could someone
shed some light?

~~~
OmarIsmail
We implement our own search box, we just made it look like the browser's
search box to try to minimize confusion.

~~~
rkangel
Surely disguising your search box as the browser's search box is merely adding
to the confusion?

Also, presumably it isn't always identical to the browser search box - you're
going to have trouble with all combinations of browsers and colour schemes and
skins etc.

~~~
danbruc
I second this and don't think this is an elegant solution. This is kind of a
leaky abstraction - you are pretending to have many rows on the screen but you
are unable to hide the fact that you don't because you are breaking the in-
page search. You will never be able to fix this in all, maybe not even in most
cases - your search box looks nothing like my Opera search box. But it does
not stop with in-page search - you are probably breaking select all, printing,
scroll bars and what about zooming? And what if I change my keyboard shortcut
for in-page search or use the menu to invoke it?

All that aside in my opinion the mistake is to allow the user to have
»hundreds of thousands of rows« on the screen - real or virtual - in the first
place. What a waste of time to scroll through that. I would just offer filters
that almost immediately update the set of matching rows and display the first
few and maybe highlight the match in each row. When the user scrolls to the
bottom you can load more rows either automatically or by pressing a button.

The user will understand what is going on, is encouraged to filter instead of
randomly scrolling through thousands of rows and everything from in-page
search to printing works just as expected. And last but not least it is
probably much simpler than your solution. (And the user is still able to
scroll through all rows and in almost all cases they will stop way before the
page size becomes a problem for the browser besides you are using an old
phone, but whoever attempts to scroll through thousands of rows on a phone
probably deserves the result.)

------
solox3
>we only actually render the rows that you see and simply reuse those rows and
change their contents

What warranted this extra load onto your database instances, as opposed to
loading all rows on the client? Do they usually have a million tasks?

~~~
OmarIsmail
Sorry, it could have been clearer. When we say "render" we mean actually
output HTML. We do load all the data onto the client.

------
asah
This is nothing: you should see the wizardry in their in-gmail application.

~~~
tseabrooks
Their app looks neat. Isn't it susceptible to gmail changes breaking
functionality?

------
ebbv
I think disguising your search box is only going to be more confusing. Giving
the user a clear and obvious search box is a better design, IMHO.

------
DigitalSea
Streak, you always amaze me with your clever technical solutions. Your Gmail
application is equally as impressive, thanks for sharing this will no doubt
come in handy one day.

