desktop e-mail UI using gaia e-mail libs (was: TB and AMO...)
ben.bucksch at beonex.com
Thu Nov 21 22:10:18 UTC 2013
First off, Andrew, thanks a ton for start this endeavor!
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.
If you have mockups or even screenshots, I think that would help a lot
to understand what you envision.
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.
A few other ideas / viewpoints:
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).
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.
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.
But with the above description, it would be easy to come up with
automatic heuristics that satisfy the above rules.
* The heuristic notices that I get a lot of mail from
"bugzilla-daemon at mozilla.org", so it makes an approriately named
folder for it. Ditto with friends.
* 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.
* 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.
* 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.
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.
P.S. (I think tb-planning is the right place for discussion. If this
isn't planning, then I don't know what is.)
Andrew Sutherland wrote, On 26.10.2013 23:41:
> On 10/26/2013 07:14 AM, Tanstaafl wrote:
>> 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.
> 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
> Implementation-wise, I want to use Mozilla's web components UI
> library, Brick (https://github.com/mozilla/brick/), and otherwise
> build things using the existing web components polyfill. Before Brick
> I was interested in using Polymer (http://www.polymer-project.org/)
> 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 (http://www.polymer-project.org/platform/node_bind.html) and
> a higher level templating system that builds on it
> (http://www.polymer-project.org/platform/template.html). 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.
> 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.
> 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.
> 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
> 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.
> 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 (https://developer.mozilla.org/en-US/docs/WebAPI/Simple_Push)
> 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.)
>> In fact, I'd like to see some kind of forum space where details can
>> be discussed (planned features, etc)...
> I'm with Blake that this is probably the best possible place for
> discussion at this time. The dev-gaia list
> (https://lists.mozilla.org/listinfo/dev-gaia) is extremely high
> traffic and a lot more general. In the event we are being disruptive
> to tb-planning, we can find another place.
> 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.
> The feature backlog for all of Firefox OS (which can be found linked
> from https://wiki.mozilla.org/B2G/Roadmap) is a google doc found here:
> 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.
> 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 https://www.pivotaltracker.com/s/projects/867311. (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
> 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
> 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.
> 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.
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning