Experimental Message View
Bryan Clark
========
There is a lot of interest in working towards some ideas of a better, faster, and sexier way of viewing and working with mail. But this work requires a lot of experimentation to iron out all the details that cannot be understood with mockups and animations. So it seems we could use a first pass at some ideas and a base platform to spring more ideas from.
A problem exists right now that it is extremely hard to create a new view or new aspects to a view. Fast and complex queries against mail are currently slow and difficult to execute.
Most of the changes discussed below surround a conceptual idea of implementing a meta-layer that sits above the current message store and provides fast and useful relational meta data information about messages. This meta-layer would be implemented in parallel to the existing message store system. There will likely be some data syncronization issues with having two database systems holding information about messages, however because our goal is to provide an incremental improvement to the current system this seems to be the better path forward when compared to ripping out the existing system and replacing it wholesale.
This experimental view is just that, experimental. If it were to be included in any kind of thunderbird release it would likely be included as an option for people to try hoping for feedback of the changes made. Pieces or whole parts of this experiment may become integrated into a new future default view of mail, however it is impossible to know what those changes would be right now.
The New Approach
==============
The new view is designed to help you process mail more effectively. Taking a lesson from Inbox Zero, "What's the action here?" [1] with these kinds of questions.
- What does this message mean to me, and why do I care?
- What action, if any, does this message require of me?
- What’s the most elegant way to close out this message and the nested action it contains?
Basic Experimental View
=================
Rich Message List and Conversation Data Mine Bar - Designed for processing conversations
+--------------------------------------+
| |
+-----+-+-----------------+-+----------+
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| {1} | | {2} | | {3} |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+-----+-+-----------------+-+----------+
{1} - Accounts Listing - remains the same as it currently is
{2} - Rich Message List - rich listing of a threaded conversation view
{3} - Conversation Data Mine Bar - conversation and person contextual information
As you can see the major change happening would be a new type of message list as well as the addition of the data mining bar. The new rich message list would replace the existing message list and the data mine bar would replace the message view pane with a section for context data analysis similar to the Xobni bar [2].
From this main view a person can quickly process conversations by archiving, deleting, or opening the conversation in a tab. Which brings us to the next major layout change.
Conversation Tab with Rich Message List and Message View
+--------------------------------------+
| |
| ___________ ______________ |
|/_All__Mail_\ / Conversation \ |
+---------------+-+--------------------+
| | | |
| | | |
| | | |
| | | |
| | | |
| {2} | | {4} |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+-+--------------------+
{1} (accounts) remains in _all_mail_ but is not shown in the
conversation tab{2} Rich Message List - rich listing of a threaded conversation view
{4} Message View Pane - displays the entire message at optimized width for reading
One way we're optimizing the first view for processing mail is to allow people to "intend to read" a conversation. The rich message list should give enough of an indication of a conversations content that a person could decide if they really need to read the entirety of any of the messages.
Much like reading online news people should be able to switch between processing and reading mail without losing their context. [3] With a double click on any message (threaded or not) in the rich message list you will open that conversation in a conversation tab (shown above). Similar to the tabbing methods in Firefox if you were to right click or middle click a conversation/message you could open in a tab in the background while keeping your context on the current message list.
There is some possibility to provide some more context information like the data mine bar in this conversation view tab. I'd love to discuss ideas on how this could be possible.
Opening a Conversation (a walk through example)
=================
From the main processing view. (ugly, yet live example [4])
+--------------------------------------+
| |
+-----+-+-----------------+-+----------+
| | | | | |
| | |-----------------| | |
| | | (1) | | |
| | |-----------------| | |
| | | | (2) | | |
| | | +---------------| | {3} |
| | | | | | |
| | |-+---------------| | |
| | | | | |
| | |-----------------| | |
| | | | | |
| | | | | |
+-----+-+-----------------+-+----------+
(1) First message in a conversation (2) Second message in a conversation
{3} Conversation data mine view
When a person single clicks on (1) it selects the message and changes {3} to display information about the person, message, and previous interactions with that person. When the person double clicks on (2) a new tab is opened showing the (1) conversation and the (2) message in the message pane.
+--------------------------------------+
| |
| ___________ _________________ |
|/_All__Mail_\ / Conversation [x]\ |
+---------------+-+--------------------+
| (1) | | |
|---------------| | |
| | (2) | | |
| +-------------| | {4} |
| | | | |
| +-------------| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+---------------+-+--------------------+
The conversation tab that was opened shows the conversation subset of
the original rich message list. Another tab has appeared during this
change, the "All Mail" tab, which gives you access to the original 3
pane processing view. To implement this kind of interface experimentation with the current code paths would be an extremely challenging excercise, yet if we believe there is a lot of value in encouraging this kind of experimentation we need to develop a new system for querying and using this kind of information.
Creating the Experimental Layout
========================
There are a number of different ways one could try to implement a system that provides the kind of information we're looking for but it's not quite time to jump into that yet. Our motivation here is to experiment and build a better approach to general experimentation in a direction.
At a high level this kind of change requires a richer and faster relational system for our message data. All of the information required to create the above rich list or data mine is essentially meta data to the actual messages and not message data at all. Only at the {4} message view should we need to query the current message store for the message data.
Here's a look at some of the new pieces.
Rich Message List
=============
Here's an examination of the rich message list items.
+---------------------------------------------+
| {{1}} {{ 2 }} {{ 3 }} {{ 4 }} |
| {{ 5 }} |
| {{ ... }} |
| {{6}} {{ 7 }} |
+---------------------------------------------+
{{1}} - photo : possibly provided from x-face, facebook, gmail, or
local address book sources{{2}} - sender
{{3}} - subject
{{4}} - date : relative time
{{5}} - short message text : first 2 sentences (45 words?) of message body
{{6}} - attachment : number and type of attachments
{{7}} - tags : any tags applied to the message or conversation
The item is designed to focus on the sender and the message content, the two elements of a message that matter most to people. Here's an example of a message item.
+---------------------------------------------+ | [[]] Bryan Rich Message List 1 hour ago | | the first couple sentences of this | | message are placed inline in the item | | 2 @ mozilla, thunderbird, important | +---------------------------------------------+We'll need a lot of experimentation on the number of lines of text we show. This will likely depend on the horizontal size of the message element and the number of words we'd like to present the person with.
Conversation Data Miner
=================
The goal of the data miner is to allow you to extract much more context from a message than is normally present and provide actions for processing mail based on that context. I don't want to constrain what could be done in the data miner view even though there will be constrains on how it's displayed. I like how the Xobni [2] sidebar has arranged data items, however I think we can also focus more on the existing message and current conversation.
+----------+
| |
| |
| |
| |
| |
| {3} |
| |
| |
| |
| |
| |
| |
+----------+
Here are some ideas for items to display in the sidebar.In general:
For the current message:
- Attachments (open or save)
- links (pull out links as often message simply contain one or
two links)
- images
- files
- Actions
- Reply, Forward, etc.
- Archive
- Tag
- Move (to folder)
- Previous Messages from this person
- Previous Attachments from this person
Concerns
======
There are lots. This is an extremely raw idea, thus the experimental status. However a major part of the goal here is to create a better platform for working with views, especially new and experimental views that could change how people use mail.
This obviously won't be right for everyone, especially initially. Hopefully this kind of example will allow or inspire some other people to dream up some really kick ass stuff.
Cheers,
~ Bryan
[1] http://www.43folders.com/2006/03/20/action
[2] http://wiki.mozilla.org/User:Clarkbw/Xobni_Like_Extension
[3] http://clarkbw.net/blog/2008/05/20/tabulation/
[4] http://clarkbw.net/designs/msg-list-view/msg-view.html
Joshua Cranmer
> Motivation
> ========
>
> There is a lot of interest in working towards some ideas of a better,
I would also like to add, for completeness's sake, that limiting the
discussion to "mail" is perhaps too restrictive. RSS feeds, representing
objects as diverse as the latest headlines, checkins to a repository, or
even a bug database should also be considered in the proposal, as well
as other potential account types for Thunderbird (like IM accounts). I
bring this up because, e.g., I may be using a combination of accounts as
a basis to search for a conversation involving proposed schema for a
database, across IRC logs, personal emails, bugzilla communication, and
newsgroups.
In this respect, accounts need some sort of metadata describing them so
that users can build powerful queries aggregating information from a
plethora of different sources.
> Most of the changes discussed below surround a conceptual idea of
> implementing a meta-layer that sits above the current message store and
> provides fast and useful relational meta data information about
> messages. This meta-layer would be implemented in parallel to the
> existing message store system. There will likely be some data
> syncronization issues with having two database systems holding
> information about messages, however because our goal is to provide an
> incremental improvement to the current system this seems to be the
> better path forward when compared to ripping out the existing system and
> replacing it wholesale.
How will this new meta-layer interact with the message databases,
especially given that many want to make databases account-level, and
that SQL-ification should bring some improvements on the basis of
indexing messages better?
> Basic Experimental View
> =================
>
> One way we're optimizing the first view for processing mail is to allow
> people to "intend to read" a conversation. The rich message list should
> give enough of an indication of a conversations content that a person
> could decide if they really need to read the entirety of any of the
> messages.
>
> Much like reading online news people should be able to switch between
> processing and reading mail without losing their context. [3] With a
> double click on any message (threaded or not) in the rich message list
> you will open that conversation in a conversation tab (shown above).
> Similar to the tabbing methods in Firefox if you were to right click or
> middle click a conversation/message you could open in a tab in the
> background while keeping your context on the current message list.
When I log into my computer to get new "messages" from Thunderbird, they
tend to fall into several categories. Some accounts are "read every
(non-spam) message very thoroughly" (bugzilla + personal), others are
"read the first message, decide to continue the thread" (mailing lists +
some newsgroups), still others are "read the subject, decide to read the
thread" (other newsgroups, some blogs), and finally the last class is
"read the subject, that's all I need" (bugzilla updates via RSS).
Summarizing, these are the potential actions to take for a message:
1. Read the message irrespective of the subject.
1a. Stop reading new messages and respond immediately.
1b. Queue up a notice to respond to the message after reading others.
1c. Needs no response.
2. Read the first message of a thread.
2a. Read the rest of the messages in this thread like step 1 above,
but action 1a. is probably not going to be undertaken.
2b. Decide I don't need to read this thread, and mark it as read.
2c. Junk this thread (typically newsgroup-specific).
3. Read the subject of the thread/message.
3a. Interesting, perform step 2.
3b. Ignore this thread.
3c. Junk this thread (again, newsgroup-specific).
4. Read the list of messages.
4a. If a message subject is interesting, click on it (and do step 2)...
4b. Otherwise, mark the folder as read when finished with the list.
> Opening a Conversation (a walk through example)
> =================
>
> To implement this kind of interface experimentation with the current
> code paths would be an extremely challenging excercise, yet if we
> believe there is a lot of value in encouraging this kind of
> experimentation we need to develop a new system for querying and using
> this kind of information.
From what I understand, I think the hardest part would be the main
messenger window; the other parts are (conceptually) mere SQL queries on
information which should all be accessible via the databases or other
components like the addressbook. Although it does sound like a good case
for presenting to an extension developer a "unified" SQL database to
query, e.g.:
SELECT subject, date, displayName FROM messages LEFT JOIN addressbook ON
messages.from = addressbook.email WHERE addressbook.category = "work";
Hmm, definitely needs some polishing there.
> Creating the Experimental Layout
> ========================
>
> At a high level this kind of change requires a richer and faster
> relational system for our message data. All of the information required
> to create the above rich list or data mine is essentially meta data to
> the actual messages and not message data at all. Only at the {4}
> message view should we need to query the current message store for the
> message data.
SQL-ification, I hope, will provide a faster relational system, since,
AFAIK, mork doesn't do any indexing beyond oids (if that even), while
the SQL schema will almost certainly index on message IDs and subject,
and maybe author and date as well, thereby speeding up queries on these
topics.
> Rich Message List
> =============
>
> {{1}} - photo : possibly provided from x-face, facebook, gmail, or local
> address book sources
> {{2}} - sender
> {{3}} - subject
> {{4}} - date : relative time
> {{5}} - short message text : first 2 sentences (45 words?) of message body
> {{6}} - attachment : number and type of attachments
> {{7}} - tags : any tags applied to the message or conversation
Here, 1, 5, 6 are the only things you can't get from the message
database right now, and 1 might not even be retrieved from the message
database in all cases.
Andrew Sutherland
> Bryan Clark wrote:
>> Motivation
>> ========
>>
>> There is a lot of interest in working towards some ideas of a better,
>> faster, and sexier way of viewing and working with mail....
>
> I would also like to add, for completeness's sake, that limiting the
> discussion to "mail" is perhaps too restrictive. RSS feeds, representing
> objects as diverse as the latest headlines, checkins to a repository, or
> even a bug database should also be considered in the proposal, as well
> as other potential account types for Thunderbird (like IM accounts). I
> bring this up because, e.g., I may be using a combination of accounts as
> a basis to search for a conversation involving proposed schema for a
> database, across IRC logs, personal emails, bugzilla communication, and
> newsgroups.
Most of these things seem like they can be shoe-horned into the existing
message view of the universe. The trick is in the conversion.
The case that I think is problematic are IRC logs, especially if we're
talking about 24-hour channel coverage. The closest-to-natural
representation I could think of would be treat each line as a separate
message, but that seems like a bad idea. How were you thinking of
representing IRC logs in Thunderbird?
(Instant Message logs are more straight-forward since you can frequently
leverage when the user closed the chat window as an indicator of
conversation termination. Barring that, inactivity seems more reliable
in a one-to-one case.)
> In this respect, accounts need some sort of metadata describing them so
> that users can build powerful queries aggregating information from a
> plethora of different sources.
Can you elaborate on this? Are you talking about having a generic
RSS-account source that also allows you to specify a schema/XSLT that
maps the items into message-world, "I am an IRC account", other?
>> Most of the changes discussed below surround a conceptual idea of
>> implementing a meta-layer that sits above the current message store
>> and provides fast and useful relational meta data information about
>> messages. This meta-layer would be implemented in parallel to the
> How will this new meta-layer interact with the message databases,
> especially given that many want to make databases account-level, and
> that SQL-ification should bring some improvements on the basis of
> indexing messages better?
I am currently working on proposing a candidate schema/plan for
discussion. The idea, as Bryan says, is that the global database exists
above the existing message stores. The information on a message would
consist of enough information to locate the message in the existing
folder-based stores, plus first-class attributes in the global database.
Anything more detailed than that would get proxied to the underlying
message header in the folder-store (once located).
Andrew
Joshua Cranmer
> The case that I think is problematic are IRC logs, especially if we're
> talking about 24-hour channel coverage. The closest-to-natural
> representation I could think of would be treat each line as a separate
> message, but that seems like a bad idea. How were you thinking of
> representing IRC logs in Thunderbird?
Your comment below about inactivity seems to make more sense than each
line. My IRC client logs by the day, but this can be an arbitrary
distinction for someone who regularly stays up past midnight. A good
heuristic would be someone changing their nick to a {regular
nick}[^A-Za-z0-9_-].* and not changing back for a few hours. If not,
mere idling for several hours should work (e.g., if you're NeilAway).
For users unlike me who do not keep IRC open day and night in a screen
on a remote server, closing by logon/logoff seems appropriate.
Of course, configurability is the key here, but we're diverging off-topic.
>> In this respect, accounts need some sort of metadata describing them so
>> that users can build powerful queries aggregating information from a
>> plethora of different sources.
>
> Can you elaborate on this? Are you talking about having a generic
> RSS-account source that also allows you to specify a schema/XSLT that
> maps the items into message-world, "I am an IRC account", other?
Most likely a function or two in an nsIMsgProtocolInfo,
nsIMsgIncomingServer, or nsIMsgFolder (based on account type,
account-level, or folder-level) would be sufficient. This is an idea to
which I am amenable to change, since it is still in an amorphous
ultra-high level conceptual state.
> I am currently working on proposing a candidate schema/plan for
> discussion. The idea, as Bryan says, is that the global database exists
> above the existing message stores. The information on a message would
> consist of enough information to locate the message in the existing
> folder-based stores, plus first-class attributes in the global database.
> Anything more detailed than that would get proxied to the underlying
> message header in the folder-store (once located).
Ah, good to know. /me makes note to CC to the bugs.
Kent James
Kent James
Joshua Cranmer wrote:
> I bring this up because, e.g., I may be using a combination of accounts as
> a basis to search for a conversation involving proposed schema for a
> database, across IRC logs, personal emails, bugzilla communication, and
> newsgroups.
>
Here, here! One thing I comment to friends and family is how incredible
it is that the Mozilla Mailnews corporate culture seems to use
anything-but-email as the normal communication channels.
I am in the middle of a "conversation" with bienvenu about performance
of virtual search. It started in this newsgroup, ran for awhile in irc
(with several other participants), now there's a bugzilla entry on a
website, and I am getting notifications in email. If the mailnews team
figured out how to effectively use TB or SM *in their own work* to
combine information flow, it would be an amazing leap forward.
This is not any different from one of my clients where I am pushing
Sharepoint. Same issues apply - just add phone to the mix (though this
whole thread is related to a phone meeting), and the much more complex
combination of communication that exist in a Sharepoint portal.
That being said, I think it will be a lost cause to use logical
communication metadata to tie together such complex conversations.
Trying to connect bienvenu's bug 436960 to the thread in
m.d.a.thunderbird, using the irc discussion as a link, is a statistical
probability problem, not a matter of putting the right entry in some
database.
rkent
Jan Husak
Does this conversation consider a concept like storing all messages in
one meta / data repository and then allowing to create associations
(e.g. to folders, to persons, to topics etc.) as a virtual link (not a
copy)? This would e.g. allow much more swifter and smoother to manage
cross folder / conversation type associations. Thread management with
links to other data / information sources should be easily associated as
the data would be normalized.
Needs adding of topic associations (today e.g. done through tags or
folders) on an automated bases to pre-classify the email (e.g. set
priorities, handle storage based on thread, mail recipeints (up to the
whole group of people involved in that thread) or simply the topic.
Today automations are done by the filter tool. Ability to create
personalized processing of mail in the background (even if this would
require some SQL type of logic like state-triggers (email just received,
did not look at it since 2 days, email outside of your set domain ... so
potentially a customer and needs follow-up etc.) would increase a lot
the experience of doing manual and repeated work with conversations and
would allow to focus on content. Management of the content could be
automated and would be the real benefit of such a new approach.
PS: I'm working on the network management (event handling) side of the
house and we've implemented NMS systems that work like a rule featured
email system incorporating automated decisions based on the operational
model. I would associate that each individual using an email system
works differently but finally faces similar challenges. A rule based
framework for email processing automations could be adjusted by any one
individually but the feature would be a common differentiator
Would that mean that this approach would dis-continue the file system
based email storage?
Andrew Sutherland
> Does this conversation consider a concept like storing all messages in
> one meta / data repository and then allowing to create associations
> (e.g. to folders, to persons, to topics etc.) as a virtual link (not a
> copy)? This would e.g. allow much more swifter and smoother to manage
> cross folder / conversation type associations. Thread management with
> links to other data / information sources should be easily associated as
> the data would be normalized.
One meta/data repository will link all messages together, virtually.
This will capture conversations spanning multiple folders and (I
suppose) accounts. We're/I'm still in the brain-storming phase, with a
post/link hopefully to come out in the few days. As such, input is
greatly appreciated...
Could you provide some specific example associations that you would want
and would be likely to make?
> Today automations are done by the filter tool. Ability to create
> personalized processing of mail in the background (even if this would
> require some SQL type of logic like state-triggers (email just received,
> did not look at it since 2 days, email outside of your set domain ... so
> potentially a customer and needs follow-up etc.) would increase a lot
> the experience of doing manual and repeated work with conversations and
> would allow to focus on content. Management of the content could be
> automated and would be the real benefit of such a new approach.
>
> PS: I'm working on the network management (event handling) side of the
> house and we've implemented NMS systems that work like a rule featured
> email system incorporating automated decisions based on the operational
> model. I would associate that each individual using an email system
> works differently but finally faces similar challenges. A rule based
> framework for email processing automations could be adjusted by any one
> individually but the feature would be a common differentiator
Are you talking about implementing an Expert System/Rule-Based
Programming System in Thunderbird?
It's an interesting idea... right now, (it is my understanding that)
message filters are run at discrete times, namely on receipt of the
message and when manually executed. This could be generalized to
conceptually always being active, and firing as soon as a state-change
results in a rule applying, even time-based thresholds. (Assume a
Rete-ish implementation for efficiency, although if we exempt time-based
thresholds, simply applying message filters to any message that has
flags/tags/etc. changed could also work.)
> Would that mean that this approach would dis-continue the file system
> based email storage?
I think the current idea is to de-couple the storage of the e-mails from
the global database that stitches all the e-mails together. The future
enhancement for e-mail storage is to make that interface pluggable, so
that people can use Maildir or whatever their heart might desire.
For now, I think I can explicitly say that no one is thinking about
storing the e-mail bodies in the SQL database.
Andrew
David Huynh
accounts and folders in Seek 2.0. The tricky part is knowing whether the
db has fallen out of sync with each particular folder. Is there a way to
determine the latest date/time when a folder was updated? Also, are the
existing message keys and thread keys unique across all accounts and
folders?
Thank you!
David
Andrew Sutherland
> I'm actually trying to build this sort of one virtual db for all
> accounts and folders in Seek 2.0. The tricky part is knowing whether the
> db has fallen out of sync with each particular folder. Is there a way to
> determine the latest date/time when a folder was updated? Also, are the
> existing message keys and thread keys unique across all accounts and
> folders?
There are two potential issues on the sync front. The first is whether
Thunderbird is really up-to-date with the folder in the IMAP case, the
second is whether the global database is up-to-date with what
Thunderibrd knows. I believe Emre and David Bienvenu are improving the
IMAP scenario. I don't know enough to say about the date/time front
right now, other than that the timestamp of the .msf file probably won't
be any help. My mental plan thus far has just been to aggressively
listen for all changes and rely on always being active.
Message keys uniquely identify a message in a folder. Thread keys are
just the message key of the message that was used to initially create
the thread.
Would you be willing to (briefly) sketch out the current status of your
global database and your plans? I'm sure your experience with the
Haystack group/project and SIMILE project have given you a lot of
insight into this fairly new territory for Thunderbird/MailNews.
For now, I am most interested in your general implementation plan and
how it deals with scalability. I believe Seek 1.0 implements an
in-memory database, and I think I recall mention of (but could be
imagining things) perhaps persisting JSON-style representations for indices?
I think it would be fantastic if we could combine efforts, but realize
that the needs of Seek 2.0 may be different (and perhaps more pragmatic,
in a way) than at least our 'stretch' implementation plan for a global
database for Thunderbird 3.0. At the very least, I would like to
understand the data Seek wants from a global database so that perhaps
the Thunderbird global database would eventually be able to serve those
needs, should our needs not be reconcilable in the near-term.
Andrew
Andrew Sutherland
> Andrew Sutherland wrote:
>> The case that I think is problematic are IRC logs, especially if we're
>> talking about 24-hour channel coverage. The closest-to-natural
>> representation I could think of would be treat each line as a separate
>> message, but that seems like a bad idea. How were you thinking of
>> representing IRC logs in Thunderbird?
>
> Your comment below about inactivity seems to make more sense than each
> line. My IRC client logs by the day, but this can be an arbitrary
> distinction for someone who regularly stays up past midnight. A good
> heuristic would be someone changing their nick to a {regular
> nick}[^A-Za-z0-9_-].* and not changing back for a few hours. If not,
> mere idling for several hours should work (e.g., if you're NeilAway).
>
> For users unlike me who do not keep IRC open day and night in a screen
> on a remote server, closing by logon/logoff seems appropriate.
>
> Of course, configurability is the key here, but we're diverging off-topic.
Off-topic perhaps, but I think this is a good thing to ponder out, at
least to a first approximation. Kent James' point about the mailnews
workflow's lack of dogfooding in this thread is well made.
(<68WdndP7mON9KtnV...@mozilla.org>, though I have no idea
how one is supposed to use such a reference) Although use of IRC is
probably rare outside of open-source development work-flows, in my
personal experience chat-rooms do crop up in corporate software
development as well.
I like what I think you are proposing. It sounds like you are
suggesting that we treat a user's comments in a given time window as a
blob/message, ignoring other users' comments, at least in terms of
content analysis (or they could be treated as quotes). Presentation, at
least when chat-aware, should still display things like a (fancy) IRC log.
So, when indexing the comments made by user A in a time interval, we could:
* treat anyone else who posted a message/seemed alive during that
interval as a 'cc'
* treat anyone else who A directed a message to as a 'to'
* (ignore anyone with 'bot' in their name)
* treat the chat channel as the newsgroup name equivalent
Depending upon how overkill we get, we could potentially go the fuzzy
logic road and attempt to express the to/cc tag values as values in the
range 0.0-1.0 (or a discrete equivalent). This would help capture that
involvement in a conversation isn't the same thing as being a major part
of the conversation.
I'm not sure what to do about (gmail-style) 'conversation' and reply
notions. It seems like they should probably be omitted; having reply-to
remain acyclic seems desirable, and treating a channel as a newsgroup
would seem to capture the 'conversation' notion sufficiently well.
Thoughts?
Andrew
Ron K.
I am jumping in here to iterate a couple of points. Generally I do not
need any of this new View function for my One POP3 account and 4-8 News
accounts. So that translates to, I want my present 3 Pane view as it is
most efficient for such a basic setup.
However, from the context of my 22 years of Army service when e-mail was
being introduced, I can see the utility for coordination of content that
accumulates from multiple sources. I had e-mail coming from the DOD
.mil.net as well as content from two WAN's. Our integration workaround
option was attachments to mail of text files from the WAN softwares.
Once Windows came on the scene we got it's clipboard. A big step
forward. So the point I am getting to is there are some sources that do
not fit any e-mail centric storage plan. It has been raised by Joshua
that IM, IRC and some Web Centric sources are elements of his
communications which tie to e-mail. The News networks are also key
sources of collaboration. We are using that here, even though several of
the participants have the list mail being cross-linked by Mailman to
news.mozilla.org. It is only with Mailman functioning as a
man-in-the-middle gateway that the two incompatible protocols can work
together. One benefit that Jabber protocol has is it's XHTML driven
messaging that may be easier to apply Meta Data extraction tools to.
Oh yes, the DOD reference brings up a relevant issue. Security has to
also fit into the scheme. I anticipate that a User could have data from
confidential sources that must never be propagated outside the security
framework the User works in. Meaning RSS feeds that may relate to the
work flow should not be able to compromise the framework. So SSL Certs
need to be a participant in some way. You may have to work with a mix
of encyphered and clear data, yet have a usable clear summary of
encrypted content that meta data will exist.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
Eddy Nigg (StartCom Ltd.)
> Oh yes, the DOD reference brings up a relevant issue. Security has to
> also fit into the scheme. I anticipate that a User could have data from
> confidential sources that must never be propagated outside the security
> framework the User works in. Meaning RSS feeds that may relate to the
> work flow should not be able to compromise the framework. So SSL Certs
> need to be a participant in some way. You may have to work with a mix
> of encyphered and clear data, yet have a usable clear summary of
> encrypted content that meta data will exist.
>
>
A very good point! Well said, Ron!
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Ron K.
I have two related experiences where IRC was the preferred communication
media. One involved a Copyright policy that was being applied to
news.annexcafe.com, a private NNTP server. By being able to use the
chat.annexcafe.com IRC server in a private #Room, staff members were
able to work out details we could not do in News, even with password
authenticated private groups.
Second case was with the Banyon Vines LAN/WAN run from the Pentagon by
the Chief of Chaplains, US Army. That network software included a chat
tool which enabled quick talk on a topic with a minimal audit trail. I
made a comment in another sub-thread which relates to this case.
> I like what I think you are proposing. It sounds like you are
> suggesting that we treat a user's comments in a given time window as a
> blob/message, ignoring other users' comments, at least in terms of
> content analysis (or they could be treated as quotes). Presentation,
> at least when chat-aware, should still display things like a (fancy)
> IRC log.
>
> So, when indexing the comments made by user A in a time interval, we
> could:
> * treat anyone else who posted a message/seemed alive during that
> interval as a 'cc'
> * treat anyone else who A directed a message to as a 'to'
> * (ignore anyone with 'bot' in their name)
> * treat the chat channel as the newsgroup name equivalent
I like you thoughts on how to capture an IRC session and the logic of
how to treat the text flow. The treatment I would apply is any person in
the room is a Lurker unless they use a topic specific key word or phrase
that hints that they made a collateral comment to the conversation. In
other words, some form of a conference call case. Yes, the news
equivalent should permit assigning an ID to the blob for tagging.
> Depending upon how overkill we get, we could potentially go the fuzzy
> logic road and attempt to express the to/cc tag values as values in
> the range 0.0-1.0 (or a discrete equivalent). This would help capture
> that involvement in a conversation isn't the same thing as being a
> major part of the conversation.
>
> I'm not sure what to do about (gmail-style) 'conversation' and reply
> notions. It seems like they should probably be omitted; having
> reply-to remain acyclic seems desirable, and treating a channel as a
> newsgroup would seem to capture the 'conversation' notion sufficiently
> well.
>
> Thoughts?
>
> Andrew
Given that there are some IM extensions and the 'Instantbird' IM
XULRunner application, this is another source that may work with the
Blob treatment if the conversation can be captured. In the case of
'Instantbird' I have looked at it's IRC abilities (primitative in the
0.1.1 alpha) and know it logs IRC. I will also point out the G-Talk
angle, which might get MoMo some financing from Google if those Jabber
conversations might work into the IM solution.
Andrew Sutherland
> Oh yes, the DOD reference brings up a relevant issue. Security has to
> also fit into the scheme. I anticipate that a User could have data from
> confidential sources that must never be propagated outside the security
> framework the User works in. Meaning RSS feeds that may relate to the
> work flow should not be able to compromise the framework. So SSL Certs
> need to be a participant in some way. You may have to work with a mix of
> encyphered and clear data, yet have a usable clear summary of encrypted
> content that meta data will exist.
Could you elaborate on the specific RSS scenario you envision? Are you
talking about side-channel leaks of information (by showing related
pieces of information to what you are looking at, we give information
about what you are looking at), or something else?
In terms of summaries of encrypted content, generally speaking, we
cannot rely on purely automated means to tell us what is (not)
confidential. We have to be told that a specific block of text,
message, interaction with a given user, use of a given account, etc. may
contain confidential information. Assuming something contains
confidential information, it seems much safer to avoid summarizing the
data or using it at all. I know just enough about information theory to
know we're liable to leak information, and making it the user's problem
(by prompting) is no good.
I think the good news is that the global database is unlikely to ever
index anything encrypted in an unencrypted form, at least based on my
enigmail experiences. This solves the security problem but at the cost
of user experience.
I think the best we can do for now is to provide the ability to mark
specific accounts as off-limits to the global database and try and keep
any specific points you or others bring up security-wise as we go about
doing things. (Banning specific folders seems risky because if IMAP is
involved, the deletion model could conceivably result in messages being
indexed that people thought no longer existed.)
Andrew
Ron K.
> Ron K. wrote:
>> Oh yes, the DOD reference brings up a relevant issue. Security has to
>> also fit into the scheme. I anticipate that a User could have data from
>> confidential sources that must never be propagated outside the security
>> framework the User works in. Meaning RSS feeds that may relate to the
>> work flow should not be able to compromise the framework. So SSL Certs
>> need to be a participant in some way. You may have to work with a mix of
>> encyphered and clear data, yet have a usable clear summary of encrypted
>> content that meta data will exist.
>
> Could you elaborate on the specific RSS scenario you envision? Are
> you talking about side-channel leaks of information (by showing
> related pieces of information to what you are looking at, we give
> information about what you are looking at), or something else?
Here I picked RSS as a sample to summarize Blogs, Wiki, and similar
sources that could be relevant to the work flow and are present within
the Tbird environment because of its RSS feed function.
Secondly, I was wondering about side-channel leaks (to use your term).
To take the DOD case, even internal working communication is considered
"For Official Use Only" and any disclosure to the public must be cleared
through Public Relations release channels. Since some sources of
information come from outside DOD, would the concepts under discussion
have vulnerabilities to accidental use of internal information when
communicating to external parties. This scenario would apply to any
Enterprise working with confidential or proprietary information.
> In terms of summaries of encrypted content, generally speaking, we
> cannot rely on purely automated means to tell us what is (not)
> confidential. We have to be told that a specific block of text,
> message, interaction with a given user, use of a given account, etc.
> may contain confidential information. Assuming something contains
> confidential information, it seems much safer to avoid summarizing the
> data or using it at all. I know just enough about information theory
> to know we're liable to leak information, and making it the user's
> problem (by prompting) is no good.
So your saying the fail safe action would be an Opt-In based policy.
Not having access to a DOA IMAP account at present, I have no input on
whether any X-headers are being used by the army.mil.net systems. I do
know I will have to jump through several hoops to reacquire access to an
old mail account I have on the army.mil.net.
> I think the good news is that the global database is unlikely to ever
> index anything encrypted in an unencrypted form, at least based on my
> enigmail experiences. This solves the security problem but at the
> cost of user experience.
>
> I think the best we can do for now is to provide the ability to mark
> specific accounts as off-limits to the global database and try and
> keep any specific points you or others bring up security-wise as we go
> about doing things. (Banning specific folders seems risky because if
> IMAP is involved, the deletion model could conceivably result in
> messages being indexed that people thought no longer existed.)
DOD uses IMAP without exception, as I understand. As I previously
commented, I do not have input on message storage from that network.
This discussion is convincing me to get my account reactivated just to
see what IMAP is about.
>
> Andrew
In general, security is the province of the IM staff of the entity
adopting use of Tbird. If We should see a potential at all, then a test
should be created to spot leaks during Try Out or Tinderboxen builds.
Jan Husak
> Jan Husak wrote:
>> Does this conversation consider a concept like storing all messages in
>> one meta / data repository and then allowing to create associations
>> (e.g. to folders, to persons, to topics etc.) as a virtual link (not a
>> copy)? This would e.g. allow much more swifter and smoother to manage
>> cross folder / conversation type associations. Thread management with
>> links to other data / information sources should be easily associated as
>> the data would be normalized.
>
> One meta/data repository will link all messages together, virtually.
> This will capture conversations spanning multiple folders and (I
> suppose) accounts. We're/I'm still in the brain-storming phase, with a
> post/link hopefully to come out in the few days. As such, input is
> greatly appreciated...
>
> Could you provide some specific example associations that you would want
> and would be likely to make?
The original message that also logically marks the top of a thread would
be the start. Replies on that thread or content (with different subject
but taken from that specific thread) would be representing individual
message records / entries as well.
Associations would be:
- storage folder
- today I store based on sender messages of the same thread in
different folders
- so the message would have an association / tag which store it
belongs to ... this would allow following threads across folders
- Workflow tag
- like the tags we have today (important, work, private etc.)
- to allow views / crosslinks on specific tag topics
- reminderfox like / calendar like etc
- to allow event based (email received) work triggers and their
follow-up / tracking
- associations can be multiple (and extend the requirements above)
- so received email still remains unique but the associations
can be multiple to allow storage, visibility even work flow
handling
>
>
>> Today automations are done by the filter tool. Ability to create
>> personalized processing of mail in the background (even if this would
>> require some SQL type of logic like state-triggers (email just received,
>> did not look at it since 2 days, email outside of your set domain ... so
>> potentially a customer and needs follow-up etc.) would increase a lot
>> the experience of doing manual and repeated work with conversations and
>> would allow to focus on content. Management of the content could be
>> automated and would be the real benefit of such a new approach.
>>
>> PS: I'm working on the network management (event handling) side of the
>> house and we've implemented NMS systems that work like a rule featured
>> email system incorporating automated decisions based on the operational
>> model. I would associate that each individual using an email system
>> works differently but finally faces similar challenges. A rule based
>> framework for email processing automations could be adjusted by any one
>> individually but the feature would be a common differentiator
>
> Are you talking about implementing an Expert System/Rule-Based
> Programming System in Thunderbird?
Not sure how close we are with our notations ... I would not call it an
expert system but from your point of view it could be something like
that. What I'm proposing is the following:
- emails behave like a list of data / records in a container
- you query them (searches) to make associations or highlight
dependencies / content relevance to each other
- one work method is to have content associated storage (content
associations can be done on subject, sender, to or cc: etc.) which
primarily is achieved today by the filter tool on reception
What I would like to see to happen ideally based on event based
management of information (what Network Management in a country wide NOC
is for example) is the following in example:
- if an email marked important (by the mail header) is not read within
24 hours (or any other adjustable time) the system should alert me
- I would consider reading an email be the same like acknowledging it
- if there is no activity on the acknowledged in 5 days I should see
an alert
- I should be able to define different levels of acknowledgements:
- if I receive an email from ZDnet, no follow-up is required
- if I receive an email from my customers, follow-up would be a
desired action
- if I receive an email associated to certain folders, I expect
usually there an exchange (thread) to happen, so I need
notification if I want to contribute on a response
- etc ... the list can be long but it's individual to work patterns
- I would consider different triggers:
- email reception ... if I have unread emails on my imap drive (e.g.
corporate calendar) I consider this another event than downloading
my inbox and distributing received mail according to my filter
settings to the different folders
- triggers on sending emails
- time triggers
- I should have a processing system in the background that allows
setting of tags / state of emails or threads
- for instance if the subject starts with 'URGENT' the system should
highlight these emails more to me applying rules how I acknowledge,
respond or delay activities on it
- if the email subject would contain e.g. Trouble Ticket / Support
Ticket information / state changes / notifications (that are set by
the system sending out the mail) the email system should add
automatically e.g. a customizable URL adding automatically the
Ticket Number to it as an association to the email so that the
ticket could be opened by just clicking this attribute. I would
consider this to be e.g. an additional tag field
I've had this with the NMS Automation products as server based tools /
automations that would run either periodically or triggered by an event
(e.g. reception or time running out) SQL queries on the database.
I'm aware we're not talking SQL here, since the data is not store in an
SQL DB.
On the other hand, I consider the greatest value of an email system to:
- normalize information (TB already does treat POP, IMAP, NewsGroups
messaging the same way so it's a start)
- offload me from repeated work by e.g. moving emails to folders or
trying to catch up with threads across folders ...
I see great potential of a rule based system to allow the user to focus
on content and it's impact / effect it has dealing with the information.
If administration, classification and other rules can be delegated to
the system as automated processing tasks you can significantly improve
user experience with the system.
However, such a automation system would require some expertise on how
you work, what your classification criteria are, how the email system
works etc. and it would be only for advanced users to gain the biggest
effect of it ... so you can call it an expert system.
In combination with Meta data storage and association such a rule based
system would be really a next generation experience.
David Huynh
Thanks for your quick reply! More below...
Andrew Sutherland wrote:
> David Huynh wrote:
>> I'm actually trying to build this sort of one virtual db for all
>> accounts and folders in Seek 2.0. The tricky part is knowing whether the
>> db has fallen out of sync with each particular folder. Is there a way to
>> determine the latest date/time when a folder was updated? Also, are the
>> existing message keys and thread keys unique across all accounts and
>> folders?
>
> There are two potential issues on the sync front. The first is whether
> Thunderbird is really up-to-date with the folder in the IMAP case, the
> second is whether the global database is up-to-date with what
> Thunderibrd knows. I believe Emre and David Bienvenu are improving the
> IMAP scenario. I don't know enough to say about the date/time front
> right now, other than that the timestamp of the .msf file probably won't
> be any help. My mental plan thus far has just been to aggressively
> listen for all changes and rely on always being active.
I think as long as Seek is in-sync with Thunderbird, that's fine. I'm
not concerned whether Thunderbird is really up-to-date with the IMAP
server. When Tb gets updated, Seek gets updated.
I also plan to listen aggressively for all changes, and using a few
heuristics like the count of messages in a folder and the folder's
storage size to determine if it has been changed. I didn't think of the
timestamp of the .msf file but that might help. And I'll give the user
an explicit button to re-index each folder, at least until Tb offers a
better way to check a folder's status.
> Message keys uniquely identify a message in a folder. Thread keys are
> just the message key of the message that was used to initially create
> the thread.
Do you think it's possible to use the "In-Reply-To" headers to piece
together threads that span folders?
> Would you be willing to (briefly) sketch out the current status of your
> global database and your plans? I'm sure your experience with the
> Haystack group/project and SIMILE project have given you a lot of
> insight into this fairly new territory for Thunderbird/MailNews.
I'd very much like to do that. But you should know Seek is more of a
hobby project for me, so I can't make promises on any time frame. Give
me a few weeks--I'm in the middle of a city-city move. Once I'm settled,
I'll write up something.
> For now, I am most interested in your general implementation plan and
> how it deals with scalability. I believe Seek 1.0 implements an
> in-memory database, and I think I recall mention of (but could be
> imagining things) perhaps persisting JSON-style representations for
> indices?
Yes, the in-memory, Javascript database was adopted from my Exhibit
project (http://simile.mit.edu/exhibit/), which I think some Mozilla
folks are already using internally :)
I'm planning on moving entirely onto sqlite, but that'll take some time.
> I think it would be fantastic if we could combine efforts, but realize
> that the needs of Seek 2.0 may be different (and perhaps more pragmatic,
> in a way) than at least our 'stretch' implementation plan for a global
> database for Thunderbird 3.0. At the very least, I would like to
> understand the data Seek wants from a global database so that perhaps
> the Thunderbird global database would eventually be able to serve those
> needs, should our needs not be reconcilable in the near-term.
Yes, I'm totally with you here. Let's just keep one another updated but
not tie our plans together so tightly. As said above, Seek is a hobby
project, so I don't want to slow you guys down in any way.
David
Gervase Markham
Some interesting ideas. I definitely support the general idea of better
and faster search, and putting each message in its context regardless of
where the other messages in a conversation are stored (archive,
sent-mail, todo, ...)
It does amaze me that Google can search the entire web in a fraction of
a second, and yet it takes me up to 30 seconds to search a few thousand
text messages.
Bryan Clark wrote:
> Most of the changes discussed below surround a conceptual idea of
> implementing a meta-layer that sits above the current message store and
> provides fast and useful relational meta data information about
> messages. This meta-layer would be implemented in parallel to the
> existing message store system. There will likely be some data
> syncronization issues with having two database systems holding
> information about messages, however because our goal is to provide an
> incremental improvement to the current system this seems to be the
> better path forward when compared to ripping out the existing system and
> replacing it wholesale.
Perhaps it would be better to define the required capabilities first and
decide on an implementation strategy second?
> One way we're optimizing the first view for processing mail is to allow
> people to "intend to read" a conversation. The rich message list should
> give enough of an indication of a conversations content that a person
> could decide if they really need to read the entirety of any of the
> messages.
>
> Much like reading online news people should be able to switch between
> processing and reading mail without losing their context. [3]
I think "processing" vs "reading" is a false dichotomy. I certainly
don't imagine myself as switching between these two modes when I read mail.
I do the Inbox Zero thing (from Getting Things Done), and I use the
Nostalgy extension for quick keyboard-based message filing. I go through
my inbox, thinking "Do? Delegate? Defer?" and save the message to
archive, todo, support or whatever accordingly. (I hardly ever delete
non-spam non-Bugzilla mail; it's just as easy to archive it.)
If I had to switch from one tab to another for every message read, that
would slow me down loads. Fortunately, this is fixable - just put the
message reading pane back into your first screen.
> With a
> double click on any message (threaded or not) in the rich message list
> you will open that conversation in a conversation tab (shown above).
Double-click = mouse = slow.
Tab switch = context switch, screen layout change = jarring.
If we want to speed up mail processing, Firefox needs to build in
something like Nostalgy, so messages can be filed using the keyboard.
> (1) First message in a conversation
> (2) Second message in a conversation
> {3} Conversation data mine view
We'd need auto-collapsing of quotes a la gmail, otherwise people who
don't trim would make some of these conversations enormous.
Maybe I just have a good memory, but I don't often need to go back and
read the body of previous messages in a conversation. I can normally
remember what they are about, and what the state of play is.
Gerv
Bryan W Clark
Hi Bryan, Some interesting ideas. I definitely support the general idea of better and faster search, and putting each message in its context regardless of where the other messages in a conversation are stored (archive, sent-mail, todo, ...) It does amaze me that Google can search the entire web in a fraction of a second, and yet it takes me up to 30 seconds to search a few thousand text messages.
Bryan Clark wrote:Most of the changes discussed below surround a conceptual idea of implementing a meta-layer that sits above the current message store and provides fast and useful relational meta data information about messages. This meta-layer would be implemented in parallel to the existing message store system. There will likely be some data syncronization issues with having two database systems holding information about messages, however because our goal is to provide an incremental improvement to the current system this seems to be the better path forward when compared to ripping out the existing system and replacing it wholesale.Perhaps it would be better to define the required capabilities first and decide on an implementation strategy second?
One way we're optimizing the first view for processing mail is to allow people to "intend to read" a conversation. The rich message list should give enough of an indication of a conversations content that a person could decide if they really need to read the entirety of any of the messages. Much like reading online news people should be able to switch between processing and reading mail without losing their context. [3]I think "processing" vs "reading" is a false dichotomy. I certainly don't imagine myself as switching between these two modes when I read mail.
I do the Inbox Zero thing (from Getting Things Done), and I use the Nostalgy extension for quick keyboard-based message filing. I go through my inbox, thinking "Do? Delegate? Defer?" and save the message to archive, todo, support or whatever accordingly. (I hardly ever delete non-spam non-Bugzilla mail; it's just as easy to archive it.)
With the message structure you have a subject which can possibly give hints to what the message is about allowing you to make some assumptions. Then there is the general structure of (essay) writing where people begin with an introduction, then arguments, and conclusion. I'm sure everyone knows the purpose of an introduction is to quickly give the motivation and then setup the thesis argument. By giving people the subject and (hopefully) motivation of the message we can help them guess the message contents without opening it.
If I had to switch from one tab to another for every message read, that would slow me down loads. Fortunately, this is fixable - just put the message reading pane back into your first screen.
With a double click on any message (threaded or not) in the rich message list you will open that conversation in a conversation tab (shown above).Double-click = mouse = slow.
Tab switch = context switch, screen layout change = jarring.
If we want to speed up mail processing, Firefox needs to build in something like Nostalgy, so messages can be filed using the keyboard.
(1) First message in a conversation (2) Second message in a conversation {3} Conversation data mine viewWe'd need auto-collapsing of quotes a la gmail, otherwise people who don't trim would make some of these conversations enormous. Maybe I just have a good memory, but I don't often need to go back and read the body of previous messages in a conversation. I can normally remember what they are about, and what the state of play is.
Another thing to think about is if the rich message list should be collapsing headers for the messages you've already read and only showing the new ones. It would clean up the default view of messages to only showing new ones. We'd likely need to always include the initial thread message so we have something to span off.
~ Bryan
Andrew Sutherland
> Do you think it's possible to use the "In-Reply-To" headers to piece
> together threads that span folders?
Yes, using References/In-Reply-To (against the Message-ID) to thread
things works pretty well in general. Unfortunately, not all
clients/MUAs generate these; the most surprising example being that
Yahoo Mail as of May 2008 still did not do so. (But Dan Mosedale
actually took steps to get a bug filed, so perhaps it will now/soon.)
The fallback is to use the subject (or Thread-Index/Thread-Topic if
Exchange was involved in the problem), which Thunderbird's threading
algorithm uses rather aggressively by default.
The major problem for threading across multiple folders seems like the
inability to rely on messages being seen in (approximately) date order,
so children can be seen before their parents. This can be resolved by
leaving markers for messages not yet seen or finding a way to traverse
the messages in date-order (I guess a two pass algorithm over your
global data-store or dubiously trying to order the traversal over all
folders of interest in pseudo-parallel.)
Information on Thunderbird's threading algorithm can be found here:
http://wiki.mozilla.org/MailNews:Message_Threading
Useful, if non-authoritative on thread-index/thread-topic can be found here:
http://blog.postmaster.gr/2007/12/23/more-fun-with-message-threading/
And in case you somehow missed jwz's seminal work on message threading:
http://www.jwz.org/doc/threading.html
>> I think it would be fantastic if we could combine efforts, but realize
>> that the needs of Seek 2.0 may be different (and perhaps more
>> pragmatic, in a way) than at least our 'stretch' implementation plan
>> for a global database for Thunderbird 3.0. At the very least, I would
>> like to understand the data Seek wants from a global database so that
>> perhaps the Thunderbird global database would eventually be able to
>> serve those needs, should our needs not be reconcilable in the near-term.
>
> Yes, I'm totally with you here. Let's just keep one another updated but
> not tie our plans together so tightly. As said above, Seek is a hobby
> project, so I don't want to slow you guys down in any way.
Works for me. Good luck with your move, and may your hobby time be
bountiful :)
Andrew
ovidiu
> The major problem for threading across multiple folders seems like the
> inability to rely on messages being seen in (approximately) date
> order, so children can be seen before their parents. This can be
> resolved by leaving markers for messages not yet seen or finding a way
> to traverse the messages in date-order (I guess a two pass algorithm
> over your global data-store or dubiously trying to order the traversal
> over all folders of interest in pseudo-parallel.)
>
FWIW, this is also subject to ThreadVis extension, which does that cross
folder/account today and seam to do well the dates ..
http://www.student.tugraz.at/ahubmann/threadvis/en/start.html
https://addons.mozilla.org/en-US/thunderbird/addon/6533
ovidiu
> Gervase Markham wrote:
>> It does amaze me that Google can search the entire web in a fraction of
>> a second, and yet it takes me up to 30 seconds to search a few thousand
>> text messages.
>>
> 100% agree. I like to think of our next generation of views as
> searches themselves. When the view is fast then searching and related
> message gathering will be fast as well.
maybe google has a faster computer/machine than yours .. :) Now
seriously, I wonder if google desktop/spotlight/vista search[1] searches
are significantly faster (not web) .. would just be an indicator
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=430614
>>
>> Perhaps it would be better to define the required capabilities first and
>> decide on an implementation strategy second?
>>
> Exactly, didn't mean to give the impression that the implementation
> was decided. Andrew and others are looking into the best way forward,
> I just wanted to offer some of the discussion happening around this as
> an option.
flexible/easy/faster/structured layout to open further possibilities for
other view proposals ..
>>
>> I think "processing" vs "reading" is a false dichotomy. I certainly
>> don't imagine myself as switching between these two modes when I read mail.
>>
> Hmmm, I didn't mean to make them sound as separate as it does reading
> it again.
if you use one tab classic and one with this it may even grow on you ..
(that's from the "you never know" series ..)
Or is just the result of trying to be more conversation oriented than
folder oriented and that reflects in more physical/visual separation ...
>> If I had to switch from one tab to another for every message read, that
>> would slow me down loads. Fortunately, this is fixable - just put the
>> message reading pane back into your first screen.
>>
> Yes, that is a real concern. The aim is to open up conversations you
> intend to read in a single tab, but also allow you to read and assume
> enough content to process messages you don't intend to read. Once in
> a tab you'd be able to read through all the messages in the
> conversation without opening new tabs.
again as above ..
>
>>> With a
>>> double click on any message (threaded or not) in the rich message list
>>> you will open that conversation in a conversation tab (shown above).
>>>
>>
>> Double-click = mouse = slow.
>>
> I am a huge fan of keyboard navigation, I believe it's key to
> providing a path for users to continue progressing towards a faster
> experience. I look at keyboard navigation in a game design sense
> where good games have simple controls but allow the person to continue
> progressing in experience and abilities.
dbclick may just = enter (or ctrl enter for tab?) . And even if not, the
mouse vs key is a matter of usage habits.
[May find that many not so computer people, and they are many, do not
do that .. I've being growing to the idea that the speed is rather on
the user thinking/processing side for the normal user, than ui click
optimization, when I was a trainer in soft. Meaning that optimization
may just be better taken in terms of intuitive ui, where keys are for
some middle to advanced user ..]
>> Tab switch = context switch, screen layout change = jarring.
>>
> Yes, but I think a counter argument can be made for rendering every
> message. In reality you don't read the entirety of every message, yet
> we flash the preview pane with the full text of every new message in
> order to process it.
like those spam in ng (and others) that you wanna kill, but when click
on it useless open happens ..
>> If we want to speed up mail processing, Firefox needs to build in
>> something like Nostalgy, so messages can be filed using the keyboard.
>>
> I like the Nostalgy extension. I want to have actions in the data
> mine view with obvious keyboard shortcuts such that we can offer the
> power and feel of Nostalgy by default.
again as above above .. this is advanced user .. (I use keys, ok?) I
think we try to meet the needs of many people, and many are not so
computer literate, simply cause they do not care that much. Or "just
think of users (customers) as very intelligent, but very busy" [somebody
else said it ..]
>>
>> We'd need auto-collapsing of quotes a la gmail, otherwise people who
>> don't trim would make some of these conversations enormous.
>>
>> ...
> Right, this is something we're seriously lacking in messages. And I
> think we can do better than GMail by giving a little bit more space
> for context in the quote collapse that gives linked references to the
> person and the message being quoted.
+1 definitely. And not just for the msg size, but for the smart
"contextual" approach intended.
Maybe just as a first step in "marking" and "auto marking" of parts of
the msg too (or tagging ..)
>
> Another thing to think about is if the rich message list should be
> collapsing headers for the messages you've already read and only
> showing the new ones. It would clean up the default view of messages
> to only showing new ones. We'd likely need to always include the
> initial thread message so we have something to span off.
Also thinking of maybe a better "gradual" closing of the msg already
read or so. I mean to let them "fade" by distance to the current msg,
the above and below still being there, the above above and next next
smaller and so on. Like a magnifier focused on current. (Hey, not really
zoom, it's just an abstraction for closing msg near and far from
current. ) Or reducing data in the header in this fashion .. Yet
another layer of contextualized comm...
ovidiu
> Jan Husak wrote:
>> Does this conversation consider a concept like storing all messages in
>> one meta / data repository and then allowing to create associations
>> (e.g. to folders, to persons, to topics etc.) as a virtual link (not a
>> copy)? This would e.g. allow much more swifter and smoother to manage
>> cross folder / conversation type associations. Thread management with
>> links to other data / information sources should be easily associated as
>> the data would be normalized.
>
> One meta/data repository will link all messages together, virtually.
> This will capture conversations spanning multiple folders and (I
> suppose) accounts. We're/I'm still in the brain-storming phase, with
> a post/link hopefully to come out in the few days. As such, input is
> greatly appreciated...
>
> Could you provide some specific example associations that you would
> want and would be likely to make?
1. say we have 2 thread tabs opened or "all" and a conversation. I would
drag a msg/rss/post to the other tab (header) to just link it and it
should appear in the conversation list as "related", not actually
threaded .. or with something in data mine called related that expands
such .. [Link would be an internal tag/id ]
Also would link/present
-web links found in msg or added (should distinguish visually ...)
-calendar stuff,
-files in os (?) other than attach
-a description/note/comment (more than a tag ..)
see more..
> Are you talking about implementing an Expert System/Rule-Based
> Programming System in Thunderbird?
>
> It's an interesting idea... right now, (it is my understanding that)
> message filters are run at discrete times, namely on receipt of the
> message and when manually executed. This could be generalized to
> conceptually always being active, and firing as soon as a state-change
> results in a rule applying, even time-based thresholds. (Assume a
> Rete-ish implementation for efficiency, although if we exempt
> time-based thresholds, simply applying message filters to any message
> that has flags/tags/etc. changed could also work.)
I would be careful with automation, as too much of it means silent
action... Some basic "auto related" msg/thread/data to the thread beyond
naturally in re fw may do (folders, topic, www links etc). I just
consider it related interesting the "educational" aspect of UI, where if
you do it manually first, for a while, you just get accustomed and
learn the feature it's there and works like that. So that when more
automation is to land, you are already familiar to it. And, oh, learning
is 2 directions, this allows dev to see how people behave on this and
how to really improve. Well, so much for gradual progress ..
And by saying learn, another one: maybe the "trainable filters" (like in
training junk) would be an option ..
>> Would that mean that this approach would dis-continue the file system
>> based email storage?
>
> I think the current idea is to de-couple the storage of the e-mails
> from the global database that stitches all the e-mails together. The
> future enhancement for e-mail storage is to make that interface
> pluggable, so that people can use Maildir or whatever their heart
> might desire.
As above. Even manual first, would be a start .. People may find out
they forgot to wish for things, they can start to hope for features etc.
[that's "creating expectations, leading people towards your idea" .. In
politics and leadership training I saw that as THE way of getting people
on one direction, sometimes for their own obvious good. Good
speakers/leader etc will make you think it was your idea. Think it
applies to planning in general. ..So much for crowd management ..]
Andrew Sutherland
The ThreadVis extension does this by walking every folder in the
account, asking each folder if has a message with the given Message-ID.
This works if you only care about a single thread at a time, but
arguably does not scale up much further than that.
Andrew
ovidiu
Bryan Clark wrote:
> A problem exists right now that it is extremely hard to create a new
> view or new aspects to a view. Fast and complex queries against mail
> are currently slow and difficult to execute.
yep
> Basic Experimental View
> =================
>
> Rich Message List and Conversation Data Mine Bar - Designed for
> processing conversations
> +--------------------------------------+
> | |
> +-----+-+-----------------+-+----------+
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> | {1} | | {2} | | {3} |
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> +-----+-+-----------------+-+----------+
>
> {1} - Accounts Listing - remains the same as it currently is
> {2} - Rich Message List - rich listing of a threaded conversation view
> {3} - Conversation Data Mine Bar - conversation and person contextual
> information
3 is clearly the new star in this concert.
I've been thinking for a while at this context data and came to an idea
derived from other ui (3d apps):
-Could it be also available in say classic layouts while hover/select a
msg and press space or other awhile and pop that data mine? In 3d apps
it became common after maya set this for accessing the menus (3d is
crazy for screen real estate..) and they where seen as a bunch of
context menus around mouse, but with some lines to connect it so that
they keep distance, group and avoid fill the screen.
Anyway, that is already mature in those apps and may be studied (can
provide links..) and the connector lines are such a beautiful metaphor
for "related" ..
>
> Conversation Tab with Rich Message List and Message View
>
> +--------------------------------------+
> | |
> | ___________ ______________ |
> |/_All__Mail_\ / Conversation \ |
> +---------------+-+--------------------+
> | | | |
> | | | |
> | | | |
> | | | |
> | | | |
> | {2} | | {4} |
> | | | |
> | | | |
> | | | |
> | | | |
> | | | |
> | | | |
> +---------------+-+--------------------+
>
> {1} (accounts) remains in _all_mail_ but is not shown in the
> conversation tab
> {2} Rich Message List - rich listing of a threaded conversation view
> {4} Message View Pane - displays the entire message at optimized width
> for reading
may need the mining data somewhere here too .. maybe as above or I'll
think of else ..
> There is some possibility to provide some more context information
> like the data mine bar in this conversation view tab. I'd love to
> discuss ideas on how this could be possible.
>
the essence of the discussion ? ..
>
> Opening a Conversation (a walk through example)
> =================
>
> From the main processing view. (ugly, yet live example [4])
> +--------------------------------------+
> | |
> +-----+-+-----------------+-+----------+
> | | | | | |
> | | |-----------------| | |
> | | | (1) | | |
> | | |-----------------| | |
> | | | | (2) | | |
> | | | +---------------| | {3} |
> | | | | | | |
> | | |-+---------------| | |
> | | | | | |
> | | |-----------------| | |
> | | | | | |
> | | | | | |
> +-----+-+-----------------+-+----------+
> (1) First message in a conversation
> (2) Second message in a conversation
> {3} Conversation data mine view
As content for 3:
a) why have replay, fw etc? is redundant with buttons and may just be
appropriate to use after really read.
so I say, first is important to focus on the correct msg when tabing
back from full read (may have already navigated there). Second, this
should be extra options for re, fw .. Have the names in conversation
under "re" with checs, not re and re all. Also for fw. Fw selected msg
(can select more than one? hmm ..) Etc
b) extra data for search, add little magnifiers aside every data (in
mineing) to search for that. search should consider not only that
criteria, but also the context of trigger, the thread, topic..
c) extra related, extract web links from pages, and add more manually
d) show all attachments in thread, great for consolidating the data
exchanged ..
e) add other relations manually, with msg, rss, files, calendar etc
f) a good place to mark/tag/ *parts* and paragraphs of a msg (and even
further link it to others ?)
!! like: -msg1: two weeks ago john said Tb is great [link1] -manually
created, like an anchor..
result of link 1 may be - msgX: john: TB is great because ....(.blah for
pages ..) or just that paragraph ...
g) add "you read this first 2 days ago, ten times now" [v] expand
dropdown with those ten times ..
want more? uh .. next time ..
> Here are some ideas for items to display in the sidebar.
>
> In general:
>
> For the current message:
>
> * Attachments (open or save)
> o links (pull out links as often message simply contain one
> or two links)
> o images
> o files
> * Actions
> o Reply, Forward, etc.
>
see above above...
>
> o
>
>
> o Archive
> o Tag
> o Move (to folder)
>
suggest/auto complete ..
>
> o
>
>
> For the conversation:
>
> * Previous Messages from this person
> * Previous Attachments from this person
>
+all attach in thread
>
>
>
> This obviously won't be right for everyone, especially initially.
> Hopefully this kind of example will allow or inspire some other people
> to dream up some really kick ass stuff.
>
(in another re) I say that gradual approach may be better to introduce
users to new possibilities. That is another thig to think of, as this
can be as intimidating as it is powerfull. Please keep in mind that
there are so many people that are very light computer users, we need
them to benefit too ... (ha, i just made it more complicated .. :) )
ovidiu
btw, great to see this starting ...
Kent James
> Hi Andrew,
>
> And I'll give the user
> an explicit button to re-index each folder, at least until Tb offers a
> better way to check a folder's status.
>
I really hate that term "re-index" if by that you mean recreating the
.msf files. As new metadata are being added to the emails, it is not
reasonable to store those in the mailstores, so the .msf files become
the primary email database. "Re-indexing" destroys all of that
information. "Purge" would be a better term. A button would only
encourage unnecessary destruction of metadata.
rkent
Joshua Cranmer
> Off-topic perhaps, but I think this is a good thing to ponder out, at
> least to a first approximation. Kent James' point about the mailnews
> workflow's lack of dogfooding in this thread is well made.
> (<68WdndP7mON9KtnV...@mozilla.org>, though I have no idea
> how one is supposed to use such a reference)
news:68WdndP7mON9KtnV...@mozilla.org is the ideal URI,
although the brokenness of mailnews's news URI handling is such that the
incorrect URI
<news://news.mozilla.org/68WdndP7mON9KtnV...@mozilla.org>
has to be used.
> Although use of IRC is
> probably rare outside of open-source development work-flows, in my
> personal experience chat-rooms do crop up in corporate software
> development as well.
By sheer luck, I have just received a message on my school's admin
mailing list which (to summarize) called for an IRC meeting because not
everyone could be in the same place at the same time. So it's not
limited to open-source development.
> So, when indexing the comments made by user A in a time interval, we could:
> * treat anyone else who posted a message/seemed alive during that
> interval as a 'cc'
> * treat anyone else who A directed a message to as a 'to'
> * (ignore anyone with 'bot' in their name)
> * treat the chat channel as the newsgroup name equivalent
Sounds reasonable to me.
> I'm not sure what to do about (gmail-style) 'conversation' and reply
> notions. It seems like they should probably be omitted; having reply-to
> remain acyclic seems desirable, and treating a channel as a newsgroup
> would seem to capture the 'conversation' notion sufficiently well.
>
> Thoughts?
This is all still very amorphous, and I don't think anybody has gotten
around to making any even prototypes yet. In the end, I think my
opinions and everybody else's depend on how the final product works, so
until we have working models it's hard to say.
Joshua Cranmer
> And in case you somehow missed jwz's seminal work on message threading:
> http://www.jwz.org/doc/threading.html
I believe this got all the way to draft RFC level. So this algorithm is
the de-facto standard.
ovidiu
Bryan Clark wrote
> Rich Message List and Conversation Data Mine Bar - Designed for
processing conversations
> +--------------------------------------+
> | |
> +-----+-+-----------------+-+----------+
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> | {1} | | {2} | | {3} |
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> | | | | | |
> +-----+-+-----------------+-+----------+
If this (or derivates) is to become a usage standard *it should be
available for other tipes of "data grouping" than threads*, like
folders, searches, advanced searches, views maybe etc.
I know threads are a nice improvement, as the views or searches today
do not allow immediate extraction of a thread in a separate view, but a
layout change with contextual data would be a benefit for all folders
for example and I see it as a necessity to *not be implemented only on
conversationnal regard*.
[And extensions aiming data management (like seek) could then find a way
to integrate in a natural way.]
Let's see:
1) folders
Data miner should present some data on the folder, maybe as a pop or
uncollapse, filters used etc
Could have dbclick on a folder and open a tab with similar to a
conversation?
2) quick searches should present data miner with search elements to/from
etc and allow small edit like add 2 criteria and a tag (by check)
3) advanced search/saved searches/views should present criteria and
allow (almost) dinamic change of it, than say save/save as folder/save
as view etc
4) contacts may just be another tab.. uh, just imagine the data miner
!... (that's for another thread)
5) filters as a tab/widget, action history etc ...
> +---------------------------------------------+
> | [[]] Bryan Rich Message List 1 hour ago |
> | the first couple sentences of this |
> | message are placed inline in the item |
> | 2 @ mozilla, thunderbird, important |
> +---------------------------------------------+
THis should be customizable, but not ony in prefs,
-somthing like a >>more or a list like in sorters
-able to drag/move/sort them around (? and all the view will update ?.. hmm)
> Conversation Data Miner
> =================
a) This should work with widgets, so that is customizable, in add/remove
widgets and in sorting them.
extensions will then add widgets or add items to a widget .. and will
not mess this, but use it.
b) If there is "too much data" concern for "miner sidebar", just make it
with:
-expand/colapse category widgets like so many apps do with panels and
attributes in sidebars
-add scrollbar to it so that data is still relaxed and of normal size
-add "relations map" to pop from it or "see more" or as maximize pane,
to show all widgets+msg spread on screen in a schema (see ore down ..)
[this may just be about inviting people to future visualisations and get
them accustomed .. and play with it!]
Extra data for "data miner" generally, not only related to above (maybe
said some before in anothre re..) in addition to yours:
-For the current message:
* Attachments (open or save)
o !Better links
! Do confront them with index, a web link to a blog post
may understand that post is also in tb and present "see here/see web"
! Do detect potential links (see especially calendar ..)
o All Attachments in Thread (open or save)[maybe
expandable/colaps/view more>> kind of ..]
o Attachments status (Already saved or viewed)
[maybe maybe as simple as "visited, active," color etc
in web links]
[may just be a link to the "action history" feature,
tiny icon aside like little magnifier is for find]
o Att history [access to action history]
o Notes -comments? [may be notes attached, or a link to a
notes feature, if notes will be like drafts or msg ..]
* Actions
o !Expanded/advanced Re, Fw, not to be redundant with
buttons, but detail them [present people in thread for selection etc]
o Actions history [for non linear undo also?]
* Structural (bad name..)
o !Folder/account+folder (where is this msg) [on click may do
stuff ..account and subfolder struct may just expand on hover]
o !Saved searches (in witch this one falls) [like above]
o Filters applied (how did it get here and tagged?) [auto
filters, manual run, etc]
o Duplicates/Similar (people may have duplicates in different
folders or in archives) [where are those ..]
* Reference
o !Links to other msg, rss, news, etc (see above in
links!)[detected from body or not so ..]
o Actions history [for non linear undo also?]
o Notes [for non linear undo also?]
* Calendar (may fall under above ..)
o Links to events/tasks (create from msg, create manual, link
to existing..)
o Alarms (create/edit/view) or indicators [pulled from
cal,created from this, created for this as a reminder ]
o !!!Detect time elements in txt and present for use
("tomorrow", "meet saturday at 10", "a month ago",etc)
o !!!Detect to do elements in txt ... ("deadline", "we have
to meet", "send me the..",etc)
For the conversation:
* Some of the abovemay just fall on thread level
o All Attachments in Thread
o Calendar elements *on all msg*
* Thread specific action
o Similar topic
o Consolidate dupes(in terms of duplicates)[may pop a map of
locations]
o Consolidate location(in terms of archive on same loc)[may
pop map of locations, tags, searches etc]
o Calendar elements *on all msg*
Others (widgets?)
*Map of conversation -this would be a pop with a schematic view of
relations/locations/tags/contacts/dates/events/actions etc
[that would be a spectacular visualisation for exploring a complicated
thread or a big relation issue along with finding/browsing something]
*Statistics for this thread and related etc
> Concerns
> ======
How to detect which of all of this is to be default/pref/extensions/ and
how to see what people will actually use?
I think only "hands on" testing can tell, discussions are just
assumtions... Add a silent hidden statistics for the use of that and ask
people (testers) to mail ,some things from time to time ..
ovidiu
I'll be back if some idea on data miner along with 2pane conversation
view ..
ovidiu
ovidiu wrote:
> Bryan Clark wrote
+---------------------------------------------+
| [[]] Bryan Rich Message List 1 hour ago |
| the first couple sentences of this |<-- text from
| message are placed inline in the item |<-- body
| 2 @ mozilla, thunderbird, important |
+---------------------------------------------+
about the "first 2 lines", could it be smarter than that?
I was thinking about the bottom reply policy on moz ng (which makes
sense..) and this seams to be useless in case of first 2 lines are quote
or "Bryan wrote .." . There may be other cases, of course ..
Could it skip quotes and capture next? As a first step towards smarter ..
Ron K.
And the other complicator that fits this comment is the use of
interspersed comment replies, with or without some bottom reply content.
Mark Banner
> Just remembered one thing:
>
>
> ovidiu wrote:
>> Bryan Clark wrote
>
> +---------------------------------------------+
> | [[]] Bryan Rich Message List 1 hour ago |
> | the first couple sentences of this |<-- text from
> | message are placed inline in the item |<-- body
> | 2 @ mozilla, thunderbird, important |
> +---------------------------------------------+
>
> about the "first 2 lines", could it be smarter than that?
I think we will need to be smarter than that, and possibly on an email
from/type basis. i.e. if I'm processing bugzilla emails, I'd probably
want a couple of lines near the top if its changing a component or a new
bug, but I'd also want the first couple of lines by the comment.
Certainly "Do not reply to this email. You can add comments to this bug
at..." wouldn't be very useful.
Standard8
ovidiu
discussion (OT here) as this relates to various languages and here the
pandora's box ... (sometimes I even used eng and ro in same threads or
even same mail ..) Aside from that, there are few standard examples
(bugzilla, ok), but I recieve incredibly diverse formatted mail. I'm
thinking this feature alone won't do, it has to relate to other info in
app, be it try to guess habits from persons, from thread, from other, be
it whatch you and your actions against those msg , etc
Now, there are probably some studies in this world about this, I just
assume things ...
ps: till then, in my biff captured text sometimes it gets : <div> blah
blah .. / etc as first lines .. ha.
Gervase Markham
> The message preview is intended to allow you to read the first couple of
> sentences of the message so processing decisions can be made.
You say that, but I just don't use it that way, and neither does anyone
else I know. Including all the Outlook users, who get terribly surprised
when they've been happily reading all their mail in the "Preview Pane"
for months, and then some embedded or active content comes along which
requires the message to be opened in a new window, and they don't know
what to do.
It may be called a "Preview Pane", but that's not what people use it
for. I only ever open messages in new windows when I want to compare two
of them, or "bookmark" them for a few seconds, which is very rarely.
Gerv
JoeS
My usage is exactly opposite. In fact, most times I have the preview pane dragged down and invisible.
This is because active content embeds (and javascript execution, if you allow it) do happen in the preview.
As a result, you could have a plugin like Crescendo running in preview, which runs again in the "fully open
window". So for me it's delete it, or fully open it.
--
JoeS
ovidiu
My use is as gerv's, no preview but view, no open in other window. I do
vertical 3 pane cause I have a laptop 17' wide 1680x1050, while on a
small screen I would probably use other layout or even joe's way. Only
after this screen size issue, one thinks of preferences ...
Bryan Clark
On a conversation level things are a little different. Once you've opened a message in a tab you're viewing the entire conversation list on the left side and the message preview pane (which shows the whole message) on the right. Essentially at that point you're looking at thunderbird in the vertical view with the account / folders pane closed and only one conversation showing in the message list.
I don't ever open single messages in new windows either, perhaps only in the same way you describe. But often I do find myself reading a number of messages in a thread and then getting sidetracked by other things. Right now Thunderbird doesn't retain any of the context needed to help me getting back to reading the message I was just reading. With a conversation opened in a tab I could be reading the Experimental Message View thread and then switch to read important email about something else; when I'm done with the important email the conversation thread would have kept my exact position in reading the thread. Sometimes people manage that kind of context purely with marking read/undread but that's a teadiuos task to perform when the application could just keep your state as it was instead of losing it.
Your point of confusing exsiting Outlook style users is well taken. I don't think you're intending to say that Outlook solved the email problem with the "Preivew Pane", but that changing peoples mode of working takes a lot of well planned execution and not just a fancy new shell. Confusing people would be one of the worst things we could do but hopefully we (like gmail in their conversation view) can create an improvement that is as understandable as regular email yet more powerful.
Cheers,
~ Bryan
![alta88[nntp]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUA6LqwHL3TKsLebE5-SwXQqtAZJOkobIl_A9x06nUxOiTLww=s40-c)
alta88[nntp]
---On 2008.Jun.06 09:38 AM, Bryan Clark wrote:
>
> On a conversation level things are a little different. Once you've
> opened a message in a tab you're viewing the entire conversation list
> on the left side and the message preview pane (which shows the whole
> message) on the right. Essentially at that point you're looking at
> thunderbird in the vertical view with the account / folders pane
> closed and only one conversation showing in the message list.
i would never open another window, nor would i ever open a message in a
'window' tab, and i always have the message pane open. for me, it would
be a jarring loss of context (as i've said elsewhere ;) to read a
message without both folderpane and threadpane visible. while other
ergonomics should certainly be added, the existing needs to be maintained.
the usage case of keeping message pane closed due to active content is
interesting. if i receive an email from an unknown (not marked always
allow in a/b), i like the Allow Remote Images notifier, which i can then
turn on. the same would be nice for javascript:
https://bugzilla.mozilla.org/show_bug.cgi?id=373481.
JoeS
> Gervase Markham wrote:
>> Bryan W Clark wrote:
>>
> I think we're mixing up terms. The above "message preview" is the 2
> sentence clip of the message written by the author (i.e. stripped of
> quoted material) and this is shown in the new message list I was talking
> about. The main purpose of that preview is to allow you to understand
> the nature of the conversation and decide if you want to read it or not.
I often wondered if the 2 sentence was actually javascript.(If it was allowed by pref) if it actually would be executed
in the tooltip clip. I'll experiment with that.
But beyond the content text preview, I think it would be helpful if it gave an indication of content type also.
Maybe a very small icon for javascript, another for remote content of *any* kind.
There are cases right now that actual content could be completely hidden. One such case would be if you have plugins
disabled and content such as:
> <embed src="http://home.myisp.com/mymusicj/Midis/AxelF.mid"
> autostart="true" loop="false" save="True" height="30" width="30">
In the above example, unless you view source, you would never know that it is there.
No attachment indicator, in fact nothing to tell the user that it is there.
I also agree with alta88 below that a javascript popup like the remote image popup would be useful.
--
JoeS
Gervase Markham
> I think we're mixing up terms. The above "message preview" is the 2
> sentence clip of the message written by the author (i.e. stripped of
> quoted material) and this is shown in the new message list I was talking
> about. The main purpose of that preview is to allow you to understand
> the nature of the conversation and decide if you want to read it or not.
We are a bit mixed up. I was assuming the scenario where you restored
the message-viewing window to the original layout.
All I can say is that this new layout, which required me to open
messages in new tabs to read the entirety of them, would be an absolute
productivity killer for me. And I just don't see the need to make people
make that effort.
Gerv
ovidiu
> Bryan Clark wrote:
>
>> The main purpose of that preview is to allow you to understand
>> the nature of the conversation and decide if you want to read it or not.
>>
>
> messages in new tabs to read the entirety of them, would be an absolute
> productivity killer for me. And I just don't see the need to make people
> make that effort.
>
1. the expanded msg info in tree is an advantage in any view (to help
decisions ..)
see Vertical view & inline .. in this group
http://groups.google.com/groups?selm=74e1648b-11af-4075-acd5-71ed810cac09%40p25g2000hsf.googlegroups.com
https://bugzilla.mozilla.org/show_bug.cgi?id=213945
[1a. the content of such body preview ..
https://bugzilla.mozilla.org/show_bug.cgi?id=307070 (part of the above..) ]
2.I admit the whole view would do for digg of msg threads or related and
maybe not for quick read and file. That will be a richer alternative for
my current search or quick search procedures. If that stands for more
than threads. For searches and views and other virtual grouping would be
great. Search terms in right pane, other relations there, drag some msg
there ..
Hmm, I think this attacks tabs use, views, rich context info, other ..
several features in one. Maybe that's why seams "not there yet" ..
Bryan Clark
brought into the classic view. If the classic view took on an
optimized message list view like what we're discussing then it could
give up some of the horizontal space for a section that does the data
mining on each selected message. So the below ascii in sections from
top left is: folder/account pane, (new) message list, (new) data mine,
message preview pane.
+---------------+
| | | |
| | | |
| +------+----+
| | |
| | |
+---+-----------+
This would at least be a way to try a gradual technology transfer from
where we are going all out in one direction.
> Anyway, that is already mature in those apps and may be studied (can
> provide links..) and the connector lines are such a beautiful metaphor
> for "related" ..
Good point, I'll try to collect some screenshots from other applications
doing similar things here.
>>
>> Conversation Tab with Rich Message List and Message View
>>
>> +--------------------------------------+
>> | |
>> | ___________ ______________ |
>> |/_All__Mail_\ / Conversation \ |
>> +---------------+-+--------------------+
>> | | | |
>> | | | |
>> | | | |
>> | | | |
>> | | | |
>> | {2} | | {4} |
>> | | | |
>> | | | |
>> | | | |
>> | | | |
>> | | | |
>> | | | |
>> +---------------+-+--------------------+
>>
>> {1} (accounts) remains in _all_mail_ but is not shown in the
>> conversation tab
>> {2} Rich Message List - rich listing of a threaded conversation view
>> {4} Message View Pane - displays the entire message at optimized
>> width for reading
> may need the mining data somewhere here too .. maybe as above or I'll
> think of else ..
Agreed, I wondered if it would make sense to create a smaller toolbar
like level under the tabs that contains an expandable data mine type
view. Something that would give you information on what you're looking
at and how to dig deeper. Very similar to the SEEK style faceted
browsing options.
Yes, they'd probably be redundant to the toolbar buttons and it might
not make sense to include them right away. But in general I think
action buttons related to the message, like reply, fwd and other should
be moved directly on to the message. The current toolbar location means
a lot of sensitive/insensitive changing of the buttons when they aren't
applicable to what's in focus. Not that I want to change the toolbar
right now, but that's a pretty bad interface design concept to keep.
> b) extra data for search, add little magnifiers aside every data (in
> mineing) to search for that. search should consider not only that
> criteria, but also the context of trigger, the thread, topic..
Exactly, lots of ways to explore and dig deeper at each topic listed.
> c) extra related, extract web links from pages, and add more manually
> d) show all attachments in thread, great for consolidating the data
> exchanged ..
> e) add other relations manually, with msg, rss, files, calendar etc
> f) a good place to mark/tag/ *parts* and paragraphs of a msg (and even
> further link it to others ?)
> !! like: -msg1: two weeks ago john said Tb is great [link1] -manually
> created, like an anchor..
> result of link 1 may be - msgX: john: TB is great because ....(.blah
> for pages ..) or just that paragraph ...
> g) add "you read this first 2 days ago, ten times now" [v] expand
> dropdown with those ten times ..
>
> want more? uh .. next time ..
Lots of really good ideas. The general theme I see is offering many
ways to browse and spring board off a single message to other content
that is connected and important.
Right, a gradual approach may be that we take the search / browse system
that is developed in this view and move it over to the other views for
their search results. That might include data mining toolbars and other
bits thought up here.
>
> btw, great to see this starting ...
I'm really glad to have all this discussion happening, wish I wasn't
packing up my life in boxes as it goes on. :)
alta88[nntp]
---On 2008.Jun.09 08:30 AM, Bryan Clark wrote:
I also thought that a shortened version of the data mine view could be brought into the classic view. If the classic view took on an optimized message list view like what we're discussing then it could give up some of the horizontal space for a section that does the data mining on each selected message. So the below ascii in sections from top left is: folder/account pane, (new) message list, (new) data mine, message preview pane.
+-----------------+
| | | |
| | | |
| +------+----+
| | |
| | |
+---+------------+
This would at least be a way to try a gradual technology transfer from where we are going all out in one direction.
If something like Lightning Today Pane comes along, it's added to the Pane Palette, a new segment is created by dropping either a vertical or horizontal splitter onto an existing pane, and it's dropped where desired. The architecture would be very similar to that of toolbar customize.
ovidiu
>
>
>
> ---On 2008.Jun.09 08:30 AM, Bryan Clark wrote:
>>>
>> I also thought that a shortened version of the data mine view could
>> be brought into the classic view. If the classic view took on an
>> optimized message list view like what we're discussing then it could
>> give up some of the horizontal space for a section that does the data
>> mining on each selected message. So the below ascii in sections
>> from top left is: folder/account pane, (new) message list, (new) data
>> mine, message preview pane.
>>
>> +-----------------+
>> | | | |
>> | | | |
>> | +------+----+
>> | | |
>> | | |
>> +---+------------+
>>
>> This would at least be a way to try a gradual technology transfer
>> from where we are going all out in one direction.
> This comes back to a discussion in this bug
> Window dialog (like customize toolbar) in which a user could
> construct, via dnd, their layout. Say those 4 panes are icons on a
> Customize dialog, along with a vertical and horizontal splitter.
> Splitters are dragged to segment the screen, panes are dropped into
> the desired segment.
say that by "customize" a dragging header appears ..
>
> If something like Lightning Today Pane comes along, it's added to the
> Pane Palette, a new segment is created by dropping either a vertical
> or horizontal splitter onto an existing pane, and it's dropped where
> desired. The architecture would be very similar to that of toolbar
> customize.
>
hover, or as a pref for these. On the default ones, extensions may
decide for them ..
ovidiu
> ovidiu wrote:
>> I've been thinking for a while at this context data and came to an
>> idea derived from other ui (3d apps):
>> -Could it be also available in say classic layouts while hover/select
>> a msg and press space or other awhile and pop that data mine? In 3d
>> apps it became common after maya set this for accessing the menus (3d
>> is crazy for screen real estate..) and they where seen as a bunch of
>> context menus around mouse, but with some lines to connect it so that
>> they keep distance, group and avoid fill the screen.
>>
> I also thought that a shortened version of the data mine view could be
> brought into the classic view. If the classic view took on an
> optimized message list view like what we're discussing then it could
> give up some of the horizontal space for a section that does the data
> mining on each selected message. So the below ascii in sections from
> top left is: folder/account pane, (new) message list, (new) data mine,
> message preview pane.
>
>
pref for "use extended Rclick" ..
>> Anyway, that is already mature in those apps and may be studied (can
>> provide links..) and the connector lines are such a beautiful
>> metaphor for "related" ..
> Good point, I'll try to collect some screenshots from other
> applications doing similar things here.
with some links to tut on net showing action ..
>> may need the mining data somewhere here too .. maybe as above or I'll
>> think of else ..
> Agreed, I wondered if it would make sense to create a smaller toolbar
> like level under the tabs that contains an expandable data mine type
> view. Something that would give you information on what you're
> looking at and how to dig deeper. Very similar to the SEEK style
> faceted browsing options.
hover .. Also, do consider all the classic views. I use vertical 3 pane
and is a completely different w/h issue on screen to spare .. On
vertical would do a seek/above/header style, on classic a sidebar is
more appropriate ..
Is it a header rclick or [v] or "more" button such a hard thing? i say
header cause there seams to be the info now (threadVis does header too)
and .. hmm
> Yes, they'd probably be redundant to the toolbar buttons and it might
> not make sense to include them right away. But in general I think
> action buttons related to the message, like reply, fwd and other
> should be moved directly on to the message. The current toolbar
> location means a lot of sensitive/insensitive changing of the buttons
> when they aren't applicable to what's in focus. Not that I want to
> change the toolbar right now, but that's a pretty bad interface design
> concept to keep.
aha. Would this land in headers (or alike) if to use the classic view?
>> b) extra data for search, add little magnifiers aside every data (in
>> mineing) to search for that. search should consider not only that
>> criteria, but also the context of trigger, the thread, topic..
> Exactly, lots of ways to explore and dig deeper at each topic listed.
Bring search to humans, visual, drag, hide criteria and such... and more
arbitrary connections/grouping ..
> Lots of really good ideas. The general theme I see is offering many
> ways to browse and spring board off a single message to other content
> that is connected and important.
As in a widget board would do, so that extensions can add more and user
can customize, on/off, order. expand collapse etc
It's in another re of me around here, I'll try to get similar panes from
other apps in captures ..
>> (in another re) I say that gradual approach may be better to
>> introduce users to new possibilities. That is another thig to think
>> of, as this can be as intimidating as it is powerfull. Please keep in
>> mind that there are so many people that are very light computer
>> users, we need them to benefit too ... (ha, i just made it more
>> complicated .. :) )
>>
> Right, a gradual approach may be that we take the search / browse
> system that is developed in this view and move it over to the other
> views for their search results. That might include data mining
> toolbars and other bits thought up here.
And provide indicators, not only in intuitive Ui, but in support/feature
highlight/tips and tricks etc
[That's another topic that you'll hear from me another time around ..
(support, user docs ..)]
>>
>> btw, great to see this starting ...
> I'm really glad to have all this discussion happening, wish I wasn't
> packing up my life in boxes as it goes on. :)
? ... or mboxes? :) don't forget the mab's ..
Ron K.
>
>
>
> ---On 2008.Jun.09 08:30 AM, Bryan Clark wrote:
>>>
>> I also thought that a shortened version of the data mine view could
>> be brought into the classic view. If the classic view took on an
>> optimized message list view like what we're discussing then it could
>> give up some of the horizontal space for a section that does the data
>> mining on each selected message. So the below ascii in sections
>> from top left is: folder/account pane, (new) message list, (new) data
>> mine, message preview pane.
>>
>> +-----------------+
>> | | | |
>> | | | |
>> | +------+----+
>> | | |
>> | | |
>> +---+------------+
>>
>> This would at least be a way to try a gradual technology transfer
>> from where we are going all out in one direction.
> This comes back to a discussion in this bug
> Window dialog (like customize toolbar) in which a user could
> construct, via dnd, their layout. Say those 4 panes are icons on a
> Customize dialog, along with a vertical and horizontal splitter.
> Splitters are dragged to segment the screen, panes are dropped into
> the desired segment.
>
> If something like Lightning Today Pane comes along, it's added to the
> Pane Palette, a new segment is created by dropping either a vertical
> or horizontal splitter onto an existing pane, and it's dropped where
> desired. The architecture would be very similar to that of toolbar
> customize.
>
I could go for this. I could see a View Pane pallet with a preview
where the layout could be mocked up before committing it with an "Apply"
button. At least for the Windows platform the "Apply" button would be
consistent with the OS UI. I would go farther and include an ability
for extensions to add there view pane to the pallet. Extensions like
Address Sidebar and Same Place IM come to mind.
alta88[nntp]
What Seek has done is even more elegant, yes. Customize type mechanism
is useful for add/remove panes, or clearing the slate and redoing.
>>
>> If something like Lightning Today Pane comes along, it's added to the
>> Pane Palette, a new segment is created by dropping either a vertical
>> or horizontal splitter onto an existing pane, and it's dropped where
>> desired. The architecture would be very similar to that of toolbar
>> customize.
>>
> We have to just think if those would be dragged/resize, expanded on
> hover, or as a pref for these. On the default ones, extensions may
> decide for them ..
Since splitters are slideable it shouldn't be much of an issue, cut a
pane (ie its containing box) in half and let the user move it, just need
to persist width/height. The fewer things extensions decide the better,
the most an extension should do is add a well defined 'pane' widget to a
Palette eg. and be done. Even show/hide toggle could be built in.
Right now extra panes are DOM hacks, not the way to build a proper product.
gNeandr
doing the window arrangements?? It seems much more flexible than MOZ is
doing ... would that concept require a total redesign? For me that
concept has the most flexibility I have worked with ... outstanding!
ovidiu
> ovidiu wrote:
>> idea derived from other ui (3d apps):
>> -Could it be also available in say classic layouts while hover/select
>> a msg and press space or other awhile and pop that data mine? In 3d
>> apps it became common after maya set this for accessing the menus
>> Anyway, that is already mature in those apps and may be studied (can
>> provide links..) and the connector lines are such a beautiful
>> metaphor for "related" ..
> Good point, I'll try to collect some screenshots from other
> applications doing similar things here.
some links with comments.
Note that 3d apps have: huge amount of menu commands, big need for
screen, usually kinda advanced users, very visual approach etc. This
means that the reasons and results are different here. I think that with
some imagination things may go beyond the immediate similarities and I
wanna stress on the "contextual" aspect of it.
This first appeared in Maya 3d along with other breakthrough UI changes.
On press and hold a bit space key all top menus appear on screen around
the mouse position as in (transparency of the menus can be set %)
http://mauricioferrazza.com/maya_images/White/Hot_box.jpg
http://www.evermotion.org/tutorials/paintfx/grass/1.jpg
as well as contextually (related to selection and current functions etc)
as in
http://img162.imageshack.us/img162/8485/polygonquickmenuobjectmrz1.jpg
http://img504.imageshack.us/img504/2810/polygonquickmenunothingrx6.jpg
http://www.webreference.com/3d/column16/marking_menu.jpg
the idea being to free some screen space and have more convenient
contextual menu
Note that this is not about spreading the context menu around, but
having more context menus and more strutured ones
In our case this may go for less functions and more for
related/structured ideas. Why not something like
http://www.yadayada.org.uk/wordpress/wp-content/project/ravenshield.jpg
or instead of space and mouse position to get such from a small button
or "more" or "related" in the thread
After this maya menus, major 3d packs eventually got similar enhancements:
-3dMax, less impressive as 3d but aybe more interesting for us, The
usual context Rclick but with another menu on top of it.
the latest MS office has such menu that even appears on a hover and
hanging for a while. (hangover?)
-Lightwave 3d has (alt key) all menus on L M and R mouse etc, not much ,
ther may just had splitted the context menu in a more cute way (modo 3d) etc
~
Another aspect really common now, not only in 3d, but all apps that need
a lot of properties, attributes etc is the Right Pane dock or whatever
it is called:
-Adobe, Corel, Inkscape even have those in a scalable, docking, movable
etc way
-3d and cad do get those properties in the same manner
Idea being about :
1. having a datamine pane that hosts widgets rather than rigid elements
(seek has them..). This will allow:
-customization of what is in and what is not, dragging, sorting those
around etc
-extensions may add specific widgets or visualizations
2. having collapsible or docking datamine or even being able to drag it
around and place it on other sides top/bottom/left
-havin it pop only when needed
-having it docked on the side along with lightning today pane for example
Continuing this comparison to graphic apps dock and panels I would give
an example to show another aspect of it:
*In Corel Draw for example, you get some stuff that I abstract for the
TB data like this:
-On screen there are some elements -this is "Msg View pane" (or compose,
but not for now..)
-On the dock right side you can get Object Manager or Layers -this could
go for "Thread pane"
- or Object properties or other that give details or specific actions on
context -!this goes for Data Mine
remarkably, this means I would normally get the thread and data mine to
compete for the same space or even to replace one another from time to time.
I was just wondering where is the correct place for such data miner.
Today we find some of that data in the header (also used by threadvis
and alike) while in your proposals it seams to get it's own space/pane.
Does this mean the header data will completely fall in the miner? would
the miner stand for a better than today's expanded header? and so on
~
Anyway, the ideas about the on screen, contextual menu or pane I say is
interesting cause of the tendencies to get all things in one place, on
one screen, a user may have. I think you have to have a serious reason
to get me in another tab or view or pane or whatever, or otherwise I'll
just not use that.
Somebody (I think Dan Ablan?) was comparing opening a window or
switching the view with going to another room. Do I need to take the
thread to another room or can have several conversations take place in
the same room and easily switch them or even, eventually combine some of
the groups? or is it just that people are getting more to the behavior
of having less walls and only virtually splitting space? (like in those
lofts etc)
regardless of the drinks and fun, the room vs activities approach I find
very good. And maybe TB should not immediately propose you to "get a
room" just because you had a conversation :)
cheers
Bryan W Clark
>> Right, this is something we're seriously lacking in messages. And I
>> think we can do better than GMail by giving a little bit more space
>> for context in the quote collapse that gives linked references to the
>> person and the message being quoted.
> +1 definitely. And not just for the msg size, but for the smart
> "contextual" approach intended.
> Maybe just as a first step in "marking" and "auto marking" of parts of
> the msg too (or tagging ..)
>>
>> Another thing to think about is if the rich message list should be
>> collapsing headers for the messages you've already read and only
>> showing the new ones. It would clean up the default view of messages
>> to only showing new ones. We'd likely need to always include the
>> initial thread message so we have something to span off.
> Also thinking of maybe a better "gradual" closing of the msg already
> read or so. I mean to let them "fade" by distance to the current msg,
> the above and below still being there, the above above and next next
> smaller and so on. Like a magnifier focused on current. (Hey, not
> really zoom, it's just an abstraction for closing msg near and far
> from current. ) Or reducing data in the header in this fashion .. Yet
> another layer of contextualized comm...
Just wanted to pull these two things out as they created some recent
conversations about message sizing relative to "knowing the sender". At
least as part of an experiment it would be interesting to see if we
could some how make messages from unknown senders visually distinct from
messages from known senders.
The parallel context here is with postal mail. When you receive a
letter in the (postal) mail written from a friend you can instantly
recognize it's nature as "not a letter of a commercial/business
nature". This recognition of a friends letter is purely based on visual
indicators like hand written print or a known return address. And this
recognition allows you to prioritize those messages instantly.
It would likely be difficult to get this kind of work done "right",
however I think it's certainly worth thinking about how parameters are
determined and trying the system at least as an extension.
Cheers,
~ Bryan
Ron K.
> ovidiu wrote:
>>>
>>> Another thing to think about is if the rich message list should be
>>> collapsing headers for the messages you've already read and only
>>> showing the new ones. It would clean up the default view of
>>> messages to only showing new ones. We'd likely need to always
>>> include the initial thread message so we have something to span off.
>> Also thinking of maybe a better "gradual" closing of the msg already
>> read or so. I mean to let them "fade" by distance to the current msg,
>> the above and below still being there, the above above and next next
>> smaller and so on. Like a magnifier focused on current. (Hey, not
>> really zoom, it's just an abstraction for closing msg near and far
>> from current. ) Or reducing data in the header in this fashion ..
>> Yet another layer of contextualized comm...
> Just wanted to pull these two things out as they created some recent
> conversations about message sizing relative to "knowing the sender".
> At least as part of an experiment it would be interesting to see if we
> could some how make messages from unknown senders visually distinct
> from messages from known senders.
With the power of CSS, color is one method to classify Unknowns. This
could be a change of background so text color according to New vs Read
is unaffected, nor would it alter Label or Tag text coloring. Another
CSS approach would be Font family, size, style or decoration changes.
Since we do have code to use addressbook display names, that could be
leveraged in this new way.
> The parallel context here is with postal mail. When you receive a
> letter in the (postal) mail written from a friend you can instantly
> recognize it's nature as "not a letter of a commercial/business
> nature". This recognition of a friends letter is purely based on
> visual indicators like hand written print or a known return address.
> And this recognition allows you to prioritize those messages instantly.
>
> It would likely be difficult to get this kind of work done "right",
> however I think it's certainly worth thinking about how parameters are
> determined and trying the system at least as an extension.
>
> Cheers,
> ~ Bryan
The idea I outlined could be put into the default theme which opens the
door to User tweaks plus Themers could adapt the scheme to compliment
there designs. There is one UI tweak that I was going to suggest to
support Font swapping. However the Fantasy font style has been dropped
from the prefs defaults, leaving only cursive, monospace, sans-serif,
and serif. I was going to suggest Fantasy being added to the
Options/Preferences dialog so a User could use it as a distinctive font
face. Since it would be a personally assigned font, this could resolve
L10N issues, letting the User pick from their collection of installed fonts.