Ovilia commented on PR #20865: URL: https://github.com/apache/echarts/pull/20865#issuecomment-2853592440
@100pah Thanks for the detailed review! ## Backward Compatibility Since we aim to reduce the overlapping issues among default components, we've had to adjust the default positions and alignment methods of the components. This might cause some situations where users' original settings lead to overlapping under the new layout, just as in the example you mentioned. However, this is **a carefully considered trade-off**. For instance, I believe the probability of displaying both the legend and the title simultaneously is much higher than that of displaying both the legend and the dataZoom. Suppose the new solution can address 60% of the previous bad-case scenarios while introducing 10% of new ones. Even so, this optimization is still highly valuable. To completely solve this problem, we would need to come up with **a robust component anti-overlapping mechanism**. Unfortunately, we're likely to run out of time to implement this in 6.0. Therefore, when the time comes, we will provide an **migration document** to inform users about which default values we've modified and how they can adjust the positions in case of overlapping. ## Theme Colors After much careful consideration and deliberation, I truly believe that this new theme is the optimal one I can come up with. When it comes to aesthetics, it might be rather challenging for me to provide objective evidence. However, in my sincere opinion, this is the best design I could come up with. Designing the theme color requires a comprehensive and holistic consideration. It's not simply about having individual colors that look good on their own; they must also harmonize well when put together. Therefore, **with due respect to all viewpoints, I'm inclined to uphold this theme**. I understand that different people may have diverse perspectives on color aesthetics, but based on my in-depth consideration and analysis, I believe this theme has its unique merits and can best meet our overall design needs. I'm more than willing to further discuss and listen to your thoughts to reach a more satisfactory solution together. If any of you have some better ideas regarding the theme color, I would humbly suggest that you could use the [theme builder](https://echarts.apache.org/zh/theme-builder.html) to create a theme think is better. Subsequently, we could further discuss it through a community voting process. As about the issue that the third color is relatively close to a neutral color, I believe this is a design choice after comprehensively considering various factors. The reasons for this design were also stated in the PR description. If you have any objections, I would suggest you propose a better overall design plan. This PR currently doesn't have the logic for a dark mode. Whether certain colors need to be adjusted may be further discussed in the PR for the dark mode in the future. My preliminary plan is to calculate the colors for the dark mode dynamically based on the light mode. If some colors need adjustment, we can then consider whether corresponding methods need to be provided. Regarding the concern that the green might be too light and the contrast for labels is insufficient, this issue isn't actually caused by the selection of the theme color. Instead, it stems from the inadequate optimization of label colors for some series. For example, pie and funnel both use label/labelLine design, why is the label color of the pie chart dark gray, while the funnel chart's label takes the theme color? Considering design consistency, could we **change the default label color of the funnel chart to the same dark gray as that of the pie chart**? In the Treemap, the yellow in the original theme color also has a problem with insufficient brightness contrast between the background color and the label color. Similar to how the [bar chart automatically calculates whether to use white or dark gray for the label](https://echarts.apache.org/examples/zh/editor.html?c=bar-label-rotation) based on the brightness of the theme color when the label is inside, wouldn't it be more reasonable if we adopted the same approach for the Treemap? ## Highlight/emphasis color of map If you think the current slightly darker gray isn't eye-catching enough, I think we could change it to light blue. However, I'm concerned that this color might cause confusion when using visualMap. Could a darker gray be acceptable to you? The originally yellow and red is never used elsewhere and the color choice is not elegant, so I feel necessary to change them. I don't quite agree with the statement "since users typically use map individually and do not combinate maps with other types of chart". Maps are likely to appear in the same dashboard as other charts, not to mention that we even support designs like displaying pie charts on the map coordinate. ## Visual map color Using darker color for smaller value was a mistake. I didn't check carefully before and will fix this later. Using a mono-tone color in visual mapping could be a better design choice. Firstly, a mono-tone design is simpler and more likely to achieve harmony. This might well be the reason why GitHub adopts a mono-tone green design. Secondly, the introduction of red may imply dangerous or negative connotations. However, in many cases, a large value doesn't necessarily carry such meanings. Therefore, for the default design, a more neutral semantic expression is, in my opinion, more appropriate. Thirdly, in the gradient from red to blue as you suggested, there is a light-blue to dark-blue section. In fact, the value corresponding to light blue is larger than that of dark blue, just as you pointed out above, dark colors usually represent larger values. Thus, using a mono-tone color can reduce such misunderstandings. ## axisTick As we can see from the following demos, most chart libraries use no axis tick for default.  I believe again, this is a design choice. The benefit of having a neat design by not showing ticks overweighs the disadvantage of data grouping. Maybe we can use a smaller `barGap` by default to better indicate the grouping. Ticks should not be hidden for time series. Can you provide the option for your time axis for me to check? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
