13 Jun
2012
13 Jun
'12
1:58 p.m.
On Wed, Jun 13, 2012 at 11:28 AM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
On Tue, Jun 12, 2012 at 9:03 PM, Ecaterina Moraru
(Valica)
<valicac(a)gmail.com> wrote:
* The argument that this feature needs to be more visible applies to
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. 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/…
Var 2: Expanded macros without header ( more WYSIWYG style ) + actions
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MacrosOptions/…
Collapsed view:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MacrosOptions/…
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs