1.4.2-beta Feedback

Hi @Louis,

Thank you for releasing the beta, I have a lot of feedback and may not be able to include all of it in this post, I will try to make it as concise as possible and I can create new feature requests / bug reports if needed for the individual points.

Feedback:

  1. Relative Styling:
    a) On other tabs that show the modified icon (blue dot), when you hover it, it turns into an X icon - this doesn’t happen for the relative styles.
    b) You cannot copy/paste all/multiple relative styles (I know this is an existing missing feature, but worth mentioning)
  2. Top/Right/Bottom/Left fields: The new UI for these is great, but you can no longer navigate via the keyboard between fields. If you tab to the field, there is no way to trigger the modal to show. When the modal is shown for one value (after clicking on the field), you cannot close the dialog except with the mouse. How about the Escape key?
  3. The three dot menu on each panel to configure the fields shown is a nice touch - being able to configure this in the Role Editor is the only way to make this useful for us. Having to configure this on a per user basis by logging in to that user is not an option for sites with lots of editors or for sites where the client creates their own user accounts. We need to be able to pre-configure helpful defaults for specific types of user.
  4. Global styles:
    a) There is no way to clear/reset/copy all/paste all global styles on a per panel or per site basis. Because copy/pasting multiple is available prior to the beta, this is a regression in features.
    b) Copy pasting existing headings/tags does not overwrite them, it adds duplicates. This may be a feature, not a bug, (if you want to quickly duplicate and add additional classes for example) but there is currently no way to clear all existing global styles from a particular panel, so this adds additional work if you just want to copy from one site to another

    c) For blocks, I’m just wondering about the reason for the limited number of blocks in the selection list and whether this list will be added to.
    Screenshot 2024-08-27 at 21.03.47
    d) For inputs, I definitely miss the ease of being able to quickly add the type of input from a list - this was a really time-saving feature and added value. Perhaps this can be restored in the new system:

Noteworthy mentions:

  1. Overall, the new global styling panel is excellent. So much more flexible and full-featured.
  2. Even though I personally miss the icons, the simplification of the UI and removal of the division of tabs is definitely progress and will be a lot more user friendly for non-technical/new users.
  3. The quick search property filtering is an excellent, really useful addition and works perfectly.
3 Likes

Unless deleting RS items do not support the undo action, this shouldn’t be a thing imo.
I also realized that the blue dot might not be in the right spot. At least when it also has the ability to delete the corresponding styles.
Accidentally clicking it happened too much for my liking.

Maybe a right click context menu, or something else, is a more suitable option to explore here.


Good points here.
Scrubbing without opening the Popover should also still be a thing, imo.


Will there be default options, too?
Not sure if I got it right, but shouldn’t the panel options work per block basis and not globally, whereas the defaults represent the global behavior?


Fully agree. So powerful and should also be ready for any future enhancements.


Not specifically the icons imo, it’s just the tabbed naviagtion.
Accordion with jumping elements and long lists isn’t just it :smiling_face_with_tear:

Removing the sub-tabs, turning them into lists, like we have now, but retaining the main tabs would’ve been best of both worlds.
Merging some areas (for example transforms with effects) and moving some stuff to the advanced tab (like RS and Pseudos), would’ve also allowed a single tab row for even simpler navigation.
Seeing the disadvantages of the panel navigation in action makes me a bit sad tbh.

Maybe there will be a time when considering a tabbed navigation as an optional feature.
After checking things, it shouldn’t bee too hard to include that.
But that shouldn’t probably even thought about until the current process has been completed and everything is maxed out polished and optimized.


It’s great, indeed!
Maybe some refinements, when time allows? But certainly not necessary at all!

image


New logic here is great, much more clear and makes sense now.

image


These little UI improvements are awesome, too!

image


Remove Tailwind from Panel Options, when TW is disabled in the Cwicly settings.
Changes already made should be preserved.


