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

Andrew Sutherland asutherland at asutherland.org
Sat Oct 26 21:41:19 UTC 2013


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



More information about the tb-planning mailing list