desktop e-mail UI using gaia e-mail libs (was: TB and AMO...)

Ben Bucksch 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).

Filtering/Sorting:
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 
> well.
>
>
> 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 
> anyways.
>
>
> 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:
> https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AtVT90hlMtdSdEd4TVVjWXNfU3ctMlVhWFRrWkpweVE#gid=12 
>
> 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 
> fine.)
>
> 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 
> https://bugzilla.mozilla.org/buglist.cgi?product=Firefox%20OS&component=Gaia%3A%3AE-Mail&resolution=---&list_id=8368297
>
> 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.
>
>
> Andrew
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20131121/690d709c/attachment.html>


More information about the tb-planning mailing list