| description |
|---|
Guides for making feature requests and design suggestions |
Your first task when creating a feature request is to make sure that someone else hasn’t proposed the same thing on the Libero Editor Github repository. If someone has, add yourself to the existing request and include any additional details that you have.
Leverage the power of the group. By describing the problem, others will be able to understand if they have the same need and contribute more effectively. Clear plain language problem definitions are key to developing and testing more robust solutions to meet all of our needs. It’s also helpful to state your need as a problem, not a solution, in order to give the team a better understanding of the context of the need, and help them develop the most effective solution.
Examples
- Solution statement (bad): I would like to see an auto complete feature for entering Authors affiliation details.
- Problem statement (good): It is common for Authors to share affiliation details. Having to enter the same affiliation details for each Author make updates very hard to manage and can lead to input errors.
State your feature request as simply and clearly as possible so that your idea is understood by all members of the team. This helps us to capitalize on a variety of skill sets and view the problem from different perspectives. As a rule, try to avoid technical jargon.
Good feature requests describe the context in which the feature will be used. It's easy to forget to write about context because you already know it so well. The best improvements to software are made with a clear understanding of how it's used.
Examples
- Vague (bad): Authors would like a button to share their article.
- Clear (good): When authors receive their proof it is reasonably common for them to involve other contributing authors to check their details and contributions to the article.
New features should add measurable value to products. Try to think about what value your proposal is expected to add, ideally in a testable way so that our users receive the intended value.
Example
- Subjective (Bad): I think this feature would make a fabulous addition to the project.
- Testable: (good) By adding this feature production staff and authors will be able to easily address all outstanding issues with an article before it is approved for publication.
Assuming the proper context has been provided as above, suggested solutions can also be helpful and provide the basis for ideas or areas of exploration for the team. Try to communicate as clearly as possible how your idea solves the problem you have described.
Your first task when making a design suggestion is to make sure that someone else hasn’t asked the same thing on the Libero Editor Github repository. If someone has, add yourself to the existing suggestion and include any additional details that you have.
We need to understand the reason for your suggestion before we can think about making any design adjustments. You may have received significant user feedback or have a compelling business case to support your rational which is important for us to understand.
Clear examples to support your case for a design adjustment can help to give us the necessary context to discuss your suggestion with you. In some instances, this may lead to an even more effective solution you hadn't thought of. Examples typically include overlapping user feedback, screenshots, usability test findings, analytics, and user stories.
State your feature request as simply and clearly as possible so that your idea is understood by all members of the team. This helps us to capitalize on a variety of skill sets and view the problem from different perspectives. As a rule, try to avoid technical jargon.
Voice your opinions clearly, constructively and calmly. Design feedback should ideally be measured against supporting user stories, taking the time to carefully work through the pros and cons of a proposed solution.