glodastrophe: the very in-progress experimental desktop front-end to the gaia email backend

Andrew Sutherland asutherland at asutherland.org
Fri Sep 18 17:04:37 UTC 2015


On Fri, Sep 18, 2015, at 11:32 AM, Robert Kaiser wrote:
> Andrew Sutherland schrieb:
> Will there be a possibility to still have a completely message-centric 
> workflow there or do people like me, who have a strong dislike for the 
> "conversation" fad, be forced to look for a different app to do their 
> email chores?

Sure, a message-centric workflow is very possible.  As noted, it's
mainly a question of creating an alternate index/view on a per-folder
basis.  As of last night when I finished up the unread count tracking,
this should now be pretty trivial to do cleanly in the back-end.  It's
also a great example of how parts of the implementation can be optional.
 I'm not sure the phone-focused gaia email app wants this, but it makes
a ton of sense for a desktop app, and a message-centric UI at least
probably wants to exist for glodastrophe for search results where I
think it makes more sense to show results on a per-message basis.

Many of the UI components could be reused too.  The main difference
between the list of conversations and list of messages right now in
glodastrophe is that we (currently) assume the number of messages in a
conversation is reasonable enough that we can fully instantiate them
into the DOM and leave it up to Gecko to be in charge of all scrolling
the usual way.  (Although the back-end is exposing the list of messages
as a virtual seekable list, we just ask for everything.  A more
message-centric UI would probably still want the list of messages
separate from the body display of the selected message, so that would
easily work as a virtual list without too much legwork, although fancier
variable height things could be done with some additional work.)

Note that the back-end would still be assigning messages to
conversations[1], but presumably this would still be useful to a
message-centric UI since it allows for:
* easy next-in-thread prev-in-thread navigation
* easy "show in conversations" or "show in thread structure"
implementations
* easy "oh, there's a reply to this message" indicators so one doesn't
need to risk accidentally reply to a moot email
* easy "oh hey, there's a new reply to this message / this thread" UI
notifications
* allows us to do eventually do need quoting tricks where you could jump
from the quote excerpt included to the full context in the original
message.  (This is more of a processing stage than runtime stage,
though.)

Andrew

1: There is some overhead to maintaining that information, but for
situations like gmail and emerging-standard JMAP (a la fastmail), the
information is basically handed to us on a platter, so the overhead is
minimal.



More information about the tb-planning mailing list