[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Blaustein / Klaus,

In brief response to matters arising:

Ordinarily a Private Message being such would not be shared. However, regarding the attached unwelcome, unnecessary, and abusive Private Message received from ElfKaa, it is shared solely as an example that can be added to the list of conduct that discourages and dissuades user participation to the considerable detriment of the GCC project as previously detailed.

Few if any contributors would invite or welcome such a message, or continue to contribute afterwards, which was undoubtedly the intention. The GCC community can only wonder as to how many other similar messages have been sent to discourage participation and the extent of the negative impact of this.

It is readily apparent to anyone from the content of the Private Message and reading of the forum ElfKaa feigns misunderstanding in a number of ways to suit their own purposes, regardless of extensive public written correspondence to the contrary, and further does not care about the detriment they have caused having chosen not to offer an apology and instead cause further detriment, in what is now exhaustively established to date as a clear and persistent course of conduct.

The selfless female that was willingly assisting the GCC project in creation of a high quality female freely distributable voice for the benefit of all users would have appreciated and accepted an apology and again been willing to assist having been previously dissuaded by the conduct of ElfKaa to the extent she decided to no longer participate. Unfortunately this latest conduct of ElfKaa has now ensured that situation detailed previously has probably become permanent which was undoubtedly the intention, as any apology now she would probably consider unconvincing and insincere.

To the same list of discouragement and dissuasion can also be added unnecessarily argumentative and / or baseless oppositional responses to proposals and feedback for the sole purpose of preventing implementation. In addition to that can be added oppositional responses that overstate trivial issues and omit readily apparent and achievable solutions plainly known to the complainant again for the sole purpose of preventing implementation. Such conduct is the exact opposite of constructive criticism. A contributor either commits further time, energy, and resources addressing this, or accepts their initial effort was in vain, gives up and walks away. It will not escape the notice of potential contributors they likely face the same if they bother in the first instance. Many will conclude they already have enough hassle in their life and do not require any more.

Notably it is almost always the case this conduct occurs when the complainant has no personal usage for what is proposed, and selfishly intends no one else to have usage either by seeking prevention of implementation. This even the case when the complainant and anyone else not requiring what is proposed are unaffected in any way by a proposal. As the oppositional response is therefore not genuine, the motivation and intention of the behaviour is similarly not so nor in good faith.

GCC should and could have a thriving community actively participating. To date, extensive efforts to encourage and promote this have been consistently thwarted by the conduct of ElfKaa and others intent on the opposite. This has persisted even when made extensively aware of the affect of their actions, in effort to stamp it out, before it stamps out the project. This indicates such actions have been undoubtedly deliberate and intentionally detrimental to the GCC project to date which is as profoundly disappointing as it is and damaging.

Below is another example:

Continuous Zoom implemented correctly introduces no problems. As proposed, pressing zoom in or zoom out would zoom in or out accordingly exactly the same as at present. Users of this existing functionality are unaffected. Users that do not require the enhanced zoom functionality are unaffected since they do not currently double tap or press and hold zoom buttons as they have no function, they will not be doing so either to access the enhanced zoom functionality when implemented. The separate unrelated issues being conflated with enhanced zoom functionality do not therefore arise any more than as at present, or indeed at all for the vast majority of ordinary users using GCC as intended.

Further, there has been no valid legitimate reason presented to date to abandon implementation of enhanced zoom functionality many if not most users will find useful, with non users being unaffected.

GCC, on the map screen, currently does not distinguish a double tap from any gesture followed quickly enough by another, if initiated from the same point on screen as the first. This is a known problem. The solution is to fix gesture detection for map reset to respond to actual double tap only. Users of Continuous Scroll when implemented have no need for repeated map scrolling in the first instance.

Another known problem, as above, except on the graph screens. Solution is similar as well, fix gesture detection for graph reset to respond to actual double tap only.

Feedback to date, including ElfKaa's, identifies the following as important:

Retain the buttons in order, and therefore...

Retain the existing appearance of the menu screen.

Avoid usage of new button images or otherwise altering images.

Avoid creating empty spaces or the appearance of anything being 'missing'.

And a new feedback on behalf of someone that did not wish to contribute directly:

Avoid 'grey out' of existing button description that may potentially cause issue dependent on user selected colours.

There have to date been the following potential solutions that have not been already eliminated:

'blank image and no text', 'blank image with description', 'blank image with unavailable', and 'image with unavailable'

Only 'image with unavailable' meets every requirement and achieves the objective of making unavailable functions discernable from others.

To address ElfKaa's comment "Nobody know what was on that fields that are yet Unavailable.. So why to say - this "fields" are "Unavailable""

The button is a relatively descriptive image of the function. The button description text 'Unavailable' in conjunction with the existing button image identifies the function and that it is currently unavailable. If implemented, users that read the 'Help' would know functions when unavailable are identified as such, and the order of the buttons. During ordinary usage, the user would in any event become familiar with the buttons and read their actual description text when the function is available. If really an issue, the description text when the function is unavailable, could rotate between [description] and [Unavailable].

Contrary to the opening statement of ElfKaa's Private Message attached, there exists no issue personal to ElfKaa, and working positively in collaboration to advance the GCC project would be welcomed. However, there in fact exists an issue with every 'contributor' whose 'contributions' include conduct that discourages and dissuades user participation to the considerable detriment of the GCC project as previously detailed.

If future contributions from ElfKaa can be as similarly positive and productive as this section, while the damage of earlier conduct cannot easily be undone, moving on and going forward, there should arise no need for such conduct to be further highlighted in effort to stamp it out, before it stamps out the project. This can then be considered to be the end of matters, which I sincerely hope that it is.

low.flying.pigs