After several days of discussions and design iterations, we’ve developed a new proposal for the highlighter, incorporating your valuable feedback.
Original Highlighter Color
We’re reinstating the old themed highlight color, which will become the default for basic ==syntax==. Custom colors will now use emoji color characters syntax, ensuring consistency across themes while preserving the semantic meaning of the colors.
For light themes, we’re using a duo-tone design for the background and foreground. While we’re generally pleased with the result, there has been some feedback from forum users. We’re currently experimenting with an alternative design for the highlighter in light themes (and adding more vibrancy to some dark themes). Though we haven’t yet decided whether this will replace the current design, we’d appreciate your feedback on these changes.
We are committed to ensuring the app is accessible to everyone, and the current highlighter design fell short of that goal. We’d like to introduce the new custom highlighter palettes designed to accommodate color-blind users.
ABSOLUTELY LOVE! For me, as an individual, this addresses my feedback to a tee (and I feel like the broader community as a whole). Thank you for taking the time to address our feedback and allowing us (those who are so opinionated about highlight colors) to “have our cake and eat it to!”
Love the new color coordinated pallet! (I wouldn’t be opposed to the color coordinated pallets have a matching text color though, but either way happy with the new proposal)
Love that you will reinstate the original highlight syntax and color!
Is there a keyboard shortcut for bringing up the colored highlighter picker on Mac? I see a shortcut for the default on 2.3.2, and none for the other colors.
I just tested, and accessing the colored highlighters is absurdly easy on mobile.
I’ve always disliked the default green highlighter, and much prefer yellow. Thank you.
Even though I just said that: echoing the joyous shouts of “the developers are listening to us users, and quickly, even!”
Reinstating the original highlight color, which will be a stripe of color over black text, and adhere to the basic markdown highlight functionality
Then, you will also keep this new 5-color highlighting extension you developed for version 2.3, as a subsection of the highlighter, which not only adds stripes of color but changes the color of the text.
You would like to address the accessibility issue by introducing additional color sets, presumably in the options menu, with options for:
Duete
Prota
Trita
Do I have this right?
I like where you’re going with this!
I’m still struggling with the accessibility portion of #2. In every example, there are both improvements and degradations to the colors.
I would suggest the basic highlighter functionality to be less rich - a canary yellow over black text to look like a modern version of physical highlighters.
For the deute option, I’m still struggling a bit. Can you name the colors in the image and I can make a suggestion?
Grateful for your responsiveness on these issues. Love the restoration of the old themed highlight color as default and the duo-tone design in the second and third images above. I’m a bit confused as to the alternative being considered–the colors in the third image mostly look less vibrant to me than those in the second. Overall, these are welcome steps.
For what it is worth (rarely comment) I thought the initial design lacked Bear’s trademark pop. I think the new designs marry the vibrancy of highlighter v1 with the extra colours or v2. I like.
By implementing the origin colour from old implementation as default colour inside new implementation you are going to break this point of your approach:
The first thing I noticed in the screenshots is that the default colour is often almost indistinguishable from a custom colour with a similar hue: one green and the other can only be distinguished from each other with concentration.
For users who want to use several colours, this means that they have to do without the main colour and always have to choose one of the custom ones and therefore no longer have a main colour that is easy to enter in the sense that the standard markdown markup is used.
If I understood correctly, the critics of point “original highlight colour” of the new implementation wanted the old system back. Then you can simply give it to them by allowing them to decide in the settings to do without multicolour highlights.
I don’t find the solution really ideal that it forces the majority of users to no longer be able to use the normal syntax without unicode circles simply because the colour wasn’t nice enough for a minority. As far as this point ‘original highlight colour’ is concerned, it has already been solved by solving the other points, ‘text colour’ and ‘colour blind user accessibility’. So this third point is both puzzling and annoying to me.
I will not be an intensive user of multiple colours. I might use a second or even a third here and there, but that’s why I want to have the main colour that I don’t have to worry about determining. Precisely because I want it to be my main colour.
By the way: I like to switch light themes and don’t want to stick to just one just to minimise the annoyance
1、【For users who want to use several colours, this means that they have to do without the main colour and always have to choose one of the custom ones and therefore no longer have a main colour that is easy to enter in the sense that the standard markdown markup is used.】
yes\yes\yes，I couldn’t agree more with this user! I want to use a variety of colors. If I follow the latest design, the default color doesn’t make sense to me, which is very uncomfortable
2、If really want to restore the default color.It is hoped that the default color display effect can be basically the same under different themes, otherwise every switch
this in turn would lead to further complaints about the fact that not every theme comes with the most beautiful and suitable colour.
nevertheless, each palette would have two very similar colours
The cleanest solution in my eyes is to make the old implementation optional, as an alternative to the new one, in which several colours are available. The rapid criticism of the new implementation was that several points were dealt with at the same time. According to the screenshots, the other and in my opinion more important points in regard to accessibility seem to have been solved. As far as the ‘original default colour’ is concerned: anyone who wants it should have it, but please not in this way. It is an absurdity to combine the old and the new implementation
I completely agree with your point, but not your conclusion. As someone who is now regularly using all the custom colors I would have to go in a manually choose one additional color…
Separating the functions adds only one more step for users (such as myself) to go in and color coordinate (not to mention that this step already exists for every other color, just not green). BUT this also restores a separate function highlighting.
For users who only highlight (which is not me), they now have the option to highlight with the color that bests matches their chosen theme (and retain the vibrancy). They are no longer restricted to a green that doesn’t match their theme.
For users (such as myself) that do both (highlight & color coordinate). I am now able to distinguish and separate two different greens (for example). Now, I can color coordinate, with a color palette that matches across different colors and themes. I am also able to have a separate color, that does standout and does not match the other color pallets- allowing me to quickly visualize the difference (i.e., a highlight).
I understand the cost is adding one more step for green, but the return is having another function that does act separately (i.e., highlighting vs. color coordinating).
I wouldn’t be opposed if there was a separate syntax for color coronating (i.e., not the ==syntaxt==, which is also being used for highlighting). But i think that would just be outside the limitations of markdown and instead i have just developed a keyboard shortcut to quickly choose different colors…
Can you elaborate more on what you struggle with? In the deute image the order is: default (green), red, yellow, blue, green, purple and the colors value are:
Red = bg: #FFDFCC text: #46342B
Blue = bg: #BDDCFF text: #43607F
Green = bg: #B7FF75 text: #32491D
Yellow = bg: #E1CCD9 text: #49273B
Purple = bg: #C9EEE1 text: #00422B
Just for color-blind users? As we don’t have plans to change the defaults (as it was one of the point of the current change)
I don’t understand your point. My point was that if you don’t care about other colors, you can simply stick with the default. The themes will automatically select the “best” color for your theme.
We prefer to steer clear of preferences like these because they significantly reduce the app’s consistency and polish.
Would overriding the default highlight hotkey for a specific color resolve this issue for you? (For instance, yellow would now be your default highlight color for every theme?)
and super happy the original highlighter color is back!!!