Cwicly status button (hide\show)

[DenisKozeev]

Hi everyone)

Can you tell me about the hide\show status button (grey\green indicator next to the class)?

When I insert a paragraph, the indicator is grey and the class is in the

inspector. If I click on the indicator, the class becomes . Everything makes sense here.

But if I insert a paragraph and change its value, the class also becomes and the indicator doesn’t light up.

Question, is it me who can’t understand the logic or is it a bug?

[Araminta]

Hi @DenisKozeev,

Welcome to the community
Thank you for bringing this up!

@DenisKozeev

But if I insert a paragraph and change its value, the class also becomes and the indicator doesn’t light up.

To clarify, I’d like to confirm that this is the current intended behavior.

Our decision is not to automatically enforce the class, even if it’s modified, as we believe a user might want the flexibility to modify it without forcing the class, especially when no styles have been attached, in order to maintain a clean output.

The behavior you’ve described is what we’ve implemented for the ID.
We assume that when a user modifies an ID, they likely intend for it to be activated.

We are open to hearing your thoughts and opinions on this choice, and we welcome further discussion on the matter.

Adding to discussion.

[DenisKozeev]

Thanks for such a quick response)

It’s probably convenient, haven’t realised it yet. It just doesn’t feel logical (maybe not used to it). And I want to understand the logic of how it works.

If I have described the logic correctly and it takes some getting used to, then ok.

It seems more logical to me that if I change the values of a class, I probably activate it, and it is logical to see the class switched on (it is immediately clear that I made changes to it, it is important to see when working with a large number of blocks).

But maybe I just haven’t got used to it in a couple of days after Webflow and that’s why I feel uncomfortable. Probably your team chose this logic for a reason and I just didn’t catch it).

[StrangeTech]

Hi @DenisKozeev,

Several people have said the same thing to me and I suggested the following potential solution in the original feature request:

Automatically make ID/Class active when typing in new value

Understood, this was something we also thought of - currently the blue dot is only shown active when the user toggles it. We thought perhaps it could be shown in a different colour if the class is implicitly active (i.e. if Cwicly has detected it is needed based on having active styles for the block). Currently, it not being shown as active, even though the class is being added to the block confused a few people in our team initially.

Also, you may be interested in this feature request:

Add active class/id visualisation to new class/id toggle field

With the latest UI changes for classes/ids by default you can’t see the ID or it’s toggled state. @Louis, it will be very helpful to make the ID a little bit more discoverable and perhaps find a way to show it above the class (small) if it has been enabled (and vice versa). This only needs to be shown if the class/id is active. Example: [Screenshot 2023-06-02 at 16.13.03] This will help with issues such as the one discussed here: Thanks!

[StrangeTech]

For the sake of keeping things clean I have added a new feature request:

Show class toggle as active when block styles have been added

Following on from this thread: And this one highlighting the same thing: Currently, the class active toggle (blue dot) is not being shown as active, even though the class is being added to the block, which confused a few people in our team initially. For clarity, we are requesting that the dot can be highlighted in a different colour if the class is implicitly active (i.e. if Cwicly has detected it is needed based on having active styles for the block). This doesn’t affect functionality …

[Marius]

@StrangeTech

Also, you may be interested in this feature request:

With the latest UI changes for classes/ids by default you can’t see the ID or it’s toggled state. @Louis, it will be very helpful to make the ID a little bit more discoverable and perhaps find a way to show it above the class (small) if it has been enabled (and vice versa). This only needs to be shown if the class/id is active. Example: [Screenshot 2023-06-02 at 16.13.03] This will help with issues such as the one discussed here: Thanks!

I find it quite surprising that this situation hasn’t been addressed to date, especially since there have been quite a few posts in that regard in the past. And I’m not even talking about all the user issues when the ID isn’t toggled.

I appreciate the ongoing improvement process and progress, and it’s fine to throw something in and wait for feedback (which was provided sufficiently in the past half year, imo).
But not addressing newly introduced flaws in a reasonable amount of time is a bit unfortunate.

Users, because the ID field is hidden,

• don’t know whether a block ID is toggled on or off
• can’t see the ID initially (in case it’s toggled on)
• in many cases don’t even know an ID input exists

These few points create a considerable number of problems, not only in terms of workflow.
It is not something minor, it’s a real issue.

I like the changes that were made.
The general approach and implementation of the class/ID area is amazing, really.
It shouldn’t be changed significantly, only some minor refinement is required.
It’s just the lack of accessible/visible info when required.

[StrangeTech]

@Marius

Users, because the ID field is hidden,

• don’t know whether a block ID is toggled on or off
• can’t see the ID initially (in case it’s toggled on)
• in many cases don’t even know an ID input exists

These few points create a considerable number of problems, not only in terms of workflow.
It is not something minor, it’s a real issue.

I definitely agree with this. Every developer I have introduced to Cwicly without exception has hit this exact issue at least once and needed a quick intro to the ID field.

Finding the ID field is not intuitive at the moment.

@Marius

I find it quite surprising that this situation hasn’t been addressed to date

I concur with this, primarily because these types of issues are regularly addressed with lightning speed by the Cwicly team.

While IDs are less of a priority in terms of general styling (due to the fact that block classes are used for that), the interactions side is where this has been presenting the most issues.

I would also still like to see this feature implemented as an optional setting:

Maintain the toggle state of ID/Class visibility when selecting blocks

Currently whenever you click to a different block, the class/id panel switches back to class mode. If you are quickly adding IDs to multiple blocks this can be frustrating. It will be great to be able to maintain the last toggled state when selecting a new block.

[DenisKozeev]

I don’t have any questions about the hidden ID field. You don’t see it, but once you know where it is, there are no questions about it. If you read the manual, you will definitely see where this field is. Besides, ID is not used that often. And when you need it, you know exactly where it is and it’s pretty close. In the same webflow it is hidden deeper, and there are no problems with it.

[Marius]

@DenisKozeev

I don’t have any questions about the hidden ID field.

Since this is a related topic, I think it’s fine to bring that in - especially since this has been tagged as discussion. It’s actually the very same topic since it’s directly linked inside the UI.

I wouldn’t have added any opinion here otherwise, as this is just another post about the same topic which has been discussed several times already.

@DenisKozeev

You don’t see it, but once you know where it is, there are no questions about it. If you read the manual, you will definitely see where this field is.

I agree with this but one needs to consider users feedback too.
A little hint which, if possible, could be implemented in a smart way wouldn’t hurt.
If you ask me, leave it as it is. Clean and simple.

@DenisKozeev

Besides, ID is not used that often.

Currently, this is the case. This might change in the future when a user decides to style ID’s instead or classes.
Still, when an ID is used, I want to know that and a tiny visual indicator would be sufficient and I can’t find a reason here why this shouldn’t be a thing.

@DenisKozeev

In the same webflow it is hidden deeper, and there are no problems with it.

I appreciate that you have no problem with that.
If webflow wouldn’t have any flaws, I’d consider to add some thoughts.
One thing though. No, it’s not hidden deeper there. It can’t be hidden deeper than literally hiding it.