Search Experience
Gervase Markham
I wanted to flag up a scenario where, for me, the new search is less
usable and more clunky than the old one, to see if we can figure out how
to streamline it.
A common thing with old search was to click on the folder you thought
the message was in, focus the search bar (Ctrl-K) and start typing. As
you typed, the messages narrowed down, and when the list got short
enough you picked the one you wanted. (Unless you had the wrong folder,
in which case you would repeat the trick in a few other folders before
giving up, pressing Ctrl-Shift-F, and carefully constructing a
cross-folder query. Not great. But let's leave that for now.)
In the new search, I find myself by reflex clicking on the "right"
folder before searching. Now, that makes no difference. Fair enough, I
may well learn not to do that. But then, I start typing. And, of course,
nothing happens. I have no idea how much I need to type before
Thunderbird has narrowed down my choices to a small set. So I type the
entire phrase or name and hit Enter. A new tab opens, the UI freezes for
five seconds with the search page half-rendered (although that might
just be my machine, and Linux) and then the search results UI arrives.
Instead of seeing a list of ten messages where I can go "ah yes, that's
the most recent one", I see a greater amount of text from about three
messages, sorted in a manner which is initially opaque. If I then sort
by date, I still have messages from across all my folders, including
ones I wrote myself (which are usually not what I'm looking for).
Because the search results are not columnar, it's harder to scan down a
column looking for e.g. the date you want. And when you do find the
message, you click it, and there's a visual jar as it opens in an entire
new tab, thereby appearing in a size and form you are not used to if you
normally use the 3-pane. And then, you have to close two tabs before you
can get back to your normal workflow.
All in all, then, it takes me quite a bit longer and a lot more steps to
find the right message than before.
Here's my suggestion. Right at the start, when you are typing in the
search box, can we do typedown searching on all fields in the current
folder as you type? At the moment, nothing happens at this stage anyway.
If the user hits Enter, fine, open the full-blown search window. But if
they can press Ctrl-K, type "flobbit" and find the message in the
current folder really quickly, we should let them do that too.
Gerv
Peter Lairo
> And when you do find the
> message, you click it, and there's a visual jar as it opens in an entire
> new tab, thereby appearing in a size and form you are not used to if you
> normally use the 3-pane. And then, you have to close two tabs before you
> can get back to your normal workflow.
And there seems to be no way to know which folder the message is in, let
alone open the message with the folder open and the folder pane visible
(i.e., in 3-pane).
> All in all, then, it takes me quite a bit longer and a lot more steps to
> find the right message than before.
I fully agree that the search results page is overloaded, poorly
structured, and cumbersome - for all the reasons Gerv mentions, and more.
--
Regards,
Peter Lairo
The browser you can trust: www.Firefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Islam: http://www.jihadwatch.org/islam101/
Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
"So, why don't we ever talk about the sun's contribution to global
warming? Well, because we can't regulate it, tax it, or make it feel
guilty for what it's doing" (www.WhatYouOughtToKnow.com)
Andrew Sutherland
>> All in all, then, it takes me quite a bit longer and a lot more steps to
>> find the right message than before.
>
> I fully agree that the search results page is overloaded, poorly
> structured, and cumbersome - for all the reasons Gerv mentions, and more.
I think a very helpful exercise would be if people could provide visual
mock-ups of how their idealized search experience should work. If the
ideal search experience is the advanced search dialog or the
pre-fancified quick search, the former still exists and the latter is
basically back since we are turning off auto-complete for quick-search.
The faceted search interface has already come very far and there is much
more than can be done. What I have found while working on it is that
the most benefit is gained from actually prototyping to try things out.
Obviously, that is hard and not everyone has the time or skill-set
required.
Visual mock-ups are a good second-choice, be they stubbed out HTML or a
series of static images. While the time effort is not to be
under-estimated on the part of the person creating the mock-up, part of
this is because it forces the vision to be more fully realized (which is
a good thing).
Andrew
Robert Kaiser
> All in all, then, it takes me quite a bit longer and a lot more steps to
> find the right message than before.
What I really would love if the global search could act very similar to
the old folder-specific search and list messages in the thread pane,
narrowing down the results as you type.
Is that generally possible to do with the gloda backend?
If yes and there is no implementation of it by then, I'll ask the
SeaMonkey team to do this for a global search in SeaMonkey 2.1.
Robert Kaiser
Andrew Sutherland
> What I really would love if the global search could act very similar to
> the old folder-specific search and list messages in the thread pane,
> narrowing down the results as you type.
> Is that generally possible to do with the gloda backend?
> If yes and there is no implementation of it by then, I'll ask the
> SeaMonkey team to do this for a global search in SeaMonkey 2.1.
Thunderbird beta 3 used gloda search to populate a thread-pane view.
This is still done if you choose "Show all as list" from the search
results page.
This was abandoned for performance reasons, especially for gmail
accounts. Opening a lot of .msf files adds up, especially if any of
them are huge (as in the gmail case).
Andrew
Russell East
Robert Kaiser
> This was abandoned for performance reasons, especially for gmail
> accounts. Opening a lot of .msf files adds up, especially if any of them
> are huge (as in the gmail case).
Interesting, why do we need to open up all the MSFs when displaying
gloda results?
In any case, I long for replacing the MSFs with account-wide SQLite DBs
as well ;-)
Robert Kaiser
Andrew Sutherland
> Interesting, why do we need to open up all the MSFs when displaying
> gloda results?
nsMsgDBViews only speak nsIMsgDBHdrs. Having gloda try and make its
message representations pretend to be nsIMsgDBHdrs had conceptual issues
but also would not have been sufficiently performant given how the
tree-view and nsMsgDBViews are implemented and XPConnect crossing costs.
Additionally, the message reader/preview pane would have definitely
needed the real message header, which can instantly provide worse-case
performance again.
Previous prototypes had gloda entirely implementing its own nsITreeView
instance, but that had performance concerns owing to the painting
strategy of the tree-view. Also, it throws away all of the application
logic baked into the nsMsgDBView instances.
> In any case, I long for replacing the MSFs with account-wide SQLite DBs
> as well ;-)
rkent has already done some very interesting work on this front.
Andrew
Robert Kaiser
> On 09/23/2009 08:28 AM, Robert Kaiser wrote:
>> Interesting, why do we need to open up all the MSFs when displaying
>> gloda results?
>
> nsMsgDBViews only speak nsIMsgDBHdrs. Having gloda try and make its
> message representations pretend to be nsIMsgDBHdrs had conceptual issues
> but also would not have been sufficiently performant given how the
> tree-view and nsMsgDBViews are implemented and XPConnect crossing costs.
> Additionally, the message reader/preview pane would have definitely
> needed the real message header, which can instantly provide worse-case
> performance again.
>
> Previous prototypes had gloda entirely implementing its own nsITreeView
> instance, but that had performance concerns owing to the painting
> strategy of the tree-view. Also, it throws away all of the application
> logic baked into the nsMsgDBView instances.
Interesting. I don't think I understand half of the gory details of
this, but I take away that implementations are somewhat incompatible,
esp. when it comes down to making them performant.
>> In any case, I long for replacing the MSFs with account-wide SQLite DBs
>> as well ;-)
>
> rkent has already done some very interesting work on this front.
That sounds even more interesting. Could finishing this work possibly do
away with the problems you mentioned? I'm obviously thinking in terms of
the next release series here - and I'd really like to have a global
search in SeaMonkey 2.1, but preferably one that still shows results in
a thread pane or at least in a real chrome view and not in something
that looks like webmail (not wanting to play down what Thunderbird has,
it may just not be the look SeaMonkey wants to have).
Robert Kaiser
Joshua Cranmer
> Andrew Sutherland wrote:
>> On 09/23/2009 08:28 AM, Robert Kaiser wrote:
>>> In any case, I long for replacing the MSFs with account-wide SQLite DBs
>>> as well ;-)
>>
>> rkent has already done some very interesting work on this front.
>
> That sounds even more interesting. Could finishing this work possibly do
> away with the problems you mentioned?
If this is the work that asuth was referring to:
<https://bugzilla.mozilla.org/show_bug.cgi?id=11050#c29>,
that work was to try to make a common interface for both SQLite and mork
database formats. The biggest issue I have with that is that it merely
moves from mork to SQLite without opening up access to the power that
comes with having real databases.
As much as I want to kill mork, I want to kill it correctly, not merely
repackage the painful parts (i.e., the API) in a different implementation.
Robert Kaiser
> As much as I want to kill mork, I want to kill it correctly, not merely
> repackage the painful parts (i.e., the API) in a different implementation.
Josh, I agree with you there (as you might know).
Robert Kaiser
Kent James
One of the things that makes mork hard to kill is that it actually works
pretty well most of the time. So if you are expecting to kill Mork for
performance reasons, you are likely to be disappointed. Gloda with
sqlite is not known for its blazing speed, the motivations to replace
Mork with sqlite are different. Mork is currently unmaintainable, and
its memory model has inconsistencies with XPCOM that makes for some
interesting crasher bugs, and requires strange mystical incantations
that Bienvenu does to keep row references from blowing up even more
frequently. Those issues, along with the flexibility that a more
conventional database offers, are likely to be the drivers.
My original motivation for doing the iGdb work, as I called my
generalized database scheme, was to preempt attempts to make mailnews as
dependent on sqlite for the summary database as it currently is on mork.
The progress of gloda has only reinforced my feelings on this. I
envision a future architecture where a very lightweight database schema,
such as my iGdb proposal, provides the minimal required summary
information, which may be implemented to interface to a variety of other
information sources - be they imap, ldap, facebook, exchange server,
mysql-driven message stores, a project management system, or whatever.
The interesting view and summary information will be provided by a
higher level database schema, which is likely to be an sqlite-based
gloda. So iGdb becomes the interface layer to whatever information
sources are available, but they can all be consolidated in gloda-based
views and search. This is not a vision driven primarily by performance,
but primarily by flexibility. Actually the major difficulty in getting
this to work was that I was trying to make it 100% compatible with
existing mork stores. It was cases where the database design was
optimized to take advantage of mork-specific features that made the
implementation challenging.
To be realistic though, I think that the chances of mailnews going this
direction are pretty slim.
rkent
Robert Kaiser
> One of the things that makes mork hard to kill is that it actually works
> pretty well most of the time. So if you are expecting to kill Mork for
> performance reasons, you are likely to be disappointed.
For a straight replace, probably, yes. But exactly that is not what
Joshua and me have in mind. The idea is to replace the
on-Mork-per-folder model with a one-SQLite-per-account model, which
actually could influence performance due to the different model,
regardless of the DB behind it.
We can do this with SQLite as we don't need to load the whole DB into
memory, which Mork is doing though (and AFAIK, that's why it's that
fast). If opening a large amount of different per-folder Mork files is
the problem with that dynamic global search in threadpane, then the
switch of models could actually improve it as we need to open fewer
files and only query the messages we need for display and not load their
whole physical folders into memory.
Also, the different model has chances of solving other long-standing
issues like correctly mark cross-posts read in multiple newsgroups.
Robert Kaiser
Andrew Sutherland
along the same lines given a need for pragmatism and gloda's existing
capabilities.
On 09/23/2009 08:22 PM, Kent James wrote:
> My original motivation for doing the iGdb work, as I called my
> generalized database scheme, was to preempt attempts to make mailnews as
> dependent on sqlite for the summary database as it currently is on mork.
Can you elaborate on this a bit more? In my mind the dominant decision
for a mork replacement is whether the API is synchronous or
asynchronous. A truly generic interface seems like it would need to be
asynchronous, and I am wondering if the truly generic part should go
elsewhere...
== On a synchronous API:
Mork presents a synchronous API once loaded, although the load itself
can be made asynchronous. The nsMsgDBView code relies on this heavily
which is significant because it is user-facing and together with the XUL
tree implementation relies on rapid conversion from message keys to
nsIMsgDBHdrs all over the place. The C++ search code is already
time-slice-y and could potentially be mooted by the database, so that's
less of a concern.
The nice thing about SQLite is that it is a very small black box (for
what it does) whose behavior is exceedingly well defined and rather
predictable. This makes it feasible for use in a synchronous fashion.
As long as we completely avoid use of the full-text indexer and keep our
queries simple then we can use it like mork. We can even use it from
multiple threads as long as we keep lock contention in mind and all of
the threads avoid fancy queries.
It is not clear to me what other implementation options are really
available for a synchronous API other than SQLite. It seems like other
implementations could be categorized as one of the following:
- Out-of-process communication that really should be asynchronous. For
example: 'real' databases, exchange server communication.
- Retreads of functionality already provided by SQLite that potentially
have more bugs and less scaling capability.
The argument for sticking to a synchronous API is to avoid having to
re-write huge swathes of C++ code that work well enough right now. I'd
rather let them keep humming along until we replace them with something
better.
== On a potentially better place for the genericity:
From an rfc822 e-mail message perspective, our needs are fairly simple.
Some headers need to be reflected into a datastore and the message
body needs to be able to be asynchronously produced on demand.
Why not have the information sources just use an explicit API to cram
the headers into our SQLite data-store and have that be where the
generic bits are? More clever information sources could do something
like IMAP where we selectively fetch headers, whereas lazy ones could
just use the existing message header parser to do it for them.
That seems like it covers IMAP, exchange, local mbox, local maildir,
other database used as a glorified body store, etc. It could cover
facebook too, although that might just do better to avoid this entire
subsystem and exist as something directly consumed by gloda (given its
potentially complex semantics and potentially poor translation to the
rfc822 model depending how far you go).
I am not sure what the use case is for your LDAP and project management
system examples; if they can produce rfc822 message bodies on demand, it
seems like they would be suitable.
== The larger questions of UI, async versus sync, and nsMsgDBView:
As alluded to above, I think the main reason the synchronous API is
required is because (especially pre gloda faceted search), the
Thunderbird UI has been built around the thread-pane. Take away the
thread pane and you can no longer do anything.
The entire stack of code driving the thread pane is assuming every
operation is pretty fast. The XUL tree widget does not cache values for
fast repainting; it just asks for them again. I do not believe the tree
widget does anything clever with scrolling and repainting either; if the
cost to do the repaints is high, the scroll thumb actually lags behind
the mouse as it tries to paint everything as you drag.
The nsMsgDBView is also in charge of the data-model backing the tree.
It performs the sorts, does the threading logic, and handles the
intersection of the two. Threaded modes of operation make it harder to
reduce the nsMsgDBView to just a database result-set viewer.
When this works (and it has been working very well for a very long time,
especially once loaded), the result is a very snappy interface. It
feels native, it feels like your data is there and you can get at it.
The ruthless precision of the scroll-bar does not make the UI any more
useful, but it is costing us a lot. The snappy interface and 'my data
is there' sensations are good things. We can't abandon having a user
interface affordance that feels like the thread-pane, but we need to
change how it works.
I see two dominate uses for a scroll-bar: relative movement ("I think
it's (just) before or (just) after what I'm looking at", and absolute
movement ("I know things are sorted by time and this happened a while
ago", "I know things are sorted by name, and Zorro's name is at the
end".) I think Google Picasa did a good thing with their re-imagined
scrollbar; it's great for relative movement. I think absolute movement
is better accomplished with an explicit time-line-like affordance. If
you're looking based on time, show an actual timeline. If you're
dealing with alphabetical names (like in an address book), show an
address-book style timeline ranging over a..z.
In the context of this dicussion, I think the best long-term plan is to
abandon nsMsgDBView and its needy database needs. We move to a display
widget capable of doing rich formatted display so we can do multi-line
entries with summary and formatting at sub-cell granularities. We move
to a strictly asynchronous mode of operation in regards to the widget
with aggressive pre-caching to maintain perceived responsiveness. We
try and only expose total orderings where we can use queries on existing
indices to keep things snappy. We use temporary tables and/or a
virtual-folder-like mode of 'continually' updated persistent queries
when the need arises.
That strategy would allow all kinds of great asynchronous fun. But it
will take quite some time to get to that point. Which means nsMsgDBView
will continue to live a long full life and synchronous is the word if we
want to replace mork prior to replacing nsMsgDBView.
== Other:
> The interesting view and summary information will be provided by a
> higher level database schema, which is likely to be an sqlite-based
> gloda. So iGdb becomes the interface layer to whatever information
I don't think we should write-off the possibility of having gloda
fronting remote data-stores. Because it is an exclusively asynchronous
API it is more than capable of serializing queries, shipping them to
somewhere, getting results back, and integrating them. It could even
run a query against the local gloda index as well as sending one off
into the cloud. The UI has to be capable of handling the possibility
for the local batch of results to come nearly immediately and other
batches to show up at random intervals, but it's feasible.
Which is to say, don't pin all your hopes on the mork-replacement layer.
> To be realistic though, I think that the chances of mailnews going this
> direction are pretty slim.
Ignoring my message here and the fact that you are one of very few
active db contributors, where did you think mailnews was headed?
Andrew
Gervase Markham
> I think a very helpful exercise would be if people could provide visual
> mock-ups of how their idealized search experience should work.
I realise it's frustrating to be given all this raw feedback with only a
few suggestions as to what to change, particularly with deadlines
approaching and string freezes near :-) And not making mockups often
leads people to suggest things which would be impossible in practice.
But having to make mockups is also a high barrier to entry into the
conversation. I'd love to have the time to spend a few hours thinking
hard about this problem, but I don't :-(
> If the
> ideal search experience is the advanced search dialog or the
> pre-fancified quick search, the former still exists and the latter is
> basically back since we are turning off auto-complete for quick-search.
Is the latter back? If I press Ctrl-K and start typing, I don't get
narrowing in the current folder... do I?
Gerv
Thomas Stache
If you select a quick search mode from the dropdown menu of the search
icon in the search box... it does.
It would be cool if the search modes would be changeable using
Ctrl-Up/Down like in the Firefox search box, and if the GloDa mode had a
different icon than the quick search modes.
Thomas
Robert Kaiser
> In the context of this dicussion, I think the best long-term plan is to
> abandon nsMsgDBView and its needy database needs.
I hope that doesn't mean you want to remove the threadpane's native
look-and feel, or that would probably be the turning point where
SeaMonkey and Thunderbird would need to part ways almost completely.
Robert Kaiser
Siddharth Agarwal
> It would be cool if the search modes would be changeable using
> Ctrl-Up/Down like in the Firefox search box
This already works for me. No visual indication, but it works.
Joshua Cranmer
the best time to discuss it (it would certainly help to defer until
after rc1). So although I'm not responding to everything you say, that
doesn't necessarily mean I agree with what I'm snipping.
On 09/25/2009 12:05 AM, Andrew Sutherland wrote:
> The nsMsgDBView is also in charge of the data-model backing the tree. It
> performs the sorts, does the threading logic, and handles the
> intersection of the two. Threaded modes of operation make it harder to
> reduce the nsMsgDBView to just a database result-set viewer.
Actually, the threading is performed by the database: the visual display
only chooses whether or not it should take advantage of this information.
> I see two dominate uses for a scroll-bar: relative movement ("I think
> it's (just) before or (just) after what I'm looking at", and absolute
> movement ("I know things are sorted by time and this happened a while
> ago", "I know things are sorted by name, and Zorro's name is at the
> end".) I think Google Picasa did a good thing with their re-imagined
> scrollbar; it's great for relative movement.
If you're referring to something like the scrollbar on the Google
Calendar widget in the Firefox tinderbox, I would recommend heavily
against it. I find that thing eternally frustrating every time I have to
use it. In fact, a lot of your thread-pane-replacement proposal sounds
like something that would rapidly get on my nerves in terms of UX, and
I'm not an old fart who resists change.
> In the context of this dicussion, I think the best long-term plan is to
> abandon nsMsgDBView and its needy database needs. We move to a display
> widget capable of doing rich formatted display so we can do multi-line
> entries with summary and formatting at sub-cell granularities.
While having a rich-formatted display (i.e., nsITreeView2) is probably
advisable, that doesn't quite match up with what you talk about:
replacing nsMsgDBView. I'm not quite sure what you intend with that, but
it sounds like you want to replace the thread pane display with some
sort of AJAXy magic widget that takes advantage of asynchrony (is that
even a word?) and ignites in my gut this strange feeling that it would
be a UX nightmare.
> Ignoring my message here and the fact that you are one of very few
> active db contributors, where did you think mailnews was headed?
While this question was not pointed at me, I think it is still one worth
answering as myself. As a side note, it seems to me that all of the
major stakeholders in this discussion have a different idea (I'm sure
bienvenu and others hold yet more positions).
I think that one of the core goals of the database in mailnews should be
to foster innovation. Of all the various forms of innovation and
extension that could go on within Thunderbird and its extensions, the
most important I think is the ability to handle stuff outside the realm
of the big 4 protocols (NNTP, IMAP, POP, and SMTP) and RSS. Flexibility
in display (in terms of coming up with new displays to replace the
folder pane, thread pane, and/or message pane) is somewhat less
important, but still rather high in my rankings; flexibility in storage
medium ranks again lower (most people won't bother with anything other
than the default), but it's still a design goal worth mentioning.
The primary goal of the database, then, would be to be able to easily
cater to these forms of innovation. As to where that would lead the
database, I don't think I yet have the answer to that question, only
pie-in-the-sky ideas (which I've mentioned on my blog before).
Kent James
> Also, the different model has chances of solving other long-standing
> issues like correctly mark cross-posts read in multiple newsgroups.
To me, this is an example of the class of problems that gloda is more
likely to solve.
Kent James
>
> On 09/23/2009 08:22 PM, Kent James wrote:
>> My original motivation for doing the iGdb work, as I called my
>> generalized database scheme, was to preempt attempts to make mailnews as
>> dependent on sqlite for the summary database as it currently is on mork.
>
> Can you elaborate on this a bit more? In my mind the dominant decision
> for a mork replacement is whether the API is synchronous or
> asynchronous. A truly generic interface seems like it would need to be
> asynchronous, and I am wondering if the truly generic part should go
> elsewhere...
I was talking mostly about the "truly generic part" as you put it. Most
of your posting deals with issues surrounding making the user interface
work quickly, and for that purpose a dedicated, specific local database
(such as mork or sqlite) will be the right approach.
>
> == On a potentially better place for the genericity:
>
> From an rfc822 e-mail message perspective, our needs are fairly simple.
> Some headers need to be reflected into a datastore and the message body
> needs to be able to be asynchronously produced on demand.
>
> Why not have the information sources just use an explicit API to cram
> the headers into our SQLite data-store and have that be where the
> generic bits are?
I suppose that is one possible approach. I think though what I was
proposing was to have a simple key/attribute kind of interface to the
information sources, and let the gloda code do the stuffing into sqlite.
> I am not sure what the use case is for ... project management
> system examples; if they can produce rfc822 message bodies on demand, it
> seems like they would be suitable.
Bugzilla is a good example of a project management system. I would like
to be able to manage bug communications and status using the same
overview tools that I currently use for mail. Why should I need to force
them into rfc822?
> In the context of this dicussion, I think the best long-term plan is to
> abandon nsMsgDBView and its needy database needs.
I think the way that I would put it is that you need to replace
nsMsgDBView with a rich tree view that properly supports your future
local database, and by that I mean gloda, not iGdb.
> I don't think we should write-off the possibility of having gloda
> fronting remote data-stores.
It's possible that we could do both. That is, prepare a very simple
interface like iGdb, and write the sqlite/gloda interface to it. If I
want to add a simple datastream to mailnews, I could write a simple iGdb
interface to it, and all would work. For more complex examples, which
might include ultimately all of the standard ones like Imap and News,
the gloda interface would be written directly.
What I like about our current approach, which I fear will not last
without architectural discipline, is the clean separation between the
transient summary data that gloda provides, and permanent data which the
mail .msf files are starting to provide. In the .msf case, that was not
well thought out, and it slowly morphed (with a little help from me)
from a transient summary to a permanent datastore. Some of your writings
have recognized this issue, but it also needs to be reflected in the
architecture. But we have the problem that mork is local, while people
clearly want metadata available remotely.
>
>> To be realistic though, I think that the chances of mailnews going this
>> direction are pretty slim.
>
> Ignoring my message here and the fact that you are one of very few
> active db contributors, where did you think mailnews was headed?
Here I was just trying to make sure that readers understand that I am
not volunteering to do the changes that I proposed, and I think whoever
ends up doing the work is likely to take a quite different direction. As
to where mailnews was/is headed, in the new Thunderbird team as far as I
can tell, user interface is the key area that generates effort and
enthusiasm. Looking at your post, it is all about how the backend can
contribute to making the user interface faster - and the types of new
interfaces that are being offered in TB resemble the free-form pages of
the web. So I would guess that where mailnews is headed is to be more
like the web, whatever that means.
That is not where I itch. To me, the key issue facing "messaging" in
general is the huge fragmentation that has occurred, and the
difficulties in assembling it into a coherent whole. Just within my own
little world, I am in the process of setting up a server infrastructure
that will allow my users to interact with me through email, a forum, a
bug database, or by comments on a blog. I suppose if I was more with it,
I would also need to add twitter and facebook accounts, and a customer
relationship management package (all web based, of course). What a mess!
A couple of years ago I did a SharePoint rollout at a client, and we
instantly had the same problems in a completely different context. To
me, that is the big issue that a product like Thunderbird could address
- but I don't see a consensus around that idea, and I doubt I am in a
position to lead the parade. I'm not even sure I am correct, I'm still
watching and learning.
rkent
Andrew Sutherland
> Actually, the threading is performed by the database: the visual display
> only chooses whether or not it should take advantage of this information.
Cross-folder/search views are threaded by the view.
Andrew
Gervase Markham
> If you select a quick search mode from the dropdown menu of the search
> icon in the search box... it does.
Except that you then need to keep switching back and forward if you want
to use Gloda or not, which makes Quick Search not so "quick" :-)
I think typing something should to typedown on all fields in the current
folder, and pressing Enter should invoke Gloda globally, with no
configuration necessary.
Gerv
Thomas Stache
Yeah, here I totally agree with you!
I also noticed that hitting ENTER while in quicksearch doesn't do a
GloDa search -- but that it should!
Robert Kaiser
If at all, then only with gloda as a helper, as gloda is supposed to not
store anything significant, while the information of read posts is
actually quite significant, and IMHO should be stored in the
account-wide replacement of the MSFs.
Robert Kaiser
Bryan Clark
This could be possible via an auto-complete drop down coming out of the
quick search. There are actually lots of possibilities to improve the
quick search with auto-complete.
I'd suggest something that is still easily "type-able" so it's quick but
not taking the enter key to open gloda searches. I personally like the
idea but in terms of general usability we'd be likely to confuse a lot
of people who just hit enter out of habit and were expecting to stay in
quick search.
There are lots of other possible ways besides auto-complete.
~ Bryan