#2644 NORM Untriag: Need incremental search in Journal
Zarro Boogs per Child
bugtracker at laptop.org
Thu Aug 2 16:50:55 EDT 2007
#2644: Need incremental search in Journal
------------------------------+---------------------------------------------
Reporter: Eben | Owner: tomeu
Type: defect | Status: new
Priority: normal | Milestone: Untriaged
Component: journal-activity | Version:
Keywords: | Verified: 0
------------------------------+---------------------------------------------
The Journal design assumes some level of incremental search. Obviously
the interval upon which this search is performed will be limited by
performance, but there are a few basic rules we can follow to make it work
pretty well in the general case.
1. Check on some interval t to see if the search string has changed. If
it has, fire off a new search. Checking for change means it will work
both when entering and when deleting characters. It's also important to
do this on an interval, so that it can perform partial searches while the
user continues to type, not just on a delay after typing stops. Decide t
based on performance; it can be variable with query length. That is, make
t smaller as search string increases in length to narrow in more quickly
on results.
2. Perform a search immediately upon an 'enter' keystroke. There's no
need to force them to wait for any interval to pass if they explicitly
initiate the search.
3. As soon as the search string becomes null (cleared), immediately
perform the search omitting the string (using only the selected filters),
so that the Journal returns to a clean state before they begin typing a
new query string.
It may be worth rigging up a system by which each incremental search is
performed on the previous set of search results, instead of from scratch.
This would seriously improve performance (from n*m to, well...something
better than that...n*log(m) average case? My algo is rusty and there are
a ''lot'' of factors to consider, not to mention that doing combinatorics
on the space of the english language is a nightmare.) You'd actually need
a cache stack, so you can handle changes in cursor position and deletions.
Oh, and all that takes up lots of RAM, which we don't have, anyway...
Oh well. The basics of an incremental search are very much needed.
--
Ticket URL: <http://dev.laptop.org/ticket/2644>
One Laptop Per Child <http://laptop.org/>
More information about the Bugs
mailing list