-
Hi there,
I just wrote a topic moreless related to this and I don’t want to flood the forum with more but the more I work with 2.0 the more I realize how essential it is to tackle certain things. And since I read Tom asking for feedback here goes something a little bit more specific.
Overall, I feel like you are trying to offer as many options as possible, without contemplating at what cost (from a user perspective). There has to be a balance between this and user friendliness as well as optimizing workflow. There’s a lot of potential and good ideas but I think SIMPLIFYING is a must. My two cents on some things:
“LAYOUT” tab:
1- Make it so that it only shows the options regarding the display option the user has chosen. Example:
If I choose “FLEX” : the “flex layout” should be opened automatically without having us to click to show or hide yet another inner tab (this already saves a couple of clicks everytime we go back to this).
Also, if I had chosen “FLEX”, the options “grid layout” and “floats” should just disappear. Not only are they useless, but it only bloats the interface and might raise doubts as to what its use is on unexperienced users.
To sum up, I would get rid of these inner tabs and automatically show or hide them based on the display option. Fewer clicks, cleaner and more intuitive.2- “Container Queries”. Is this really something useful? If it was up to me I would put it under a “more tab”. I think it is a very secondary option to be honest.
3- Also, under “display” you have the “list item” option but then another tab for “LISTS” outside the “LAYOUT” tab, why so overly complicated? make it so that when you choose the “list item” option on the layout, it shows the “LIST” tab options inside the layout tab. In the “LISTS” tab you even say “List properties will not apply unless the element’s display property is set to list-item”. So why even show this tab then if I’m using another display? simplify. Only show what is used.
“LISTS” tab:
1- As I just said, it is unnecessary and bloats the interface. Display it inside the “layout” tab ONLY when “list-item” is chosen. I’d just get rid of this tab.
“BACKGROUNDS” tab:
Check the image I enclose. My suggestions:
a) Show a circle -or square, whatever- with the colors used (in case of gradient) so that we get a preview on what is going on
b) Regarding the information next to it, please do not display css code in there, make it a little bit easier on the user. Just show the type of background we’re using: “image”, “linear-gradient” or “superposition”.
“MEDIA” tab:
1- Ok, what is this even? don’t we have all the options on the “BACKGROUNDS” tab when we add an image as a background? I’m genuinely asking, I don’t understand its use. Again, to me it feels like it just bloats the interface and raises questions. It feels like quite an advanced feature for very very specific cases, and so for that I don’t think it belongs on a level 1 hierarchy, I would put it under a “MORE” or “ADVANCED” tab.
“MORE” tab:
3- Bring back the “hide toogle” please. No matter how you want to explain the global style thing, that is super counter-intuitive.
“COLORS” tab:
1- BRING THIS BACK pleeeeease. To have all colors -or most of them- in one tab (backgrounds, typography, etc.) was way cleaner, fewer clicks, more intuitive and from a design perspective, it allowed you to see everything from the get-go and make quick changes. It is baffling to me that right now, to change something as simple as a hover color now we have to go to the hover tab, click on the element and again on the color.
—
There’s a lot more (example: the use of shapes is now SUPER confusing, the use of advanced features like :after and :before feel like super hidden) but maybe it would be worth for another thread, and I don’t want to keep it too long.
Want to hear your view on these things, because to me, these are very very essential.
-
Hi Eduardo
again, I would like to thank you for taking the time to give such great feedback,.
All of these ideas we will take on board to see how we can improve.
Ill try and review what I can here.Conditionally showing properties
There are some complications with conditionally displaying properties. For one we don’t want to add extra logic to the UI, aside from the overhead it ( as proven in the past ) can could result in hidden properties.
There are instances where the context of properties are unknown such as adding a Flex Box as a child of a CSS Grid. Or working with local settings for a display property that is set on a global style.But your feedback is valuable and I will take this on board within our review.
What I would recommend here is to use the Search option so you can quickly find and display just the properties you want to work with.
Container Queries – good point ill put it up for review.
Lists, same as point 1. And those should also be accessible when the HTML tag is set a UL,
Background tab
I totally agree and thank you for the mockup, I think that should be doable.Media Tab
this is currently reserved for the Image Block object settings. In the future it will provide properties for other media typesHide Toggles.
We have this under review for some potential shortcuts , I’ll add your vote to this.
Our current advice is to build Global Styles for this function. The Display property has thenonevalue which you can use for this. Its a more versatile solution.Colors
You will be happy to hear that this will be addressed in the next release.Shapes
We have introduced a lot more flexibility like you now have full control over the shapes position etc. Let us know how we can improve.Pseudo Elements
We need a separate “place” for creating them. As I agree, they are currently tough to work with. Appreciate your input on this.Again I want to thank your for your valuable feedback.
-
Thanks for your feedback again David.
“There are instances where the context of properties are unknown such as adding a Flex Box as a child of a CSS Grid.” — The way I see it is that it should only affect said object but not interfere with child objects. Following your example: if you have a flex child inside a CSS Grid, that shouldn’t be a problem: you choose CSS Grid on the layout dropdown in the parent object, and once you create a child object inside it you still get to choose whaver layout you want from the dropdown.
What I’m saying is: once you’ve chosen the layout you want (be it Grid, Flex, etc.) that all the options not belonging to that option should be hidden, but only affecting that particular object.
If hiding stuff is not your cup of tea, another approach would be to make it VERY VISUALLY CLEAR which inner tabs are affected by our option and which are not. Example: if I choose “flex” in the layout dropdown menu, put “float” and “css grid” inner tabs at 30% opacity, or paint them a much lighter grey. In the end, my main concern is to make things intuitive because I provide support for over 40 websites working with Generateblocks and I know first-hand how massively confusing this can be to the average user. It was to me the first time I saw it.
“Lists, and those should also be accessible when the HTML tag is set a UL” — Great then! then do so, make it appear when certain conditions are met. My point being is that having all options available at all times -even whey they don’t make sense to have them at display- only adds noise, and if this is a tool to improve workflow and make things intuitive, then I feel like it kind of defeats the purpose.
Also, maybe it’s just me but everything in the LIST tab is only used in very particular cases right? do you think it deserves the same space and importance as “sizing”, “spacing” or “tipography”? that’s why I suggested to have it under another tab, for instance “layout” (which again, unless you choose “list-item” on the layout the “list” options wouldn’t even work lol so what’s the point of putting it somewhere else?).
“What I would recommend here is to use the Search option so you can quickly find and display just the properties you want to work with.” — This sounds good on the paper, but there is nothing “quick” when having to type into a search input. Quick and optimized in terms of workflow is having things at face-value and intuitively understanding what is affecting my design and what not.
Media Tab this is currently reserved for the Image Block object settings. In the future it will provide properties for other media types — you mean to say that “media tab” only displays on image block? because the media tab shows in all sorts of blocks to me, it is in the container, text and title. That’s why I don’t understand what is doing there.
Regarding shapes it is a little bit more complex, but it is super confusing how they work with containers. So first you need to choose the shape inside the container options but then if you want to edit the shape it has its own div outside the container? the first time I saw it I even thought it was a bug.
Hide Toggles and Colors Nice to hear 🙂
Pseudo Elements — undestandibly it is not easy, and I don’t think it should be the focus right now. This is definetely something only more advanced users will use, and I think the work should be targeting more standard users.
-
The GenerateBlocks inspector controls are super advanced, the system was built so it would work in any context, including blocks, global styles, complex selectors, pseudo states and under any responsive breakpoint. They are also portable so you can expect to see those same controls being used elsewhere in the future.
This gives GenerateBlocks an unprecedented level of flexibility. Our challenge is to get the UI right and provide users of all ability to reach their particular needs. That is why your feedback is invaluable and very much appreciated, and all your points are understood and taken on board.
That said, there are technical challenges for what you propose.
To show properties contextually requires a lot of logic; is it a block?, what is its HTML tag? is it a block selector?, is it inserting a style, is it a global style?, or a global style selector?, is it any of the above under a pseudo state?, or in a responsive view? etc. That’s before assessing each of the conditional properties.It’s also risks an existing property value to become hidden, leading to less transparency and confusion. Similar logic to this did exactly that in previous versions blocking users from accessing border styles or flex options in certain conditions.
Aside from those challenges and pitfalls, the logic comes with a super high overhead in the editor and it would become a constant condition to analyse as we further develop the product. In short what seems simple on paper is a technical nightmare 🙂
The other main concern is the UI inconsistencies. For many users an inconsistent interface would pose a bigger problem then having obsolete settings
So I hear your concerns and have taken them onboard. We do have plans for improvements and in the short term they are as I have covered here;
https://generate.support/topic/various-questions-and-issues-with-2-0/#post-156564
Going forward I am hopeful to bring you more updates on this.
The Shape Block, yes I can imagine it was a shock at first, and we are looking at how we can reconnect the blocks so the container has greater oversight of the shapes within it.
-
I get it, it’s easier said than done (I’m talking about the technical challenges). I can always get by technically speaking -or even go back to css, despite the drawbacks in workflow- but my clients are my main concern. I am certain about how overwhelming this will be to them, especially the “layout” tab, which to me is one of the biggest flops in terms of UI. But I’m positive and hopeful that you will find a workaround.
Also, please respond this thing on my previous message (just to make sure it is not a bug):
“Media Tab this is currently reserved for the Image Block object settings. In the future it will provide properties for other media types — you mean to say that “media tab” only displays on image block? because the media tab shows in all sorts of blocks to me, it is in the container, text and title. That’s why I don’t understand what is doing there.”
Thanks!
-
The Media panel, to confirm it’s not a bug.
Above I explained the technical issues and risks of conditionally displaying style properties.
What perhaps I didn’t explain is the real advantages of having them always displayed, even if they seem irrelevant in the context of the currently selected block.With the use of the CSS Selectors, you can style HTML within a blocks content, for example an image inside a Container or more complex a dynamic inline image inside a Text Block.
- You must be logged in to reply to this topic.