12 Jun
2012
12 Jun
'12
8:03 p.m.
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
12 Jun
12 Jun
8:16 p.m.
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
13 Jun
13 Jun
6:57 a.m.
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/
10:28 a.m.
On Tue, Jun 12, 2012 at 9:03 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:12 a.m.
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 <mariusdumitru.florea(a)xwiki.com>om>:
On Tue, Jun 12, 2012 at 9:03 PM, Ecaterina Moraru
(Valica)
<valicac(a)gmail.com> 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
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
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
14 Jun
14 Jun
3:33 p.m.
On Wed, Jun 13, 2012 at 2:58 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
Ok :)
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.
Sure, but the design should take this case into account too..
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.
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.
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).
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 :) ). * 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).
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 2: Expanded macros without header ( more WYSIWYG style ) + actions
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/MacrosOptions/…
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/…
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
4530
days inactive
4532
days old
6 comments
5 participants
participants (5)
-
Ecaterina Moraru (Valica) -
Jeremie BOUSQUET -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol