trello indexing is bad
I have many examples of trello indexing for search failing, but here's one.
Search for "flight singapore london" returns no results. Actual card contains "fly singapore -> london", so fly and flight aren't treated as co-stemmed (whatever the term) by indexer. But in comment of card is "flights", so word and its regular plural by adding "s" aren't treated as co-stemmed?
I've added "keyword: flight" as a comment, and will see if that gets indexed and affects the search "flight singapore london" at some point in the future.
But in other cases, all the search terms do appear literally, but the search still fails.
More interestingly, playing with this raises some thoughts about application architecture.
Many applications are "eventually consistent". New data is added, and at some point in the future, indexes are updated, linked records are updated, aggregates, and so on. In almost no cases is there an indication to the user about this. Could be "all up to date", or "records to receive", or "processing records", or "disconnected; don't know if there are new records", and in all cases "this known as of timestamp, compared with now". Where the data replication and processing can be handled by middleware, this is then reportable to the user in a uniform way. On a traditional window frame, this could be indicated by an icon in one of several states. On a phone (anything full-screen), some nook or cranny of the screen might be reserved for this. Or it could be handled "inside" the application, but preferably as a secondary indication, with the OS / middleware one being definitive. The only thing I've used that came close to this is Lotus Notes, in that applications had databases that got replicated at the Lotus Notes level, and could work disconnected. But it was horrible to use.
Coming back to the case at hand, me adding "keyword: flight" would result in my search on other device saying "no results (but changed records from last 3 minutes have not yet been indexed)", or some indication on the screen that reprocessing is taking place. And, kind of separately, why can't it brute-force search through this new record so that it does indeed present an up-to-date view?

Comments
Post a Comment