[xwiki-devs] [UX][Proposal] Improvements for WYSIWYG macros
Hi, This is a proposal regarding the WYSIWYG macros: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MacrosOptions Other discussions: - Making it user-friendly to edit pages with macros for new users (was Re: Need some Help & Explanations) http://xwiki.markmail.org/thread/rnhe6tl3x7snquz7 Thanks, Caty
Hi Caty, On Jun 12, 2012, at 8:03 PM, Ecaterina Moraru (Valica) wrote:
Hi,
This is a proposal regarding the WYSIWYG macros: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MacrosOptions
Other discussions: - Making it user-friendly to edit pages with macros for new users (was Re: Need some Help & Explanations) http://xwiki.markmail.org/thread/rnhe6tl3x7snquz7
Sounds good in general. One issue: there's no notion of nested macros. Each macro is responsible for its content and it's a black box for anyone else. What we discussed in the past is to add the ability to register special editors for macros and use that editor for editing the macro's content. The Macro descriptor would allow providing a hint which would correspond to a specific Macro Content Editor and if none is specified default to the default editor. For example Macros having wiki content could use the hint "wiki". Thanks -Vincent
On 06/12/2012 02:03 PM, Ecaterina Moraru (Valica) wrote:
Hi,
This is a proposal regarding the WYSIWYG macros: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MacrosOptions
Other discussions: - Making it user-friendly to edit pages with macros for new users (was Re: Need some Help & Explanations) http://xwiki.markmail.org/thread/rnhe6tl3x7snquz7
This goes a bit against true WYSIWYG, since in view mode it will look different. I'm not saying that it's a bad thing, on the contrary, I welcome the change. I'd like to see an expanded inline macro. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Tue, Jun 12, 2012 at 9:03 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
This is a proposal regarding the WYSIWYG macros: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MacrosOptions
It's an interesting proposal and it's good you bring this subject up, but.. :) I'm not sure about putting Collapse/Expand Macros on the tool bar because: * The tool bar is a place for features that don't have a menu or that are frequently used. * The argument that this feature needs to be more visible applies to any entry from the menu that is not on the tool bar. This feature is certainly less important than creating a link or inserting an image. I don't think crowding the tool bar is a good idea. * Why text buttons and not icons? * The tool bar is generic. If the macro plugin can put some buttons on the right end of the tool bar then any WYSIWYG editor plugin should be able to do it. We end up with a tool bar split in two. What would be the rule (for a plugin) to put buttons on the left side versus right side of the tool bar? * I don't think it looks nice when the tool bar has multiple lines (which can happen if you activate all the plugins and feaures and reduce the browser window size or use the editor in a form that doesn't take the full page width, e.g. class="xform half" or with both left and right panels). I'm fine with displaying the macro header for block macros (including macro parameters) but I don't think it changes anything for macros with large output. If the macro output spans across multiple 'pages' and you scroll then the macro header is hidden. Also, in-line macros can't have the header. I'm not fond of displaying the background for the macro output. The dashed border and the highlight are enough IMO. Displaying a context tool bar when clicking on the macro should work with both in-line and block macros. This can be made generic and reused for links, images, etc. Same as Sergiu, I'd like to see how you handle in-line macro, i.e. macros inside the text (across multiple lines). A single macro in a table cell is still a block macro. Same as Vincent, we can't really display nested macros. Thanks, Marius
Other discussions: - Making it user-friendly to edit pages with macros for new users (was Re: Need some Help & Explanations) http://xwiki.markmail.org/thread/rnhe6tl3x7snquz7
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Specifically for {{include}} and {{display}} macros, maybe it could be interesting to have the possibility to directly edit the targeted document. I mean, if I choose "edit content" for such macro, the whole wysiwyg editor content is replaced by the content from the targeted document, something similar to what we have in wiki edit mode for included documents. If I just choose "edit" or "edit parameters", then I can update the targeted reference and other options of the macros. The same could be done for macros that have content, the content would replace and fill the wysiwyg editor, maybe with navigation option to move back and forth the hierarchy of macros contents. I could even be "trans-editors", for example you could edit the inner content in wysiwyg then decide to move to wiki edit mode. WDYT ? Jeremie 2012/6/13 Marius Dumitru Florea <[email protected]>:
On Tue, Jun 12, 2012 at 9:03 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
This is a proposal regarding the WYSIWYG macros: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MacrosOptions
It's an interesting proposal and it's good you bring this subject up, but.. :)
I'm not sure about putting Collapse/Expand Macros on the tool bar because:
* The tool bar is a place for features that don't have a menu or that are frequently used. * The argument that this feature needs to be more visible applies to any entry from the menu that is not on the tool bar. This feature is certainly less important than creating a link or inserting an image. I don't think crowding the tool bar is a good idea. * Why text buttons and not icons? * The tool bar is generic. If the macro plugin can put some buttons on the right end of the tool bar then any WYSIWYG editor plugin should be able to do it. We end up with a tool bar split in two. What would be the rule (for a plugin) to put buttons on the left side versus right side of the tool bar? * I don't think it looks nice when the tool bar has multiple lines (which can happen if you activate all the plugins and feaures and reduce the browser window size or use the editor in a form that doesn't take the full page width, e.g. class="xform half" or with both left and right panels).
I'm fine with displaying the macro header for block macros (including macro parameters) but I don't think it changes anything for macros with large output. If the macro output spans across multiple 'pages' and you scroll then the macro header is hidden. Also, in-line macros can't have the header.
I'm not fond of displaying the background for the macro output. The dashed border and the highlight are enough IMO.
Displaying a context tool bar when clicking on the macro should work with both in-line and block macros. This can be made generic and reused for links, images, etc.
Same as Sergiu, I'd like to see how you handle in-line macro, i.e. macros inside the text (across multiple lines). A single macro in a table cell is still a block macro.
Same as Vincent, we can't really display nested macros.
Thanks, Marius
Other discussions: - Making it user-friendly to edit pages with macros for new users (was Re: Need some Help & Explanations) http://xwiki.markmail.org/thread/rnhe6tl3x7snquz7
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Jun 13, 2012 at 11:28 AM, Marius Dumitru Florea < [email protected]> wrote:
On Tue, Jun 12, 2012 at 9:03 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
This is a proposal regarding the WYSIWYG macros: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MacrosOptions
It's an interesting proposal and it's good you bring this subject up, but.. :)
I'm not sure about putting Collapse/Expand Macros on the tool bar because:
* The tool bar is a place for features that don't have a menu or that are frequently used.
* The argument that this feature needs to be more visible applies to
any entry from the menu that is not on the tool bar. This feature is certainly less important than creating a link or inserting an image. I don't think crowding the tool bar is a good idea.
Toolbars offer easily access to features. Usually in toolbars you duplicate the functionality that it's in the menus (rarely the toolbar is the only place where you can find a certain functionality). Also some toolbar are customizable and let the user select what he needs; other times the toolbar are contextual and change accordingly to the actions done by users (like detecting if the page has macros put the macros actions in the toolbar so they are easily accessible). IMO macros are an important feature, but yes I agree that we don't need to crowd the toolbar. The problem is that going up and down in the menus to do collapse/expand for the macros can be quite annoying. One thing that I don't like in particular is the 'auto-magic' of appearances and disappearances for 'Collapse/Expand' and 'Collapse All/Expand All'. The need to get in a macro or get out of the macro in order to get the functionality is annoying.
* Why text buttons and not icons?
Well this is because this is a wireframe and I found it to be more important to highlight and communicate the functionality than to go into details. If I would have put just an icon on that toolbar I'm sure some people would have missed it (I'm quite sure not everyone have seen it like it is now :) ).
* The tool bar is generic. If the macro plugin can put some buttons on the right end of the tool bar then any WYSIWYG editor plugin should be able to do it. We end up with a tool bar split in two. What would be the rule (for a plugin) to put buttons on the left side versus right side of the tool bar?
IMO macros are important especially for XWiki. Regarding the addition of buttons into the toolbar, in any other desktop application you can customize the toolbar and decide where you want to put some icons: so is not just about left or right, you could put icons anywhere, but I think this is another discussion. Also we already have an icon for "Import external content" which IMO is not that generic.
* I don't think it looks nice when the tool bar has multiple lines (which can happen if you activate all the plugins and feaures and reduce the browser window size or use the editor in a form that doesn't take the full page width, e.g. class="xform half" or with both left and right panels).
The case you mentioned depends on the preference of the administrator, because he will be the one to activate all this functionality. If he needs it and doesn't mind spanning on multiple lines, than that's ok. Again another discussion.
I'm fine with displaying the macro header for block macros (including macro parameters) but I don't think it changes anything for macros with large output. If the macro output spans across multiple 'pages' and you scroll then the macro header is hidden. Also, in-line macros can't have the header.
I'm not fond of displaying the background for the macro output. The dashed border and the highlight are enough IMO.
I think this is the most important change in this proposal (according to what can be easily changed and with fewer implications). Having a different bakground color states that the content has a special status. The highlight and the dashed border are good. The only problem is that they appear only when the user hovers the element. If the content is very large and you are scrolling down there is no way someone could make the distinction between what is content and what comes from a macro. And this is especially the case for the HTML macro or any other macro that generates content. One exercise could be to go through XWiki.XWikiSyntax and try to count how many macros are in the document. You would need to hover each line of the content in order to activate the 'dashed border' and see that in some places you have macros (I'm talking especially in the 'Expand All' state).
Displaying a context tool bar when clicking on the macro should work with both in-line and block macros. This can be made generic and reused for links, images, etc.
Same as Sergiu, I'd like to see how you handle in-line macro, i.e. macros inside the text (across multiple lines). A single macro in a table cell is still a block macro.
Var 1: Expanded macros + header (block, inline) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MacrosOptions/V... Var 2: Expanded macros without header ( more WYSIWYG style ) + actions http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MacrosOptions/V... Collapsed view: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MacrosOptions/i...
Same as Vincent, we can't really display nested macros.
This was an idea that I thought it was interesting and also I tried to imagine how it would look like with this proposal structure. Thanks, Caty
Thanks, Marius
Other discussions: - Making it user-friendly to edit pages with macros for new users (was
Re:
Need some Help & Explanations) http://xwiki.markmail.org/thread/rnhe6tl3x7snquz7
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Jun 13, 2012 at 2:58 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Jun 13, 2012 at 11:28 AM, Marius Dumitru Florea < [email protected]> wrote:
On Tue, Jun 12, 2012 at 9:03 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
This is a proposal regarding the WYSIWYG macros: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MacrosOptions
It's an interesting proposal and it's good you bring this subject up, but.. :)
I'm not sure about putting Collapse/Expand Macros on the tool bar because:
* The tool bar is a place for features that don't have a menu or that are frequently used.
* The argument that this feature needs to be more visible applies to
any entry from the menu that is not on the tool bar. This feature is certainly less important than creating a link or inserting an image. I don't think crowding the tool bar is a good idea.
Toolbars offer easily access to features. Usually in toolbars you duplicate the functionality that it's in the menus (rarely the toolbar is the only place where you can find a certain functionality).
Sure.
Also some toolbar are customizable and let the user select what he needs; other times the toolbar are contextual and change accordingly to the actions done by users (like detecting if the page has macros put the macros actions in the toolbar so they are easily accessible).
Sure, would be nice to have the tool bar configuration at user level and also to display tool bar features based on the current context.
IMO macros are an important feature, but yes I agree that we don't need to crowd the toolbar. The problem is that going up and down in the menus to do collapse/expand for the macros can be quite annoying.
We have a shortcut key.
One thing that I don't like in particular is the 'auto-magic' of appearances and disappearances for 'Collapse/Expand' and 'Collapse All/Expand All'. The need to get in a macro or get out of the macro in order to get the functionality is annoying.
I understand.
* Why text buttons and not icons?
Well this is because this is a wireframe and I found it to be more important to highlight and communicate the functionality than to go into details. If I would have put just an icon on that toolbar I'm sure some people would have missed it (I'm quite sure not everyone have seen it like it is now :) ).
Ok :)
* The tool bar is generic. If the macro plugin can put some buttons on the right end of the tool bar then any WYSIWYG editor plugin should be able to do it. We end up with a tool bar split in two. What would be the rule (for a plugin) to put buttons on the left side versus right side of the tool bar?
IMO macros are important especially for XWiki. Regarding the addition of buttons into the toolbar, in any other desktop application you can customize the toolbar and decide where you want to put some icons: so is not just about left or right, you could put icons anywhere, but I think this is another discussion. Also we already have an icon for "Import external content" which IMO is not that generic.
When I said the tool bar is generic I wasn't referring to the icons placed on it. By 'generic' I meant that any plugin can put icons on it. Right now the tool bar is a list of features displayed from left to right. What you propose is to have two lists of features, one on the left and the other on the right. My question is what is the meaning of the 'left' vs. the 'right' side.
* I don't think it looks nice when the tool bar has multiple lines (which can happen if you activate all the plugins and feaures and reduce the browser window size or use the editor in a form that doesn't take the full page width, e.g. class="xform half" or with both left and right panels).
The case you mentioned depends on the preference of the administrator, because he will be the one to activate all this functionality. If he needs it and doesn't mind spanning on multiple lines, than that's ok. Again another discussion.
Sure, but the design should take this case into account too..
I'm fine with displaying the macro header for block macros (including macro parameters) but I don't think it changes anything for macros with large output. If the macro output spans across multiple 'pages' and you scroll then the macro header is hidden. Also, in-line macros can't have the header.
I'm not fond of displaying the background for the macro output. The dashed border and the highlight are enough IMO.
I think this is the most important change in this proposal (according to what can be easily changed and with fewer implications). Having a different bakground color states that the content has a special status.
The highlight and the dashed border are good. The only problem is that they appear only when the user hovers the element. If the content is very large and you are scrolling down there is no way someone could make the distinction between what is content and what comes from a macro. And this is especially the case for the HTML macro or any other macro that generates content.
The macro output can have its own background color (e.g. box, code). I feel that marking the macro output with a background color reduces too much the WYSIWYG level.
One exercise could be to go through XWiki.XWikiSyntax and try to count how many macros are in the document. You would need to hover each line of the content in order to activate the 'dashed border' and see that in some places you have macros (I'm talking especially in the 'Expand All' state).
I don't think knowing the macro count is very important but I understand your point. We can have an option to highlight the output of all macros (either on the menu or on the tool bar). I'd vote for this option to be unset by default (i.e. by default you have full WYSIWYG).
Displaying a context tool bar when clicking on the macro should work with both in-line and block macros. This can be made generic and reused for links, images, etc.
Same as Sergiu, I'd like to see how you handle in-line macro, i.e. macros inside the text (across multiple lines). A single macro in a table cell is still a block macro.
Var 1: Expanded macros + header (block, inline) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MacrosOptions/V...
I still don't see a real in-line macro, such as: Blah blah {{foo}}this is an in-line macro{{/foo}} blah blah {{bar}}this in-line macro spans across multiple lines{{/bar}} blah blah.
Var 2: Expanded macros without header ( more WYSIWYG style ) + actions http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MacrosOptions/V...
Ok, I see the second Info macro. Personally, I prefer that expanded macros don't show the header and that the background (or any other macro marker) appears only on hover or when the "highlight macros" option is activated. I'm +1 for the context tool bar (reusable for other features like links or images). Thanks, Marius
Collapsed view: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MacrosOptions/i...
Same as Vincent, we can't really display nested macros.
This was an idea that I thought it was interesting and also I tried to imagine how it would look like with this proposal structure.
Thanks, Caty
Thanks, Marius
Other discussions: - Making it user-friendly to edit pages with macros for new users (was
Re:
Need some Help & Explanations) http://xwiki.markmail.org/thread/rnhe6tl3x7snquz7
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Ecaterina Moraru (Valica) -
Jeremie BOUSQUET -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol