treeger - File Manager Roadmap

Users should shape treeger by arranging a small set of useful Home modules rather than navigating a large settings surface. Recent files, pinned folders, quick access, saved searches, storage, and future modules should all be hideable and reorderable. Folder-level view and sort choices should be remembered independently.

The default view should remain quiet: one primary action, direct file and folder rows, and no permanent toolbar full of commands. Editing actions should appear in selection mode or a contextual sheet. Advanced features should be discoverable, but should not compete with browsing.

Destructive actions should use a treeger Trash with an undo window. Copy and move operations should have visible progress, conflict handling, and cancellation. The app should never silently overwrite a file.

History, pins, saved views, and preferences stay on-device. Content indexing is opt-in, understandable, and removable. Network or cloud providers should be additions, not requirements.

Recent means recently opened by the user. Opening a file again moves it to the top and refreshes its opened time. Merely browsing past a file or generating a thumbnail does not count.

Created, downloaded, and modified files do not enter Recent unless the user opens them. Those are properties of the file rather than evidence of user activity, and combining them would make the list surprising. Future views such as New downloads or Changed this week belong under search filters or Smart Stacks and should use the file’s created/modified metadata explicitly.

Folders are excluded from this list. Important folders are already represented by pins and Quick access; a future navigation-history feature should be named and designed separately if it proves useful.

The detailed feature history, constraints, ordered deliveries, and release evidence are maintained in Spaces Feature Brief.

Product thesis: treeger should be able to replace both a conventional file manager and a local gallery. The same device files need a location-first view when the user wants filesystem control and a visual, content-first view when the user wants to browse media. Switching between those views is a core product behavior, not a persona to infer or a demand signal that must be established first.

Proposed solution: Home is the application-wide dashboard and is outside every Space. It presents a Spaces section alongside shared Recently Used, pinned folders, and Quick Access. A Space is a persistent definition over the same local files: name, icon, included folders, hierarchical or aggregate-content browsing, permanent content-type membership, and a default shared layout. The built-in Explorer Space navigates direct folder contents; the built-in Gallery Space recursively presents images and videos as a visual, date-grouped collection.

Search, temporary filters, sort, grouping, selection, file actions, opening, properties, thumbnails, transfers, Recent history, and Trash are shared capabilities rather than per-Space implementations or policies. Their behavior is derived from current results, selected files, filesystem capabilities, and viewer support. Switching a Space never moves or duplicates files and should preserve each Space’s browsing context.

List and Grid use the shared SpaceLayout axis rather than separate Gallery and folder-view concepts. Explorer retains backward-compatible per-folder overrides; Gallery can project the same filtered results as either a visual grid or a source-aware list without rescanning or changing Space membership.

Space membership and file ownership are separate. Permanent content membership is also separate from temporary result filters: clearing a Gallery filter never makes non-media files Gallery members. Removing an item from a custom Space, if that becomes supported, changes only that Space’s configuration. It must not delete the underlying file. Delete has the same meaning in every Space and uses the existing treeger Trash behavior. The initial Gallery prototype lacked Delete only because shared selection and actions had not yet been integrated; Gallery now uses the same selection, action, transfer-shelf, and Trash flows as Explorer.

Prototype disposition: The first debug-only prototype used a compact Files / Gallery dropdown on Home and Gallery. That navigation has been superseded by the decided model: Home gains a Spaces section, no Space is selected on Home, and an Explorer / Gallery dropdown switches Spaces only from Space screens. A centered vertical icon rail remains a possible later interaction experiment, not part of the foundation. Gallery may continue using the existing recursive search while the shared content browse engine derives its roots and permanent membership from the Space definition. Explorer uses the corresponding hierarchical engine and retains its current folder when switching Spaces. Neither engine adds a media index, new delete semantics, or Space-specific file-operation state.

Every Spaces-lab delivery should rebuild the local debug application for device testing. The tracked artifacts/treeger-debug.apk is refreshed only when an APK artifact delivery is explicitly requested.

Decision point: Promotion from the debug lab depends on whether the existing infrastructure can produce a fast, understandable Gallery, a credible Explorer, and seamless navigation from the application Home. Refine source grouping, capture-date ordering, internal preview, video thumbnails, shared actions, and retained navigation state incrementally. Persona- or interest-based custom Spaces remain a later extension of the same definition axes rather than a prerequisite for the two built-ins.

