It probably will be - I'm intending to rewrite my changes from scratch and although I'm 30 hours into the mods, this is first time I've waded through the Roundcube code.

As far as I can tell, it's not just the list code that needs changing for lists to co-exist - the core Roundcube mail/addressbook 'task' code that listens for e.g. 'select' events will need changing to be more discerning about where the event came from.

Thanks for the advice - it all helps.

Dr. I. J. Lewis Director, University Computing Service University of Cambridge O: +44 1223 334702 M: +44 7774 017 590 (asst: Lori Klimaszewska lamk2@cam.ac.uk)

On 28 Mar 2012, at 08:10, Peter Overtoom ps.overtoom@redheadtech.nl wrote:

Isn't it a better idea to completely revise the "List" codes to allow 2 instances on one page instead of hacking in one change at the time? You could submit the changes to the main branch.

On Tue, Mar 27, 2012 at 8:17 PM, Ian Lewis ijl20@cam.ac.uk wrote: My experimental effort in extending Roundcube to provide a 'contact-centric' email experience is progressing ok, although I'm doing some fairly major engineering... The net of it is to arrive at the layout shown in the attached screenshot - the 'contact-centric' view is reached by clicking on a contact name anywhere it appears (otherwise Roundcube still behaves as usual, with folders of emails being displayed in the preview pane.) Contact names appear in the contacts list, in the mail list display 'From:' column, and in the From, To, CC fields of emails. Emails are opened by clicking on the 'Subject', as opposed to anywhere on the entire row.

From the screenshot you can see I've got multiple 'lists' on the same page (I'm using an updated Larry style). I.e. contacts and mails, having taken the contacts list off the Larry compose page (thanks Thomas). But I'm dealing with clashes between the lists all the time - I've sorted out the basic 'select' events. Today's discovery is the 'pagenext' etc commands are conflicting between the lists (i.e. the pagenext button on the contact list and the mail list are triggering the same command).

Has anyone dealt with this issue before and have a recommended approach? At the moment I'm hacking fixes in as I go along but need to choose between giving the contact list and mail list different commands, or modifiy the receiving code to take note of which gui object the commands came from...

thanks...

Ian

Ian Lewis Director, University Computing Service University of Cambridge office: +44 1223 334702 mobile: +44 7774 017590 _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev

---

Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev

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). Maybe it's too late to agree different meanings of these terms, but here's the proposal:

Contact-Centric Conversation Definition:

THREAD: given an EMAIL parent, a sequence of EMAIL replies traceable to that common parent. There's no reason afaik for this to be folder-specific except for limitations of server implentation. A thread ignores contact references entirely.

CONVERSATION: given a pair of CONTACTS (typically one is the current user of the email client), some sequence of EMAILS exchanged between those contacts. Again, there's no particular reason to limit this to a folder, and the minimum sensible implementation would search both the inbox and sent items folders.

Clearly the conversation view could be organised by thread if the user prefers.

Cyrus searching in multiple folders to pull out threads is a good thing though. It's not clear to me that those developers have considered the 'contact-centric' view at all though.

My work comes in a different direction: what if 'contact' was genuinely a first-class data object in the email client, (1) how would you select the contact? (2) how would the email client behave then?

(1) is straightforwardly by clicking on the contact name anywhere you see it.

(2) this is where 'conversation' (by my definition) appears - it's a fairly logical presentation of EMAILS with a CONTACT as the primary context. Alternatively the 'folder' presentation can be maintained with the emails presented by folder (e.g. 'Inbox = From, and Sent = To) - this uses existing standard functionality of the IMAP client by searching the folder based on email address.

The work I've done building a prototype with Roundcube suggests the contact-centric approach does have merit, not least as it co-exists quite well with the existing folder-view of emails, and also suggests it is materially different than the practical implementation of 'address book' that exists in all email clients I've seen.

I have an advantage at the moment in that afaik I'm the only user of a real contact-centric email client (although of course all email clients have address books) and accumulating comments from real experience in a blog:

http://collabtools.blogspot.co.uk/2012/02/contact-centric-email.html

Thanks again for your comment re Cyrus - it's certainly useful to me.

cheers - Ian

On 2012-03-28 09:27, Jeroen van Meeuwen (Kolab Systems) wrote:

On 2012-03-27 19:17, Ian Lewis wrote:

...

My experimental effort in extending Roundcube to provide a 'contact-centric' email experience is progressing ok, although I'm doing some fairly major engineering... The net of it is to arrive at the layout shown in the attached screenshot - the 'contact-centric' view is reached by clicking on a contact name anywhere it appears (otherwise Roundcube still behaves as usual, with folders of emails being displayed in the preview pane.) Contact names appear in the contacts list, in the mail list display 'From:' column, and in the From, To, CC fields of emails. Emails are opened by clicking on the 'Subject', as opposed to anywhere on the entire row.

Hi Ian,

Thank you for the interesting exercise you're going through - while you're making progress it becomes more and more interesting to me where you're going with this.

I do have a special interest because, among other reasons, Cyrus IMAP will most likely -in the foreseeable future- release a feature called "Conversations" - emails related to one another, across the traditional boundaries of a folder, which almost naturally, I suppose, is most instinctively navigated through Contacts, Categories, Contexts, Distribution Lists and whathaveyou.

This work is currently ongoing within FastMail(.fm), and though without an RFC (there's plans to submit a draft for a proper IMAP4rev1 extension RFC), but if you are interested, let me know.

Kind regards,

Jeroen van Meeuwen

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