Open Bug 638522 Opened 13 years ago Updated 2 months ago

Add indicator/icon in header pane when message has related messages - enhancement to Open Message in Conversation

Categories

(Thunderbird :: Message Reader UI, enhancement)

Product:
Thunderbird
Component:
Message Reader UI
Platform:
x86
All
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: wsmwk, Assigned: protz)

References

Details

Attachments

(1 obsolete file) 

I want to know when a message has related messages in other folders. The use case is message management where not all messages are in the current folder (they might have been filtered or manually moved off), and not using a conversation view add-on (don't want the UI busyness nor the overhead).

So, add an indicator/icon in header pane when message has related messages in other folders (and only then), as indicated by gloda.  Preferably the indicator is also clickable to invoke open in conversation
While this sounds nice in practice, the overhead is likely to be substantial. This implies running a gloda query for each message you display, which as you know if you've tried Thunderbird Conversations, is horribly costly.

An alternative solution might be:
- gloda indexes a new message,
- gloda finds all messages in the conversation, there are N messages,
- for each msgHdr in the conversation, gloda updates its special property called "conversationCount", sets it to N.

A similar procedure could be carried out when a message is deleted, for the other remaining messages in the conversation.

This shifts the work load from displaying a message to indexing messages, which remains costly as well. I see no easy solution for this, CCing :asuth who might have some thoughts.
Appreciate the insight. Let me add these thoughts to the mix...

The example case here is a folder of primarily new bugmail (but it could be any "Inbox" type folder), and the messages related to them are likely in other folders - which might include an archive folder, and other "special category" folders. So it is almost sufficient for the UI to only indicate there are >1 related messages. conversation.

And because I am mostly interested in the productivity gain, I can stomach some modest performance hit. (it would be super cool if functions like this could be done on a background thread to reduce the impact)  I'm more about avoiding the "conversation UI" in my default view than avoiding the overhead.

An alternative that might work for me is a lightweight mode of conversations UI - show me a single message by default and make me click to show the conversation.
> An alternative that might work for me is a lightweight mode of conversations UI
> - show me a single message by default and make me click to show the
> conversation.

an alternative, from the above line of thought ... scrap all the ideas above, no "conversation indicator" but 
a) Open in Conversation on the toolbar, one click
b) don't open a conversation tab unless there is >1 message (why bother?)
(In reply to comment #1)
> - for each msgHdr in the conversation, gloda updates its special property
> called "conversationCount", sets it to N.

I'm generally on board with this idea, but instead of modifying every message, the right thing to do would be to keep the conversation object up-to-date with information about the conversation.  That was the original plan, but it fell by the wayside.  (You can tell it was in the original plan because the conversation objects pretend to have useful information that they don't actually have :)

We could even go a little further than just storing a count of the messages in the conversation... for example, the threading and chronological structure of the conversation could be stored, and then we could know that someone replied to your message, or there were other messages after your message chronologically.  The other information considered was inlining message snippets in the conversation object, at least of the unread messages, for Bryan's various conversation-centric displays.

I have great faith in protz's ability to implement something like this :)
(In reply to comment #4)
> I'm generally on board with this idea, but instead of modifying every message,
> the right thing to do would be to keep the conversation object up-to-date with
> information about the conversation.  That was the original plan, but it fell by
> the wayside.
If I understand you correctly, you're thinking about:
1) enhancing the GlodaConversation objects with extra information and,
2) running a background gloda query when a message is displayed, that updates the UI when it finds out about related messages in the same conversation (and does nothing if we moved to something else and the query didn't have time to complete in time).
> 
> We could even go a little further than just storing a count of the messages in
> the conversation... for example, the threading and chronological structure of
> the conversation could be stored, and then we could know that someone replied
> to your message, or there were other messages after your message
> chronologically.  The other information considered was inlining message
> snippets in the conversation object, at least of the unread messages, for
> Bryan's various conversation-centric displays.
That sounds pretty cool. That would enable us to do things like:

------------------------------------------
Message 1           |  From:
|- Message 2        |  To:
\- Message 3        |  Subject:
   |- *Message 4*   |
   \- ... etc.      |  Message body....

With the bolded message in the left half telling you how the message you're reading relates to other messages in the conversation.

> 
> I have great faith in protz's ability to implement something like this :)

Sure. I'm taking this bug. Do you believe Gloda's current performance will be able to cope with repeated queries for each message displayed? Of course, it won't block the UI, since it's asynchronous gloda queries, but it might take a lot of time to complete!
Assignee: nobody → jonathan.protzenko
(In reply to comment #5)
> If I understand you correctly, you're thinking about:
> 1) enhancing the GlodaConversation objects with extra information and,
> 2) running a background gloda query when a message is displayed, that updates
> the UI when it finds out about related messages in the same conversation (and
> does nothing if we moved to something else and the query didn't have time to
> complete in time).