Problem: Useful groups often cross folder boundaries or change continuously. Users otherwise repeat the same search for things such as PDFs changed this week, large downloads, or screenshots not yet organised. A static pinned folder cannot represent these sets.

Proposed solution: A Smart Stack is a saved search whose results update from explicit rules for location, type, date, and size. It can be placed on Home like a module without moving files. Rules must remain visible and editable; opaque AI classification must not be the only explanation for why an item appears.

Terminology: the live rule is the saved, continuously evaluated query; the Smart Stack is its optional presentation as a module on Home.

Decision point: Build only after scoped search and filters are dependable. Prototype without a permanent index first, then measure performance. Any later index must be opt-in, local, removable, and clearly explain its storage cost.

Current disposition: Deferred. Scoped search covers the current need, and there is not yet evidence that people repeatedly need the same changing, cross-folder result sets or want them as Home modules.

Problem: Copy and move require choosing files in one location and a destination in another. A modal folder picker hides context, while an invisible clipboard makes it easy to forget what will be pasted or whether an operation is active.

Proposed solution: A temporary operation shelf holds the selected files while the user navigates normally. It shows what is being carried, offers Copy here or Move here, and then becomes compact progress UI with cancel and conflict handling. A later version could collect files from multiple locations.

Decision point: Compare this flow with a conventional destination picker during the copy/move prototype. Keep the shelf only if it reduces navigation mistakes without becoming permanent screen furniture or creating accessibility problems.

Problem: A single global view is wrong for different content. Photos benefit from a spacious grid, Documents from a dense list, and Downloads from modified- date grouping. Reconfiguring the view on every visit creates repeated work.

Proposed solution: Remember list/grid mode, density, grouping, and sort for an individual folder after the user changes it there. Global settings remain the default for folders without a remembered preference.

Decision point: Add after list and grid modes exist. Provide a clear Use default reset and monitor whether per-folder state makes behavior feel surprising. The first delivery remembers view mode only; global Sort remains unchanged. The following information-density polish derives List/Grid section groups from global Sort rather than storing an independent grouping choice. Per-folder Sort and density remain future Folder Memory work.

Problem: Storage cleanup tools often use alarming totals and opaque one-tap actions. Users still need help finding a few understandable sources of clutter, but should remain in control of deletion.

Proposed solution: Optional, local-only suggestions surface reviewable sets such as stale installer files, duplicate downloads, empty folders, or unusually large items. Every suggestion explains its rule and opens a normal selection screen; there is no clean everything action.

Decision point: Consider only after Trash, properties, search filters, and safe multi-select deletion exist. Each rule needs a low false-positive rate and must be useful without content uploading or opaque classification.

Problem: Opening files one by one in other apps breaks browsing context and is slow when visually checking several nearby items. A normal list or thumbnail grid is efficient but flattens a collection, making exploration and comparison harder.

Proposed solution — Phase 2, Peek: Add a focused in-app preview for any file treeger can render or represent with a useful thumbnail. Examples include an image, a PDF page, a video frame, album art, or a text excerpt. When content cannot produce a thumbnail, use a typographic tile built from the file name and extension rather than excluding it. Peek supports adjacent-item navigation, useful metadata, share, and Open with; format-specific controls such as pinch zoom are additive. Entering Peek counts as opening the file and therefore updates Recently Used. Long-press remains reserved for multi-select, so Peek should use a tap or explicit preview action rather than a conflicting gesture.

Possible extension — Phase 3, Spatial View: Explore an optional visual canvas that represents every file as either its thumbnail or its file-name tile and lets people move through groups with depth or zoom. Photos are a particularly strong use case, but the interaction is not photo-only. The canvas could group by time, type, or folder and reveal detail as the user moves closer. It remains an alternative to the predictable list/grid, not a replacement for normal browsing.

Decision point: Add preview formats incrementally and ship Peek only if it is fast and memory-safe on large folders while preserving normal Android sharing and opening behavior. Treat the spatial view as a separate prototype: decide its exact user task, test it with mixed libraries as well as photo-heavy ones, and require a clear advantage over list/grid plus zoom before committing to 3D rendering, motion, and accessibility costs.