desktop e-mail UI using gaia e-mail libs (was: TB and AMO...)
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
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 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
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.
More information about the tb-planning