What to do with eip-figure branch?
Document Actions
EiP - Preview Mode
Plan A - Change the workflow to force users into the workspace editor.
Plan B - Drive the users into the workspace editor by removing the add buttons and thus restrict the user to editing existing tags.
Ross is looking at EiP versus EiS usage to see how many users will be made unhappy.
Cameron will investigate adding a new workflow for editing published content.
EiS - Save Mode
Rename "Edit In Place" to "Tag Editor Assistant". This will reduce the WYSIWYG expectations.
Add a check box with label "Enclose in <figure>." (and possibly an explanation of what figure gives you). When checked, hitting Save will add an enclosing <figure> tag with no caption or name. Users can later add caption or name by editing the figure.
Change "Media" label in the Add Here pulldown to "Media/Image".
kupu
We need to address our long term needs for a browser WYSIWYG XML Editor. kupu is an existing XHTML editor that has been integrated into Plone. For our purposes kupu will need major extension to support our CNXML<->XHTML editing needs. Both desired workflows (Manpreet) and technical limitations (Cameron) will need to investigated.
Going forward, limiting our EiP work in favor kupu may be the desired project direction.
Re: What to do with eip-figure branch?
For the text beside checkbox what we wish to convey is:
Enclose in <figure>. Allows optional name, caption, auto-numbering and inclusion in list of figures for printing.
The presentation of that information depends on the visual design.
1) The explanation text could be shown right there in regular font
2) it could be shown there in a smaller font,
3) it could be a pop-up if you click on the "<figure>",
4) there could be a help link next to the checkbox explaining what the figure tag does.
Maybe Max can do some mockups for us to help us decide.
Lastly - we would also have to provide a way to remove the figure wrapper.
Re: What to do with eip-figure branch?
As for the "Enclose in <figure>" idea, it's one I like, but I don't like the idea of telling users about the features they can buy by enclosing it, and then expecting them to know to hit Save and then click on the surrounding figure (and not the same media/table/code tag they were just in) in order to find the new features that figure-wrapping has supposedly bought them. My preference would be to have the "Enclose in <figure>" option open a new section of the current editor (just like the "Edit optional media parameters" link does) which provides inputs for the name and caption. Presumably, unselecting the checkbox would hide the inputs and prevent the figure from wrapping around the media/table/code. While this option would be more WYSIWYG than tags-in-order TEA, it would have the benefit of not getting us into the same problem of two-step editing once the user did click Save and then edited the figure (unless clicking on the surrounding figure either (a) only opens an editing area for the name and caption (followed by Save?) or (b) opens a name-first, media/table/code-second, caption-third editor, both of which I think would be problematic in terms of providing a way to remove the wrapped figure, as Manpreet reminds us is necessary).
In any case, I will mock that up, along with the suggestions Manpreet has made for the text beside the "Enclose in <figure>."
Re: Re: What to do with eip-figure branch?
Brian - would this help in the implementation issues with the server error that we were discussing just before I left?
11 commits vs. 124 total, for 8.9% of edits.