Type type type type. Autocomplete contact…
Completed contact becomes a bubble! Bubble becomes a constraint, showing us only the messages involving the given contact. (The idea is that you could then click on/select/whatever the bubble and change the constraint to be only to/from/cc/whatever if you are so inclined.)
Type type type, autocomplete, new constraint! Now we’re looking at all the messages involving the two given contacts. (Some of the messages with just one constraint were mailing list postings, but not explicitly involving the second contact. This listing shows only messages where both contacts were directly involved. We will have the ability to filter-out messages involving lists as desired, which may be desired by default in a case like this.)
What is exciting about this?
- The contacts are matched using a suffix-tree implementation on a reduced set of contacts (as a first-pass). In this case, those with sufficient ‘popularity’. ‘Frecency’ a la ‘places’ is also planned. And of course, we can hit the database as needed. The suffix-tree is nice because it allows extremely rapid lookups while also allowing for substring matching.
- The contact popularity is computed automatically by the gloda indexing process, taking into account both messages you receive and send. (I think the current address-book code just increments popularity on send?)
- I think the bubbles are cool. (Hyperlink-styling would also work, but would not be cool.)
- Having the text converted into an explicit object representation (bubbles) is better than just doing string filtering (as quicksearch does) because it allows explicit actions on the object given knowledge of the object type.
- We can convert more than just contacts/identities to explicit objects. As demonstrated at the summit, we have a plugin that detects bugzilla bug references in messages as well as (American/NANP-style) phone-numbers in messages. We could detect these and promote them as well, etc.
- The filtered messages are being delivered by gloda, the global database (backed by SQLite), which means that we aren’t searching just one folder.
- There are a lot of places that you, the reader, will shortly be able to hack on and contribute to make this even more exciting. A vicious cycle of exciting-ness will ensue until everyone is dancing in the streets.
Andrew- this is exciting stuff! Looking forward to seeing more TB3 UI changes.
Question: does this feature work with double-byte character sets? Most of my Japanese email comes in with the sender’s name in kanji, not roman characters (the actual email address is roman of course, I’m speaking about the name.)
Cool! When can we try? 🙂
I especially like the identicon support.
Gen: I don’t believe any part of this implementation precludes non-ASCII/full unicode support. I expect there are probably a number of spots where charset stuff has some glitches, but there are a lot of rough-edges/prototype-only stuff that needs to be improved/ruggedized in general too.
Unfortunately, the full-text indexing as prototyped in the next blog post using SQLite FTS3’s will require more leg-work to work in all languages. We should be able to get tokenization for most (all?) languages using ICU if we stick with SQLite3’s FTS3, but stemming will likely be spotty at best for languages other than English. The good news on that front, however, is that we also have good work on OS-native full-text search, which hopefully can provide a high quality text-search, assuming Microsoft and Apple have stemmers…
hansen: soon! 🙂
It’s great to see previews of some of these exciting advances. Thank-you.
Hi, will it be possible to still show contact name and mail address in the same line?
Archaeopteryx: One of the things we are trying to do is better handle the fact that a single contact can have multiple ways you can contact them… multiple e-mail accounts, (in the future) one or more IM accounts, etc.
Since you are most likely to really care about communication with the person rather than the e-mail address, the idea is that even if we match on the e-mail address, for the searching, we promote it to the contact. You can then adjust this to either involve only certain of their e-mail addresses, restrict to one of to/from/cc rather than all, etc. So, I guess I’m saying it’s appropriate to not show their e-mail addresses in this case.
Having said that, the screenshots are exclusively a technology demo and have not yet received the love of our UX (User eXperience) lead, Bryan Clark.
Pingback: Bryan Clark » Blog Archive » Looking at User Experience for Thunderbird 3