Folder Hierarchy

[kewisch]

🎯The objective

The aim of this project is to support reacting to release feedback by improving the display of folders within the account drawer, in order for users to better navigate between folders and be more productive when finding the email that is relevant to the user. More specifically, we would like to show the folders in a hierarchy and collapse folders as needed.

🎒Resources

• This was a prior roadmap item for the 2024 roadmap which got deprioritized to get the release out of the door.

🦮Rules of the Road

🟢In Scope

• Add a folder hierarchy to the account drawer
• Provide a way to collapse folders starting at a certain level
• Avoid horizontal scrolling and take available horizontal space into account

🔴Out of Scope

• Folder management operations like creating/deleting

🚧Technical and/or Business Requirements

• Review required refactoring of internal folder management

Cross-Functional Tasks

🎨Design

• Provide mockups for adjusted folder drawer layout

⁉️QA

• Test folder layout with different types of folders, string lengths, hierarchies, etc.

📊MarComm

• Review app store feedback to see if we can bump some of the reviews after implementing this feature

🤝Support - Product

• Review SUMO articles to see if we need to update screenshots

[kewisch]

Don't get too excited yet, this isn't on the immediate roadmap but is related to the work we're doing on #8812 so it might be a by-product of what we do :)

[ccpp]

Thank you for your great work!

Could you please include thubderbird-style archive subfolders in your plans? Also explained in https://github.com/thunderbird/thunderbird-android/issues/3472#issuecomment-418353023

And, may I ask for keeping following issues that were both closed by "cannot reproduce" after last drawer rework.

• #7849
• #8137

[kewisch]

The scope for this epic is still being nailed down since it isn't an immediate priority, but I don't want to expand too much. Archive subfolders should be a separate issue, what we should really do is see if there are some performance improvements we can do loading with many contacts.

For enhancement suggestions like this, would you mind posting them over on Mozilla Connect? This is a great place for the community to discuss and help shape new ideas together, and is something we review regularly to determine the future roadmap.

To get the most out of your post, check out this quick guide on crafting impactful suggestions. Focusing on the problem your idea solves and how it could help others can really make it stand out!

I'll check out the issues you mentioned.

[ccpp]

Thank you @kewisch for your information, I was not aware of Mozilla infrastructure taking over planning information.

My desired feature of subfolders in archive is already there. Whoever wants it and has a Mozilla account, give kudos there .. https://connect.mozilla.org/t5/ideas/archive-emails-to-per-year-subfolders/idi-p/73258

[bpesner]

I volunteer for this issue. I have working code that I've tested with an email address served by Dovecot and one served by Yahoo (here are some screen shots).

I tried testing with gmail but apparently the debug build variant uses a browser for logging into gmail that google doesn't accept.

My code only addressses the main folder view (as in the screenshots). It doesn't address the Manage Folders or Choose Folder functions. In any case, I have no idea how to invoke the Choose Folder function. However, both functiona are built using FastAdapter, which has an extension supporting expandables, so it would actually be easier to address the issue in those functions. I can do that if the project team desires.

My code makes modifications that should only be visible to the main folder view code (package app.k9mail.feature.navigation.drawer.ui.folder). The basic strategy is to convert the flat input folder list (ImmutableList<DisplayFolder>) to the FolderList function into a heirarchical list, with parent folders owning lists of child folders. Then the FolderListItem function is called recursively, with a level parameter added. The current icon parameter that indirectly goes to the Material3 NavigationDrawerItem is preceeded by an expand/compress icon (a chevron) that is made invisible for folders that have no children, is rotated appropriately when a folder with children is expanded or compressed and is shifted to the right an amount based on the level using a Spacer. Finally, when children are compressed, the recursive call to FolderListItem is skipped.

There are of course more details that I can share if needed. I haven't forked and branched the repository because I wanted to give the project team a chance to review this before I cluttered the repository. Please review and let me know how to proceed.

[kewisch]

Hi @bpesner thank you for stepping up! Just to clarify, is your work in addition to #630 ? There was a pull request in #8956 and then #9045 that may already cover what you mention, but maybe I am missing something. The new drawer that includes the changes you will find in the code as the "dropdown" drawer, which is enabled in debug and daily as a feature flag.

Let's move discussion to a separate issue, feel free to file one, this epic is more the meta issue for a broader set of changes.