General Options for the Design Panel, like have for the Navigator, such as:

  • Allow opening all, not only one at the time
  • Open/close all (toggle)

Maybe something like a toggle (settings/gear icon) for quick access next to the property search.


Ability to remove Tilt and Separators via Panel options as a whole (no granular options needed, doesn’t make sense here).

image


Not exactly sure about this and I would appreciate more opinions here.
Would it make sense to move the Pseudos and Relative Styling areas to the Advanced tab? I mean from the workflow perspective, etc.
Are there any downsides?

Custom selectors and pseudos are not a design thing, and logically should be part of the Advanced tab. But there’s more to consider, so I’m asking what other users think here.


I also think, and this is something which is in my mind for a long time, but didn’t mind too much because of the space-saving tabbed navigation, but for my liking, the inputs are too tall.

image

Visually, it’s a bit more appealing with all the nice padding, etc.
But shouldn’t play a role inside an efficient working environment.

Basically same goes for quick inserter.
At least an optional compact mode could be implemented:

Any thoughts are appreciated here, too!


I’ll get straight to the point.
Webflow in this area just nails it, and I’ve seen many other tools adopted this as well.

image

You kinda started this process here already:

image
image

Merge inner and outer shadows, great opportunity to implement other stuff (also text shadow, etc.) easily, thanks to the simplified and efficient UI.
Include the transforms to the effects, because with this approach, it wouldn’t make any more sense.
Make the items draggable, which is also essential for filters.

There is such a significant difference:

image

Displaying all these properties when not needed, just doesn’t make sense
Other areas could be optimizes as well, like:

image

(but which would require something like recently discussed).

Not trying to change Cwicly’s identity here, just throwing in some thoughts how to improve things, as the general accordion navigation, like we know it from other builders, is awful - and we all know that.

The ultimate goal should be to have an UI available which you can still work with nicely and efficiently, when all panels are opened at the same time.


I hope you don’t mind when sharing some more general feedback, which is not specifically related to the beta.

image

These could receive some modern overhaul, to fit into the overall UI.
Also in terms of UX (dissmiss link / close icon, etc.)


Could we reduce the Attibutes’ UI a bit? Using ACF, it just gets worse.

image

When using multiple attributes, it’s not a good experience at all.
Maybe only displaying the attribute and value in the panel, and everything else the user sets up inside a modal, like:

image

Or maybe using the dynamic inserter?

image


Some small things:

image

Spacing should be Letter Spacing, as we also have Word Spacing, to streamline the labels.

Border (same goes for Outline) should be labeled as Color instead.


For my liking, for the purpose to just set a simple border, this takes too much space:

image

Especially, as in most cases, radius and width only needs a single value.
Somehow, this could be cut in half, with some UI elements expanding when granular styling is required (different widths and radius).
Similar things with Outline.

I think there is just room for overall improvement (in whichever way) and I think you got my point without going through everything in detail.


image

Thoughts?


I know Webflow does it that way, but not a big fan tbh, but that’s rather an individual thing.
All these items, also in the block editor, like RS, border, transitions, etc, could receive some contrast to the background color.
It lacks a bit in hierarchy.

image


There are multiple instances where the term “Duration” is unclear.
I think this has been brought up somewhere else in the past.
This needs to be streamlined, by at least add the unit, like (s) or (ms) or giving the user the ability to specify the unit by removing the limiting inputs that only accept specific values.

The limiting inputs, which unfortunately are still a thing in several instances, should be finally addressed, too. This is part of the basic builder functionality which hasn’t been focused on for too long.


What I hope to see with the initial version on the WP repository, is a UI overhaul of the Role Editor and Settings. Some polish and a better overview (organizing this immense number of available options) would be appreciated, also to align with the modern design of the builder and themer.


Again, sorry for being a bit more general.
Just added some things to consider for the current and ongoing process.

2 Likes

I’m guessing the opacity field is shown here as “trans” could be the start of “transparency”, which some people may search for.

