2.4.2 | Colorizer # Value

Support
#1

This is minor but definitely a bug. You used to be able to type hex codes directly into the colorizer without the hash and all would work nicely. Now you MUST include the # for it to even register.

#2

Hi @DoncoMarketing,

Thanks for writing in!

Yes, you have to include # in the color in the updated version of the theme.
I will check with our development team if this is bug or intentional and get back to you.

Thanks

#3

Hi @basanta,

Thank you for the followup. These seems like usability backtracking for no reason. I would love to at least know / understand the justification for this decision once you hear back from the team.

Looking forward to your reply.

Thanks!

#4

Hi Josh,

I can provide some more info here. I understand how this could be seen as a regression because of how it worked previously. After 2.4.0 was released we observed some issues with how it integrated in the new inspector. For example, clearing out the input wouldn’t work, and if you tried to erase “transparent” it would jump back. Most of Huebert has been rewritten for the 2.4.2 update. Because we were taking the time to rewrite it we looked back over older requests regarding the color picker.

Something that has been requested is that Huebert would remember the exact way you entered a color. If you left the color picker and came back, you would see it converted to RGB format. This is because the old version would always reformat the output value. The benefit with this method is that we can accept values more loosely since we aren’t actually storing the user input.

Moving forward it will simply validate what you’ve input and if it’s a valid CSS color value it will be accepted and remembered. Try entering something like blue and notice how it remembers your choice even after you save. The tradeoff is that for it to be considered valid CSS, the hash symbol is required to notate your value is a hex color code.

To recap, we can either:

  1. Clean loosely entered incoming values because the stored output will be reformatted.
  2. Require valid CSS input and store/remember the exact value.

We wanted to do number 2 originally but ran into some challenges at the time. I do understand how this affects your current workflow, and I’m sorry for the switch up. We will be keeping it this way moving forward since we feel the UX is more predictable when you can come back to your color picker and see exactly what you entered originally instead of it changing.

Let me know if there’s anything else you’d like to chat through here. Thanks so much for your feedback this cycle! We’ve been able to resolve a few issues with your input and they’ll be in the next point release.

1 Like
#5

Hi Alexander,

Completely makes sense – and if it is for the greater good of the product, I’m all for it.

As a side note, it would be nice if he minor changes (like this) that could potentially affect workflow were present in the changelog. I know it might sound stupid but my workflow has been to always type in the hex values off the top of my head intentionally knowing that they’ll be converted to RGB. I can change that part of my workflow but knowing this prior to having an “issue” would be valuable.

I spent a good minute trying to figure out why the colorizer wasn’t accepting my hex inputs (as I’ve always done them) then decided to try including hash (which was just a guess) and sure enough that solved things.

I read the changelog regularly so having that knowledge up front would have been amazing.

Regarding other issues this cycle – glad to help! All part of the growth process and I want to see ThemeCo succeed because that means my business’s product offering succeeds :slight_smile:

Thanks for all you and the team do. Let me know if you need any early beta testers to break things for you guys. More than happy to help.

#6

Hello @DoncoMarketing,

Thanks for the input. To become beta tester please take a look at following article and check the How Can I Get Involved? section.

Thanks.

#7

Thanks Josh! I wanted to reply here personally as well. I definitely appreciate your feedback and you’re right, that’s something that should have been added to the changelog more descriptively. I added some extra information to the 2.4.2 update.

#8

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.