Proposing a change to design

更新於1年前

    Design is a hot topic. Many users and developers have strong feelings about design, so it is important that the community is given the opportunity to comment on future changes before they are made. People deeply experienced with MuseScore may lack perspective on how things appear to those starting afresh or transitioning from a competing commercial product.

    Adjust expectation

    Musescore the desktop software is a free and open source product (wikipedia) developed and supported by non paid volunteers and managed by Muse Group subsidiary empolyees, source. Open source is not democracy, see discussion, and the product is fully owned by (through subsidiary) Muse Group. All users that use the forum on musescore.org are not necessary the real decision makers, unless otherwise proclaimed. Please do not feel it is unfair if your elaborated proposal is rejected: you are free to fork the open source repo, or write a plugin.

    Existing reference and graphics

    Dig into Github Wiki and .org Developers' Handbook listed on development overview for specifications and design principles.
    github repo /share/icons (Musescore 4)
    github repo /share/themes (colors hex, Musescore 4)
    Branding (Graphics in Dev Handbook, editable by any log-in user, no Musescore 4 yet)
    Logos and Graphics (Graphics on .org, no Musescore 4 yet)
    MuseScore on Wikidata.org

    Search for similar or duplicate ideas

    Getting feedback

    If you want to chat and exchange ideas, use a relevant forum.

    If you want to propose a change to MuseScore's design then you should make a post in the Development and Technology Preview Forum. Your post should include:

    1. A description of your idea.
    2. Diagrams or a mock-up of any visual aspects of your design.
    3. An outline of how it addresses each of the Factors Influencing Design (see below), or an explanation of why you think a particular factor doesn't apply in this case.

    IMPORTANT: Chat with developers and gain concensus before you start coding to save yourself from having to make significant changes later on. It has happened that finished projects were wasted not getting pull or rebase.

    Factors influencing design

    If you want to make changes to MuseScore's design then you need to think about:

    • Consistency with existing designs (or why you think a new approach is needed)
    • Ease of adoption for new and existing users
    • Ability to perform common tasks quickly (basic features)
    • Flexibility to perform less common tasks (advanced features)
    • Localisation (translations and regional variants)
    • Portability (across devices and platforms)
    • Scalability (across screen sizes and pixel densities)
    • Accessibility (for people who are blind, colorblind, partially sighted, or motor impaired)

    The above factors do not necessarily apply in all cases. For example, if you want to change MuseScore's icons then this should have very little impact on accessibility or localisation. However, if you want to rearrange where the buttons that use those icons will appear on the screen then this would affect accessibility, and if you want to display text next to those icons then the text needs to be translatable.

    Accessibility First!

    Accessibility is often treated as an afterthought: something that can be added later once the visual design has been finalised. This is wrong. Prioritising the visual aspect of design often leads to a bad design that is difficult to fix without tearing everything up and starting all over again. If your design process starts with a picture then you will never see the alternatives.

    If you focus on delivering accessibility first, then you will get most of the other factors "for free". See this example of a proposal to redesign MuseScore's Mixer to see how prioritising accessibility leads to a better design for all users, not just those with accessibility needs.