This is great. The reset button is much requested and very welcome.

@Louis What exactly is the state for the show/hide? If it is highlighted blue, does this mean it shown or hidden? I’ve noticed that when it is highlighted, we see the white modified dot, but when it is not highlighted we don’t. This seems to work opposite to how it used to, in the sense that if you manually chose to show the class for the block, then it was highlighted with the additional blue dot, but regardless, if you modified the style properties it would show the white modified dot. This seems to be a bug to me.

This also very much shows the way forward for multiple backgrounds.

The same UI strategy can be used with the current display of background panel (separating the overlay of course).

2 Likes

I have the feeling that you are answering your own question here.
That’s exactly how it’s supposed to work, no?

Well, I think there’s a bit of change in the logic to make things more clear.
If you apply a rule to your block, the option to toggle the class manually, is gone.
This removes the confusion to the previous iteration, where the user could still toggle it (without any effect, as the class was applied anyway), even when styles are applied and the class is required.

So now, you can either toggle it manually, if no styles are applied, which is the sole purpose of doing so, as it’s added automatically when at least one style is applied.

Exactly.
This is the way for all properties that allow multiple instances, and can also either simplify existing properties, like box-shadow or enhance existing properties, like text-shadow.

You are certainly right. Transparency and text transform it is (the missing label confused me lol, maybe also a topic to address, as missing labels are a thing in some areas).
From some further testing, it worked perfectly. Having a property search available is so good and will certainly affect my workflow.
They’ve done an amazing job here.
I want to add that I find the position of the search a good choice. Probably no better spot available.

What I find important though is that we are able to find exact CSS properties, like

  • font-size
  • background-repeat

which isn’t possible currently.

3 Likes

So, I agree that if it works this way, then that is indeed an improvement. Unfortunately, it didn’t work that way on the first site I tested it on:

I added style properties and no modified dot was shown:
Screenshot 2024-08-28 at 22.33.41

Only when I toggle the show/hide eye icon to be highlighted blue is the white modified dot shown:
Screenshot 2024-08-28 at 22.33.49

This is contrary to what you described and what I was expecting.

I have since tested on other instances and I can confirm this only happens on one of our test sites (which also has other issues with the beta), so I am not that concerned.

On the working instances it works exactly as you described and I agree, it is great and a big usability improvement. :+1:

Yes, spot on. Making the user experience consistent while also enhancing the capabilities of Cwicly to allow users to do more with styles. Definitive Win-Win.

1 Like

Definitely a good plan! :brain:

This is also extremely important because the way the filters are applied visually can change based on the order they are specified. :brain:

Hello @StrangeTech,

Thanks for the detailed feedback, really appreciated!

I’ll be going through your points one by one.

Have you tried using the Role Editor for this? Or is there something not working out when you set it up through the Role Editor?

Hi @Louis,

For some reason I didn’t see it the first time I checked, was probably caching or temporary blindness! Thank you for adding this :smile:

Here are the results of my testing:

  1. When toggling individual fields on and off in the role editor, this works correctly in the inspector but is not reflected in the toggle panel for existing users created before the change or new users created after the change for a specific role (I tested Administrator and Editor). It always seems to display the default toggle values until the user edits them, not the ones from the role editor.


  2. When toggling visibility of a panel group this works perfectly


Now all we need are for these other settings to get the same treatment and Cwicly will be super configurable and usable for our clients:

  1. Navigator settings
  2. Editor settings

@Louis, Confirming that this was caused by the Local Fonts error and is now fixed!

1 Like

Hey @Louis.
Happy to see you considered some suggestions to be useful and already implemented some in the new beta :partying_face:

Nice to see this, which also helps a lot in these scenarios:

image

I have two points which could be considered.
The default and hover bg color (and active bg color in the globals) are almost indistinguishable from each other now.

For example, here the H4 is hovered/active:

image

In the block inspector, the active indicator could also be added.
This helps when multiple items are available, like transitions, RS, etc.

