+1 for the general dialog anyway On Mon, Jan 5, 2009 at 3:27 PM, Thomas Mortagne <[email protected]> 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 <[email protected]> wrote:

...

Hi,

I've made a mockup for the macro dialog in the WYSIWYG editor : http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialogs...

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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

-- Thomas Mortagne

Hi JV, On Jan 5, 2009, at 6:52 PM, Jean-Vincent Drean wrote:

On Mon, Jan 5, 2009 at 3:27 PM, Vincent Massol <[email protected]> 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.

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 :)

...

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

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?

...

* Rendered macros

We must support them as well as "placeholder macros" IMO.

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.

...

* 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 ?

That's what we had discussed. Now I don't see that button in your UI proposal.

...

* 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.

Thanks -Vincent

On Jan 5, 2009, at 8:50 PM, Jean-Vincent Drean wrote:

On Mon, Jan 5, 2009 at 7:19 PM, Vincent Massol <[email protected]> wrote:

...

...

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 :)

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.

...

...

...

* Rendered macros

We must support them as well as "placeholder macros" IMO.

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).

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 | | | --------------------------------------------

-1 from me Doesn't work for inline macros and take up too much space. It's no longer WYSIWYG. Thanks -Vincent

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 ?

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.

...

...

...

* 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.

See the ascii art above.

Thanks, JV.

On Mon, Jan 5, 2009 at 3:45 PM, Marius Dumitru Florea <[email protected]> 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.

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:

...

Hi,

I've made a mockup for the macro dialog in the WYSIWYG editor : http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialogs...

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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost