Intriguing…
The benefits of a visual website builder will always be a tradeoff between convenience and creativity, not because of software constraints, but rather the inherent limitations of HTML and CSS to display a web page. Even hand-coding is limited by this. Put simply, the “box model” foundation sucks, and despite all the clever things we’ve learned how to do, the web is still built on this sucky foundation.
1 Like
True @printninja… the box model is great for rapidly building a website but it does limit design creativity. I still use an image app like Adobe’s Fireworks to make the prototype design, then either follow-up with Dreamweaver or PineGrow to build the site. But I find that PineGrow often forces me to abandon some of my original design features because of its reliance on BootStrap whereas Dreamweaver is more receptive to implementing “non-boxy” designs.
But I shouldn’t complain… I remember being blown away the first time I saw an animated GIF on a website - and that was only 25 years ago! (Yeah, I’m that old).
Well, yes and no, mostly no 
Pinegrow isn’t reliant on Bootstrap, us developers (oh! look at me! calling myself a Dev!) who USE the BOOTSTRAP … model IN Pinegrow …are reliant on it.
Pinegrow can start as a plain html, you can use images, with transparent edges, faded texts, all sorts to "loose* the box model… circular structures with CSS3.
But… our tools can greatly increase our productivity if we know how to use them and have some design flair, Pinegrow allows us to run free
or
We can be limited by out tools, lack of knowledge and skills and just use the damn thats fast! oh pretty colours! model that comes of of the box… Bootstrap.
SO it’s a middle way and skillz set you free if you have a tool that can set you free and not limit you.
Pinegrow can do that, if you combine it with radical skillz and don’t… just use Bootstrap.
(ps, just for the record…I too am limited by my skillset but am aspiring to break out of it!
Pinegrow and some other things allow me this opportunity)
That’s true in a way and it is a bit sad that Flexbox and CSS Grid took such a long time. For more than 20 years CSS lacked some proper layout tools.
On the other hand, HTML/CSS is super universal and a steady growing standard, it will always have to deal with a bunch of different browsers, screen sizes and backwards compatibility.
Thanks @matjaz for the helpful CSS Grid course by the way, highly recommended! Can’t wait for lesson 10 and 11.
1 Like
Excellent catch - which can’t be second enough.
Coming from a so called “It doesn’t require any knowledge of code at all”-application(*), it’s obvious, where the limitations are mostly hosted: In front of the screen. It is coming from my experience of being a supporter seeing hundreds of expertise - not really groundbreaking though - being moderate: pretty mediocre.
Web is a media requiring different thoughts and stuff than our well known print experiences. Just an example:
A decorated box might be an eye-catcher of high value in a print - in web it’s worth nothing without content. That’s what people mostly struggle when they design for web: Content, readability, contrast …
Another example: High glossy magazine’s articles are often in multiple columns. This is not to transfer to web, cause the readability doesn’t come up to our expectations. We even have a CSS rule for it - mostly untouched.
Just as a notation to myself:
CSS-Grid is brand-new however I cannot really get used to it. It feels so table-like - which was in fact the most weird hack created for designers ever.
Cheers
Thomas
(*) Not to forget - the above mentioned application was great for two decades - and lost the race cause of the evolving web - and an audience persisted on being code-aphobic.
Yes, its interesting.
In a Magazine… you dont code the result. its pigments, its fixed sizes, and layouts,
if you want a smaller version - you CREATE a smaller version - and hand that out instead.
(like a flyer in a magazine)
The same for Powerpoint Presentations - you don’t code those,
Word documents (draggy droppy presentation) -unless your a LATEX freak…
and a myriad other things.
You create…creations, as you want.
with the web? MEH!
the LAYOUT keeps changing… on its OWN! depending on what consumes it (hello Responsive design/graceful degradation/progressive enhancement)
its as though the way forward (with no code)
would be
"Anticipated Behaviour*
ie, create a thing and then have a set of RULES… that all WEB things adhered too!
WOW! a standard! (Sort of like .DOC -er oh hang on… these fall apart in Libre office too) With NO Proprietary brand code (Hello Browser wars!)
So, make a thing - this is Layout for size one.
this is what it looks like in size 2
etc for umpteen sizes.
A visual thing.
then, Layout or template … things.
This is the Layout for this size device.
this is for this size.
and … the Element things you made… with their standard
“I look like this at this size” setting -transferred/matched with their corresponding template size they were being shoe horned into.
…which would be saved in some standard format , a la .JSON thing or such like (with the thing Behing constructed with standard html and css behind the scenes)
and so a new standard web language…>OR …set of instructions that dictate sizes/templates/layout shapes. and extension of what we already have. would make sense.
ie, CSS GRID has JUST starting making traction - after 20 years!
So something along these lines! (grids? 
. )
its the obvious next step (next? 20 years late if you ask me)
to STILL be manually coding all this malarky, due to a lack of a STANDARD layout methodology at this level of technological advancement seems totatlly nuts to me!
Its like the whole Web Media Layout methodology is missing the Obvious next level,
and Overarching method of Formatting the LAYOUT overall, Not the Micromanaging of individual components with things like BootStrap and CSS Grid, Trying to replicate this obvious missing bit.
The Elephant (NOT) in the room… which SHOULD be in the room.
So, yeah , I feel your pain at the loss of your beloved app @Thomas.
but. hey we now have Pinegrow … oh, and code layouts… or there is always.>>>>Bootstrap
ps. and Im going to play with http://dragify.com while I await to see the exciting new beastie… PineGrowSeedling
PGS?>… (Pretty Good Software… Please Grow Slowly… Productivity Going Super?)
UPDATE.
having just watched this -
I feel somewhat like… WP…might…be doing the sort of thing I was anticipating, with its Gutenberg project… taking over and implement Semantic structure on the CMS… which …takes over the actual site/wysiwyg view.
Thus replicating my missing layout language of the web. -where blocks adapt/conform to thier container template in some sensible manner.
mmmm, so, how does/would/could this affect the whole WP Theme approach… PG+WP theme builder… all other builders (Beaver, elementor, Genesis etc) and … the up and running PGS ?
Now…if the WP GUTENBERG concept could externalise and morph across the actual complete pantheon of the web experience then,
Well, I think we would have arrived.
And maybe PGS would already have its finger on the pulse of those sorts of concepts.
Since, they are a bit visinary in PGTowers
And all this is predicated upon not giving two hoots about the effect of Gutenberg upon CURRENT WP …methodology, but rather,
How that principle (of designated content being described as something from initialisation and styled/manipulated via a standard language/api) would pan out if applied to the whole blank canvas of an empty web page and a truly creative canvas.
A promising start for web 3.0 I think
Don’t get me wrong here! I am standing for web-design as a profession - and I’m happy leaving the “intuitive” world of asking: "Can this be done with XXX (substitute it with your preferred app :-)). For this reason I hope, Pinegrow-Towers are finding a very different name for their baby (e.g. Squirrel - so we’ll probably have a squirrel_user who knows?).
So there is no look back - just sweet memories of where I’m coming from.
But I prefer looking into the future - and I don’t need to do it in a faceless app. The underlying code as the language is a must have for me - such as I’m trying to communicate in the agreed language of this board.
As I remember it half-way correct:
Sir Tim Berners Lee once mentioned being surprised that there are so many different apps for solving one simple thing called HTML.
Cheers
Thomas
Yeah… I should have expanded a bit more. I do like PineGrow’s ability to play nicely with other toys in the sandbox: I can migrate between Dreamweaver and PG, one to do site layout for the front end and the other to interface with a dB (like MySQL) for the back end.
If I were a bit more advanced in my coding skills (currently I’m an admitted code-aphobic since I started out only as a designer) I could use PG’s HTML feature so I don’t have to abandon unique design styles. But for now, using PG’s tools with Bootstrap has helped me greatly to better understand proper HTML (love it’s HTML error checker), CSS (currently struggling with PG’s CSS UI), json, and js. So it is a terrific learning tool - albeit some scattered documentation.
Each site I build contains more of the features PineGrow has to offer. So I am getting ‘smarter’ (insert chuckles, winks and grins here). So far, I’ve built three responsive sites for clients using PineGrow all of which use Bootstrap components – including my latest dev/test site: http://statecollegedev.com (comments definitely welcomed).
And I do like visiting here with you nice folks.
Wow, this thread kind of went (grew) sideways a bit.
Then again, since this is still largely a fictitious new Pinegrow product, I guess everything is off topic in a sense until we actually know more about it.
Well, there is no indication based upon any official specs that it will be changing anytime soon. 
Speaking in general, regarding to the “Box Model” and designers. I am always amazed at how easily designers seem to get tripped up right out of the gate with the box model. Most give up learning HTML/CSS forever after they can’t wrap their head around this simple basic concept. Many designers likewise still struggle in visual apps coping with the box model.
I see your new response clarifying things, but going back to your original statement.
Sadly, thats a common misconception which I see largely throughout the web being spoken by many people when referring to and talking about Pinegrow. They perceive it solely as a “Bootstrap Builder”.
Unfortunately some of that has to do with Pinegrows own marketing over time. Along with the continued need too actively get out and “control the message and branding” of the product across the web and all the channels.
But in fact people can leverage virtually any fronted framework or approach with Pinegrow. In doing so they may not have the advantage of its full visual capabilities such as dropping library items, etc., but people can create a page/site with anything they choose and use various visual methods and approaches to help them along the way while using whatever frontend approach they desire.
Continuing back towards the whimsical discussion of this New Pinegrow product.
So if we compare with the likes of Webflow as an example, if it indeed is considered one of the current standard bearers in the designer centric product space. Then Pinegrow already has relative existing features which can be “retooled and further simplified” as required / needed which correspond in various ways with Webflow:
- Existing Core App (Pinegrow)
- Core UI Underlying Structure
- Projects
- Layer Tree
- CSS Grid
- FlexBox
- Visual Page Helpers
- Visual CSS Designer
- Library
- Smart Drag and Drop
- Various Drag and Drop enabled features
- Responsive Tools
- Responsive Views
- Blocks, Snippets, Components
- Etc.,
I‘m curious to see however what current features will be omitted, diminished, streamlined and made ‘simplistic’ for a Pinegrow app geared specifically towards designers.
It seems “simplicity and visual ideals” would be at the forefront, much more so than the current state of Pinegrow. In these regards Webflow and other tools in this product space have various visual approaches that can certainly be referenced. Things such as layout, animation, interactions, CMS, SEO, service integrations, etc.,
So its will be interesting if it will be along the lines of various existing modern visual builders. Or maybe instead more towards the various existing design & prototype tools, except with the differentiation of having code export? Or the next generation of design and prototype tools currently coming forth that already include code export? Or perhaps some entirely different thought by @matjaz, a Pinegrow inspired workflow mindset different than what is currently found in the market within this product space. Perhaps that is what @matjaz has hinted at.
Regarding designers and apps, in the end it appears to always be about:
- minimal interaction with the underlying source structures
- simplistic
- intuitive
- Ultimately what limitations remain that will hold designers back from leveraging their design skills to produce sites with the various modern requirements and integrations
The last one is usually the biggest challenge for web development regarding designer focused tools, as it’s a perpetual list of features, services, integrations, connectivity and so on. There will aways be additional requests and perceived requirements of missing features. But even the baseline level list of feature needs on “todays web” is quite far reaching and diverse even for visual apps.
Will this new app be derived and based upon a specific framework (Bootstrap), or instead forge ahead by simply using vanilla FlexBox, CSS Grid, etc., ?
Perhaps this by Webflow previously has woken the sleeping giant in @matjaz and the Pinegrow Team. 
Since Webflow is also web tech, they could listen to their users and eventually bring it offline as well.
Maybe a battle royal back on the desktop someday, with a million other apps. :–)
Maybe the big question is at what point does the staff need to increase to keep up with everything:
- development
- documentation
- tutorials
- marketing
- etc.,
@Marf , I was looking forward to you coming back and sharing some thoughts.
How will this impact (help/hurt) the division on whom should use Pinegrow? As seen with the previous lack by many concerning any type of inclusion for designers or those learning in another thread ?
IMO, the Pinegrow team would benefit from consulting with people who are using PG in a commercial environment where getting websites built quickly and professionally is job #1. The needs and pressures of using any piece of software in the professional arena quickly expose whatever drawbacks or inadequacies are present, and the feedback is usually going to be quite valuable.
Equally crucial is keeping track of what your competitors are doing, and making sure they don’t gain a significant competitive advantage (like Webflow seems to be doing.)
There are too many PG competitors cropping up every month for them to miss any opportunity to get ahead of the competition.
2 Likes
Outside of my role and involvement in the Pinegrow team and my total faith & trust for the present and future of our application(s) as well as in Matjaz’s decisions, as a web professional, beyond having to fulfil my immediate needs , robustness, efficiency, versatility, interoperability and permanent availability are 5 of the most important points when I select the tools for my duty.
I have been monitoring and scouting all the tech novelties around for nearly 20 years now and I have realised long time ago that the “graal app” - the application that would offer me to meet 100% of my needs - does not exist and , because the technology changes almost every days, will (probably) never exist.
I prefer to carefully select and use a set of modern, robust, very efficient and interoperable tools for any of my particular needs and as long as they can communicate each other, are able to read/write my documents (genuine HTML/CSS/JS …) and don’t leave me trapped in proprietary formats or processes that does not correspond to standard practices, my pro life is fine. 
1 Like
^ Indeed, well said @Emmanuel.
Thats why I was surprised to hear of this from @matjaz , as thats not really the Pinegrow approach.
I guess @matjaz was talking about custom html tags like the one you can find in your documents when you deal with specific features in Pinegrow (wordpress and other). These tags cannot be considered as “proprietary” but they are mandatory if you want to keep using/tweaking the corresponding awesome features from Pinegrow.
The documents are still readable, writable from any editor and viewable in any browser.
1 Like
Assumedly you know more than us as part of the team, so we’ll see.
This is a great thread, thanks to all for participating!
And as the discussion gets longer, so do your expectations of what PGS will or should be. Hope we won’t all be disappointed in the end
Regarding Bootstrap:
There is nothing in PGS that would tie it down to one particular framework. That said, even when working with plain HTML sites, in most real-life cases, we need stuff like Normalize css, responsive breakpoints, mixins for media queries etc. So instead of reinventing this, the current thinking is to just take these boilerplate stuff from Bootstrap. (Bootstrap is very modular, you can pick and choose what parts you use).
On top of that, most websites need components like Navbar, slider, Rows & columns, maybe Cards. Again, it makes sense to take these out of Bootstrap, rather to invent our own. This level will probably be optional, so you’ll be able to start a project without these components.
What are your thoughts about this approach?
Box model & designers
CSS grid removes a lot of limitations and drawbacks of the legacy web box model. At the same time, it still forces us to use an underlying structure for our layouts. Can’t just put elements wherever you want. And, in my view, that’s a good thing. The power of the web comes from its structure and organization, both on content side and on the design side - if your end goal (as it should be) is a positive user experience.
Looking at Macaw, IMO, its biggest failure was that it came out too early - at the time when floats, margins and absolute / relative coordinates were still the way to freely position elements. They tried to expose these concepts through visual tools, with some success. But at the end, the result was messy and wobbly, especially when you add responsiveness to the mix. CSS grid offers a clean alternative.
Proprietary styling
@Emmanuel and @Pinegrow_User touched on this topic above.
When creating a tool like PGS, that aims at making a part of the workflow (for example CSS styling) less complex and more direct, you have to give up the ability for the tool to be a general purpose editor. There is no way to have both: the ability to edit any HTML/CSS project and a smarter, non-CSS way of styling elements.
For technical reasons, PGS generates SASS code on the fly, from styling information that is saved in a XML file (XML works better with source versioning systems than JSON). So, the output is clean and extendable SASS and CSS code, but of course, as soon as you edit SASS code directly, the ability to continue using PGS for styling is lost.
That said, you still have the option to include non-PGS stylesheets into the page, where you can do whatever you want, also override PGS styles.
And, you won’t get locked into using PGS. If one day you decide not to use PGS anymore, you’ll just continue to work with its SASS or CSS files.
Branding
Another topic where your input is very welcome:
At the moment, the idea is to keep Pinegrow name/brand for both apps. So, we’ll have the existing “Pinegrow Web Editor” and the new “Pinegrow X” where X is some smart-sounding word, like Squirrel
The benefit of that is having a unified brand for all our apps. The drawback is the risk of confusing people, because often Pinegrow Web Editor is called just Pinegrow.
So,
Pinegrow Web Editor & Pinegrow Squirrel, or
Pinegrow & Squirrel
Let’s see where this discussion goes next
Exactly for this reason, I created my own framework - independent of all major and popular frameworks. I think I have even found the only lil piece which is “responsive by design” rather than being “responsive by device”. All the rest is as you said: Normalize, a padding/margin system, colours and shadows loaned by Material design, a carousel/slider (slick) - and a pre-built responsive typography system. All this covers about 80% of my current needs. It enables me to “design” in code without going much into a designer’s app first.
I’m full of weird ideas - not meant to end, cause I never had the opportunity to talk about. It is something like:
Let’s create kind of an API/CDN with some cool features and stuff (such as bower). Let’s have a pre-Head and pre-Before-Body-End area within the app in which you throw the links needed in. Both areas are able to concatenate, compile and minify this into “one-working-simple-link-to-resources” to each place (a CodeKit if to speak so). And let’s add this feature into Pinegrow Pro.
Since your brilliant screencast, I had to somehow review my opinion. PG offers the most enhanced way, giving CSS Grid a go. It should be much wider populated - and it would make 99% of all articles “How to” redundant.
In other words: There is so much the current Pinegrow Pro could do and there is even more we could do for Pinegrow Pro. Personally spoken, I don’t see much time, effort and resources to invest this in a seedling right now. But admittedly, I love the developer’s idea of coming from both sides as well.
Cheers
Thomas
Ah XML, ok.
Well, the following probably wont be popular, but here goes.
I agree @Printninja.
As you mention, targeted communication, direct user feedback along with comparative industry awareness are each essential. Unfortunately at times it seems current users are left without a voice (Forum/Slack) regarding user input, features suggestions, etc. Even though the Pinegrow team is said to be silently watching throughout. I have no doubt they are observing even without providing reaction or input in most cases.
But as one example, it took nearly 2 years to get any developer feedback and subsequent action on peoples desire for a VS Code extension. However it was then followed by a handful of days (see github commits) to bring it to market and make it a reality. These types of instances concerning delay can have varying negative effects on the public brand as well as current and potential users when they are left lingering. When instead in many cases such things could be discussed and even resolved fairly quickly as shown with that example. There are similar things voiced by users that would bring a substantial overall benefit to a multitude of users both current and potential. While avoiding this type of lingering negative impact upon the product, instead making the app and product line stronger and more marketable for everyone involved.
At some point users can begin to feel largely unheard, and stop offering valuable usage feedback along with feature and workflow suggestions. This too can have negative impact upon a product. Other similar examples of user suggestions, many requiring similar minimal implementation time, while offering widespread benefits exist throughout the Forum and Slack with little too no feedback or action being provided.
So various things could certainly improve for the broader good concerning current and ongoing communication between the developers and the end users. Things simply move too fast in this space for any app developers to be tone deaf regarding user voices and potential customers. Everything from feedback on usage, feature and workflow suggestions along with user awareness input of beneficial features in other apps and the industry as a whole.
I understand this design centric app could provide a large influx of revenue and users into Pinegrow moving forward – which is certainly great for overall growth and development of the entire company and product line. But this new fragmentation does cause some worry, regarding focus on the main core app. Instead of focusing on its refinement, new features, documentation, api, marketing, etc. With some of those existing areas still needing direct attention, updating and development. This new endeavor is being given development time and thus taking away from the focus of those existing areas.
I truly understand the desire of this direction of catering better to designers.
But the biggest “disappointment” would be if this newly altered focus causes none of the apps to fully reach their potential or keep pace with the industry and competition. I would much rather prefer to have Pinegrow Pro and upward solidified, advanced and reach their fuller mature potential more quickly. But I understand the place and potential of this new app in the product line and how it can indeed benefit the future of Pinegrow as a company.
So we’ll see. 
“The man who chases two rabbits, catches neither.” ― Confucius
I doubt “squirrels” would be much different, probably worse with climbing included. ;–) So hopefully things don’t slow down or become hindered concerning the focus on the core app while chasing after other things. Unless staff has increased, its hard to imagine some impact not taking place with this added product initiative.
Obviously I am unaware of the significance regarding changes coming for version 5. But from that, it sounds perhaps maybe more like refinements than major advancements. Recalling the announcement concerning the altering of versioning numbers:
Hopefully “Pinegrow 5” wont suffer the lack of “significant” advancements in features, while being distracted with chasing two rabiits or squirrels. 
2 Likes