Yes to 1, kinda to 2.  It should be a background query, but just for the currently displayed message, which will also net us the conversation meta-info.  We would not query for the other messages.

> > I have great faith in protz's ability to implement something like this :)
> 
> Sure. I'm taking this bug. Do you believe Gloda's current performance will be
> able to cope with repeated queries for each message displayed? Of course, it
> won't block the UI, since it's asynchronous gloda queries, but it might take a
> lot of time to complete!

The query I'm proposing is not all that expensive.  It could be optimized fire if desired so we only retrieve the conversation object and don't return the message object to gloda.  (The lookup by message-id which would result in a message would still happen for join purposes, but gloda would not hear about it so it would not need to join on the message text or perform the contact/identity lookups.)
(In reply to comment #6)
> The query I'm proposing is not all that expensive.  It could be optimized fire
> if desired so we only retrieve the conversation object and don't return the

s/fire/further/.  Need to stop cooking smores and responding to bugs at the same time.
I think I like how this is evolving. 

To add to comment 5, it would be neat to know whether the message i am viewing was preceded somewhere in the same subthread by a message *I* wrote. (Bonus points for indicating proximity) The reason for wanting this information is to help gauge whether how strongly a response is warranted from me. The immediate context is pretty much as I laid out it in comment 0. 

Plus, let me throw out this thought from the (shudder) newsgroup world, where I have often thought about this type of issue more than in the mail world. For sanity sake one often operates in view unread messages, with often long threads, many participants, and many subthreads.  The question often arises - is this person's article I am reading in a subthread where I previously commented?
(In reply to comment #8)
> I think I like how this is evolving. 

Just so we're clear, this would all be somewhat speculative and any UI would need to start out life as an extension, and there is no guarantee of ux-review approval for such a change to the message reader header...

The gloda changes can be more directly greenlit since it's a direct win, although since we would need to bump the schema version, we might want to stack up a few disk space/performance wins before landing it.  (Search table column re-ordering and page size are the super easy disk space win and performance win, respectively.  Page size may be a minor kick in the pants in terms of disk space usage though, so it would be nice if we could have even super-naive stop-word support in the tokenizer at the same time too...)
Bryan, any thoughts about this?
To give the kind of information display you're looking for I think you'd need something like the Thread Arc [1] to accurately convey to people that this message is part of a conversation.  We could try icons and text but a small visualization would really be the right way to go.

Just thinking out loud here.  If you had Gloda grab the conversation data about a message after it was displayed you could fade in a visualization about the conversation once gloda returned with the information.  Even something simple, as the Thread Arc is sweet but likely more than is required for this goal. 

See Thread Arcs first, then look at these examples:

Single Message
(o) 

Child Message
o-(o)

Parent Message
(o)-o

Grand Child Message
o-o--(o)

Grand Parent Message
(o)--o-o

Middle Child
o-o--(o)--o-o

These 6 types could probably give you just enough information about the conversation to know if you want to open it up in the viewer; I might be missing a few others that would be important.  The left and right most dots would be related to the earliest and latest messages in the conversation.

Clicking on any of these visualizations (except maybe the single message) would take you to the conversation list view.  It's possible that you could implement tooltips for each message dot such that you give the sender and date/time of the message for a quick glance at the whole conversation.

A small visualization like this could possibly just fit in a single line in the header space, though I haven't really looked for space like that so don't hold me to it.

[1] http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/7a30ed0aac59bf5d85256d79006f272f?OpenDocument
(In reply to Bryan Clark (Firefox Search PM) [:clarkbw] from comment #11)
> To give the kind of information display you're looking for I think you'd
> need something like the Thread Arc [1] to accurately convey to people that
> this message is part of a conversation.  We could try icons and text but a
> small visualization would really be the right way to go.

+1
See Also: → 1475910
Severity: normal → S3
See Also: → 531319
Attachment #9381734 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: