Proposed implementation
“Add an album artwork gallery with swipe navigation, zoom, a slideshow, and PDF support.”
Feature ideas and unmet needs are welcome. Symfonium is fully user-driven. Feature requests and direct feedback from the people who use the app shape how it evolves.
A useful request explains the need, the current limitation, and the result you want. This gives the developer and other users a clear starting point for discussion.
Why context matters
Section titled “Why context matters”Symfonium supports many media providers, playback methods, Android devices, screen sizes, and workflows. Changes can affect navigation, performance, reliability, or existing behavior in other parts of the app.
Explaining the need can reveal a simpler or broader approach. It also gives other users a clear way to add relevant context from their own setup.
Describe the need, then propose the solution
Section titled “Describe the need, then propose the solution”Start with what you are trying to accomplish, what prevents you from doing it today, and what a successful outcome would change. Include relevant context such as the media provider, device, playback method, or part of the app involved. For media-related requests, identify whether the content is stored locally, embedded in media files, or supplied by the provider.
You are still encouraged to suggest a solution. The distinction is that the proposed implementation should support the need, rather than replace its explanation.
Example: album artwork and booklets
Section titled “Example: album artwork and booklets”Need and outcome
“I keep additional album artwork and digital booklets alongside my music. I currently have to leave Symfonium to view them, which interrupts the listening experience. I need a way to access those materials while an album is playing.”
The gallery remains a valid proposal. Explaining the need shows why it matters and leaves room to consider where the artwork comes from, which providers expose it, which formats can be supported, and what can work consistently across different setups.
Other applications can be useful references. Explain which part of their approach solves your problem, as well as what remains missing or inconvenient. Their implementation may depend on a different interface, data model, or set of supported providers, so reproducing it exactly may not be the best fit for Symfonium.
Make the discussion useful
Section titled “Make the discussion useful”Before opening a new topic, check the documentation and search the feature-request forum using several related terms. For example, an idea about album booklets may already be discussed under terms such as additional artwork, back cover, or folder images. If a request already covers the same need, add your distinct use case or relevant context to that discussion instead of creating a duplicate.
Keep one coherent need per topic. Combining unrelated ideas makes each one harder to understand, discuss, and evaluate.
Keep the provided template and complete each relevant section. It is designed to capture the context needed for evaluation. A concise explanation of the need is more useful than a detailed specification with no context. Follow-up questions may reveal an existing option, a provider limitation, or another way to reach the same outcome.
If Symfonium already provides the behavior but it is not working as expected, this is a support issue rather than a feature request. Reproduce the problem, gather logs, and open a support topic instead.
How requests are evaluated
Section titled “How requests are evaluated”Evaluation can include:
- Fit with Symfonium’s purpose and overall experience
- How the outcome could help different workflows
- Technical feasibility across Android versions, devices, and media providers
- Effects on performance, reliability, usability, and existing behavior
- Implementation complexity and long-term maintenance
- Existing options or related requests that may already address the need
A request can describe a valid need and still fall outside Symfonium’s scope, depend on capabilities that Android or a provider does not expose, conflict with established behavior, or be difficult to support reliably over time. Considering these constraints helps keep the app consistent and dependable.
Submitting a request opens a topic for discussion, not a commitment to a specific implementation or date. If the idea moves forward, its scope and design may evolve during that discussion.
Submit your request
Section titled “Submit your request”Sign in to the forum, open the Feature requests category, select New Topic, and follow the provided template.
Open a feature requestExplain the need, the current limitation, and the outcome you want to achieve.
Report a problem insteadIf an existing feature is not working correctly, gather logs and open a support issue.