<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">First off, Andrew, thanks a ton for
start this endeavor!<br>
<br>
I was hoping somebody would do this, and I was hoping it would be
you. Nobody else can better design a desktop email app than you.<br>
<br>
If you have mockups or even screenshots, I think that would help a
lot to understand what you envision.<br>
<br>
I like your ideas from what I understand. The "river of messages"
reminds me of Myk's prototype that he demoed I think in 2008. I
think that's a good idea for incoming mail, esp. when it's also
classified into different "rivers", as you say and as Myk had.<br>
<br>
A few other ideas / viewpoints:<br>
<br>
Incoming mail is one important part. The body of existing message
is important as well, though. I can't find the right message
without proper sorting (and I can see that other people cannot
find old mail at all, so I believe my system is better than
average).<br>
<br>
Filtering/Sorting:<br>
I generally file message based on projects, e.g. Thunderbird is
one folder, and my day job project another, and each of my best
friends has one folder. Other people I have less contact with go
into larger groups, based on where I know them from. Furthermore,
if one source generates a lot of mail, I create a separate folder
for that, e.g. bugzilla at Mozilla, or trac at work, or each
mailing list separate.<br>
<br>
With Thunderbird, all this is very tedious manual work. I can make
filters for a lot of it, but it takes time to make filters and
arrange the order, so I still have to manually sort a lot.<br>
<br>
But with the above description, it would be easy to come up with
automatic heuristics that satisfy the above rules.<br>
<ul>
<li>The heuristic notices that I get a lot of mail from
<a class="moz-txt-link-rfc2396E" href="mailto:bugzilla-daemon@mozilla.org">"bugzilla-daemon@mozilla.org"</a>, so it makes an approriately
named folder for it. Ditto with friends.</li>
<li>It can find groups of people by seeing who is To/CC in the
email at the same time and often. These get grouped into a
folder, too. That takes care of a lot of projects, and of
groups of friends as well.</li>
<li>For work mail, it could notice that a lot of mail comes from
@foobar.com, so it makes a folder "Foobar". Could be combined
with the previous rule.</li>
<li>If I move emails manually (e.g. via drag&drop) into a
folder, and they all have a common criteria (e.g. from, or
parts of the summary), make a rule.</li>
</ul>
<p><br>
As least for my mail processing, that would help so much, it
would be a dramatic relief, and take a lot of the pain out of
email for me. It would help a lot with finding mail, without
having to resort to exact keywords. I don't think any other
email client does that yet, in this sophistication, so it's time
that somebody does.<br>
</p>
<br>
<br>
P.S. (I think tb-planning is the right place for discussion. If
this isn't planning, then I don't know what is.)<br>
<br>
<br>
Andrew Sutherland wrote, On 26.10.2013 23:41:<br>
</div>
<blockquote cite="mid:526C36FF.70405@asutherland.org" type="cite">On
10/26/2013 07:14 AM, Tanstaafl wrote:
<br>
<blockquote type="cite">I'm curious if you have written anything
up on what you are planning? UI mockups, or even just musings or
ramblings would be perfectly fine.
<br>
</blockquote>
<br>
Nothing written up, but I'll give it a whirl here. My general
first stage plan is to create a minimal implementation that
surfaces the existing Gaia E-mail app functionality in a desktop
UI that can help me do faster morning mail triage. I do plan to
blog about notable progress show-and-tell style and am happy to
drop updates in here as well.
<br>
<br>
<br>
Implementation-wise, I want to use Mozilla's web components UI
library, Brick (<a class="moz-txt-link-freetext" href="https://github.com/mozilla/brick/">https://github.com/mozilla/brick/</a>), and otherwise
build things using the existing web components polyfill. Before
Brick I was interested in using Polymer
(<a class="moz-txt-link-freetext" href="http://www.polymer-project.org/">http://www.polymer-project.org/</a>) and particularly in its Model
Driven View mechanism (non standards track). MDV seems like it
has now been split into a lower level DOM primitive
(<a class="moz-txt-link-freetext" href="http://www.polymer-project.org/platform/node_bind.html">http://www.polymer-project.org/platform/node_bind.html</a>) and a
higher level templating system that builds on it
(<a class="moz-txt-link-freetext" href="http://www.polymer-project.org/platform/template.html">http://www.polymer-project.org/platform/template.html</a>). Either
way, the churn is high enough that I'll probably just go with
whatever idiom Brick is using for data binding in its example.
<br>
<br>
<br>
UI-wise, my tentative message list plan is to do a
latency-optimized "river of mail" UI that is probably familiar to
anyone who used Google Reader. The messages will be displayed one
after the next in their entirety, eventually with some smart quote
collapsing for those cases where it seems likely the author of the
message is not a compulsive quote gardener. These will be
pre-loaded so that "j"/"k" can rapidly move through the messages.
<br>
<br>
<br>
My first enhancement to the message list flow will be to improve
my processing of to-do items from the triage. Currently I tag
messages I think I need to follow-up on with an "!action" tag
which I can then quick-filter on later. I think I can improve on
this by using a light-weight tagging/grouping mechanism. When
there's an e-mail or bug that looks like it necessitates further
action, I'll hit some key to tag the message and then type a quick
description of the problem, like "gmail broke", "folder sync". If
I already have put a message in that tag group, autocompletion
will work. I'll also have keys or a chord to moot a tag group or
replace the current contents of the tag group with the message I'm
looking at.
<br>
<br>
It's my hope that this will let me track bugs/mails that merit a
response, but where someone else will hopefully have already
replied saying what I would already have said. I can then moot my
need to follow-up. Or it will turn out the situation mooted
itself; maybe the bug got resolved invalid or was duped to a
platform issue, etc. There are of courses cases here where
conversation-threading or magic bugzilla integration would work
(or just using a magic bugzilla client instead of bugmail), but
those aren't things the e-mail app can do and are non-trivial to
implement right now. Also, frequently I find a similar class of
problem will involve multiple concurrently filed bugs, multiple
mail threads, etc. so automated threading won't cut it anyways.
<br>
<br>
<br>
The next set of enhancements would likely be to implement
classification of new messages into multiple streams (somewhat
like how it was done in raindrop). This would let me have a high
priority message stream for direct e-mails / bugzilla review
requests and needinfo requests that I should process multiple
times per day. Other streams would exist for mailing list
traffic, bug triage, and broadcast mails that I should keep up
with but which don't justify context switching. In order to
discourage compulsive checking of mails, I'd put
oinking-pig-in-the-fridge timers on all streams, with much longer
timers on the low priority streams. For the high priority stream,
I think I'd go with a notification-on-a-delay or otherwise attempt
to defer the notification until passive inference says my
concentration was already broken.
<br>
<br>
For example, I lock my computer screen whenever I leave it. If
I've left the computer, flow has probably been broken, so that
seems like a good time to put a persistent/ambient notification.
And that way I can just quickly see if the indicator is on without
getting into the habit of always bringing up the mail UI to see if
there's anything notable. Webpages can't really know when you
lock your screen, but the Simple Push API
(<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/WebAPI/Simple_Push">https://developer.mozilla.org/en-US/docs/WebAPI/Simple_Push</a>) and
Mozilla's server infrastructure (or one's own infrastructure) can
be used to generate a notification the app can process by hitting
a simple URL with a PUT request. And that can easily be hooked up
to the screensaver life-cycle. (One other reason I might do this
would be to give my Firefox OS device a few second head start
before I unplug it from USB power to prep for potentially leaving
the house and bring itself up-to-date, etc.)
<br>
<br>
<br>
<blockquote type="cite">In fact, I'd like to see some kind of
forum space where details can be discussed (planned features,
etc)...
<br>
</blockquote>
<br>
I'm with Blake that this is probably the best possible place for
discussion at this time. The dev-gaia list
(<a class="moz-txt-link-freetext" href="https://lists.mozilla.org/listinfo/dev-gaia">https://lists.mozilla.org/listinfo/dev-gaia</a>) is extremely high
traffic and a lot more general. In the event we are being
disruptive to tb-planning, we can find another place.
<br>
<br>
<br>
In terms of features the goal is to keep as much of the mail app
logic in the back-end as possible. That way all users of the
e-mail libraries get all the same benefits. The Firefox OS mobile
app, the desktop app thing I'm going to make, other apps people
might want to make, etc. But because the MoCo-sponsored
development is for the mobile app and that is my day job, many of
the features will be based on what the product features planned
for the mobile app are. While I hope to structure things so we can
add features that the mobile app doesn't need and do so in a way
that doesn't negatively impact the mobile app's code size/load
time, there may be some features that need to wait until the
mobile app needs them because of the comprehensive changes that
would be required. For example, proper conversation support will
likely require a database overhaul and will need to be coordinated
with the mobile app.
<br>
<br>
The feature backlog for all of Firefox OS (which can be found
linked from <a class="moz-txt-link-freetext" href="https://wiki.mozilla.org/B2G/Roadmap">https://wiki.mozilla.org/B2G/Roadmap</a>) is a google doc
found here:
<br>
<a class="moz-txt-link-freetext" href="https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AtVT90hlMtdSdEd4TVVjWXNfU3ctMlVhWFRrWkpweVE#gid=12">https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AtVT90hlMtdSdEd4TVVjWXNfU3ctMlVhWFRrWkpweVE#gid=12</a>
<br>
You do not need to be signed in to view the spreadsheet, but if
you are already signed in with Google credentials, it might prompt
you to refresh your login or something like that. You can choose
to sign out or refresh and things should work. The e-mail
features can be found on the "Productivity" tab of the spreadsheet
because the e-mail app is part of the "productivity" functional
team. The spreadsheet includes Calendar and Calculator features
too because the productivity functional team also works on those
too.
<br>
<br>
The spreadsheet is maintained by the Firefox OS product team and
is a list of proposed/desired features for the product. Just
because a feature is listed there does not mean it will get
implemented, although it means that someone wants us to have it.
Either product, UX, or due to a Firefox OS partner request. It
gets noted in the spreadsheet when a feature gets committed to,
but all feature work is also tracked in bugzilla and also
reflected into our pivotal tracker instance at
<a class="moz-txt-link-freetext" href="https://www.pivotaltracker.com/s/projects/867311">https://www.pivotaltracker.com/s/projects/867311</a>. (We use pivotal
for agile sprint planning. It has the short-list of features and
the shortlist of bugs to fix. It's good to get an idea of what's
happening at a glance, but if you just follow bugzilla you'll also
be fine.)
<br>
<br>
Both the Firefox OS e-mail app UI bugs and back-end
bugs/enhancements go in the "Gaia::E-Mail" component in bugzilla
under the "Firefox OS" product (which recently changed from
Boot2Gecko). The list of unresolved bugs can be browsed at
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/buglist.cgi?product=Firefox%20OS&component=Gaia%3A%3AE-Mail&resolution=---&list_id=8368297">https://bugzilla.mozilla.org/buglist.cgi?product=Firefox%20OS&component=Gaia%3A%3AE-Mail&resolution=---&list_id=8368297</a><br>
<br>
I think I'll use github issues for the desktop mail app initially;
bugzilla would be the wrong place for that unless we make it a
more formal Mozilla project at some point.
<br>
<br>
Right now I'm leaning towards the name "mysteriousmail" because
it's a Pet Shop Boys reference and I do want to put PGP support
in, but Blake has a knack for catchy project names, so we'll have
to see if he comes up with something irresistible.
<br>
<br>
<br>
Andrew
<br>
_______________________________________________
<br>
tb-planning mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>