I think this should only be the case when the changes would be immense (which I do not hope). Maintaining the old Design is an indication that the changes were too big (and maybe targeting a different target group) or that there are now serious downsides / disadvantages. I hope a new designed Pinegrow would be better for both new and experienced users.
I understand what youāre saying but I do not agree. I think it should absolutely be the case. Some people just do not accept new, even if itās only marginal. That and people want to move over in their own time rather than being forced suddenly. I think at least 3 month crossover period.
I think Pinegrow get a lot of things right so Iām anticipating a new look/feel while making advancements in only a few areas. This is my hope as well but I donāt want to stifle creativity and welcome any well-researched departures away from the current UX even if it takes time to come around to it and for this, a nice crossover period would be great!
When someone wants to keep the old UI, he or she is not forced to install the new version. Itās always a question of resources in the Pinegrow Team. Users could still download and use Pinegrow 2 if they want.
A fair pont @matjaz made on the flexibility of the UI had me toying with the idea of only presenting options based on display properties. Some people like to create the flex child properties before the parent as an example. This in some peoples eyes would limit flexibility.
I think a middle ground could be met somewhere and I would hypothesise that starting with an adaptable UI would probably be welcome by most. I have resorted to using the icons more though, even though It gets a bit hazy with transform/flex/gridā¦ (cc: @matjaz on that one)
Personally, I wouldnāt risk booting people out of new features. Iām digging my heels in on the option to allow people the option to adjust to a new UI in their own time whilst not missing out on any other improvements that are made. I guess itās up to the PG team ultimately.
Great to see the active discussion here Thanks all!
The goal of the redesign is not to disturb the existing structure and workflow. So, needing to have the old design available as an option would mean we failed at that.
We will use Pinegrow Online to test all changes with you before we push anything to the production apps.
The following point is great to illustrate the somewhat complex requirements of a general purpose CSS editor:
At first glance it makes perfect sense to just show flex controls if display flex is set.
.articles {
display: flex;
//show flex controls when editing this rule
}
.hero {
//don't show flex controls when editing this rule
}
Now, imagine that display: flex is set with a Bootstrap or Tailwind utility class, not the .article rule:
<div class="articles display-flex">...</div>
.articles {
text-align: left;
}
Should we show Flex controls when .articles is selected or not?
We could check the computed style of the selected element, and if Flex is set there, show the flex controls. But what if flex is set with a media query that is not active at that size, or with JavaScript code that didnāt run yet?
What if you are editing a CSS rule that is not active on the selected element and we have no way to compute the style and figure our weather flex is set or not?
Context specific controls would be nice in 90% of cases, but cause problems in other situations. IMO, the only solution is to have a switch that can toggle this function (Show only relevant properties ON/OFF).
Maybe Itās enough to just blend the flex properties out like in a closed accordion? Like the visual editor uses such accordions to order (and hide) options right now
Ok so if itās just UI, Iām less concerned about crossover.
I do think thereās opportunity for some blue sky thinking on UX but maybe this is beyond the scope of the task. As some specific examples, I like the way Figma (and now Framer) do their flex layoutā¦
I also like the way Webflow does itās padding/margin
They compress/simplify the UI and cognitive effort for me.
And generally I like the emphasis on iconography over text which I think is PG downfall.
Iād also would like to see more Icons than text in the UI. It makes the user find things faster and new users with less coding skills can understand the effect of e.g. a css property even better. Displaying text on hover is a must then.
Hi @matjaz ,
Only use Pinegrow for rapid HTML prototyping with Bootstrap and creating Interactions.
Can not imagine to create a 700 + pages multi language website in Pinegrow (I tried, but itās all extra work for nothing).
In Codekit I can install Bootstrap (what ever version I want and the latest as well!!!) accompanied by all JavaScript I want to download from Github or to update and maintain). And keep total control over it!
I use HTML includes in Codekit that are simple .kit extensions converted to HTML when included in the .kit webpages. (like PHP includes) When I look at the Pinegrow Masterpages they are way to complicated!
In Sublime Text I do my coding, because of the unfinished code editor in Pinegrow (lack of plugins to install for the editor). I use MAMP as a local server to be able to use serverside Ajax technology in my websites.
Would like to see more development in the Interactions Plugin. Like the in previous posts named custom presets, but also more plugins from Greensock implemented!
Thanks,
David
Well, I wouldnāt say I āsimplyā work around them with code as the process involved is usually quite lengthy and mentally challenging. Thiugh I did succeed at it most times, creating a workaround for ACF blocks (before the block action existed) and managed to integrate innerblocks in it as well (also, before the block action allowed for such things).
Despite that it āfeelsā as if I am an āadvancedā user in some form or another but Iāll leave that for others to judge.
It seems like the topic is veering off a little.
From my perspective, Iām very interested in knowing which companion apps, automations, and external scripts you use with Pinegrow web editor, as well as any unique workflows you may have.
Whatās your favorite features? Do you use workarounds for some tasks?
Are you working as a freelancer? Do you work in agencies? Do you have a team that you collaborate with? Do you use a versioning system? And so on, and so on.
Thanks for the reminder to keep this more about usability than feature requests. Iāve been giving it a bit more thought, and here are a few more points that might be worth mentioning. Some are about how I use Pinegrow, while others are just general usability thoughts.
Iām trying REALLY hard not to do any solutioning here!
Preview Canvas
I donāt think I ever consciously realized this before, but apparently, I donāt use the preview ācanvasā very much aside from selecting elements to edit elsewhere and previewing changes that I make. Almost all the heavy lifting I do is in the Tree panel, Element Properties, Project Panel, and Style Panel.
As I was thinking about it, I realized that a lot of WordPress page builders, and maybe other tools like Webflow, are designed in such a way so that you are interacting more with the canvas. In Pinegrow, I find that the tree and panels are a more logical place to work. Maybe thatās just my style, or maybe there is some inherent limitation in Pinegrow that steered me toward that way of working. I have no ideaā¦
Inserting elements
I used to use the library panel for this, and would configure my screen so I could drag and drop from the library panel to the tree. Now, I never use this and rely solely on the ā+Insertā button at the top of the screen. Again, to drag elements to the tree. I rarely, if ever, drag anything directly onto the canvas.
I also find the code inserter WAY more useful than hunting down and dragging individual elements from the list. Itās blazingly fast and almost as nice as Emmet, in my opinion. I can see, though, how someone coming from another tool might not like it if they are used to large friendly icons for each element. I personally like the smaller text-based buttons with their simple HTML tags.
Rearranging and Modifying Elements
Again, here I find that the tree view is way more efficient than trying to guess where something should go on the canvas. In the tree view, I can see exactly where Iām moving things.
I also find the āselected elements menuā to a distraction, and itās one of the first things I turn off when Iām configuring my workspace. I think my biggest issue is that there is no way to make it disappear without disabling it, and having it on the screen makes it hard for me to see whatās happening in the preview. If I could easily dismiss it (maybe by hitting escape or something), I might find it more useful since it does seem to offer some useful tools in a convenient location.
Element Properties Panel
I feel like this panel is wasted space unless you are using a framework like Tailwind or Bootstrap. With either of those frameworks, itās great to be able to set your element properties and framework classes/properties all in one place. If Iām not using a framework, however, it feels like an afterthought. and something that might be better combined with the Style panel.
Of course, having said that, Iād also be frustrated if I was working on a Tailwind project and had to switch to the style panel to edit element properties. So, I guess trying to please me is a losing battle.
CSS Editing
This is a place that confused me a lot in the beginning, and still trips me up from time to time. On the Element Properties panel, I can add or remove an existing class but to do anything with that class I have to switch to the Style tab. Also, if I add a new class using this dialog, it only adds it to the HTML properties, but doesnāt create the rule in my stylesheet (there is a different dialog for that!)
Nowā¦ switching over to my style tab, I can easily create new rules and classes, but I canāt assign existing classes nearly as easily. I feel like there is an opportunity here to simplify the workflow a bit.
On the plus side, I LOVE the Create New CSS Rule dialog; every time I use it I am thankful for how easy it is to do what I want. Now that I know how to use it, that isā¦
CSS and Tailwind Class Trees
I havenāt used these as much as I want to yet, so I donāt have any strong feedback. My initial impressions are positive, however, and it looks like they will make for a good āexpertā workflow.
Tailwind Class Styles
I love this in concept, but donāt like that itās a separate panel. I would love to see this combined with the other Tailwind stuff at some point. Also, while Iām thinking about it, this seems to behave a bit like a workaround for not being able to use Tailwindās @apply directive. Iād love to see a more āNative Tailwindā implementation.
Actions Panel
For new Pinegrow users, this could very easily be confused with the WordPress Theme Builder panel since some of the actions are named similarly. I think there might be an opportunity to distinguish them a little more so that new users understand their purposes a bit better.
Interactions
My biggest struggle here is the lack of documentation and tutorials. There are so many different options and choices that it can get overwhelming very fast, especially for someone who isnāt intimately familiar with how to use GSAP. Even if you do know GSAP, the implementation in Interactions seems just different enough that I sometimes have to fool around to figure out what Iām trying to accomplish. I think more robust documentation and examples would go a long way here.
Stylesheet Manager vs. Manage Libraries & Plugins
These similar-sounding dialog boxes tripped me up a lot in the beginning since it isnāt clear from the dialog boxes what they do and when I should use them. Again, here is an opportunity to maybe improve the new user experience a bit by making them more informative.
Things I often use: Library, Components (all sorts of them with editable areas), Masterpages, SVG Icons, Tree-Tab, Visual Style Editor, all types of code editor (Yes, I use PG as my primary Code editor for JS and PHP), Interactions, Interaction Blueprints like galleries, Actions, Wordpress and WooCommerce Themes with Smart actions.
Things I almost never use: Design Panel, Frameworks like Bootstrap, Tailwind and so on, AI Assistant
Iām working as a one person business and create Websites for customers.
@adamslowe thanks for the follow up response about how you use PG.
Visual helpers - including the selected element menu - can be easily toggled with CMD+T.
May be shortcut key āRā might be helpful to create a new CSS rule, and jump automatically to styles panel from the tree?
Yep, the shortcuts are helpful for more advanced users who know about them. From a UI perspective, it was confusing to me when I first approached it and I suspect Iām not alone there.
Of course, like with photoshop, we can fly around the interface once we know a few important keyboard shortcuts.
The CMD/CTRL+T toggle is a big help. I was actually thinking something a bit more like Gutenbergās default behavior, where the toolbar is shown when the element is actively selected but hidden otherwise. Also, did I seriously just use Gutenberg as an example of what I like? What is this world coming to???
Block selected/active and toolbar shown.
Block not selected. Toolbar Hidden.
I suppose that is the trade-off of these powerful applications that are packed with features and for which simplified access is not always possible, considering the number of possibilities already availableā¦
To draw a parallel, indeed, using Photoshop without keyboard shortcutsā¦ itās depriving oneself of a devilishly efficient workflow.
I primarily use PG to keep my FSE themes organized in a uniform structure between teammates and also to be able to see (more or less) how a design is going to look before I export it to the theme. The ability to quickly create semi-custom blocks is also a huge time saver. PG is also excellent for training Jr. Devs who are new to WordPress. At first, when I was new to WordPress, I used the UI a lot, but now that Iām more proficient, I find that I donāt use the UI nearly as much, with the exception of WP actions, the dom tree, and PUG code inserter. Now that Iāve memorized more SCSS, I find it faster to hand type in VScode (the code is much more organized this way too). I still use the CSS UI from time to time for quick one-off changes. I also use the PHP action a lot.
I donāt think PG will ever be user-friendly to non-coders, especially if they are coming from a WP page builder. Iāve seen other companies like Toolset go down the path of abandoning their Developer and Power User market segment in an attempt to make coding ācodeless,ā and now they are circling the toilet with tons of savvy users and coders abanding them (including me). The easier you make it for non-coders who only need it for a one-off project, the harder it becomes for real DEVs who will be lifelong clients. The support alone for the non-coder market is probably 6x what you need compared to people who at least understand the fundamentals of coding. The DIY page builder market is already oversaturated. Iām not sure why PG is going after it. Especially since AI will be building non-coder simple websites with text prompts very soon. Iām not hating here, just donāt want to see PG abandon the core market itās really good for.