Experimental package: Instantly Preview any block
Permalink
I've built a package that enables you to instantly preview blocks when adding them to an area.
See it in action:https://www.youtube.com/watch?v=SsVfuPEssNc...
GitHub:https://github.com/hammertimedk/InstaPreview...
Background
============
Late 2012 I saw this:http://www.youtube.com/watch?v=UK42Hont3to... from here:http://blog.codinghorror.com/what-you-cant-see-you-cant-get/... and thought it pretty damn cool. It got me thinking about trying something similar for Concrete5, but never got around to it. Especially after seeing the upcoming 5.7 release previews, I dismissed the idea as being potentially irrellevant. My main gripe with regards to C5 content editing has always been the tinyMCE implementation and Redactor seemed to solve most of my pet peeves.
A year later a Heureka moment hit me with regards to how to actually implement this and I decided to revisit the idea. With the not immediately impending release of v5.7, then I thought this might still be relevant as a concept also considering that the rather winding "add block"->"modal window"->"edit/save"->"publish page"->"Visit page from front end to make absolutely sure everything renders the way I want it" workflow will still exist.
In short, this package
* Gives the user a 100% accurate rendering of how their page will look when published
* Provides this functionality exactly where the user needs it, shortening the typical workflow by several steps (hopefully) resulting in fewer errors and less time wasted
* User can interact with elements on the Preview page in order to test out videos, slideshows or other components
* Eliminates the need for in-block preview functionality (e.g. form block, page list block)
* Achieves this effect by using the built-in Versioning system in a relatively responsible manner
* Works with all stock out-of-the-box Concrete5 blocks, and should work well with blocks that adhere to C5 standards.
Check out other notes and a rundown on how I achieve this at GitHub.
I'm fairly excited about this package, and I think the effect is pretty neat. I wanted to touch C5 core stuff as lightly as possible and try to ensure that this "would just work" with most, if not all blocks. I think I've achieved that somewhat, but a "real" baked-in previewing system would be the way to go I feeel.
What do you think guys? Is this, as a concept, worth looking into for the new v5.7 - or should I/we just leave it as-is as a neat curiosity that will never make it to the marketplace (due to the core file overrides I'm doing)?
Any comments welcome :O)
See it in action:https://www.youtube.com/watch?v=SsVfuPEssNc...
GitHub:https://github.com/hammertimedk/InstaPreview...
Background
============
Late 2012 I saw this:http://www.youtube.com/watch?v=UK42Hont3to... from here:http://blog.codinghorror.com/what-you-cant-see-you-cant-get/... and thought it pretty damn cool. It got me thinking about trying something similar for Concrete5, but never got around to it. Especially after seeing the upcoming 5.7 release previews, I dismissed the idea as being potentially irrellevant. My main gripe with regards to C5 content editing has always been the tinyMCE implementation and Redactor seemed to solve most of my pet peeves.
A year later a Heureka moment hit me with regards to how to actually implement this and I decided to revisit the idea. With the not immediately impending release of v5.7, then I thought this might still be relevant as a concept also considering that the rather winding "add block"->"modal window"->"edit/save"->"publish page"->"Visit page from front end to make absolutely sure everything renders the way I want it" workflow will still exist.
In short, this package
* Gives the user a 100% accurate rendering of how their page will look when published
* Provides this functionality exactly where the user needs it, shortening the typical workflow by several steps (hopefully) resulting in fewer errors and less time wasted
* User can interact with elements on the Preview page in order to test out videos, slideshows or other components
* Eliminates the need for in-block preview functionality (e.g. form block, page list block)
* Achieves this effect by using the built-in Versioning system in a relatively responsible manner
* Works with all stock out-of-the-box Concrete5 blocks, and should work well with blocks that adhere to C5 standards.
Check out other notes and a rundown on how I achieve this at GitHub.
I'm fairly excited about this package, and I think the effect is pretty neat. I wanted to touch C5 core stuff as lightly as possible and try to ensure that this "would just work" with most, if not all blocks. I think I've achieved that somewhat, but a "real" baked-in previewing system would be the way to go I feeel.
What do you think guys? Is this, as a concept, worth looking into for the new v5.7 - or should I/we just leave it as-is as a neat curiosity that will never make it to the marketplace (due to the core file overrides I'm doing)?
Any comments welcome :O)
Hi John,
I was hoping you'd chime in, and thank you for the kind words :O)
On to your questions:
- Does it work with ajax-heavy blocks?
Depends on what you mean. When adding a block, the block can do any ajaxing it wants to, as long as it updates the ccm-form fields properly. My package relies on the block form data being submitted as usual, so it's only in cases where the block does something on submit (like the regular Content block, which grabs content from the tinyMCE iframe and adds it to the ccm-form fields) where we have potential for incompatibility.
While viewing the preview, ajaxing should work as usual however if the block relies on fetching data based in its instance ID, then stuff will crap out, as that instance will already have been removed from the system.
- Does it work with ajax-heavy themes?
I can't see why not. Don't quote me on that though - haha.
- Could you skin it with a clear modal overlay to prevent any interaction with the preview (other than closing it)?
Neat idea! This is certainly doable - having a div across the iframe with a higher z-index to capture events would do the trick nicely
- How much does the database grow each time a preview is made?
I haven't looked into this, really (scribbles on todo list). In theory I think it shouldn't grow as what we are doing is creating a new page version, saving the block to it, rendering the page and deleting the preview version immediatly. So if the delete version codepath in C5 cleans up after itself properly (which I think it does) then not much, if any, junk should be left in the db
- Are there lots of block IDs being created?
Yes while generating the preview we are cloning the current version so a lot of blocks are being versioned etc. - but this should get cleaned up after the preview is shown.
- What does the site look like to another visitor while this is taking place?
If another visitor hits the site in the short time it takes to render the preview, they will in fact see the preview version live.
- What happens with blocks with secondary tables?
Depends on how well they are written I suppose. If they do not clean up after themselves when C5 deletes the block version, then some junk might accrue here.
Another idea I've had for this is quick and easy responsive previewing:https://github.com/hammertimedk/InstaPreview/issues/1... - which might be useful :O)
Ermm... Yeah I don't think the package in its current state is robust enough as I'm pretty sure there must be blocks out there that will crap out and render the preview ineffective. We are playing around with versions after all (creating, approving, deleting) so if something goes terribly wrong then unexpected results might occur. I've tried to make this as robust as possible and have it revert nicely when bad stuff happens, but I can't be sure this will work in all cases.
I wouldn't want to do a pull request with the current concept, without a clear indication from the core team, as I think this should be baked in thoroughly into the core with more wide reaching changes to the versioning system, or skip that whole (hacky) approach and do a real preview renderer.
Anyway, if the core team likes it, it will be food for thought, and if they want I could donate some hours of my time building it :O)
I was hoping you'd chime in, and thank you for the kind words :O)
On to your questions:
- Does it work with ajax-heavy blocks?
Depends on what you mean. When adding a block, the block can do any ajaxing it wants to, as long as it updates the ccm-form fields properly. My package relies on the block form data being submitted as usual, so it's only in cases where the block does something on submit (like the regular Content block, which grabs content from the tinyMCE iframe and adds it to the ccm-form fields) where we have potential for incompatibility.
While viewing the preview, ajaxing should work as usual however if the block relies on fetching data based in its instance ID, then stuff will crap out, as that instance will already have been removed from the system.
- Does it work with ajax-heavy themes?
I can't see why not. Don't quote me on that though - haha.
- Could you skin it with a clear modal overlay to prevent any interaction with the preview (other than closing it)?
Neat idea! This is certainly doable - having a div across the iframe with a higher z-index to capture events would do the trick nicely
- How much does the database grow each time a preview is made?
I haven't looked into this, really (scribbles on todo list). In theory I think it shouldn't grow as what we are doing is creating a new page version, saving the block to it, rendering the page and deleting the preview version immediatly. So if the delete version codepath in C5 cleans up after itself properly (which I think it does) then not much, if any, junk should be left in the db
- Are there lots of block IDs being created?
Yes while generating the preview we are cloning the current version so a lot of blocks are being versioned etc. - but this should get cleaned up after the preview is shown.
- What does the site look like to another visitor while this is taking place?
If another visitor hits the site in the short time it takes to render the preview, they will in fact see the preview version live.
- What happens with blocks with secondary tables?
Depends on how well they are written I suppose. If they do not clean up after themselves when C5 deletes the block version, then some junk might accrue here.
Another idea I've had for this is quick and easy responsive previewing:https://github.com/hammertimedk/InstaPreview/issues/1... - which might be useful :O)
Ermm... Yeah I don't think the package in its current state is robust enough as I'm pretty sure there must be blocks out there that will crap out and render the preview ineffective. We are playing around with versions after all (creating, approving, deleting) so if something goes terribly wrong then unexpected results might occur. I've tried to make this as robust as possible and have it revert nicely when bad stuff happens, but I can't be sure this will work in all cases.
I wouldn't want to do a pull request with the current concept, without a clear indication from the core team, as I think this should be baked in thoroughly into the core with more wide reaching changes to the versioning system, or skip that whole (hacky) approach and do a real preview renderer.
Anyway, if the core team likes it, it will be food for thought, and if they want I could donate some hours of my time building it :O)
With the current issues on the forum summary page, changes and replies are frequently getting hidden well down the scroll, or only noticeable by observing the reply count. So I am afraid I have only just read your reply.
The core team are very sensitive to anything that overrides core behaviour, and especially anything that alters their view of the UI. The closest addon for getting in deep to the core that I have seen approved is Automatic Block Identification
http://www.concrete5.org/marketplace/addons/automatic-block-identif...
Its much smaller, only just got through, and is black.
Another recent addon that almost didn't make it is Page Importer
http://www.concrete5.org/marketplace/addons/page-importer/...
(finally approved as red)
The alternative suggested for airing interesting projects is to add a github link to
http://www.concrete5.org/developers/open-source/...
There is nothing to prevent you trying both. You could also try a PM to Greg Joyce to ask if it stands any chance.
It will need a lot of reviews over different sites and circumstances and is sufficiently complex that it may just be too much of a commitment for many reviewers, so progress through the PRB would probably be slow no matter what.
The core team are very sensitive to anything that overrides core behaviour, and especially anything that alters their view of the UI. The closest addon for getting in deep to the core that I have seen approved is Automatic Block Identification
http://www.concrete5.org/marketplace/addons/automatic-block-identif...
Its much smaller, only just got through, and is black.
Another recent addon that almost didn't make it is Page Importer
http://www.concrete5.org/marketplace/addons/page-importer/...
(finally approved as red)
The alternative suggested for airing interesting projects is to add a github link to
http://www.concrete5.org/developers/open-source/...
There is nothing to prevent you trying both. You could also try a PM to Greg Joyce to ask if it stands any chance.
It will need a lot of reviews over different sites and circumstances and is sufficiently complex that it may just be too much of a commitment for many reviewers, so progress through the PRB would probably be slow no matter what.
A few random questions:
- Does it work with ajax-heavy blocks?
- Does it work with ajax-heavy themes?
- Could you skin it with a clear modal overlay to prevent any interaction with the preview (other than closing it)?
- How much does the database grow each time a preview is made?
- Are there lots of block IDs being created?
- What does the site look like to another visitor while this is taking place?
- What happens with blocks with secondary tables?
As you suspect, I agree you may have trouble getting this into the marketplace. In the PRB the core team usually suggest that blocks like this go on the related projects page.
If it is robust, perhaps it could become a pull request on the core? However, I wouldn't put too much time into a core pull request without checking with Franz/Andrew first. Core UI related pulls that are outside of their vision for the UI have often been rejected.