The color component makes it much easier to quickly find the active item than finding the matching modal heading/content and item label/content.


I would like to emphasize once again how good the new Global Elements area is.
Conceptually the best (custom) selector manager I have ever seen.
The overall modern, clean/clear UI shows its true strength here.
It just looks so pleasing and is a great experience working with it.

The dedicated “Edit Rules” modal is an excellent idea btw. for quite a few reasons :+1:

Down the road, I would like to see a search and some filter functionality here.
Something like folders, tags, etc.
I’m not sure, but it may have already been mentioned that this is in the pipeline.


While I was looking for a specific information in the previous live, I’ve just seen that the Pseudos and Relative Styling panels were not available in the Design tab at that time.
Now I’m wondering whether they just weren’t finished yet or whether you might have experimented a little internally with the placement.
Just a bit curious, as I was addressing this exact point in my first post above.

1 Like

Thanks for the enthusiasm about the Global Elements, @Marius! It’s always been an area that has bothered me.
Although I now see, with this new setup, some overlapping with Global Classes (Global Classes and Stylesheets will have a rework) that I might explore further down the line.

Great point, thanks!
We did have a more striking differentiation and settled with what does now seem too subtle.

Great observation! We were trying a few different setups, and did have them in the Advanced tab at one stage.

For Pseudos I believe it makes sense and can’t see anything that really goes against placing it in the Advanced tab.

As for Relative Styles, one downside that came up pretty quickly was the switching between editing RS properties and normal design properties.
Currently, when you exit RS editing, you’re switched back to the Design tab with the RS panel open. You can quickly apply or view styles you’ve applied to the block/global class you’re editing.
If you move RS to the Advanced tab, you’re having to switch between both tabs, even if you’re not wanting to edit the block/global class currently selected.

3 Likes

Thanks for sharing your thoughts here @Louis, appreciate it!

Agreed. There were also a lot of discussions in that regard.
This new approach solves so many issues and ambiguities at once.

That’s indeed a good point!
Curious how this gets addressed, and waiting patiently to see what you come up with.

I also agree, it is like the same category in which attributes belong.
So the Advanced tab would be the perfect fit.

Practical experience is exactly what I was looking for. Thanks for that!

I think this is a question of perspective/workflow and the argument is not conclusive due to the fact that the Relative Styling items are accessible through the class overview, which is available independently of the active tab.

If you differentiate creation and management (edit, delete, duplicate, etc.) with the actual styling of the selector, it’s a completely different story.

Also, if the removed option to create Relative Styles from the class overview comes back at some point, and a context menu is introduced to manage all aspects, the arguments for it being in the Design tab will become even fewer.

Nevertheless, I do agree with you that Relative Styling in the Design tab makes probably the most sense if you look at it as a whole. At least in the current state of Cwicly.

Confirming that this has been added and appears to be working perfectly in 1.4.2-beta3. Thank you @Louis!

1 Like

Some more general minor things…

Just want to add this, as I can’t edit my previous post anymore:

image


Is it planned to make the Primary tab accessible for Relative Styling editing for specific blocks or when applicable?
Currently, it does nothing other than closing the Relative Styling panel, which is not that intuitive.

image


Could the active tab being remembered?

image

For Block and Stylesheet, this works just fine. But not for Globals.


Some small UI proposals:

Following the naming convention in the builder (Background - *) and the CSS properties.
image

There were also users in the past who confused it with a parallax effect option.


Unify the edit experience:

image

Setting the “Edit Rules” icon apart from the Free-Form icon:

image


Using the same icon for


and ofc all other instances.


image

Any thoughts?
The current pseudos (hover, active, etc.) could come as default, but these could be controlled globally, so the user can decide what to display by default and add others on demand per block basis.

1 Like

Agree with all of these points. :+1:

1 Like

Sorry for barging in at the last minute.

Here’s my feedback about the spacing UI: