Kiwix-android: Style guide for the Android Kiwix github repository

[Frans-Lukas]

Is your feature request related to a problem? Please describe.

The Kiwix Android app contains some consistency with regard to design but fails at other design decisions. Examples include the contrast of text in some views being too low or the behavior of actions being inconsistent with expectations. (Contrast of Zim book tags (currently has a contrast ratio of 2.7, where 4 is the recommended ratio [1][5]) and one-click downloads are poor design decisions because they are non-negligible if internet access is limited [2].)

Describe the solution you'd like

To combat future design-mishaps a short but concise design document could be added to the repository. This design document serves two purposes:

1. A reference in design argumentation.
2. A way for contributors to see how the app should look and behave. E.x. [4]

To start with I think our design document should contain:

• The colors of Kiwix and how to use them.
• Some links to where to look when researching a design decision.
• A sentence or two about accessibility. That is, contrast, color and perhaps something similar to Firefox Fenix's page about accessability [3]:

Accessibility (or "a11y") is about making apps usable by everyone. Android developers need to pay particular attention to users with visual impairment, auditory impairment, and restricted motor skills.

Describe alternatives you've considered

I have looked at some other large github repos and noticed that very few contain design guides, therefore I am cautious on whether we should create a design document or not. My worry is that it will bloat the readme and that is why I want to keep it concise.

Additional context

This is part of my summer of code proposal and something I will work on in the coming week. I also want to hear what other things might be good to include in a design document for this project.

[1] https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
[2] https://material.io/design/communication/confirmation-acknowledgement.html#confirmation
[3] https://github.com/mozilla-mobile/shared-docs/blob/master/android/accessibility_guide.md
[4] https://material.io/design/color/applying-color-to-ui.html#usage
[5] https://contrast-ratio.com/#%234883CC-on-%23C8DAEE

[yashk2000]

This is a good idea and will definately be of help to new contributors. Maybe instead of adding this to the README causing it to bloat, this could be added to contributing.md as this is information just for people who will contribute.
Also, below are a few other points you could add in the list:

• Mention that Kiwix has a set of text appearances already defined like textAppearanceHeadline6 etc and contributors should use those instead of creating their own new appearances. I did that a couple of times unknowingly when I started contributing as I didn't know that there were already some predefined styles.
• You can mention that instead of calling a resource of the above type by doing something like @resourceFile/textAppearanceHeadline6, such resources can be instead called by
  ?textAppearanceHeadline6
• Mention that when a contributor creates new string resources, they should add those to the vaules-qq files too for the ease of translation of the string into other languages.

[Frans-Lukas]

It's good to hear you think it will help! I like your suggestions as well. However, they feel like pure contribution advice. I.e. how to work with design elements when working in the project. Which I think is great to have but should be in a separate document.
E.x:
contrib.md -> designGuide.md
contrib.md -> designElements.md
or
contrib.md -> designGuide.md
designGuide.md -> designElements.md

Where '->' indicates a link.
designGuide.md is more 'theoretical' and designElements.md is more practical.

Do you agree? Definitely open to other suggestions as well.

[macgills]

Adding string resources can be its own document, we have an existing task to document this process #1759

[yashk2000]

@Frans-Lukas your idea is good. We can link all of these guides in the contributing.md I guess. That way one doc itself won't get too bloated but will contain the guidelines(or at least links to them) in a single place.