5 Jan
2009
5 Jan
'09
3:11 p.m.
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
JV.
5 Jan
5 Jan
3:27 p.m.
How do you get the different macro categories ("Presentstion",
"Development") ? Is it an enum or each macro can define its category
with a custom String in its descriptor ? And in that case is "Code"
means you know the content will be code because it's a macro of
category "Development" or just "Code" is the label for any macro (in
that case I would prefer "Content") ?
On Mon, Jan 5, 2009 at 3:11 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
3:31 p.m.
+1 for the general dialog anyway
On Mon, Jan 5, 2009 at 3:27 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
How do you get the different macro categories
("Presentstion",
"Development") ? Is it an enum or each macro can define its category
with a custom String in its descriptor ? And in that case is "Code"
means you know the content will be code because it's a macro of
category "Development" or just "Code" is the label for any macro
(in
that case I would prefer "Content") ?
On Mon, Jan 5, 2009 at 3:11 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
--
Thomas Mortagne
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
4:32 p.m.
On Jan 5, 2009, at 3:27 PM, Thomas Mortagne wrote:
How do you get the different macro categories
("Presentstion",
"Development") ? Is it an enum or each macro can define its category
with a custom String in its descriptor ? And in that case is "Code"
means you know the content will be code because it's a macro of
category "Development" or just "Code" is the label for any macro
(in
that case I would prefer "Content") ?
I think we need to add the notion of category in the rendering for
macros with the ability to specify several categories for a given macro.
Thanks
-Vincent
On Mon, Jan 5, 2009 at 3:11 PM, Jean-Vincent Drean <jv(a)xwiki.com>
wrote:
> Hi,
>
> I've made a mockup for the macro dialog in the WYSIWYG editor :
> http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
>
> I've assumed that using a tree to browse macros was :
> - Scalable.
> - Consistent with link dialogs.
> Shout if you think about another way of displaying them.
>
> Note that the second dialog is generated dynamically and will vary a
> lot according to macros needs (see 2 bis), its layout must remain as
> simple as possible.
>
> Here's my +1.
>
> JV.
3:27 p.m.
On Jan 5, 2009, at 3:11 PM, Jean-Vincent Drean wrote:
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
I'd really like to have a way to filter/search macros. I want to be
able to type "ht" and all macros containing "ht" in their names or
description or parameter description would be listed.
Re macros we also need to define behaviors:
* Rendered macros
* Outline around macro block when cursor is inside a macro rendered
content
* Ability to double click inside macro content and it opens up the
edit dialog box?
* When is the rendered macro content refreshed? Manual refresh button?
(the easiest I think)
* What about macros that take a lot of space like an {{include}}? Do
we offer a button to "fold"/"unfold" macros?
Otherwise +1
Thanks
-Vincent
http://xwiki.com
http://massol.net
http://xwiki.org
6:52 p.m.
On Mon, Jan 5, 2009 at 3:27 PM, Vincent Massol <vincent(a)massol.net> wrote:
I'd really like to have a way to filter/search macros. I want to be
able to type "ht" and all macros containing "ht" in their names or
description or parameter description would be listed.
I guess this could be done with a suggest input at the bottom as seen
in the link dialogs mockup.
I suggest to put this in the "possible improvements to keep in mind"
category since it's a power user need and we don't have that much
macros ftm.
Re macros we also need to define behaviors:
I thought this had been voted before but it was a proposal :
http://markmail.org/message/zz2iyc6lhjgtvwja
* Rendered macros
We must support them as well as "placeholder macros" IMO.
* Outline around macro block when cursor is inside a
macro rendered
content
I think we should always keep this outline to have a visual hint for
"everything in this box is not editable".
* Ability to double click inside macro content and it
opens up the
edit dialog box?
+0.
* When is the rendered macro content refreshed? Manual
refresh button?
(the easiest I think)
From the thread linked aboved I understood that
we'd have to refresh
the whole page ? Do you suggest to have a top level refresh
button or
did I missed something ?
* What about macros that take a lot of space like an
{{include}}? Do
we offer a button to "fold"/"unfold" macros?
I think this is the kind of macro that should be represented by a
placeholder. Has stated in a previous thread having included document
displayed inline in the editor would distract editors from the page
content itself. This will be also needed by other macros like "map"
(mentioned by Jerome) where having an iframe in our WYSIWYG iframe
could be a problem and, if not, performance would certainly be.
7:19 p.m.
Hi JV,
On Jan 5, 2009, at 6:52 PM, Jean-Vincent Drean wrote:
Yes but I thought we were re-voting on everything in each UI domain.
I'm fine if we agreed about something but I can't find it on
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HMacros
so it wasn't recorded as agreed on. I haven't scanned past
discussions but if you have then maybe you could move the result on
that page for all topics that were agreed on?
I don't understand what a "placeholder macro" is (did you mean "macro
placeholder"?). Maybe you mean a "placeholder mode" which can be
toggled on/off. If so would be nice to include it in the UI proposal
to see where it would be located.
That's what we had discussed. Now I don't see that button in your UI
proposal.
Thanks
-Vincent
On Mon, Jan 5, 2009 at 3:27 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
I'm pretty sure this is not a power user feature. It's like saying
search are for power users... Google.com has probably proven it's not
the case :)
I'd really like to have a way to filter/search macros. I want to be
able to type "ht" and all macros containing "ht" in their names or
description or parameter description would be listed.
I guess this could be done with a suggest input at the bottom as seen
in the link dialogs mockup.
I suggest to put this in the "possible improvements to keep in mind"
category since it's a power user need and we don't have that much
macros ftm. Re macros we
also need to define behaviors:
I thought this had been voted before but it was a proposal :
http://markmail.org/message/zz2iyc6lhjgtvwja * Rendered
macros
We must support them as well as "placeholder macros" IMO. * Outline
around macro block when cursor is inside a macro rendered
content
I think we should always keep this outline to have a visual hint for
"everything in this box is not editable".
* Ability to double click inside macro content
and it opens up the
edit dialog box?
+0.
* When is the rendered macro content refreshed?
Manual refresh
button?
(the easiest I think)
From the thread linked aboved I understood that we'd have to refresh
the whole page ? Do you suggest to have a top level refresh button or
did I missed something ? * What about
macros that take a lot of space like an {{include}}? Do
we offer a button to "fold"/"unfold" macros?
I think this is the kind of macro that should be represented by a
placeholder. Has stated in a previous thread having included document
displayed inline in the editor would distract editors from the page
content itself. This will be also needed by other macros like "map"
(mentioned by Jerome) where having an iframe in our WYSIWYG iframe
could be a problem and, if not, performance would certainly be.
8:50 p.m.
On Mon, Jan 5, 2009 at 7:19 PM, Vincent Massol <vincent(a)massol.net> wrote:
Let me rephrase : since we'll have between, let's say, 10 and 30
macros I think having a search feature is overkill and will be useful
only to power users.
I don't understand what a "placeholder macro" is (did you mean "macro
placeholder"?). Maybe you mean a "placeholder mode" which can be
toggled on/off. If so would be nice to include it in the UI proposal
to see where it would be located.
I meant "macro placeholder", a graphical box (read-only div) appearing
in the wysiwyg instead of the rendered macro.
Macros arguments would be displayed in the same order and with the
same labels as in the edit dialog.
It wouldn't be configurable by the user, the macro itself would
determine if it should be displayed rendered or by a placeholder in
the WYSIWYG.
Examples :
--------------------------------------------
| Macro -- include |
~~~~~~~~~~~~~~~~~~~~~~~~~
| page : Main.WebHome |
--------------------------------------------
--------------------------------------------
| Macro -- map |
~~~~~~~~~~~~~~~~~~~~~~~~~
| location : 10 rue Pernety |
| service : google |
| message : test message |
| size : default |
| zoom : default |
--------------------------------------------
That's what we had discussed. Now I don't see that button in your UI
proposal.
I'll make a proposal for this ASAP.
See the ascii art above.
Thanks,
JV.
I guess this could be done with a suggest input at the bottom as seen
in the link dialogs mockup.
I suggest to put this in the "possible improvements to keep in mind"
category since it's a power user need and we don't have that much
macros ftm.
I'm pretty sure this is not a power user feature. It's like saying
search are for power users... Google.com has probably proven it's not
the case :) * Rendered macros
We must support them as well as "placeholder macros" IMO. >> * Outline around macro block when cursor is
inside a macro rendered
>> content
>
> I think we should always keep this outline to have a visual hint for
> "everything in this box is not editable".
I think it would be even more clear if the rendered macros were
represented within a box like the ones above (just an idea, I don't
know if it is doable) :
--------------------------------------------
| Macro -- Table of content |
~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| Rendered HTML |
| |
--------------------------------------------
WDYT ?
* When is the rendered macro content refreshed? Manual
refresh
button?
(the easiest I think)
From the thread linked aboved I understood that we'd have to refresh
the whole page ? Do you suggest to have a top level refresh button or
did I missed something ? * What about macros that take a lot of space like an
{{include}}? Do
we offer a button to "fold"/"unfold" macros?
I think this is the kind of macro that should be represented by a
placeholder. Has stated in a previous thread having included document
displayed inline in the editor would distract editors from the page
content itself. This will be also needed by other macros like "map"
(mentioned by Jerome) where having an iframe in our WYSIWYG iframe
could be a problem and, if not, performance would certainly be.
9:06 p.m.
On Jan 5, 2009, at 8:50 PM, Jean-Vincent Drean wrote:
I don't understand what a "placeholder macro" is (did you mean "macro
placeholder"?). Maybe you mean a "placeholder mode" which can be
toggled on/off. If so would be nice to include it in the UI proposal
to see where it would be located.
I meant "macro placeholder", a graphical box (read-only div) appearing
in the wysiwyg instead of the rendered macro.
I still believe we should have a toggle button for the placeholder
mode (on/off).
-1 from me
Doesn't work for inline macros and take up too much space. It's no
longer WYSIWYG.
Thanks
-Vincent
On Mon, Jan 5, 2009 at 7:19 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
Let me rephrase : since we'll have between, let's say, 10 and 30
macros I think having a search feature is overkill and will be useful
only to power users.
IMO you're confusing power users and productivity. I don't agree that
novice users are not interested in productivity. Even if it were true
we also want to address "power users" in the wysiwyg editor.
The reason I'm mentioning this here is because I'd like that we have a
builtin filter box in the tree view. I really wanted to have it in the
other tree view and I don't think the suggestion box is good enough.
You're trading a large viewport for filtering with a small combo box.
It doesn't make sense to me.
If we have the filter built in the treeview component then we can have
it all the time for all dialog boxes easily and there's no need to
wait for later.
I guess this could be done with a suggest input at the bottom as
seen
in the link dialogs mockup.
I suggest to put this in the "possible improvements to keep in mind"
category since it's a power user need and we don't have that much
macros ftm.
I'm pretty sure this is not a power user feature. It's like saying
search are for power users... Google.com has probably proven it's not
the case :) * Rendered
macros
We must support them as well as "placeholder macros" IMO. Macros arguments would be displayed in the same order
and with the
same labels as in the edit dialog.
It wouldn't be configurable by the user, the macro itself would
determine if it should be displayed rendered or by a placeholder in
the WYSIWYG.
-1
It completely depends on the context. As importantly it breaks the
notion of WYSIWYG.
Examples :
--------------------------------------------
| Macro -- include |
~~~~~~~~~~~~~~~~~~~~~~~~~
| page : Main.WebHome |
--------------------------------------------
--------------------------------------------
| Macro -- map |
~~~~~~~~~~~~~~~~~~~~~~~~~
| location : 10 rue Pernety |
| service : google |
| message : test message |
| size : default |
| zoom : default |
--------------------------------------------
This doesn't work for all inline macros. So you cannot use this layout
for inline macros. It also doesn't scale. In placeholder mode we
should only display like the first parameter (Macro:include
page:Main.WebHome) and display all parameters in a tooltip of when
editing the macro.
We really need a placeholder mode and I would only implement it as a
second step (priority lower than implementing the rendered mode).
>> *
Outline around macro block when cursor is inside a macro rendered
>> content
>
> I think we should always keep this outline to have a visual hint for
> "everything in this box is not editable".
I think it would be even more clear if the rendered macros were
represented within a box like the ones above (just an idea, I don't
know if it is doable) :
--------------------------------------------
| Macro -- Table of content |
~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| Rendered HTML |
| |
-------------------------------------------- WDYT ?
That's what we had discussed. Now I don't see that button in your UI
proposal.
I'll make a proposal for this ASAP.
See the ascii art above.
Thanks,
JV.
* When is the rendered macro content refreshed? Manual
refresh
button?
(the easiest I think)
From the thread linked aboved I understood that we'd have to refresh
the whole page ? Do you suggest to have a top level refresh button
or
did I missed something ? * What about macros that take a lot of space like an
{{include}}?
Do
we offer a button to "fold"/"unfold" macros?
I think this is the kind of macro that should be represented by a
placeholder. Has stated in a previous thread having included
document
displayed inline in the editor would distract editors from the page
content itself. This will be also needed by other macros like "map"
(mentioned by Jerome) where having an iframe in our WYSIWYG iframe
could be a problem and, if not, performance would certainly be. 
3:45 p.m.
+1
What about the Macro entry on the menu bar? Will it have the same
sub-items as in the tree?
Thanks,
Marius
Jean-Vincent Drean wrote:
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:55 p.m.
On Mon, Jan 5, 2009 at 3:45 PM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
+1
What about the Macro entry on the menu bar? Will it have the same
sub-items as in the tree?
AFAIR this has been discussed in the past and the idea was to put
(read: hardcode) the most used macros (ex: TOC) in the menu bar.
4:06 p.m.
On Mon, Jan 5, 2009 at 3:11 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
+1 as well.
Guillaume
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://blog.xwiki.com/
4:15 p.m.
+1 for the general layout.
As a side note, I'd like we consider introducing a hook for macros to
provide their own insertion dialog (in place of the generic 2bis). This
would allow to have restrictions on parameter combinations. (for
example: user can define a value for param2 only if param1 has been set
to a specific value - this is the case for the map macro : we could say
width and height parameters are meaningless unless the size parameter
has been set to "custom"). I suppose we could also define those rules in
the rendering with new annotations and still use a generic dialog, but
it would probably be overkill compared to custom dialogs provided by the
macro itself.
Anyway, just an idea.
Jerome.
Jean-Vincent Drean wrote:
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:28 p.m.
On Jan 5, 2009, at 4:15 PM, Jerome Velociter wrote:
+1 for the general layout.
As a side note, I'd like we consider introducing a hook for macros to
provide their own insertion dialog (in place of the generic 2bis).
This
would allow to have restrictions on parameter combinations. (for
example: user can define a value for param2 only if param1 has been
set
to a specific value - this is the case for the map macro : we could
say
width and height parameters are meaningless unless the size parameter
has been set to "custom"). I suppose we could also define those
rules in
the rendering with new annotations and still use a generic dialog, but
it would probably be overkill compared to custom dialogs provided by
the
macro itself.
Yes but Dialog is about UI. We cannot have UI in the macro itself. We
could have separate WYSIWYG extensions but it would be done in the
WYSIWYG not in the Rendering/Macro.
What we can have in macros are constraints/validation information.
Thanks
-Vincent
Anyway, just an idea.
Jerome.
Jean-Vincent Drean wrote:
> Hi,
>
> I've made a mockup for the macro dialog in the WYSIWYG editor :
> http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
>
> I've assumed that using a tree to browse macros was :
> - Scalable.
> - Consistent with link dialogs.
> Shout if you think about another way of displaying them.
>
> Note that the second dialog is generated dynamically and will vary a
> lot according to macros needs (see 2 bis), its layout must remain as
> simple as possible.
>
> Here's my +1.
>
> JV.
6 Jan
6 Jan
10:27 a.m.
It's good to keep that feature in mind but I don't think macro
developers will have a lot of time to develop their own insertion screen.
We should focus our priority more on having the right list of "field
types" in the definition system for macros.
On this subject here are my comments with a general +1 on the dialog:
0/ This system should support velocity macros right from the start. This
is the easiest way to write macros. We should even have a page in the
admin to manage the libraries (including the velocity macros) and add a
new one using a simple form. This would create a descriptor for the
library/macros and make the macro available right from the start. This
is a good way to make XWiki extensible. We could even have a button to
propose the macro for inclusing on http://code.xwiki.org.
And the macro system should be connected to the Application Manager or
better name Extension Manager.
1/ Should category be category or should it be library (corresponding to
a set of macros provided by a installable library). Or should we have
both ?
For the sake of simplicity I think we could only have library and then
introduce a category later (but how is the category list managed).
2/ There should be a nice description for the library/category and a
link to documentation. This can appear as a toolip or it could be
possible to click on the category/library and the next screen would show
the list of macros with the description of the macro and at the top the
description of the category/library. The category/library could have a
screenshot or icon for visual indentification.
3/ There should be a description for each macro. This can appear as a
tooltip.
4/ Each param of a macro should have a description, a name, a pretty
name (language based), a default value and wether it is required. The
default value can be displayed under the field.
5/ The non editable macro bloc in the wysiwyg that would show the result
in wysiwyg is cool but could be a phase 2 feature.
6/ Even double clicking to reedit is a phase 2 feature.
Ludovic
Jerome Velociter a écrit :
+1 for the general layout.
As a side note, I'd like we consider introducing a hook for macros to
provide their own insertion dialog (in place of the generic 2bis). This
would allow to have restrictions on parameter combinations. (for
example: user can define a value for param2 only if param1 has been set
to a specific value - this is the case for the map macro : we could say
width and height parameters are meaningless unless the size parameter
has been set to "custom"). I suppose we could also define those rules in
the rendering with new annotations and still use a generic dialog, but
it would probably be overkill compared to custom dialogs provided by the
macro itself.
Anyway, just an idea.
Jerome.
Jean-Vincent Drean wrote:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
JV.
_______________________________________________
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
5829
days inactive
5830
days old
14 comments
8 participants
participants (8)
-
Guillaume Lerouge -
Jean-Vincent Drean -
Jean-Vincent Drean -
Jerome Velociter -
Ludovic Dubost -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol