Problem/Motivation
In our 3-part plan we talked about finishing this module by building in it in stages.
- Stage 1: Have a preview on the same page as the edit page.
- Stage 2: Update the preview when the user stops typing in a form field (debounce)
- Stage 3: Make form fields Reactive (Editing the preview immediately)
I propose that we release version 1.0.x as soon as we can accomplish stage 1.
Then, we can begin targeting commits to Version 2.0.x and launch 2.0 as soon as we accomplish stage 2's objectives. (mainly reloading the preview upon editing fields)
And if we ever figure out how to get stage 3 done, that'll be version 3.0.x
It wouldn't be ideal to be supporting all 3 versions, but we can plan the deprecation and elimination of versions if we ever get that far.
Proposed resolution
We're very close to meeting the minimum requirements of 1.0.x. I think we can start preparing the release and getting this out there. Then we can work on minor (1.0.(x+1)) and major (1.y.x) updates if we get a lot of feedback / think of improvements.
Remaining tasks
Agree on release plan.
Completed
#3343009: Position the new iFrame so preview and edit are side by side
#3343519: Take over the Preview button
#3343904: Replace enablePreview logic with permission check.
#3344702: Add Tests
#3344458: Provide a button to open preview in new page
#3347602: Remove contextual links from same_page'ed preview
Release Blockers
#3343006: [meta] Address accessibility concerns
#3343414: Move Preview controls to edit page
#3345990: Toggle Preview Should Refresh Preview
Nice to haves
#3345096: Add a grabber to the left border of the dialog
#3344837: On by default, make off-by-default an opt-in setting
#3344846: Better module page
#3345266: Scroll position is lost when refreshing the preview
#3345991: Provide Preview Presets for Common Device Widths
Comments
Comment #2
cosmicdreams commentedComment #3
cosmicdreams commentedComment #4
cosmicdreams commentedComment #5
cosmicdreams commentedComment #6
cosmicdreams commentedComment #7
brianperryAdded `Scroll position is lost when refreshing the preview` as a nice to have.
I'm also thinking that `Provide a button to open preview in new page` should be a release blocker. And maybe `Allow user to show preview pane by default` as well. Thoughts?
Comment #8
brianperryI also think #3345990: Toggle Preview Should Refresh Preview should be a release blocker.
Comment #9
cosmicdreams commentedFor 1.0.x, I'm thinking of the question:
The initial release isn't going to be our last release. So we just need to put a version out that we'll want to support until the next version comes out. That said I can make an argument for each of the release blockers:
#3343006: [meta] Address accessibility concerns
Accessibility is an important gate to get through for Drupal work. And, speaking for myself here, I don't make a lot of modules. It's cool to learn what is all needed in order to properly produce work that is accessible.
#3345096: Add a grabber to the left border of the dialog
Is really a nice to have, if we don't have this feature the same page preview doesn't break.
#3343414: Move Preview controls to edit page
I think this is on the fence of being a release blocker. This is an important feature to consider as changing this in the future might mean breaking backwards compatibility.
#3344702: Add Tests
Really should be a release blocker, but we could skate on manual testing for a while. I'm struggling to figure this out and the struggle is kind of fun right now.
#3344837: On by default, make off-by-default an opt-in setting
Really it's a nice to have. We can add this later without breaking backwards compatibility
#3345266: Scroll position is lost when refreshing the preview
Likewise, saving the scroll position could be added without breaking backwards compatibility. If not, yes, it should be a release blocker.
#3344458: Provide a button to open preview in new page
I DO however think that adding a preview button is a release blocker. If we don't provide one then we've broken backwards compatibility. Users can currently click on preview and see a full preview. After the install our module they can't.
#3345990: Toggle Preview Should Refresh Preview
This sounds like the stereotypical nice to have. It extends a button that we've added with additional behavior. Yes, I think it's likely that we'll need to have the link to a button but I don't think it will actually "break" anything if we do that.
Comment #10
cosmicdreams commentedComment #11
cosmicdreams commentedComment #12
cosmicdreams commentedVery close to 1.0.x @shaal, let's discuss #3343006: [meta] Address accessibility concerns
Comment #13
cosmicdreams commentedComment #14
cosmicdreams commentedComment #15
cosmicdreams commentedComment #16
cosmicdreams commentedComment #17
cosmicdreams commented#3345990: Toggle Preview Should Refresh Preview has a fix. Once in we have 1 more blocker to complete then we can focus on phase 2.
Comment #18
cosmicdreams commentedNext Steps
Comment #19
cosmicdreams commentedComment #20
cosmicdreams commentedV1 is at alpha. We can tweak it some more. The majority of our focus is on Phase 2
We haven't heard much from the community about whether they're excited about V1 and need it to be polished more. But if they do we can put some effort into here.
I for one, am very excited about what is coming in Phase 2. If it appears that we have low uptake on v1 we could just squash it and have 2.0.x be our sole release.
Comment #21
martijn de witSaw a demo via Twitter. It looks very promising all. I think it up to the real editors if they gone use / love this new module.
Comment #22
cosmicdreams commentedThank you! A new demo video may come later this week. We'll be able to share the recent wins that have landed. Keep following the progress here
Comment #23
brianperryMarking as fixed since we're well past 1.0 at this point.