Need an option to re-order folders, or be more wise about folder ordering

RESOLVED WONTFIX

Status

--
enhancement
RESOLVED WONTFIX
4 years ago
8 months ago

People

(Reporter: standard8, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

My main IMAP account has a lot of folders, I have a bunch of year/month Archive folders as created by Thunderbird.

I also have other folders which start later in the alphabet.

Due to this, unless I do specific renaming, I have to scroll through several pages of folders before I get to my main folders which aren't the core inbox/sent etc.

It would be useful if we could have an option to re-order folders, e.g. putting some near the top of the list, or demoting others to the bottom.
Asking for UX guidance. I expect this is likely outside the norm for most email users, so more advanced folder reordering UI may be too much clutter. Grouping standard folders at the top may make more sense, but also may not be 100% the same across all accounts due to variances in email server reporting of those folders.
Flags: needinfo?(jhuang)

Comment 2

4 years ago
Hi Mark,
I agree that the main folders (inbox/sent...) should be list on the top of the screen rather than order them by alphabet.
However, I guess right now the order of the folders is reflecting to what you have on server, right? My suggestion is not to move the main folders in group automatically by ourselves because some users may intent to move those folders by purpose.

But in your case, I can study how we are going to manage the folders but I need James to evaluate the possibility of changing the order and possible conflict with other email servers.
Flags: needinfo?(jhuang)
(In reply to Juwei Huang from comment #2)
> I agree that the main folders (inbox/sent...) should be list on the top of
> the screen rather than order them by alphabet.
> However, I guess right now the order of the folders is reflecting to what
> you have on server, right? My suggestion is not to move the main folders in
> group automatically by ourselves because some users may intent to move those
> folders by purpose.

To clarify, my folder list currently looks like:

- Inbox
- Drafts
- Local Drafts
- Sent
- Junk
- Trash
- <some folders that I've got that start with A>
- Archives
-- 2009
--- 2009-01
--- 2009-02
-- < 72ish more archives folders in a tree>
- <my other useful folders continuing in alphabetical order>

This is typical "mail" client format - the "core" folders first, followed by the rest in alphabetical order.

The pain is having to scroll through the 70 ish folders worth of archives to get to some of the folders I want. I don't really want to have to do that every time I want to read email in a different sub-folder - especially as I probably would never visit the archives folders on my mobile (whereas I will visit some of the others as I get release driver email etc).

I've seen other mail clients on mobile that let you manually decide to put folders in the top group rather than the bottom. That may be too much here, but it'd certainly be nice not to have to scroll through the 70 folders each time.
Flags: needinfo?(jhuang)
Clarifying, we already order special-folders near the top.  Relative ordering occurs among siblings for each folder in the hierarchy, which largely covers the dominant normal cases of folders-at-top-level and everything-lives-in-the-INBOX-namespace idioms.

Check out https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/master/data/lib/mailapi/mailbridge.js#L34

=== excerpt ===
var FOLDER_TYPE_TO_SORT_PRIORITY = {
  account: 'a',
  inbox: 'c',
  starred: 'e',
  important: 'f',
  drafts: 'g',
  localdrafts: 'h',
  queue: 'i',
  sent: 'j',
  junk: 'k',
  trash: 'm',
  archive: 'o',
  normal: 'z',
  // nomail folders are annoying since they are basically just hierarchy,
  // but they are also rare and should only happen amongst normal folders.
  nomail: 'z',
};

/**
* Make a folder sorting function that groups folders by account, puts the
* account header first in that group, maps priorities using
* FOLDER_TYPE_TO_SORT_PRIORITY, then sorts by path within that.
*
* This is largely necessitated by localeCompare being at the mercy of glibc's
* locale database and failure to fallback to unicode code points for
* comparison purposes.
*/
function makeFolderSortString(account, folder) {
  if (!folder)
    return account.id;

  var parentFolder = account.getFolderMetaForFolderId(folder.parentId);
  return makeFolderSortString(account, parentFolder) + '!' +
         FOLDER_TYPE_TO_SORT_PRIORITY[folder.type] + '!' +
         folder.name.toLocaleLowerCase();
}
======

For Mark's case, if the archive folders were created with \Archive or \All on a server that supports SPECIAL-USE using a client that supports SPECIAL-USE (I forget if TB would have been doing this), the result is that the archives would end up sorted before the normal stuff no matter what.  Of course, they alphabetically end up in basically the same place anywho.

It sounds like if we simply made it possible to collapse/expand folders/level of hierarchy, it would more immediately address Mark's problem.

Other options would be for us to honor the IMAP subscribed folders mechanism and/or have a checkbox list display to let the user select which folders to show in the folder list.  We could then also reuse that UI for the list of folders to automatically synchronize.  (Right now we only automatically synchronize the INBOX.)

Comment 5

4 years ago
It's a good idea to collapse/expand the folders if necessary. But it needs more visual inputs and more time to evaluate a better ux flow to make it happen. I will consider it as a feature, so need info Sri to comment.

I would say that it may not happen in this release, but I definitely will look into it on next release:)
Flags: needinfo?(jhuang) → needinfo?(skasetti)

Comment 6

4 years ago
Yes, we should consider this for the next release...
I will add it to the backlog...
Flags: needinfo?(skasetti)

Comment 7

8 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.