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/Var%20IM1%20-%20with%20headers.png 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/Var%20IM2%20-%20without%20headers.png 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/inlineMacros.png > > > >> >> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
