With the release of Pinegrow 3 & 4, and now moving forward. With the new complete UI redesign and plethora of great new CSS Features and underlying core logics, it seems like there is now the ability for adding support for such a feature.
With the inclusion of the CSS Visual Editor integration, along with various other CSS features which are now in place in the workflow and other general features across the app. It seems like now things are in place with in Pinegrow to easily add the ability to manipulate and visually adjust the Basic CSS Properties like:
margin
padding
dimension
position
rotation
z-index
Directly on the page itself via simple dragging etc. Working with and doing so in unison and concurrently with all the other new CSS Features and CSS Visual Editor.
Based upon current existing features, it seems to now be just be a matter of adding and hooking the logic with the CSS Visual Editor, and CSS features across the app. Which appears already solved since v3, concerning whats needed with the logic across all CSS features. In addition to the general application logic, it appears the overall logic already exists now in Pinegrow for this feature to be accomplished and successful.
I briefly touched on this already with a comment @matjaz in the Beta-4 channel, when PG 4 Beta 4 released with the new ability to now grab & drag items on the page like you can do in the Tree View.
Allowing for manipulation directly on the page concerning Basic CSS Properties seems like a no brainer and the logical next step at this point for Pinegrow.
Given all the improved features structure and underlying logic. Especially now with all the new CSS improvements and integrations across the app that work already in conjunction directly with the Visual CSS Editor. These basic CSS manipulations would allow for even faster and easier layout and design scaffolding of pages. By having the ability to manipulate these basic CSS properties directly on the page per item right in place.
Corresponding Live CSS Edits on the page, for adjusting Basic CSS Properties
could be something like the following:
margin — grab handle + mouse drag to resize
padding — grab handle + mouse drag to resize
dimension — grab handle + mouse drag to resize
position — selection + item drag position
rotation — grab handle + mouse drag rotation
z-index — right click context - bring forward or send backward , etc.,
snapping — each could also have a snapping feature, based upon grid size or near item relationships
If needed there could be a button in the top bar of icons too enable / disable this ability, etc. There seems like many ways it could be implemented into the workflow without sacrificing, hindering or conflicting with current CSS, Page and Item related features and functions.
Also there are many existing open source libraries that could assist in adding these features if needed. Including needed things like the following:
control handles
mouse functions
drag and drop
constraining to parent objects or areas *
snapping
resizing
rotation
depth sorting
etc.
Or even some vanilla JS & CSS should do the trick for some. Others could simply leverage existing logic via open source libraries.
This type of workflow feature was discussed briefly before by Pinegrow users in a previous thread, regarding this type of basic CSS Property manipulation per item directly on page. I have also directly talked with other current Pinegrow users whom would welcome this feature as part of Pinegrow as well.
Likewise when simply looking and watching across the overall landscape of web development applications and cloud based web development offerings. I have witnessed comments which seem like many non and potential new Pinegrow users, would agree that such a feature would make Pinegrow even more attractive of an application to market and gather more users with. I think adding such a feature could benefit many existing users and bring in many new Pinegrow users as well.
So I wanted to submit a formal Feature Request, for consideration. Thanks for your time @matjaz, keep up the great work with all things Pinegrow.
That’s indeed something we’re working towards, and as you noticed, a lot of changes in Pinegrow 3 and 4 have been laying the groundwork for making such features possible.
A couple of issues are still open:
Where to store the manipulated CSS prop: into style attribute, a selected CSS rule…, without creating a mess.
How to handle situations where changing the width, for example, will have no effect because a higher priority CSS rule is setting the value, or, if max-width is set somewhere.
It’s easy to make a simple on-page controls that work with style attribute. But, look at Macaw, it had powerful GUI manipulation tools, but users were not happy with the code output and with Scarlet it seemed they abandoned that approach and instead wanted to do something quite similar to Pinegrow.
Visual approach usually doesn’t lead to a well structured code and maintainable projects. I think, it can be pulled off in an usable way, but designing this process still requires some fine tunning.
You’re welcome. Thanks so much for taking time to respond, before it too slipped into the abyss.
I also posted a few other “detailed” Feature Request ideas here at the forum if you are interested. I am happy to share thoughts and ideas to help improve Pinegrow. Especially when they can advance it further to help benefit existing users and gain more users also.
As you say, I noticed the groundwork getting in place for such features becoming reality. But I do acknowledge it is perhaps not as simple as it would appear, mostly due to workflow considerations and outcomes, and that there are considerations and concerns that may go along with any feature development.
It’s really nice however to hear your response that it’s something you are working towards.
Fragmented CSS
As it stands right now I believe this type of fragmented CSS can still presently occur and still remains to be considered even with the workflow as it currently stands at this moment.
You can go into Pinegrow and start using the new Visual CSS Editor, which by default creates a “inline style attribute” for the selected item you are working on. You can do this on as many items you like and Pinegrow will amass a list of “Classes without rules” which translates to all these visual edits placing inline styles on items.
The user can then save the file without warning and these inline styles will remain in place. Of course we know inline styles are largely frowned upon in general within the industry as it fragments the CSS workflow across locations and makes maintenance a nightmare to search for all the corresponding CSS instances in multiple locations. But having said that you can use it effectively, to create HTML emails which may require inline CSS, etc.
So what to do, or what can be done to help prevent this inline CSS fragmentation?
Perhaps a 3 Step Actionable Warning System approach as follows:
1.]
Advise the user upfront with an overlay covering the entire Visual CSS Editor with an informative warning explaining the workflow in quick simple terms, or even video doing the same. So the user understands the correct way and the ramifications of not following the suggested proper methods of declaring classes, etc… This advises of the process, and places the outcome and responsibility with the user. It would also be a chance to make the user aware of the following two related features.
2.]
The next thing might be a “common indicator” (relevant icomoon icon (to stick with theme), or custom icon, etc.) that shows visually on page which items still have inline CSS attributes. Have some kind of CSS Inline Style (red) warning indicator displayed on each item, where inline style attributes are found to exist. Such an icon + warning, could be located in each items control bar when selected, or even displayed when not selected. There could also perhaps be a CSS warnings icon in the top icon bar of the app that toggles the display of the icons on all related items which have inline CSS, so the user can address each instance that displays warnings. When these warning icons are rolled over it could display a (red) tooltip immediately explaining the issue. It could also be present in Tree View to the left side of each item, and basically anywhere else which is relevant across the app for each item until inline styles are dealt with by the user.
At which time, when a class is declared and the inline CSS is no long present for the item, the indicator disappears across the app from all visual occurrences being displayed for that item. It would help give multiple opportunities to warn of such inline CSS attributes present and give the user multiple opportunities to address it. These indicators would help users to clean up things as they work as needed, and also lessen the length of the compiled list given in the next suggestion (#3) which happens upon Save, Save As or Close, etc.
Here are quick generic examples demonstrating the above ideal. Note: I’m not saying it fits with the UI design, just for the purpose of quick reference regarding #2.
Etc., You get the idea, across all relative features and areas as needed as briefly described in #2.
While #1 & #3 should be more obvious regarding what they discuss, without showing examples.
3.]
The last thing would be to quickly parse the HTML and check for inline CSS “style” attributes in the source upon trying to Save, Save As or Close, etc., and display a scrollable module window with a list of all these instances of inline Style Attributes behind a description of what it is they are associated with (img, div, id name, etc,). Have the same + button for “Save element style to CSS rule” beside each item to give users a chance to correct any remaining inline styles present from using the Visual CSS Editor, etc., that still remain after the above two warnings and opportunities. It could act like the present features that when you select each instance it takes you directly to that item, if you need to explore it further before deciding on a class name or association. Also give the user the ability to quickly bypass this process and simply acknowledge the warning and issues and proceed directly to Save, Save As or Close, etc. Then its again left on each user how they want to later rectify the inline styles and not on Pinegrow just like the initial warnings.
Would be applicable across CSS features:
The same type of solution would be in place for items “modified directly on page” as discussed in this feature request for Basic CSS Properties. Obviously all CSS features need to remain working in conjunction as they presently are. If the approach is taken as described by also having a button in the top bar to enable disable on page edits of basic CSS Properties, that again would be a chance for an initial warning information described above, and interaction by the user.
A developer should quickly learn or already be aware and know the current new Pinegrow CSS workflow already. But in the midst of working and using the Visual CSS Editor, or via on page direct item controls (as discussed in the first post), even a seasoned developer might let something inadvertently slip though as inline CSS. So it’s not just towards the newer less experienced user that this can occur or be a problem. Thats why perhaps a multiple step warning process (as described above) which is modestly direct and “encouraging” is needed to ensure proper structuring of CSS within pages and projects by users.
Having such failsafe warning methods, seems like the only way all case scenarios could be noted and addressed concerning avoiding inline CSS style fragmentation, and helping to create structured code and maintainable projects. Since you obviously can’t assume everyone has the same understanding or comprehension of the application or web development in general. So this type of approach would seemingly be needed to help prevent such cases and actively make the user informed and actionable.
Or do you get even more direct and force the app too demand a CSS Class ?
Forcing the declaration of a class by the user for each item, if an existing class is not found when any type of user edits occur per item. This would occur when a user selects an item and uses the Visual CSS Editor, or the discussed direct page manipulation of Basic CSS Properties in this thread, and across the other CSS manipulation methods, etc. At which time they are forced to first declare a class via a prompt. But then how do you handle that as each item can have multiple classes associated with it, you would need to have all the existing associated classes offered to the user in the prompt to decide which class the settings and changes get added to.
Is direct forcing the right approach however, or are the 3 more subtle tactics mentioned above regarding indicators and process better. Certainly it would be less in your face as described above verse forcing the decision constantly of the user and demanding a class.
Subtle encouragement and actionable methods:
I feel the 3 step actionable warning approach described above would be a better method vs constant forced interaction. Plus it would be easy to document and show in video, so the the process and workflow should quickly become self evident to all users. With in app documentation you can even launch and go to specific sections from within the app areas and features, as the documentation is developed further.
Regardless a method has to be in place to provide the user a method of interaction to understand the presence of inline CSS derived from these types of various Visual CSS Editing methods, and a way to easily address it through actions. I think the above 3 step approach could enable an easy clean workflow, while creating and encouraging clean source output and provide maintainable and structured code for pages and projects. While working all within the existing app structure, logic and workflow, with out creating a mess as you said.
Obviously to not annoy users, these types of warnings systems should also have the ability to disable or toggle for those users whom don’t need them or don’t want to see them constantly.
What are your thoughts @matjaz concerning these ramblings ?
Agreed, thats why I specifically asterisked the “constraining to parent objects or areas *” bullet, as I knew parent child relationships and properties will be important within such a workflow.
The width example you give, and all relative things similar. Would it require some type of fast algorithm for runtime checking. Evaluating up and down each items parent child tree what CSS properties exist and comparing that to defined rules and constraints to know what properties work with each other or against each other concerning CSS properties up and down the hierarchy. But with many scenarios and property comparisons is such a method possible or practical? Could such a runtime or algorithm and workflow be created or efficient, to gather and compare such arrays of properties conditionally against each other. Perhaps, since its a limited basic set of properties to compare against that was suggested. Then what do you do if a property does not comply, etc., disable the feature per item? Maybe.
I would hope however that there may be an easier answer or approach to allow smart on page visual editing of the basic CSS properties mentioned. But I understand that many things need taken into consideration and its not simply just black and white, but a bit of grey.
I do too, again I do too !
Hopefully that all makes some sort of sense. I look forward to any feedback, thanks for your time and consideration. @matjaz .
Their has been or still are, other apps using approaches similar to Pinegrow’s method of using inline styles for “initially” applying Visual CSS Styling manipulations to items. However each suffers from the same CSS fragmentation possibilities, unless the user is careful to adhere to a very specific workflow and take care to properly apply class names. They each offer methods of manual conversion via some form of user input, but with no encouragement, reminders, warnings or calls to action about doing so.
Users are typically required to keep constant track of all instances and references within that workflow themselves with no practical feedback or warnings from the app about inline styles. All this occurs at their own discretion, with no failsafes, warnings or calls to action by the apps to ensure proper CSS classes are ever defined and inline styles are converted and removed. The apps simply expect or assumes the user will properly declare classes for the inline attributes derived from visual styling tools (that initially use inline styles) per item.
Aside from an entirely different approach of first leveraging inline styles for visual manipulation, the chance for fragmentation remains the core problem. In my opinion due to no warnings or failsafe methods provided by the applications for the users to engage with and utilize actionable methods to ensure for clean output and maintainable code structures. With the example approach I previously described above as an example, it would offer “multiple entry points” and subtle reminders to rectify such inline CSS discrepancies though various calls to action by the app for the user.
The common denominator for all all these applications is that they assume the user will convert to proper classes from the inline styles used by the visual input approaches, with no warnings, failsafe methods, calls to action. So the workflows themselves are enabling the chance for fragmentation and not taking steps to ensure for the user, clean output and maintainable code structures.
You see others approaches that avoid the initial inline styles and just make incremental class names for you based upon what you add to the page, .image, .image-2, .heading, .heading-2, etc. Some use a similar approach but worse and just give nondescript class names for things added by the user, .dh54637, .eb226783, etc. These style of approaches are perhaps more automated, but would not fall into the category of clean maintainable code. Since they are so vague and confusing regarding the class descriptions unless the user is given the opportunity and choses to rename everything.
So in the end where does the responsibility fall for such a Visual workflows — app, user, both?
I say “both” realistically, and thats why I proposed the above type of example method. Which I believe would provide a workflow that would support the ability for various Visual CSS Controls and assist the user, to leverage those controls. While still providing methods to ensure quality maintainable code in the process though warnings, failsafe methods and calls to action via various entry points throughout the application.
While still allowing the user freedom to work how they want visually through visual controls but with accountability measures in place to leverage the visual tools. Upfront the user is given the ability for visual control freedom, but ultimately in the end - the responsibility is also placed upon them to adhere to warnings and industry standards to ensure proper source structures, through calls to action methods by the application.
Like mentioned previously such methods would be easy to document and understood across all skill levels, based upon visual indicators. By using simple “red” warning symbols/text, this could also facilitate other areas in the app which may require simple visual warnings and actionable followup. With other possible failsafes in the app for other features and reasons when needed as well. So this approach would not need to be unique for Visual CSS Editing only, but could offer various warning indicators, intended for other things if needed or determined by the workflow in application.
The thread has simply been my input towards the ideal of such a workflow. I wanted to try to emphasize the need and importance of having:
Warnings
Failsafe methods
Calls to action
Multiple entry points
Etc.,
For providing successful Visual Editor methods that encourage and ensure the user creates clean output and maintainable code structures and avoid fragmentation that can occur with these types of visual methods in applications.
I hope perhaps something may be useful or provide further things to think about regarding development and workflow in Pinegrow. By discussing how to possibly handle these things, and the reasons behind them from a UI / UX and application workflow standpoint. To hopefully help Pinegrow users and ensure the desired clean output and maintainable code structures when using the application and these types of visual controls.
Thanks again for your time, keep up the good work @matjaz .
( It took me a while to find this article I wanted to reference with this verbiage. )
I too have previously reviewed Macaw, and would have loved to try the Scarlet Beta but seemingly missed out. But I studied each as much as I could regarding there UI / UX, workflow, etc. Macaw via trying the app and Scarlet just through articles, screen grabs, videos and discussions online. It would have been nice had they remained to see what could have become with things.
When they were working on Scarlet they talked about a “Live Design Environment”. In reality with the rewrite of Pinegrow and the new core structure and UI, and it’s expanding Visual tools, etc. That is exactly what Pinegrow has matured towards, but with so much more to offer as an app.
Regarding my above emphasis about utilizing basic: Reminders, Encouragement, Warnings, Failsafe Methods, Calls to Action, Multiple Entry Points, Accountability Measures, etc.
I think the above described style of approach would offer what was echoed by the Macaw guys in 2015.
You have to provide enough affordance to help people up the learning curve, but not so much that it gets in the way of a super user. Preference is another hurdle. We have to design things as agnostic as possible to allow people’s preferences to shine through without sacrificing the intentions of the application.
We believe those decisions should be made by designers/developers, but they don’t need to be hand-written. Traditional WYSIWYG editors output absolute positioning, random IDs and just plain garbage, but this new breed of tools has found ways to improve the workflow to give you strong, usable code.
To me such an approach with aspects as I described above, would fit these requirements and offer:
Designers who wish to avoid the depths of code, while still learning about and how to code.
Developers who wish to work quicker visually, but still have complete full control over code.
I hope something I rambled on about in this thread was somehow beneficial or sparked further ideas to consider. Hopefully for the advancement of Pinegrow and to possibly benefit its users in a positive, productive way.
I guess with this post, I will now stop talking to myself.
Thanks @Pinegrow_User! And no, you’re not talking to yourself. Unfortunately, no magic wand for software development was discovered yet, so implementing ideas takes a while
Management of inline styles is something we’ll soon need, even before any visual on-page controls, since we are already encouraging using inline styles by having Style attribute on top of the Style panel.
Also, we have to spend a bit more effort on marketing and documenting the features we already have.
I didn’t expect an actual feature to be accomplished by end of week. Just had hoped something might be of value through discussion and dialog. I know you and the team watch and listen even sometimes in silence and you are all busy working to make Pinegrow better with each passing day and with even the subtlest features onward to the next milestones.
Fully understand.
The achievements starting with v3 and onward, totally deserve to be trumpeted loudly and showcased fully. Congratulations on the new rewrite and all the advancements to this point. It really opens the door for more great and wonderful things to come.
Keep up the great work. Thanks for taking my ideas into consideration.
Allowing for manipulation directly on the page concerning Basic CSS Properties seems like a no brainer and the logical next step at this point for Pinegrow.
I guess with this post, I will now stop talking to myself.