When you try to create several top level block wrappers or containers such as Sections, Divs and Containers, the default behavior is to generate them as a child items instead of duplicating them.
It forces to locate the desired block out of the block above and given that most of the times blocks like sections tend to be useful to contain other elements, it makes no sense to me that this block types do not follow the behavior of the shift-control-D shortcut of simply duplicating the block by default.
This behavior reveals an issue with the navigator, of hiding the block navigator buttons behind the layout interface making it very difficult to interact with them, forcing me to narrow the layout to be able to reach the buttons and it is not good at all for a convenience and workflow.
It makes the navigator pretty clunky and unpractical, being the primary purpose to be helpful and practical I believe.
Please let me know if that is the intended behavior or if I am doing something wrong.
At least for the block generation I think it worth a feature request to make the main container blocks to duplicate instead of creating child elements of them when the block button is clicked.
Don’t know how to insert images but you can take a quick look and see what i talk about.
I have experienced what you are referring to and if I understand correctly you are saying you would like to insert a container block multiple times in a row and subsequent inserted blocks would be added within the same parent as the first item.
I can understand why this is desirable in that particular flow and there is something else to take into consideration.
Currently, one useful behaviour of the way blocks are inserted is - when you insert a container block, it automatically selects the inserted block. This allows you to quickly add child blocks to it. I believe this is the correct default behaviour because it makes sense to highlight the active block and in many cases when inserting a container block it is for the purpose of placing items within it, which this behaviour allows.
The change you propose would require when inserting a container, that its parent remains selected, which while it would enable the particular flow you described, it would not allow the one I described.
Perhaps this could be a nice opportunity for a feature request, something like if we shift click on an item in the inserter it adds it to the parent - this would give you the speed of flow while retaining the current default behaviour. Win-win.
This is a tricky one, because in a deeply nested layout, some blocks in the navigator may be indented so far that they are not visible at all.
Currently the two ways we can work with these are to resize the navigator width or horizontally scroll and I don’t see any other way to address that particular case.
Regarding the action buttons that appear on hover, for visible blocks in the navigator, it may be possible to argue the position of the buttons could be fixed to the right of the visible portion of the block it is in, but when the width of the visible portion of the block is shorter than the width of the buttons, this would still need to overflow somehow. Due to these considerations, I personally think it is implemented in the most practical way for the current navigator interface.
Unfortunately I don’t have any suggestions for a solution but I guess the shift-click to open another parent would be better than nothing.
I consider very useful that the generated container is automatically selected but in the case of the section block I think is unlikely that you need to nest into other section but its more common that you create several sections to build a page but that’s me.
Also, comparisons being so hideous, Just by chance I noticed in a video the way those panels work in Bricks, and it looks more consistent and the flow seems better.
I work with cwicly because I have no time to learn all the tools, because of the components and a few things more so I really want this tool to be better if not the best.
I’m glad more people has brought the navigator matter to consideration, unfortunately it seems its been a while and no action has been taken.
The X button gets hidden in the right or left configuration so often and it looks more as if it was a bug than if it was intended.
Ok, I guess i can live with that, I will dig into that shortcuts list.
Now that mentioned, it seems there is an error with the described shortcut in this documentation page Blocks - Documentation (though I know where to find them in the interface)
I am referring to the feature request posts shared by @StrangeTech, I assume that with what mentioned about the contextual menu and the shortcuts, all this matters have been addressed right?
Would you mind sharing with me the width that you have currently set on your navigator?
Maybe we provide too much liberty in this instance and should not allow resizing the navigator. Maybe force a large width like other builders? Then this would require quite a large number of nested children before encountering what you describe.
So, tell me how to accurately to “set” the navigator’s width, If its even possible.
Though I believe yes, indeed you provide way too much liberty in this case, since the navigator can stretch itself to the end of the window.
Wow! the liberty to break the page if anyone can.
If it was intended, what an awful development choice.
The #1 rule of development should be (and i am no coder): If it can be broken, do not put it there.
Then write a sticky note and put it in the corner of your screen.
Do you mean to a specific pixel size? If so, for what purpose do you need this?
The Navigator is resizable on drag so you can set it to any width you want at any time - if you drag it to the size of the window, you can simply drag resize it smaller again as required.
If there a bug in the resizing that causes the window to to break, that is definitely something worth fixing. I haven’t come across this when using Cwicly, so perhaps you know what steps trigger this and then it can be fixed.
I am personally a big fan of freedom, flexibility and adaptability in a tool and it is one of the things I respect most about Cwicly because it has allowed us to do style and layout tasks quickly and efficiently that were very limited in other tools without imposing opinionated restrictions on how it should be done.
As long as the user is in control and the UI is intuitive, I haven’t come across a downside to providing freedom for the user. There are some cases where it is worthwhile restricting less experienced or non-technical users (such as using roles with custom permissions and the role editor to prevent them from editing templates or information that may negatively affect the site) and many times our clients actually request this, but for optimal development and creativity in development, allowing maximum flexibility in the tool you use is an ideal starting point in my opinion.
BTW, lets not get caught into the idea that you have the best page builder in the existence because as awesome as it is, Its just not.
Now, every builder has its flaws and i think that everyone here is willing to support this tool in hopes for it to be better.
For what I’ve seen, many people have been here for what it look like the early access for the most awesome piece of software that is up to become, but it has flaws, is clear your team work hard and appreciate it but is it has weaknesses, How about “fact check” your ego a bit.
This is not about me, you or your tool, this is about business.
Don’t be the guy who does breakdance with code but has awful marketing and customer relationship skills.
To sum it up, the growth of this tool depends not on your ability to develop godly pieces of code but in the people you are able to attract and connect, Those people are going to bring you the business and it does not matter where they come from.
Well it comes from the question that @Louis made about sharing the width i have set for my navigator, I have no particular interests on setting a specific width.
You try it!, if by chance or accident you extend the navigator’s width of the end of the window (Which seems purposeless and looks awful) its there, and is not the best experience to work with the navigator and I believe more people have pointed out before me. probably other builders do it better probably or not.
Moving blocks, nesting, jumping up and down while I move them… so there are workarounds but there is not enough documentation for them and many people struggle, lets not say its optimized for the most efficient workflow.
Again, I did not use the word liberty, I was sick of tools like elementor that tells you that you can create whatever you want but its not truth, so I am all for it All i said here was, there are some issues with the navigator and the shortcuts do not solve them all, at least for me.
And no, in my humble opinion, the cwicly UI is Not intuitive, the learning curve is very steep and the documentation, coupled with the pre-made templates in the cloud library, does not help.
Just do not assume that every thing is perfect and that i am wrong when i see any flaw.
I often try to use material from the cloud lib, and it turns out it uses the legacy or deprecated code…
I will probably take the time to record, document, report and edit every type of issue i experience while I try to learn the tool, but there is just not enough time.
I see, I believe he may have been asking to get more context, so he could determine better in what way it was working/not working for you, although I won’t speak on his behalf.
I am not sure why at this point you assumed I hadn’t tried it, but for clarities sake, I have.
Since there is a sensible default in place and currently, the only way to change the width is by dragging, it seems unlikely to me that any user would somehow find themselves with a full width navigator while not knowing how that happened.
Also, since it is so easy to resize using dragging, I don’t see how it can be made more discoverable or intuitive to the user. Given most resizable sidebars work this way as a standard convention, if anyone familiar with modern UI wanted to change the width, they would most likely naturally attempt to drag it to resize.
Possibly the only case I could see, is in the scenario where a user accidentally resizes the responsive container in the canvas rather than the navigator (or vice versa), although this is an edge case (pun intended).
To be 100% clear, I am not claiming the Navigator is perfect, there is always room for improvements, new features and optimisations. That said, Cwicly have been refining this over many iterations based on user feedback and it is already much better than it has ever been.
Recent examples:
(one you are very familiar with)
For my day-to-day usage, there is only one major feature lacking in the Navigator at this stage, which is multiple selection. Once that is in place, everything else that can be added will be a useful enhancement.
And since the recent fixes, there is only one slightly annoying usability issue left, which is regarding the drag preview being incorrectly aligned when moving an item. This may be related to what you were mentioning and I will be raising this as a bug ASAP.
I appreciate that @Louis used the word first, I was just responding to it in kind.
Agreed!
I think Cwicly’s UI has many very intuitive and well thought out aspects and there may still be a few areas where this is not yet the case. By sharing your experiences with these I have every confidence their team will move things in the right direction.
No assumptions here, it isn’t a battle of right/wrong, your feedback is valuable and necessary. The more perspectives and viewpoints that are introduced, the more the UI can be refined and the better the tool can become for all of us.
My primary goals in these conversations is to help facilitate the above by isolating the crux of the issues and to help separate any already fixed issues and already included features from significant new points that the Cwicly team can then focus on including.
We are all passionate about what we want/need and I believe the best way for all of us to get more is by finding common ground and focusing on Win-Win outcomes.
