Hi Jeroen - I totally accept a real conversation could be 3-way (or more) so the terminology is a bit awkward - fact is conversation/thread is mixed up now so I hijacked the first term. I agree the UI presentation highlights quite a lot of interesting issues, a 'contact-centric conversation' needs to consider the to, from and cc fields, and there's a specific issue exactly as you say with distribution lists.
All this only matters a damn when you arrive at the list by clicking on a contact - if you're happy browsing folders, searching, and sorting by columns, then you can choose a folder/thread view without much of an issue.
In a trivial example of an email thread between 3 people, assuming at various times the contacts are all in the from, to and cc fields (e.g. the participants are doing 'reply-all'), then the 'contact-centric conversation' *will* pull out all the emails in the thread. The UI display becomes multi-state though -
- From <contact>,
- From <user> To/CC <both contacts>
- From <another contact> To <user and contact>
I've thought about a good UI for a 'contact-centric conversation' (maybe I'll stick with that phrase...) between multiple people (because of the multi-state issue) but at this formative stage I just sketched something basic:
http://collabtools.blogspot.co.uk/2012/03/email-conversation-improved-style....
Once you have the email list in the context of 'contact', you're still able to toggle it between a 'thread' view and 'list view' - I hadn't really considered the 'contact-centric thread' view as that should be very similar to the folder thread view (although the UI could still highlight emails *from* the contact in some way). Note that looking at the contact-centric view doesn't preclude alternate searches or the traditional folder or thread views...
Folder-independent searching should be kick-ass though...
There are other advantages to a 'contact-centric' view, particularly that you can include other information that is contact-centric, such as other message types or even trivially contact information from other systems. A web-based client makes this particularly easy. A specific point is this typically requires a *reverse* lookup from email address to user-id for colleagues within the enterprise as that's what the information elsewhere is keyed on (e.g. shared documents in the document system).
Thanks for the nudge - if there's anything I should do to help let me know...
cheers - Ian
On 2012-03-29 11:44, Jeroen van Meeuwen (Kolab Systems) wrote:
On 2012-03-29 11:00, Ian Lewis wrote:
Hi Jeroen, thanks very much for the comment as my work seems a bit like sailing the unknown at the moment. The Cyrus IMAP "Conversations" are interesting mainly because an email thread search now spans folders. However, as far as I can tell, that development really refers to a THREAD (reply emails with a common parent email), not what I would call a CONVERSATION (emails between two people).
Hi Ian,
I'm sorry, obviously you have given this a lot more thought than I have - I didn't want to raise any ambiguity in terminology, but I suppose there's a point in using (among other things, perhaps?) cross-folder threading. Note that the "Conversations" feature in Cyrus IMAP, if I recall correctly, is also supposed to implement cross-folder search capabilities (i.e. search for From/To/CC <contact>?).
I reckon you'll agree, a conversation does not necessarily exist between just two peers. I reckon there may be many parties to a conversation, and perhaps, intuitively, users expect no gaps to exist in a conversation - but you tell me ;-)
So, if I were to select "Lewis, Ian" wanting to see all communications involving "Lewis, Ian", I suppose I want to see the complete thread and not just the messages you sent or the messages I myself or somebody else (with you or me in CC or through a list?) sent to you. I wonder what the conversation(s) would otherwise look like in a UI? A "thread" -as part of one or more conversations- with/without gaps comes to mind, and I suppose there's quite a difference between the two.
In any case, the "Conversations" feature in Cyrus IMAP isn't finalized. It needs an RFC draft still, and then the server-side implementation needs to be brought up to par with the actual proposed definition of the protocol extension. I *suppose* this could be a very interesting endeavour for you to participate in, and I'm confident you'd bring an insightful, valuable perspective to the entire process.
Admittedly, I don't think work on the definition has even started yet. While this means there's quite a lot of work to do, I suppose it also means there's more flexibility as to what the protocol extension definition ultimately ends up looking like.
Hence, I figured I'd give you a nudge ;-)
Kind regards,
Jeroen van Meeuwen